【入門編】 AWS Security Groupのインバウンドルールにおける0.0.0.0/0制限と自動監査 – 暗号理論・認証基盤 & エンドポイントセキュリティ防御ガイド

こんにちは！インフラやセキュリティの世界へようこそ。
初めてクラウドを触る時、「とりあえずどこからでもアクセスできるようにしよう！」と、AWSのセキュリティグループで 0.0.0.0/0（世界中のどこからでも）という設定にしてしまった経験はありませんか？

実はこれ、現実の世界にたとえると「自宅の玄関の鍵を全開にしたまま、表札に『どうぞお入りください』と貼り紙をしている状態」なんです。

今回は、なぜこの 0.0.0.0/0 の開放が危険なのか、そしてそれをどうやって自動で監視・見つけてお尻を叩いてくれる（修正する）のかを、身近な防犯の仕組みに例えながら、一歩ずつ優しく紐解いていきましょう！

—

1. 家の鍵で考える「セキュリティグループ」と 0.0.0.0/0 の恐怖

クラウドの世界における「セキュリティグループ」は、あなたのサーバー（仮想的なお家）の周りにある頑丈な門のようなものです。

通常、この門では「誰が中に入ることを許可するか」というルールを決めます。

会社のIPアドレスからだけ通す（信頼できる家族だけ）
データベースには、特定のWebサーバーからだけ通す（お隣さんだけ）

しかし、ここに 0.0.0.0/0 という設定を入れてしまうとどうなるでしょうか？
これは、「世界中のあらゆる人間、もちろん善意の人もいれば、サイバー泥棒も含めて、誰でも我が家のリビングに自由に出入りしていいですよ」と宣言しているのと同じことになります。

攻撃者はどうやってあなたのサーバーを見つけるのか？

泥棒は、あなたの家を一つずつノックして回るわけではありません。「全自動のバール」のようなツールを使って、インターネットの海全体を常にスキャンしています。
「おっ、あそこの家のデータベース用のポート（例えば 3306 や 5432）が、誰でも入れる状態で開いているぞ！」と見つかった瞬間、パスワード総当たり攻撃（ブルートフォース攻撃）や、システムの隙を突いた攻撃が始まります。

「テスト環境だから大丈夫」「まだ中身が入っていないからいいか」という油断が、踏み台にされて企業全体のインシデントに繋がる……これが現場で本当によくある事故なんです。

—

2. 人間はミスをする。だから「自動番犬（AWS Config）」を飼おう！

「よし、これからは気をつけよう！」と思っても、人間はうっかりミスをする生き物です。「急ぎの案件だったから、ついテスト用に一時的に開けっぱなしにして、そのまま忘れて帰ってきちゃった……」なんてことは、ベテランのエンジニアでもやってしまいがちです。

そこで登場するのが、AWS Config という自動おまわりさん（自動番犬）です。

AWS Configは、あなたのAWS環境にあるセキュリティグループが「安全なルールを守っているか」を24時間体制で監視し続けてくれます。「おや、このセキュリティグループ、誰でもアクセスできる 0.0.0.0/0 になってるぞ！」と見つけると、即座に「危ないよ！」とアラートを出したり、自動で元の安全な状態に戻してくれたりします。

—

3. 実践！AWS Configで不要なポート開放を検知・修正する設定

それでは、実際にどうやってこの自動番犬を配置するのか、具体的な設定を見ていきましょう。
難しく考えず、「こういう仕組みで守られているんだな」という雰囲気を掴んでいただければバッチリです！

ステップ1: AWS Configの標準ルールを有効化する

AWSには、あらかじめ用意された便利な「セキュリティの検査キット」がたくさんあります。その中の一つである restricted-incoming-traffic（受信トラフィックの制限）というルールを使います。

AWSマネジメントコンソールからAWS Configを開き、次のような設定でルールを追加します。

{
  "ConfigRuleName": "check-restricted-incoming-traffic",
  "Source": {
    "Owner": "AWS",
    "SourceIdentifier": "RESTRICTED_INCOMING_TRAFFIC"
  },
  "InputParameters": {
    "blockedPorts": "22,3306,5432" 
    /* 外部に絶対に公開してはいけない危険なポート（SSHやデータベース等）を指定します */
  }
}

このルールを設定しておくと、もし誰かが指定したポートに対して 0.0.0.0/0（全開放）のルールを追加した瞬間に、AWS Configが「非準拠（ルール違反）」の判定を下してくれます。

ステップ2: 自動で修正（修復）する仕組みを組む

「見つかるだけじゃなくて、勝手に直してほしい！」という場合は、AWS Systems Manager (SSM) Automation と組み合わせます。

ルール違反が検知されたときにトリガーされる、自動修復用のスクリプト（CloudWatch EventsやEventBridge経由で実行されるイメージ）の例を見てみましょう。

import boto3

def lambda_handler(event, context):
    """
    AWS Configで「非準拠」と判定されたセキュリティグループを自動的に修正するLambdaのサンプルコード
    """
    ec2 = boto3.client('ec2')
    
    # イベントからセキュリティグループのIDを取得
    # （実際にはConfigの通知から対象のリソースIDを抽出します）
    group_id = "sg-0123456789abcdef0"
    
    print(f"警告: セキュリティグループ {group_id} で不適切なオープンポートが検知されました。修正を開始します。")
    
    try:
        # 危険なインバウンドルール（0.0.0.0/0からのアクセス）を削除する処理
        response = ec2.revoke_security_group_ingress(
            GroupId=group_id,
            IpPermissions=[
                {
                    'IpProtocol': 'tcp',
                    'FromPort': 22, # 例としてSSH(22番)を指定
                    'ToPort': 22,
                    'IpRanges': [{'CidrIp': '0.0.0.0/0'}]
                }
            ]
        )
        print("セキュリティグループの修正が完了しました。0.0.0.0/0のルールが削除されました。")
        
    except Exception as e:
        print(f"エラーが発生しました: {str(e)}")

このように、人間がうっかり 0.0.0.0/0 で穴を開けてしまっても、システムの番犬が即座に見つけて塞いでくれる。これが、モダンなインフラストラクチャにおける堅牢化の姿です。

—

まとめ：一歩ずつ、安全なインフラを作っていきましょう！

今回は、AWS Security Groupの 0.0.0.0/0 制限と、AWS Configを用いた自動監査についてお話しました。

0.0.0.0/0 の開放は、家の鍵を全開にするようなもの。
人間のうっかりミスは必ず起きるので、AWS Configなどの「自動の番犬」に監視を任せる。
危険な設定を見つけたら、アラートを出したり自動で塞いだりする仕組みを作る。

最初は覚えることが多くて大変に感じるかもしれませんが、「安全な設定ってどうやるんだっけ？」と一歩ずつ確認しながら進めていけば大丈夫です。一緒に、安心で安全なクラウドの世界を作っていきましょう！