プレイブック

ユーザー属性（例：部署）に基づいてセキュリティグループのメンバーシップを自動的に管理します。

→メンバーシップタイプが「動的ユーザー」のMicrosoft Entra IDセキュリティグループを構成し、属性ベースのルールを定義します。

理由: 属性ベースのルールにより、ユーザーライフサイクル変更時の継続的な手動管理が不要になります。Entra ID P1/P2が必要です。

リファレンス↗

単一の管理ポイントから複数のサブスクリプションにわたり一貫したガバナンス（ポリシー、RBAC）を適用します。

→管理グループを作成し、その下にサブスクリプションを配置し、管理グループスコープでポリシーまたはRBACロールを割り当てます。

理由: ポリシーとロールの割り当てはすべての子サブスクリプションに継承され、一元化された一貫したガバナンスを可能にします。

リファレンス↗

サブスクリプション全体で、承認されていないAzureリージョンへのリソースデプロイを防止します。

→サブスクリプションスコープで、組み込みの「許可される場所」Azure Policyを`Deny`効果で割り当てます。

理由: ポリシーは予防的なガバナンスを提供します。RBACはアクションを制御し、デプロイ場所は制御しません。リソースロックは変更/削除を防止し、新規デプロイは防止しません。

VMを管理するためのアクセス許可を付与しますが、基盤となる仮想ネットワークやユーザーアクセスは付与しません。

→リソースグループまたはVMスコープで、組み込みの「Virtual Machine Contributor」ロールを割り当てます。

理由: このロールは、広範なContributorまたはOwnerの権限を付与することなく、特定のVM管理権限（起動、停止、再イメージ化）を提供します。

ユーザーが企業ネットワーク外から特定のクラウドアプリ（例：Azure portal）にアクセスする際にMFAを要求します。

→企業のIPアドレス用の「名前付き場所」を除外条件として含む条件付きアクセスポリシーを作成し、MFAを許可コントロールとして要求します。

理由: 信頼された場所を除外することが、企業ネットワーク上でMFAをバイパスし、それ以外の場所でMFAを強制するための鍵です。

リファレンス↗

Ownerロールを持つ管理者であっても、重要なリソースの削除を防止します。

→リソースまたはそのリソースグループに`CanNotDelete`または`ReadOnly`リソースロックを適用します。

理由: リソースロックは、RBACロールに関係なくすべてのユーザーに適用され、誤削除に対する最も強力な保護を提供します。

Azure Policyによって識別された既存の非準拠リソースを自動的に修正します（例：不足しているタグを追加する）。

→`Modify`または`DeployIfNotExists`効果を持つポリシーの場合、ポリシー割り当ての修復タスクを作成します。

理由: 修復タスクは、既存のすべての非準拠リソースに対してポリシーの修正アクションをトリガーし、環境をコンプライアンスに準拠させるプロセスを自動化します。

部署、プロジェクト、または事業単位別に分類されたAzureコストをレポートします。

→すべてのリソースに一貫したタグ（例：「CostCenter」）を適用します。Azure Cost Managementを使用して、そのタグでコストをフィルターおよびグループ化します。

理由: タグは、異なるリソースグループやサブスクリプション間でのカスタムコスト配分とレポート作成のための主要なメカニズムです。

必要なときにのみ、限られた期間、承認ワークフロー付きで管理者に特権ロールを付与します。

→Microsoft Entra Privileged Identity Management (PIM) を使用します。ユーザーをロールの対象とし、アクティベーション要件を構成します。

理由: PIMはJust-In-Time (JIT) アクセスを強制し、常時特権アカウントの露出を減らし、完全な監査証跡を提供します。

外部パートナーが自身の企業資格情報を使用してAzureリソースにアクセスできるようにします。

→Microsoft Entra B2Bコラボレーションを使用して、パートナーをゲストユーザーとしてテナントに招待します。

理由: B2Bにより、テナント内で新しい資格情報を作成および管理する必要がなくなります。パートナーは既存のIDプロバイダーを使用して認証を行います。

