オンプレシステムのAzure移行時の留意点（随時更新中）

1. Azure Virtual Network 設計

1-1. アドレス空間／サブネット設計

1. Parameter: VNet アドレス空間（CIDR: 10.0.0.0/16 等）、サブネットごとの CIDR、名前（WebSubnet, AppSubnet, DBSubnet）

2. 推奨値 / 例:

   • “vnet-prod-east” → 10.0.0.0/16

     • “subnet-web” → 10.0.0.0/24

     • “subnet-app” → 10.0.1.0/24

     • “subnet-db” → 10.0.2.0/24

   • 専用 “AzureFirewallSubnet” も別途 10.0.255.0/26 のように確保

3. 補足: IP アドレスがオンプレ環境と重複しないかを確認し、将来的な拡張（追加サブネット等）も考慮して余裕を持った CIDR を割り当て。NIST CSF “Protect - Communications (PR.PT)” の観点から段階的にサブネットを分割し、機能ごとにセキュリティ境界を明確にする。

1-2. VNet Peering / Hub-Spoke

1. Parameter: Hub-Spoke トポロジ、VNet Peering の名前 / AllowForwardedTraffic 設定

2. 推奨値 / 例:

   • “HubVNet” (共通ネットワークサービス) + “SpokeVNet-Web”, “SpokeVNet-App” のように分割

   • Peering: “Allow Gateway Transit = True” で Hub 経由の ExpressRoute / VPN 接続を活用

3. 補足: オンプレとの接続や複数サブスクリプション管理を意識しつつ、NIST SP 800-53 SC-7（Boundary Protection）要件に沿ってネットワーク境界を構築

2. NSG (Network Security Group)

2-1. NSG ルール設計

1. Parameter: インバウンド／アウトバウンドルール、送信元・宛先IP／ポート、プロトコル (TCP/UDP)

2. 推奨値 / 例:

   • “Inbound: Allow HTTP (TCP/80) only from Internet to WebSubnet”

   • “Inbound: Allow DB access (TCP/1433) only from AppSubnet to DBSubnet”

   • デフォルト：Deny all others

3. 補足: NIST CSF “Protect - Access Control” の観点から、最小権限となるよう NSG ルールを厳格化。Flow Logs (NSG) を有効にし、Log Analytics へ送信して不審トラフィックを監視

2-2. Service Tag / ASG（Application Security Group）

1. Parameter: Service Tag（Internet, AzureLoadBalancer, etc.）、ASG（WebASG, AppASG）

2. 推奨値 / 例:

   • Service Tag “Internet” を使い、外部との通信をまとめて管理

   • “AppASG” → WebSubnet からの通信のみ許可 など ASG でまとめる

3. 補足: ルール数が多くなる場合、ASG や Service Tag で抽象化し可読性を高める。NIST SP 800-53 AC-4（Information Flow Enforcement） の実装例として推奨

3. Azure Firewall / WAF (Application Gateway)

3-1. Azure Firewall

1. Parameter: Firewall SKU (Standard / Premium)、Public IP、Firewall Subnet (AzureFirewallSubnet)

2. 推奨値 / 例:

   • Premium SKU: TLS Inspection, IDPS 機能を有効

   • Subnet: “AzureFirewallSubnet” (例: 10.0.255.0/26)

   • 送信（Outbound）規則、受信（Inbound）規則、DNAT ルールを定義

3. 補足: NIST SP 800-53 SC-7（Boundary Protection） に該当し、Layer3-4 + IDPS（Premium）機能で East-West / Outbound / Inbound トラフィックを一元制御。Hub-Spoke 構成の場合は Hub VNet に配置し Spoke VNet と Peering

3-2. Application Gateway (WAF)

1. Parameter: WAF v2 SKU、Frontend IP (Public / Private)、Listener 設定、OWASP CRS バージョン

2. 推奨値 / 例:

   • “Public IP”: 1 つ割り当て → HTTP(S) Listener

   • WAF ポリシー: Prevention モード / OWASP CRS 3.2 以上

   • Autoscaling 有効化 (min=2, max=10)

3. 補足: L7 レベルでの攻撃防御 (OWASP Top10) や SSL Offloading が可能。NIST CSF “Protect - Communications Security” で Web アプリを保護する際に推奨

4. ExpressRoute / VPN (ハイブリッド接続)

4-1. Site-to-Site VPN

1. Parameter: VPN Gateway SKU (VpnGw1-5), GatewaySubnet, IKEv2/IPsec 設定

2. 推奨値 / 例:

   • SKU: VpnGw2 or VpnGw3 if 中～高帯域が必要

   • IPsec Policy: AES256/SHA256/DHGroup14 or 24

   • Active-Active 接続で冗長化

3. 補足: オンプレとの帯域や遅延要件がさほど高くなければ VPN でコスト削減。NIST SP 800-53 SC-8 (Transmission Confidentiality) を満たすため TLS/IPsec 等の暗号化を確認

4-2. ExpressRoute

1. Parameter: 回線帯域 (50Mbps～10Gbps), Peering Type (Private/Microsoft Peering), 冗長接続

2. 推奨値 / 例:

   • 金融業や大規模企業で低レイテンシ / SLA が必要 → ExpressRoute 1Gbps + 冗長化

   • Microsoft Peering で Office 365 / Dynamics 365 のトラフィックも専用線経路に

3. 補足: NIST CSF “Protect - Communications (PR.PT)” で高可用・高セキュリティ回線が求められる場合 ExpressRoute が有効。帯域とコストのバランスを検討

5. 追加のセキュリティ要件・ログ管理

5-1. Azure Monitor / Sentinel 連携

1. Parameter: Diagnostic Settings (VNet Flow Logs, Firewall Logs, WAF Logs), SIEM (Sentinel)

2. 推奨値 / 例:

   • Network Watcher で NSG Flow Logs (Version2) を有効化し、Log Analytics Workspace に送信

   • Azure Firewall / Application Gateway WAF のログも含め Sentinel で相関分析

3. 補足: NIST SP 800-53 AU（Audit） でネットワーク上の不審アクセスや攻撃を追跡するため、流量・脅威ログを一元管理

5-2. 証跡保全と改ざん防止

1. Parameter: Storage Account (Immutable Blob), Retention Policy

2. 推奨値 / 例:

   • ログを最低 90日～1年保管 → 監査法人要請やインシデント対応のため

   • 重要インシデントログは Immutable Storage で削除・改ざん不可モードを有効化

3. 補足: NIST CSF “Detect” (DE) と “Respond” (RS) でのインシデント調査に備え、ログが変更されないようにする。AU-9（Protection of Audit Information）に対応

6. まとめ

クラウド移行時のネットワーク & セキュリティ設計は、Azure Virtual Network や NSG、Azure Firewall / WAF の組み合わせを最適に構成し、オンプレとの接続（VPN / ExpressRoute）を安全かつ可用性を担保する形で設計することがポイントです。

• VNet 設計: CIDR / サブネット分割、Hub-Spoke トポロジ、Peering

• NSG: ポート / IP / プロトコル単位で最小権限ルールを適用

• Azure Firewall / WAF: L3-L4 の統合管理（Firewall）および L7 レイヤーの攻撃防御（WAF）

• ExpressRoute / VPN: 帯域要件・冗長化を考慮し、企業規模やネットワーク負荷に最適化

• ログ監査: Network Watcher / Azure Monitor / Sentinel でフローやイベントを集約し、NIST 800-53 SC / AU ファミリに沿った形で監視体制を整える

このように、NIST CSF の “Protect” (PR.PT)、NIST SP 800-53 の SC-7（Boundary Protection）や CM ファミリ（Configuration Management）を意識しながら設計することで、クラウド移行後も堅牢なネットワーク構成とセキュリティを両立できます。

​

​

APPENDIX

以下では、Azure Virtual Network (VNet) 設計のうち、アドレス空間／サブネット構成 (1-1) をよりパラメーター（具体的設定・考慮項目）レベルに掘り下げて解説します。オンプレミスから Azure へ移行する際は、VNet の CIDR 設計やサブネット分割が今後の運用やセキュリティに大きく影響します。以下のポイントを意識しながら設計を進めると、NIST SP 800-53 SC-7（Boundary Protection） や NIST CSF “Protect - Communications (PR.PT)” に則った堅牢なネットワークを構築できます。

1-1. アドレス空間／サブネット設計

A. アドレス空間（CIDR ブロック）の決定

1. Parameter: “VNet CIDR” (例: 10.0.0.0/16)、オンプレと重複しないか、将来拡張余地

2. 推奨値 / 例:

   • 10.0.0.0/16 をひとつの VNet に割り当て、最大 65534 ホスト (実効)

   • 既にオンプレが 10.0.0.0/16 を使用中なら、10.100.0.0/16 など重複しないブロックを選定

3. 補足:

   • Azure VNet は後から CIDR ブロック追加が可能だが、オンプレとの重複が生じると VPN/ExpressRoute の設定が厄介に。最初に十分な範囲を確保する

   • NIST CSF “Identify - Asset Management (ID.AM)” で IP 範囲の管理を明確にし、将来的なサブネット追加にも余裕を持たせる

B. サブネット分割

1. Parameter: サブネットごとに CIDR / 用途 / 名前命名規則 (WebSubnet, AppSubnet, DBSubnet, MgmtSubnet など)

2. 推奨値 / 例:

   • 例:

     • Subnet-Web → 10.0.0.0/24 (ウェブサーバー, App Gateway, 80/443 通信)

     • Subnet-App → 10.0.1.0/24 (アプリケーション層, REST API 等)

     • Subnet-DB → 10.0.2.0/24 (データベース, TCP/1433 や 3306 等)

     • Subnet-Mgmt → 10.0.10.0/24 (Bastion / Jumpbox, Backup Agents 等)

3. 補足:

   • サブネット分割により NSG (Network Security Group) や Azure Firewall で役割ごとの通信制限を適用しやすい

   • NIST SP 800-53 SC-7（Boundary Protection） によるネットワーク境界の分離（機能別や機密度別のサブネット化）

C. 特殊サブネット（Azure FirewallSubnet、GatewaySubnet 等）

1. Parameter:

   • Azure Firewall Subnet: “AzureFirewallSubnet”, CIDR 例: 10.0.255.0/26

   • VPN Gateway Subnet: “GatewaySubnet”, CIDR 例: 10.0.254.0/27

2. 推奨値 / 例:

   • Firewall が必要な場合、AzureFirewallSubnet 名は固定 / 必須 → Premium SKU 利用ならさらに TLS Inspection 用に十分なサイズを確保

   • ゲートウェイを設置するなら “GatewaySubnet” も名前固定, /27 以上の CIDR

