1. EC2ポート設定とSecurity Hub連携によるセキュリティ強化の全体像
    1. 責任共有モデルとEC2のセキュリティ責任
    2. Security Hubが果たす統合的な役割
    3. なぜポート管理がセキュリティの要となるのか
  2. EC2ポート設定の具体的なステップ：25番ポート申請から主要ポート開放まで
    1. ポート25（SMTP）の特殊な取り扱いと申請プロセス
    2. 一般的なWebサービスにおける主要ポート開放手順
    3. ポート設定変更後のSecurity Hubによる確認とベストプラクティス
  3. 利用状況別EC2ポート設定例とSecurity Hubによる具体的な監視ポイント
    1. Webアプリケーションサーバー向けポート設定と監視
    2. データベースサーバー向けポート設定と監視
    3. 開発・テスト環境向けポート設定と監視
  4. EC2ポート管理とSecurity Hub運用で避けるべき一般的な落とし穴
    1. 不要なポートの開放放置によるセキュリティリスク
    2. 広範囲なIPアドレスからのアクセス許可
    3. Security Hub導入後の運用形骸化の回避策
  5. 【ケース】予期せぬポート開放が発覚しSecurity Hubで改善した事例
    1. 架空のケーススタディ：開発環境での誤ったポート開放
    2. Security Hubによる問題の検出と警告
    3. 改善策と再発防止のための運用改善
  6. まとめ
  7. よくある質問
    1. Q: EC2の25番ポートを使うには申請が必要ですか？
    2. Q: Security HubのEC2関連の検出項目には何がありますか？
    3. Q: EC2で80番ポートや443番ポートを開放する際の注意点は？
    4. Q: EC2で「502 Bad Gateway」が発生する主な原因は何ですか？
    5. Q: Security Hub EC2 2などの検出結果はどう対応すべきですか？

EC2ポート設定とSecurity Hub連携によるセキュリティ強化の全体像

責任共有モデルとEC2のセキュリティ責任

AWSにおけるセキュリティは「責任共有モデル」に基づいており、クラウド基盤そのものの安全性はAWSが確保します。しかし、EC2インスタンスの設定、特にポート開放やゲストOSの管理など「クラウド内のセキュリティ」はユーザーの責任範囲です。この認識は、セキュアなシステム構築の出発点となります。外部からのサイバー攻撃は依然として高い頻度で発生しており、総務省の調査（令和6年版 情報通信白書）によれば、2023年時点では日本の各IPアドレスに対して約14秒に1回もの攻撃通信が観測されています。このような状況下で、ユーザーが自身の責任範囲を理解し、適切なセキュリティ対策を講じることの重要性は計り知れません。

EC2インスタンスのポート設定は、不正アクセスを防ぐための第一の防御線とも言えます。不要なポートを開放することは、攻撃者に対して意図せず侵入口を提供してしまうリスクを伴います。したがって、必要なポートのみを最小限に、かつ厳格なアクセス制限のもとで開放することが、EC2セキュリティの基本原則となります。この原則を遵守することで、潜在的な攻撃経路を大幅に削減し、システム全体のセキュリティレベルを向上させることが可能です。

Security Hubが果たす統合的な役割

AWS Security Hubは、複数のセキュリティサービスから得られる検出結果を一元的に管理し、セキュリティ態勢を可視化するための統合セキュリティ管理サービスです。Amazon GuardDuty（脅威検出）、Amazon Inspector（脆弱性管理）など、AWSが提供する多様なセキュリティサービスからのシグナルを自動的に集約し、標準化された形式で提示します。これにより、セキュリティイベントの監視と対応にかかる運用負担を大幅に軽減することが可能です。

Security Hubは、集約された情報を基にリスクの重大度（Critical, High, Medium, Lowなど）を自動で評価し、対応の優先順位を明確に示します。これにより、セキュリティ担当者は膨大なアラートの中から本当に対応すべき脅威に迅速に焦点を当てることができます。さらに、AWSのセキュリティベストプラクティスに基づいた設定ミスをリアルタイムで自動チェックする機能も備えており、2025年10月3日時点では、333項目ものセキュリティコントロールを提供しています。これにより、継続的なコンプライアンス遵守とセキュリティ設定の最適化を支援し、ユーザーの運用を強力にバックアップします。