めったにアクセスされないが保持する必要がある長期データ（例：コンプライアンスアーカイブ）のストレージコストを最小限に抑えます。

→BLOBライフサイクル管理ポリシーを使用して、BLOBをHot/CoolからArchive層に自動的に移行します。

理由: Archive層はストレージコストが最も低いです。ライフサイクルルールは、BLOBの経過時間または最終アクセス時間に基づいて階層化プロセスを自動化します。

リファレンス↗

プライマリリージョンの障害発生時でも、セカンダリリージョンからストレージデータへの読み取りアクセスを確保します。

→ストレージアカウントをRead-Access Geo-Redundant Storage (RA-GRS) またはRA-GZRSで構成します。

理由: 標準のGRS/GZRSはデータをレプリケートしますが、フェールオーバーが行われるまでセカンダリへの読み取りアクセスを許可しません。「RA」プレフィックスは継続的な読み取りアクセスに必要です。

特定のコンテナーに対するShared Access Signature (SAS) トークンのセットを即座に失効させる機能。

→コンテナー上の保存されたアクセスポリシーに基づいてSASトークンを作成します。失効させるには、ポリシーを変更または削除します。

理由: 保存されたアクセスポリシーを変更すると、それに関連付けられたすべてのSASトークンが即座に無効になり、一元的な失効メカニズムが提供されます。

オンプレミスのファイルサーバーとAzureファイル共有を同期し、ローカルディスクスペースの使用量を最小限に抑えます。

→Azure File Syncをデプロイし、サーバーエンドポイントでクラウド階層化を有効にします。

理由: クラウド階層化は、頻繁にアクセスされる（「ホットな」）ファイルのみをローカルにキャッシュし、あまり使用されないファイルはAzureに階層化され、ローカルサーバー上ではスタブとして表示されます。

ストレージアカウントへのネットワークアクセスを特定のVNetサブネットとパブリックIPアドレスに制限します。

→ストレージアカウントファイアウォールを有効にします。サブネット用の仮想ネットワークルールと、パブリックIP用IPアドレスルールを追加します。

理由: ストレージファイアウォールは、ストレージアカウントのパブリックエンドポイントでネットワークレベルのアクセス制御を直接提供し、他のすべてのトラフィックをブロックします。

指定された期間の復旧を許可することで、BLOBを偶発的な削除から保護します。

→ストレージアカウントでBLOB論理削除を有効にし、保持期間（例：14日間）を構成します。

理由: 論理削除は、削除されたBLOBを構成された期間保持し、簡単な復元を可能にします。これは偶発的なデータ損失に対する最初の防御線です。

特定の期間、データを消去不可、変更不可（WORM）の状態で保存するというコンプライアンス要件を満たします。

→BLOBコンテナーで時間ベースの保持ポリシーを構成し、そのポリシーをロックします。

理由: ロックされた時間ベースの保持ポリシーはBLOBを不変にし、保持期間が期限切れになるまで（管理者を含む）誰も削除または変更できないようにします。

ネットワーク帯域幅が限られている場合に、非常に大きなデータセット（例：50TB以上）をAzure Blob Storageに移行します。

→オフライン転送にはAzure Data Box物理アプライアンスを使用します。

理由: 大規模なデータセットの場合、物理デバイスを発送する方が、低速または飽和したネットワーク接続経由でデータを転送するよりもはるかに高速です。

VMに対して99.99%のSLAを達成し、リージョン内の単一データセンター障害からアプリケーションを保護します。

→同じリージョン内の異なるAvailability Zonesに複数のVMインスタンスをデプロイします。

理由: Availability Zonesは物理的に分離されたデータセンターです。Availability Setsは単一データセンター内のラックレベルの障害からのみ保護します（99.95% SLA）。

リファレンス↗

完全リリース前に、ライブの運用トラフィックで新しいアプリケーションバージョンをデプロイおよびテストし、ダウンタイムをゼロにします。