3. 補足: Azure が提供するゲートウェイリソースやファイアウォールリソースはサブネット名が予約済みのため、衝突を避けるよう計画的に CIDR を割り当てる

D. 命名規則・タグ

1. Parameter: vnet-<env>-<region> などの命名法、Tag: “owner=”, “env=dev/prod”

2. 推奨値 / 例:

   • vnet-prod-jpeast、subnet-web, subnet-db

   • Tag: “environment=production”, “costCenter=XXXX”

3. 補足: 運用やコスト管理を容易にするため、NIST CSF “Identify - Governance (ID.GV)” でも推奨されるようにリソース命名とタグを統一しておく

E. IP アドレス管理ツールとの連携

1. Parameter: IPAM (IP Address Management) ツール との対応, DHCP Range

2. 推奨値 / 例:

   • On-Prem の IPAM でクラウド用 CIDR を予約し、重複を防ぐ

   • Azure VNet 内は静的割り当ても可能だが、通常は Azure 側の DHCP 自動割り当て

3. 補足: 大規模企業では IPAM をオンプレとクラウドで連携し、NIST CSF “Identify - Asset Management (ID.AM)” の一部として IP アサインを重複なく可視化する

F. ネットワーク通信の制御・監視

1. Parameter: “NSG ルール”, “Flow Logs”, “Diagnostics Settings”

2. 推奨値 / 例:

   • サブネット（または NIC）に NSG を割り当て、必要ポートのみ Allow, 他は Deny

   • Network Watcher で Flow Logs v2 → Log Analytics / Sentinel に送信

3. 補足: NIST SP 800-53 CM ファミリ (Configuration Management) と SC-7（Boundary Protection）でネットワーク制御を明確化し、ログを監査可能な形で保管

G. 構成変更の運用 (IaC)

1. Parameter: Terraform, Bicep, ARM Template などの IaC (Infrastructure as Code)

2. 推奨値 / 例:

   • “vnet-prod” の設定をすべて Terraform で記述 → GitHub / Azure DevOps でバージョン管理

   • Pull Request → CI/CD → “terraform plan” → “terraform apply”

3. 補足: NIST CSF “Identify - Governance (ID.GV)” や CM-2 (Configuration Management) で推奨される。変更内容をコード化して監査ログに残すことで、トレーサビリティを確保

2. NIST SP 800-53 / NIST CSF との関連

1. SC-7 (Boundary Protection)

   • サブネット分割、NSG、Firewall で境界制御を実装。

   • VNet とオンプレ境界（VPN / ExpressRoute）やインターネットへの通信経路を可視化・制御

2. CM（Configuration Management） ファミリ

   • VNet の CIDR、Subnet、NSG、Firewall 設定を一元管理し、変更は承認制（IaC + Pull Request）

3. NIST CSF “Protect - Communications and Security (PR.PT)”

   • ネットワーク通信経路を安全に保ち、Flow Logs や Diagnostics で不正アクセスを監視

3. まとめ

Azure Virtual Network のアドレス空間やサブネット設計は、クラウド移行全体の基盤となるため、下記ポイントを詳細に詰める必要があります：

• CIDR ブロックを十分に確保し、オンプレ IP と重複しないようにする

• サブネット分割（Web/App/DB/Mgmt 等）で役割ごとのトラフィック制限を可能にし、NSG ルールを最小化

• 特定サブネット名（AzureFirewallSubnet、GatewaySubnet）は予約済みネーミングである点に留意

• VNet Peering や Hub-Spoke 構成を活用し、大規模環境の拡張性とセキュリティを両立

• IaC（Terraform/Bicep 等）でネットワーク構成変更をコード化し、変更管理と監査を実施

これらをしっかり実装することで、NIST 800-53 SC-7 や NIST CSF “Protect - Communications (PR.PT)” の要件に合致する、堅牢かつ拡張性のあるネットワーク基盤を Azure 上に構築できるようになります。

​

​

1. Hub-Spoke トポロジの概念

1-1. Parameter: Hub VNet / Spoke VNet の区分

1. Parameter: “HubVNet” (共通ネットワークサービス用) と “SpokeVNet-XXX” (各アプリ / 部署用)

2. 例:

   • HubVNet: 10.0.0.0/16

     • ここに Azure Firewall、VPN/ExpressRoute Gateway などを配置

   • SpokeVNet-Web: 10.1.0.0/16 (Web サービス)

   • SpokeVNet-App: 10.2.0.0/16 (アプリ層)

3. 解説:

   • Hub VNet には共通インフラ（Firewall, Gateway Subnet, Bastion Subnetなど）を集約し、Spoke VNet はアプリケーション単位やチーム単位で作成

   • NIST SP 800-53 SC-7 でいうネットワーク境界管理を、Hub-Spoke アーキテクチャで段階的にセキュリティ制御しやすくする

2. VNet Peering のパラメーター設定

2-1. Peering の名前 / AllowForwardedTraffic / AllowGatewayTransit

1. Parameter:

   • Peering 名前 (e.g., “Hub-to-SpokeWeb”, “SpokeWeb-to-Hub”),

   • AllowForwardedTraffic, AllowGatewayTransit, UseRemoteGateways (3フラグ)

2. 推奨例:

   • “Allow Gateway Transit = True” on HubVNet Peering (enables Spoke VNet to use Hub’s VPN/ExpressRoute)

   • “Use Remote Gateway = True” on SpokeVNet (Spoke が Hub のゲートウェイを利用する)

   • “Allow Forwarded Traffic = True” → Hub Firewall でパケットフォワーディングを実現

3. 解説:

   • Allow Gateway Transit = True: Hub VNet に配置した ExpressRoute Gateway / VPN Gateway を Spoke から経由できるようにする

   • Use Remote Gateway: Spoke VNet 側で “Yes” に設定し、Hub のゲートウェイ経由でオンプレと通信する

   • Forwarded Traffic: Azure Firewall や NVA (Network Virtual Appliance) を通す際に必要

2-2. Cross-Subscription / Cross-Tenant Peering

1. Parameter: Peering のサブスクリプション / テナントが異なる場合の設定

2. 推奨例:

   • “Spoke” が別サブスクリプションにあるときは、Peering 先を Resource ID で指定

   • 別テナント間 Peering は “Tenant Bから Invitation” → “Tenant Aが Accept” の流れで構成

3. 解説:

   • 大規模組織やマルチテナント環境では跨ぎが発生しやすい。NIST CSF “Identify - Governance (ID.GV)” でサブスクリプション/テナント構造を統制

3. Spoke VNet の運用

3-1. DNS 解決

1. Parameter: Hub VNet 内に DNS サーバー (Azure AD DS / 自前 DNS) を置く or Azure DNS

2. 推奨例:

   • Hub VNet でカスタム DNS (10.0.0.10) を運用、Spoke VNet は VNet Peering 経由で参照

   • On-Prem DNS と ExpressRoute/VPN でつながる場合、Hub VNet でフォワーダを設ける

3. 解説: DNS をどう解決するかがアプリ連携に影響。NIST SP 800-53 CM-2 / SC ファミリに基づき、名前解決を安全に行う

3-2. ネットワークセキュリティ

1. Parameter: Spoke VNet に NSG (subnet/NIC 単位), Azure Firewall (Hub)

2. 推奨例:

   • Spoke VNet 内で NSG を設定（Inbound Web ポートのみ Allow）

   • Outbound は Hub Firewall を経由して制御

3. 解説: SC-7（Boundary Protection）の実装例として、トラフィックは必ず Hub Firewall/NVA を経由する設計を推奨

4. オンプレとの連携（VPN / ExpressRoute）

4-1. Hub VNet での接続集中

1. Parameter: VPN Gateway Subnet, ExpressRoute Gateway Subnet, “Allow Gateway Transit”

2. 推奨例:

   • 例: “GatewaySubnet” 10.0.255.0/27 in Hub VNet

   • “ExpressRoute Gateway” or “VPN Gateway” を Hub に集約 → Spoke VNet は Hub 経由で on-prem と通信

3. 解説: マルチサブスクリプション / 複数 VNet がある場合にも、Hub & Spoke でゲートウェイを一元管理できる。NIST CSF “Protect - Communications” の観点で管理性向上

5. ログ・監査

5-1. Peering Diagnostics / Flow Logs

1. Parameter: Network Watcher → NSG Flow Logs (v2), VNet Peering Diagnostic Settings

2. 推奨例:

   • Hub VNet / Spoke VNet ともに Flow Logs を有効化 → Log Analytics

   • Peering 不備がないか、Network Watcher の Connection Troubleshoot で検証

3. 解説: NIST SP 800-53 AU（Audit）ファミリでネットワークイベントを監査可能にし、不審経路や漏れを早期に検知できる体制を構築

6. まとめ

VNet Peering / Hub-Spoke トポロジを設計する際には、以下のパラメーターを詳細に検討することで、クラウド移行後のネットワーク構成を統制し、NIST SP 800-53 SC-7 の境界保護と NIST CSF のネットワークセキュリティ要件を満たすことができます。

1. Hub VNet

   • 共通インフラ (Azure Firewall / NVA / Bastion / Gateway Subnet) を配置

   • “Allow Gateway Transit = True” で Spoke VNet が VPN/ExpressRoute を共有利用

2. Spoke VNet

   • アプリ別/部署別で分割、Use Remote Gateway = True で Hub のゲートウェイを活用

   • “Allow Forwarded Traffic = True” でトラフィックを Firewall / NVA へ転送

3. 命名や管理

   • Peering 名: “Hub-to-SpokeWeb”, “SpokeWeb-to-Hub”, “Hub-to-SpokeApp”…

   • IaC (Terraform/Bicep) で Peering 設定をコード化し、変更管理を徹底

4. 監査ログ

   • Network Watcher, NSG Flow Logs, Peering Diagnostics 設定

   • Log Analytics + Sentinel で集中監視

このように、しっかりとパラメーターを押さえつつ設計することで、オンプレから Azure への移行時にもスムーズにハイブリッド接続や多サブスクリプション運用を実現し、セキュリティと可用性の両面を強化できます。

 

 

 

 

以下では、NSG（Network Security Group） のルール設計について、パラメーター（具体的設定項目）レベルで詳しく解説します。オンプレからクラウドに移行した際に Azure 上でネットワークアクセスを制御する基本機能であり、NIST CSF “Protect - Access Control (PR.AC)” における最小権限の実装例として重要な役割を担います。

 

2. NSG (Network Security Group)

2-1. NSG ルール設計

