クラウドシフトが進む一方で、セキュリティ事故が増加しています。「AWSのセキュリティ対策をどこから始めればよいか分からない」と不安を感じている担当者も多いのではないでしょうか。

この記事では、AWSセキュリティの全体像を5つのレイヤーに分解し、リスク・コスト・優先順位を整理して解説します。記事を読むことで、自社のAWS環境に必要なセキュリティ対策を体系的に理解し、具体的な対策を検討できるようになることでしょう。

AWS環境のセキュリティ対策は、世界規模の製造メーカーや大手IT企業など多くの企業のシステム構築を支援してきた株式会社テクノプロにご相談ください。ITシステム構築に強みを持つ株式会社テクノプロなら、AWS導入の準備段階からビジネス設計、本稼働、運用の各段階に応じて、経験豊富なエンジニアが効率的に支援を行い、費用対効果の高いサービスを実現します。

AWSセキュリティの基礎｜安全性・オンプレとの違い・責任共有モデル

AWSのセキュリティを正しく理解するためには、AWS自体の安全性がどのように担保されているかについての知識やオンプレミス環境との違いとなる「責任共有モデル」の理解が必須です。

ここでは、AWSが提供する強固セキュリティを持つ基盤や、オンプレとの違い、利用者が担うべき責任範囲について解説します。

AWSのセキュリティが評価される3つの理由｜基盤・認証・設計思想

AWSはグローバル規模のクラウド事業者として、オンプレミス環境では実現が難しい以下のようなセキュリティ対策を標準で提供しています。

・堅固なデータセンターが基盤となっている ・国際的なセキュリティ認証を受けている ・セキュリティを前提とした設計思想がサービスに組み込まれている

各対策の特徴は以下の通りです。

堅固なデータセンターが基盤となっている

AWSは、物理的な侵入や設備障害を前提とした多層的な物理セキュリティと高可用性設計により、データセンター基盤の安全性を確保しています。

・外観から識別できない設計により、セキュリティを強化 ・データセンターの場所を非公開にしてセキュリティを維持 ・MFA (多要素認証) と監視カメラによる24時間365日の継続的な監視 ・無停電電源装置 (UPS) とディーゼル発電機による多段階のバックアップ電源体制 ・冗長化された空調システムで運用継続性を確保 ・複数の拠点をつないで、ネットワークが止まりにくい構造

国際的なセキュリティ認証を受けている

AWSのセキュリティ体制は、国際的な認証や第三者監査によって客観的に検証・保証されています。

・ISO 27001 (情報セキュリティマネジメント)やISO 27017 (クラウドセキュリティ) 、ISO 27018 (クラウドプライバシー) などの国際基準を取得 ・SOC 1やSOC 2、SOC 3の第三者監査レポートを定期的に取得 (6ヶ月ごと) ・PCI DSS レベル1、FedRAMP認証により、金融機関や米国政府機関での利用が可能 ・独立した第三者評価機関による継続的な厳格な監査をクリア ・金融業界の規制 (FISC) や政府セキュリティ基準 (DoD SRG) にも対応

セキュリティを前提とした設計思想がサービスに組み込まれている

AWSは、サービス設計の段階からセキュリティを前提としたアーキテクチャ思想（Security by Design）を採用しています。

・「最小権限の原則」に基づいてユーザーに必要最小限の権限のみを付与可能 ・ネットワークやアプリケーション、データ層にわたる多層防御を標準提供 ・複数のセキュリティサービス (VPC・Shield・WAFなどの) により、段階的な防御が可能 ・利用者自身が暗号化やアクセス制御、ログ監視などの高度なセキュリティ設定を実施可能

AWSは物理層から運用ルール、サービス設計に至るまで徹底した対策を行っています。利用者は強固なAWS基盤上でシステムを運用することで、ビジネスに集中できます。

オンプレミスとの違い | クラウド特有のセキュリティ強化ポイント

オンプレミスとクラウドでは、セキュリティ対策の重要なポイントが以下のように異なります。

オンプレミス	社内ネットワークと外部を隔てるファイアウォールや境界防御が中心
クラウド	ID管理とアクセス制御がセキュリティ対策の中核

AWSとオンプレミスとの最大の違いは、物理的なインフラ管理をAWSに任せられる点です。
サーバーの配置や電源管理、入退室管理といった物理レイヤーのセキュリティ対策はAWSが実施するため、利用者はこれらの運用負荷から解放されます。結果的に、限られたリソースをアプリケーションの保護やデータの暗号化といった、より上位レイヤーの対策に集中させることが可能です。

一方で、以下のようなクラウド特有のリスクも存在し、対策が必要です。

リスク	API経由でインフラを操作できるため、設定ミス (S3バケットの公開設定など) で情報漏洩につながる可能性
対策	AWS Configなどの構成管理サービスを活用して、設定変更を継続的に監視・監査する

AWS Configは、AWSリソースの構成履歴を記録し、あらかじめ定義したルールに違反する状態 (例えば、S3バケットがパブリックになっているなど) を検出できます。​EventBridgeやLambdaと連携させることで、問題を検知した際の通知や、自動修復の実行も可能です。

クラウドとオンプレの比較については、以下の記事でも詳しく解説しています。

あわせて読みたい

【最新版】クラウドメリット10選！デメリットやオンプレとの比較 インターネットの普及が進み、より効率の良いシステム導入の必要性から会計や勤怠など様々な業務についてクラウド化が進んでいます。本記事では、企業が注目するクラウ...

AWSの責任共有モデル |AWSと利用者の役割分担

AWSのセキュリティには「責任共有モデル」という考え方があります。これは、AWSと利用者がそれぞれの担当範囲でセキュリティ責任を負うという概念です。