→App Serviceデプロイメントスロットを使用します。スロットにデプロイし、テストしてからスワップを実行します。オプションで、カナリアテストのためにトラフィックルーティングを使用します。

理由: スロットは完全なステージング環境を提供します。スワップ操作はトラフィックのほぼ瞬時のリダイレクトであり、ダウンタイムをゼロに保証します。

最小限のコストでインフラストラクチャ管理なしに、スケジュールに基づいて短期間のコンテナ化されたバッチジョブを実行します。

→Azure Container Instances (ACI) を使用します。

理由: ACIは秒単位の課金とクラスター管理のオーバーヘッドがないため、散発的または短期間のコンテナワークロードにとって最も費用対効果の高いオプションです。

予測可能な日次のピーク（例：営業時間）を持つワークロードを自動スケーリングし、予期せぬスパイクにも対応します。

→VM Scale Setの自動スケーリングを、スケジュールベースのルールとメトリックベースのルールの両方で構成します。

理由: プロアクティブ（スケジュール）とリアクティブ（メトリック）なスケーリングを組み合わせることで、パフォーマンス（ピーク前に準備完了）とコスト効率（アイドル時にスケールダウン）の最適なバランスを提供します。

Azure Kubernetes Service (AKS) クラスターのコンテナイメージを、脆弱性スキャン付きのプライベートレジストリに安全に保存します。

→Azure Container Registry (ACR) Premium SKUを使用し、マネージドIDを使用してAKSと統合します。

理由: ACRはAzure内に共同配置されたプライベートレジストリを提供します。Premium SKUには脆弱性スキャンが含まれます。マネージドIDは、AKSからACRへの安全な資格情報なしの認証を提供します。

アプリケーションのダウンタイムを引き起こすことなく、すべてのVMSSインスタンスでOSまたはアプリケーションの更新を実行します。

→VMSSモデル（例：新しいイメージバージョン）を更新し、ローリングアップグレードポリシーを使用します。

理由: ローリングポリシーは、構成可能なバッチでインスタンスを更新し、更新プロセス全体を通じてトラフィックを処理するために常にインスタンスのサブセットが利用可能であることを保証します。

完全なオーケストレーターなしで、ネットワークとストレージを共有する必要があるマルチコンテナアプリケーション（例：アプリ+ロギングサイドカー）をデプロイします。

→コンテナを単一のAzure Container Instances (ACI) コンテナグループにデプロイします。

理由: コンテナグループは複数のコンテナを共同配置し、localhostネットワークとボリュームを共有します。これはKubernetesの複雑さなしにサイドカーパターンに最適です。

VMのOSまたはデータディスクのサイズをデプロイ後に増やします。

→VMの割り当てを解除し、Azureでディスクリソースのサイズを変更し、VMを起動してから、ゲストOS内でパーティションを拡張します。

理由: Azureディスクのサイズ変更は、単にスペースを多く割り当てるだけです。ゲストOSは、ファイルシステムパーティションを拡張することで、その新しいスペースを使用するように指示される必要があります。

アプリケーションに資格情報を保存せずに、App ServiceがAzure Key Vaultからシークレットに安全にアクセスできるようにします。

→App Serviceでシステム割り当てマネージドIDを有効にし、そのIDにKey Vaultシークレットに対する`Get`および`List`アクセス許可を付与します。

理由: マネージドIDは資格情報なしの認証メカニズムを提供します。アプリケーションはKey Vaultのアクセストークンを自動的に取得でき、シークレット管理が不要になります。

大規模で複雑なInfrastructure-as-Codeデプロイを、より小さく、再利用可能で保守可能なコンポーネントに整理します。

→デプロイをBicepモジュールにリファクタリングし、各モジュールが論理単位（例：ネットワーク、コンピューティング）を表すようにし、メインのBicepファイルからそれらをオーケストレーションします。

理由: モジュールはコードの再利用を促進し、可読性を向上させ、複雑なインフラストラクチャデプロイの管理を簡素化します。

VNet内でアプリケーション層（Web、アプリ、データ）を分離し、隣接しない層間の直接通信を防止します。

