AWSの利用範囲が広がるにつれ、セキュリティ設定は個別最適になりがちです。AWSと自社の責任範囲が曖昧なままだと、パッチの未適用や過剰な権限付与、ログの取得漏れなどが見過ごされ、インシデントにつながるおそれがあります。
何から手を付けるべきか迷う方も多いのではないでしょうか。本記事では、AWS クラウドセキュリティを責任共有モデルから整理し、優先順位の決め方と進め方を具体的にご紹介します。

AWSクラウドセキュリティは責任共有モデルから考える

結論として、AWSを使っても、セキュリティ対策が不要になるわけではありません。責任共有モデルを前提に、自社の責任範囲を明確にして対策することが出発点です。本記事では、対策領域を次の6つに分けて整理します。

• 権限管理：IAMで、誰が何をできるかを管理する
• ネットワーク：外部に公開する範囲を最小化する
• データ保護：暗号化とキー管理の基準をそろえる
• ログと監査：操作の記録を残す
• 監視・検知：脅威を見つけ、素早く対応する
• 継続改善：ベストプラクティスで見直し続ける

AWSと利用者の責任範囲

AWSの公式情報（AWS責任共有モデル）では、セキュリティとコンプライアンスは、AWSと利用者の共有責任と説明されています。AWSは「クラウドのセキュリティ」を担い、利用者は「クラウドにおけるセキュリティ」を担います。

AWSが担うのは、データセンターの施設、ハードウェア、ネットワーク、仮想化の基盤などです。利用者が担うのは、データの管理、アクセス権限の設定、OSやアプリケーションの更新などです。つまり、基盤が守られていても、設定の不備や権限の与えすぎは利用者側の課題です。

利用するサービスによって変わる責任範囲

利用者の責任範囲は、選ぶサービスによって変わります。公式情報では、Amazon EC2のようなIaaS（インフラを借りる形態）は、必要なセキュリティ設定と管理を利用者が行うと説明されています。

EC2では、ゲストOSの更新、アプリケーションの管理、Security Groupの設定が利用者の担当です。一方、Amazon S3のような抽象化されたサービスでは、AWSがOSやプラットフォームまで運用します。利用者は、データの暗号化、資産の分類、IAMの権限設定を担います。

サービスの種類	例	AWSが担う範囲	自社が担う範囲
IaaS	Amazon EC2	物理基盤、仮想化	OSの更新、アプリ、Security Group、データ、権限
抽象化されたサービス	Amazon S3、DynamoDB	インフラ、OS、プラットフォーム	データの管理、暗号化、資産の分類、権限
サーバーレス	AWS Lambda	実行基盤、OS	コード、権限、データ

利用するサービスが変われば、責任範囲も変わります。移行や新しいサービスの採用のたびに、見直しましょう。

責任範囲を対策の優先度に落とし込む方法

責任範囲が分かったら、自社が担う部分を対策領域に分けます。進め方は、次の3ステップです。

1. 利用中のサービスごとに、自社の責任範囲を書き出す
2. 書き出した内容を、6つの対策領域に分類する
3. 領域ごとに現状を確認し、不足している対策を洗い出す

洗い出した対策の優先順位は、「リスクの大きさで優先順位を決める」で整理します。各領域の詳細は、次の章以降をご覧ください。

IAMで権限を管理し最小権限を実現する

IAM（AWS Identity and Access Management）は、AWSの操作権限を管理するサービスです。誰が、どのリソースに、何をできるかを定義します。権限が広すぎると、問題が起きたときの被害も広がります。

ルートユーザーの保護とIAMロールの基本

ルートユーザーは、AWSアカウントで最も強い権限を持つユーザーです。公式情報では、ルートユーザーが必要な作業以外では使わないことが強く推奨されています。また、ルートユーザーにはMFA（パスワードに加えて、もう1つの認証要素を使う仕組み）の設定が必要です。

日常の作業には、IAMロール（一時的に権限を引き受ける仕組み）を使います。公式のベストプラクティスでは、人とワークロードの両方で、一時的な認証情報を使うことが推奨されています。長期のアクセスキーに頼らない運用が基本です。

社内にID基盤がある場合は、IDフェデレーション（社内のIDでAWSにログインする仕組み）も検討しましょう。IAMユーザーが必要な場合は、MFAを必須にします。