AWSはインフラ領域を含む「クラウドのセキュリティ」に責任を持ちます。一方で、OSの更新やアクセス権限の設定、データ管理など「クラウド内のセキュリティ」は利用者の責任です。

AWSと利用者の責任範囲を整理すると次の通りです。

担当	責任範囲
AWS	・データセンターの物理セキュリティ ・サーバーなどのハードウェア ・ネットワークインフラ・仮想化基盤
利用者	・OSやミドルウェアの更新 ・アクセス権限の設定 ・システムで扱うデータ ・ネットワークのトラフィック制御

責任分界点を正しく理解していないと、重大なセキュリティギャップが生じる恐れがあります。例えば「AWSを使っているから安全だ」と誤解し、OSの脆弱性対策やアクセス制御を怠れば、サイバー攻撃や情報漏洩の被害に遭うリスクは高まります。

AWSが提供する安全な基盤の上で、利用者が適切な設定と運用を継続的に行うことで、高いレベルのセキュリティの実現が可能です。

AWSセキュリティの全体像｜防御設計の5つのレイヤーと主要サービス

AWSにおけるセキュリティ対策は、複数の防御層を重ねる多層防御の考え方が基本で、以下の5つのレイヤー (階層) で考えます。

・IDとアクセス管理 ・ネットワーク防御 ・データ保護と暗号化 ・監査とログ管理 ・脅威検知と統合管理

ここでは、各レイヤーの中核となるAWSサービスとその役割について解説します。

IDとアクセス管理(IAM・MFA・IAM Identity Center・Cognito・Secrets Manager)

5つのレイヤーの中でも、IDとアクセス管理はすべてのセキュリティ対策の起点となる重要な要素です。
利用者の身元確認や権限の制御、認証情報の安全な保護を通じて、不正アクセスを防ぎ、安全な運用基盤を提供します。

クラウド環境では、インターネット経由で多様なユーザーやシステムがリソースへアクセスします。そのため、誰が (認証)・どんなことをできるのか (認可) 厳密に管理する仕組みを構築します。

IDとアクセス管理の中核を担うサービスは次の通りです。

IAM	・AWSリソースへのアクセス権限を細かく制御する ・ユーザーや役割 (ロール) ごとに許可 / 拒否のポリシー設定を可能にする ・最小権限の原則を実現するための基本サービスとなる
MFA	・パスワードに加え、スマートフォンなどのデバイスによる追加認証を実現する ・IDやパスワード漏洩時の、なりすましリスクを低減する ・MFAは、ルートユーザー (管理者) を含む全ユーザーでの有効化が推奨される
IAM Identity Center (旧 AWS SSO)	・複数のAWSアカウントやビジネスアプリへのSSOを可能にする ・従業員のIDとアクセス権を一元的に管理する ・Azure ADなど他の認証サーバーとも連携可能
Cognito	・自社開発のWebシステムやモバイルアプリ向け認証サービスとなる ・利用者の会員登録やログイン機能を提供する ・ソーシャルログイン (Google・Facebookなど) に対応している
Secrets Manager	・データベースのパスワードやAPIキー等の機密情報を安全に管理できる ・アプリケーションのコードにおける、認証情報の直書きを排除できる ・認証情報のローテーション (定期変更) を自動化できる

AWSでは、管理対象（例：従業員／顧客）や保護対象（例：アクセス権／認証情報）などの目的に応じて、上記のサービスを選択します。
用途ごとに適切に使い分け・組み合わせることで、無理のない形で強固な認証・認可の仕組みを構築できます。

ネットワーク防御 (VPC・Security Group・NACL・WAF・Shield)

ネットワーク防御は、5つのセキュリティレイヤーの中でも、外部からの攻撃を最前線で防ぐ役割を担う重要なレイヤーです。

クラウド環境では外部との通信が前提となるため、AWSと外部ネットワークの境界で適切なトラフィック制御を行うことが重要です。

具体的には、次のような対策を実施します。

・外部の不正アクセスやDDoS攻撃 (大量の通信を送りシステムをダウンさせる攻撃) をブロック ・許可された通信のみを通すフィルタリング対応

ネットワーク防御の主なサービスと特徴は次の通りです。

VPC	・AWS内に論理的に隔離された仮想ネットワークを構築 ・インターネットに接続しないプライベートな領域を作成可能 ・外部から直接アクセスできない安全な環境の基盤
Security Group	・EC2インスタンスなどの単位で適用されるステートフル (入口がOKなら出口も自動許可する設定) な仮想ファイアウォール
NACL	・Security Groupを補完するネットワークレベルの制御として併用されることが多い ・ネットワークのアクセスをコントロールするリスト ・サブネット単位で動作するステートレス (入口・出口の両方で許可設定が必要) な仮想ファイアウォール
WAF	・Webシステムへの一般的な攻撃を検知・ブロック ・脆弱性を突く攻撃 (SQLインジェクション・XSSなど) を防ぐ ・独自のルールを作成して特定のアクセスを制限
Shield	・DDoS攻撃の保護 ・Standardプランは全ユーザーに無償で自動適用 ・Advancedプランは大規模な攻撃への対応とコスト保護が可能

VPCを使うことで、自社専用の閉じたネットワークをAWS上に作ることができます。社内システムなどを外部から直接アクセスできない場所に配置できるため、安全に運用できる実行環境の基盤となります。

ファイアウォールは、Security Groupをメインに使い、必要に応じてNACLを併用して防御を強化することが一般的です。特にSecurity GroupとNACLの使い分けがポイントとなります。入口通信も自動許可されるSecurity Groupに対し、NACLは入口と出口の通信を個別に許可する必要があります。ネットワークの入口から内部の通信制御まで、複数のポイントで防御を固めることが重要です。