A. インバウンド／アウトバウンド ルール

1. Parameter: ルールの方向（Inbound / Outbound）、優先度（100～4096）、送信元・宛先 IP / Subnet / Service Tag、ポート (TCP/UDP)、プロトコル

2. 推奨値 / 例:

   • Inbound:

     • Allow HTTP (TCP/80) only from “Internet” (Service Tag) to “WebSubnet”

     • Allow DB access (TCP/1433) only from “AppSubnet” to “DBSubnet”

     • Deny all others byデフォルト (最終的に “::* = Deny”)

   • Outbound:

     • Deny all 0.0.0.0/0 except HTTPS (TCP/443) if厳格に外部アクセスを制限

     • 許可が必要な特定ドメイン or IP だけ Allow (Azure SQL, Storage, etc.)

3. 補足:

   • 最小権限を基本とし、事前に具体的な通信要件を洗い出してルール化

   • ルール優先度は数値が小さいほど優先度が高い

   • NIST CSF “Protect - Access Control (PR.AC)” で示されるように、原則 Deny 他は必要最低限だけ Allow

B. 送信元 / 宛先の指定

1. Parameter: IP アドレス範囲、Service Tag（Internet, AzureLoadBalancer, AzureTrafficManager 等）、Application Security Group (ASG)

2. 推奨値 / 例:

   • “source = Internet (Service Tag)”, “destination = 10.0.0.0/24 or ASG=WebASG”

   • “source = DBASG, destination = 10.0.1.0/24” で DB 間通信を制限

3. 補足: Service Tag を使うと Azure 標準リソース（Load Balancer, Storage, SQL 等）へのアクセス指定を簡略化。ASG（Application Security Group） で同一アプリに属するVMをグループ化し、ポート/プロトコルルールを一括設定できる

C. TCP / UDP、プロトコル種別

1. Parameter: TCP, UDP, ICMP, すべて (Any)

2. 推奨値 / 例:

   • HTTP/HTTPS 用にTCP 80/443

   • DB 用にTCP 1433（SQL Server）、3306（MySQL）、1521（Oracle）など

   • ICMP (ping) は要件がなければ原則 Deny

3. 補足: 不要なプロトコル（Telnet, FTP, etc.）は許可しないが原則。NIST SP 800-53 SC-7（Boundary Protection）でも無用なプロトコルを閉じることが推奨される

2-2. ルールの優先度／命名規則

A. 優先度と命名

1. Parameter: Priority（100～4096）、Name（“Inbound-Web-HTTP-80-Allow”など）

2. 推奨値 / 例:

   • 100: “Inbound-Web-HTTP-80-Allow”

   • 110: “Inbound-Web-HTTPS-443-Allow”

   • 4000: “Inbound-Deny-All”

3. 補足: ルールは優先度が小さいほうから評価される。最終的にDeny Allを入れておき、意図しない通信用に抜けを作らないようにする

B. 管理方法 (IaC / Azure Portal / CLI)

1. Parameter: Terraform / Bicep / ARM Templates / Portal など

2. 推奨値 / 例:

   • Terraform で “azurerm_network_security_rule” リソースを定義し、ルールをコード化

   • メンテナンス性向上のため、Pull Request でレビュー

3. 補足: NIST CSF “Identify - Governance (ID.GV)” / CM-2（Configuration Management） を徹底するため、ネットワークルールも IaC 化が推奨される

2-3. Flow Logs (NSG)

A. NSG Flow Logs 有効化

1. Parameter: Diagnostic Settings (Network Watcher), Flow Logs “Version2”

2. 推奨値 / 例:

   • Network Watcher → “Enable NSG Flow Logs” → 選択した NSG → Log Analytics / Storage / Event Hub

   • Version2 で宛先ポートやアプリ層情報を詳細取得

3. 補足: NIST SP 800-53 AU（Audit）で通信ログ監査を実現。Flow Logs から不審なトラフィックを発見し、Sentinel でアラート化

B. Flow Logs の保管・分析

1. Parameter: Log Analytics Workspace 名、保存期間（90日～1年）、SIEM (Sentinel) 連携

2. 推奨値 / 例:

   • “law-secprod” (Log Analytics)、保存期間：180日 + Archive

   • Sentinel の “NSG Flow Logs” コネクタ設定 → 不審IPリストと突合

3. 補足: 改ざん防止（Immutable Storage）も検討し、NIST CSF “Detect” （DE）領域や AU-9（Protection of Audit Information）にも対応

2-4. 運用のベストプラクティス

A. “最小権限” 原則

1. Parameter: “Inbound: Deny All” + “Allow 特定ポート/サービス”

2. 推奨値 / 例:

   • Subnet / NIC レベルでルールを定義し、業務に必要な通信だけを明示的に許可

   • ICMP, SMB, Telnet 等は基本的に Deny

3. 補足: NIST CSF “Protect - Access Control (PR.AC)” で不要トラフィックを禁止し、攻撃面を縮小

B. ネーミング規則・タグ

1. Parameter: NSG 名（nsg-prod-web, nsg-prod-db）、Tag: env=prod, owner=NetworkingTeam

2. 推奨値 / 例:

   • nsg-dev-web, nsg-prod-app など環境名 + 役割を含む

3. 補足: 運用規模が拡大すると NSG が多数存在するため、Naming & Tagging で一目でわかるように整理

3. まとめ

NSG (Network Security Group) ルール設計は、クラウドネットワークにおける基本的なアクセス制御を担い、NIST SP 800-53 における SC-7 (Boundary Protection) や AC ファミリ の要件を満たすための中核となります。具体的には以下の項目を慎重に設定し、最小権限の実装と監査ログの活用を行うことが重要です：

1. インバウンド／アウトバウンドルール

   • 必要なポート／プロトコル／送信元・宛先を明確化し、それ以外は Deny

   • Service Tag や ASG で管理を簡略化

2. 優先度と命名

   • ルールの Priority を低→高の順で評価する仕組みを理解し、Deny all ルールを最終的に設定

   • ルールの名前を “Inbound-Web-HTTP-80-Allow” など可読性を高める

3. Flow Logs

   • Network Watcher で Flow Logs (Version2) を有効化して、Log Analytics / Sentinel に集約

   • 不審アクセスをトラッキングし、NIST CSF “Detect” フェーズでの分析・インシデント対応を容易に

4. IaC 化と監査

   • Terraform / Bicep / ARM Templates で NSG ルールを記述し、Pull Request で変更審査

   • AU-2（Auditable Events）に基づき、変更操作や実際の通信ログを監査法人や内部監査で示せるよう準備

このように、パラメーター単位で NSG を設計・管理することで、オンプレ環境から Azure への移行後もセキュアで透明性の高いネットワークセキュリティを維持できます。

​

 

 

 

 

 

 

以下では、Azure の Network Security Group (NSG) ルールにおいて、通信先や送信元を抽象的に管理するためのService TagおよびApplication Security Group (ASG) を活用する際のパラメーター設定や検討事項を詳しく解説します。これらを使うことで、NSG ルール定義が大幅に簡素化され、可読性や保守性が向上します。NIST SP 800-53 AC-4（Information Flow Enforcement） における情報フローの制御を効率よく行う実装例とも言えます。

 

 

2-2. Service Tag / ASG（Application Security Group）

A. Service Tag の設定

A-1. 主な Service Tag の種類

1. Parameter: “Internet”, “AzureCloud”, “AzureLoadBalancer”, “VirtualNetwork”, “AzureTrafficManager”, 等

2. 推奨値 / 例:

   • “Internet” を使うと、送信元／宛先を 0.0.0.0/0 と指定する代わりに抽象化可能

   • “AzureLoadBalancer” で内部ロードバランサとの通信を許可する場合など

3. 解説:

   • Service Tag は Microsoft が管理する IP 範囲をまとめたラベル。ユーザーが IP 範囲を個別に指定する手間を減らし、タグだけで外部アクセスを定義できる。

   • 例えば Inbound Rule: “source = Internet (Service Tag), destination = WebSubnet, port = 80” といった形で簡易化

A-2. 適用の際の注意点

1. Parameter: 送信元 (source) / 送信先 (destination) に設定できるかどうか（“Internet” は送信元/宛先どちらも可？）

2. 推奨値 / 例:

   • 受信規則の “source = Internet” で外部からの通信を示す

   • 送信規則の “destination = Storage” (Service Tag) で Azure Storage へのアクセスを許可

3. 解説:

   • サービスによっては Service Tag が送信元指定なのか宛先指定なのかが異なる。マイクロソフトが公開する Service Tag リストを参照し、対象範囲や利用可能なルール方向（inbound/outbound）を確認

B. Application Security Group (ASG)

B-1. ASG の基本概念

1. Parameter: ASG 名 (例: “WebASG”, “AppASG”), メンバーとなる NIC / VM

2. 推奨値 / 例:

   • “WebASG” に Web VM 群を登録 → NSG ルール “Allow inbound from AppASG → WebASG (port 443)”

   • “DBASG” に DB VM 群を登録 → NSG ルール “Allow inbound from AppASG → DBASG (port 1433)”

3. 解説:

   • ASG は NIC レベルに割り当てる “タグ” のようなもので、同じ用途のVMをグループ化して NSG ルールを書く。CIDR や IP を指定せず、論理的にグループ名で通信許可を定義できる

B-2. ルールでの活用

1. Parameter: NSG ルールの “source” や “destination” に “ASG=WebASG” と設定

2. 推奨値 / 例:

   • “Inbound rule: source = AppASG, destination = WebASG, protocol = TCP, port = 443, action = Allow”

   • “Inbound rule: source = WebASG, destination = DBASG, protocol = TCP, port = 1433, action = Allow”

3. 解説:

   • VM 台数が多い場合でも、個別 IP / サブネット範囲を指定する代わりに ASG で管理可能

   • NIST CSF “Protect - Access Control (PR.AC)” での最小権限実装を容易にし、VM の増減に応じて NIC を ASG に追加/削除するだけでルールを変更せず済む

3. 運用上のポイント

3-1. 命名規則・階層化

1. Parameter: ASG 名 (app-web-asg, app-db-asg など)、Service Tag の活用範囲

2. 推奨値 / 例:

   • “asg-prod-web”, “asg-prod-db” といった形で環境 (prod/dev) + 役割 (web/db) を明確化

   • Service Tag はインバウンドで “Internet” のみなら簡易管理、それ以外は “AzureCloud” 等を適宜活用

3. 解説: 大規模環境では ASG 数やルール数が膨大になるため、命名の一貫性とドキュメント管理が重要

3-2. Flow Logs と監査