最小権限ポリシーと権限棚卸し

最小権限とは、作業に必要な権限だけを与える考え方です。公式情報では、まずAWS管理ポリシーから始め、段階的に権限を絞り込む進め方が示されています。ただし、AWS管理ポリシーは多くの利用者向けのため、自社にとって最小権限とは限りません。

絞り込みには、IAM Access Analyzerが役立ちます。実際に使われた操作をもとに、最小権限のポリシー案を生成できます。外部に共有されているリソースの確認にも使えます。

定期的な権限棚卸し（付与済みの権限を見直す作業）も欠かせません。使われていないユーザーやロールは、削除を検討します。異動や退職のタイミングに合わせて実施すると、権限過多を防ぎやすくなります。

ネットワークセキュリティで公開範囲を最小化する

ネットワークの対策は、外部に公開する範囲を最小限にすることが基本です。通信の入口を絞り、内部の経路も分けることで、被害の広がりを抑えられます。

VPCとサブネット設計の基本

VPC（Amazon Virtual Private Cloud）は、AWS上に作る専用の仮想ネットワークです。VPCの中をサブネット（ネットワークの区画）に分けて、役割ごとに配置します。

基本は、外部に公開するものと、公開しないものを分けることです。たとえば、Webサーバーは公開側、データベースは非公開側のサブネットに置きます。インターネットへの経路を持たないサブネットを使えば、公開範囲を狭められます。

AWS内のサービスにインターネットを経由せず接続したい場合は、AWS PrivateLinkが使えます。プライベートな経路でサービスに接続する仕組みです。

Security GroupとNetwork ACLの使い分け

Security Groupは、サーバーなどの単位で、通信を許可する範囲を決める設定です。Network ACLは、サブネットの単位で、通信を許可または拒否する設定です。違いは、次のとおりです。

観点	Security Group	Network ACL
適用の単位	サーバーなどのリソース	サブネット
設定の考え方	許可する通信を指定する	許可と拒否の両方を指定する
戻りの通信	自動で許可される	個別に設定が必要
主な用途	日常的な通信制御	サブネット単位の追加の防御

日常的な制御は、Security Groupが中心です。Network ACLは、サブネット全体への追加の防御として使います。AWSの成熟度モデルでも、危険な通信ポートのブロックは、早期に取り組む項目とされています。

AWS WAFとAWS Shieldによる外部攻撃対策

AWS WAFは、Webアプリケーションへの不正なリクエストを防ぐサービスです。ルールに沿って不審な通信を検知し、遮断します。AWSなどが提供するマネージドルール（ルールのセット）も使えます。

AWS Shieldは、DDoS攻撃（大量のアクセスで業務を妨げる攻撃）への対策サービスです。より高度な保護を行う上位版もあります。公開するWebサービスの重要度に応じて、適用範囲を決めましょう。

暗号化とキー管理でデータ保護の基準をそろえる

データ保護では、守る強さの基準をそろえることが重要です。まずデータを重要度で分類し、分類ごとに暗号化の方針を決めます。方針の例は、次のとおりです。

分類	例	暗号化の方針
機密	個人情報、取引情報	暗号化を必須にし、鍵も厳格に管理する
社内限定	社内文書、業務データ	暗号化を標準にする
公開可	公開済みの資料	必要に応じて判断する

保存時と通信時の暗号化の基本

暗号化は、守る場面で2つに分けられます。

• 保存時の暗号化：ストレージやデータベース内のデータを守る
• 通信時の暗号化：ネットワークを流れるデータを守る

両方を組み合わせると、漏えいのリスクを下げられます。AWSの成熟度モデルでは、保存時の暗号化は基礎の段階、通信の暗号化は効率化の段階です。まず保存時の暗号化から着手しましょう。

AWS KMSの役割とキー管理の注意点

AWS KMS（AWS Key Management Service）は、暗号化に使う鍵を作成・管理するサービスです。多くのAWSサービスと連携できます。キー管理の注意点は、次の3つです。

• 権限を分ける：鍵を管理する人と、使う人を分ける
• 使用状況を記録する：CloudTrailで、鍵の使用を追跡する
• 削除に注意する：鍵を削除すると、暗号化したデータが読めなくなるおそれがある。削除前の確認手順を決めておく

