1. EC2基盤設計の全体像：セキュリティと運用最適化の要点
    1. 責任共有モデルの理解と利用者責任範囲
    2. 多層防御の重要性と基本原則
    3. テナンシー選択とパフォーマンス・セキュリティへの影響
  2. EC2インスタンス設定とセキュリティ強化のステップ
    1. セキュリティグループ設定の基本と実践
    2. IAMロールを活用した安全なアクセス管理
    3. OSレベルでのセキュリティ対策とパッチ適用
  3. 実践で役立つEC2設定：ユースケース別セキュリティ戦略
    1. ウェブサーバー（公開系）のセキュリティ戦略
    2. データベースサーバー（非公開系）のセキュリティ戦略
    3. 開発・管理用インスタンスのセキュリティ戦略
  4. EC2運用時の落とし穴：見落としがちな設定と対策
    1. デフォルトVPC・セキュリティグループの危険性
    2. ソース/宛先チェックの設定見落とし
    3. 古いAMI・OSイメージの使用と脆弱性
  5. 【ケース】不正アクセス阻止：セキュリティグループ再設定と改善の軌跡
    1. 不正アクセス発生状況とその原因特定（架空のケース）
    2. セキュリティグループ再設定と多層防御の導入
    3. 再発防止策と継続的な運用改善
  6. まとめ
  7. よくある質問
    1. Q: EC2セキュリティグループの主な役割は何ですか？
    2. Q: EC2テナンシーの種類と選択基準を教えてください。
    3. Q: EC2でセキュアブートは利用可能ですか？
    4. Q: EC2の送信元/送信先チェックとは何ですか？
    5. Q: 専有ホストと専有インスタンスの違いは何ですか？

EC2基盤設計の全体像：セキュリティと運用最適化の要点

責任共有モデルの理解と利用者責任範囲

AWS環境におけるセキュリティは、その責任範囲が明確に分かれています。いわゆる「責任共有モデル」とは、AWSが責任を持つ「クラウドのセキュリティ」と、利用者が責任を負う「クラウド内のセキュリティ」を指します。EC2のようなIaaSサービスでは、ゲストOSの管理、セキュリティグループ設定、データ暗号化、IAMによるアクセス権限管理など、多くの項目が利用者の責任範囲となります。

近年、日本国内ではクラウドサービス利用率が上昇しており、総務省「情報通信白書 令和5年版」によると、企業等のクラウドサービス利用率は72.2%に達しています。しかし、利便性の向上と引き換えに、利用者の設定不備が直接的なセキュリティリスク（誤設定による情報漏洩など）に繋がる可能性も増大しています。実際、2023年 タレス クラウドセキュリティレポートによれば、過去1年間に44%の日本企業がクラウド環境でのデータ侵害を経験しています。

このため、自身の責任範囲を正確に理解し、適切なセキュリティ対策を講じることが、EC2を安全に利用する上で不可欠です。IaaSの特性を鑑み、設定一つ一つに潜むリスクを把握し、対策を講じる意識が求められます。

多層防御の重要性と基本原則

堅牢なEC2基盤を構築するためには、単一のセキュリティ対策に頼るのではなく、複数の防御策を組み合わせる「多層防御」の考え方が極めて重要です。具体的な設計原則としては、まずVPC（Virtual Private Cloud）とサブネットによるネットワーク分離が挙げられます。これにより、インターネットから直接アクセスさせたくないデータベースやアプリケーションサーバーを、プライベートサブネットに配置し、論理的な境界で保護できます。

次に、AWS IAM（Identity and Access Management）による最小権限の原則の適用です。EC2インスタンスやユーザーには、その職務を遂行するために必要最低限の権限のみを付与し、過剰な権限による情報漏洩や不正操作のリスクを低減します。さらに、AWS GuardDutyなどの脅威検知サービスや、CloudTrail、CloudWatch Logsを利用したログ監視を組み合わせることで、異常なアクティビティを早期に検知し、インシデント発生時の迅速な対応が可能になります。

これらの対策を組み合わせることで、仮に一部の防御層が突破されても、次の層で脅威を食い止める可能性が高まり、システム全体のセキュリティ耐性を向上させることができます。

