Skip to content

MS_AzureWAFSecurity

Jump to bottom
nishi_74322014 edited this page Sep 1, 2026 · 1 revision

Azure Well-Architected Framework - Security

概要

俯瞰すると、以下のようにサマリ出来るらしい。
＋基礎

インフラ構築と運用

マイクロ・セグメンテーション

中央統制と権限移譲

オンプレ → クラウド（Azure では

ID 管理と認証・認可

オンプレ → クラウド（Azure では

システム構築とアプリ開発

開発プロセスへの折込

ツール、レビューなど。

設計とテスト

自動化

IaC (Infrastructure as Code) ＋ DevOps

セキュリティ運用

ISMS（DNET_SecurityManagement.md）、ITIL（DNET_ServiceManagement.md）の

検知

オンプレ → クラウド（Azure では

対応・復旧

オンプレ → クラウド（Azure では

改善

オンプレ → クラウド（Azure では

詳細

原則

責任共有モデル

https://learn.microsoft.com/ja-jp/azure/well-architected/security/

  • 物理 Data Center
    "信ぜよ、されど確認せよ"

  • ソフトウェア

設計原則

https://learn.microsoft.com/ja-jp/azure/well-architected/security/principles

  • 要件

    • セキュリティの優先順位をミッションに整合させる
    • 包括的な戦略を構築する

  • 設計

    • シンプルさを促進する
    • 攻撃者を念頭に置いて設計する
    • ネイティブの制御を活用する
    • ID を主要なアクセス制御として使用する
    • アカウンタビリティ（真正性、責任追跡性、否認防止、信頼性）
    • 自動化を採用する
    • 情報の保護に注力する
    • 回復力を考慮して設計する
    • ゼロトラストを前提とする

  • 運用

    • ベースラインとベンチマーク
    • 継続的な改善を推進する
    • セキュリティ教育を奨励する

補足（最新化 / W-AF の柱の再編）: Azure Well-Architected Framework は
その後改訂され、セキュリティの柱は
**CIA トライアド（機密性・完全性・可用性）**を軸に整理し直されている。
チェックリストの項目名は変わったが、
上記の設計原則（ID を主軸に、ネイティブ制御を使い、ゼロトラストを前提に）
という骨子は変わっていない。

基本

https://learn.microsoft.com/ja-jp/azure/well-architected/security/

経験とデータを活用

脅威モデリングを活用

補足（STRIDE）: 脅威モデリングの代表的な分類法。
対策の抜けを機械的に洗い出すために使う。

略 脅威 対応する性質
S poofing なりすまし 認証
T ampering 改ざん 完全性
R epudiation 否認 否認防止（監査ログ）
I nformation Disclosure 情報漏洩 機密性
D enial of Service サービス妨害 可用性
E levation of Privilege 権限昇格 認可

データフロー図を描き、境界を越える箇所ごとに
この 6 つを当てはめていくのが基本手順。

規制当局のセキュリティ標準

https://learn.microsoft.com/ja-jp/azure/well-architected/security/

  • 規制当局のセキュリティ標準に準拠
  • クラウドを想定しないケースがある。

リスク低減するセキュリティ戦略

https://learn.microsoft.com/ja-jp/azure/well-architected/security/

  • 攻撃のためのハードルを上げる

  • 攻撃が成功した際の軽減・回復方法

    • 多層防衛
    • 早期の検知と対応

  • 攻撃をうまくコントロール

    • 最小特権付与
    • 短い有効期間
    • 検知＆無効化
    • アクセス先毎の権限の細分化

役割と分担

ガバナンス・リスク・コンプライアンス（GRC）

ガバナンス

https://learn.microsoft.com/ja-jp/azure/cloud-adoption-framework/govern/

  • 検討事項

    • セキュリティ機能別の役割

      • ネットワーク・セキュリティ
      • ネットワーク管理
      • サーバ VM のセキュリティ
      • インシデント監視・対応
      • ポリシー管理
      • ID 管理

    • 企業部門毎のマイクロ・セグメンテーション

  • 中央（統括部門）側の作業

    • VM のセキュリティ確保

    • インシデント通知の受け取り

    • よく知られたリスクの検知・修復

    • 侵入テスト、古いプロトコルの検出

    • 定期的なアクセス監査

    • 不正な ID 利用の監視

    • その他

      • 環境の作成と管理の自動化
      • 各種ベンチマークによる体制評価
      • ポリシー準拠の監査と適用

    • 関連する機能

  • 権限分掌設計

    • コア・サービス
      Hub VNET, ADDS, DNS/DHCP の作成と管理
      中央（統括部門）側でも権限を持ち、管理

      • セキュリティチーム
      • ポリシー管理チーム
      • ネットワーク管理チーム
      • 緊急事態用アカウント
      • 中央 IT 運用チーム

    • 部門サービス
      Spoke VNET, 業務システムの作成と管理
      中央（統括部門）側でも適切に権限を持ち、管理

      • セキュリティチーム
      • ポリシー管理チーム
      • ネットワーク管理チーム
      • 緊急事態用アカウント
      • IT 運用チーム
      • アプリケーション管理者

