クラウドのネットワークセキュリティ

なぜネットワーク境界がまだ重要なのか

「アイデンティティが新しい境界線」という考え方が広まった一方で、ネットワーク層の制御は依然として重要な多層防御の1枚です。IAMの権限設計がどれだけ厳格でも、データベースポートが0.0.0.0/0に開放されていれば、認証をバイパスした直接攻撃や、脆弱なミドルウェアへのエクスプロイトが成立してしまいます。ネットワークセグメンテーションは、1つの制御が突破された場合の被害範囲を限定する「爆発半径(Blast Radius)」の縮小に直結します。

典型的なネットワークセグメンテーション

Webアプリケーションを例にした典型的な3層構成です。インターネットからのトラフィックはロードバランサーで受け、パブリックサブネットとプライベートサブネットを分離し、データベースはさらに隔離されたサブネットに配置します。各層の境界でSecurity Group/NSG/Firewall Ruleによるチェックポイントを設けます。

パブリックサブネットには本来ロードバランサーやNAT Gatewayのみを配置し、アプリケーションのワークロードやデータベースはインターネットから直接到達できないプライベートサブネットに隔離するのが原則です。

主要概念とAWS/Azure/GCPの対応

よくある設定ミス

• 機密ポートを0.0.0.0/0へ開放 High Risk

  SSH(22)、RDP(3389)、MySQL(3306)などの管理・データベースポートが、インターネット全体からのアクセスを許可した状態で本番に残る。

• フラットなネットワーク構成 High Risk

  Web層・アプリ層・データ層がセグメンテーションされておらず、1台の侵害がネットワーク全体への横展開を許してしまう。

• デフォルトVPCの利用継続 Medium Risk

  アカウント作成時に自動生成されるデフォルトVPCをそのまま本番ワークロードで利用し、意図しないパブリックサブネット構成のまま運用される。

• VPC Flow Logsの未有効化 Medium Risk

  VPC Flow Logs/NSG Flow Logs/Firewall Rules Loggingが有効化されておらず、通信の可視性がなく異常なトラフィックを検知できない。

• PaaS接続時のパブリックエンドポイント依存 Medium Risk

  マネージドDBやオブジェクトストレージへの接続を、VPC Endpoint/Private Link/Private Service Connectを使わずパブリックインターネット経由のまま構成している。

攻撃シナリオ: 開放されたポートへの直接接続

攻撃者が対象組織のパブリックIPレンジをポートスキャンし、インターネットに開放されたデータベースポートを発見する、という想定です。

1. 対象のパブリックIPレンジに対してポートスキャンを実施する。
2. SSH/RDP/MySQLなど、本来インターネットに公開すべきでないポートの開放を発見する。
3. クラウド側の設定情報を(漏洩した認証情報などから)確認し、どのSecurity Groupが該当ポートを0.0.0.0/0に開放しているかを特定する。
4. 開放されたポートへ直接接続を試み、認証情報の総当たりやデフォルト資格情報での侵入を試みる。

# 1. 対象IPに対する主要ポートのスキャン
$ nmap -p 22,3389,3306 203.0.113.10

# 2. 開放が確認できたポートへの直接接続を試行
$ mysql -h 203.0.113.10 -u root -p

# 3. (漏洩認証情報を保持している場合)0.0.0.0/0を許可しているSecurity Groupを特定
$ aws ec2 describe-security-groups --filters Name=ip-permission.cidr,Values=0.0.0.0/0

# 4. 該当グループが紐づくインスタンス/RDSを列挙し攻撃対象を絞り込む
$ aws ec2 describe-instances --filters Name=instance.group-id,Values=sg-0123456789abcdef0

検知

VPC Flow Logs / NSG Flow Logs / GCP Firewall Rules Loggingを有効化し、想定外のポート・送信元からの通信を継続的に監視します。

• 管理ポート(22/3389)やDBポート(3306/5432等)への、社内IPレンジ以外からの接続試行。
• 普段トラフィックのないパブリックサブネットからプライベートサブネットへの予期しない通信。
• GuardDutyのUnauthorizedAccess:EC2/SSHBruteForceやRecon:EC2/PortProbeUnprotectedPort、Microsoft Defender for CloudやGoogle Security Command Centerのネットワーク関連ファインディング。

SELECT srcaddr, dstaddr, dstport, action, COUNT(*) AS attempts
FROM vpc_flow_logs
WHERE dstport IN (22, 3389, 3306, 5432)
  AND action = 'REJECT'
  AND start_time > date_sub(now(), 1h)
GROUP BY srcaddr, dstaddr, dstport, action
ORDER BY attempts DESC;

是正

広範囲に開放されたルールを特定のCIDRへ絞り込み、さらに可能な場合はインターネット経由の直接アクセス自体を廃止してSSM Session Manager等の踏み台経由に切り替えます。

# 0.0.0.0/0からのSSH許可ルールを取り消す
$ aws ec2 revoke-security-group-ingress --group-id sg-0123456789abcdef0 --protocol tcp --port 22 --cidr 0.0.0.0/0

# 社内/踏み台のCIDRのみを許可する狭いルールを追加
$ aws ec2 authorize-security-group-ingress --group-id sg-0123456789abcdef0 --protocol tcp --port 22 --cidr 203.0.113.0/28

# 直接SSHをやめ、SSM Session Manager経由のアクセスに切り替える
$ aws ssm start-session --target i-0abcdef1234567890

実際に手を動かす

このページで扱った「0.0.0.0/0に開放されたSecurity Group」の検出と是正を、実際のシナリオ形式で体験できます。Scenario → Architecture → CLI Commands → Misconfiguration → Detection → Remediation → Verificationの流れで、スキャンから是正確認までを一通り実施します。

実装チェックリスト

• SSH(22)/RDP(3389)/DBポート等の機密ポートが0.0.0.0/0に開放されていない
• VPC Flow Logs / NSG Flow Logs / Firewall Rules Loggingがすべてのネットワークで有効化されている
• パブリックサブネットとプライベートサブネットが明確にセグメンテーションされている
• デフォルトVPCが本番ワークロードで利用されていない
• 管理アクセスが直接SSH/RDPではなく、SSM Session Manager等の踏み台/ブローカー経由になっている
• データベース等のデータ層サブネットにはインターネットからの直接経路(IGWルート)が存在しない
• PaaSサービスへの接続にVPC Endpoint/Private Link/Private Service Connectを利用し、パブリックインターネット経由を避けている
• Security Group/NSG/Firewall Ruleの定期棚卸しが運用プロセスとして組み込まれている