テナンシー選択とパフォーマンス・セキュリティへの影響

EC2インスタンスのテナンシー設定は、パフォーマンス、コスト、そしてセキュリティに直接的な影響を与える重要な選択肢です。EC2には大きく分けて「共有インスタンス」「専有インスタンス」「専有ホスト」の3種類のテナンシーがあります。「共有インスタンス」は、複数のAWSアカウントのインスタンスと物理ハードウェアを共有する一般的な形式で、最もコスト効率が高い選択肢です。

一方、「専有インスタンス」は、単一のAWSアカウントのインスタンス専用の物理ハードウェア上で実行され、他のAWSアカウントとハードウェアを共有しません。これにより、特定の規制要件を満たす必要がある場合や、より厳密な分離を求める場合に適しています。さらに「専有ホスト」は、ユーザーが物理サーバー全体を占有するため、既存のソフトウェアライセンスを持ち込む場合や、サーバーレベルでの厳密な分離が必要な場合に利用されます。

特に高いセキュリティ要件や規制遵守が求められるシステムでは、専有インスタンスや専有ホストの利用を検討することで、物理レベルでの分離が実現し、潜在的なリスクを低減できる可能性があります。それぞれのテナンシーの特性を理解し、要件に合わせた適切な選択を行うことが、EC2基盤設計の最適解に繋がります。

出典：AWS セキュリティドキュメント、Amazon EC2 とは、責任共有 – セキュリティの柱、情報通信白書 令和5年版、2023年 タレス クラウドセキュリティレポート

EC2インスタンス設定とセキュリティ強化のステップ

セキュリティグループ設定の基本と実践

EC2インスタンスのセキュリティを強化する上で最も基本的な対策の一つが、セキュリティグループの適切な設定です。セキュリティグループは、インスタンスに着信するトラフィックと、インスタンスから発信するトラフィックを制御する仮想ファイアウォールとして機能します。設定の基本は「最小権限の原則」に基づき、必要なポートとIPアドレス範囲のみを許可することです。

例えば、ウェブサーバーであればHTTP (80番ポート) とHTTPS (443番ポート) のみを「0.0.0.0/0」（インターネット全体）からのアクセスを許可し、SSH (22番ポート) やRDP (3389番ポート) のような管理ポートへのアクセスは、運用担当者のオフィスIPアドレスや、専用の踏み台サーバーのIPアドレスなど、極めて限定された送信元からのみ許可するように設定します。これにより、不要なアクセス経路を閉鎖し、不正アクセスのリスクを大幅に低減できます。

セキュリティグループはステートフルであり、一度許可された通信の戻りトラフィックは自動的に許可されます。そのため、送信ルールよりも受信ルールに重点を置いて設定することが重要です。定期的にセキュリティグループの設定を見直し、現在のシステム要件に合致しているか、過剰な許可がないかを確認する運用も欠かせません。

IAMロールを活用した安全なアクセス管理

EC2インスタンスが他のAWSサービス（S3、DynamoDB、CloudWatchなど）にアクセスする必要がある場合、IAMロールを活用することが最も安全なアクセス管理方法です。インスタンスにIAMロールをアタッチすることで、アクセスキーやシークレットアクセスキーをインスタンス内に直接保存する必要がなくなり、これらの認証情報が誤って漏洩するリスクを排除できます。

IAMロールは、特定の権限をカプセル化したもので、インスタンスが必要とする最小限の権限のみを付与するよう設計します。例えば、S3バケットへの読み取りアクセスが必要なウェブサーバーには、S3への読み取り権限のみを持つIAMロールをアタッチします。これにより、万が一インスタンスが侵害されたとしても、攻撃者がアクセスできる範囲を限定し、被害の拡大を防ぐことが可能です。

IAMロールは一時的な認証情報を自動的に取得・更新するため、手動でのキー管理の手間をなくし、運用上のセキュリティを大幅に向上させます。インスタンスにアタッチされたロールは、インスタンスメタデータサービスを通じて利用可能となり、アプリケーションから簡単に利用できます。

OSレベルでのセキュリティ対策とパッチ適用