1. Parameter: NSG Flow Logs v2 → Log Analytics / Sentinel, Diagnostic Settings

2. 推奨値 / 例:

   • Service Tag や ASG を使ったルールが正しく動いているか確認するために Flow Logs 解析

   • 不正通信（想定外の宛先IPなど）を検知するアラートを Sentinel で作成

3. 解説: NIST SP 800-53 AU ファミリ（Audit）にもとづき、どの ASG 同士の通信が実際に発生しているかを記録し、不審トラフィックや誤設定を早期発見

4. 例：Web-DB 間の通信を ASG で管理

• WebASG: Web サーバーの NIC をメンバー化 (VM1, VM2, VM3 など)

• DBASG: DB サーバーの NIC をメンバー化 (VM4, VM5)

• NSG ルール:

  • Inbound: source = WebASG, destination = DBASG, port = 1433 (SQL), action = Allow, priority = 100

  • Inbound: “Deny All others” (priority = 4000)

これにより、DBASG 側でポート 1433 を受ける通信を WebASG 由来に限定可能。VM に変更（追加/削除/スケール）した際も、NIC を適切な ASG に追加/削除するだけで済むため管理が容易。

5. まとめ

Service Tag と Application Security Group (ASG) を使うと、個別 IP や CIDR を羅列する従来型の NSG ルールよりも抽象化され、可読性・保守性が大幅に向上します。NIST SP 800-53 AC-4（Information Flow Enforcement）の要件を技術的に実装するうえで、以下の点を念頭に置くと効果的です：

1. Service Tag

   • Internet, AzureLoadBalancer, AzureCloud 等のタグを活用し、外部リソースへの許可/拒否を簡略化

   • Microsoft が Service Tag 対応 IP 範囲を更新してもタグで追随できる

2. ASG

   • 同一用途の VM（Web, App, DB, Bastion など）を論理グループ化し、NSG ルールをグループ単位で定義

   • VM 台数や IP 範囲が変動しても、ASG に NIC を追加/削除するだけで済む

3. Flow Logs / 監査

   • NSG Flow Logs v2 を有効にし、Log Analytics / Sentinel で通信状況を可視化・監視

   • 定期的にルールを見直し、最小権限の原則に立ち返る

これらの設計と運用を徹底することで、オンプレミスから Azure への移行時のネットワークセキュリティ管理がスムーズになり、NIST CSF “Protect - Access Control (PR.AC)” の要件にも適合しやすくなります。

​

​

​

​

​

以下では、Azure Firewall を導入してオンプレから Azure に移行した際のネットワークセキュリティを強化するステップとして、Firewall SKU、Public IP、Subnet、ルール設定などのパラメーター（設定項目）を詳細に解説します。特に、NIST SP 800-53 SC-7 (Boundary Protection) に則ったレイヤー3～4レベルの一元制御、および Premium SKU による IDPS・TLS Inspection を活用する点がポイントです。

​

​

​

​

3-1. Azure Firewall

A. Firewall SKU / Public IP の設定

1. Parameter: Firewall SKU (Standard / Premium)、Public IP 名（例：fw-publicip）、Firewall Subnet 名前（AzureFirewallSubnet）

2. 推奨値 / 例:

   • SKU: “Premium” if TLS Inspection or IDPS is required, “Standard” for基本的な L3-4制御

   • Public IP: 1 つ以上割り当て（例: fw-publicip-prod）

   • Firewall Subnet: 10.0.255.0/26 (必ず名前は AzureFirewallSubnet)

3. 解説:

   • Premium SKU は TLS inspection によるアプリ層の脅威検出機能 (IDPS) が付与

   • サブネット名は “AzureFirewallSubnet” という予約済み文字列が必須

   • パブリックIP がないと、インターネット向けアウトバウンド / Inbound NAT が確立できない

B. ルール設定（Outbound / Inbound / DNAT）

B-1. Outbound ルール

1. Parameter: Network rule (L3-L4) または Application rule (L7)

2. 推奨値 / 例:

   • Network rule: “Allow” from SpokeVNet-Subnet to Internet (TCP/443)

   • Application rule: “Allow” from SpokeVNet-Subnet to myapp.azurewebsites.net on port 443

3. 解説:

   • Network rule: IP/Port単位で制御 (例: 0.0.0.0/0 への 443 通信)

   • Application rule: FQDN (DNS名) ベースでアクセスを管理し、TLS Inspection可能（Premium SKU）

   • NIST SP 800-53 SC-7 で要求されるネットワーク境界防御を行いつつ、最小限のインターネット通信のみ許可する

B-2. Inbound ルール

1. Parameter: DNAT / Destination IP, ポート, Forward to Backend IP

2. 推奨値 / 例:

   • DNAT: Public IP on Firewall (TCP/443) → Private IP in Spoke Subnet (10.0.1.4)

   • 追加で “Allow” ルールを Network Rule でも設定

3. 解説:

   • Inbound を Azure Firewall で受け、Spoke VNet のアプリサーバーに転送する

   • WAF が別途（App Gateway）ある場合は、Firewall で DNAT → App Gateway → VM というフローを組むケースも

   • NIST CSF “Protect - Communications” の観点で外部からの受信トラフィックを一箇所 (Azure Firewall) に集約し、脅威検知する

B-3. DNAT ルール

1. Parameter: DNAT ルールコレクション、Priority、Source IP/Port, Destination IP, Protocol

2. 推奨値 / 例:

   • DNAT ルールコレクション名: “DNAT-ProdWeb” / Priority: 200

   • Source: Firewall PublicIP (TCP/443), Destination: 10.0.1.4:443

3. 解説:

   • DNAT ルールコレクションでインバウンドを転送し、Network Rule で対応する許可ルールも書く

   • Premium SKU では IDPS を経由して脅威検知が可能。NIST SP 800-53 SI（System and Information Integrity） の観点でも悪意あるトラフィックを検知しやすい

C. Premium SKU: TLS Inspection / IDPS

C-1. TLS Inspection

1. Parameter: Azure Firewall Premium, Certificate for Decryption/Re-Encryption (Key Vault)

2. 推奨値 / 例:

   • Key Vault に自己署名 CA 証明書をアップロード → Firewall で TLS Inspection を有効化

   • アプリルールや IDPS で HTTPS トラフィックを復号し、マルウェア検知やドメイン制限を強化

3. 解説:

   • HTTP/HTTPS レイヤーでの脅威検知が可能

   • NIST SP 800-53 SC-7 / SI-4 (Information System Monitoring) などで暗号トラフィック内の攻撃を検出できる仕組みが有効

C-2. IDPS (Intrusion Detection & Prevention System)

1. Parameter: Azure Firewall Premium で IDPS モード (Alert / Alert & Deny)

2. 推奨値 / 例:

   • 初期は “Alert” モードで誤検知を確認し、安定後 “Deny” モードに切り替え

   • 規則セット（シグネチャ）を定期的に更新

3. 解説:

   • NIST SP 800-53 SI-4 (Information System Monitoring) や SI-7（Software, Firmware, and Information Integrity）に相当し、攻撃パターンをリアルタイム検出

D. Hub-Spoke 配置

1. Parameter: Firewall を Hub VNet に配置し、Spoke VNet と Peering

2. 推奨値 / 例:

   • Hub VNet (CIDR 10.0.0.0/16) → AzureFirewallSubnet (10.0.255.0/26) → Firewall Premium SKU

   • Spoke VNet (App Subnet, DB Subnet) からデフォルトルート(0.0.0.0/0) を Firewall に向ける UDR

3. 解説: Hub-Spoke 構成で全トラフィックが Firewall を経由する設計が基本。NIST CSF “Protect - Communications” で一元的に境界防御を行い、Spoke 側のリソースを保護

4. 補足：ログと監査

A. Firewall Policy / Logging

1. Parameter: Firewall Policy (Azure Firewall Manager), Diagnostics Settings (Log Analytics / Event Hub / Storage)

2. 推奨値 / 例:

   • Azure Firewall Manager でポリシーを作成し、複数 Firewall に適用

   • Firewall Logs (レイヤー3-4) と IDPS Logs (Premium) を Log Analytics に送信

3. 解説: NIST SP 800-53 AU（Audit） に沿って、Firewall が許可 / 拒否 / IDPS 検知したイベントを記録し、SIEM (Sentinel) でアラート化

B. Flow Logs + Firewall Logs

1. Parameter: NSG Flow Logs (Network Watcher), Azure Firewall Logs

2. 推奨値 / 例:

   • NSG Flow Logs で細かい TCP/UDP セッションを観察

   • Firewall Logs でポート/プロトコル単位の可視化と IDPS アラートを確認

3. 解説: NIST CSF “Detect” フェーズでの脅威検知を強化するには、複数階層（NSG + Firewall）ログを相関分析し、ネットワーク内部や外部からの攻撃を迅速に見つける

5. まとめ

Azure Firewall は、NIST SP 800-53 SC-7（Boundary Protection） の要件を満たすためのクラウドネイティブなファイアウォールソリューションであり、次のようなパラメーターを設定することが鍵となります：

1. SKU: Standard か Premium (TLS Inspection / IDPS の要否)

2. パブリック IP / Subnet: “AzureFirewallSubnet” （必須）, /26 程度の CIDR を確保

3. Outbound / Inbound / DNAT ルール:

   • Application Rule (L7) で FQDN ベース制御 (Premium なら TLS Inspection)

   • Network Rule (L3-L4) で IP/Port を指定

   • DNAT ルールコレクションで外部→内部サーバーの転送定義

4. IDPS (Premium): “Alert mode” or “Alert & Deny” + シグネチャ更新

5. ログ・監査: Firewall Logs, IDPS Logs, Audit to Log Analytics / Sentinel, Diagnostics Settings

6. Hub-Spoke トポロジ: Firewall を Hub VNet に配備し、Spoke VNet から強制トンネリング (UDR) で通過させる

これらの設定を踏まえ、オンプレから Azure への移行時にネットワーク境界を集中的に管理することで、クラウド移行後も堅牢な通信制御や脅威検知を実現します。さらに、NIST CSF の “Protect” カテゴリで必要となる複数レイヤーのセキュリティ対策を強化し、Shared Responsibility Model における利用者側責任（アプリケーション層 / ネットワーク設定）を十分にカバーすることが可能です。

​

​

以下では、Application Gateway (WAF) を導入してオンプレから Azure に移行した際に Web レイヤーを保護するステップとして、WAF v2 SKU、Frontend IP（Public/Private）、Listener 設定、OWASP CRS バージョン といったパラメーターを詳細に説明します。特に、NIST CSF “Protect - Communications Security” および NIST SP 800-53 SC-7 (Boundary Protection) に該当する L7 レイヤーでの攻撃対策が主眼となります。