→各層に個別のサブネットを使用し、各サブネットにNetwork Security Groups (NSGs) を適用してトラフィックフローを制御します。

理由: NSGは、送信元/送信先IP範囲（サブネット）、ポート、およびプロトコルに基づいて詳細なステートフルフィルタリングを可能にし、ネットワークマイクロセグメンテーションを実現します。

異なるAzureリージョンにある2つのVNetをMicrosoftバックボーンネットワーク経由でプライベートに接続します。

→2つのVNet間でグローバルVNetピアリングを構成します。

理由: グローバルピアリングは、VNet-to-VNet VPN接続よりもシンプルで低遅延、高帯域幅です。トラフィックはプライベートなMicrosoftネットワーク上に留まります。

VNet-AはHub-VNetにピアリングされ、Spoke-VNetもHub-VNetにピアリングされています。VNet-AのVMはSpoke-VNetのVMに到達できません。

→原因は、VNetピアリングが非推移的であることです。通信を有効にするには、VNet-AとSpoke-VNetを直接ピアリングするか、HubでNVAを使用します。

理由: ピアリングはデイジーチェーンを作成しません。Network Virtual Applianceを介したルーティングが構成されていない限り、通信には各VNetが直接接続されている必要があります。

オンプレミスネットワークからAzure VNetへの、パブリックインターネット経由の永続的な暗号化されたIPsecトンネルを確立します。

→VNetにAzure VPN Gatewayをデプロイし、サイト間 (S2S) 接続を構成します。

理由: これは、単一のオンプレミスサイトとAzure VNet間のハイブリッド接続のための、標準的で安全かつ信頼性の高いソリューションです。

Azure Load Balancerが、異常なバックエンドVMにトラフィックを送り続け、アプリケーションのタイムアウトを引き起こしています。

→ロードバランサー上で、バックエンドVM上のアプリケーションの正常性を正確にチェックするヘルスプローブを構成します。

理由: ロードバランサーは、異常なインスタンスを検出するために完全にヘルスプローブに依存しています。正しく構成されたプローブがなければ、失敗したVMをトラフィックローテーションから削除することはできません。

