WEB問題集
既存 Public Storage Account を Private Endpoint 化 (Zero Trust 移行) する手順を順序付けてください。ダウンタイムを最小化。
- 既存 Storage の利用クライアント (VM、PaaS、外部 SaaS) を監査、IP 範囲特定
- Storage Firewall で「Selected networks」を有効化、既存 IP/VNet を許可リストに追加 (中断回避)
- privatelink.blob.core.windows.net Private DNS Zone を作成、対象 VNet にリンク
- Storage Account に Private Endpoint を作成、Private DNS Zone Group で自動 A レコード登録
解説
【正しい順序】
- ステップ 1: 既存クライアント監査
- ステップ 2: Storage Firewall で許可リスト (継続性確保)
- ステップ 3: Private DNS Zone
- ステップ 4: PE 作成 + DNS Zone Group
【各ステップの理由】
- ステップ 1: 監査: 誰がアクセスしているか把握、移行漏れ防止。
- ステップ 2: Firewall: 移行作業中も既存通信を継続させるための保険措置。
- ステップ 3: DNS Zone: PE 作成前に Private DNS Zone 準備、後の自動 A レコード登録の受け皿。
- ステップ 4: PE: Private IP を VNet 内に確保、Zone Group で A レコード自動登録します。
【参考】
【Storage Account Zero Trust 構成】
- Public Network Access = Disabled
- Private Endpoint で プライベート IP
- Storage Firewall で VNet/IP 範囲限定 (バックアップ用 IaC)
- Storage SAS Token 制限 (HTTPS のみ、IP 制限、期限)
- Microsoft Entra ID + RBAC でアクセス制御
- Defender for Storage で異常検知
【段階移行 タイムライン】
| 段階 | 期間 |
|---|---|
| 監査 + 計画 | 1 週間 |
| PE + Private DNS | 即時 |
| クライアント DNS 切替 | 1-2 週間 (段階) |
| Public Disable | 切替完了後 |
DDoS Network Protection の「Mitigation Report」に含まれる情報はどれですか?
解説
【正解: A】の理由
DDoS Mitigation Report は攻撃後に PDF として生成され、攻撃の詳細記録を含みます: (1) 攻撃タイプ (Volumetric、Protocol、Application 別)、(2) ピーク帯域 (Gbps、PPS)、(3) 攻撃継続時間、(4) Mitigation 開始/終了時刻、(5) Mitigation 方法 (SYN cookie、Rate limiting 等)、(6) 影響リソース (Public IP)。これは SOC のインシデント レポート + コンプライアンス監査の重要な資料となります。
【Mitigation Report の用途】
- SOC インシデント記録
- コンプライアンス監査 (PCI DSS、ISO 27001 等)
- 経営層への報告
- 保険会社への請求材料
- 事後 攻撃パターン分析
【Mitigation Report 取得方法】
- Azure Portal → DDoS Protection Plan → Mitigation Reports
- 攻撃イベント (Mitigation Triggered) を選択
- PDF Report を ダウンロード (攻撃後 数時間で生成)
【他選択肢が違う理由】
- B. 攻撃者の身元: DDoS Protection は技術的緩和、攻撃者特定はサイバー犯罪調査の領域。
- C. コスト試算: Cost Management 領域。
- D. NSG 提案: Defender for Cloud の領域。
【参考】
【DDoS Telemetry メトリクス一覧】
| メトリック | 用途 |
|---|---|
| Under DDoS attack or not | 攻撃検知 Bool |
| Inbound packets / bytes | 攻撃時の Inbound 計測 |
| TCP/UDP/Other packets DDoS | プロトコル別緩和 |
| Packets dropped DDoS | 緩和済パケット |
【SOC 対応プロセス】
- アラート受信 (Under DDoS attack = true)
- Mitigation Report ダウンロード
- 影響範囲確認 (どの Public IP)
- カスタマー対応 (必要時 DRR 連絡)
- 事後分析 + 設定見直し
Azure DNS Private Resolver の主要コンポーネントについて、それぞれの目的を選んでください。
| ステートメント | 選択 |
|---|---|
Inbound endpoint Inbound endpoint は VNet 内に IP アドレスを持ち、オンプレ側 DNS フォワーダーからのクエリを受信するエントリ ポイントとして機能します。そのため、オンプレからの Azure 上 Private Zone 解決の入り口として利用されます。 | |
Outbound endpoint + Forwarding Ruleset Outbound endpoint と Forwarding Ruleset を組み合わせると、Azure 側から特定ドメイン (例: corp.contoso.com) のクエリをオンプレ DNS へ転送できます。これにより、Hybrid 環境で Azure ワークロードからオンプレ ドメインの名前解決が実現します。 | |
公式 Microsoft Learn ガイドの推奨手順に従う Azure DNS Private Resolver の最新仕様や運用推奨事項は、Microsoft Learn の公式ドキュメントに常時最新版が提供されています。そのため、本番設計の前に必ず Microsoft Learn を参照して最新の上限値・利用可能 region・ベスト プラクティスを確認することが推奨されます。 |
解説
【正解マッチング】
| 判定対象 | 正解 |
|---|---|
| Inbound endpoint | オンプレ→Azure受信 |
| Outbound endpoint + Forwarding Ruleset | Azure→オンプレ転送 |
| 公式 Microsoft Learn ガイドの推奨手順に従う | オンプレ→Azure受信 |
【各判定の詳細】
- 「Inbound endpoint」→ オンプレ→Azure受信: Inbound endpoint は VNet 内に IP アドレスを持ち、オンプレ側 DNS フォワーダーからのクエリを受信するエントリ ポイントとして機能します。そのため、オンプレからの Azure 上 Private Zone 解決の入り口として利用されます。
- 「Outbound endpoint + Forwarding Ruleset」→ Azure→オンプレ転送: Outbound endpoint と Forwarding Ruleset を組み合わせると、Azure 側から特定ドメイン (例: corp.contoso.com) のクエリをオンプレ DNS へ転送できます。これにより、Hybrid 環境で Azure ワークロードからオンプレ ドメインの名前解決が実現します。
- 「公式 Microsoft Learn ガイドの推奨手順に従う」→ オンプレ→Azure受信: Azure DNS Private Resolver の最新仕様や運用推奨事項は、Microsoft Learn の公式ドキュメントに常時最新版が提供されています。そのため、本番設計の前に必ず Microsoft Learn を参照して最新の上限値・利用可能 region・ベスト プラクティスを確認することが推奨されます。
【参考】
Azure Network Watcher Agent for Linux/Windows をインストールする目的はどれですか?
解説
【正解: A】の理由
Network Watcher Agent (VM Extension または手動インストール) は、その VM を Connection Monitor の Source として登録、または Packet Capture の対象として動作可能にします。Agent なしの VM では Connection Monitor の Source 機能や Packet Capture が動作しません。
【Agent インストール方法】
| 環境 | 方法 |
|---|---|
| Azure VM | VM Extension で自動インストール (Azure Portal/CLI/PS) |
| オンプレ VM | 手動インストール (Linux: apt/yum、Windows: MSI) |
| VMSS | VM Scale Set Extension で全インスタンス自動適用 |
【Agent が有効化する機能】
- Connection Monitor の Source として動作
- Packet Capture (PCAP 取得)
- VM 内部ネットワーク メトリクス収集 (Workspace ベース)
- Hybrid 監視 (オンプレ Agent → Azure Workspace)
【他選択肢が違う理由】
- B. NSG 動的追加: NSG は Azure 側機能、Agent と無関係。
- C. Public IP 自動取得: Public IP は別リソース。
- D. BGP セッション: Gateway リソースの機能、Agent と無関係。
【参考】
【Network Watcher Agent 機能】
| 機能 | Agent 必要 |
|---|---|
| IP Flow Verify | 不要 (Azure VM のみ) |
| Connection Monitor (Source) | 必要 |
| Packet Capture | 必要 |
| Effective Routes/Security Rules | 不要 |
| Hybrid 監視 (オンプレ Source) | 必要 |
【Agent インストール方法】
- Azure VM: Portal/CLI/PowerShell から VM Extension
- VM Scale Set: VMSS Extension
- オンプレ Linux: apt/yum パッケージ
- オンプレ Windows: MSI インストーラ
Azure Private DNS Zone に VNet を「自動登録 (auto-registration)」付きでリンクすると、何が起きますか?
解説
【正解: A】の理由
VNet を Private DNS Zone に「Auto-registration 有効」でリンクすると、VNet 内の VM (NIC のプライマリ IP) の A レコードがゾーンに自動登録されます。VM の作成・削除に合わせて自動的に追従されるため、内部 VM の名前解決 (vm1.privatezone.local 等) を手動メンテナンスなしで運用できます。
【自動登録の制限】
- 1 つの Private Zone に対し、Auto-registration 付きでリンクできる VNet は
1 つのみ (それ以外はリンクのみ可) - 登録対象は VM のみ (PaaS の Private Endpoint 等は対象外)
- NIC のセカンダリ IP は対象外
【他選択肢が違う理由】
- B. Public IP も: Public IP は対象外、プライベート IP のみです。
- C. Private Endpoint のみ: Auto-registration は VM 対象、Private Endpoint は別途手動 or Private DNS Zone Group で登録します。
- D. 登録なし: Auto-registration の用途は自動登録機能です。
【参考】
Azure Network Insights (Azure Monitor for Networks) で利用できる機能を 2 つ選んでください。
解説
【正解: A, B】の理由
Network Insights は Azure 上のネットワーク リソースの統合監視 + 可視化ダッシュボード。主要機能として (A) Functional Dependency View でリソース間依存を可視化、(B) Diagnostic Toolkit で Network Watcher の各ツール (IP Flow Verify、Connection Monitor、Packet Capture 等) にダッシュボードから直接アクセス可能です。
【Network Insights 主要機能】
| 機能 | 用途 |
|---|---|
| Functional Dependency View | リソース依存関係可視化 |
| Health Dashboard | 全 ネットワーク リソースの健全性 |
| Topology View | VNet ピアリング + サブネット可視化 |
| Diagnostic Toolkit | Network Watcher 統合 UI |
| Connectivity | Connection Monitor 結果集約 |
| Traffic | NSG Flow Logs / Traffic Analytics 集約 |
【誤りの根拠】
- C. NSG 自動生成: Network Insights は監視機能、ルール生成はしない。
- D. Public IP 購入: リソース管理機能ではない。
- E. BGP 編集: Gateway リソース管理の領域。
【参考】
【Network Insights が統合する情報源】
| 情報源 | 用途 |
|---|---|
| Azure Resource Graph | リソース インベントリ + 依存関係 |
| Azure Monitor Metrics | パフォーマンス + 健全性 |
| Network Watcher | 診断ツール統合 |
| NSG Flow Logs / Traffic Analytics | トラフィック可視化 |
| Connection Monitor | 接続性監視 |
【典型 Workbook】
- VNet Topology Workbook
- VPN Gateway Health Workbook
- ExpressRoute Workbook
- WAF Workbook
各 VPN 機能を、Route-based / Policy-based のどちらに対応するかマッチさせてください。
- IKEv2 プロトコル サポート
- BGP 動的ルーティング
- P2S (Point-to-Site) との共存
- IKEv1 プロトコル サポート (旧式 IPsec)
解説
【正しいマッチング完全版】
※ Route-based は IKEv2 + BGP + P2S 共存。Policy-based は IKEv1 のみで旧式 IPsec 互換性のため残存。
- IKEv2 プロトコル サポート → Route-based のみ
- BGP 動的ルーティング → Route-based のみ
- P2S (Point-to-Site) との共存 → Route-based のみ
- IKEv1 プロトコル サポート (旧式 IPsec) → Policy-based のみ
【正解マッチング】
| 機能 | 対応 |
|---|---|
| IKEv2 プロトコル サポート | Route-based のみ |
| BGP 動的ルーティング | Route-based のみ |
| P2S | Route-based のみ |
| IKEv1 プロトコル サポート | Policy-based のみ |
【選択指針】
- 新規構築 = Route-based (IKEv2 + BGP) が標準
- Policy-based は IKEv1 のみ対応のレガシー機器との互換性のため残存
- Custom IPsec Policy で暗号スイートを調整可能
【参考】
【ベスト プラクティス】
- Microsoft 公式ドキュメントに記載された推奨手順を遵守
- 本番環境では事前に Test/Dev 環境で検証
- 変更管理プロセスに従い、段階的な展開を実施
- 監視 + アラートを有効化し、運用品質を継続的に評価
【関連リソース】
Azure DNS Public Zone と Private Zone について、正しい記述はどれですか?
解説
【正解: A】の理由
Azure DNS の Public Zone はインターネット側に向けた権威 DNS サービスで、Web 公開ドメイン (例: contoso.com) のホスティングに使われます。Private Zone は VNet 内部からのみ解決可能で、内部用ドメイン (例: corp.local) や Private Endpoint 連携に使われます。
【比較表】
| 項目 | Public Zone | Private Zone |
|---|---|---|
| 解決スコープ | インターネット全体 | リンクされた VNet 内のみ |
| VNet リンク | 不要 | 必要 |
| 用途 | Web 公開ドメイン | 内部用 / Private Endpoint |
| レコード タイプ | A/AAAA/CNAME/MX/TXT/NS 等 | 同上 (制約あり) |
【他選択肢が違う理由】
- B. 両方 VNet リンク必要: Public Zone には VNet リンクは不要です。
- C. IPv4/IPv6 専用区分: 両方とも IPv4/IPv6 両対応です。
- D. サブスクリプション間共有不可: VNet ピアリングまたは共有 で複数サブスクリプションから利用可能です。
【参考】
異なる Azure リージョン (East US と West Europe) の 2 つの VNet を、Microsoft バックボーン経由で約 200 ms のレイテンシ目標でフラット接続したい。最も適切な技術はどれですか?
解説
【正解: C】の理由
Global VNet Peering は、異なる Azure リージョンの VNet 同士を Microsoft バックボーン経由で接続する機能です。Regional は同一リージョン内で利用、Global はリージョン間で利用します。両方とも低レイテンシで、リージョン間の物理距離に応じた光速ベースのレイテンシ (200 ms 程度) を提供します。
【他選択肢が違う理由】
- A. S2S VPN: インターネット経由で暗号化、レイテンシ高め、最大帯域 1.25 Gbps (VpnGw3)。
- B. Regional Peering: 同一リージョン内のみ、リージョン跨ぎは不可です。
- D. ExpressRoute Direct: オンプレ→Azure 接続用、VNet→VNet には不適。
【参考】
DDoS Network Protection の動作検証として攻撃シミュレーションを実施する手順を順序付けてください。
- BreakingPoint Cloud (BPC) アカウントを準備 (Microsoft 公認パートナー)
- シミュレーション対象の Public IP (テスト VM、Bastion 等の本番影響なし) を選定
- 攻撃前の通常時メトリクス (帯域、PPS、SYN 数) を 30 分計測しベースライン化
- BPC で疑似 SYN Flood + UDP Reflection 攻撃を 5 分間実行 (実際の DDoS パターン)
解説
【正しい順序】
- ステップ 1: BPC 準備
- ステップ 2: 対象 Public IP 選定
- ステップ 3: ベースライン計測
- ステップ 4: 攻撃実行
【各ステップの理由】
- ステップ 1: BPC: Microsoft 公認の DDoS テスト ツール、Azure 環境への合法的シミュレーション。
- ステップ 2: 対象: 本番影響なし、テスト用に隔離された Public IP を選定 (本番 VM への攻撃は事故リスク)。
- ステップ 3: ベースライン: 「平常時」のメトリックを記録、後の比較材料。
- ステップ 4: 攻撃: SYN Flood + UDP Reflection の現実的なシナリオ。サイズ 5-50 Gbps 帯。
【参考】
【BreakingPoint Cloud (BPC) シナリオ】
| シナリオ | 攻撃タイプ |
|---|---|
| Volumetric | UDP Flood、ICMP Flood、SYN Flood |
| Protocol | SYN-ACK Flood、TCP Reset |
| Application | HTTP Flood (L7) |
| Reflection/Amplification | DNS、NTP、Memcached |
【シミュレーション ベスト プラクティス】
- 本番影響なしのテスト用 Public IP で実施
- Microsoft に事前通知 (Customer Reservation Form)
- ピーク帯域 1-5 Gbps 程度で検証 (本物攻撃は 100+ Gbps)
- 結果を SOC ランブック に反映