​

3-2. Application Gateway (WAF)

A. WAF SKU 選択

1. Parameter: “Application Gateway v2 SKU” (Standard_v2 or WAF_v2)

2. 推奨値 / 例:

   • WAF_v2 SKU を選ぶと、アプリ層の攻撃（OWASP Top 10）を防御可能

   • “Autoscaling” 機能 (min=2, max=10) で可用性を確保

3. 解説:

   • WAF 機能を利用するには “WAF_v2” SKU が必須。Standard_v2 は単なる L7 LB であり WAF 機能なし

   • NIST SP 800-53 SC-7 (Boundary Protection) の観点で、レイヤー7 (HTTP/HTTPS) 攻撃をフィルタリングする際に不可欠

B. Frontend IP (Public / Private)

1. Parameter: Frontend IP Config (Public IP / Private IP)、DNS 名 (例: myapp.eastus.cloudapp.azure.com)

2. 推奨値 / 例:

   • “Public IP”: 1 つ割り当て → “HTTP / HTTPS Listener”

   • Private IP：VNet 内で内部アクセスのみ受ける場合

3. 解説:

   • インターネット向け公開の場合は Public IP で Listener を構成

   • 社内 (オンプレ / VNet内) 限定のアプリなら Private IP Listener でデプロイ

   • NIST CSF “Protect - Communications Security (PR.PT)”：適切な IP スコープ (public / private) を選び、余計な外部公開を防ぐ

C. Listener 設定

1. Parameter: “HTTP / HTTPS” Listener、Host name、Port、SNI、SSL 証明書

2. 推奨値 / 例:

   • Listener 名: “listener-https-443”

   • Protocol: HTTPS, Port: 443, Host name: www.example.com

   • SNI: 有効化, SSL 証明書: Key Vault に格納 / PFX アップロード

3. 解説:

   • リスナー単位でドメインやポートを指定し、WAF がフロントエンドリクエストを受けてバックエンドプールへ転送

   • SSL/TLS 終端（Offloading）を Application Gateway に任せて、バックエンドサーバーとの通信は内部 HTTP などにできる

D. WAF ポリシー (OWASP CRS)

1. Parameter: “Prevention / Detection” モード、OWASP CRS (Core Rule Set) バージョン (3.2+)、カスタムルール

2. 推奨値 / 例:

   • “Prevention モード” 本番稼働時、疑わしいリクエストをブロック

   • “CRS 3.2” か以降で最新の脆弱性シグネチャに対応

   • カスタムルールで特定パラメータや IP を Allow / Deny

3. 解説:

   • OWASP CRS による XSS / SQL Injection / CSRF などの攻撃防御

   • Detection モードはロギングのみでブロックしないテスト用、本番では Prevention モードに移行

   • NIST SP 800-53 SI-4 (Information System Monitoring) や SC-7 (Boundary Protection) を補完し、高度なレイヤー7 攻撃も検知・遮断

E. Autoscaling とスケーリングパラメーター

1. Parameter: Min/Max Instances, Autoscale Threshold (CPU Utilization)

2. 推奨値 / 例:

   • min=2, max=10, Autoscale Trigger= CPU 70% or “Avg Requests/sec”

3. 解説:

   • 大量アクセスが発生しても Application Gateway が自動でスケールアウトし、サービスを継続

   • NIST CSF “Protect - Resource Management (PR.IP-4)” で過負荷リスクを緩和し、可用性を維持

F. SSL Offloading / End-to-End SSL

1. Parameter: “SSL Offloading”, “End-to-end TLS”, “TLS Policy (1.2+, ciphers)”

2. 推奨値 / 例:

   • Offloading: フロントエンドだけ TLS termination → Backend は HTTP (非暗号)

   • End-to-end: フロントエンド・バックエンドとも TLS で暗号化

   • TLS Policy: “AppGwSslPolicy20170401S” or Custom ciphers

3. 解説:

   • オンプレ / 法規制 (PCI DSS, HIPAA) 次第でフル暗号化を要求される場合は “End-to-end”

   • NIST SP 800-53 SC-8 (Transmission Confidentiality) で SSL/TLS のバージョンや暗号スイートを制限し、安全性を確保

G. Backend Pool / Health Probe

1. Parameter: Backend Pool (IP/Hostname, VM Scale Set, App Service, AKS) + Health Probe (path, interval)

2. 推奨値 / 例:

   • Backend Pool: “WebServer1(10.1.0.5), WebServer2(10.1.0.6)”

   • Health Probe: path = “/healthcheck”, interval=30s, healthyThreshold=3

3. 解説:

   • WAF が正常なバックエンドだけにトラフィックを振り分けることで可用性を維持

   • PCI DSS や FISC などの可用性要件が高い業種で特に必須

H. ログと診断

1. Parameter: “ApplicationGatewayAccessLog”, “ApplicationGatewayFirewallLog”, “Diagnostic Settings → Log Analytics / Event Hub / Storage”

2. 推奨値 / 例:

   • Access Log: HTTP status, request URI, latency

   • Firewall Log: Rule triggered, Attack type (OWASP rule ID)

   • Storage / Log Analytics で 90日～1年保管 & Sentinel で相関分析

3. 解説:

   • NIST SP 800-53 AU ファミリ（Audit） で Web レイヤーの操作ログを収集し、攻撃シグネチャや可疑なリクエストを監視する

まとめ

Application Gateway (WAF) を導入し、WAF_v2 SKU で「OWASP CRS + Autoscaling + SSL/TLS 制御 + L7 ロードバランシング」を活用することで、NIST CSF “Protect - Communications Security” の要件を満たす高水準の Web アプリ防御を実現できます。具体的なパラメーターとしては、

1. SKU: WAF_v2 を選び、Autoscale と WAF ポリシー (OWASP CRS 3.2+) を設定

2. Frontend IP / Listener: Public / Private IP、リスナー名、SNI、SSL 証明書

3. WAF ポリシー: Prevention モード、CRS バージョン指定、カスタムルール

4. Autoscaling: min=2, max=10 のように設定し、トラフィック増に耐えられる構成

5. SSL Offloading / End-to-End SSL: 要件に合わせて暗号化を終了する地点や TLS Policy を定義

6. Logging & Analytics: WAF Access/WAF Logs を Log Analytics / Sentinel に連携し、攻撃を検知・防御

このように、WAF を複数のアプリケーションや異なるサブスクリプションでも共通的に使用する形で設計すれば、オンプレからクラウドへ移行した Web アプリ全体に対し、SSL/TLS 終端・WAF機能・OWASP Rule による攻撃対策を一貫して提供できます。

​

​

​

以下では、Site-to-Site VPN を活用してオンプレミスと Azure 間を接続する際のパラメーター（設定項目）レベルでの詳しい解説を行います。帯域要件やコスト面を考慮して VPN (IPsec/IKE) を選ぶケースは多く、NIST SP 800-53 SC-8 (Transmission Confidentiality) の暗号化要件に対応するには、確実に安全な暗号化スイートを設定することが重要です。

​

​

​

4-1. Site-to-Site VPN

A. VPN Gateway SKU

1. Parameter: “VpnGw1”, “VpnGw2”, “VpnGw3”, “VpnGw4”, “VpnGw5”

2. 推奨値 / 例:

   • VpnGw1: 小規模 ~ 中規模でコストを抑えたい場合

   • VpnGw2 or VpnGw3: 中～高帯域が必要な場合（数百 Mbps まで対応）

   • VpnGw4 / VpnGw5: 極めて大規模、かつ数 Gbps の通信が必要なシナリオ

3. 解説:

   • SKU によって VPN の最大スループットや同時接続数が異なる

   • 必要帯域と冗長度を検討し、費用対効果のバランスを取る

B. GatewaySubnet

1. Parameter: “GatewaySubnet” 名前固定、CIDR (例: 10.0.254.0/27)

2. 推奨値 / 例:

   • GatewaySubnet を /27 以上のサイズで確保

   • VNet のアドレス空間内に “GatewaySubnet” を作成し、VPN Gateway を配置

3. 解説:

   • サブネット名は必ず “GatewaySubnet” とする

   • Azure が Gateway サービスを内部的に管理するため、VNet ピアリングや Azure Firewall と組み合わせる際のルーティングも注意

C. IKEv2 / IPsec 設定

1. Parameter: IKEv1 / IKEv2 選択、暗号スイート (AES256 / SHA256 / DHGroup14 など)

2. 推奨値 / 例:

   • AES256/SHA256 組み合わせ、DHGroup14（もしくは 24）を使う → 高いセキュリティレベル

   • IKEv2 を推奨し、古い IKEv1 は利用しない

3. 解説:

   • NIST SP 800-53 SC-8 (Transmission Confidentiality) にて、強力な暗号化アルゴリズム（AES 256bit / SHA2 系ハッシュ）を要求する

   • VPN デバイスやファイアウォールとの互換性を事前に検証

D. Active-Active 接続 / 冗長化

1. Parameter: “Active-Active” モード (構成の有無)、BGP ルーティング

2. 推奨値 / 例:

   • “Active-Active = True” としてオフプレ側も 2 つのトンネルを張る

   • BGP を有効化し、動的ルーティングによる冗長経路を確保

3. 解説:

   • 障害耐性を高めるための設計 → NIST CSF “Protect - Communications” / CP ファミリ（Contingency Planning）にも沿う

   • Azure VPN Gateway 上で BGP を使うと、オンプレルーター側も BGP 対応が必要

E. Bandwidth / Latency要件

1. Parameter: VPN の実効帯域 (数十 Mbps ～ 数百 Mbps)、遅延 (ms)

2. 推奨値 / 例:

   • 軽量トラフィック (ファイル共有、管理系) なら VpnGw1/2 でも十分

   • 重い DB レプリケーションなど大容量通信があるなら VpnGw4/5 or ExpressRoute を検討

3. 解説:

   • NIST CSF “Identify - Risk Assessment (ID.RA)” で業務要件を見極め、VPN の帯域が足りるかどうかを性能テスト

F. コスト

1. Parameter: Gateway SKU の月額費用 + 送信データ転送料

2. 推奨値 / 例:

   • VpnGw1: $$140/month$ 程度

   • VpnGw2: $$200~$ 程度

   • Outbound データ転送に従量課金が適用される場合あり

3. 解説:

   • ExpressRoute が高コストで導入ハードルが高い一方、VPN は比較的安価だが性能・SLA は限定的

   • NIST CSF “Protect - Resource Management (PR.IP-4)” に従い、コストと可用性を天秤にかけて選択

