Recomendados
Recomendados
Mais conteúdo relacionado
Mais procurados
Mais procurados (20)
Semelhante a Real World Azure RBAC
Semelhante a Real World Azure RBAC (20)
Mais de Toru Makabe
Mais de Toru Makabe (20)
Último
Último (11)
Real World Azure RBAC
- 1. Real World Azure RBAC 真壁 徹 日本マイクロソフト株式会社 クラウドソリューションアーキテクト 2020/02/12 あなたと仲間を 守るために
- 2. 自己紹介 apiVersion: selfIntroduction/v1 name: “真壁 徹(まかべ とおる)” company: name: “日本マイクロソフト株式会社” role: “クラウド ソリューションアーキテクト” career: - name: “大和総研” - name: ”HP Enterprise” cert : “CNCF Certified Kubernetes Admin.” education: “JAIST(社会人コース 在学中)”
- 3. Azure RBAC おさらい 公式の まとめページがあるくらい 奥深い https://docs.microsoft.com/ja-jp/azure/role-based-access-control/
- 4. Azure RBAC おさらい • 職務 = 役割(ロール) • Azure管理プレーン(*)を通じた Azureリソースへのアクセスを 制御する • ユーザー = 人 + アプリケーショ ン “チーム内で職務を分離し、職 務に必要なアクセス許可のみを ユーザーに付与する仕組み” 公式ドキュメントより ざっくり言うと (*) Azure Resource Manager APIと考えてOK いっぽう、Azureリソース上にのるアプリやデー タはデータプレーンと呼びます(今日は触れません)
- 5. Azure RBACおさらい 何のため 誰のため “データ アクセスにセキュリティ ポリシーを適用する組織では、必知 事項と最小権限のセキュリティ原則に基づいてアクセスを制限するこ とが不可欠です” 公式ドキュメント “Azure の ID 管理とアクセス制御セキュリティのベスト プラクティス“より • 必知事項 = 知る必要がある人だけがアクセスできる • 最小権限 = 役割ごとに必要な操作を明確に定義し、限定する • 外部からの侵入だけでなく、内部アクセスからもリソースを保護する • 悪意ある操作だけでなく、過失からもリソースを保護する • リソースだけでなく、仲間を過失から守る
- 6. 仲間を守る データセンター/サービス障害の多くは 人とその行動に関連している • 実は人ではなくプロセスや環境 が原因であることが多いが… • 故意ではなくとも当事者の心理 的ダメージは大きい • でも技術の神は手を動かした人 に微笑む • RBACはそんな仲間を守るための 仕組みでもある “According to the data, the vast majority of data center failures are caused by human error. Some industry experts report numbers as high as 75%, but Uptime Institute generally reports about 70% based on the wealth of data we gather continuously.“ How to avoid outages: Try harder! - Uptime Institute より
- 7. Azure RBAC おさらい • Principal: 校長、社長、主体、主 犯 • セキュリティプリンシパル = ア クセス権の付与対象となる主体 のこと • 主体は人だけではない (Azureリ ソースを操作する デプロイメン ト支援アプリなど) セキュリティ プリンシパル 人に 割当 アプリに 割当 https://docs.microsoft.com/ja-jp/azure/role-based-access-control/overview
- 8. Azure RBAC おさらい • そのロールがAzureのリソース 種別ごとに、できる操作/できな い操作を定義 (read、write、 action、delete) • 組み込み(ビルトイン)ロールが 多数提供されている • カスタムロールを作ることもで きる ロール定義 https://docs.microsoft.com/ja-jp/azure/role-based-access-control/overview
- 9. Azure RBAC おさらい • 仮想マシンやストレージなど、 各リソースにまで対象を絞れる • 範囲を広げてリソースグループ、 サブスクリプション、管理グ ループ全体も対象にできる • きめ細かさと設計、設定、維持 の容易さはトレードオフ スコープ https://docs.microsoft.com/ja-jp/azure/role-based-access-control/overview
- 10. Azure RBAC おさらい ロールの割り当て • セキュリティプリンシパルに • スコープを指定して • ロールを割り当てる https://docs.microsoft.com/ja-jp/azure/role-based-access-control/overview
- 11. Azure RBAC おさらい • RBACはどのようなリソースで あっても操作の定義は同じ(read、 write、action、delete) • 各リソースには様々なプロパ ティがあり、それに応じて制御 できるのがPolicy • 例: 仮想マシンのサイズを限定、 NICのサブネットを限定 “Azure Policy は、既存のリ ソースについて、デプロイ中の プロパティに焦点を当てます。 Azure Policy では、リソースの 種類や場所などのプロパティが 制御されます” 公式ドキュメントより Azure Policy とRBACの違い 2つは組み合わせて使う
- 12. • 原則は、必知事項と最小権限 • しかし、細かく管理しすぎると複雑になる • 複雑すぎる仕組みはインシデントの元 RBACの原則と現実 いかにバランスをとるか
- 14. ケース1. 利用者も管理者も俺 あなたなら どうRBACする • やりたい放題が許される • リソースを壊してしまっても他 人に迷惑をかけない Subscription
- 16. ケース2. 仲間が増える あなたなら どうRBACする • チーム運用の初期でありがち • チームはお互いをよく知り、信 頼関係がある • 試行錯誤中なので強い権限が欲 しい • 落ち着いたら一括で権限を絞り たいので、チームをまとめて定 義しておきたい
- 17. ケース2. 仲間が増える 例 • Azure ADグループに Contributorを割り当てる • Ownerの数はアクセス権付与フ ローが滞らない程度の最小限に • 監査証跡は考慮する(Activity Logの保管とLog Analyticsへの 接続など) Owner Contributor Azure AD Group
- 18. ケース3. DevとOpsが分かれる あなたなら どうRBACする • この辺から工夫が要る • Devを縛るのではなく、意図せ ぬ操作と失敗からDevを守る意 識で • Devに本当に必要な権限は何か? を議論する(例として Application Insightsの管理権限 を必要とする) Ops Dev Application Insights Resource Group
- 19. ケース3. DevとOpsが分かれる 例 • まずは役割を決め、必要に応じて 役割を追加(RBACは足し算) • [議論]スコープをリソースやリ ソースグループに限定するべきか • [議論]本番と非本番を分けるか • ここでサブスクリプションとリ ソースグループの設計がジャブの ように効いてくる Ops Dev A.I. Component Contributor Owner
- 21. サブスクリプション戦略を事前に考えておこう いまは要らなくても いつか必要な日が来る • サブスクリプションを本番と 非本番で分けておけば解決す る問題は多い • アプリ(システム)で分けるとさ らに分離度は高い • 管理グループを活用してRBAC 設定を継承し、手間を省く 公式ドキュメント “複数の Azure サブスクリプショ ンでの拡張“より
- 22. ケース4. デプロイに強い権限が必要 あなたなら どうRBACする • デプロイツールで環境を一括作 成したい • そのためには強い権限(サブスク リプションレベル)が必要 • 社外パートナーもチームに参加 • 本番環境でパートナーが強い権 限を持たずに済むようにしたい Ops Partner Dev/Ops Resource Group
- 23. ケース4. デプロイに強い権限が必要 例 • 人ではなくパイプライン、ツー ルに権限を付与する(サービスプ リンシパル、マネージドID) • パートナーは非本番で検証した コードをリポジトリでプルリク エスト • マージ後、自動デプロイする Ops Partner Dev/Ops Resource Group Owner Contributor
- 24. FAQ トラブル対応時など、パートナーさんへ本番へのアクセスを一時的に許可したい やり口 おすすめ度 なぜ そのたびにIDを作り権限を付与 する × トラブルでプレッシャーがかか る時に、その作業がトラブりが ち、ID消し忘れがち、そのIDを 使いまわ(略 がち IDを事前に作り権限を付与して おき、使いまわ(略 × 誰の操作か証跡が取れない PCI DSSなど使いまわ(略 を禁じ ている基準もある パートナーさんのIDに一時的に 権限を付与する △ トラブル対応後に権限取り消し を忘れがち PIM(Privileged Identity Management)でパートナーさん のIDに一時的に権限を付与する 〇 期限を切って権限を付与できる
- 25. ケース5. 複数の役割、複数のパートナー企業 あなたなら どうRBACする • DevがPoCで使ったオレオレ Azure ADテナントに住んでおり、 その存続を主張 • パートナー企業が複数に Ops Partner A Dev/Ops Resource Group Partner B Dev/Ops Dev
- 26. ケース5. 複数の役割、複数のパートナー企業 例でなく論点を挙げます じっくり考えてみましょう • Azure ADテナントは統合? それぞれにユーザーを登録? • パートナー企業が使う環境毎にサブスクリプションを分けるべき? • リソースグループで分割してみる? • 本番へのユーザーアクセスはパイプライン経由のみにすればOK? • いっそ内製色を強めて、パートナーさんにはそのグループへ入って もらう? • 将来、他のチームやプロジェクトが追加されても破綻しない?
- 29. FAQ Azure Blueprint や Azure Lighthouse で解決できそうな気がしています お目が高い。 RBACを理解し、サブスクリプション/リソースグループ設計を再考し、 組織やパートナーさんとの関係に想いを馳せた後に ぜひご検討を。 Azure Blueprint とは Azure Lighthouse とは 機会があれば 別途 解説の場を。
- 30. おすすめドキュメント このプレゼンで触れたものの他に • Azure 向けの Microsoft Cloud 導入フレームワーク • 大規模組織における責任とロールの分離 • 複雑な企業向けのガバナンス ガイド • 管理操作の一元化 • Azure 管理グループのドキュメント
- 32. © Copyright Microsoft Corporation. All rights reserved.