Microsoft Azure Security Engineer Associate
最終確認：2026年5月
AZ-500 試験で問われるアーキテクチャパターンのスキャン可能なリファレンス。上から順に読むか、セクションへジャンプ。
承認と正当化を必要とする特権Azure ADロールへのジャストインタイム（JIT）アクセスを提供する。
ロールに対してMicrosoft Entra Privileged Identity Management (PIM) を構成する。「アクティブ化の承認を要求」を設定し、承認者を指定し、「アクティブ化時に正当化を要求」を有効にし、最大アクティブ化期間を設定する。
理由: PIMは、JITロール昇格のためのネイティブなAzureサービスである。単にユーザーを適格にするだけでは不十分であり、ポリシー設定によって承認と正当化のワークフローが強制される。
機密アプリにアクセスするすべてのユーザーに対してMFAと準拠デバイスを強制するが、特定のヘルプデスクグループをデバイス準拠ルールから除外する。
2つの条件付きアクセス（CA）ポリシーを作成する。ポリシー1はヘルプデスクグループを除く「すべてのユーザー」を対象とし、MFAと準拠デバイスを要求する。ポリシー2はヘルプデスクグループのみを対象とし、MFAのみを要求する。
理由: 除外を含む単一のポリシーでは、除外されたグループに対するすべての要件が削除される。2つのターゲットを絞ったポリシーにより、各グループが正しい、個別の制御セットを確実に取得できる。
検出されたIDリスクに自動的に対応する：高リスクのサインインをブロックし、高リスクユーザーにパスワードのリセットを強制する。
2つのMicrosoft Entra ID Protectionポリシーを構成する。「サインインリスクポリシー」を高リスクレベルでアクセスブロックに設定する。「ユーザーリスクポリシー」を高リスクレベルでパスワード変更を要求に設定する。
理由: サインインリスクは単一の認証試行（リアルタイム）に関するものであり、ユーザーリスクはID自体（侵害された資格情報）に関する累積スコアである。これらは異なる修復アクションを必要とする。
ハイブリッドID環境のユーザーがクラウドパスワードをリセットし、それをオンプレミスActive Directoryに同期させることを許可する。
Microsoft Entra Connectで「パスワードライトバック」機能を有効にする。Azure ADで、対象ユーザー向けにセルフサービスパスワードリセット（SSPR）を有効にして構成する。
理由: SSPRはパスワードリセットのためのクラウド側のユーザーインターフェースを提供する一方、パスワードライトバックは新しいパスワードハッシュをオンプレミスADに同期させるEntra Connectのコンポーネントである。
すべてのゲストユーザーアクセスを定期的にレビューし、承認されなくなったゲストまたは非アクティブなゲストを自動的に削除する。
Microsoft Entra ID Governanceでアクセスレビューを作成する。すべてのグループのゲストユーザーを対象とし、定期的なスケジュール（例：四半期ごと）を設定し、「結果をリソースに自動適用」を有効にする。オプションで、非アクティブなユーザーをレビューする。
理由: アクセスレビューは、アクセスの定期的な再認証のための専用のガバナンスツールである。「結果を自動適用」機能は、ループを閉じて削除を自動化するために不可欠である。
外部パートナーに対し、90日後に自動的に期限切れになるアクセスバンドル（グループ、アプリ、SharePointサイト）をセルフサービスで要求する方法を提供する。
Microsoft Entra Entitlement Managementを使用する。パートナー向けに接続済み組織を作成する。リソースを含むアクセスパッケージを作成する。そのパッケージに対して、接続済み組織のユーザーが90日の有効期限付きで要求できるポリシーを定義する。
理由: エンタイトルメント管理は、特に外部ユーザー向けの、大規模なアクセスをガバナンスするために設計されている。リソースをバンドルし、要求と承認から期限切れと削除まで、アクセスライフサイクル全体を自動化する。
高セキュリティアプリケーションは、フィッシングおよび中間者攻撃に耐性のある方法でユーザーが認証することを要求する。
FIDO2セキュリティキーやWindows Hello for Businessのような認証方法を強制する。これらの方法は公開鍵暗号を使用し、デバイスにバインドされており、資格情報の盗難を防ぐ。
理由: SMS、音声通話、単純なプッシュ通知のような方法はフィッシング可能である。FIDO2とWHfBは、要求元に紐付けられた暗号チャレンジを使用するため、フィッシングに耐性がある。
VM上で実行されているバックグラウンドサービスが、ユーザー操作なしにMicrosoft Graphからすべてのユーザープロファイルを読み取る必要がある。
Microsoft Entra IDでアプリケーションを登録する。API権限の下で、`User.Read.All`に対してMicrosoft Graphの「アプリケーション」権限（「委任」ではない）を付与する。管理者が管理者同意を付与する必要がある。
理由: アプリケーション権限は、アプリが自身のID（クライアントID/シークレットまたは証明書）を使用して、自身として動作することを許可する。委任された権限は、サインインしたユーザーコンテキストを必要とするが、これは非対話型デーモンアプリでは利用できない。
AKSクラスター内のポッドが、クライアントシークレットや証明書などの保存された資格情報を使用せずにAzure Key Vaultに安全にアクセスできるようにする。
Azure ADワークロードIDを使用する。ユーザー割り当てマネージドIDを作成し、K8sサービスアカウントとマネージドIDの間でフェデレーションID資格情報を確立し、そのマネージドIDにKey Vaultへのアクセス権を付与する。
理由: ワークロードIDはOIDCフェデレーションを使用してKubernetesトークンをAzure ADトークンと交換し、クラスター内でシークレットを保存、管理、またはローテーションする必要を完全に排除する。
Azure Key Vaultを保護し、特定のVNetからのアクセスのみを許可し、すべての操作をログに記録し、重要なキーの偶発的な削除から保護する。
Key Vaultファイアウォールを構成し、「プライベートエンドポイントと選択されたネットワーク」からのアクセスを許可する。Log Analyticsワークスペースへの診断ログを有効にする。ソフトデリートと削除保護の両方を有効にする。
理由: ソフトデリートは偶発的な削除からの回復を可能にするが、削除保護は特権ユーザーでさえも保持期間中にコンテナーまたはその内容を永続的に削除することを防ぐ。この組み合わせは、TDEキーを保護するために不可欠である。
Azure App Serviceが、構成に接続文字列パスワードを保存することなく、Azure SQL Databaseに認証してデータを取得する必要がある。
App Serviceでシステム割り当てマネージドIDを有効にする。Azure SQLで、App ServiceのマネージドID名にマップされた包含ユーザーを作成し、必要なデータベースロール（例：db_datareader）を付与する。
理由: マネージドIDは、Azure AD内でAzureリソース自体にIDを提供する。Azureが資格情報の作成とローテーションを自動的に処理するため、保存されたシークレットが不要になり、これは主要なセキュリティベストプラクティスである。
Azure Key Vaultで組織が管理するキーを使用して、Azure VMマネージドディスクを保存時に暗号化する。
ディスク暗号化セットリソースを作成する。Azure Key Vaultから顧客管理キー（CMK）を使用するように構成する。ディスク暗号化セットをVMのマネージドディスクに割り当てる。
理由: これはCMKによるサーバー側暗号化（SSE）であり、ストレージインフラストラクチャ内のデータを暗号化する。ゲストOS内でBitLocker/dm-cryptを使用してデータを暗号化し、通常はOSディスクとデータディスクを一緒に使用するAzure Disk Encryption (ADE) よりもシンプルである。
Azure Container Registry (ACR) に保存されているコンテナイメージが、デプロイされる前に脆弱性スキャンされていることを確認する。
Microsoft Defender for Containersを有効にする。これにより、ACR内のイメージがプッシュ時、プル時、および新しく発見された脆弱性について継続的に自動スキャンされる。
理由: この「シフトレフト」セキュリティプラクティスは、CI/CDパイプラインの早い段階で脆弱性を特定する。Defender for Containersは、Azureエコシステム内でこのスキャン機能をネイティブに提供する。
Azure SQL Databaseに対する潜在的なSQLインジェクション攻撃や異常なアクセスパターンを検出し、アラートを受け取る。
論理SQLサーバーでMicrosoft Defender for SQLを有効にする。これにより、高度な脅威保護と脆弱性評価が提供される。
理由: Defender for SQLは、ネットワークレベルのツールでは視認できないSQLインジェクション、ブルートフォース攻撃、異常なデータアクセスなどの脅威を検出するために、行動分析と機械学習を使用する専用のワークロード保護プランである。
ストレージアカウントを特定のVNetに制限するが、Azure Backupのような信頼されたMicrosoftサービスが引き続きアクセスできるようにする。
ストレージアカウントのネットワーク設定で、「選択された仮想ネットワークとIPアドレスから有効」を選択する。必要なVNet/サブネットを追加する。次に、「信頼されたMicrosoftサービスがこのストレージアカウントにアクセスすることを許可する」のチェックボックスをオンにする。
理由: 信頼されたサービス例外は、特定のMicrosoftサービスがVNetファイアウォールルールをバイパスするための安全なパスを作成する。これがなければ、ユーザーに代わって動作するサービス（バックアップやポータルなど）はブロックされる。
特権データベース管理者（DBA）からでも、Azure SQLデータベース内の特定の機密データ列（例：クレジットカード番号）を保護する。
Always Encryptedを使用する。クライアントアプリケーションドライバーは、データをデータベースに送信する前に透過的に暗号化し、暗号化キーはデータベースエンジンに決して公開されない。
理由: 透過的データ暗号化（TDE）はデータベース全体を保存時（ディスク上）に暗号化するが、アクセス権を持つDBAはデータを引き続き見ることができる。Always Encryptedはクライアント側暗号化を提供し、データを管理する者（DBA）とデータを見ることができる者を分離する。
Azure VM上で機密性の高いデータを処理し、ハイパーバイザーやクラウドオペレーターからでもメモリ内で暗号化され保護された状態を維持する。
Azure Confidential VMをデプロイする。これらのVMは、AMD SEV-SNPのようなハードウェアベースの信頼実行環境（TEE）を使用して、分離された暗号化されたメモリス空間を作成する。
理由: 標準のVM暗号化（ADEやSSEなど）は保存時のデータを保護する。Confidential Computingは、メモリ内で*使用中の*データを保護する唯一のテクノロジーであり、クラウドで最高レベルのデータプライバシーと分離を提供する。
App Serviceが、Key Vault SDKを使用するためにアプリケーションコードを変更することなく、Key Vaultからのシークレットをアプリケーション設定として使用する必要がある。
App ServiceでマネージドIDを有効にし、Key Vault内のシークレットに対する「取得」権限を付与する。App Service構成で、Key Vault参照としてフォーマットされた値を持つアプリケーション設定を作成する：`@Microsoft.KeyVault(SecretUri=...)`。
理由: この機能により、App ServiceプラットフォームはマネージドIDを使用して実行時にシークレット値を解決できる。アプリケーションコードは標準の環境変数を読み取るだけで、Key Vaultとのやり取りを抽象化する。
コンプライアンス関連データをAzure Blob StorageにWORM（Write-Once, Read-Many）状態で7年間の保持期間で保存する。
ストレージコンテナで、不変性ポリシーを構成する。時間ベースの保持ポリシーを7年に設定し、ポリシーをロックする。ロックされると、保持期間が終了するまで、データは誰によっても変更または削除できなくなる。
理由: この機能は、規制コンプライアンス要件（例：SEC 17a-4）を満たすように特別に設計されている。ポリシーをロックすることが、真に不変にするための重要なステップである。
単一のAzure SQLデータベースを使用するマルチテナントアプリケーションで、あるテナントのユーザーが自分のテナントに属するデータのみを見ることができるようにする。
行レベルセキュリティ（RLS）を実装する。セッションコンテキストまたはユーザー検索テーブルに保存されているユーザーのテナントIDに基づいて行をフィルタリングする述語関数を持つセキュリティポリシーを作成する。
理由: RLSはデータベースエンジン内で直接アクセスロジックを強制する。これはアプリケーション層でフィルタリングを実装するよりも安全で信頼性が高い。なぜなら、バイパスできず、アプリケーションコードに対して透過的であるからである。
UEFIからOSカーネルまでのブートチェーン全体の整合性を確保することで、ブートキットやルートキットから第2世代VMを保護する。
Trusted Launchが有効なVMをプロビジョニングする。これにより、すべてのブートコンポーネントの署名を検証するセキュアブートと、計測ブートおよびアッテステーションのための仮想Trusted Platform Module（vTPM）がアクティブになる。
理由: Trusted Launchは、従来のOSレベルのセキュリティ制御を転覆できる高度な低レベルマルウェアに対処する。VMのハードウェア信頼のルートを確立する。
別々のサブネットでホストされているアプリケーション層（Web、アプリ、データ）間のトラフィックを分離する。
各サブネットに専用のネットワークセキュリティグループ（NSG）を作成する。各NSGで、必要なポートで先行する層のソースIP範囲からのトラフィックのみを許可するインバウンドルールを作成する。（例：アプリ層NSGはWeb層サブネットからのTCP/8080を許可する）。
理由: 各サブネットに固有の最小特権NSGを適用することで、多層防御と東西トラフィックフローに対するきめ細かい制御が提供され、VNet全体に対する単一の複雑なNSGよりも安全である。
ハブスポークトポロジにおいて、すべてのスポークVNet間のトラフィックを、ハブ内のNVAまたはAzure Firewallによって検査されるように強制する。
各スポークサブネットで、他のスポークのアドレス空間に対して、ネクストホップタイプを「VirtualAppliance」に設定し、NVA/FirewallのIPアドレスを指定したユーザー定義ルート（UDR）を作成する。NVAのNICでIP転送を有効にする。
理由: デフォルトでは、VNetピアリングによりスポークが直接通信できる。UDRはこのデフォルトのルーティング動作を上書きし、トラフィックを中央検査ポイントに強制する。
VNet内にプライベートIPアドレスを持つPaaSサービス（例：Azure SQL、Storage）を提供し、トラフィックがパブリックインターネットを通過しないようにする。
VNet内のPaaSサービス用にプライベートエンドポイントを作成する。重要なのは、PaaSサービスのネットワーク設定でパブリックネットワークアクセスを無効にし、パブリックエンドポイントをブロックすることである。
理由: プライベートエンドポイントは、サービスをプライベートIPアドレスでVNet *内*に導入する。サービスエンドポイントは、Azureバックボーン経由でパブリックIPへのルートを最適化するだけである。プライベート専用通信を強制するには、パブリックアクセスを無効にする必要がある。
IPリストを手動で管理することなく、VMからWindows Updateなどの動的なMicrosoftサービスエンドポイントへのアウトバウンドトラフィックを許可する。
Azure Firewallで、アプリケーションルールコレクションを作成する。ターゲットFQDNタイプを「FQDNタグ」に設定し、「WindowsUpdate」タグを選択したルールを追加する。
理由: FQDNタグは、Microsoftが管理するFQDNの厳選されたコレクションである。これは、基盤となるIPが頻繁に変更されるPaaSサービスへのアクセスを許可する正しい方法である。サービスタグはIPベースのルール用である。
Web Application Firewall (WAF) が、管理対象ルール（例：SQLインジェクション）での誤検知により、アプリケーションへの正当なトラフィックをブロックしている。
WAFポリシーで、WAFをPreventionモードに維持する。トラフィックをブロックしている管理対象ルールを見つけ、誤検知の原因となっている特定の要求ヘッダー、Cookie、またはボディパラメーターに対して除外を構成する。
理由: 除外は、誤検知を処理する最も正確な方法である。特定の例外を作成しながら、他のすべてのトラフィックに対してルールの保護を維持できるため、ルール全体を無効にするよりも安全である。
管理ポートをインターネットに公開したり、VMにパブリックIPを必要とせずに、Azure VMへのセキュアなRDP/SSHアクセスを提供する。
Azure Bastion（高度な機能にはStandard SKU）をVNet内の専用サブネットにデプロイする。Azureポータルを介してVMにアクセスし、Bastionサービスを介して接続する。
理由: Bastionはセキュアなジャンプボックスとして機能し、RDP/SSH接続を仲介する。唯一のパブリックIPはBastionサービス自体にあり、これはMicrosoftによって強化および管理されており、VMの攻撃対象領域を劇的に削減する。
開発者に対し、開発VM上の管理ポート（RDP/SSH）への時間制限付きで監査されたアクセスを提供する。
Microsoft Defender for Cloudを有効にし、VMに対するジャストインタイム（JIT）VMアクセスを構成する。ユーザーはDefender for Cloudを介してアクセスを要求し、これによりNSGルールが動的に変更され、特定のIPから限られた時間だけアクセスが許可される。
理由: JITはDefender for Cloudのコア機能であり、管理ポートをデフォルトで閉じたままにし、オンデマンドでのみ開くことでVMのネットワーク態勢を強化する。
デプロイ時に、特権コンテナの禁止など、セキュリティのベストプラクティスをAzure Kubernetes Service (AKS) クラスターに強制する。
AKS用Azure Policyアドオンを有効にする。「Linuxベースのワークロード向けKubernetesクラスターポッドセキュリティ制限付き標準」という組み込みポリシーイニシアティブを割り当てる。
理由: これは、Kubernetes向けの一元化された大規模アドミッションコントローラーとしてAzure Policyを活用し、ワークロードがクラスター内で作成される前にセキュリティとコンプライアンスのガードレールを適用する。
Azure VNetからのすべてのインターネット向けトラフィックを、インターネットに到達する前に検査のためオンプレミスのセキュリティアプライアンスに戻すようにルーティングする。
サイト間VPNまたはExpressRouteを構成する。アドレスプレフィックス0.0.0.0/0に対してユーザー定義ルート（UDR）を作成し、ネクストホップを仮想ネットワークゲートウェイに設定する。
理由: 強制トンネリングとして知られるこのパターンは、Azureのインターネットへのデフォルトルートを上書きし、すべての送信トラフィックをゲートウェイ経由でオンプレミスネットワークに強制することで、どのVMも企業のセキュリティ制御をバイパスできないようにする。
Azure Firewallを使用して、VMからのアウトバウンドTLS暗号化トラフィックを脅威について検査する。
Azure Firewall Premiumをデプロイする。TLSインスペクションと侵入検知（IDPS）を有効にする。ファイアウォールに下位CA証明書を構成し、その公開鍵をクライアントVMに信頼されたルートCAとしてデプロイする。
理由: 暗号化されたトラフィックを検査するには、ファイアウォールが中間者操作を実行する必要がある。これには、Premium SKU、脅威検出のためのIDPS、およびクライアントマシンでのTLSエラーを回避するための適切な証明書インフラストラクチャが必要である。
複数のVNetおよびサブスクリプションにわたるすべての公開アプリケーションを、コスト効率の高い方法で大量のDDoS攻撃から保護する。
単一のAzure DDoS Protectionプランを作成する。この1つのプランを、保護が必要なパブリックIPアドレスを含むすべての仮想ネットワークに関連付ける。
理由: 単一のDDoS Protectionプランは最大100のVNetをカバーでき、VNetごとまたはIPごとにではなく、プランに対して定額の月額料金を支払う。この集中型モデルは、複数のプランを展開したり、IPごとの保護SKUを使用したりするよりもはるかに費用対効果が高い。
Microsoft Sentinelで重大度の高いインシデントが作成された場合、関連するユーザーアカウントをAzure ADで自動的に無効にし、Teamsでセキュリティチームに通知する。
重大度の高いインシデント作成時にトリガーされる自動化ルールを作成する。このルールはプレイブック（ロジックアプリ）を呼び出す必要がある。プレイブックはAzure ADコネクタを使用してユーザーを無効にし、Teamsコネクタを使用してメッセージを投稿する。
理由: これはSOAR（Security Orchestration, Automation, and Response）パターンを示す。自動化ルールはトリガー/条件エンジンであり、プレイブックはアクション/ワークフローエンジンである。
多数のAzureサブスクリプション全体にわたって、一貫したセキュリティポリシーセットを適用し、Defender for Cloudプランを有効にする。
すべてのサブスクリプションを管理グループの下に整理する。Azureセキュリティベンチマークポリシーイニシアティブを割り当て、必要なDefender for Cloudプランを管理グループレベルで有効にする。
理由: 管理グループは、エンタープライズ規模のガバナンスのための主要なツールである。このレベルで適用されるポリシーと設定は、すべての子サブスクリプションに継承され、一貫性を確保し、管理オーバーヘッドを削減する。
Sentinelで、ユーザーが初めて新しい国からサインインしたことを検出するカスタム検出を作成する。
スケジュール済みクエリ分析ルールを作成する。最近の`SigninLogs`と過去の`SigninLogs`の集計履歴を結合して、これまでに見たことのないUserPrincipalName/Countryの組み合わせを特定するKQLクエリを使用する。
理由: KQLを使用したスケジュール済みクエリルールは、Sentinelにおけるカスタム脅威検出の基盤であり、単純なイベントマッチングを超える複雑なステートフルロジックを可能にする。
コンプライアンスのためにSentinelでセキュリティログを2年間保持するが、コスト管理のために高速でインタラクティブなクエリに利用できるのは直近90日間のみとする。
Log Analyticsワークスペースで、「インタラクティブ保持」を90日に設定する。「合計保持」（アーカイブ）を730日（2年）に設定する。必要に応じてテーブルごとに保持ポリシーを構成する。
理由: この階層化アプローチは、コストと機能のバランスをとる。インタラクティブ層は高価だが高速である。アーカイブ層は長期保存のための非常に低コストである。アーカイブされたデータは、非同期の検索ジョブを介して、または一時的に復元して、引き続きクエリを実行できる。
インシデント調査中に、侵害されたユーザー、サインイン元のIP、アクセスしたリソース間の関係を迅速に視覚化する必要がある。
Microsoft Sentinelのインシデントページから、調査グラフを開く。グラフを使用して、さまざまなアラートやログソースにわたるエンティティとその接続を視覚的に探索する。
理由: 調査グラフは、攻撃のストーリーをマッピングする強力な視覚化ツールであり、ログクエリでイベントを手動で関連付けるよりも、インシデントの範囲とタイムラインをはるかに簡単に理解できるようにする。
ユーザーアカウントを侵害し、ネットワーク内の異常なリソースやホストにアクセスしようとしている攻撃者を検出する。
Microsoft Sentinelでユーザーおよびエンティティ行動分析（UEBA）が有効になっており、関連するデータソース（Azure ADログ、Defender for Endpoint/セキュリティイベント）が接続されていることを確認する。UEBAで横方向移動に関連する異常検出を監視する。
理由: UEBAは、各ユーザーとエンティティの正常な行動のベースラインを構築する。ユーザーが初めてサーバーにアクセスしたり、異常なプロトコルを使用したりするなど、横方向移動を示す逸脱の検出に優れており、これは静的ルールでは見つけにくい。
コンプライアンスには必要だがリアルタイム分析には不要な、大量で冗長なログのMicrosoft Sentinel取り込みコストを削減する。
これらのログのテーブルプランを「Basic Logs」に構成する。さらに、XPathクエリやその他の変換を使用するデータ収集ルール（DCR）で、取り込み前にノイズの多い低価値イベントを除外する。
理由: Basic Logsは、クエリ機能が制限され、保持期間が短くなる代わりに、取り込みコストを大幅に削減できる。DCRを使用してソースでフィルタリングすることは、不要なデータがワークスペースに到達するのを防ぐことでボリュームを削減する最も効果的な方法である。
既存および新規のすべてのAzureストレージアカウントで「セキュア転送が必要」を有効にするなど、セキュリティ設定を自動的に強制する。
`DeployIfNotExists`または`Modify`効果を持つAzure Policyを割り当てる。既存の非準拠リソースについては、ポリシー準拠ブレードから修復タスクを作成して変更を適用する。
理由: 監査および拒否ポリシーは、非準拠を報告またはブロックするだけである。`DeployIfNotExists`および修復タスクを伴う`Modify`は、構成ミスを積極的に修正し、ポリシーを自動化されたガバナンスとセキュリティ強化のための強力なツールにする。
AKSクラスターで、疑わしいプロセス実行や既知の悪意のあるIPにコンテナが接続するなど、ランタイム脅威を検出する。
Microsoft Defender for Containersを有効にする。これにより、クラスター内の各ノードにDaemonSet（Defenderエージェント）がデプロイされ、ホストおよびコンテナからセキュリティシグナルを収集し、リアルタイムの脅威検出を提供する。
理由: ACRスキャンが「シフトレフト」セキュリティを提供する一方で、ランタイム保護はデプロイ後に発生する脅威を検出するために重要である。Defender for Containersは、クラスター内のホストおよびワークロードレベルでこの可視性を提供する。