G. Security

1. Parameter: “IPsec/IKE” ポリシー、PFS (Perfect Forward Secrecy)、Tunnel Mode

2. 推奨値 / 例:

   • AES256, SHA256, DHGroup14 / 24, PFS enabled

   • Disable IKEv1, old ciphers (DES, 3DES, MD5) は使用しない

3. 解説:

   • NIST SP 800-131A などで示唆される強力な暗号スイートを選択

   • オンプレ機器側との互換性を事前に確かめる

H. 運用・ログ

1. Parameter: “VPN Diagnostics Logging” = On, Azure Monitor / Log Analytics への転送

2. 推奨値 / 例:

   • VPN Gateway Diagnostic Settings → Resource-specific logs → Activity Logs, Connection Logs

   • Azure Sentinel 連携でトンネルダウン / 再接続等をアラート化

3. 解説:

   • NIST SP 800-53 AU（Audit） の要求で VPN 接続の可用性や失敗イベントを追跡可能にし、トラブルシューティングやセキュリティ監視を実施

まとめ

Site-to-Site VPN は、NIST SP 800-53 SC-8 (Transmission Confidentiality) に準拠するために安全な暗号化 (IPsec/IKE) を適用しながら、比較的低コストでオンプレと Azure をつなぐ手段として有効です。具体的なパラメーターとしては以下を検討します。

1. VPN Gateway SKU: “VpnGw1” ～ “VpnGw5” のうち、必要な帯域や接続数に合ったモデルを選択

2. GatewaySubnet: 名前は固定 (“GatewaySubnet”) で、CIDR (/27 以上) を確保

3. IKEv2 / IPsec 設定: AES256 + SHA256 + DHGroup14/24 など強力な暗号化スイートを使用

4. Active-Active 冗長化: 2 つのトンネルで高可用性を実現、BGP (動的ルーティング) をオプションで使用

5. ログと監査: VPN Gateway Logs を Azure Monitor / Sentinel に送信し、接続ステータスやトラフィックを監視

6. コスト管理: SKU 月額 + 従量課金 (Outbound) を踏まえて選択し、必要に応じて ExpressRoute との比較検討

このように、“VPN + Azure VNet” の構成を最小権限の NSG や Firewall と組み合わせることで、オンプレ環境と Azure 間の安全なトラフィックをNIST CSF や SP 800-53 の要件に適合する形で実現できます。

​​

​

​

以下では、ExpressRoute を利用してオンプレミスと Azure を接続する際のパラメーター（設定項目）を中心に、帯域幅、Peering Type（Private/Microsoft）、冗長構成などを記述します。NIST CSF “Protect - Communications (PR.PT)” を満たすためには、高可用かつ安全な専用線接続が必要となる場面が多く、金融・大規模企業で特に選択肢として挙がるのが ExpressRoute です。

​

4-2. ExpressRoute

A. 回線帯域 (50Mbps～10Gbps)

1. Parameter: 回線スピード（50Mbps, 100Mbps, 1Gbps, 2Gbps, 5Gbps, 10Gbps など）

2. 推奨値 / 例:

   • 小規模拠点で 100Mbps 程度

   • 金融業や大規模企業 → 1Gbps ~ 10Gbps で低レイテンシかつ高帯域が必要

   • 帯域を動的にアップグレード可能（契約形態による）

3. 解説:

   • ExpressRoute はインターネットを経由しない専用線に近い経路提供で、回線品質が高い

   • NIST CSF “Protect - Communications (PR.PT)” で要求される可用性確保 (高帯域・低遅延) を実装する形

B. Peering Type (Private Peering / Microsoft Peering / Public Peering)

1. Parameter: “Private Peering”, “Microsoft Peering”, “Public Peering”

2. 推奨値 / 例:

   • Private Peering: Azure VNet との接続に使用 → VM, PaaS (一部) へ専用線アクセス

   • Microsoft Peering: Office 365 / Dynamics 365 など Microsoft 公共サービスへの専用線ルート

   • Public Peering: 以前の方法で Public Endpoint (Azure Storage, Azure SQL) に専用線アクセス（現行はほぼ “Microsoft Peering” に統合）

3. 解説:

   • 多くのシナリオで Private Peering（VNet間接続）を中心に使い、Office 365 などへの最適化が必要なら Microsoft Peering を追加

   • NIST SP 800-53 SC-7 (Boundary Protection) で公共クラウドアクセスを専用線化し、通信経路を安全に保つ

C. 冗長接続

1. Parameter: Primary / Secondary 回線、冗長ルータ / POP 拠点 (diverse path)

2. 推奨値 / 例:

   • ExpressRoute Premium（世界的なリージョン接続や高帯域をカバー）

   • 2 本の物理回線を別ルートで確保し、片方故障でも切り替え

   • BGP でルーティングを動的に切り替え

3. 解説:

   • SLA (99.95% 以上) を達成するには回線冗長が必須となる

   • 金融庁ガイドラインや FISC 安全対策基準でも DR/BCP 用に物理ルート分散を求めるケースがある

   • NIST CSF “Protect - Communications” かつ “Recover (RC)” の観点でも高可用性ルートが推奨

D. 実際の回線手続き / 接続

1. Parameter: キャリア・プロバイダ選定 (NTT, KDDI, Colt, BT, Verizonなど)、POP 場所、物理工事

2. 推奨値 / 例:

   • 大手キャリアが提供する ExpressRoute 回線をデータセンター or オンプレまで敷設

   • Azure の “ExpressRoute Location” と接続プロバイダをマッチングし、帯域と料金を見積

3. 解説:

   • NIST CSF “Identify - Risk Assessment (ID.RA)” でキャリア障害リスクやPOP場所の地理的分散を検討

   • 導入まで数週間～数か月かかる点や月額費用が大きい点に注意

E. ルーティング設計 (BGP)

1. Parameter: ASN (Autonomous System Number), BGP Peering (Private / Microsoft), Route Filter

2. 推奨値 / 例:

   • 自社 ASN (例: 65001) を用意し、Azure の ASN (12076) と BGP ピアを確立

   • Route Filter: “Microsoft Peering” で O365 / Dynamics 365 サービスを限定する

3. 解説:

   • ExpressRoute は BGP を使い動的にルーティング情報交換。オンプレと Azure の IP 範囲を相互にアドバタイズ

   • BGP が不慣れな企業は設計段階でネットワーク専門家の支援を受けることが多い

F. コスト見込み

1. Parameter: 初期導入費（回線敷設、ポートチャージ）、月額費用（帯域、従量）、プレミアムアドオン

2. 推奨値 / 例:

   • 1Gbps Port: 1～数十万円/月 + 回線費 + “ExpressRoute Premium” 加算

   • Outbound データ転送が従量課金 or 無制限プランなど選択可能

3. 解説:

   • NIST CSF “Protect - Resource Management (PR.IP-4)” で必要リソース確保を行い、IaaS / PaaS のコストと合わせて TCO を算出

   • 一般に VPN よりも高額だが、可用性や帯域、レイテンシが優位

G. ログ・監査

1. Parameter: ExpressRoute Monitor (Azure Monitor / Resource Health), NPM (Network Performance Monitor)

2. 推奨値 / 例:

   • ExpressRoute Connection status (BGP up/down) を Log Analytics で常時監視

   • モジュール “Network Performance Monitor” でオンプレ～Azure 間の遅延測定

3. 解説:

   • 障害時の検知と通知を迅速に行い、NIST SP 800-53 SI-4（System Monitoring）と CP ファミリ（Contingency Planning）で冗長構成を確保

まとめ

ExpressRoute は、NIST CSF “Protect - Communications (PR.PT)” や NIST SP 800-53 SC-7 (Boundary Protection) の要件を満たすために、インターネットを経由しない専用線接続を提供し、可用性・セキュリティを高める手段として有力です。移行にあたっては、以下のパラメーターを詳細に検討しましょう。

1. 回線帯域 (50Mbps ~ 10Gbps)

   • 必要となるトラフィック量に応じて SKU を選定

2. Peering Type (Private / Microsoft / Public)

   • VNet 接続 (Private)、Office 365 用 (Microsoft) など用途に合わせる

3. 冗長接続

   • Primary / Secondary 回線の多重化、BGP による自動フェイルオーバー

4. ルーティング (BGP, Route Filter)

   • On-Prem と Azure 間で IP 座席の重複がないことを確認し、ASN を決定

5. コスト

   • Port チャージ + 帯域費用 + Premium アドオン（広域接続等）

6. ログ監視

   • Azure Monitor / NPM で BGP セッションや可用性を監視、緊急時の切り替えや障害検出を自動化

このように、ExpressRoute を適切に構成することで、大規模・高可用性・高セキュリティが求められるシステム（特に金融業や大企業）において、オンプレミス～Azure 間の専用線クオリティの接続を実現できます。

​​

​

​

​

セキュリティ要件・ログ管理

​

以下では、Azure Monitor と Azure Sentinel を連携させ、VNet Flow Logs、Firewall Logs、WAF Logs など各種ログを一元管理・分析するための手順やパラメーターを、NIST SP 800-53 AU（Audit） の視点で記述します。オンプレから Azure に移行した後のネットワーク監視やセキュリティ監査を強化するため、ネットワーク周りのログをすべてLog Analytics に集約し、Sentinel で相関分析・アラート化する流れが重要です。

​

​

5-1. Azure Monitor / Sentinel 連携

A. Diagnostic Settings （Network Watcher, Firewall, WAF 等）

A-1. Network Watcher: NSG Flow Logs (Version2)

1. Parameter: “Enable NSG Flow Logs”, “Flow Logs Version” (v2), “Storage / Log Analytics / Event Hub”

2. 推奨値 / 例:

   • NSG Flow Logs v2 → Log Analytics Workspace “law-networksecurity”

   • Retention: 90日 (ホット) + Archive 1年

3. 解説:

   • NSG Flow Logs により、サブネット／NIC 単位でトラフィックの通過可否を記録（送信元 IP, 宛先 IP, ポート, プロトコル, Bytes など）

   • Flow Logs v2 は流量やメタ情報がより詳細に取得できる

   • NIST SP 800-53 AU（Audit） の要件を満たすため、すべての通信可否を記録し、不審アクセスを後から追跡できる設計

A-2. Azure Firewall Logs

1. Parameter: Firewall 設定 → Diagnostics → “AzureFirewallApplicationRule”, “AzureFirewallNetworkRule”, “AzureFirewallDNSProxy”