EC2インスタンスのOS管理は、利用者の責任範囲であり、セキュリティの要です。定期的なOSセキュリティパッチの適用は、既知の脆弱性を悪用した攻撃からシステムを保護するために不可欠なプロセスです。AWS Systems Manager (SSM) のPatch Managerなどのサービスを活用することで、パッチ適用プロセスを自動化・簡素化し、効率的にセキュリティレベルを維持することが可能です。

パッチ適用に加え、インスタンスに不要なソフトウェアやサービスがインストールされていないか確認し、使用しないものは停止またはアンインストールすることも重要です。不要なソフトウェアは、未知の脆弱性の温床となる可能性があるため、最小限の構成を保つことが推奨されます。また、適切なアンチウイルス・マルウェア対策ソフトを導入し、定期的にスキャンを実行することも有効な対策となります。

これらのOSレベルでの対策は、アプリケーション層やネットワーク層のセキュリティ対策と並行して実施することで、より包括的な防御体制を構築します。OSの健全性を保つことは、EC2インスタンス全体のセキュリティを支える基礎となります。

実践で役立つEC2設定：ユースケース別セキュリティ戦略

ウェブサーバー（公開系）のセキュリティ戦略

インターネットに公開されるウェブサーバーは、最も攻撃の対象になりやすいため、厳重なセキュリティ対策が求められます。まず、ウェブサーバーは直接インターネットに接続するのではなく、AWS ELB (Elastic Load Balancing) または ALB (Application Load Balancer) を介してトラフィックをルーティングする構成を推奨します。ELB/ALBのセキュリティグループでは、HTTP (80番ポート) とHTTPS (443番ポート) のみを「0.0.0.0/0」から許可し、ウェブサーバーインスタンスのセキュリティグループでは、ELB/ALBからのトラフィックのみを許可するよう設定します。

管理ポート（SSHなど）は、ELB/ALBのセキュリティグループでは許可せず、専用の踏み台サーバーやVPN経由でのアクセスのみを許可するように設計することで、攻撃経路を限定します。さらに、AWS WAF (Web Application Firewall) を導入し、SQLインジェクションやクロスサイトスクリプティングなどのL7層のウェブ攻撃からアプリケーションを保護します。AWS Shield StandardまたはAdvancedを有効にすることで、DDoS攻撃に対する耐性も強化できます。

これらの対策を組み合わせることで、公開系ウェブサーバーのセキュリティを多角的に強化し、悪意あるアクセスからシステムを守ることが可能になります。

データベースサーバー（非公開系）のセキュリティ戦略

データベースサーバーは、最も機密性の高い情報を扱うため、インターネットから隔離された環境に配置することが絶対条件です。EC2でデータベースを構築する場合、必ずプライベートサブネットに配置し、インターネットゲートウェイを経由した直接的なアクセスを完全に遮断します。データベースサーバーのセキュリティグループは、そのデータベースを利用するアプリケーションサーバーからのアクセス（例: MySQL 3306番ポート）のみを許可するように厳密に設定します。

これにより、外部からの不正アクセスだけでなく、意図しない内部からのアクセスも制限できます。さらに、データベースのデータは、保管時（ストレージ暗号化）および転送時（SSL/TLS通信）の両方で暗号化を適用することを強く推奨します。AWS KMS (Key Management Service) を利用して暗号化キーを管理することで、セキュリティをさらに強化できます。

マネージドサービスであるAmazon RDSの利用も、セキュリティ面で大きなメリットがあります。RDSは、AWSがOSパッチ適用やバックアップ、フェイルオーバーなどを管理してくれるため、利用者の運用負担を軽減しつつ、高いセキュリティレベルを維持することが可能です。

開発・管理用インスタンスのセキュリティ戦略

開発やシステム管理に利用するインスタンスも、適切なセキュリティ対策を講じることが重要です。これらのインスタンスは通常、本番環境へのアクセス権限を持つため、もし侵害されればシステム全体に深刻な影響を及ぼす可能性があります。まず、開発・検証環境と本番環境は、VPCやアカウントを分けて完全にネットワーク分離することを強く推奨します。