データ保護と暗号化 (S3・KMS・Macie)

データ保護と暗号化は、データを守る仕組みを提供するレイヤーです。

外部の侵入を許してしまった場合でも、保存データや通信内容を保護する必要があります。重要なデータは、保管時と転送時の両方でデータ保護と暗号化を行います。

データ保護と暗号化の主なサービスと特徴は次の通りです。

S3	・AWSの標準的なデータ保存サービス ・データの自動暗号化機能やアクセス制限機能を提供 ・安価で耐久性が高く、大量のデータを安全に保存可能
KMS	・データの暗号化や復号に使用する暗号化キーを作成・管理 ・S3など他のAWSサービスと連携して暗号化を実行 ・ログ連携によりキーの利用履歴を記録し、誰がいつ使用したか追跡可能
Macie	・AIを活用したデータセキュリティサービス ・S3バケット内の個人情報 (氏名・クレジットカード番号など) を自動検出 ・意図しないデータの公開や漏洩リスクを可視化して通知

データの暗号化はS3だけではありません。サーバーの保存領域であるEBSや、データベースのRDSなども、設定を有効化するだけで暗号化できます。暗号化キーをKMSで一元管理することで保存データの漏洩リスクをさらに低減できます。

監査とログ管理 (CloudTrail・Config・CloudWatch Logs)

監査・ログ管理は、システムへの操作や変更履歴を記録し、追跡可能にするレイヤーです。

インシデント発生時の追跡やコンプライアンス遵守のために欠かせません。いつ、誰が、何をしたのかを記録しておくことで、問題が発生した際に、その原因を明らかにします。また、記録により影響範囲も特定可能です。

監査とログ管理における主なサービスと特徴は次の通りです。

CloudTrail	・AWSアカウント内のAPI操作履歴を記録するサービス ・管理イベント (リソース作成・削除など) は自動記録、S3オブジェクト操作などのデータイベントは設定で有効化可能 ・誰が・いつ・どのリソースに対し・何をしたかが追跡可能 ・セキュリティ事故の原因究明や監査対応の証跡となる
Config	・AWSリソースの設定変更履歴を記録・評価するサービス ・いつ設定が変更されたかを時系列で確認可能 ・セキュリティルールへの違反 (例: S3の公開設定) を自動検知
CloudWatch Logs	・システムやアプリケーションのログを一元的に収集・監視 ・特定のエラーコードや文字列を検知してアラート通知 ・複数のサーバーのログを集約し、分析を効率化

CloudTrailやConfigが主に「監査・統制」を目的としたサービスであるのに対し、CloudWatch Logsは、システム運用や障害対応を支えるログ管理基盤として位置づけられます。

また、ログは定期的にモニタリングし、異常があれば検知できる体制を整えることがポイントです。これらのサービスを有効化しておくことで、見えないリスクを可視化し、何かあった時の被害を少なく抑えます。

脅威検知と統合管理 (GuardDuty・Inspector・Security Hub)

脅威検知と統合管理は、システム全体の異常やリスクをリアルタイムで検知・可視化するレイヤーです。

どんなに防御を固めても、未知の攻撃や設定ミスによるリスクをゼロにすることは難しく、異常な通信や設定不備を即座に発見する仕組みが必要です。

脅威検知と統合管理における主なサービスと特徴は次の通りです。

GuardDuty	・AWS環境内のログ (CloudTrail・VPC Flow Logsなど) を機械学習で分析し、脅威を自動検知 ・不正な通信や、アカウントの乗っ取りの兆候を発見 ・設定を有効化するだけで、即座に監視の開始が可能
Inspector	・EC2インスタンスやコンテナイメージの脆弱性を自動で診断 ・OSの更新漏れや、意図しないネットワーク露出を検出 ・継続的なスキャンにより、安全な状態を維持
Security Hub	・各セキュリティサービスの検知結果を一元的に集約・管理 ・業界ガイドライン (CISベンチマークなど) に基づくスコアを可視化 ・優先度の高いリスクを特定し、迅速な対応を支援

これらのAWSのサービスを組み合わせることで、トラブルを早期に検知する体制を構築できます。特にSecurity Hubによるリスクの一元管理は、運用の効率化と迅速なインシデント対応に大きく影響します。

AWSセキュリティの設計・運用に不安がある場合は、国内25,000人以上(*1) の技術者を擁し、大手企業を中心に2,555社との取引実績 (*2) を持つ株式会社テクノプロにご相談ください。責任共有モデルを踏まえたセキュリティ設計から、AWS環境の構築、本稼働後の運用・改善まで、安全性と実務性を両立した支援が可能です。

*1: 2024年6月末時点
*2:  (株) テクノプロ及び (株) テクノプロ・コンストラクション 2024年6月末時点

AWSセキュリティにおけるレイヤー別ポイント

前章では、AWSセキュリティを構成する5つのレイヤーと主要サービスについて解説しました。ここでは、各サービスを実際に活用する際の具体的な設計指針と、ベストプラクティス (推奨設定) について解説します。

AWSが推奨する設計思想に基づき、正しく設定を行うことでセキュリティリスクを抑えることができます。

IDとアクセス管理 | IAM・IAM Identity Center・Cognitoの設計指針

IDとアクセス管理の設計において、最も避けるべきは過剰な権限付与とIDの分散管理です。

不正アクセスや誤操作による事故を防ぐために、以下の4つの指針に基づいた設計が必要です。