2. 推奨値 / 例:

   • Logs を Log Analytics Workspace “law-firewall” に集約

   • Firewall Policy (Azure Firewall Manager) で中央管理し、複数 Firewall に共通のロギングを適用

3. 解説:

   • Azure Firewall の Application / Network ルールによる許可／拒否イベントを記録

   • Premium SKU の IDPS 検知ログ (アラート) も取得し、攻撃パターンを分析

   • NIST CSF “Detect (DE)” フェーズで重要なログソース

A-3. WAF (Application Gateway) Logs

1. Parameter: “ApplicationGatewayAccessLog”, “ApplicationGatewayFirewallLog”

2. 推奨値 / 例:

   • Diagnostic Settings → Log Analytics Workspace “law-waf”

   • AccessLog: HTTPリクエスト情報 (URI, Status Code, Latency)

   • FirewallLog: WAF ルール (OWASP CRS) によるアラート / ブロックイベント

3. 解説:

   • L7 レイヤーの攻撃や不正リクエストを捕捉するために重要

   • NIST SP 800-53 AU および SI-4 (Information System Monitoring) にも合致し、Web アプリへの攻撃を可視化しやすくなる

B. Log Analytics Workspace

1. Parameter: Workspace 名、リージョン、保存期間、ソリューション (NSG, Network Performance Monitor, Defender for Cloud)

2. 推奨値 / 例:

   • “law-secprod” (Security-centric Workspace), 90日保持 + コールドストレージ (Archive) 1年

   • リージョンは VNet と同じく日本国内 (Japan East 等) で集約

3. 解説:

   • 全ての Diagnostics Logs を同じ Workspace に送り、データ相関分析をしやすくする

   • 保管期間 / Immutable Storage 化の要否は NIST SP 800-53 AU-9（Protection of Audit Information） で検討

C. Azure Sentinel (SIEM) 連携

C-1. Data Connectors

1. Parameter: Sentinel “Data connectors” → “Azure Firewall”, “Application Gateway”, “Network Security Group”, “Azure Activity” 等

2. 推奨値 / 例:

   • 有効化 → Workspace / Subscription を指定 → テンプレートルールや Workbook をインポート

   • “Azure Firewall Connector” で IDPS イベントを取り込み

3. 解説:

   • Sentinel はマネージド SIEM で、クラウド環境のロギングを自動連携

   • NIST CSF “Detect (DE)” で脅威インテリジェンスを活用したアラートを設定し、異常行動を検知

C-2. KQL ルール / アラート

1. Parameter: Sentinel Analytics Rule (Scheduled Query), Kusto Query Language (KQL)

2. 推奨値 / 例:

   • “NSGFlowLogs | where DestinationIP == <critical DB IP> and Port != 1433” → アラート

   • “AzureFirewallNetworkRule | where Action == ‘Deny’ and SourceIP is in knownMaliciousIPList” → Severity High

3. 解説:

   • KQL で柔軟に検索・アラート条件を定義

   • NIST SP 800-53 SI-4 (Information System Monitoring) に基づき、疑わしい通信をリアルタイムに検出する仕組みを実装

D. 不審トラフィックの可視化と対応

D-1. ワークブック / ダッシュボード

1. Parameter: Sentinel Workbook (Network Security, Firewall Dashboard, WAF Overview)

2. 推奨値 / 例:

   • “Azure Firewall Overview” → Top Deny/Allow ルール、IDPS シグネチャヒット数

   • “NSG Flow Logs Analysis” → パケット量トップ IP, 常に通信が失敗している IP

3. 解説:

   • グラフィカルなダッシュボードで運用チームがリアルタイムにネットワーク異常を把握し、NIST CSF “Detect (DE.CM)” フェーズにおける監視を強化

D-2. インシデントレスポンス

1. Parameter: Sentinel “Automation Rule” (Logic Apps), “Incident Triage”

2. 推奨値 / 例:

   • 攻撃検知 → 自動的に Azure Firewall ルールで該当 IP をブロック (Logic Apps)

   • ダミーインシデントで演習し、NIST CSF “Respond (RS)” フェーズのプロセスを検証

3. 解説:

   • ログ監視 → アラート → 自動化された対処フロー → Post-mortem レポートの流れを確立し、継続的にブラッシュアップ

E. 運用上のベストプラクティス

1. Parameter:

   • 統一された命名規則（Log Analytics Workspace, Diagnostics Settings, Sentinel Rule）

   • 長期保存 / Immutable Storage の要否

2. 推奨値 / 例:

   • “diagnostic-nsgflow-webprod” など命名し、タグ “env=prod, project=webapp”

   • 監査法人から 1年以上の保管を要求されるなら Immutable Blob Storage へエクスポート

3. 補足:

   • NIST 800-53 AU-9（Protection of Audit Information） でも監査ログの改ざん防止を推奨しており、Azure Storage の “Time-based Retention” オプションなどを活用

まとめ

Azure Monitor と Sentinel を連携し、VNet Flow Logs / Firewall Logs / WAF Logs などの複数ソースを一元管理することで、NIST SP 800-53 AU（Audit） の基準を満たしながら、下記のような利点が得られます：

1. 総合的なネットワーク可視化

   • NSG Flow Logs (Version2) でサブネット/VM 単位の通信状況を可視化

   • Azure Firewall / WAF Logs で L3～7 階層の攻撃/遮断/許可を追跡

2. 相関分析 / アラート

   • Sentinel の “Analytics Rule” で複数ログを横断し、脅威となるパターンを自動検知

   • オンプレ・クラウド間のログ連携も行い、包括的なセキュリティ監視を実現

3. 監査 / ログ保管

   • Log Analytics で 90日～1年以上保管し、改ざん防止や監査法人対応がしやすい

   • Immutable Storage + Archive オプションで法定監査要件にも対応可能

こうした仕組みを整備することで、オンプレ移行後のネットワークセキュリティが高まり、NIST CSF “Detect” と “Respond” フェーズの効率的なサイクルを構築できます。また、AU ファミリ（Audit and Accountability）を充足し、内外監査や規制要件にも柔軟に応じられます。

​​

​

​

​

​

​

以下では、監査ログなどの証跡を Azure で保管する際、Immutable Blob Storage（WORM: Write Once, Read Many） を活用してログの改ざん防止と**一定期間の保持（Retention Policy）**を実現するための具体的設定項目や流れを詳しく解説します。NIST CSF “Detect” (DE) および “Respond” (RS) のインシデント調査フェーズや、NIST SP 800-53 AU-9（Protection of Audit Information） を踏まえ、クラウドでのログ保管の改ざんリスクに対応する方法として有効です。

​

​

​

5-2. 証跡保全と改ざん防止

A. Storage Account 設定

A-1. Storage Account Type / SKU

1. Parameter: “Blob Storage” / “General Purpose v2” / “Premium / Standard”

2. 推奨値 / 例:

   • “General Purpose v2” Standard (LRS / GRS など) が一般的

   • Blob Storage アカウントを選んでログファイル (NSG Flow Logs, Firewall Logs 等) を専用コンテナに保管

3. 解説:

   • Immutable Blob Policy は Block Blob のコンテナに適用するため、Blob Storage か General Purpose であることを確認

   • 過度な IOPS / スループットが不要なら Standard で十分

B. Immutable Blob (WORM) 設定

B-1. コンテナレベルの Immutability Policy

1. Parameter: Time-based retention / Legal hold

2. 推奨値 / 例:

   • “Time-based Retention = 365 days” → 1年間は書き込み後のオブジェクトを削除 / 上書き不可

   • “Legal hold” は特定タグをつけて保護、必要がなくなるまで取り消し不可

3. 解説:

   • Write Once, Read Many (WORM) で、ログを保存したら期間内は削除・編集が一切できない

   • 監査法人や規制要件で数年間の改ざん不可保管が求められる場合に適合

B-2. パラメータ例

1. Parameter: retentionEnabled = true, retentionDays = 365, allowProtectedAppendWrites = true (optional)

2. 推奨値 / 例:

   • CLI / ARM Template で --period 365 など指定

   • “allowProtectedAppendWrites” は追記 (append) は可能だが上書きは不可にする設定

3. 解説:

   • Azure Portal からは Container → Access policy → Immutable blob storage で設定

   • バージョニングや Soft Delete と組み合わせることで、さらに安全性が増す

C. Retention Policy

C-1. 保管期間の検討

1. Parameter: 保管日数 / 法定要件 (1年 / 3年 / 5年) / 監査法人からの要請

2. 推奨値 / 例:

   • “最低 90日” は短期ログ分析用 + “1年～5年” などアーカイブ保管

   • 金融・医療業界や公的機関では 3～7年保持を求められる場合も

3. 解説:

   • NIST SP 800-53 AU-11（Audit Record Retention） で「必要な期間ログを保持し、証拠を提出可能にする」

   • Immutable 期間が終了すると自動削除または書き込み可となるが、誤設定に注意

C-2. マルチ段階保存（Hot/Cool/Archive + WORM）

1. Parameter: アクセス層 (Hot / Cool / Archive), Immutable Policy, Tiering

2. 推奨値 / 例:

   • 最初の 90日 → Hot/Cool 層でアクセス解析

   • その後 “Archive” + WORM で長期保存

3. 解説:

   • コスト最適化と監査要件を両立するため、NIST CSF “Identify - Asset Management (ID.AM)” でもロギング戦略を明確化

D. ログの送信 / 連携フロー

D-1. Diagnostic Settings → Immutable Blob

1. Parameter: Azure Resource (NSG Flow Logs, Firewall, WAF, Activity Logs), Destination “Storage”

2. 推奨値 / 例:

   • “Flow Logs → Storage account: stg-nsglogs → Container: nsgflow → Time-based Retention 365 days”

   • “ApplicationGatewayFirewallLog → stg-waflogs → Container: waf → WORM 1 year”

3. 解説:

   • Log Analytics / Sentinel とは別に、追加のバックアップ として Immutable Blob に保存する方法

   • 後から監査法人対応などで取り出す際に変更不可能な証跡を提示可能

D-2. SIEM / Sentinel 連携

1. Parameter: “Sentinel Data Connector” or “Log Analytics + Additional Export”

2. 推奨値 / 例:

   • Sentinel でリアルタイム分析しつつ、Immutable Blob はアーカイブ証拠として保存

   • AU-9（Protection of Audit Information）を満たすために “Production” 環境ログは必ず Immutable

3. 解説:

   • Sentinel は一時解析・相関用、Immutable Blob は改ざん不可の証拠保管用という 2 段構えが多い

E. 運用・監査でのポイント