ログ管理と監査で操作の記録を残す

ログは、インシデント対応と監査の両方で土台になります。何が起きたかを後から追えなければ、原因の特定も、監査への説明もできません。

CloudTrailとAWS Configの役割

CloudTrailは、AWSアカウント内の操作を記録するサービスです。誰が、いつ、何をしたかを、API呼び出しの履歴として残します。

公式情報では、イベント履歴で直近90日分の管理イベントを確認できると説明されています。ただし、これは恒久的な記録ではありません。長期保存には、証跡（トレイル）を作成して、S3へ配信します。

AWS Configは、リソースの設定変更を記録し、ルールに沿っているかを評価するサービスです。CloudTrailが「操作」を残すのに対し、Configは「設定の状態」を残します。想定した構成からのずれ、つまりドリフトの検知にも役立ちます。

ネットワークやアクセスのログの使い分け

CloudTrailとConfig以外にも、用途別のログがあります。目的に合わせて、必要なものを有効にします。

ログ	記録する内容	主な用途
VPC Flow Logs	VPCの通信の情報	不審な通信の調査
ALBログ	ロードバランサーへのリクエスト	Webアクセスの追跡
S3アクセスログ	S3へのアクセス要求	データ参照の追跡
CloudWatch Logs	アプリやサービスのログ	集約、検索、アラーム

すべてを一度に有効にする必要はありません。重要なシステムから順に、記録の範囲を広げましょう。

ログのまとめ方・保管期間・改ざん対策

ログは、1か所にまとめて保管するのが基本です。CloudTrailのドキュメントでは、専用のS3バケットに証跡を保存し、ログ保管用のアカウントを使う構成が示されています。AWS Organizationsを使う場合は、組織全体のログを記録する組織の証跡も作れます。

改ざん対策には、CloudTrailのログファイル整合性検証が使えます。ログが削除または変更されていないかを、確認できる機能です。あわせて、ログをKMSで暗号化し、保管先のアクセス権限も絞ります。

保管期間は、社内規程や監査の要件に合わせて決めます。具体的な年数は、自社の要件から逆算してください。

監視・検知とインシデント対応を運用に組み込む

ログを残すだけでは、異常に気づけません。検知の仕組みと、気づいた後の動きまで、運用に組み込む必要があります。

GuardDutyで脅威を検知する

Amazon GuardDutyは、AWSアカウントやワークロードを監視し、不正な活動や異常な動作を検知する、脅威検出サービスです。公式情報では、異常検出、機械学習、脅威インテリジェンスを組み合わせると説明されています。

EC2、コンテナ、サーバーレスなど、複数の実行環境を保護できます。S3やデータベース向けの保護機能も用意されています。検出結果は、Security HubやEventBridgeに転送できます。

まずは、基本の脅威検出を有効にするのが現実的です。AWSの成熟度モデルでも、基本の脅威検出は、クイックウィンの1つです。

Security Hubで検出結果をまとめて優先順位を付ける

AWS Security Hubは、セキュリティの検出結果を統合し、重大な問題に優先順位を付けるサービスです。公式情報では、シグナルを相互に関連付け、対応すべき問題を判断しやすくすると説明されています。

なお、Security Hubは2025年12月に一般提供が始まった統合サービスで、GuardDuty、Amazon Inspector、Amazon Macie、Security Hub CSPMのシグナルを相関分析します。従来のSecurity Hubの機能である設定のチェックなどは、現在はSecurity Hub CSPMとして提供されています。

GuardDutyが「見つける」役割なら、Security Hubは「まとめて、優先順位を付ける」役割です。企業全体の状況を一元的に確認できるため、運用の手間も抑えられます。

観点	GuardDuty	Security Hub
役割	脅威の検出	検出結果の統合と優先順位付け
主な使い方	不審な動きを見つける	全体を見て、対応の順番を決める
連携	結果をSecurity Hubなどへ転送する	複数のサービスの結果を受け取る

なお、Security Hubは機能やプランの更新が続いています。導入時は、公式の機能ページと料金ページで、最新の内容を確認してください。

通知・連絡経路・自動対応の考え方