URLパス（例：/images/* vs /api/*）に基づいて、HTTP/Sトラフィックを異なるバックエンドサーバープールにルーティングします。

→パスベースのルーティングルールを持つAzure Application Gatewayを使用します。

理由: Application GatewayはHTTPリクエストを検査し、URLパスに基づいてルーティング決定を行うLayer 7ロードバランサーです。標準のAzure Load BalancerはLayer 4であり、それはできません。

カスタムDNSサーバーを持つVNet内のVMが、Azure Private DNS Zone内のホスト名を解決できません。

→プライベートゾーンのクエリを、Azureが提供するDNSリゾルバーIP (168.63.129.16) に条件付きで転送するようにカスタムDNSサーバーを構成します。

理由: カスタムDNSサーバーを使用すると、Azureの内部DNSがバイパスされます。カスタムサーバーは、Azure DNSにリクエストを転送することで、Azure固有のゾーンを解決する方法を学習する必要があります。

スポークVNetからのすべてのインターネット向けトラフィックが、ハブVNet内の中央Azure Firewallによって検査されるように強制します。

→スポークサブネットにユーザー定義ルート (UDR) を持つルートテーブルを適用します。UDRは、ファイアウォールのプライベートIPを指すデフォルトルート (0.0.0.0/0) です。

理由: UDRはAzureのインターネットへのデフォルトシステムルートを上書きし、セキュリティ検査のために送信トラフィックフローを制御および一元化することを可能にします。

VPNを構成せずに、パブリックIPアドレスを持たないVMに安全なRDP/SSHアクセスを提供します。

→VNet内の専用サブネット (AzureBastionSubnet) にAzure Bastionをデプロイします。

理由: Bastionはマネージドジャンプボックスサービスを提供し、Azure portal経由でTLSを介した安全な管理アクセスを可能にし、VM上のパブリックIP露出を排除します。

VMとPaaSサービス（例：Azure SQL）間のトラフィックがプライベートネットワーク上に留まり、PaaSサービスがパブリックにアクセスできないようにします。

→VMのVNet内にPaaSサービスのプライベートエンドポイントを作成し、PaaSサービス上のパブリックネットワークアクセスを無効にします。

理由: プライベートエンドポイントは、PaaSサービスにVNet内のプライベートIPを提供し、パブリックアクセスを無効にすることで、そのプライベートIP経由でのみ到達可能であることを保証します。

グローバルユーザーを最寄りのリージョンアプリケーションエンドポイントにルーティングして、可能な限り低いレイテンシーを確保します。

→「パフォーマンス」ルーティングメソッドでAzure Traffic Managerを使用します。

理由: パフォーマンスルーティングメソッドは、DNSを使用してクライアントをその場所から最もネットワークレイテンシーが低いエンドポイントに誘導します。

リソースメトリック（例：VM CPU使用率）が設定された期間、しきい値を超えた場合に通知（電子メール、SMS、Webhook）を送信します。

→Azure Monitorでメトリックアラートルールを作成し、通知アクションを定義するアクショングループにリンクします。

理由: これが標準的なパターンです。アラートルールは条件（何を/いつ）を定義し、アクショングループは結果の通知（誰に/どのように）を定義します。

2つのVM間のトラフィックが特定のNetwork Security Group (NSG) ルールによってブロックされているかどうかを判断します。

→Azure Network WatcherのIPフロー検証ツールを使用します。

理由: IPフロー検証はパケットフローをシミュレートし、どのNSGとルールがトラフィックを許可または拒否しているかを明示的に報告するため、NSGの競合をトラブルシューティングするための決定的なツールです。

アプリケーション整合性と長期保持を備えた、スケジュールベースのポリシーベースのAzure VMバックアップを構成します。

→Recovery Servicesコンテナーを作成し、バックアップポリシー（スケジュール、保持）を定義し、ターゲットVMのバックアップを有効にします。

理由: Recovery Servicesコンテナーは、Azure Backupの中央管理エンティティです。バックアップデータを安全に保存し、すべてのバックアップおよび復元操作を管理します。

リファレンス↗

複数のサブスクリプションにわたるVMのパフォーマンス（CPU、メモリ、ディスク、ネットワーク）を監視するための一元化されたダッシュボードを作成します。

→中央のLog Analyticsワークスペースをデプロイし、すべてのターゲットVMに対してVM Insightsを有効にして、ワークスペースを指すようにします。

理由: VM Insightsはパフォーマンスデータを収集および集約し、事前構築済みのワークブックと、サブスクリプション全体で統合された「大規模な」パフォーマンスビューを提供します。

未利用のAzureリソースやコスト削減の機会（例：VMの適切なサイズ変更）を事前に特定します。

→Azure Advisorのコストに関する推奨事項を定期的に確認します。

理由: Azure Advisorはリソース使用状況を自動的に分析し、追加の構成なしで、コスト削減のための実用的なパーソナライズされた推奨事項を提供します。

プライマリリージョンからセカンダリリージョンへAzure VMをレプリケートし、ディザスターリカバリー機能を提供します。

→Azure Site Recoveryを使用します。Recovery Servicesコンテナーを作成し、ターゲットリージョンへのVMのレプリケーションを有効にします。

理由: ASRは、Azureリージョン間のVMレプリケーション、フェールオーバーテスト、およびフェールオーバー/フェールバックをオーケストレーションするためのネイティブAzureサービスです。

単一のLog Analyticsワークスペース内で、セキュリティログとパフォーマンスログで異なるデータ保持期間を設定し、コストを最適化します。

→ワークスペースレベルのデフォルト保持期間を設定し、その後、個々のテーブルレベル（例：SecurityEventテーブル）でより長い保持期間を構成します。

理由: テーブルごとの保持により、特定のデータに対する長期的なコンプライアンス要件を満たしつつ、重要度の低い大量データのストレージコストを最小限に抑えることができます。