AWSのセキュリティ診断とは？必要性・診断項目・費用・実施の流れを解説

AWSは、サーバーやネットワークなどクラウド基盤自体の保護をAWSが担う一方、IAMやS3、Security Groupといった各種設定は利用者の責任です。この分担は「責任共有モデル」と呼ばれ、設定に不備があれば情報漏えいや不正アクセスに直結します。

本記事では、AWSのセキュリティ診断の必要性や診断項目、実施の流れ、見積もりのポイント、サービスの選び方までを解説します。

AWSを含むクラウド環境のセキュリティ診断の詳細はこちら

AWSのセキュリティ診断とは

AWSのセキュリティ診断とは、情報漏えいや不正アクセスにつながるリスクを洗い出すサービスです。IAMの権限設定、S3の公開範囲、Security Groupの通信制御など、AWS特有の設定項目の確認を軸に、システムの既知の脆弱性まで対象とします。

AWS環境のリスクは、大きく「設定の不備」と、OS・ミドルウェア・アプリケーションに存在する「既知の脆弱性」という2つの観点から確認する必要があります。
AWS環境全体のリスクを把握するには、この2つの観点を含めて診断することが望ましく、実際の診断サービスでも両観点をまとめて提供しているケースが多く見られます。GMOサイバーセキュリティ byイエラエも、この両観点で診断しています。 

クラウド診断サービスの詳細はこちら

将来のユーザー拡大を見据えて早期にセキュアなクラウドインフラを構築

ミチビク株式会社

AWSのセキュリティ診断が必要な理由

これまでも、クラウド環境の設定不備を原因とした情報漏えいや不正アクセスが相次いでいます。特にAWSでは、IAMやS3、Security Groupの設定ミスがセキュリティ事故に直結しやすい傾向があります。

海外セキュリティ企業UpGuardの調査では、取引先（パートナー企業）のS3バケットの設定ミスによって大手通信会社の顧客情報が最大1,400万件、外部から閲覧可能な状態にあったと報告されています。 

出典：UpGuard「Cloud Leak: How A Verizon Partner Exposed Millions of Customer Accounts」（2017年7月12日）

こうした事故の多くは、システムの脆弱性ではなく設定不備が原因です。だからこそ、設定内容を定期的に確認し、不備を早期に発見・改善するセキュリティ診断、脆弱性診断の重要性が高まっています。

AWS責任共有モデルとは

AWS責任共有モデルとは、クラウド基盤のセキュリティをAWSと利用者で分担する考え方です。

AWSはデータセンターやネットワーク、仮想化基盤など「クラウドを支える基盤部分」の保護を担います。一方、IAMやSecurity Group、S3といった各種設定は、利用者が管理する責任範囲です。

また、EC2などIaaS型のサービスではゲストOSやミドルウェアの管理・パッチ適用も利用者側の責任となりますが、S3・Lambda・RDSのようなマネージドサービスではOS層の管理はAWS側が担うなど、サービス形態によって責任範囲が異なる点にも注意が必要です。

 サービス形態ごとの責任範囲の違いは、以下の図のとおりです。 

※本表はAWS公式の分類ではなく、便宜的な整理です。
参考：AWS公式「責任共有モデル（Shared Responsibility Model）」 

AWS公式でも、データの管理やアセットの分類、IAMツールでの適切な権限設定については利用者側の責任であると説明されています。つまり、AWS側の基盤に不備がなくても、利用者側の設定ミスがあれば情報漏えいにつながる可能性があるということです。

利用者が管理すべきAWSの設定

利用者が管理すべき代表的な設定には、IAMのアクセス権限、S3バケットの公開範囲、Security Groupの通信許可ルールなどがあります。初期設定のまま運用したり、検証目的で緩めた設定を戻し忘れたりすることで、意図せず外部に公開された状態になるケースが少なくありません。

AWS特有のセキュリティリスク

AWSでは、IAMやS3、Security Groupをはじめ、AWSならではの設定項目がセキュリティリスクの原因になりやすい傾向があります。ここでは、AWSのセキュリティ診断で重点的に確認される代表的なリスクを紹介します。

IAM（アクセス権限）の設定不備

IAMの設定不備は、AWS環境における代表的なリスクの一つです。