管理用インスタンスへのアクセスは、直接インターネットから許可するのではなく、VPN接続を介するか、専用の踏み台サーバー（Bastion Host）を経由させるべきです。踏み台サーバーのセキュリティグループは、特定のIPアドレス範囲からのSSH/RDPアクセスのみを許可するように設定し、そこからのみ他の内部インスタンスへのアクセスを許可します。これにより、外部からの直接的な攻撃対象を限定できます。

さらに、AWSにログインするIAMユーザーには、多要素認証（MFA）を必須と設定し、パスワードだけでなく追加の認証要素を求めることで、不正ログインのリスクを大幅に低減します。定期的なアクセスログの監視も、不審なアクティビティを早期に検知するために不可欠です。

EC2運用時の落とし穴：見落としがちな設定と対策

デフォルトVPC・セキュリティグループの危険性

AWSアカウントを作成すると自動的に生成される「デフォルトVPC」および「デフォルトセキュリティグループ」は、手軽にインスタンスを起動できる反面、運用時に見落としがちなセキュリティリスクを内包しています。デフォルトVPCは、サブネットやインターネットゲートウェイが自動的に設定されているため、深く意識せずに利用してしまうケースがあります。

特に、デフォルトセキュリティグループのルールには注意が必要です。デフォルトでは、そのセキュリティグループに属するすべてのインスタンスからのすべての内部通信（all traffic）を許可する設定になっていることが多く、セキュリティポリシー上不必要な広範な通信を許可してしまっている可能性があります。また、外部からのアクセスについても、意図せず全開放されてしまうリスクもゼロではありません。

新規の環境構築時には、必ずカスタムVPCを作成し、必要なサブネット、ルートテーブル、ネットワークACL、そして最小権限の原則に基づいたセキュリティグループを設計することを推奨します。既存の環境でデフォルト設定を安易に利用している場合は、早急に設定内容を見直し、最小限のアクセス許可に修正する作業が求められます。

ソース/宛先チェックの設定見落とし

EC2インスタンスが特定のネットワーク機能（例えばNATインスタンス、VPNサーバー、ファイアウォールアプライアンスなど）を果たす場合、「ソース/宛先チェック」の無効化という重要な設定を見落とすことがあります。通常、EC2インスタンスは自身を送信元または宛先とするトラフィックのみを処理しますが、NATインスタンスのように、自身のIPアドレスではないトラフィックを転送する役割を担う場合は、このチェックを無効化する必要があります。

この設定を無効化しないと、インスタンスは自身以外のIPアドレス宛のパケットを転送せず、期待通りにNATやVPNの機能が動作しません。設定方法は、EC2コンソールで対象インスタンスのネットワークインターフェイスを選択し、「アクション」から「ソース/宛先チェックを変更」を選んで無効化するだけです。

ネットワークアーキテクチャ設計時に、EC2インスタンスがどのような役割を担うのかを明確にし、必要に応じてこのチェックを適切に無効化することで、意図したネットワーク機能を実現できます。一般的なアプリケーションサーバーとして利用する場合には、この設定を変更する必要はありません。

古いAMI・OSイメージの使用と脆弱性

EC2インスタンスを起動する際に使用するAMI（Amazon Machine Image）や、そのAMIに含まれるOSイメージが古いものである場合、既知のセキュリティ脆弱性を抱えているリスクがあります。これは、OSやミドルウェアに発見された脆弱性に対するパッチが適用されていない状態を意味し、攻撃者にとって格好のターゲットとなり得ます。

この落とし穴に対する対策は、常に最新のセキュリティパッチが適用されたAMIを使用することです。AWSが提供する公式AMIは定期的に更新されていますが、独自に作成したカスタムAMIや、マーケットプレイスから取得したAMIを利用している場合は、そのAMIが最新の状態に保たれているか、または定期的に最新のパッチを適用するプロセスが確立されているかを確認する必要があります。AWS Systems Manager (SSM) のPatch Managerなどを活用し、自動的にパッチ適用を行う仕組みを導入することも有効です。

「利用者の責任」であるOS管理を怠ると、せっかく堅牢なネットワーク設計やセキュリティグループを設定していても、OSレベルの脆弱性から侵入を許してしまう可能性があります。定期的なAMIの棚卸しと更新、そしてOSパッチの適用は、EC2運用における必須事項です。

