WEB問題集
ある企業は複数のリージョンに展開された 50 台の仮想マシン、複数の App Service、AKS クラスターを運用しています。これらすべてのリソースのログとメトリックを一元的に収集し、KQL でクエリ可能にしたうえで、管理工数を最小化したいと考えています。推奨すべきソリューションに含めるべきものはどれですか。
解説
【正解: A】の理由
複数リージョンに分散した 50 台の VM、複数の App Service、AKS クラスターのログとメトリックを一元的に収集し、KQL でクロスリソースのクエリを行いつつ管理工数を最小化するには、単一の Log Analytics ワークスペースに集約するのが最適です。各リソースの診断設定で、プラットフォーム ログとメトリックの送信先を同一ワークスペースに指定すれば、テーブルをまたいだ相関分析や、複数リソースを横断するアラート ルールを一箇所で構成できます。ワークスペースを分割すると横断クエリでは複数ワークスペースを明示的に指定する必要が生じ、アクセス制御やコスト管理も煩雑になります。データ主権など特別な要件がない限り、Microsoft も集約を推奨しています。
【他選択肢が違う理由】
- B: リソース グループごとにワークスペースを分けると横断的な KQL クエリやアクセス管理が複雑化し、管理工数がかえって増大します。
- C: ローカルにログを保存して定期的に Storage へコピーする方式は KQL でクエリできず、リアルタイム分析やアラートに適しません。
- D: すべてのメトリックを Event Hubs にのみ送る構成は外部 SIEM への転送用ストリームで、それ自体は KQL のクエリ先になりません。
【参考】
New-AzRoleAssignment -SignInName "user@contoso.com" `
-RoleDefinitionName "{{BLANK1}}" `
-ResourceGroupName "{{BLANK2}}"| ステートメント | 選択 |
|---|---|
|
{{BLANK1}}
割り当てるロール名を指定する -RoleDefinitionName には、要件である Reader を指定します。Owner は閲覧者要件に反する過剰な権限です。 |
|
|
{{BLANK2}}
RG スコープでの割り当てには -ResourceGroupName にリソースグループ名 rg-prod を指定します。 |
解説
【正解マッチング】
| 判定対象 | 正解 |
|---|---|
| {{BLANK1}}: 割り当てるロール名 (-RoleDefinitionName) | Reader |
| {{BLANK2}}: 割り当てスコープのリソースグループ名 (-ResourceGroupName) | rg-prod |
【ポイント】
Azure RBAC のロール割り当てを PowerShell で行うには New-AzRoleAssignment を使用し、割り当てるロールを -RoleDefinitionName で、割り当てのスコープを指定します。要件では閲覧のみを許可するため、-RoleDefinitionName には組み込みロールの Reader を指定します。Reader は対象スコープ内のリソースの参照を許可し、作成・変更・削除は許可しない、最小権限に近い読み取り専用ロールです。Owner はすべての操作に加えてアクセス権の委任まで許可する過剰な権限であり、閲覧のみという要件に反します。割り当てのスコープはリソース グループ単位のため、-ResourceGroupName に rg-prod を指定し、この割り当てを rg-prod 配下に限定します。New-AzRoleDefinition はカスタム ロール定義を新規作成するコマンドレットであり、既存ロールの割り当てには使用しません。
【参考】
- Kusto (KQL) クエリやアラート ルールで監視・通知を構成する
- 収集するログ カテゴリとメトリックを選択する
- 対象リソースに診断設定を追加し送信先にワークスペースを指定する
- ログを集約する Log Analytics ワークスペースを作成する
解説
【正しい順序】
- ログを集約する Log Analytics ワークスペースを作成する
- 対象リソースに診断設定を追加し送信先にワークスペースを指定する
- 収集するログ カテゴリとメトリックを選択する
- Kusto (KQL) クエリやアラート ルールで監視・通知を構成する
【ポイント】
- ステップ 1 ワークスペース作成: ログとメトリックの集約先となる Log Analytics ワークスペースを最初に用意します。
- ステップ 2 診断設定追加: 各リソースに診断設定を追加し、送信先として作成済みワークスペースを指定して収集を有効化します。
- ステップ 3 カテゴリ選択: 必要なログ カテゴリとメトリックを選び、過剰なコストを避けつつ要件に必要なデータを収集します。
- ステップ 4 クエリ・アラート構成: KQL クエリで分析し、アラート ルールを設定して異常時に通知が飛ぶようにします。
【誤った順序の問題点】
- ワークスペース作成前に診断設定を追加する: 送信先のワークスペースが存在しないと診断設定でワークスペースを指定できず、構成が完了しません。
- カテゴリ選択を省略する: 収集対象を選ばないと必要なログが取得できず、または不要なデータでコストが増大します。
【参考】
ある設計で、Azure リソースが他の Azure サービスへ資格情報レスでアクセスする ID 戦略を推奨します。マネージド ID の正しい設計判断を 2 つ選んでください。
解説
【正解: B / C】の理由
マネージド ID は、資格情報を保管・ローテーションすることなく、Azure リソースが他の Azure サービスへ Entra ID 認証と RBAC で安全にアクセスするための仕組みです。設計では 2 種類を使い分けます。単一のリソースにのみ紐づき、そのリソースのライフサイクルに連動して自動的に作成・削除されてよい場合は、システム割り当てマネージド ID を選びます。一方、複数のリソースで同じ ID と権限を共有したい場合や、リソースとは独立したライフサイクルで ID を管理したい場合は、ユーザー割り当てマネージド ID を選びます。いずれもシークレット管理が不要で漏えいリスクを抑えられます。選択肢 B と C はこの使い分けを正しく示すため正解です。
【他選択肢が違う理由】
- A: マネージド ID は Azure リソースに紐づくため、Azure 外のオンプレミス サーバーには割り当てられません。
- D: ストレージ アカウント キーの使用は資格情報レスの ID 戦略ではなく、最小権限や監査の観点でも劣ります。
- E: シークレットをコードにハードコードすると漏えいリスクが高く、マネージド ID を使う目的そのものに反します。
【参考】
- Microsoft Entra B2B コラボレーション
- Privileged Identity Management (PIM)
- マネージド ID
- サービス プリンシパル
解説
【正解マッチング】
| 項目 | 説明 |
|---|---|
| マネージド ID | Azure リソースが資格情報を保持せずに別の Azure サービスへ認証する |
| サービス プリンシパル | 非対話型の自動化スクリプトやアプリがディレクトリ オブジェクトとして認証する |
| Privileged Identity Management (PIM) | 管理者ロールを必要なときだけ時間制限付きで昇格させる |
| Microsoft Entra B2B コラボレーション | 取引先のユーザーを自社テナントのアプリにゲストとして招待する |
【ポイント】
認証や権限管理の各機能は目的が明確に分かれています。マネージド ID は、VM や App Service などの Azure リソースに Entra ID が自動管理する ID を紐付け、資格情報をコードや構成に保持せずに Key Vault やストレージなど別の Azure サービスへ安全に認証させます。サービス プリンシパルは、アプリケーションや自動化スクリプトがディレクトリ オブジェクトとして認証するための ID で、シークレットや証明書を用いた非対話型のサインインに利用されます。Privileged Identity Management (PIM) は、管理者ロールを常時付与せず、必要なときだけ承認や MFA を伴って時間制限付きで昇格 (ジャストインタイム) させ、権限の常時保有によるリスクを下げます。Microsoft Entra B2B コラボレーションは、取引先など外部組織のユーザーをゲストとして自社テナントのアプリに招待し、外部 ID のまま安全に共同作業させます。