検知した結果は、確実に担当者へ届ける必要があります。Amazon EventBridgeは、AWS上のイベントをきっかけに、処理を起動する仕組みです。検出結果を、メールやチャットへの通知、チケットの起票につなげられます。

さらに、AWS Lambda（サーバーを用意せずにプログラムを実行するサービス）やAWS Systems Managerを使うと、対応の一部を自動化できます。たとえば、侵害の疑いがあるサーバーを、ネットワークから切り離す処理です。ただし、誤検知の影響が大きいため、段階的に導入します。

運用の前に、重大度ごとの連絡経路を決めておきます。たとえば、重大度が高いものは即時に担当者へ、低いものは日次でまとめて確認します。成熟度モデルでも、対応手順書であるインシデント対応のプレイブックが、基礎の対策に挙げられています。

AWS Well-Architectedを使って改善を続ける

セキュリティ対策は、一度整えて終わりではありません。AWS Well-Architectedなどの枠組みを使い、定期的に見直す仕組みが必要です。

セキュリティ設計の要点

AWS Well-Architected Frameworkは、6つの柱で構成されています。そのうち、セキュリティの柱は、安全なワークロードを設計・運用するためのベストプラクティスを示しています。

公式のホワイトペーパーでは、データとシステムを保護し、アクセスを制御し、セキュリティイベントに自動的に対応する設計が目指す姿とされています。

実践には、AWS Well-Architected Toolによるレビューが役立ちます。ワークロードをベストプラクティスに照らして評価し、改善点を洗い出せます。

AWSセキュリティ成熟度モデルは、対策の優先順位付けを支援します。クイックウィン、基礎、効率化、最適化の4段階で、推奨事項が整理されています。

複数アカウントの分け方と全社ルール

AWSの利用が広がると、アカウントが増えます。環境ごと、システムごとにアカウントを分けると、影響範囲を限定できます。成熟度モデルでも、マルチアカウント管理は、基礎の対策に位置づけられています。

AWS Organizationsは、複数のアカウントを一元的に管理するサービスです。AWS Control Towerは、複数アカウントの環境を、推奨される構成で整えるサービスです。全社共通のルール（ガードレール）を、アカウントに一括で適用できます。

ルールの例は、利用できるリージョンの制限や、ログの無効化の禁止などです。個人の判断に頼らず、仕組みで守る形にしましょう。

脆弱性対応と構成管理で設定のばらつきを防ぐ

脆弱性管理は、ソフトウェアの弱点を見つけて修正する取り組みです。Amazon Inspectorは、EC2やコンテナイメージなどの脆弱性を自動でスキャンします。パッチの適用は、AWS Systems Managerで一括して行えます。

設定のばらつきを防ぐには、IaC（構成をコードで管理する手法）が有効です。同じ構成を繰り返し作れるため、手作業による設定ミスを減らせます。成熟度モデルでは、効率化の段階に位置づけられています。

変更管理では、構成の変更を記録し、承認を経て反映する流れを整えます。想定外の変更は、AWS Configでのドリフト検知で見つけます。

AWSクラウドセキュリティ対策の進め方

ここまでの内容を、実際の進め方に落とし込みます。現状診断、初期対策、監視の整備、運用の定着の順に進めるのが基本です。

リスクの大きさで優先順位を決める

対策の領域が多いため、すべてを同時に進めるのは現実的ではありません。リスクの大きさで優先順位を決めます。判断の軸は、次の3つです。

• 影響の大きさ：漏えいや停止が起きた場合の、業務や顧客への影響
• 起こりやすさ：インターネットへの公開や、権限の広さなどの状況
• 対策のしやすさ：必要な工数や費用

AWSセキュリティ成熟度モデルは、実装のしやすさ、コスト効率、改善の効果をもとに、推奨事項を4つの段階に分けています。迷った場合は、クイックウィンから着手するのが現実的です。

判断の例を挙げます。インターネットに公開している業務システムでは、権限と公開範囲の確認を最優先にします。社内向けの小規模な環境では、ログと基本の検知から始めます。

最初に確認すべき初動10項目

初動では、効果が大きく、取り組みやすい項目から確認します。成熟度モデルのクイックウィンを参考に、10項目を抜粋しました。