なぜポート管理がセキュリティの要となるのか

EC2インスタンスにおけるポート管理は、外部からの不正アクセスを防ぐ上で極めて重要な役割を担います。ポートとは、サーバーが外部と通信するための「窓口」のようなものであり、この窓口が開いたままだと、意図しないアクセスや悪意のある攻撃を受けやすくなります。例えば、WebサーバーであればHTTP（80番）やHTTPS（443番）ポートを開放する必要がありますが、これ以外の不要なポート、特に管理用ポート（SSHの22番、RDPの3389番など）をインターネット全体に開放してしまうと、ブルートフォースアタックや脆弱性を突いた攻撃の標的となりかねません。

セキュリティの基本原則である「最小権限の原則」は、ポート管理にも当てはまります。必要最低限のポートのみを開放し、さらにアクセス元IPアドレスを限定することで、攻撃のリスクを大幅に低減できます。Security Hubは、このようなセキュリティグループの設定ミスや、広範囲なIPアドレスからのアクセス許可を自動的に検出し、警告を発する機能を持っています。これにより、ヒューマンエラーによる設定ミスを早期に発見し、迅速な修正を促すことが可能となり、EC2インスタンスを外部の脅威から守るための堅牢な基盤を築くことができるのです。

出典：令和6年版 情報通信白書（総務省 / 2024年調査時点）、AWS Security Hubにおける「重大」な検出結果と運用を理解しよう（AWS公式ドキュメントおよび関連解説 / 2026年1月6日更新時点）

EC2ポート設定の具体的なステップ：25番ポート申請から主要ポート開放まで

ポート25（SMTP）の特殊な取り扱いと申請プロセス

AWSでは、スパムメール送信防止のため、EC2の25番ポート（SMTP）はデフォルトで制限されています。これは、AWSプラットフォーム全体の健全性を保ち、悪用を防ぐための重要な措置です。そのため、EC2インスタンスから直接メールを送信する必要がある場合でも、まずはAmazon Simple Email Service (SES) などのAWSのマネージドサービスを利用することを強く推奨します。SESは高い到達性やスケーラビリティ、送信監視機能を提供するため、メール送信のベストプラクティスと言えます。

もし、どうしてもEC2から直接25番ポート経由でメールを送信する必要がある場合、AWSの「Eメール送信制限解除リクエスト」フォームから申請を行うことで、制限解除を検討してもらえる可能性があります。申請時には、具体的な使用目的、送信元IPアドレス、迷惑メールを防止するための技術的対策（例: 送信元の限定、ログ監視、SPF/DKIM設定など）を詳細に記載する必要があります。ただし、解除は「スパム送信を助長しない」ことを前提に行われ、万が一自社環境が踏み台にされスパムが送信された場合、AWSアカウント停止などのリスクがあるため、通信経路の厳格な制限が前提となります。

一般的なWebサービスにおける主要ポート開放手順

EC2インスタンスでWebアプリケーションを運用する場合、一般的なWebサーバーに必要なポートを開放する必要があります。主なポートとその役割は以下の通りです。

  • HTTP (80番ポート): 暗号化されていないWeb通信に使用されます。
  • HTTPS (443番ポート): SSL/TLSによる暗号化されたWeb通信に使用されます。現在ではセキュリティのためHTTPSの使用が標準です。
  • SSH (22番ポート): Linuxインスタンスへのリモート管理接続に使用されます。
  • RDP (3389番ポート): Windowsインスタンスへのリモートデスクトップ接続に使用されます。

これらのポートを開放する際は、以下の手順でセキュリティグループを設定します。まず、EC2コンソールで該当のインスタンスを選択し、「セキュリティグループ」の設定を確認します。新しいインバウンドルールを追加する際には、プロトコル（TCP）、ポート範囲（例: 80, 443, 22）、ソース（アクセス元）を指定します。特に管理用ポートであるSSH（22番）やRDP（3389番）は、必ず自社の固定IPアドレスや、VPN経由のアクセス元IPアドレスに限定し、「0.0.0.0/0」（インターネット全体）からのアクセスは絶対に許可しないように徹底してください。これにより、不正アクセスリスクを大幅に低減できます。