ルートユーザーの保護 (利用の制限)	・ルートユーザーはアカウント作成時や緊急時以外は使用しない ・アクセスキーは作成せず、コンソールログインのパスワードは厳重に管理する ・管理者を含む全ユーザーでMFAを有効化する
最小権限の原則 (IAMポリシー設計)	・不必要に強い権限を与えない ・業務に必要なアクションとリソースのみを許可するポリシーを作成する ・不要になった権限は定期的に棚卸しして削除する
IDの一元管理 (IAM Identity Centerの活用)	・個別のIAMユーザー作成は避け、IAM Identity CenterでIDを集約する ・一度のログインで複数のAWSアカウントへアクセスできる環境を構築する ・退職や異動の際に、アクセス権を即座に無効化できる体制を整える
アプリ利用者認証 (Cognitoの活用)	・自社アプリのユーザー認証には、セキュリティ機能が整ったCognitoを採用する ・認証基盤を自作せず、マネージドサービスに任せる

従来は、IAMユーザーをアカウントごとに作成してID管理を行う方法が一般的でした。
しかし、この方式ではアカウントごとにIDやパスワード（アクセスキー）を管理する必要があり、複数アカウント環境では管理負荷やID削除漏れのリスクが高まります。

こうした背景から、現在はIAM Identity Centerによる従業員IDの一元管理が推奨されています。

一方で、社内ユーザーではなく、アプリ利用者向けの認証基盤が必要な場合もあり、自社で開発するWebシステムなどのユーザー認証には、Cognitoを採用します。
Cognitoを使うことで、セキュリティアップデートの負担を減らし、MFAやソーシャルログインなどの機能も容易に実装できます。

IAM Identity Centerは従業員向けのID管理、Cognitoはアプリ利用者向けの認証基盤として使い分けるのが基本です。

ネットワーク防御 | VPC・WAF・Shieldの役割と設定例

ネットワーク防御の設計は、攻撃対象領域の最小化が重要です。インターネットに公開するリソースを限定し、多層的な防御壁を構築することでリスクを軽減します。

具体的な設計指針は以下の通りです。

VPC設計 (ネットワーク分離)	・AWS環境を外部公開エリア (パブリックサブネット) と内部隔離エリア (プライベートサブネット)に分離する ・データベースなどの重要リソースは内部隔離エリアに配置する ・外部への通信が必要な場合はNATゲートウェイ (インターネット接続用の出口) を経由させる
通信制御 (Security Group・NACL)	・Security Groupで「0.0.0.0/0 (全開放) 」の設定は避け、特定のIPアドレスやセキュリティグループのみを許可する ・NACLは、Security Groupでは対応できない特定のIP帯域ブロックなど、補助的に利用する
Web防御 (WAF・Shield)	・AWS WAFのマネージドルールを利用し、SQLインジェクション等を防ぐ ・Shield StandardでDDoS攻撃への基本的な対策を行う
保守アクセス (Session Manager)	・保守作業で利用する際は、SSHポートを開放せずにSession Managerで接続する ・Session Managerを使うことでポートを経由せず、安全に接続できる

VPC設計では、Webサーバーなど外部公開が必要なものは外部公開エリア、データベースなどの重要情報は内部隔離エリアに配置するのが一般的です。内部隔離エリアからのインターネットへのアクセス (OSの更新など) には、NATゲートウェイを利用し、外部からの直接着信を遮断しつつ必要な通信のみを許可します。

また、サーバーの保守運用において、従来のようなSSH鍵を使った接続は推奨されません。Session Managerを利用することで、SSHポートを開放せずにブラウザやCLIから安全に接続でき、さらに誰がいつ操作したかといった監査ログも記録されます。

データ保護と暗号化｜KMS・Macieによる暗号化・漏洩検知

データ保護と暗号化の設計におけるポイントは以下の2点です。

・すべてのデータを暗号化すること ・暗号化キーを自社でコントロールすること

万が一データが流出しても、解読できない状態にしておくことで被害を防ぎます。

具体的な設計指針は以下の通りです。

S3暗号化 (保管データの保護)	・S3のデフォルト暗号化設定を行う ・機密性の高いデータには、SSE-KMS (KMSキーによる暗号化) を採用する ・バケットポリシーで非暗号化通信 (HTTP) を拒否する
鍵管理 (KMSの設計)	・重要データの保護にはカスタマー管理キーを使用する ・キーの利用権限をIAMポリシーで厳格に分離する ・キーのローテーション (自動更新) を有効化する
漏洩検知 (Macieの活用)	・Macieを有効化し、S3内の機密データを自動検出する ・意図せず公開されているバケットや、個人情報が含まれるファイルを特定しアラートを通知させる

現在、S3はバケット単位でデフォルト暗号化を設定できるようになりました。セキュリティ要件が高い場合は、KMSを利用した暗号化の検討が必要です。

KMSを利用する場合、鍵の種類には「AWS管理キー」と「カスタマー管理キー (CMK) 」の2種類があります。

AWS管理キー	無料管理ポリシー (誰が使えるか) を変更できない
カスタマー管理キー	有料利用者の責任で詳細なアクセス制御や監査が可能

機密情報を扱う場合は、カスタマー管理キーの利用がベストプラクティスです。

また、データが暗号化されていても、誤ってインターネットに公開されていれば意味がありません。Macieを利用することで、機械学習がS3バケット内をスキャンし、氏名やクレジットカード番号などの機密データを自動で発見します。これにより、保存すべきでない場所に機密データが放置されているリスクを早期に検知できます。

暗号化・鍵管理・漏洩検知をセットで設計することが、AWSにおけるデータ保護の基本です。