※ 緊急事態用アカウント : Break Glass Account
　 条件付きアクセスは外しておく。

補足（コア／部門の分割が権限設計の骨格）: この
「コア・サービスは中央、部門サービスは各部門。ただし中央も権限を持つ」
という設計は、Azure Virtual Data Center の
Hub & Spoke 構成にそのまま対応する。

Hub  （コア・サービス）  … 中央が排他的に管理
  ↕ ピアリング
Spoke（部門サービス）    … 部門が管理。中央は監査・ポリシー適用の権限

現在は管理グループ（サブスクリプションの上位階層）に
Azure Policy と RBAC を割り当てることで、
「部門に自由を与えつつ、外してはいけない枠は中央が固定する」
という形が標準的に実装できる。

リスク

保護対象に対する攻撃が成功する確率と影響

コンプライアンス

  • 標準、組織、管理、法規制
  • 例：ISO27001、NIST、PCI DSS

設計と実装

ID 管理とアクセス管理

Azure AD

  • 単一ディレクトリ利用
    （運用管理作業用アカウントの話）

  • ID 同期の設計
    （強権限 ID は同期しない）

  • 外部ディレクトリの利用
    （B2B/B2C の利用）

  • 認証

    • パスワード保護対策機能の利用

    • レガシー認証のブロック、
      パスワードレス認証、2FA/MFA

    • SSO の実施（SAML、OIDC）

  • 条件付きアクセス

  • 攻撃シミュレーションの実施

補足（「強権限 ID は同期しない」の意味）: オンプレミス AD と
Azure AD を同期する場合、
オンプレ側が侵害されるとクラウド側も巻き添えになる。
したがって、クラウドの全体管理者・特権ロールに就くアカウントは
**クラウド専用（クラウドオンリー ID）**として作り、同期対象から外す。
これは Azure Subscriptionの管理@エンプラ の
「VDC 専用ディレクトリ」の議論と同じ動機である。

境界型ネットワークから脱却

ネットワーク・セキュリティ

  • NIDS / NIPS / NDLP（DNET_SecurityCountermeasureDefense.md）の利用

  • ネットワーク通信の可視化
    Azure Sentinel（SIEM）によるログ統合

    • NSG ログ
    • WAF のログ
    • 仮想ネットワークタップ
    • Azure Network Watcher

  • IP アドレス設計

  • AzureのDDoS対策

  • 強制トンネリング（オンプレ迂回）を避ける

    • 通信量の増大
    • レイテンシの悪化
    • コストの増加

補足（最新化）: 仮想ネットワーク TAP は提供されなかった
（プレビューのまま廃止）。
現在、同等の目的には Azure Virtual Network Flow Logs
（NSG フローログの後継）＋ Traffic Analytics、
あるいはパケット単位が必要なら
Network Watcher のパケット キャプチャを用いる。

ストレージ・データ・暗号化

  • ストレージアクセスに利用する認証方式の選択

  • プラットフォーム暗号化サービスを無効化しない

  • 仮想マシンの VHD ファイルを保護

    • VHD ファイルに適切な認証・認可を設定
    • ADE（Azure Disk Encryption）でディスク暗号化

補足: 「ストレージアクセスに利用する認証方式の選択」は具体的には、
共有キー（アカウント キー）を無効化し、
Azure AD の ID ベース認証（RBAC）に寄せる
ことを指す。キーは失効の単位が粗く、漏洩時の被害が全体に及ぶため。
SAS トークンを使う場合も、
ユーザー委任 SAS（Azure AD ベース）を選ぶのが現在の推奨。