ポート設定変更後のSecurity Hubによる確認とベストプラクティス

EC2インスタンスのポート設定（セキュリティグループルール）を変更した後は、その設定がAWSのセキュリティベストプラクティスに準拠しているか、Security Hubで確認することが重要です。Security Hubは、セキュリティグループに関する設定ミスや、広範囲なアクセス許可といった潜在的なリスクを自動的に検出し、アラートとして通知します。

具体的には、Security Hubのコンソールで「検出結果」セクションを確認し、セキュリティグループに関する「重大」または「高」の検出結果がないかをチェックします。例えば、「EC2.SecurityHub.2: Security groups should not allow unrestricted incoming traffic to ports commonly used for administrative access」のような項目が検出された場合、管理ポート（SSH 22、RDP 3389など）が「0.0.0.0/0」からのアクセスを許可している可能性が高いです。このような検出結果が見つかった場合は、速やかにセキュリティグループのルールを見直し、アクセス元IPアドレスを厳しく制限するなどの修正を行ってください。定期的にSecurity Hubの検出結果を確認し、未対応のアラートがない状態を維持することが、継続的なセキュリティ改善には不可欠です。

出典：Amazon EC2 インスタンスまたは Lambda 関数のポート 25 の制限を解除するにはどうすればよいですか（Amazon Web Services / 最終確認日：2026年6月23日）

利用状況別EC2ポート設定例とSecurity Hubによる具体的な監視ポイント

Webアプリケーションサーバー向けポート設定と監視

Webアプリケーションサーバーでは、主にHTTP（80番ポート）とHTTPS（443番ポート）をインターネットに開放します。管理のためにSSH（22番ポート、Linuxの場合）またはRDP（3389番ポート、Windowsの場合）も必要ですが、これらはインターネット全体ではなく、特定の管理用IPアドレスまたはVPNからのアクセスに限定することが極めて重要です。例えば、社内ネットワークのグローバルIPアドレスや、踏み台サーバーのプライベートIPアドレスのみをSSH/RDPのソースとして指定します。

Security Hubでは、このようなWebサーバーの設定を以下のように監視できます。まず、セキュリティグループが「0.0.0.0/0」からのSSHやRDPアクセスを許可していないか、自動でチェックし警告します。さらに、GuardDutyが有効になっていれば、SSHポートに対するブルートフォースアタックの試行や、その他の異常なネットワークアクティビティを検出した際に、Security Hubにアラートとして集約されます。これにより、設定ミスだけでなく、実際の脅威に対しても迅速に対応できる体制を構築できます。

データベースサーバー向けポート設定と監視

データベースサーバーは、機密性の高いデータを扱うため、原則としてインターネットに直接開放してはなりません。必要なポート（例：MySQL 3306番、PostgreSQL 5432番、SQL Server 1433番など）は、Webアプリケーションサーバーや内部のバッチサーバーなど、信頼できる内部からのアクセス元に限定して開放します。具体的には、Webアプリケーションサーバーが属するセキュリティグループIDをデータベースサーバーのセキュリティグループのインバウンドルールでソースとして指定するのが一般的な方法です。

Security Hubでの監視においては、データベース関連ポートが誤ってインターネットに開放されていないかが主要なチェックポイントとなります。Security Hubは、不適切なデータベースポートの公開を検出し、「重大」な検出結果として報告します。また、Amazon Inspectorと連携している場合、データベースエンジン自体の脆弱性や設定ミスもスキャンされ、その結果がSecurity Hubに集約されます。これにより、ネットワークレベルのセキュリティだけでなく、アプリケーションレベルの脆弱性も統合的に監視し、多層的な防御を強化できます。

開発・テスト環境向けポート設定と監視

開発・テスト環境は、本番環境と異なり一時的なポート開放が必要になる場合がありますが、これもセキュリティリスクとなります。例えば、開発者が一時的にデバッグ目的で特定のアプリケーションポート（例: 8080番）をインターネットに開放し、テストが終了した後も閉じ忘れてしまうケースが考えられます。このような状況は、攻撃者にとって格好のターゲットとなり得ます。

