0
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

@handson-lab(ハンズオンラボ)

5分でわかるAWSセキュリティグループ設定ミス防止法【EC2接続できない原因トップ5】

0
Posted at

5分でわかるAWSセキュリティグループ設定ミス防止法【EC2接続できない原因トップ5】

隔週でエンジニアもくもく会、実践型ハンズオンを開催中！

私たちハンズオンラボでは、AWSの実務で直面する「EC2に接続できない」「セキュリティ設定でミスした」といった悩みを解決するための、もくもく会、実践型ハンズオンを定期開催しています。

✅ 完全ハンズオン形式で実機を触りながら学べる
✅ 現役インフラエンジニアが伴走してサポート
✅ 初心者大歓迎・仲間とつながりながらスキルアップ

興味がある方は、ぜひ一度遊びに来てください!

📍 connpassページ: [https://zeki-chan-lab.connpass.com/]

はじめに

「EC2にSSH接続できない...」
「セキュリティグループの設定を変更したら、突然インターネットに繋がらなくなった...」

こんな経験、ありませんか?

私も新人時代、セキュリティグループの設定ミスで1時間ロスしたり、本番環境で0.0.0.0/0のまま公開してセキュリティ部門から厳重注意を受けたりと、散々な目に遭ってきました。

この記事では、インフラエンジニア10年目の私が、EC2接続トラブルの原因トップ5と、それを防ぐための3つの鉄則をお伝えします。

AWS SAA資格を取得したばかりの方、実務でセキュリティグループ設定に悩んでいる方に向けて、実体験ベースで解説していきます。

セキュリティグループ設定ミス トップ5

第5位:アウトバウンドルールをすべて削除してしまった

具体的なエピソード

新人時代、セキュリティ強化のつもりで「不要なルールは削除しよう」と思い立ち、アウトバウンドルールをすべて削除したことがあります。その瞬間、EC2からインターネットへの接続がすべて遮断され、yumコマンドもcurlも動かない状態に。復旧までに30分かかりました。

なぜ困ったのか

セキュリティグループはステートフルな仕組みです。インバウンドで許可された通信の戻りは自動的に許可されますが、EC2から外部へ接続を開始する場合は、アウトバウンドルールで明示的に許可する必要があります。

デフォルトではアウトバウンドは「すべて許可(0.0.0.0/0)」ですが、これを削除すると外部との通信がすべて遮断されます。

どう解決したか

アウトバウンドルールに以下を追加しました:

タイプ プロトコル ポート範囲 送信先 説明
すべてのトラフィック すべて すべて 0.0.0.0/0 外部への接続を許可

ポイント: デフォルトのアウトバウンドルールは安易に削除しない。削除する場合は、必要な通信(HTTP/HTTPS、DNS等)を個別に許可してから削除する。

第4位:ソースIPアドレスの指定を間違えた

具体的なエピソード

自宅からEC2にSSH接続できるように、セキュリティグループのインバウンドルールに「自分のIPアドレス」を登録しました。ところが、5分後には接続できなくなってしまいました。

原因は、会社のVPN経由で接続していたため、IPアドレスが頻繁に変わっていたこと。VPNサーバーのIPアドレスを登録すべきだったのに、クライアント側のIPを登録していたのです。

なぜ困ったのか

AWSマネジメントコンソールの「マイIPを自動検出」機能は便利ですが、以下の点に注意が必要です:

  • VPN経由の場合: VPNサーバーのIPアドレスを許可する必要がある
  • 動的IPの場合: ISPによってはIPアドレスが頻繁に変わる
  • プロキシ経由の場合: プロキシサーバーのIPアドレスを許可する必要がある

どう解決したか

接続環境を正確に把握し、適切なIPアドレスを登録しました。

確認コマンド:

# 自分の現在のグローバルIPアドレスを確認
curl ifconfig.me

オプション解説:

  • なし(このコマンドにオプションは不要)

VPN経由の場合の対応:

  1. VPN管理者にVPNサーバーのIPアドレスを確認
  2. そのIPアドレス(またはCIDR範囲)をセキュリティグループに登録
  3. 接続テストを実施

ポイント: 「マイIPを自動検出」は便利だが、VPNやプロキシ環境では要注意。必ずcurl ifconfig.meで確認を。

第3位:インバウンドルールにSSH(ポート22)を追加し忘れた

具体的なエピソード

新人時代、初めてEC2インスタンスを構築した時のことです。セキュリティグループを新規作成し、意気揚々とSSH接続を試みたところ、接続タイムアウト。1時間調べ回って、ようやくインバウンドルールにSSH(ポート22)を追加し忘れていたことに気づきました。

なぜ困ったのか

セキュリティグループはデフォルトですべて拒否の設計思想です。新規作成したセキュリティグループには、何もルールが設定されていません。つまり、インバウンドルールを明示的に追加しない限り、外部からの通信はすべてブロックされます。

初心者の頃は、「EC2を起動すれば接続できる」と思い込んでいましたが、セキュリティグループの設定が必須だと学びました。

どう解決したか

インバウンドルールにSSHを追加しました:

タイプ プロトコル ポート範囲 ソース 説明
SSH TCP 22 [自分のIP]/32 自宅からのSSH接続を許可

AWS CLIでの確認コマンド:

# セキュリティグループのルールを確認
aws ec2 describe-security-groups \
  --group-ids sg-xxxxxxxxx \
  --query 'SecurityGroups[0].IpPermissions'

オプション解説:

  1. --group-ids: 確認したいセキュリティグループのIDを指定
  2. --query: 出力結果をJMESPath形式でフィルタリング(インバウンドルールのみ表示)

ポイント: EC2作成時は、セキュリティグループのインバウンドルールを必ず確認。SSH/RDP等の接続ポートが開いているかチェックする。

第2位:0.0.0.0/0で全世界に公開してしまった

具体的なエピソード

これは最もやってしまいがちなミスです。私も初めてRDP(リモートデスクトップ)を設定した際、「とりあえず接続できればいいか」と思って、ソースを0.0.0.0/0(全世界からアクセス可能)に設定してしまいました。

その日のうちにセキュリティ部門から連絡があり、「全世界に3389番ポートを開放しているサーバーがある」と指摘されました。幸い本番環境ではなかったものの、冷や汗をかいた経験です。

なぜ困ったのか

0.0.0.0/0は「すべてのIPアドレスからアクセス可能」という意味です。SSH(22番)やRDP(3389番)といった管理ポートを全世界に公開すると、以下のリスクがあります:

  • ブルートフォース攻撃: 世界中からパスワード総当たり攻撃を受ける
  • 脆弱性スキャン: セキュリティホールを探す自動ツールのターゲットになる
  • 不正アクセス: 侵入されるとデータ漏洩や改ざんのリスク

どう解決したか

管理ポートは、必ず接続元IPアドレスを限定しました:

タイプ プロトコル ポート範囲 ソース 説明
SSH TCP 22 203.0.113.0/24 社内ネットワークからのみ許可
RDP TCP 3389 203.0.113.0/24 社内ネットワークからのみ許可
HTTP TCP 80 0.0.0.0/0 Webサーバーなので全世界に公開OK
HTTPS TCP 443 0.0.0.0/0 Webサーバーなので全世界に公開OK

セキュリティグループのベストプラクティス:

  • 管理ポート(SSH/RDP)は絶対に0.0.0.0/0にしない
  • 接続元IPを/32(単一IP)または/24(クラスC範囲)で限定
  • 本当に全世界公開が必要なのは、WebサーバーのHTTP/HTTPSくらい

ポイント: 0.0.0.0/0は「とりあえず」で使わない。管理ポートは必ず接続元を限定する。

第1位:セキュリティグループの変更履歴を確認できず原因特定に時間がかかった

具体的なエピソード

これが最も困ったパターンです。ある日、EC2への接続が突然できなくなりました。前日まで問題なく接続できていたのに、何が変わったのか全くわかりません。

セキュリティグループの設定を確認しても、どこが変更されたのか分からず、原因特定に半日かかりました。後で知ったのですが、AWSにはCloudTrailというサービスがあり、誰がいつセキュリティグループを変更したかの履歴を確認できることを知りました。

なぜ困ったのか

セキュリティグループは、複数人で管理している場合、誰かが意図せず変更してしまうことがあります。しかし、AWSマネジメントコンソールの画面だけでは、変更履歴や変更者を確認できません。

変更履歴を確認するには、以下のいずれかが必要です:

  • AWS CloudTrail: API呼び出しのログを記録するサービス
  • AWS Config: リソースの設定変更履歴を追跡するサービス

どう解決したか

CloudTrailで変更履歴を確認する方法:

  1. CloudTrailコンソールを開く
  2. イベント履歴を選択
  3. フィルタ条件を設定:
    • イベント名: AuthorizeSecurityGroupIngress(インバウンドルール追加)
    • イベント名: RevokeSecurityGroupIngress(インバウンドルール削除)
    • イベント名: AuthorizeSecurityGroupEgress(アウトバウンドルール追加)
    • イベント名: RevokeSecurityGroupEgress(アウトバウンドルール削除)

AWS CLIでの確認方法:

# 過去24時間のセキュリティグループ変更履歴を取得
aws cloudtrail lookup-events \
  --lookup-attributes AttributeKey=ResourceType,AttributeValue=AWS::EC2::SecurityGroup \
  --start-time $(date -u -d '1 day ago' +%Y-%m-%dT%H:%M:%S) \
  --max-results 50

オプション解説:

  1. --lookup-attributes: 検索条件を指定(ここではEC2セキュリティグループのイベントに絞り込み)
  2. --start-time: イベント検索の開始時刻(ISO 8601形式)
  3. --max-results: 取得する最大イベント数(1〜50)

ポイント: CloudTrailは必ず有効化しておく。変更履歴が追跡できないと、トラブルシューティングが困難になる。

セキュリティグループ設定ミス防止の3つの鉄則

鉄則1:最小権限の原則を徹底する

セキュリティグループの設定では、必要最小限の権限のみ許可するのが鉄則です。

チェックリスト:

  • 0.0.0.0/0は本当に必要か?(管理ポートは絶対NG)
  • ソースIPは/32または/24で限定できないか?
  • ポート範囲は最小限に絞れないか?(22番だけ、443番だけ等)
  • アウトバウンドルールは必要な通信のみに限定しているか?

鉄則2:命名規則とタグを活用する

セキュリティグループが増えてくると、どれがどのサーバー用か分からなくなります。

推奨命名規則:

  • [環境]-[サービス名]-[役割]-sg
  • 例: prod-web-alb-sg(本番環境のWebサーバーALB用)
  • 例: dev-db-rds-sg(開発環境のRDS用)

タグの活用:

Key: Environment / Value: Production
Key: Service / Value: WebServer
Key: Owner / Value: infra-team

鉄則3:変更前にバックアップ、変更後に接続確認

セキュリティグループを変更する前に、必ず現在の設定をメモしておきましょう。

変更手順:

  1. 変更前: 現在のルールをスクリーンショットまたはテキストで保存
  2. 変更実施: ルールを追加/変更
  3. 接続確認: 即座にSSH/RDP接続をテスト
  4. 問題発生時: 即座に元の設定に戻す

AWS CLIでのバックアップ例:

# セキュリティグループの設定をJSON形式で保存
aws ec2 describe-security-groups \
  --group-ids sg-xxxxxxxxx \
  > sg-backup-$(date +%Y%m%d).json

オプション解説:

  1. --group-ids: バックアップしたいセキュリティグループのIDを指定
  2. > sg-backup-$(date +%Y%m%d).json: 出力を日付付きファイルにリダイレクト

トラブル時の確認手順(5ステップ)

EC2に接続できない時は、以下の順番で確認しましょう:

ステップ1:セキュリティグループのインバウンドルールを確認

  • SSH(22番)またはRDP(3389番)が許可されているか?
  • ソースIPは正しいか?(VPN経由の場合はVPNサーバーのIP)

ステップ2:ネットワークACL(NACL)を確認

セキュリティグループとは別に、**NACL(ネットワークアクセスコントロールリスト)**という仕組みがあります。NACLはサブネット単位でトラフィックを制御します。

セキュリティグループとNACLの違い:

項目 セキュリティグループ NACL
適用範囲 インスタンス単位 サブネット単位
ステート ステートフル(戻りは自動許可) ステートレス(明示的に許可必要)
ルール評価 すべてのルールを評価 番号順に評価(最初にマッチしたルールを適用)
デフォルト すべて拒否 すべて許可

ステップ3:EC2インスタンスの状態を確認

  • インスタンスは起動中(running)か?
  • ステータスチェックは2/2パスしているか?

ステップ4:ルートテーブルを確認

  • インターネットゲートウェイへのルート(0.0.0.0/0)が設定されているか?

ステップ5:CloudTrailで変更履歴を確認

  • 誰がいつセキュリティグループを変更したか?
  • 変更内容は何か?

まとめ

この記事では、AWSセキュリティグループの設定ミストップ5と、ミス防止の3つの鉄則をお伝えしました。

設定ミストップ5:

  1. 変更履歴を確認できず原因特定に時間がかかる → CloudTrailを有効化
  2. 0.0.0.0/0で全世界に公開 → 管理ポートは接続元IP限定
  3. SSH(ポート22)を追加し忘れ → インバウンドルール確認
  4. ソースIPの指定ミス → VPN経由の場合は要注意
  5. アウトバウンドルール削除 → デフォルト設定を理解する

3つの鉄則:

  1. 最小権限の原則を徹底
  2. 命名規則とタグを活用
  3. 変更前にバックアップ、変更後に確認

セキュリティグループは、AWSの最も基本的なセキュリティ機能ですが、設定ミスでトラブルになるケースが非常に多いです。この記事で紹介した5つのパターンを知っていれば、9割のトラブルは防げるはずです。

もし今、セキュリティグループの設定で困っていたら、ぜひこの記事を参考にしてみてください。そして、実際に手を動かして確認してみることをお勧めします!

一緒に学びませんか?

ハンズオンラボでは、AWSの実践的なスキルを身につけるためのハンズオン実習を定期開催しています。

「セキュリティグループの設定を実機で試してみたい」
「他の参加者と一緒に学びたい」
「現役エンジニアにその場で質問したい」

そんな方は、ぜひ一度遊びに来てください!

✅ 完全ハンズオン形式で実機を触りながら学べる
✅ 現役インフラエンジニアが伴走してサポート
✅ 初心者大歓迎・仲間とつながりながらスキルアップ

📍 connpassページ: [https://zeki-chan-lab.connpass.com/]

関連リンク

0
1
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
0
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?