アプリケーションとサービス

  • 守りかたの基礎
    他に比べて圧倒的に重要（≒ いくらインフラで守ってもアプリで漏れる。）

    • スコープの際を意識する。

      • IaaS
      • PaaS/CaaS
      • SaaS

    • リスクの高い部分を意識して対策する。

    • DevOps アプローチを採用する。
      Secure DevOps Kit for Azure

  • ２つのアプローチ

    • ボトムアップ : ソフトウェア開発ライフサイクル（SDLC）
    • トップダウン : 脅威モデリング

  • 設計・実装上のポイント

    • 基本的なセキュリティ機能を自力実装しない、
      各サービスが持つセキュリティ機能を活用する。
    • 鍵を使わずなるべく ID 認証（Managed ID）を利用する。
    • WAF を利用する（ただしそれだけに依存しない）

  • コンテナのベストプラクティス

    • CaaS は Managed 型のサービスを使う。
    • コンテナ・イメージの身元を確認する。
    • コンテナを管理者権限で実行しない。
    • コンテナを監視する。

補足（「いくらインフラで守ってもアプリで漏れる」）: これは
FgCF の Weakest Link や、
Azure Virtual Data Center の
「閉域化に投資してもアプリ脆弱性を突かれれば同じ」という指摘と同一の主張である。
本ページ全体を通して一貫して繰り返されている論点であり、
投資配分を決める際の判断基準として読むべきところ。

運用管理作業（Administration）

作業特権アクセスの厳格な管理

補足（「最小特権付与も程々に」という現実解）: 最小特権を突き詰めると
カスタム ロールが乱立し、

  • 誰も全体像を把握できなくなる、
  • API の追加でロールが壊れる（必要な操作が増える）、

という別のリスクが生まれる。
この「原則と運用性のバランスを取れ」という指摘は実務的に重要で、
Azure Policy 側で
「やってはいけないこと」を禁止する方が管理しやすい場合が多い。

なお MDATP は Microsoft Defender for Endpoint、
Azure Sentinel は Microsoft Sentinel に改称されている。

セキュリティ運用（SO）

補足（「適切に選別する」＝費用の話でもある）: SIEM の課金は
取り込みデータ量に比例するため、これは技術要件であると同時に費用要件である。
Log Analytics の
分析ログ / 基本ログ / アーカイブの層分けと併せて設計すること。

Fit & Gap

  1. エンプラでの慣例
  2. W-AF でのスタンス
  3. エンプラ・W-AF 間の折衷案

NW 閉域性確保

  1. 入出力の閉域化。
  2. 入力のみの閉域化。
  3. 折衷案

NW 透明性確保

  1. 到達経路の明確化（接続元をホワイトリスト的に絞る）が慣例。
  2. W-AF には記載が無い（CDN は管理されている、...が透明性が無い）。
  3. オンプレと同じ製品の仮想アプライアンス版を採用する。

権限分掌

  1. 中央統制（野良クラウド発生の原因になる）が慣例。
  2. W-AF では柔軟な権限移譲を許可するスタンス
  3. ２つの方法

管理者アカウントの PWD ローテ

  1. 共有アカウント（root, administrator）
  2. 個人アカウント（個人特定のため）
  3. ２つの方法
    • 共有アカウントはオンプレ延伸環境（IaaS）で利用
    • 個人アカウントはクラウド環境（PaaS、SaaS）で利用

アプリの脆弱性

  1. 軽視されている
  2. 重視されている（ただし、実践は困難）
  3. 人材育成とコンサル利用

管理端末の脆弱性

  1. OA 環境との分離を想定していないケースが多い。
  2. 厳格なハードニング（堅牢化）が推奨されている。
  3. OA 環境からの分離とハードニング（堅牢化）の推進

移行メモ（誤字）: 原文の「バードニング」は
**ハードニング（hardening、堅牢化）**の誤記と判断し修正した。

補足（この Fit & Gap こそが FgCF の核心）: 一般的な W-AF の解説は
「あるべき姿」を述べるだけで終わるが、この節は
日本のエンタープライズの慣例と、W-AF の推奨がどこでぶつかるかを
正面から並べている点に価値がある。
特に「NW 閉域性」「権限分掌」の 2 つは、
実際のプロジェクトで必ず論点になる箇所である。

参考

Microsoft Learn

nakama

FgCF > ゼロトラスト型マルチクラウド IT 環境 > Azure Well-Architected Framework : Security セクション概要解説

※ 体系・pwd は FgCF (Financial-grade Cloud Fundamentals) を参照。

Tags: 移行, インフラストラクチャ, クラウド, セキュリティ, 通信技術, Azure

このWikiは「Open棟梁Project」,「OSSコンソーシアム 開発基盤部会」によって運営されています。

NetDevInfraWiki

マイクロソフト系技術情報 Wiki
Open 棟梁 Wiki

（未着手）

開発基盤部会 Wiki

移行管理: DONE ／ TODO

Clone this wiki locally