開発・テスト環境においても、本番環境と同様に最小限のポート開放を原則とし、一時的な開放が必要な場合は、使用期間を限定し、終了後は速やかに閉じる習慣を徹底することが重要です。Security Hubは、開発・テスト環境のセキュリティグループ設定も監視対象とすることができます。特に、テスト用として一時的に開放されたポートがインターネットに公開されたままになっていないか、あるいは長期にわたって不要なポートが開いたままになっていないかを自動的に検出し、注意を促します。これにより、開発・テスト環境のセキュリティホールが本番環境への脅威とならないよう、早期に問題を特定し対処することが可能になります。

チェックリスト：ポート設定の確認ポイント

  • Webサーバー管理ポート（SSH/RDP）は固定IPまたはVPNに限定されていますか？
  • データベースポートはインターネットに直接開放されていませんか？
  • 開発・テスト環境のポート開放は最小限に抑えられ、定期的に見直されていますか？
  • Security Hubの検出結果に「重大」または「高」のポート関連アラートはありませんか？
  • ポート設定変更後は、必ずSecurity Hubで設定ミスがないか確認していますか？

EC2ポート管理とSecurity Hub運用で避けるべき一般的な落とし穴

不要なポートの開放放置によるセキュリティリスク

EC2インスタンスのポート管理における最も一般的な落とし穴の一つは、一度開放したポートを閉じ忘れてしまうことです。特に、一時的な検証作業や特定のベンダーからのアクセス許可のためにポートを開放した後、その必要がなくなったにもかかわらず、セキュリティグループのルールを削除し忘れてしまうケースが頻繁に発生します。このような不要なポートの開放は、システムに潜在的な脆弱性をもたらし、攻撃者にとって侵入経路となり得る「開いたままの窓」を提供しているようなものです。

このリスクを回避するためには、セキュリティグループのルールを定期的に見直し、不要になったインバウンドルールは速やかに削除する運用プロセスを確立することが不可欠です。Security Hubは、設定されたセキュリティコントロールに基づき、このような不要なポート開放（特に管理ポートの広範な開放など）を自動的に検出し、警告を発します。検出結果を定期的にレビューし、該当するアラートがあればすぐに修正対応を行うことで、セキュリティリスクを最小限に抑えることができます。

広範囲なIPアドレスからのアクセス許可

セキュリティグループの設定において、ソースIPアドレスを「0.0.0.0/0」（インターネット全体）に設定することは、セキュリティ上極めて危険な行為であり、避けるべき一般的な落とし穴です。特に、SSH（22番ポート）やRDP（3389番ポート）といった管理用のポートをインターネット全体に開放してしまうと、ブルートフォースアタック（総当たり攻撃）や、既知の脆弱性を悪用した攻撃の直接的な標的となります。

このような設定は、悪意のあるアクターがサーバーに不正にアクセスし、マルウェアのインストール、データの窃取、踏み台としての利用などを行うリスクを大幅に高めます。Security Hubは、セキュリティグループが管理ポートへの広範なアクセスを許可している場合、それを「重大」な検出結果として報告し、優先的に対処すべき問題として明確に示します。対策としては、必ずアクセス元のIPアドレスを特定の固定IPアドレス（例：自社のオフィスIP、VPN終端IP）に限定するか、Bastionホスト（踏み台サーバー）経由でのアクセスを強制するなどの厳格な制限を適用してください。

Security Hub導入後の運用形骸化の回避策

AWS Security Hubは強力なセキュリティ管理ツールですが、導入して終わりではありません。その効果を最大限に引き出すためには、継続的な運用が不可欠です。最も避けるべき落とし穴の一つは、Security Hubからの検出結果やアラートが多すぎて、確認や対応が形骸化してしまうことです。これにより、本当に重要なセキュリティインシデントを見逃すリスクが高まります。

運用形骸化を防ぐためには、まず以下の点を考慮してください。

  1. 通知体制の確立: 重大度に応じたアラートの通知先（例: Slack、PagerDuty、メール）と担当者を明確にし、迅速な対応を促します。
  2. 抑制済み項目の棚卸し: ビジネス要件上やむを得ず特定のセキュリティコントロールを抑制している場合、その理由と期間を定期的に見直し、不要な抑制は解除します。
  3. 定期的なレビュー: Security Hubのダッシュボードや検出結果を週次または月次で定期的にレビューする時間を設け、未対応のアラートがないか確認します。
  4. 最新脅威の把握: IPAが発表する「情報セキュリティ10大脅威」などを参照し、基本的なポート設定だけでなく、AI悪用やランサムウェアなど、変化する最新の脅威に対する「全社的なリスク管理」の視点を持つことが不可欠です。

