Microsoft SC-500 (Cloud and AI Security Engineer Associate Certification) 1-10

監査を各サーバーまたはインスタンスのレベルで有効化すると、その配下にあるデータベースへ監査設定をまとめて適用できるため、今後データベースが追加されても個別設定を繰り返す必要がなく、管理負担を抑えられます。
また、監査ログの送信先をLog Analytics ワークスペースにすると、複数リソースの監査データを一元的に保存し、Azure Monitor LogsでKQLを使用して検索、分析できます。
Event Hubsは外部システムへのストリーミングに適していますが、直接KQLで分析する保存先ではありません。
Storageアカウントは長期保存に適していますが、KQLによる一元分析という要件にはLog Analyticsが最適です。

サーバーおよびデータベース レベルでの監査ポリシー
Azure SQL Database および Azure Synapse Analytics の監査を設定する

コンテンツ フィルタリングは、AIへの入力と生成された出力を分析し、暴力、性的内容、自傷、憎悪などの有害なコンテンツを検出またはブロックするための機能です。
また、安全性評価を使用すると、生成AIアプリケーションの応答に含まれる有害性やポリシー違反の程度を継続的に測定できます。
コンテキストウィンドウの拡大は処理可能な情報量、GPUの追加は性能、仮想ネットワークは通信の分離や保護に関係しますが、生成内容そのものの安全性を直接判定する機能ではありません。Microsoftでは、Azure AI Content Safetyを利用してユーザー生成コンテンツとAI生成コンテンツの有害性を検出できます。

Azure AI Content Safety とは?
リスクと安全性の評価者

プロンプトインジェクションは、悪意のある入力によってモデルの指示や動作を操作し、接続されたデータやツールを不正に利用させる攻撃です。
そのため、外部入力を信頼せず、検証やPrompt Shieldsなどで不正な指示を検出することが重要です。
さらに、攻撃が検出をすり抜けた場合に備え、AIが呼び出せるツールと実行権限を必要最小限に制限することで被害を抑えます。ログの無効化は調査能力を低下させ、応答の無条件な信頼は危険です。
温度パラメーターは出力の多様性を調整するものであり、攻撃対策にはなりません。

プロンプト シールド
人工知能セキュリティ

Microsoft Sentinelのプレイブックは、Azure Logic Appsを基盤とする自動化ワークフローです。
新しいインシデントをトリガーとして、外部ITSMシステムのAPIや利用可能なLogic Appsコネクタを呼び出し、サービスチケットを自動作成できます。
対象のITSM製品にMicrosoft Sentinel用のパッケージ化されたソリューションがなくても、カスタムワークフローとして連携可能です。
実運用では、インシデント作成時にプレイブックを実行する自動化ルールも構成します。
ブックは可視化、ウォッチリストは参照データの管理、分析ルールは脅威を検出してアラートやインシデントを生成するための機能であり、外部システムでのチケット作成には適していません。

Microsoft Sentinelのプレイブックを使用して脅威対応を自動化する
Microsoft Sentinel プレイブック用の Azure Logic Apps

App2では、組み込み認証のIDプロバイダーとしてMicrosoft ID プロバイダーを構成し、Microsoft Entra IDでユーザーを認証します。
さらに、対応するエンタープライズ アプリケーションで「割り当てが必要ですか」を［はい］に設定すると、明示的に割り当てられたユーザーまたはグループだけがサインインしてアクセストークンを取得できます。
IPアクセス制限は接続元ネットワークを制御する機能であり、個々のユーザーやグループの利用可否は制御しません。
RBACはAzureリソースの管理権限を付与する仕組みであり、この要件のアプリ利用制御には該当しません。

Azure App Service および Azure Functions での認証と承認
Microsoft Entra アプリを一連のユーザーのみに制限する

テナントスコープのカスタムプラグインを管理できるユーザーを所有者のみに設定すると、共同作成者は組織全体で使用されるプラグインを追加または管理できなくなります。
一方、ユーザースコープの設定は変更しないため、共同作成者は自分のセッションで使用するカスタムプラグインを引き続き作成および管理できます。
Bはユーザースコープの権限まで制限するため要件に反します。
Aは共同作成者による組織全体の管理を許可し続け、Cはユーザースコープだけを指定するため、テナント全体の管理権限を制限できません。
Microsoft公式文書では、現在も製品名としてMicrosoft Security Copilotが使用されています。

Microsoft Security Copilotでプラグインを管理する
Microsoft Security Copilotでプラグインとエージェントを管理する

外部クライアントからポート5000へ接続できないようにするには、コンテナー グループのパブリック IP アドレスではポート443のみを公開します。
Azure Container Instancesの同一コンテナー グループ内にあるコンテナーは、同じホストとネットワーク名前空間を共有し、外部公開されていないポートもlocalhost経由で相互通信できます。そのため、App1からcontainer2へ接続するエンドポイントには、localhost:5000を指定します。
cg1.contoso.com:5000を使用するとパブリック側のポート公開が必要になり、外部アクセスを防止する要件を満たせません。Azure Container Instancesは現在も正式なサービス名称です。

Azure Container Instances のコンテナー グループ
チュートリアル:Resource Manager テンプレートを使用してマルチコンテナー グループをデプロイする

Azure RBACでは、ユーザー、グループ、サービス プリンシパルなどに対し、リソースとスコープを指定して必要な権限だけを割り当てられます。
そのため、開発者の作業内容に対応する最小限の組み込みロールまたはカスタムロールを付与することで、最小特権を実現できます。
Azure Policyの除外はポリシー適用の対象外を定義する機能であり、アクセス権を付与する仕組みではありません。
リソース ロックは誤削除や変更を防止し、管理グループはサブスクリプションを階層管理しますが、個別のアクセス許可は制御しません。
なお、最新のMicrosoft Learnでは関連プラットフォーム名としてMicrosoft Foundryが使用されており、Azure OpenAIへの個別アクセス管理には引き続きAzure RBACが使用されます。

Microsoft Foundry Models (クラシック) での Azure OpenAI のロールベースのアクセス制御
組み込みロールのAzure

Microsoft Entra Privileged Identity Management（PIM）では、管理者をAzureロールの有資格ユーザーとして登録し、必要なときだけ一定期間ロールをアクティブ化できます。
永続的な特権を削減し、Just-In-Timeで必要な時間だけアクセス権を付与できることが主な利点です。
また、アクティブ化時に多要素認証、承認、理由の入力などを要求して特権利用を厳格に制御できます。
動的グループは属性に基づくメンバーシップ管理、アクセス パッケージはリソースへのアクセス要求とライフサイクル管理、セルフサービス パスワード リセットはアカウント回復を目的とするため、この要件には適しません。
製品名は現在もMicrosoft Entra Privileged Identity Managementです。

Microsoft Entra Privileged Identity Management とは
Azure RBAC での有資格ロールと期限付きロールの割り当て

App1 がアクセスキーを保持せずに Azure Files を読み取るには、マネージド IDを Microsoft Entra ID のセキュリティプリンシパルとして使用し、Azure RBAC のデータアクセスロールを付与します。
ストレージ ファイル データ特権閲覧者ロールを App1 のマネージド ID に割り当てることで、OAuth を使用した読み取りアクセスが可能になります。
A はキーを引き続き使用し、B はキー認証を禁止するだけで権限を付与しません。
C は Azure portal 上の既定の認証方式を変更する設定であり、App1 のアクセス権にはなりません。
なお、Azure AD の現在の名称は Microsoft Entra ID です。

Azure ファイル共有に共有レベルのアクセス許可を割り当てる