Q1.ある Azure サブスクリプションには、次のリソースが配置されています。
・Server1 という名前の Azure SQL Database 論理サーバーがあり、その配下には DB1 という名前のデータベースが存在します。
・Instance1 という名前の Azure SQL Managed Instance があり、このマネージド インスタンスには DB2 という名前のデータベースが存在します。
これらに対してデータベース監査を構成する予定です。
ソリューションは、次の要件を満たす必要があります。
・KQL クエリを実行できる場所で、監査データを一元的に参照できるようにする。
・データベースが新たに追加された際の継続的な運用負荷を最小限に抑える。
何を構成すべきですか。
回答領域で適切な選択肢を選んでください。
解答を見る
監査を各サーバーまたはインスタンスのレベルで有効化すると、その配下にあるデータベースへ監査設定をまとめて適用できるため、今後データベースが追加されても個別設定を繰り返す必要がなく、管理負担を抑えられます。
また、監査ログの送信先を Log Analytics ワークスペースにすると、複数リソースの監査データを一元的に保存し、Azure Monitor Logs で KQL を使用して検索、分析できます。
Event Hubs は外部システムへのストリーミングに適していますが、直接 KQL で分析する保存先ではありません。
Storage アカウントは長期保存に適していますが、KQL による一元分析という要件には Log Analytics が最適です。
サーバーおよびデータベース レベルでの監査ポリシー
Azure SQL Database および Azure Synapse Analytics の監査を設定する
Q2.ある企業では、生成 AI が作成したコンテンツを利用者へ表示する前に、その安全性を確認する運用を検討しています。
狙いは、有害・不適切、またはポリシーに反する応答を自動的に検出することです。
どの機能を優先的に採用すべきですか。
解答を見る
コンテンツ フィルタリングは、AI への入力と生成された出力を分析し、暴力、性的内容、自傷、憎悪などの有害なコンテンツを検出またはブロックするための機能です。
また、安全性評価を使用すると、生成 AI アプリケーションの応答に含まれる有害性やポリシー違反の程度を継続的に測定できます。
コンテキスト ウィンドウの拡大は処理可能な情報量、GPU の追加は性能、仮想ネットワークは通信の分離や保護に関係しますが、生成内容そのものの安全性を直接判定する機能ではありません。
Microsoft では、Azure AI Content Safety を利用してユーザー生成コンテンツと AI 生成コンテンツの有害性を検出できます。
Azure AI Content Safety とは?
リスクと安全性の評価者
Q3.ある企業では、基幹システムと連携する AI チャットボットを狙ったプロンプトインジェクション攻撃を懸念しています。
最も効果的な緩和策はどれですか。
解答を見る
プロンプトインジェクションは、悪意のある入力によってモデルの指示や動作を操作し、接続されたデータやツールを不正に利用させる攻撃です。
そのため、外部入力を信頼せず、検証や Prompt Shields などで不正な指示を検出することが重要です。
さらに、攻撃が検出をすり抜けた場合に備え、AI が呼び出せるツールと実行権限を必要最小限に制限することで被害を抑えます。
ログの無効化は調査能力を低下させ、応答の無条件な信頼は危険です。
温度パラメーターは出力の多様性を調整するものであり、攻撃対策にはなりません。
プロンプト シールド
人工知能セキュリティ
Q4.Workspace1 という名前の Microsoft Sentinel ワークスペースを新規に構成しています。
社内には、Azure Marketplace の Microsoft Sentinel ソリューションでは対応していない外部の IT サービス管理（ITSM）システムが存在します。
Workspace1 で新規のセキュリティ インシデントが発生するたびに、その ITSM システム上でサービス チケットが自動生成されるようにする必要があります。
何を作成すべきですか。
解答を見る
Microsoft Sentinel のプレイブックは、Azure Logic Apps を基盤とする自動化ワークフローです。
新しいインシデントをトリガーとして、外部 ITSM システムの API や利用可能な Logic Apps コネクタを呼び出し、サービス チケットを自動作成できます。
対象の ITSM 製品に Microsoft Sentinel 用のパッケージ化されたソリューションがなくても、カスタム ワークフローとして連携可能です。
実運用では、インシデント作成時にプレイブックを実行する自動化ルールも構成します。
ブックは可視化、ウォッチリストは参照データの管理、分析ルールは脅威を検出してアラートやインシデントを生成するための機能であり、外部システムでのチケット作成には適していません。
Microsoft Sentinelのプレイブックを使用して脅威対応を自動化する
Microsoft Sentinel プレイブック用の Azure Logic Apps
Q5.インターネットに公開された、App1、App2、App3 という名前の 3 つの Azure App Service Web アプリがあります。
いずれのアプリでも組み込み認証を使用しています。
このうち App2 はバックエンド API をホストしています。
本来その API を利用できないはずの一部の社内ユーザーが、App2 にサインインできてしまう状態です。
App2 へのアクセスを、割り当て済みの Microsoft Entra ユーザーおよびグループのみに制限する必要があります。
App2 には何を構成すべきですか。
回答するには、適切な構成を正しい方法へドラッグしてください。
各構成は、1回、複数回、または一度も使用しない場合があります。
ウィンドウ間の分割バーをドラッグしたり、スクロールして内容を表示したりする必要がある場合があります。
選択肢を要件のドロップ欄へドラッグ、またはタップして配置。配置済みの欄をクリックで戻せます（同じ選択肢は複数回使用可）。
IPアクセス制限
ローカル認証
Microsoft IDプロバイダー
ロールベースのアクセス制御（RBAC）の割り当て
テナント全体の管理者同意
解答を見る
App2 では、組み込み認証の ID プロバイダーとして Microsoft ID プロバイダーを構成し、Microsoft Entra ID でユーザーを認証します。
さらに、対応するエンタープライズ アプリケーションで「割り当てが必要ですか」を［はい］に設定すると、明示的に割り当てられたユーザーまたはグループだけがサインインしてアクセス トークンを取得できます。
IP アクセス制限は接続元ネットワークを制御する機能であり、個々のユーザーやグループの利用可否は制御しません。
RBAC は Azure リソースの管理権限を付与する仕組みであり、この要件のアプリ利用制御には該当しません。
Azure App Service および Azure Functions での認証と承認
Microsoft Entra アプリを一連のユーザーのみに制限する
Q6.組織で Microsoft Security Copilot を運用しています。
現状では、Security Copilot の共同作成者が、自分のセッション向けのカスタムプラグインを作成できるだけでなく、組織全体のカスタムプラグインまで管理できてしまいます。
共同作成者による組織全体のカスタムプラグインの管理を禁止する必要があります。
ただし、この対応が、共同作成者が自分のセッション用のカスタムプラグインを作成する機能に影響してはなりません。
プラグイン設定で何を選択すべきですか。
解答を見る
テナントスコープのカスタムプラグインを管理できるユーザーを所有者のみに設定すると、共同作成者は組織全体で使用されるプラグインを追加または管理できなくなります。
一方、ユーザースコープの設定は変更しないため、共同作成者は自分のセッションで使用するカスタムプラグインを引き続き作成および管理できます。
B はユーザースコープの権限まで制限するため要件に反します。
A は共同作成者による組織全体の管理を許可し続け、C はユーザースコープだけを指定するため、テナント全体の管理権限を制限できません。
Microsoft 公式文書では、現在も製品名として Microsoft Security Copilot が使用されています。
Microsoft Security Copilotでプラグインを管理する
Microsoft Security Copilotでプラグインとエージェントを管理する
Q7.cg1.contoso.com という DNS 名を持つ、CG1 という名前の Azure Container Instances のコンテナー グループがあります。
CG1 は次のように構成されています。
TCP ポート443で HTTPS を提供し、App1 という名前のアプリケーションをホストする container1 という名前の Linux コンテナー。
TCP ポート5000で待ち受け、App1 からのみアクセスされる container2 という名前の Linux コンテナー。
パブリック IP アドレス。
セキュリティ レビューの結果、外部クライアントが CG1 のパブリック IP アドレス経由で TCP ポート5000へ到達できてしまうことが判明しました。
次の要件を満たす必要があります。
外部クライアントが TCP ポート443のみを使って container1 にアクセスできるようにする。
container1 は引き続き container2 にアクセスできるようにする。
何を構成すべきですか。
回答領域で適切な選択肢を選んでください。
解答を見る
外部クライアントからポート5000へ接続できないようにするには、コンテナー グループのパブリック IP アドレスではポート443のみを公開します。
Azure Container Instances の同一コンテナー グループ内にあるコンテナーは、同じホストとネットワーク名前空間を共有し、外部公開されていないポートも localhost 経由で相互通信できます。
そのため、App1 から container2 へ接続するエンドポイントには、localhost:5000 を指定します。
cg1.contoso.com:5000 を使用するとパブリック側のポート公開が必要になり、外部アクセスを防止する要件を満たせません。
Azure Container Instances は現在も正式なサービス名称です。
Azure Container Instances のコンテナー グループ
チュートリアル:Resource Manager テンプレートを使用してマルチコンテナー グループをデプロイする
Q8.ある組織では、開発者が Azure OpenAI リソースを利用できるようにする計画を進めています。
管理部門は、付与するアクセス許可を最小特権の原則に沿ったものにしたいと考えています。
何を使用すべきですか。
解答を見る
Azure RBAC では、ユーザー、グループ、サービス プリンシパルなどに対し、リソースとスコープを指定して必要な権限だけを割り当てられます。
そのため、開発者の作業内容に対応する最小限の組み込みロールまたはカスタム ロールを付与することで、最小特権を実現できます。
Azure Policy の除外はポリシー適用の対象外を定義する機能であり、アクセス権を付与する仕組みではありません。
リソース ロックは誤削除や変更を防止し、管理グループはサブスクリプションを階層管理しますが、個別のアクセス許可は制御しません。
なお、最新の Microsoft Learn では関連プラットフォーム名として Microsoft Foundry が使用されており、Azure OpenAI への個別アクセス管理には引き続き Azure RBAC が使用されます。
Azure OpenAI Service のロールベースのアクセス制御
Azure 組み込みロール
Q9.ある企業では、管理者に対して権限を常時割り当てておく代わりに、特権を持つ Azure ロールへ Just-In-Time でアクセスを付与したいと考えています。
どの Microsoft Entra の機能を実装すべきですか。
解答を見る
Microsoft Entra Privileged Identity Management（PIM）では、管理者を Azure ロールの有資格ユーザーとして登録し、必要なときだけ一定期間ロールをアクティブ化できます。
永続的な特権を削減し、Just-In-Time で必要な時間だけアクセス権を付与できることが主な利点です。
また、アクティブ化時に多要素認証、承認、理由の入力などを要求して特権利用を厳格に制御できます。
動的グループは属性に基づくメンバーシップ管理、アクセス パッケージはリソースへのアクセス要求とライフサイクル管理、セルフサービス パスワード リセットはアカウント回復を目的とするため、この要件には適しません。
製品名は現在も Microsoft Entra Privileged Identity Management です。
Microsoft Entra Privileged Identity Management とは
Azure RBAC での有資格ロールと期限付きロールの割り当て
Q10.storage1 という名前の Azure Storage アカウントがあり、その中に Azure ファイル共有が含まれています。
App1 という名前のアプリケーションは、システム割り当てマネージド ID を使ってこのファイル共有へアクセスします。
一方、管理者はストレージ アカウントのアクセス キーを利用してファイル共有にアクセスしています。
App1 がストレージ アカウントのアクセス キーを使わずにファイル共有へアクセスできるようにする必要があります。
storage1 で何を構成すべきですか。
解答を見る
App1 がアクセス キーを保持せずに Azure Files を読み取るには、マネージド ID を Microsoft Entra ID のセキュリティ プリンシパルとして使用し、Azure RBAC のデータ アクセス ロールを付与します。
ストレージ ファイル データ特権閲覧者ロールを App1 のマネージド ID に割り当てることで、OAuth を使用した読み取りアクセスが可能になります。
A はキーを引き続き使用し、B はキー認証を禁止するだけで権限を付与しません。
C は Azure portal 上の既定の認証方式を変更する設定であり、App1 のアクセス権にはなりません。
なお、Azure AD の現在の名称は Microsoft Entra ID です。
Azure ファイル共有に共有レベルのアクセス許可を割り当てる