これにより、Security Hubを単なる監視ツールではなく、組織全体のセキュリティ態勢を継続的に改善するためのプラットフォームとして活用できます。

出典：情報セキュリティ10大脅威 2026（IPA 独立行政法人 情報処理推進機構 / 2026年5月21日更新）

【ケース】予期せぬポート開放が発覚しSecurity Hubで改善した事例

架空のケーススタディ：開発環境での誤ったポート開放

これは、架空のケースにおける事例です。あるIT企業A社では、開発チームが新しいWebサービスのプロトタイプ開発を進めていました。開発の効率化のため、テスト目的で一時的に開発用EC2インスタンスの特定のポート（例えば、開発中のアプリケーションが使用する8080番ポートや、一時的なデバッグ用の9000番ポートなど）を、自身の作業用IPアドレスに限定して開放しました。しかし、デバッグ作業の途中で、アクセス元IPアドレスの指定を誤り、意図せず「0.0.0.0/0」（インターネット全体）からのアクセスを許可してしまったセキュリティグループルールを追加してしまいました。開発チームはテストが完了した後も、この誤ったルールを削除し忘れてしまい、ポートはインターネットに公開されたまま放置されていました。

数週間後、この開発用EC2インスタンスで、普段のテストアクセスとは異なる不審な通信がログに記録され始めました。しかし、開発チームは多忙を極めており、日常的なログ監視まで手が回らない状況でした。この設定ミスは、放置されればいつ重大なインシデントにつながってもおかしくない状態でした。

Security Hubによる問題の検出と警告

A社は以前からAWS Security Hubを導入し、セキュリティ態勢の可視化と継続的な監視を行っていました。このケースにおいて、Security Hubは開発用EC2インスタンスのセキュリティグループに存在する「0.0.0.0/0」からの広範囲なポート開放（8080番ポートなど）を自動的に検出し、「重大」な検出結果として報告しました。具体的には、「EC2.SecurityHub.2: Security groups should not allow unrestricted incoming traffic to ports commonly used for administrative access」のようなコントロールがトリガーされたと考えられます。

さらに、GuardDutyも有効化されていたため、この公開されたポートに対して外部からの不審なスキャンや、ブルートフォースアタックに類似する通信試行を検知し、その検出結果もSecurity Hubに集約されました。Security Hubは、これらの複数のシグナルを統合して優先順位付けし、A社のセキュリティ担当者にSlack経由でアラート通知を行いました。これにより、開発チームが気づかなかったポート開放と、それに伴う脅威の兆候が、セキュリティ担当者の目に留まることとなりました。

改善策と再発防止のための運用改善

Security Hubからのアラートを受け取ったセキュリティ担当者は、すぐに調査を開始し、開発用EC2インスタンスにおける意図しないポート開放が発覚しました。担当者は開発チームと連携し、該当するセキュリティグループルールを速やかに削除し、アクセス元を厳密に制限するルールに修正しました。これにより、外部からの不正アクセスリスクは即座に解消されました。

この事例を教訓として、A社は再発防止のために以下の運用改善を実施しました。

  1. セキュリティグループ変更承認プロセスの見直し: セキュリティグループの変更を行う際には、必ず複数の担当者によるレビューと承認を必須としました。
  2. CI/CDパイプラインへのセキュリティチェック組み込み: インフラ変更を伴うデプロイ前に、IaC（Infrastructure as Code）のコードを対象としたセキュリティスキャンを実施し、広範囲なポート開放などの設定ミスを自動的に検出する仕組みを導入しました。
  3. Security Hub検出結果の定期レビュー体制強化: セキュリティ担当者だけでなく、各開発チームのリーダーもSecurity Hubの検出結果を定期的にレビューする義務を負い、チーム内でセキュリティ意識を高める取り組みを行いました。

これらの改善により、A社はセキュリティグループの設定ミスによるリスクを大幅に低減し、より堅牢なセキュリティ態勢を構築することができました。