監査とログ管理 | CloudTrail・Configによる証跡化

監査とログ管理の設計は、インシデント発生時の証拠保全とコンプライアンス要件 (監査対応) を満たすために、ログを確実に取得・保管する必要があります。

具体的な設計指針は以下の通りです。

操作ログ (CloudTrail)	・全リージョンで有効化してAPIの操作を記録する ・ログファイルは1つのS3バケットに集約して保存する ・ログの改ざんを防ぐため、S3のバージョニングやオブジェクトロックを利用する
構成管理 (Config)	・リソースの設定変更履歴を記録し、変更前の状態を確認可能にする ・S3バケットが公開されていないかなどのルールを適用し、違反を自動検知する ・コンプライアンス基準への準拠状況を継続的に評価する
ログ保管 (S3・KMS)	・集約したログはKMSで暗号化して保存する ・保管期間 (ライフサイクル) を設定し、古いログは安価なストレージクラスへ移行する

特にCloudTrailは、全リージョンで有効化しないと監査の抜け漏れが発生します。また、取得したログ自体が改ざんされないよう、保存先S3のアクセス制御と暗号化も重要な設計ポイントです。

構成管理は、Configで事前に定義されたマネージドルールを利用します。これにより、セキュリティのベストプラクティスに沿っているかの自動チェックが可能です。例えば、「セキュリティグループで全開放ポートがあるか」などを常に監視し、違反があれば即座に通知する仕組みを構築します。

脅威検知と統合管理｜GuardDuty・Inspector・Security Hubの連携活用

脅威検知と統合管理では、防御壁をすり抜ける攻撃や運用で発生する設定不備を見逃さないために、継続的な監視と評価が必要です。

具体的な設計指針は以下の通りです

脅威検知 (GuardDuty)	・全リージョンで有効化し、悪意のある通信や不正利用を監視する ・検出結果はEventBridge等と連携し、管理者への即時通知を設定する
脆弱性管理 (Inspector)	・EC2インスタンスなどに対する継続的なスキャンを有効化する ・OSやソフトウェアの脆弱性が発見された場合、パッチ適用などの対応フローを整備する
統合管理 (Security Hub)	・GuardDuty・Inspector・Configなどの検出結果をSecurity Hubに集約する ・業界ガイドライン (CISベンチマークなど) に基づくセキュリティスコアを可視化し、改善の指標とする

GuardDutyは、有効化するだけでVPCフローログなどを機械学習で分析し、不正な通信やアカウントの悪用を自動検知します。追加の設定負荷が少ないため、全アカウント・全リージョンでの有効化が推奨されます。

脆弱性管理は、Inspectorを使い、EC2やECR (コンテナイメージ) の脆弱性を管理します。脆弱性は日々新たに発見されるため、一度きりの診断ではなく継続的にスキャンし続けることが重要です。Inspectorは自動でスキャンを行い、リスクの高い脆弱性を特定します。

これらの情報は個別に確認するのではなく、Security Hubで統合管理します。GuardDuty (脅威) ・Inspector (脆弱性) ・Config (設定不備) の結果を集約することで、セキュリティスコアとして現状を数値化 (可視化) が可能です。スコアにより、対応すべき優先順位が明確になり、効率的なセキュリティ運用が可能となります。

AWSセキュリティでよくあるリスク｜設計・運用で起きがちな失敗と対策

AWSにおける多くのセキュリティ事故は、利用者の設定ミスや管理不備に起因します。

ここでは、実際に発生しやすいセキュリティ事故のパターンと、その原因・対策を解説します。リスクの具体例を知ることで、自社の環境に潜む危険性を再確認し、予防策を講じることが可能です。

アカウント乗っ取り (IAM・MFAの不備)

セキュリティのトラブルで頻繁に発生しているのがアカウントの乗っ取りです。

主なパターンは以下2点です。

・アクセスキーの漏洩 ・不正ログイン (パスワード突破)

アカウント乗っ取りは被害が大きく、管理者権限を奪われた場合、AWSやシステムのあらゆる操作を許すことになります。原因を理解して、対策を取ることが大切です。

アカウント乗っ取りは主に「アクセスキー漏洩」と「不正ログイン」の2パターンがあります。それぞれの被害や原因、対策は以下の通りです。

▼アクセスキー漏洩

想定される被害	・不正利用による高額な料金請求 ・他社への攻撃拠点 (踏み台) として利用
原因	・プログラムへのアクセスキー埋め込み ・GitHub等への誤公開 ・PCのウイルス感染
対策	・IAMロールを利用してアクセスキーを発行しない ・git-secrets等を使い、機密情報 (アクセスキーなど) の誤ったコミットを防止 ・アクセスキーを定期的にローテーション (交換) する ・使用していないアクセスキーは無効化または削除する

▼不正ログイン

想定される被害	・管理者権限の不正利用 ・機密情報の漏洩や削除 ・サービスの停止やデータ消失
原因	・推測されやすいパスワードの使用 ・パスワードの使い回し ・MFAの未設定
対策	・できる限り、全ユーザーに対してMFAの利用を必須設定とする ・できる限り、IAMユーザーの個別作成は避け、Identity Centerで一元管理する ・パスワードのルールを厳格化する (文字数の増加や組み合わせの複雑化)

アカウントの乗っ取りで特に多いのは、発行したアクセスキーを誤ってGitHubなどに公開してしまうケースです。

攻撃者は自動化ツールを使って公開されたキーを数分以内に検知し、不正利用を開始します。一度乗っ取られると、数十万〜数百万円もしくはそれ以上の高額請求が発生することもあります。

