WEB問題集
AZ700-SEC#9
複数 Azure Firewall インスタンスのルールを集中管理する Microsoft マネージド サービスはどれですか?
解説
【正解: A】の理由
Azure Firewall Manager は複数の Azure Firewall インスタンスや Secured Virtual Hub のルールを Firewall Policy として一元管理する Microsoft マネージド サービスです。これにより、複数 region やマルチ Hub 環境でのセキュリティ ポリシー統一が運用効率的に実現できます。
【他選択肢が違う理由】
- B: ARM はリソース管理基盤で、Firewall 専用ではありません。
- C: Azure Policy は構成監査用で、Firewall ルール集中管理ではありません。
- D: Azure Monitor は監視機能です。
【参考】
AZ700-SEC#10
Azure DDoS Protection の SKU 機能差について、各機能に対応するものを選んでください。
| ステートメント | 選択 |
|---|---|
自動有効化 + 全 Azure リソースで動作 + 大規模 Volumetric 攻撃の自動緩和 DDoS Basic はすべての Azure リソースで自動的に有効化される無料プランで、Microsoft グローバル ネットワーク レベルで大規模 Volumetric 攻撃を自動緩和します。そのため、追加コストなしで基本的な DDoS 防御が提供されます。 | |
VNet 単位の機械学習ベース アダプティブ チューニング + Mitigation Report + DRR サポート Network Protection は VNet 単位でベースライン学習を行うアダプティブ機能、Mitigation Report 出力、DDoS Rapid Response (DRR) チーム支援を提供する有料プランです。これにより、本番ワークロードに対する高度な DDoS 防御と攻撃対応が実現します。 | |
Public IP 単位の保護 (個別 IP のみコスト最適化) IP Protection は Public IP 単位で保護を有効化する細粒度プランで、Network Protection より低コストで個別 IP の防御が可能となります。そのため、特定 Public IP のみ保護したい小規模ワークロードに適合します。 |
解説
【正解マッチング】
| 判定対象 | 正解 |
|---|---|
| 自動有効化 + 全 Azure リソースで動作 + 大規模 Volumetric 攻撃の自動緩和 | Basic (無料) |
| VNet 単位の機械学習ベース アダプティブ チューニング + Mitigation Report + DRR サポート | Network Protection (有料) |
| Public IP 単位の保護 | IP Protection (有料) |
【各判定の詳細】
- 「自動有効化 + 全 Azure リソースで動作 + 大規模 Volumetric 攻撃の自動緩和」→ Basic (無料): DDoS Basic はすべての Azure リソースで自動的に有効化される無料プランで、Microsoft グローバル ネットワーク レベルで大規模 Volumetric 攻撃を自動緩和します。そのため、追加コストなしで基本的な DDoS 防御が提供されます。
- 「VNet 単位の機械学習ベース アダプティブ チューニング + Mitigation Repor…」→ Network Protection (有料): Network Protection は VNet 単位でベースライン学習を行うアダプティブ機能、Mitigation Report 出力、DDoS Rapid Response (DRR) チーム支援を提供する有料プランです。これにより、本番ワークロードに対する高度な DDoS 防御と攻撃対応が実現します。
- 「Public IP 単位の保護」→ IP Protection (有料): IP Protection は Public IP 単位で保護を有効化する細粒度プランで、Network Protection より低コストで個別 IP の防御が可能となります。そのため、特定 Public IP のみ保護したい小規模ワークロードに適合します。
【参考】
AZ700-SEC#11
Application Gateway WAF v2 を新規にデプロイして OWASP CRS による Web 攻撃防御を有効化する手順を、正しい順序に並べてください。
- Application Gateway WAF v2 SKU をデプロイ
- WAF Policy を作成 (OWASP CRS バージョン選択)
- WAF Policy を Application Gateway / Listener に関連付け
- Detection モードで動作確認 → 安定後 Prevention モードへ切替
解説
【正しい順序】
- ステップ 1: Application Gateway デプロイ
- ステップ 2: WAF Policy 作成
- ステップ 3: WAF Policy 関連付け
- ステップ 4: 検知 → 防御の段階切替
【各ステップの理由】
- ステップ 1 Application Gateway デプロイ: WAF v2 SKU を選んでデプロイし、リスナーとバックエンドの基本構成を完成させます。
- ステップ 2 WAF Policy 作成: OWASP CRS (3.2 / 3.1 / 3.0) バージョンを選び、Managed Rules + Custom Rules を含む WAF Policy を構成します。
- ステップ 3 WAF Policy 関連付け: 作成した WAF Policy を Application Gateway 全体または特定 Listener に関連付けます。
- ステップ 4 検知 → 防御の段階切替: Detection (検知のみ) モードで動作確認し、誤検知パターンを Exclusion Rule で除外した後に Prevention (実遮断) モードへ切り替えます。
【誤った順序の問題点】
- Prevention モードでいきなり本番運用: 誤検知で正常トラフィックが遮断される本番影響が大きくなります。
- WAF Policy なしで WAF SKU 運用: Managed Rules が動作せず、WAF SKU を選んだ意味がなくなります。
【参考】
AZ700-SEC#12
NSG / ASG の動作について、各記述が正しいか判定してください。
| ステートメント | はい | いいえ |
|---|---|---|
NSG ルールは Priority の値が低い番号 (例: 100) から評価され、最初にマッチしたルールで決定される NSG ルールは Priority 100〜4096 の範囲で低い番号から順に評価され、最初にマッチしたルールでアクセス可否が決定される First-match 動作です。そのため、ルールの並び順 (Priority 順) を正しく設計することがトラフィック制御の鍵となります。 | ||
1 つの NIC は最大 1 つの ASG にのみ所属できる 1 つの NIC は複数の ASG に所属できる仕様で、「Web 層 + 監視対象」のような役割の組み合わせを表現可能です。これにより、NSG ルールで Source / Destination に ASG を指定する設計の柔軟性が大きく高まります。 | ||
AVNM の Security Admin Rules は NSG より優先され、Always Deny で NSG の許可を上書きできる AVNM の Security Admin Rules はテナント / Subscription レベルで強制適用され、NSG より高い優先度で評価されます。そのため、Always Deny で構成したルールは Subscription 内のすべての NSG の許可を上書きできます。 |
解説
【正解一覧】
| ステートメント | 正解 |
|---|---|
| NSG ルールは Priority の値が低い番号 | はい |
| 1 つの NIC は最大 1 つの ASG にのみ所属できる | いいえ |
| AVNM の Security Admin Rules は NSG より優先され、Always Deny で NSG… | はい |
【各判定の詳細】
- 「NSG ルールは Priority の値が低い番号」→ はい: NSG ルールは Priority 100〜4096 の範囲で低い番号から順に評価され、最初にマッチしたルールでアクセス可否が決定される First-match 動作です。そのため、ルールの並び順 (Priority 順) を正しく設計することがトラフィック制御の鍵となります。
- 「1 つの NIC は最大 1 つの ASG にのみ所属できる」→ いいえ: 1 つの NIC は複数の ASG に所属できる仕様で、「Web 層 + 監視対象」のような役割の組み合わせを表現可能です。これにより、NSG ルールで Source / Destination に ASG を指定する設計の柔軟性が大きく高まります。
- 「AVNM の Security Admin Rules は NSG より優先され、Always …」→ はい: AVNM の Security Admin Rules はテナント / Subscription レベルで強制適用され、NSG より高い優先度で評価されます。そのため、Always Deny で構成したルールは Subscription 内のすべての NSG の許可を上書きできます。
【参考】
AZ700-SEC#13
Azure Firewall で特定の FQDN (例: *.microsoft.com) への HTTPS Outbound のみを許可する場合、利用するルール種別はどれですか?
解説
【正解: A】の理由
Azure Firewall の Application Rule は FQDN ベースのルールで、特定の HTTPS Outbound (例: *.microsoft.com、*.windowsupdate.com) を許可する用途に利用します。Standard SKU でも利用可能で、Application Rule は L7 ヘッダー (Host / SNI) を見て FQDN マッチングを行います。
【他選択肢が違う理由】
- B: Network Rule は L3-L4 (IP / ポート / プロトコル) ベースで、FQDN マッチングは Application Rule の役割です。
- C: NAT Rule は Inbound 用 DNAT で、Outbound FQDN 許可とは異なる用途です。
- D: DDoS Rule は Azure Firewall の標準ルール種別ではありません。
【参考】
AZ700-SEC#14
各 Azure Firewall ルール種別を、対応するユース ケースにマッチさせてください。
項目（ドラッグしてください）
- L3-L4 で TCP / UDP の Outbound を IP / ポート ベース許可
- HTTPS Outbound を *.example.com 等の FQDN ベース許可
- Public IP:443 → Backend Web Server 192.168.1.10:443 の DNAT
- TLS 復号後の URL パスベース検査 (Premium 限定)
Network Rule
Application Rule
NAT Rule (DNAT)
解説
【正しいマッチング完全版】
※ Network Rule は L3-L4、Application Rule は FQDN / URL ベース (Premium TLS Inspection 含む)、NAT Rule は DNAT (Inbound) の対応関係を覚えると Firewall 設計が明確になります。
- L3-L4 で TCP / UDP の Outbound を IP / ポート ベース許可 → Network Rule
- HTTPS Outbound を *.example.com 等の FQDN ベース許可 → Application Rule
- Public IP:443 → Backend Web Server 192.168.1.10:443 の DNAT → NAT Rule (DNAT)
- TLS 復号後の URL パスベース検査 (Premium 限定) → Application Rule
【正解マッチング】
| 機能 | 対応 |
|---|---|
| L3-L4 で TCP / UDP の Outbound を IP / ポー… | Network Rule |
| HTTPS Outbound を *.example.com 等の FQDN… | Application Rule |
| Public IP:443 → Backend Web Server 192… | NAT Rule (DNAT) |
| TLS 復号後の URL パスベース検査 | Application Rule |
【参考】
AZ700-SEC#15
NSG / Azure Firewall ルールで Azure サービスのパブリック IP 範囲を簡潔に指定したい場合、利用される機能はどれですか?
解説
【正解: A】の理由
Service Tag は Microsoft が管理する Azure サービスの Public IP 範囲を抽象化した名前で、Storage.JapanEast や AzureCloud などのタグを NSG / Azure Firewall ルールで指定できます。Microsoft が IP 範囲を自動更新するため、Azure サービスの IP 変更にユーザが追随する必要がありません。
【他選択肢が違う理由】
- B: 手動 IP プレフィックスは管理負担が高く、Service Tag が自動更新で代替します。
- C: DNS Forwarder は名前解決の機能で、ルール記述用ではありません。
- D: UDR は経路制御で、ルール記述用ではありません。
【参考】
AZ700-SEC#16
WAF Policy を本番運用に移す際の「Detection → Prevention」段階適用の手順を、正しい順序に並べてください。
- Detection モードで WAF Policy を有効化 + ログ収集
- 検知ログを分析 + 誤検知パターンを特定
- Exclusion Rule で誤検知を除外
- Prevention モードに切替 + 継続監視
解説
【正しい順序】
- ステップ 1: Detection モード有効化
- ステップ 2: 検知ログ分析
- ステップ 3: Exclusion Rule 適用
- ステップ 4: Prevention モード切替
【各ステップの理由】
- ステップ 1 Detection モード有効化: 検知のみで遮断は行わない安全モードで WAF Policy を有効化し、Log Analytics に検知ログを送信します。
- ステップ 2 検知ログ分析: 一定期間 (通常 1〜2 週間) の検知ログを分析し、正常リクエストが誤検知されているパターンを特定します。
- ステップ 3 Exclusion Rule 適用: 誤検知された Request Header / Cookie / Body Parameter を Exclusion Rule で WAF 検査から除外します。
- ステップ 4 Prevention モード切替: 誤検知が解消された後に Prevention モードへ切り替え、Block 動作で本番運用を開始します。継続的に監視してチューニングを続けます。
【誤った順序の問題点】
- Prevention モードでいきなり開始: 誤検知で正常リクエストが大量に遮断される本番影響が出る可能性が高くなります。
- Exclusion なしで Prevention 切替: 正常リクエストが Block されるため、業務が継続できなくなります。
【参考】
AZ700-SEC#17
NSG が許可または拒否したフロー (5-tuple ベース) を記録して、Traffic Analytics で異常分析する機能はどれですか?
解説
【正解: A】の理由
NSG Flow Logs は Network Watcher の機能で、NSG が許可 / 拒否したすべてのフローを 5-tuple (Source IP / Destination IP / Source Port / Destination Port / Protocol) ベースで記録します。Traffic Analytics と組み合わせると Threat Intelligence ベースの異常検知やトラフィック傾向分析が可能となります。
【他選択肢が違う理由】
- B: Activity Logs はリソース操作ログで、トラフィック フロー記録は別です。
- C: Application Insights はアプリケーション監視用です。
- D: Boot Diagnostics は VM 起動ログで、ネットワーク フロー記録はしません。
【参考】
AZ700-SEC#18
各 Service Tag の用途について、各記述が正しいか判定してください。
| ステートメント | 選択 |
|---|---|
Service Tag「AzureCloud」は全 Azure Public IP 範囲を意味し、特定 region 限定にはサブタグ (例: AzureCloud.JapanEast) を使う AzureCloud は全 Azure Public IP 範囲の総称タグで、region 限定したい場合は AzureCloud.JapanEast、AzureCloud.EastUS のようなサブタグを使います。これにより、地理的範囲を絞った Outbound 許可ルールを構成できます。 | |
Service Tag「VirtualNetwork」は同一 VNet 内の Private IP 範囲とピアリングされた VNet を含む VirtualNetwork タグは同一 VNet の IP 範囲、ピアリング先の VNet 範囲、オンプレ接続 (VPN / ER) で広告された範囲を含む統合タグです。そのため、内部通信ルールを簡潔に記述できます。 | |
Service Tag は ユーザが任意の名前で作成できる Service Tag は Microsoft が管理する事前定義タグで、ユーザは新規 Service Tag を作成できません。カスタム範囲を扱いたい場合は ASG (Application Security Group) を活用します。 |
解説
【正解マッチング】
| 判定対象 | 正解 |
|---|---|
| Service Tag「AzureCloud」は全 Azure Public IP 範囲を意味し、特定 region… | はい |
| Service Tag「VirtualNetwork」は同一 VNet 内の Private IP 範囲とピアリング… | はい |
| Service Tag は ユーザが任意の名前で作成できる | いいえ |
【各判定の詳細】
- 「Service Tag「AzureCloud」は全 Azure Public IP 範囲を意味し…」→ はい: AzureCloud は全 Azure Public IP 範囲の総称タグで、region 限定したい場合は AzureCloud.JapanEast、AzureCloud.EastUS のようなサブタグを使います。これにより、地理的範囲を絞った Outbound 許可ルールを構成できます。
- 「Service Tag「VirtualNetwork」は同一 VNet 内の Private I…」→ はい: VirtualNetwork タグは同一 VNet の IP 範囲、ピアリング先の VNet 範囲、オンプレ接続 (VPN / ER) で広告された範囲を含む統合タグです。そのため、内部通信ルールを簡潔に記述できます。
- 「Service Tag は ユーザが任意の名前で作成できる」→ いいえ: Service Tag は Microsoft が管理する事前定義タグで、ユーザは新規 Service Tag を作成できません。カスタム範囲を扱いたい場合は ASG (Application Security Group) を活用します。