• 業務上不要な権限まで付与する「過剰な権限付与」
• rootユーザーやIAMユーザーへの多要素認証（MFA）が未設定のままになっている状態
• アクセスキーが長期間ローテーションされずに放置されている状態

などが挙げられます。いずれもアカウントが乗っ取られた際の被害範囲を広げる要因になるため、権限設計の見直しと定期的な棚卸しが欠かせません。

S3バケットの公開設定

S3バケットの公開設定不備は、情報漏えい事故の代表例です。アカウント単位・バケット単位で公開を制限する「Public Access Block」が無効になっていたり、バケットポリシーで意図せず「全世界に公開」の設定になっていたりすると、誰でもデータを閲覧できる状態になります。

S3は2023年1月以降のアップロード分を既定で自動暗号化していますが、これは保存時の保護に過ぎず、公開設定や認証情報の漏えいで外部からアクセスされれば復号済みのデータが読み取られてしまいます。
より強固な保護には、S3管理キーではなく顧客管理キー（SSE-KMS）を利用し、鍵へのアクセス権限で保護することが推奨されます。また、2023年1月より前に作成された既存オブジェクトは自動暗号化の対象外のため、暗号化状況の棚卸しも必要です。 
診断では、これらの設定がアカウント単位・バケット単位で適切に制限されているかを確認します。

Security Group・ネットワーク設定

Security Groupは、EC2などのAWSリソースへの通信を制御するファイアウォールの役割を担います。業務上不要なポートを外部に公開したままにしていたり、送信元IPを「0.0.0.0/0」のように広範囲に許可していたりすると、不正アクセスの入り口になります。

あわせて、VPCのサブネット構成やネットワークACL（NACL）の設定に、不要な通信経路が生じていないかも確認すべき項目です。

監査証跡・ログ管理

AWS環境での操作履歴を記録するCloudTrailや、リソース構成の変更を追跡するAWS Configが有効化されていないと、不正な操作や設定変更が発生した際に原因の特定が遅れます。ログを取得しているだけでなく、一定期間保管し、必要なときに追跡できる状態になっているかも診断で確認するポイントです。

暗号化・鍵管理

AWS KMSを使った暗号鍵の管理体制も、確認すべき項目です。保存データや通信経路が暗号化されていない、あるいは鍵へのアクセス権限が過剰に付与されていると、データ漏えい時の被害が拡大します。鍵のローテーション設定やアクセス権限の範囲についても、あわせて確認します。

コンテナ・サーバーレス環境のリスク

Amazon EKSやECSといったコンテナ環境、AWS Lambdaのようなサーバーレス環境にも、AWS特有のリスクが存在します。コンテナに付与するIAMロールの権限が過剰であったり、Lambda関数の環境変数に認証情報を保持していたりするケースが代表的です。

環境変数は既定で保存時暗号化されているものの、実行関数への閲覧権限を持つ利用者にはコンソールやAPI経由で値が見えてしまうため、認証情報はSecrets ManagerやParameter Storeで管理することが推奨されます。 

関連記事：AWSでセキュリティ対策するには？基本や関連サービスを紹介

AWSのセキュリティ診断で確認する項目

AWSのセキュリティ診断では、アクセス管理やネットワーク、ストレージ、ログ管理など、AWS環境全体の設定や構成を確認します。ここでは、診断で重点的にチェックされる主な項目を紹介します。

アクセス管理

アクセス管理では、IAM（Identity and Access Management）によるユーザー・ロールの権限設計や、MFA（多要素認証）の設定状況を確認します。特に強い権限を持つユーザーの管理状況は、重点的にチェックされる項目です。

rootユーザー管理

AWSアカウントのrootユーザーは、すべてのリソースに対して最高権限を持つため、日常的な運用での使用は推奨されません。診断では、rootユーザーへのMFA設定やアクセスキーの無効化、利用状況などを確認し、不適切な運用が行われていないかを評価します。

マルチアカウント（AWS Organizations）統制

複数のAWSアカウントを利用する場合は、AWS Organizationsによる一元管理が重要です。診断では、組織単位（OU）の設計やService Control Policy（SCP）の適用状況、アカウントごとの権限管理などを確認し、統制が適切に行われているかを評価します。

ストレージ・データ保護

ストレージ・データ保護では、S3バケットの公開範囲やアクセス権限、AWS KMSによる暗号鍵の管理状況を確認します。保存データが適切に保護されているかが焦点です。