このことから、アクセスキーの管理とMFAの徹底は優先して対応すべき課題です。

S3バケットの誤設定と情報漏洩

アカウント乗っ取りと並んで頻発する事故が、S3バケットの公開設定ミスによる情報漏洩です。S3の設定を誤ると、保存したファイルがインターネットから誰でも閲覧・ダウンロードできる状態になってしまいます。

主な被害・原因・対策は以下の通りです。

想定される被害	・機密情報の漏洩 (顧客リスト・個人情報・設計書など) ・社会的信用の失墜 ・損害賠償の発生
原因	・パブリックアクセスブロック (外部公開の禁止機能) 設定を誤って無効化している ・バケットポリシー (アクセスルール) で誤ったアクセス権限を設定している
対策	・パブリックアクセスブロックの設定をアカウントレベルで有効化する (デフォルト設定の確認) ・バケットポリシーでアクセス権限を適切に制御する ・Macieを利用して機密データの公開リスクを監視する

効果的な対策は、S3の機能であるパブリックアクセスブロックの有効化です。設定を有効化しておけば、仮に作業者が誤って公開するという操作をしても、AWS側で強制的にブロックされます。

マルウェア感染・悪用 (EC2・Lambdaの脆弱性)

マルウェア感染は、OSやソフトウェアの更新を放置し、脆弱性（セキュリティホール）を残したままにしていることが主な原因です。感染したサーバーは、自社システムへの被害だけでなく、攻撃者によって他社への攻撃拠点として悪用されることもあります。

主な被害・原因・対策は以下の通りです。

想定される被害	・他社への攻撃拠点としての悪用 (DDoS攻撃の加担など) ・ランサムウェアによるデータの暗号化・身代金要求 ・クリプトジャッキング (勝手に仮想通貨マイニングを行われる)
原因	・OSやミドルウェアのセキュリティパッチ適用漏れ ・不要なポートの開放Webアプリケーションの脆弱性 (SQLインジェクションなど)
対策	・Systems Manager (Patch Manager) を利用してOSパッチの管理・適用を徹底する ・Inspectorを利用して脆弱性を継続的にスキャンする ・GuardDutyを利用してマルウェアの活動や異常通信を検知する

特にOSの更新漏れは、注意が必要です。新しい脆弱性は日々発見されるため、構築時に安全だったサーバーも、時間が経てば危険な状態になります。Inspectorを利用して、サーバーやコンテナの脆弱性スキャンを継続的に実施し、発見されたリスクには即座にパッチ適用が必要です。

監査・ログ未設定による見えないリスク

セキュリティ対策をしていても、100%防御することは非常に難しいです。このため、「いつ・誰が・何をしたか」という記録 (ログ) が重要になります。ログ設定が不十分だと、万が一の事故発生時に原因究明ができません。したがって、被害範囲の特定が難しくなり、見えないリスクを抱えることになります。

主な被害・原因・対策は以下の通りです。

想定される被害	・不正操作の犯人や侵入経路が特定できず、トラブルの根本を解決できない ・被害に気づくのが遅れ、情報流出が長期間続いてしまう ・コンプライアンス監査や法的な説明責任を果たせない
原因	・CloudTrailが無効、または「使用しているリージョンのみ」有効にしている ・Configによる構成変更の記録が行われていない ・VPCフローログ (通信記録) が取得されていない ・ログの保存期間が短く、調査時点ですでに消えている
対策	・CloudTrailを全リージョンで有効化し、ログをS3に集約する ・Configを有効化し、リソースの設定変更履歴を記録する ・VPCフローログを有効化し、通信トラフィックを記録する ・S3のライフサイクル設定等を利用し、ログを長期間安全に保管する

ログは、飛行機のフライトレコーダーと同じ役割を持ちます。事故が発生した際、ログがなければ何が起きたのかを正確に説明できず、原因究明や再発防止も困難になります。
そのため、CloudTrailは利用状況に関わらず全リージョンで有効化し、確実に記録を残すことが重要です。

AWSセキュリティ対策の優先順位 | 目的別 × 3段階アプローチ

AWSのセキュリティ対策は、ビジネスのフェーズやシステムの規模に合わせて優先順位をつけながら段階的に導入していくことが大切です。
ここでは、導入すべきセキュリティ対策を3つのフェーズに分けて解説します。

最低限構成 | 初期構築フェーズ (MFA ＋ S3 ＋ CloudTrail)

最低限構成は、AWSアカウントを作成後に実施すべきセキュリティ対策です。
これらは推奨ではなく必須設定であり、未設定の場合はアカウント自体が危険な状態となるため注意が必要です。

具体的な対象と対策は以下の通りです。

ID管理 (不正侵入防止)	・ルートユーザーのMFAを設定する ・作業用のIAMユーザーまたはIAM Identity Centerを利用し、ルートユーザーの使用を停止する ・作成したIAMユーザーにもMFAを強制する
データ保護 (漏洩防止)	・S3のパブリックアクセスブロックをアカウントレベルで有効化し、意図しないデータ公開を根元から防ぐ
ログ記録 (証跡確保)	・CloudTrailを全リージョンで有効化し、操作ログをS3に保存する

まずは「玄関の鍵をかける (MFA) 」「窓を閉める(S3ブロック) 」「監視カメラをつける (CloudTrail) 」という流れで、セキュリティの基礎を固めます。これらはコストもほとんどかからないため、対策を行うべき基本的な設定です。

標準構成 | 監査対応フェーズ (GuardDuty ＋ Config ＋ Security Hub)

標準構成は、本番環境での運用を開始し、社内のコンプライアンス基準や外部監査に対応するための構成です。
脅威を自動検知し、システムの状態を可視化することで、継続的なセキュリティ運用を可能にします。

