例外のコスト
Landing Zoneは一度設計され、その後の運用の中で拡張されていきます。そこから本当の歴史が始まります。厳しい納期を抱えた最初のプロジェクトは、Policy Reviewがスプリントより長くかかるからという理由で、階層の外にSubscriptionを作ります。金曜の午後にContributorの権限では作業が進まなかったベンダーは、Management GroupのOwnerを付与されたまま、Go-live後は誰も気に留めなくなります。HubのFirewallがSpokeのスループットを下げると、SpokeはHubを迂回して直接Peeringを結びます。どの判断もその瞬間には合理的でした。そして今もすべてそのままです。
影響は具体的です。階層の外にあるSubscriptionはPolicyを継承しないため、Policyによる保護も受けません。Management GroupレベルのOwnerは、当時まだ存在していなかったSubscriptionも含め、配下のすべてのSubscriptionに継承されます。Firewallへのルートを持たないPeeringは、SOCからは見えないネットワークパスです。Azure Landing Zone ReviewはCloud Adoption Frameworkの8つのDesign Areasに沿って、設計と現状を照らし合わせ、乖離を経過年数ではなく影響の大きさで並べ替えます。
Cloud Adoption Frameworkの8つのDesign Areas
MicrosoftがLanding Zoneの意思決定を8つのDesign Areasに整理しているのは、そうしなければ多くの問題がチームの狭間に隠れてしまうからです。ネットワークチームがHubを構築し、Identityチームがロールを割り当て、Policyの例外を承認した人物はどちらの記録にも残りません。私たちはすべての8つを同じ問いで検証します。何が想定されていたか、何が実装されているか、その差異から何が生じるか。
Azure BillingとEntra ID Tenant
Enrollment、Billing階層、そしてすべての基盤となるTenant。買収によって生まれた2つ目のTenantは、ライセンス・ID・請求を統合しなければならない局面が来るまで、問題として表面化しないことがほとんどです。
Identity und Access Management
プラットフォームレベルのロール、Service PrincipalおよびPIM。Root Management GroupのOwnerは、後から作成されるすべてのSubscriptionに静かに継承されます。
Resource Organization
Management Group階層、Subscriptionの設計、名前規則とタグ。誤ったManagement GroupにあるWorkloadは誤ったPolicyを継承しますが、それが判明するのはたいていAuditの指摘が入ってからです。
Network TopologyとConnectivity
Hub-and-SpokeまたはVirtual WAN、ハイブリッド接続、DNS、Firewall、Private Endpoints。Hubを迂回したPeeringは技術的には問題なく動作しますが、SOCからは見えません。
Security
Defender for Cloud、暗号化、Key Vault、およびWorkloadではなくプラットフォームレベルに存在するすべての要素。一部のSubscriptionでのみ有効なDefenderプランが保護するのは、まさにその範囲だけです。
Management
Monitoring、Logging、BackupおよびRecovery。Diagnostic Settingsの欠落は通常運用では気づかれず、インシデント発生時に書き出されていなかったログが必要になって初めて明らかになります。
Governance
Azure Policy、イニシアティブ、例外、コスト管理。Exemptionに有効期限があるのは、誰かが設定した場合に限ります。ほとんどは設定されていません。
Platform AutomationとDevOps
Infrastructure as Code、パイプライン、Azure Verified Modules。ポータルで変更されたプラットフォームには2つの真実があります。リポジトリの状態とAzureの状態です。有効なのは後者です。
進め方
- チームへのヒアリングチームへのヒアリングツールではなく、プラットフォームを運用している人たちから始めます。アーキテクチャ、ツール、運用プロセス、戦略。スキャンが後から検出する発見事項の多くには背景があり、それを把握していれば正しく評価できます。意図的な判断と、誰もが忘れた仮設対応は別物です。
- 環境の読み取り環境の読み取り次にToolingで環境を読み取ります。Management Groups、PoliciesとExemptions、ロールの割り当て、ネットワークパス、Diagnostic Settings、コスト。3年前の状態ではなく、Cloud Adoption Frameworkの現在の基準に照らして自動的に検証します。
- 発見事項の優先順位付け発見事項の優先順位付けツールが乖離を見つけ、インタビューがその背景を説明します。優先度はその両方を合わせて初めて決まります。権限の継承やログの欠落が上位に来て、命名規則の違反は下位になります。影響のない発見事項はメモであり、対応指示ではありません。
- レポートのレビューセッションレポートのレビューセッションDesign Areaごとの成熟度、発見事項、推奨事項が記載されたレポートをお渡しし、一緒に内容を確認します。100件の発見事項を把握してもらうためではなく、月曜日にどこから着手するかを明確にするためです。
優先順位付きレポート
8つのDesign Areasに沿ってLanding Zoneを評価したレポートをお渡しします。各領域の成熟度、優先順位付けされた発見事項、そして私たちに問い合わせることなくプラットフォームチームが実行できる推奨事項が含まれます。さらに、スキャナーにはできない判断を加えます。Frameworkからの乖離が意図的な決定なのか、見落としなのかの区別です。このレポートは、数年間Landing Zoneを運用してきて、その間に環境とFrameworkの両方でどのような変化があったかを把握したいプラットフォームチームやIT管理者を対象としています。移行を前にしているなら、移行作業よりも先に基盤を確認すべきです。ベンダーからプラットフォームを引き継いだ場合は、自分で構築していない第三者の目が必要です。実装は含まれません。実装は別プロジェクトとして、私たちと、パートナーと、またはあなたのチームで進めることになります。
その次のステップ
よくいただく事前の質問
最初の会話で出てくる質問に、その場と同じように答えます。
glueckkanjaのLanding Zoneでないと対象外ですか？
いいえ。Enterprise-Scale-Template由来のもの、他のベンダーが構築したもの、ポータルで少しずつ育てたものを問わず、あらゆるLanding Zoneを対象にします。判断基準はCloud Adoption Frameworkであり、私たちのAzure Foundationではありません。Reviewの結果によってAzure Foundationを推奨することはありますが、それは前提条件ではありません。
ReviewとModul Azure der Preventive Servicesの違いは何ですか？
問いかける内容が異なります。Modul Azureは攻撃者がSubscriptionから管理プレーンへどのように到達するかを問い、ハードニングロードマップに終着します。Landing Zone Reviewはプラットフォーム全体が健全かどうかを問います。組織、ネットワーク、Governance、運用、自動化、コスト。SecurityはそのうちのDesign Areaの一つに過ぎません。両方を必要とするなら、まずReviewから始めるべきです。Reviewが地図を提供し、その上にモジュールが経路を描き込みます。
どのような権限が必要ですか？
読み取り専用です。分析には最上位のManagement GroupへのReader権限と、Cost Managementの読み取り権限があれば十分です。変更は一切行いません。Reviewの完了後はアクセス権を削除します。Reader権限だけでReviewを実施できること自体、一つの発見事項でもあります。それができないLanding Zoneは、最初の課題がすでに見つかっています。
コストの確認も行いますか？
はい。Landing ZoneにおけるコストはGovernanceの発見事項と原因が共通することが多いためです。Tagがなければ請求をチームに紐付けられず、Budget Alertがなければ放置されたVMは月末になるまで気づかれません。誰も管理しないReservationは使われていないキャパシティに費用を払い続けます。気になった点はすべて数字とともにレポートに記載します。
Reviewにはどのくらいの期間がかかりますか？
インタビューと分析には数日程度です。あなたたちの側が必要なのは、インタビューの時間、読み取り権限の付与、レポートを一緒に確認するセッションの3つです。最も手間がかかるのは、その後でリストをどう処理するかの部分であり、それはあなたたちのものです。
実装は含まれていますか？
含まれていません。意図的な設計です。自社の後続案件を優先するようなReviewは、Reviewとは呼べません。優先順位と推奨事項をお渡しし、実装は別プロジェクトとして進めます。私たちと、パートナーと、またはあなたたちのチームで。その後Landing Zoneをゼロから構築し直したい場合は、Azure Foundationがその道筋を提供します。