ネットワーク

ネットワークの診断では、Security Groupの通信制御に加え、Amazon EC2やAmazon RDSの公開範囲、アクセス制御の設定状況を確認します。データベースが不必要に外部公開されていないかも重点確認項目です。

関連記事：プラットフォーム脆弱性診断とは？必要性や基礎知識を解説

ログ・監査

ログ・監査では、AWS CloudTrailによる操作履歴の記録状況や、AWS Configによる構成変更の追跡設定を確認します。事故発生時に原因を追跡できる体制になっているかが評価ポイントです。

脅威検知・セキュリティ監視

脅威検知・セキュリティ監視では、Amazon GuardDuty、AWS Security Hub、Amazon Inspector、Amazon Macie の導入・設定状況を確認します。

AWS Security Hubは、GuardDuty（脅威検知）、Inspector（脆弱性管理）、Macie（機密データ検出）の検出結果を自動的に相関分析し、リスクの優先順位付けまで行う統合的なセキュリティ運用基盤です。
診断では、こうした監視体制が実際に機能しているかもあわせて評価します。

出典：AWS公式「ほぼリアルタイムの分析とリスクの優先順位付けが可能な AWS Security Hub が一般公開されました」（2025年12月12日） 

AWSのセキュリティ診断を実施する方法

AWSのセキュリティ診断は、AWSが提供する公式サービスを活用する方法と、セキュリティベンダーへ依頼する方法に大別されます。それぞれ特徴が異なるため、目的に応じた選び方が重要です。

AWS公式サービスを利用する方法

AWSには、Amazon Inspector、AWS Security Hub、Amazon GuardDutyなど、セキュリティ診断や脅威検知を支援する公式サービスが用意されています。
Inspectorは既知の脆弱性の検出、GuardDutyは不審な挙動の検知を担い、Security HubはMacieを含む複数サービスの検出結果を自動的に相関分析し、AWS環境全体のセキュリティ状態を一元的に可視化します。 

ただし、これらは自動検知が中心のため、権限設計など運用面のリスクまでは評価しきれない場合があります。

セキュリティベンダー依頼する方法

セキュリティベンダーに依頼する場合、AWS公式サービスでは判断が難しい権限設計や運用ルールまで踏み込んだ確認を受けられる点がメリットです。自社で診断リソースを確保しにくい企業でも、第三者の視点でリスクを網羅的に洗い出せます。

手動診断が必要な理由

ツールによる自動診断は、既知のパターンに基づくチェックが中心のため、IAMの権限設計やネットワーク構成のように「組織ごとに正解が異なる」設定は評価が難しいという限界があります。手動診断では、専門エンジニアが業務要件を踏まえたうえで、設定の妥当性そのものを確認できます。

ツール診断だけでは見つからないリスク

前述の通り、S3バケットの設定ミスが原因で、複数の企業において顧客情報が外部からアクセス可能な状態になっていた事例が報告されています。こうした設定不備は権限設計や運用ルールに踏み込んだ確認が必要なため、自動ツールだけでなく専門家による手動診断が重要とされています。

AWSのセキュリティ診断の流れ

AWSのセキュリティ診断は、診断会社や対象環境によって進め方が異なりますが、依頼から報告書受領までは目安として2週間〜1.5ヶ月程度かかります。ここでは、一般的な診断の流れを紹介します。

診断手法別のシステムへの影響

前述のとおり、AWS環境のリスクは「設定の不備」と「既知の脆弱性」という2つの観点から確認することが望ましく、実際の診断では、これらの観点に応じた手法を組み合わせて実施します。用いられる代表的な手法は、次の3つです。

• 設定レビュー
  設定の不備を確認する、AWSのセキュリティ診断の中心となる手法
• 脆弱性診断
  OS・ミドルウェア・アプリケーションの既知の脆弱性を検出する手法
• ペネトレーションテスト
  攻撃者の視点で実際に侵入を試みる手法

これらは対象システムへの影響度が異なるため、実施前に想定される影響を確認しておくことが重要です。

設定レビューの場合

設定レビューは、IAMの権限設定やS3の公開範囲、Security Groupの通信制御といった設定情報を、AWSマネジメントコンソールやAPI経由で確認する診断手法です。対象システムへ直接アクセスするわけではないため、通常は負荷や停止を伴わず、本番環境でも実施しやすい手法です。 