具体的な対象と対策は以下の通りです。

脅威検知 (侵入発見)	・GuardDutyを有効化し、マルウェア通信や不正な振る舞いを24時間365日監視する
構成管理 (ルール監査)	・Configを有効化し、リソースの設定変更履歴を記録する ・不要なSSHポートやRDPポートの開放を検出するルールを設定し、違反を自動検知する
可視化 (統合管理)	・Security Hubを有効化し、GuardDutyやConfigの検出結果を一元管理する ・セキュリティスコアを活用し、現状のリスクレベルを可視化する

人間が手動でログを監視するのではなく、AWSのマネージドサービスを使い、異常があれば通知が来る仕組みを構築します。これにより、運用負荷を抑えながら高い安全性を維持できます。

強化構成 | ゼロトラスト・自動化フェーズ (Control Tower ＋ Lambda修復 ＋ SSO)

強化構成は、高度なセキュリティ体制 (ゼロトラスト) や運用自動化を目指す構成です。
複数のAWSアカウントを持つ組織や大規模なシステムを運用する企業において、ガバナンス強化と運用の効率化を実現します。

具体的な対象と対策は以下の通りです。

統制管理 (ガバナンス)	・Control Towerを導入し、マルチアカウント環境のガバナンスを強化する ・組織全体のセキュリティポリシーを強制的に適用する ・ログの削除禁止など、組織で決めたセキュリティルール (ガードレール) を全アカウントに適用する
ID統合 (SSO)	・IAM Identity Center (旧AWS SSO) を利用してID管理を一元化する ・個別のIAMユーザー管理を廃止し、シングルサインオンを実現する
自動化 (自動修復)	・Lambdaを活用し、検知したセキュリティリスクを自動的に修復する 例：セキュリティグループで危険なポートが開放された際、即座に自動で閉じる

強化構成は、手作業によるミスを排除し、組織全体で統一されたセキュリティレベルを維持することが目的です。特にIdentity CenterによるSSOは、利便性と安全性を両立できることから、組織の規模が大きくなる前に導入の検討が必要です。

AWSセキュリティの費用感とコスト最適化

AWSのセキュリティ対策には一定のコストがかかりますが、事故発生時の損害と比べると、必要な投資であるケースがほとんどです。

各サービスは従量課金が基本となるため、課金体系を理解したうえで、予算に応じた適切なサイジングを行うことが重要です。

主要サービス別料金比較 (GuardDuty・Security Hub・WAF・Shield)

AWSのセキュリティサービスは従量課金が基本的な料金体系です。サービスごとに課金の基準が異なります。課金の基準を理解して利用することが大切です。

主要なサービスの料金体系と特徴は以下の通りです。

GuardDuty (脅威検知)	・分析するログの種類と量に応じた課金 ・CloudTrailイベント (100万イベント単位) ・VPCフローログやDNSログ (GB単位) で計算
Security Hub (統合管理)	・セキュリティチェック実行回数と、他サービスにおける検出結果の取り込み数に応じた課金 ・業界ガイドライン (CISベンチマークなど) の実行回数とサードパーティからの検出結果取り込み数で計算 　* GuardDutyやInspectorなど、他のAWSサービスからの検出結果取り込みは無料
WAF (Web防御)	・Web ACL (ルールセット) 数・ルール数・リクエスト数に応じた課金 ・Web ACL (月額固定) ・含まれるルール数 (月額固定) ・検査したリクエスト数 (100万件単位) で計算
Shield (DDoS対策)	・Advancedは月額3,000ドル (組織単位・年間契約) の固定費 ・DDoS攻撃時のデータ転送料は免除される (コスト保護機能) ・Standardは無料 (全AWSユーザーに自動適用)

Shield Advancedは月額3,000ドルの固定費が発生します。DDoS攻撃のリスクが高い大規模なエンタープライズ環境や、高トラフィックのWebサービス向けといえます。

コストと安全性を両立するベストプラクティス (Well-Architected Framework準拠)

AWSには「AWS Well-Architected Framework」という、クラウド運用のベストプラクティスを体系化したフレームワークがあります。

フレームワークにはセキュリティに関して「セキュリティの柱」として記載されています。この柱に沿って設計・運用することで、例えば以下のように、無駄なコストを抑えつつ、安全性の高いシステムを構築できます。

・マネージドサービスを活用して運用工数を削減 ・自動化によって手動作業のミスとコストを削減

一方で、コストと安全性のバランスを見極めることも大切です。
すべてのデータやシステムに対して、一律に高いレベルのセキュリティ対策を講じると、コストが過剰になる恐れがあります。守るべき情報の重要度に応じてリスクを分類し、必要な箇所に予算を集中させることが重要です。

このように、守るべき資産とリスクに応じて対策の強弱をつけることが、AWSにおけるコスト最適化のポイントとなります。

AWSセキュリティの継続的改善フロー | 可視化・自動化・IaC

AWSセキュリティは、一度設定して終わりではなく、継続的に改善し続ける運用プロセスです。
サイバー攻撃の手法は日々進化しており、ビジネスに伴うAWS環境の変化に対応し続ける必要があります。

ここでは、AWSのマネージドサービスを活用して、セキュリティ状態を可視化し、運用を効率化 (自動化) するサイクルについて解説します。

Security Hubによるスコア可視化と改善サイクル

Security Hubを活用することで、セキュリティ状態を数値化し、継続的にPDCA (改善サイクル) を回すことができます。

Security Hubは、以下に基づいて、AWS環境の設定状況を自動的にチェックします。

