Azure Blueprints 概要

1. Azure Blueprints
真壁 徹
日本マイクロソフト株式会社
クラウドソリューションアーキテクト
2020/09/14
企業で期待される背景と特徴、活用方法

2. エンタープライズ規模の設計原則
マイクロソフト クラウド導入フレームワークより
サブスクリプションの民主化
ポリシー手動のガバナンス
単一のコントロールおよび管理
プレーン
アプリケーション中心、原型に
中立
Azureネイティブの設計とロー
ドマップの調整

3. それぞれ一行で言うと
(個人の解釈が含まれます)
サブスクリプションの民主化
プロジェクト/プロダクトチームに権限を委譲し、ビジネスの変化に追従しやすくする
ポリシー主導のガバナンス
機能やプロジェクトレベルで細かく「制限」せず、ポリシーとRBACで「保護」する
単一のコントロールおよび管理プレーン
独自の管理ポータルやツールを作らず、ポリシーとRBACで標準化・ガバナンスと多様性を両立する
アプリケーション中心、原型に中立
リフト&シフト? IaaS/PaaS? と決めつけて型にはめず、アプリケーションの特性と目的に合わせる
Azureネイティブの設計とロードマップの調整
Azureの特徴を活かす、また、ロードマップを意識する(欲しい機能はプレビュー/ロードマップにあるかも)

4. Azure Policyによるポリシー主導のガバナンス
リソースの特徴に合わせ、リソースに対する操作を評価、対応する
リソース作成時の拒否、監査(ログ
記録)、変更、関連リソース作成
既存リソースに対する評価と修復
例: HTTPS、診断ログ、バックアッ
プの有効化、etc
サブスクリプション、リソースグ
ループだけでなく管理グループに
も割り当て、継承可能

5. Azure Policy 組み込みポリシー/イニシアティブ
ポリシーを目的や用途別にまとめたものがイニシアティブ
ポリシー数
432
イニシアティブ数
25

6. Deploy Enterprise-Scale with Azure VWAN
エンタープライズ規模での
Azure ランディングゾーン 設計例
ランディングゾーン
= 着地点として使えるテンプレート
各プロジェクト
向け ランディン
グゾーン

7. ガバナンス視点でのポイント
全社的に適用したい
「必要最小限の」ポリ
シーを上位階層に
プロジェクト共通ポ
リシーは「ガード
レール」を意識
専門家が担当する管理
グループのポリシーに
は自由度を
プロジェクト追
加作業の効率化

8. ガバナンス視点でのポイント 1/2
全社的に適用したい「必要最小限の」ポリシーを上位階層に
• このレベルに色々入れたくなるが、ぐっと我慢する
• 下位の管理グループは専門家向けとプロジェクト向けに分かれることを意識する
• 下位の管理グループ全てに継承が必要なポリシーか、を議論する
• ここでは監視、監査、セキュリティサービスの有効化にとどめることが多い
(NSGなどサービス固有の細かな制限は行わない)
を
専門家が担当する管理グループのポリシーは自由度を
• ネットワークや管理系サービスは特に進化が速く、全体に及ぼす効果も大きい
• その試行や展開を上位ポリシーで制限しないようにする
• 担当者の専門性を信頼し、委任する
• 必要に応じ、PIMで権限付与を承認制、期限付きとする

9. ガバナンス視点でのポイント 2/2
プロジェクト共通ポリシーは「ガードレール」を意識する
• 各プロジェクトの主体性とスピード感、会社としてのリスク軽減を両立する
• 制限ではなく保護
• はじめから完璧な共通ポリシーを作るのは難しいため、リファクタリングを前提とする
• 組み込みポリシーを活用/参考にする (カスタムポリシーも作れるが、沼になりやすい)
を
プロジェクト追加作業の効率化
• ポリシーは管理グループで一括設定、継承できる
• その他のRBAC設定、必須リソース作成作業をいかに効率化するか
• 将来参加プロジェクト数が多くなる場合は重要な論点
• Azure Blueprintsはこの課題を解決するのに有用

10. Azure ガバナンス関連サービス、機能
CRUD
Azure Resource Manager (ARM)
Query
Role-based
Access
Policy
Definitions
ARMTemplates
Management Groups
Subscriptions

11. ARM Templates
Policy Definitions
Role-based access controls
Custom Scripts*
Blueprint
Cloud Engineer
Cloud Architect
+
ISO 27001
FedRAMP
NIST
…
(*) on roadmap

12. Blueprintsは必須か
必須ではない
• 目指すことの本質は必要なポリシーやリソースのコード化、自動化
• ARM TemplateやTerraformなどで、ポリシーやリソースの作成や割り当ては可能
• 組織として習熟したツールがあれば、それで実現してもよい
• を
Azure Blueprintsの利点
• BlueprintsがAzure内に保管、バージョン管理される
• Blueprintsとそれを使って割り当てたリソースの関係が追跡できる
• Blueprintsのバージョンアップを、それを使って割り当てたリソースすべてに反映できる
• Blueprintsで割り当てたリソースをロックできる
(リソース所有者でも、Blueprintの権限を持たない場合は変更、削除できない)
• Azure Policy/RBAC/ARM Templateを「組み合わせた元ネタ」として使える
Azure Blueprint とは

13. 典型的なユースケース
サブスクリプション提供時の基本的定型作業
• リソースグループ作成
• リソースグループに対するRBAC設定
サブスクリプション提供時のランディングゾーン作成
• 基本的定型作業＋ポリシー、リソース作成
• 詳細ポリシー、Azure Monitor、Key Vaultなど
コンプライアンス準拠に役立つポリシー設定
• PCI-DSS、ISO 27001、NIST SP800など
Azure Blueprints サンプル

14. リファクタリングが重要
はじめから完璧を目指さず、小さくはじめ、大きく育てる
• 知見のない状態では、従来の方針や知識で
標準化してしまいがちで、クラウドの良さ
を活かせない
• 一方で標準化せず進めると、手戻りの影響
が大きい
• 後から変更、洗練することを前提に、小さ
くはじめる
• 初期に必要な最小限の「ガードレール」は
大いに議論する
• ポリシーは追加、変更、削除できる（はじ
めから完璧でなくていい）
ランディング ゾーンのリファクター

15. エンタープライズ規模の IT ポートフォリオ全体をサポートするために必要なサブ
スクリプションの数は、多数になる可能性があります。
クラウド導入フレームワークの初期段階では、高頻度のリファクタリングが推奨
されますが、これは 10 個目の運用ワークロードがクラウドにデプロイされる前(く
らいに)に安定するはずです。
(しかし)企業のポートフォリオ全体にわたって作業する場合、10 個のアプリケー
ションを(それぞれのプロジェクトが)すばやくデプロイし、リファクタリングを行
うことは非現実的です。
代わりに、中央の IT チームまたは優れたクラウド センターによって、最初のリ
リース時に完成度の高いランディング ゾーンを用意することが推奨されます。
クラウド導入フレームワークのエンタープライズ規模ランディング ゾーン アーキテクチャ
萎縮せず
小さくはじめて
育てよう

16. 参考ドキュメント
クラウド導入フレームワークのエンタープライズ規模の設計原則
Azure の更新情報
Azure Feedback
Azure Policy の組み込みのポリシー定義
Azure Policy の組み込みイニシアチブの定義

17. © Copyright Microsoft Corporation. All rights reserved.