1. セキュリティ連絡先の登録：AWSからの通知を、担当者が受け取れるようにする
2. ルートユーザーの保護：MFAを設定し、日常の利用を避ける
3. MFAの適用：人が使うIDに、MFAを設定する
4. IDフェデレーション：社内のIDで、一時的な権限を使う
5. 意図しない権限の確認：IAM Access Analyzerで、外部への共有を確認する
6. CloudTrailの有効化：API呼び出しを記録する
7. GuardDutyの有効化：基本の脅威検出を始める
8. Security Hub（CSPM）の導入：設定の不備を継続的にチェックし、検出結果を統合する
9. 危険な通信ポートの確認：Security Groupの開放範囲を絞る
10. パブリックアクセスのブロック：意図しない公開を防ぐ

これらを一度に完了する必要はありません。現状診断で未対応の項目を洗い出し、順に進めましょう。

運用体制・役割分担・費用の考え方

セキュリティは、導入後の運用が成否を分けます。役割分担を決め、継続できる体制を作りましょう。

役割	主な担当	担当する内容の例
全体の統括	情報セキュリティ部門	方針やルールの策定、監査への対応
基盤の運用	インフラ、クラウド推進担当	アカウント管理、ログと検知の運用
アプリの対応	開発、システム担当	脆弱性への対応、権限の申請
外部の支援	パートナーなど	診断、構築の支援、監視の代行

運用を内製するか、外部に委託するかは、人員とスキルで判断します。改善の状況は、検出結果の件数や、対応までの時間などを定点観測すると見えます。よくある失敗は、サービスを有効にしただけで、通知を誰も見ていない状態です。

費用は、利用するサービスと、分析するログやイベントの量などで変わります。サービスごとに料金体系が異なるため、公式の料金ページで確認してください。AWS料金見積りツールを使うと、概算をつかめます。

AWSクラウドセキュリティでよくある質問

Q1. AWSに任せられる範囲はどこまでですか？

AWSが担うのは、物理施設、ハードウェア、仮想化の基盤など、クラウド自体のセキュリティです。データ、権限、OSやアプリの更新などは、利用者側の責任です。利用するサービスで変わるため、詳しくは「利用するサービスによって変わる責任範囲」をご覧ください。

Q2. GuardDutyとSecurity Hubは、どう使い分けますか？

GuardDutyは、不正な活動や異常を検知するサービスです。Security Hubは、検出結果を統合し、優先順位を付けるサービスです。両者は競合せず、組み合わせて使います。

Q3. 最初に有効化すべきサービスは何ですか？

成熟度モデルのクイックウィンでは、CloudTrail、GuardDuty、Security Hubなどが挙げられています。あわせて、ルートユーザーのMFAと、IAMの権限の確認も早めに行いましょう。詳しくは「最初に確認すべき初動10項目」をご覧ください。

Q4. セキュリティ運用の費用は、何で決まりますか？

利用するサービスの種類と、その利用量で決まります。たとえば、分析するログやイベントの量などです。具体的な単価は、公式の料金ページで確認してください。

まとめ｜AWSクラウドセキュリティは責任範囲と優先順位から始める

AWSを使っても、セキュリティ対策が不要になるわけではありません。責任共有モデルを起点に、IAM、ネットワーク、暗号化、ログ、監視・検知の各領域で、自社の責任範囲を整理することが出発点です。

進め方は、リスクの大きさで優先順位を決め、初動の項目から着手し、改善を続けることです。まずは現状診断で、未対応の項目を洗い出してみてください。

テクノプロは、AWSアドバンストティアサービスパートナーとして、AWS認定資格3,000件以上の保有実績を持つ技術者集団です。ご支援の形は、大きく3つからお選びいただけます。

・請負・準委任：チーム体制で、現状のセキュリティ診断から設定の見直し、監視・検知の整備、運用ルールの策定までを一括してお引き受けします

・技術者派遣：AWSのセキュリティ設計・運用の経験を持つ技術者がプロジェクトに参画し、自社チームの一員として対策を推進します

・技術者教育：AWSトレーニングパートナーとして、セキュリティ運用を自社で担うための人材育成を支援します（年間1,000人の育成実績）

「何から手をつけるべきか整理したい」「現状の設定が適切か診断してほしい」という段階でもご相談いただけます。
ぜひテクノプロまでお気軽にご相談ください。