脆弱性診断の場合

脆弱性診断は、Webアプリケーションやプラットフォーム(OS・ミドルウェアなど)に存在する既知の脆弱性を、実際に疑似的な通信を送信して検出する診断手法です。対象システムへ直接アクセスして通信を行うため、実施方法によっては一時的にシステムへ負荷がかかる場合があります。事前に対象範囲や実施時間帯をすり合わせておくことが望まれます。 

ペネトレーションテストの場合

ペネトレーションテストは、攻撃者の視点で実際に侵入を試みる手法のため、他の手法よりもシステムへの影響が大きくなる可能性があります。本番環境で実施する場合は、影響範囲や実施タイミングについて事前に綿密なすり合わせが必要です。

関連記事：ペネトレーションテスト（侵入テスト）とは？メリットや有効手法まで解説

AWSのセキュリティ診断の費用と見積もりのポイント

AWSのセキュリティ診断の費用は、対象範囲や手法によって大きく異なります。ここでは、費用を左右する主な要因と、見積もり時に押さえておきたいポイントを紹介します。

関連記事：脆弱性診断の費用は？価格相場や比較ポイントを解説

費用を左右する要因

AWSのセキュリティ診断の費用は、主に以下の要因によって変動します。

• AWSアカウント数：診断対象のアカウントが多いほど確認項目が増える
• リソース数：EC2やS3など対象リソースの数
• 診断範囲：設定レビューのみか、脆弱性診断やペネトレーションテストを含むか
• 手動診断の有無：ツール診断のみか、専門エンジニアによる手動診断を含むか
  
• これらの組み合わせによって、費用は大きく変動します。

見積もりを依頼する際のポイント

こうした費用を左右する要因は対象環境や診断目的によって組み合わせが異なるため、多くの診断サービスでは個別見積もりを採用しています。まずは自社の対象環境や診断目的を整理したうえで相談することをおすすめします。

見積もりを依頼する際は、以下の項目を事前に整理しておくと、上記の要因を踏まえたより正確な見積もりを受け取りやすくなります。

見積もりチェックリスト

1. 診断対象となるAWSアカウント数
2. 対象リソース・サービス（EC2、S3、RDS、Lambdaなど）
3. 診断対象の環境（本番・検証・開発）
4. 診断の目的（リリース前、監査対応、定期診断など）
5. 希望する診断範囲（クラウド設定、脆弱性診断など）
6. 希望する実施時期・納期
7. 改善支援・再診断の希望有無

AWSのセキュリティ診断を選ぶ際のポイント

AWSのセキュリティ診断サービスを選ぶ際は、以下のポイントを確認しておくと、自社に合ったサービスを選びやすくなります。

クラウド診断の実績

AWSをはじめとするクラウド環境の診断実績が豊富かどうかは、診断の精度に直結します。業界や規模が近い企業への支援実績も確認しておくと安心です。

手動診断に対応しているか

ツール診断だけでは、権限設計や運用ルールに関わるリスクを見落とす可能性があります。専門エンジニアによる手動診断に対応しているかを確認しましょう。

診断レポート・改善提案の内容

診断結果を一覧化するだけでなく、リスクの優先順位や具体的な改善策まで提示してもらえるかは、対応スピードに大きく影響します。

アフターサポート

改善後の再診断や、設定変更に関する相談に対応してもらえるかなど、診断後のサポート体制もあわせて確認しておくとよいでしょう。

GMOサイバーセキュリティ byイエラエのクラウド診断サービス

GMOサイバーセキュリティ byイエラエのクラウド診断は、設定の不備と既知の脆弱性の両観点を、1つの診断メニューの中で確認できます。専門家がAWS環境を診断し、設定不備やセキュリティリスクを可視化します。

こんな企業におすすめ

• AWS環境の設計・設定に不安がある
• サービスのリリース前、AWS移行前に安全性を確認したい
• 利用者増加を見据え、クラウド環境のセキュリティを強化したい
• 第三者による客観的な診断を受けたい
• 診断だけでなく、改善提案や再診断まで支援を受けたい
• 監査、コンプライアンス対応に備えたい

クラウド診断サービスの詳細はこちら

AWS環境のセキュリティに不安がある方は、まずはお気軽にご相談ください。