【ケース】不正アクセス阻止：セキュリティグループ再設定と改善の軌跡

不正アクセス発生状況とその原因特定（架空のケース）

ある日、弊社のウェブサービスを運用するEC2インスタンスにおいて、異常なSSHログイン試行のアラートが頻発しました。監視ツールからの報告により、特定のIPアドレスから不審なアクセスが急増していることが判明。直ちに詳細調査を開始した結果、ウェブサーバーのセキュリティグループで、本来は限定すべきSSH（22番ポート）へのアクセスが、誤って「0.0.0.0/0」（インターネット全体）から許可されている設定になっていることが明らかになりました。

この設定変更は、以前のシステム改修時に担当者が誤って行ってしまい、その後のレビューで検出されずに残っていたものでした。調査レポート「企業のセキュリティインシデントに関する調査レポート2025」でも、日本国内で発生するセキュリティインシデントの主要原因の63.6%が「不正アクセス（ランサムウェアを除く）」とされており、今回のケースもその典型的な例といえます。セキュリティグループの設定不備が、直接的な侵入リスクに繋がることを痛感する出来事となりました。

幸いにも、この時点では内部システムへの深刻な侵害は確認されませんでしたが、この脆弱性が放置されていれば、データ漏洩やサービス停止に発展する可能性がありました。

セキュリティグループ再設定と多層防御の導入

不正アクセスの試行が確認された直後、以下の緊急対応を実施しました。

  1. 問題のセキュリティグループから、SSH（22番ポート）への「0.0.0.0/0」からの許可ルールを即座に削除しました。
  2. SSHアクセスは、運用チームの固定IPアドレスと、専用に用意した踏み台サーバーのプライベートIPアドレスからのみ許可するように再設定しました。
  3. ウェブサーバーをパブリックサブネットからプライベートサブネットへ移行し、インターネットからの直接アクセスを遮断。アクセスはALB (Application Load Balancer) 経由のみとしました。ALBのセキュリティグループはHTTP/HTTPSのみを許可し、ウェブサーバーへのトラフィックをALBのみに限定しました。
  4. AWS WAFを導入し、一般的なウェブ攻撃（SQLインジェクションなど）からアプリケーションを保護するルールを適用しました。

これらの対策により、一時的に露呈していたSSHポートへの不正アクセス経路は完全に閉鎖され、ウェブサーバーに対する多層的な防御体制が確立されました。緊急対応後も監視を継続し、異常がないことを確認しました。

再発防止策と継続的な運用改善

今回の不正アクセス未遂を教訓に、再発防止と継続的なセキュリティ運用改善のため、以下の施策を導入しました。

  1. 変更管理プロセスの強化: セキュリティグループを含むインフラ設定変更時は、必ず複数の担当者によるレビューと承認を必須としました。AWS CloudFormationなどのIaC（Infrastructure as Code）導入も検討し、変更履歴の追跡と管理を徹底します。
  2. リアルタイム監視の強化: AWS CloudTrailとAmazon CloudWatch Logsを連携させ、セキュリティグループの変更イベントを検知した際に、担当者へ即座に通知するアラートシステムを構築しました。これにより、意図しない設定変更を早期に発見できます。
  3. 定期的なセキュリティレビュー: 半年に一度、セキュリティ専門家によるインフラ設定レビューを実施し、潜在的な脆弱性や設定不備がないか体系的にチェックする運用を確立しました。
  4. 従業員教育の徹底: 全従業員に対し、AWSの責任共有モデルと「最小権限の原則」の重要性に関する定期的なセキュリティ教育を実施し、意識向上を図りました。

このような継続的な改善活動を通じて、クラウド環境のセキュリティレベルを維持し、将来的なリスクを最小限に抑えることを目指します。

チェックリスト

  • セキュリティグループは最小限の許可に設定されていますか？
  • IAMロールは最小権限の原則に従っていますか？
  • OSパッチは定期的に適用されていますか？
  • デフォルトVPC/セキュリティグループの不用意な利用はありませんか？
  • セキュリティ関連イベントの監視は適切に設定されていますか？
  • 不正アクセス阻止の経験は組織のセキュリティ改善に活かされていますか？

出典：企業のセキュリティインシデントに関する調査レポート2025