・業界ガイドライン (CISベンチマークなど) ・AWSが推奨するセキュリティのベストプラクティス

チェックの結果は、各セキュリティ標準ごとに0〜100%のセキュリティスコアが表示され、全体のサマリースコアも確認できます。

スコアを指標として、以下のPDCAを回します。

現状の可視化	定期的にセキュリティスコアを確認する
問題の特定	スコア低下の原因となっている重要度の高い問題を特定する
対策の実施	検出された設定不備や脆弱性を修正する
効果の確認	自動再評価により、スコアが改善されたことを確認する

PDCAを回すことで、セキュリティレベルを確実に維持・向上させることができます。

AWS Configルール・EventBridgeによる自動監査フロー

Configを利用することで、社内のセキュリティルールに違反しているリソースを自動的に検出できます。セキュリティ運用の負荷を減らすためには、Configを使った自動監査の仕組みが有効です。

Configでは、「S3バケットを公開しない」「EBSを暗号化する」といったルール (Configルール) を定義します。AWSが提供するマネージドルールを使えば、一般的なベストプラクティスをすぐに適用できます。独自の要件がある場合はカスタムルールを作成することも可能です。

Configルールによる自動監査は、以下の流れで実行されます。

1.検知 (検出)	Configルールが違反 (非準拠) を検知し、EventBridgeへ検知イベントを発行する
2.起動 (トリガー)	EventBridgeが検知イベントをトリガーとしてSNSを呼び出す
3.通知 (送信)	SNS (通知サービス) は管理者に違反を通知する

これにより、問題の発見から対応開始までの時間を大幅に短縮できます。

EventBridge・Lambda・SNS・Slack (Chatbot連携) による自動通知フロー

検知したリスクを迅速に対応へつなげるためには、通知経路の自動化が重要です。Security HubやGuardDutyなどが検知したイベントは、以下の流れで処理・通知されます。

1.検知 (検出)	Security HubやGuardDutyが脅威を検知し、EventBridgeへ検知イベントを発行する
2.起動 (トリガー)	EventBridgeが検知イベントをトリガーとして、Lambda (整形処理) を起動する
3.整形 (処理)	Lambdaがイベント情報から「何が起きたのか」「重要度」などを抽出し、読みやすいメッセージに整形して、SNSを呼び出す
4.通知 (送信)	SNSはSlack (AWS Chatbot連携) に脅威の内容を通知する

このようなフローを構築することで、担当者は管理画面を常時監視する必要がなくなります。重要なアラートが即座に通知され、インシデント発生時に迅速な対応が可能です。

Lambda・Systems Managerによる自動修復フロー

AWSでは、自動通知に加え、特定の単純なインシデントに対して自動修復フローを構築することも可能です。例えば、Security Groupで意図せず危険なポートが全開放された場合、以下の流れで自動修復が実行されます。

1.検知 (検出)	Configルールが違反を検知し、EventBridgeへ検知イベントを発行する
2.実行 (トリガー)	EventBridgeが検知イベントをトリガーとして、Lambda (自動修復プログラム) を起動する
3.修復 (実行)	LambdaはSystems ManagerのAutomationドキュメント (手順書) を実行し、ポートを閉じる

自動修復は、設定を誤ると正常な通信まで遮断してしまうなど、意図しない影響を及ぼすリスクがあります。最初は通知のみから始め、影響範囲が限定的なものからスモールスタートで導入することが大切です。

CloudFormationとIaCによるセキュリティ設定の自動化フロー

セキュリティレベルを長期的に維持するためには、インフラ構築をコード化するIaCの導入が推奨されます。AWSの代表的なネイティブのIaCサービスは「CloudFormation」です。

CloudFormationを利用すると、セキュリティ設定を含むインフラ構成をテンプレート (コード) として記述できます。テンプレートにより、手動操作による設定ミスを排除し、何度でも同じ環境を自動で構築することが可能です。

CloudFormationと監視サービスを連携させた運用は、以下の流れで実行されます。

1.検知 (検出)	Security HubやConfigが不備を検知し、EventBridgeへ検知イベントを発行する
2.起動 (トリガー)	EventBridgeが検知イベントをトリガーとして、SNSを呼び出す
3.通知 (送信)	SNSは管理者に不備の内容を通知する
4.修復 (適用)	管理者は検出された不備に対して、個別リソースを手動修正するのではなく、CloudFormationのテンプレートを修正し、同じ構成を再展開する

これにより、最新の構成をコードとして一元管理でき、正常なセキュリティ状態を自動的に維持することが可能です。個別リソースの手動修正ではなく、常にテンプレートを修正して適用することで、構成のズレを防ぎ、長期的に安定したセキュリティ運用を実現できます。

まとめ

AWSのセキュリティ対策は、一度導入して終わりではなく、継続的に改善し続けるプロセスです。記事で解説したIDとアクセス管理・ネットワーク防御・データ保護と暗号化・監査とログ管理・脅威検知と統合管理という「5つのレイヤー」を意識し、まずはMFAやS3のブロック設定といった「最低限の構成」から始めることが重要です。その上で、Security HubやConfigなどのマネージドサービスを活用し、リスクの可視化と自動化を進めることで、運用負荷を抑えながら環境を維持できます。

クラウドサーバーの構築支援なら、国内25,000人以上 (*1) の技術者を擁し、大手企業を中心に2,555社との取引実績 (*2) を持つ株式会社テクノプロにお任せください。AWS導入の準備段階からビジネス設計、本稼働、運用まで、一括して任せることができます。
*1: 2024年6月末時点
*2:  (株) テクノプロ及び (株) テクノプロ・コンストラクション 2024年6月末時点