0.0.0.0/0 という「死の門」を閉ざせ：AWSインフラを自動防御する泥臭い実戦論
エンジニア諸君、現場の運用は順調か？
「とりあえず疎通確認のために0.0.0.0/0を開けておいた」――その一言が、数年後に悪夢のようなインシデントの引き金になる。私がこれまで見てきた侵入事件の8割は、こうした「一時的な開放」の放置から始まっている。
暗号技術がどれほど堅牢でも、玄関の鍵を開けっ放しにしては意味がない。今日は、AWSのセキュリティグループ（SG）における「0.0.0.0/0」という脆弱性の正体と、それを人間が監視するのではなく、コードでねじ伏せるための戦術を共有する。
—
1. なぜ「0.0.0.0/0」が全エンジニアの敵なのか
攻撃者は常にスキャンしている。nmapやmasscanといったツールを使えば、地球上の全IPアドレスのポート開放状態を数時間でなめ尽くすことは容易だ。
もし君たちのSSH（22番）やRDP（3389番）、あるいは未設定の管理画面がインターネットに晒されていれば、攻撃者は「ブルートフォース攻撃」を開始する。ここでRSAやECDSAといった公開鍵暗号の強度が試されることになるが、そもそも「攻撃者に認証の機会すら与えない」ことこそが、最強の防衛だ。
攻撃者の視点：PoCの一例
攻撃者はまず、ターゲットのIP範囲に対してTCP接続を試みる。
# 攻撃者がターゲットのポートをスキャンする様子
nmap -p 22,80,443,3306,6379 1.2.3.4/24 --openもしここで、DBポート（3306）やRedis（6379）が公開されていれば、次は辞書攻撃や既知の脆弱性を突くスクリプトが自動で走り出す。0.0.0.0/0の開放は、自ら「ここに脆弱な扉がありますよ」と看板を掲げているのと同じだ。
—
2. 自動監査の要：AWS Configで「設定漏れ」を物理的に消す
人間はミスをする。だからこそ、仕組みで縛る。AWS Configの「マネージドルール」を使えば、セキュリティグループの違反を検知し、自動修復（Remediation）を走らせることが可能だ。
設定の勘所
AWS Configのルール restricted-common-ports を有効化し、以下のパラメータを適用する。
- ルール名:
restricted-common-ports - 対象ポート:
22, 3389, 27017, 6379（これらは絶対に外に晒してはならない）
しかし、これだけでは足りない。特定のアプリ用ポートなどは独自ルールが必要になる。そんな時は、AWS Lambdaを使ったカスタムRemediationが最強の武器になる。
—
3. 【実践】違反SGを自動で剥ぎ取るLambda関数（Python）
以下のコードは、AWS Configが「0.0.0.0/0を許可しているSG」を検知した瞬間に、対象のルールを削除（または拒否）するスクリプトだ。これをLambdaに載せれば、深夜のデプロイミスも即座に無効化できる。
import boto3
ec2 = boto3.client('ec2')
def lambda_handler(event, context):
# AWS Configからイベント情報を受け取る
invoking_event = event['invokingEvent']
configuration_item = event['configurationItem']
sg_id = configuration_item['configuration']['groupId']
# 0.0.0.0/0 を許可しているセキュリティグループを特定し、ルールを削除する
# ※本番投入時は、特定のSG IDのみに絞るか、ホワイトリスト判定を入れること
try:
ec2.revoke_security_group_ingress(
GroupId=sg_id,
IpPermissions=[
{
'IpProtocol': 'tcp',
'FromPort': 22,
'ToPort': 22,
'IpRanges': [{'CidrIp': '0.0.0.0/0'}]
}
]
)
print(f"セキュリティ違反を検知: {sg_id} の 22番ポートを閉鎖しました。")
except Exception as e:
print(f"エラー発生: {e}")運用上の注意点:
このスクリプトをいきなり本番環境で「自動削除モード」にするな。まずは「通知（SNS）」だけ飛ばすモードで運用し、安全を確認してから削除アクションを有効にすること。
—
4. 最後に：暗号理論と境界防御のバランス
RSAやECDSAを用いた公開鍵暗号は、通信の「中身」を守る。しかし、境界防御（SG設定）は「箱」そのものを守る。
- Webアプリ開発者へ: 認証基盤には必ずJWT（JSON Web Token）やOAuth 2.0を導入し、暗号学的署名を検証すること。
- インフラエンジニアへ: 「信頼できるIPのみを許可する」という原則を徹底し、どうしても外部アクセスが必要な場合は、AWS WAFやVPN（AWS Client VPN / Systems Manager Session Manager）を介在させ、直接的なポート開放を排除せよ。
0.0.0.0/0は、利便性と引き換えにセキュリティを投げ捨てる行為だ。その「利便性」を、SSM Session Managerのようなセキュアな手段に置き換えることこそ、プロのエンジニアの仕事だ。
現場からは以上だ。君たちのインフラが、鉄壁であることを願っている。
コメント