1. Parameter: Immutable Policy 変更時の承認フロー、Legal Hold の取り消しフロー

2. 推奨値 / 例:

   • Time-based Retention を 1 年 → 途中で下げられない設定 (強化されたポリシー)

   • 取り消しには二重承認が必要 (社内でガバナンス)

3. 解説:

   • Immutable Policy は一度有効化・設定した期間が絶対となり簡単には変更できない

   • NIST CSF “Respond (RS)” や “Recover (RC)” フェーズで証拠を改ざんされないようにするための仕組み

まとめ

証跡保全と改ざん防止を行うには、Azure Storage の Immutable Blob (WORM) 機能が非常に有効であり、NIST SP 800-53 AU-9 や NIST CSF “Detect (DE) / Respond (RS)” の要件をクリアする以下のような構成を推奨します：

1. Storage Account

   • General Purpose v2 / Blob Storage

   • LRS/GRS 選択し、災害時の冗長性も考慮

2. Immutable Container

   • Time-based Retention (例: 365日) or Legal Hold

   • “Append Writes Only” オプションでログファイルの安全追記

3. Retention Policy

   • 短期（90日） + 中長期（1年～）など段階的運用

   • 大企業・監査要件（3年～5年）にも対応

4. Azure Monitor Diagnostics

   • 各種ログ（Flow Logs, Firewall Logs, WAF Logs, Activity Logs）を Immutable Blob に送信

   • 併せて Log Analytics / Sentinel にも転送し、リアルタイム分析 + 不変アーカイブを両立

5. 監査・オペレーション

   • Immutable 期間内は削除・改変不可能 → 監査法人要請やインシデント調査時に強力な証拠

   • 取り消しには管理者多重承認を設定し、安易に変更できないガバナンスを整備

これらのパラメーターを精査することで、オンプレ移行後のクラウド上において監査ログの完全性を担保し、不正操作や障害発生時の調査に役立てる仕組みを構築できます。

​​

​

​

以下では、オンプレミス環境から Azure へ移行した際のコスト試算を行うために、どのようなパラメーター（項目）をアセスメントし、どんな手順で試算していくかを例示します。実際には企業規模やシステム要件により大きく変動しますが、NIST CSF “Identify - Governance (ID.GV)” や “Identify - Risk Assessment (ID.RA)” の視点から、コスト面も含めた移行リスク評価が必要となるケースが多いです。ここでは代表的なコスト項目と、試算フローを示します。

​

​

1. 主なコスト項目

A. Compute（仮想マシン / App Service）

1. Parameter: VM サイズ (vCPU, メモリ)、数量、稼働時間（24/7 or 一部時間帯）

2. 例:

   • 4 vCPU, 16GB RAM の Standard D4s v4 VM x 3 台、24/7 稼働

   • 1 台あたり月 $$200～$300$ 程度 → 合計 $$600～$900$

   • App Service (P1v3) 月 $$100～$200$

3. 解説:

   • 既存オンプレ物理サーバーをどのような Azure VM SKU にマッピングするかを考え、ポータルのPricing CalculatorやAzure Migrate のリフト＆シフト評価ツールで見積り

   • Dev/QA 環境はオートシャットダウンなどでコスト削減可能

B. Storage（Disk / Blob / Files）

1. Parameter: ディスク種類 (Standard HDD / SSD / Premium SSD / Ultra Disk)、Blob Storage (Hot / Cool / Archive)

2. 例:

   • VM OS ディスク: Premium SSD 128GB x 3 → 月 $$30$ 程度

   • データディスク: Standard SSD 1TB x 3 → 月 $$100$ 程度

   • Blob Storage for logs: 1TB Hot + 3TB Cool → 月 $$50~$100$ 程度

3. 解説:

   • IOPS / スループットが必要かどうかで Premium / Ultra を選ぶ

   • データアクセス頻度が低い場合、Cool / Archive レイヤーで大幅にコスト削減

   • Azure Calculator で容量やレプリケーション (LRS/GRS) を入力し、月額費を算出

C. Network（Bandwidth、ExpressRoute / VPN）

1. Parameter: 出力トラフィック(GB/月)、ExpressRoute 帯域 (50Mbps / 1Gbps etc.)、VPN SKU

2. 例:

   • Outbound データ転送 1 TB/月 → $$70~$90$

   • ExpressRoute 1Gbps ポート + Premium アドオン → $$3,000+/月$

   • VPN Gateway (VpnGw2) → $$200+/月$

3. 解説:

   • ネットワークコストは “インターネット／ExpressRoute” の帯域 + Outbound データ転送 で大きく変動

   • NIST CSF “Protect - Communications” で高可用性回線が必要なら ExpressRoute 冗長接続コストも追加

D. Database Services（SQL DB / Managed Instance / OSS DB）

1. Parameter: Azure SQL Database (DTU / vCore)、Managed Instance、PostgreSQL/MySQL “Basic / GP / Memory Optimized”

2. 例:

   • SQL Database “General Purpose, 4 vCore, 200GB storage” → $$300～$500/月$

   • Managed Instance “8 vCore, 500GB” → $$1,000+/月$

3. 解説:

   • オンプレ DB 互換性 (SQL / Oracle / PostgreSQL) で選択肢変わる

   • バックアップ保管期間 (7日～35日、Long-term retention) や HA 構成 (Zone redundant) もコストに反映

E. Additional Services（Firewall, WAF, Monitoring）

1. Parameter: Azure Firewall、Application Gateway (WAF_v2)、Defender for Cloud / Sentinel、Backup / Site Recovery

2. 例:

   • Azure Firewall Standard $$900+/月$、Premium $$1,300+/月$

   • WAF_v2 Autoscaling → min=2, max=10 インスタンス → 基本 $$200+/月 + usage$

   • Sentinel: Ingest 量 100GB/月 → $$150+/月$

   • Backup: VM 10台, 500GB 合計 → $$50~/月$

3. 解説:

   • NIST SP 800-53 で推奨される boundary protection (Firewall/WAF) や監査ログ (Sentinel) はコスト要素大

   • 監査要件が厳しいほど、ログ収集量やバックアップ保持期間が増えコストが上昇

2. 移行コスト全体の試算例

A. パラメーター例：中規模企業シナリオ

1. Compute: VM 4台 (D4s_v4), App Service 1 (P1v3)

2. Storage: Premium SSD OS 128GB x 4 + Data Standard SSD 2TB, Blob Logs 2TB (Cool)

3. Network: VPN Gateway (VpnGw2), 2TB/month outbound

4. DB: Azure SQL Database GP 4 vCore (500GB)

5. Firewall/WAF: Azure Firewall Standard, App Gateway WAF_v2 (Autoscale min=2)

6. Sentinel: Logs ~ 100GB/month

​

B. 参考月額試算

• VM (4台): $800 ~ $1,200

  • 備考: 4 x (D4s_v4: $200~$300)

• App Service (1 P1v3): $150 ~ $200

• Storage (Disk/Blob): $200 ~ $300

  • 備考: Premium SSD + Blob logs 2TB (Cool tier)

• Network (VPN Gateway): $200 ~ $300

  • 備考: VpnGw2 SKU + 2TB outbound ($70~$100)

• DB (Azure SQL 4vCore): $300 ~ $500

• Firewall (Standard): $900 ~ $1,000

• WAF (v2): $250 ~ $350

  • 備考: Autoscale min=2 (base cost + usage)

• Sentinel (100GB): $150 ~ $200

• 合計 (概算): $2,950 ~ $4,050

​

C. 補足

• 上記は概算であり、実際には予約インスタンス / Azure Hybrid Benefit の利用などで VM / SQL コストを抑制可能

• 定期的なシャットダウン（Dev/QA 環境）や Storage tier 選定を最適化することでさらにコストダウン

• NIST CSF “Identify - Risk Assessment (ID.RA)” でビジネス要件を満たすうえで必要なリソースを確定し、その後 Azure Pricing Calculator や Azure Migrate Assessment で詳細試算

3. コスト試算プロセス

1. Parameter: Azure Migrate or 3rd Party Assessment Tool, Azure Pricing Calculator, Reservation / Hybrid Benefit

2. 推奨例:

   • Azure Migrate でオンプレ VM の CPU/RAM/ディスク使用量を収集 → 推奨 SKU & コスト見積り

   • Azure Calculator で各リソースの SKU / 量 (ストレージ容量、ログ量など) を入力

3. 解説:

   • ある程度のバッファ（10～20%）を見込んだうえで初期見積りを立てる

   • 運用開始後の利用実績を監視し、オートスケールやシャットダウンなどの最適化施策でコストを調整

4. NIST CSF とコスト評価

NIST CSF はセキュリティリスク評価に重きを置きますが、コスト面も重要な要素です。特に以下の観点が関連します：

1. Identify - Risk Assessment (ID.RA)

   • ハイアベイラビリティやセキュア構成が必要なシステムほど、ExpressRoute・Firewall Premium など高コストの選択肢になる

2. Protect - Resource Management (PR.IP-4)

   • 不必要に大きいリソースを使わない、オートスケールやシャットダウンを設定して最適コスト運用する

3. Respond / Recover

   • DR 構成（Site Recovery、Geo Redundant Storage）もコストを押し上げるが、組織の事業継続リスクを軽減する投資とみなす

最終的には、セキュリティ要件と可用性・運用負荷のバランスをとりながら、コスト面でも合理的な設計を目指すアプローチが必要です。

まとめ

Azure 移行時のコスト試算では、Compute / Storage / Network / DB / Firewall / Logging といった主要なリソースを列挙し、数量・SKU・稼働時間・帯域などの具体パラメーターを洗い出す形で評価するのが基本です。以下のステップが代表的な流れです：

1. 資産・要件の棚卸し

   • オンプレに何台のサーバー / ディスク容量 / ネットワーク帯域 / DB ライセンスがあるか

2. Azure でのマッピング

   • VM SKU、Managed Disk 種類、ExpressRoute or VPN、Azure SQL or Managed Instance

3. ツール活用

   • Azure Migrate Assessment + Azure Pricing Calculator で試算

4. 見積もり結果

   • 各リソース費用 + 送信データ転送料 + ログ保管費 + (オプション) Reserved Instances, Hybrid Benefit

5. NIST CSF 絡み

   • Security コントロール強化（Firewall, Sentinel, WAF, DR）がコストに上乗せされる

   • ただしリスク軽減効果が得られ、組織のコンプライアンス要件に応えやすくなる

このアセスメント結果をもとに、企業として最適なクラウドアーキテクチャとセキュリティモデルを選定し、必要なコストを経営層に説明するという形が理想的です。

​