2026.08.22

AWSセキュリティ診断の進め方とAmazon Inspector活用の判断軸

経営リスクナビ編集部

AWSセキュリティ診断は、クラウド特有の責任分界や設定ミスの不安がある中で、「どこを誰が、どの手段で点検するか」を決めるための実務ツールです。とくに誤公開や権限過大は、攻撃者の高度さ以前に運用の穴から事故化しやすく、放置すると情報漏えい・不正利用・調査と是正の手戻りが重なります。ペネトレーションテストは依頼から完了まで数カ月かかることがあるため、緊急度の高い確認と計画型の診断を分けて考える必要があります。以下では、AWSの責任共有モデルの整理と診断手法の選び方、運用への落とし込み方の判断材料として要点を示します。

AWSセキュリティ診断の全体像
- AWSセキュリティ診断とは
- 責任共有モデルで見る自社範囲
AWSのセキュリティリスク
AWS診断手法の選び方
Amazon Inspectorの活用法
AWSセキュリティ診断の実務
AWS診断の運用と委託判断
よくある質問
AWSセキュリティ診断への対応で次にすべきこと

AWSセキュリティ診断の全体像

AWSセキュリティ診断とは

AWSセキュリティ診断とは、AWS上で稼働するシステムについて、不正アクセス・情報漏えい・不正利用（例：暗号資産マイニングの踏み台化）につながる弱点を、設定と脆弱性の両面から洗い出して是正につなげる評価プロセスです。クラウドでは「サービス事業者側のセキュリティ問題」よりも、利用者側の設定不備や運用ミスにより事故が起きることがあるため、発生を前提に適宜監査していく設計が重要です。

AWSセキュリティ診断で主に見る観点（例）

IAM（Identity and Access Management）の権限設計と運用（最小特権、不要IDの削除、共有アカウント抑止など）
S3バケットなどストレージの公開範囲と共有設定（誤公開・URLリンク経由の閲覧可能性を含む）
セキュリティグループ等のネットワーク制御（管理ポートの公開、意図しない到達可能性）
OS・ミドルウェア・アプリケーションの既知脆弱性（パッチ未適用、不要サービス稼働など）
監視とログ（事後追跡に足るログ取得・保全、運用記録の有無）

また、より安全性を担保する観点では、再構築されたサーバやクラウド環境の安全性について、第三者である外部専門組織に確認を依頼することが重要だとされています（第三者チェックの考え方）。診断は「見つける」だけで終わらず、修復して再確認する運用まで含めて初めて効果が出ます。

責任共有モデルで見る自社範囲

AWS利用で前提となるのが、クラウド事業者と利用者で責任範囲を分担する責任共有モデルです。ここを曖昧にすると、「誰も見ていない領域」が生まれ、結果として設定不備や運用不備が温存されます。

区分	AWS（クラウド自体のセキュリティ）	利用者（クラウドにおけるセキュリティ）
物理・基盤	データセンターの物理的保護、ハードウェア、基盤ネットワーク等	自社では原則コントロール不可（ただし委託先管理として理解が必要）
OS・ミドルウェア	マネージドサービスの一部はAWS側で運用	EC2等のゲストOS更新、ミドルウェアのパッチ適用、設定の安全化
ID・権限	IAMの仕組み自体の提供	退職社員や不要IDの削除、共有アカウントのパスワード変更、権限の棚卸し
データ保護	暗号化機能などの提供	保存データの機密性判断、暗号化の適用、公開範囲・共有設定の管理
監視・ログ	サービスログ出力機能の提供	ログ取得・保全、操作履歴から不正変更や影響期間を精査できる体制整備

責任共有モデルの実務的な整理（代表例）

参照情報でも、クラウドの事故は「サービス側の問題ではなく利用者側の問題」により起き得ること、そして人的ミスを前提に適宜監査することが推奨されています。したがって、自社責任範囲（設定・ID・ログ・運用変更管理）を診断対象として明確化し、定常運用に落とし込む必要があります。

AWSのセキュリティリスク

設定ミスが招く主要リスク

クラウド運用で最も現実的に起きるのは、攻撃者が高度なゼロデイで突破する以前に、利用者側の設定ミスで情報が露出するケースです。参照情報でも、クラウドストレージの公開権限ミスにより、URLリンクが分かれば第三者でも閲覧・ダウンロードできる状態になり、機密データが意図せず第三者の目に触れるリスクが挙げられています。

設定ミスが直結しやすい被害パターン

ストレージの公開・共有設定ミスにより機密情報が外部から閲覧・ダウンロード可能になる
管理用ポートをインターネットへ開放し、ブルートフォース（総当たり）攻撃の試行を受ける
侵害後に不正なサーバ作成や設定変更をされ、利用料金増大や二次被害（踏み台化）につながる

また「スキャン」は攻撃者が弱点探索のために行うアクセスを含み、参照情報では、プログラムのバージョンやサービス稼働状況の確認、侵入行為の試み（未遂）、マルウェアの感染の試み（未遂）、ssh等へのブルートフォース（総当たり）攻撃（未遂）も含むと整理されています。つまり、設定ミスがあると攻撃者側の探索活動に早期に引っかかり、被害化が加速します。

アクセス管理不備の典型例

IAMを中心とするアクセス管理不備は、侵害の起点になりやすい領域です。とくにクラウドはインターネット経由で外部からアクセスされ得る特性があるため、参照情報でもID管理は極めて重要とされています。

典型的な不備と実務での注意点

退職社員が発生したのにIDを直ちに利用不可にせず削除もしない
退職者に共有アカウントのID・パスワードを渡していたのに、退職時にパスワードを変更しない
強い管理者権限のアカウントを複数人で共有して常用し、責任追跡（誰が何をしたか）が曖昧になる
アクセスキー等の認証情報を誤って公開し、不正操作（リソース作成、データ窃取）に悪用される

さらに、侵害後の観点としても、参照情報では「攻撃者が窃取した認証情報を不正利用し、各種クラウドサービスの設定を変更していないことを確認する」ことが確認事項として挙げられています。設定変更（例：メール転送など）の内容次第では情報漏えいにつながるため、変更日時・操作ログから影響期間や対象データ（機密情報）を精査する必要があります。

公開設定の事故が起きやすい会社の共通点と、S3・Security Groupで先に潰す確認順

誤公開が起きやすい組織では、部門・チームごとに独自判断でリソースが作られ、全社のガバナンス（統制）や点検が追いつかない構造になりがちです。参照情報でも、人的ミスを前提に適宜監査していく必要性が述べられており、運用で「戻し忘れ」を起こさない仕組みが重要です。

S3とセキュリティグループで先に潰す確認順（外部露出を最速で落とす）

S3の公開・共有設定を点検し、公開権限ミスやURLリンク経由で第三者が閲覧可能な状態がないか確認します。
S3のバケットポリシー等を見直し、意図しない外部主体に対して閲覧・取得を許容していないか確認します。
セキュリティグループのインバウンドルールを確認し、ssh等へのブルートフォース（総当たり）攻撃の試行を受け得る全開放がないか確認します。
意図しない設定変更が起きた場合に追跡できるよう、変更日時や操作ログを確認できる状態（ログ取得・保全）を整えます。

「公開されてしまうと誰でも取れる」タイプの事故は復旧コストが大きくなりやすいので、まず外部露出の可能性を消す順番で確認する運用が現実的です。

AWS診断手法の選び方

脆弱性診断と設定診断の違い

AWS環境の診断は大きく、ソフトウェアの欠陥（既知の脆弱性）を見つける脆弱性診断と、クラウド設定の誤り・逸脱を見つける設定診断に分けて整理すると意思決定がしやすくなります。参照情報でも、外部公開されているサーバや通信機器に対する脆弱性診断、ネットワーク環境診断、クラウド移行後の設定不備の確認といった第三者チェックの重要性が述べられています。

観点	脆弱性診断	設定診断
主対象	OS・ミドルウェア・アプリケーションの既知の欠陥	クラウドサービス設定、権限、公開範囲、監視・ログ、運用手順
見つけやすい問題	パッチ未適用、不要サービス稼働、既知CVEなど	ストレージ公開権限ミス、共有設定の誤り、意図しない外部到達、権限過大
事故との関係	侵入の起点になり得る欠陥を減らす	人的ミス由来の事故（誤公開・誤設定）を抑止しやすい

脆弱性診断と設定診断の違い（実務での使い分け）

どちらか一方では抜けが生じます。クラウドではとくに「利用者側の設定不備」による漏えいが起き得るため、設定診断を軽視しないことが重要です。

ペネトレーションテストの位置づけ

ペネトレーションテスト（侵入テスト）は、攻撃者視点で侵入可能性を検証し、現状の対策がどこまで有効かを確かめる評価です。参照情報でも、攻撃者の視点で侵入できるか試すことが「最もシンプルで効率的な方法」とされ、疑似的な攻撃により現状対策の有効性をチェックできるとされています。

一方で注意点として、参照情報では、業務への影響を考慮する必要があり、範囲設定を中心とした調整や事前準備が必要で、疑似攻撃そのものにも期間を要するとされています。また、一般的には依頼からテスト完了まで数カ月かかり、即時に実施できるものではない点は、経営判断（計画・予算・体制）の前提になります。

Inspectorで足りる環境と手動診断を足すべき環境の分かれ目

Amazon Inspectorのような自動化サービスは、既知の脆弱性や一定の設定リスクの「検出」を継続運用しやすい一方で、業務文脈に依存する判断や、組織的・人的リスクまで含めた網羅的点検は限界があります。参照情報でも、サイバー被害だけでなく、内部からの情報漏えいや組織的・人的なセキュリティリスクを回避する意味で、会社組織を網羅的にチェックする全体的な診断の重要性が述べられています。

自動（Inspector中心）で回しやすい領域／手動診断を足したい領域

自動中心が向く領域：既知脆弱性の継続検出、パッケージ更新漏れの早期発見、定常的なリスク可視化
手動を足したい領域：公開・共有設定の妥当性判断、権限設計の是非、運用手順（例外運用）の適否、内部不正も見据えた統制評価

「どこまで自動化で足りるか」は、システムの複雑さだけでなく、扱う情報の性質（機密・個人情報等）と、変更頻度・例外運用の多さで判断するのが実務的です。

Amazon Inspectorの活用法

Amazon Inspectorの役割

Amazon Inspectorは、AWS環境内のワークロードに対して、脆弱性や意図しない露出リスクを継続的に評価し、結果を可視化して修復につなげるサービスです。自動スキャンにより検出を継続できる点は、参照情報で述べられている「人的ミスを前提に適宜監査していく」運用と相性が良く、日常運用としての点検を支える役割になります。

また、侵害時・侵害後の実務では「意図しない設定変更が行われていないか」「変更日時や操作ログから影響範囲を精査」する必要が出ます。Inspector自体は設定変更監査の万能ツールではありませんが、検出結果の蓄積と運用フロー化により、少なくとも脆弱性・露出の観点での異常把握を定常化しやすくなります。

設定から結果確認までの流れ

運用に組み込む観点では、最初に有効化して終わりではなく、「結果を誰が見て、どう是正し、どう再確認するか」まで決める必要があります。

有効化から結果確認までの最小フロー（運用設計込み）

有効化の前に、対象アカウント・対象環境（本番／検証）・責任者・連絡経路を確定します。
AWS管理コンソール等からInspectorを有効化し、対象ワークロードが自動検出される状態にします。
Findings（検出結果）を確認し、修復担当（アプリ／インフラ）に割り当て、対応期限の管理に載せます。
是正後に再評価し、検出がクローズすることをもって完了とします。
侵害を想定し、設定変更日時・操作ログ等で影響期間を追跡できるログ取得・保全の運用も並行整備します。

参照情報では、設定変更（例：メール転送等）が漏えいにつながり得るため、設定変更日時や操作ログから影響期間や機密データへの影響を精査する重要性が述べられています。Inspectorの結果確認も、こうした「追跡可能性（説明可能性）」の運用とセットで評価するのが実務的です。

EC2・ECR・Lambdaのどこまで見えるかで判断する、Inspector適用前の対象整理

Inspectorの適用効果は、対象にするワークロードと、運用での見方（誰が何を責任を持って直すか）で決まります。対象整理をせずに全リソースへ一律適用すると、ノイズが増えて是正が止まりやすくなります。

適用前に整理しておきたいこと（対象と責任の紐づけ）

EC2はOS・ミドルウェアの更新責任が自社側にあるため、検出結果の修復オーナーをインフラ担当に割り当てます。
ECRはイメージ作成プロセス（CI/CD）での修復が必要になりやすく、開発側の修正責任と結びつけます。
Lambdaは依存ライブラリ管理が論点になりやすく、デプロイ手順と一体で修正できる体制を作ります。
退職社員や不要IDを直ちに削除する等のID管理不備は別レイヤーの統制課題なので、IAM棚卸し・監査とセットで運用設計します。

参照情報でも、退職者が出た場合に直ちにIDを利用不可能にして削除すること、共有アカウントのパスワード変更を忘れないことが注意点として挙げられています。Inspector適用の前提として、こうした運用統制を「別枠で確実に回す」整理が必要です。

AWSセキュリティ診断の実務

計画からスキャンまでの進め方

スキャンは、実施計画と関係者調整なしに走らせると、業務影響や誤解（攻撃と誤認される等）を招きます。参照情報でも、ペネトレーションテストは業務への影響を考慮する必要があり、範囲設定の調整や事前準備が必要で、依頼から完了まで数カ月かかることがあるとされています。したがって、診断種別ごとに計画の作り方を変えるのが現実的です。

計画からスキャンまでの実務ステップ（AWS向け）

目的を定義し、脆弱性診断・設定診断・ペネトレーションテストのどれを実施するかを決めます。
対象範囲（外部公開資産、重要資産、クラウド設定領域、ログ範囲）を確定し、例外条件も整理します。
実施による影響（負荷、誤検知、運用監視チームのアラート）を想定し、連絡・周知の手順を決めます。
自動スキャンを実行し、検出結果を収集して一次トリアージ（誤検知の切り分け、重要度分類）をします。
手動検証が必要な項目（設定変更の妥当性、侵入経路の連鎖等）を追加調査し、是正計画に落とします。

加えて、攻撃者は侵入後にクラウド設定を不正変更する場合があるため、参照情報にあるとおり「意図しない設定変更が行われていないか確認する」観点を、診断の確認項目にも含めておくと、運用に繋がりやすくなります。

IAMとS3とネットワークの確認点

AWS診断で優先順位が高いのは、侵入起点になりやすいIAM、漏えい事故に直結しやすいS3、外部露出を決めるネットワークです。参照情報では、クラウドストレージの公開権限ミスや共有設定が「非公開」になっていないことにより、ゲストアカウント等でも意図せず閲覧できるケースが挙げられています。

優先して確認するポイント（IAM・S3・ネットワーク）

IAM：退職社員や不要IDを直ちに削除し、共有アカウント運用がある場合は退職時にパスワード変更を徹底します。
IAM：侵害後を想定し、サインイン履歴や操作ログを追跡可能にして、設定変更日時から影響期間を精査できるようにします。
S3：公開権限ミスによりURLリンクが分かれば第三者でも閲覧・ダウンロードできる状態がないか点検します。
S3：共有設定が「非公開」になっているか、簡易アカウント等で意図せず閲覧できないかを確認します。
ネットワーク：ssh等に対するブルートフォース（総当たり）攻撃の試行を受け得る全開放がないかを確認します。

ここは「技術設定」だけでなく、「退職時手続」「例外運用」「ログ保全」などの運用も含めて診断することで、実態に即した改善につながります。

診断結果の優先順位と是正対応

検出結果が多数になるほど、全件を同時に直す発想は破綻します。参照情報でも、100個の課題を洗い出してもすべてに対策はできず、優先課題を決める必要があるとされ、評価指標として重要度、緊急度、難易度、効果、コスト、時間が例示されています。また、マトリクスに評価を入れる場合も、過度に厳密にしすぎず、ただし「なぜその評価か」を説明できるロジックを持つことが重要だとされています。

評価軸	見るポイント	補足
重要度	機密情報・業務継続への影響の大きさ	漏えい・停止の影響を含む
緊急度	悪用されやすさ、外部露出の有無	インターネット到達や公開状態を重視
難易度	修正に必要な工数・調整量	リリース調整、互換性確認など
効果	修正でどれだけリスクが下がるか	代替策の有無も含む
コスト	追加費用や運用費	外部委託、ツール費など
時間	完了までの見込み期間	止められない業務との調整を含む

優先順位付けの評価軸（例：5段階で運用）

是正対応では、外部露出があるもの、設定ミスにより第三者が閲覧可能な状態になり得るもの、攻撃の試行（スキャンや総当たり）を受けやすい入口を優先し、修正後は再評価でクローズを確認します。

診断前に誰が何をそろえるか――アカウント一覧・構成図・例外申請の社内準備

診断の精度は、事前準備で大きく変わります。参照情報でも、侵害を前提に「意図しない設定変更が行われていないか確認する」ことや、設定変更日時・操作ログ等から影響期間を把握して調査範囲に含めることが述べられています。つまり、診断前から「追跡できる材料」を揃えておく必要があります。

診断前に揃える社内準備（役割分担の例）

情シス：AWSアカウントの一覧と管理者、外部公開資産の一覧、連絡先（緊急停止手順を含む）
インフラ：ネットワーク構成図、セキュリティグループ設計方針、外部接続経路（VPN等）の棚卸し
開発：ECRイメージや依存関係、Lambda関数の棚卸し、リリース手順と影響範囲
セキュリティ／監査：例外運用（公開が必要なポート等）の根拠、承認記録、期限と見直し条件
共通：操作ログ等により設定変更日時から影響期間を精査できる状態（ログ取得・保全、作業記録）

第三者チェックを外部専門組織に依頼する場合も、上記が揃っているほど、誤解や手戻りが減り、報告書の実効性が上がります。

AWS診断の運用と委託判断

再テストとDevSecOpsへの組み込み

修正後に再テストをしないと、「直したつもり」でリスクが残ります。さらに、侵害時には攻撃者がクラウド環境の設定を不正変更する可能性があるため、参照情報で挙げられているとおり、意図しない設定変更が行われていないか確認し、設定変更日時や操作ログから影響期間やデータ（機密情報）を精査する運用が重要です。再テストは、こうした運用の一部として位置づけると継続しやすくなります。

DevSecOps（開発・運用にセキュリティを組み込む考え方）としては、CI/CDに検査を組み込み、日々の変更で設定不備や脆弱性を増やさない仕組みにします。

DevSecOpsに組み込むときの実務ポイント

自動スキャン結果をチケット化し、対応期限・例外承認・再確認までをワークフロー化します。
ログ取得・保全を前提にし、設定変更日時や操作ログで追跡できる状態を維持します。
退職者対応（ID無効化・削除、共有アカウントのパスワード変更）を手続として組み込み、人的ミスを減らします。

自社実施と外部委託の比較

自社実施と外部委託は、競合ではなく補完関係として設計する方が失敗しにくいです。参照情報では、外部専門組織による第三者チェックが重要であり、外部公開されているサーバ・通信機器への脆弱性診断やネットワーク環境診断、クラウド移行後の設定不備確認が挙げられています。

観点	自社実施（内製・ツール活用）	外部委託（第三者診断）
強み	高頻度で回せる、日々の変更に追随しやすい	第三者視点で盲点を突きやすい、説明可能性（客観性）を確保しやすい
向く領域	定常的な脆弱性管理、検出の継続運用	外部公開資産の脆弱性診断、ネットワーク環境診断、クラウド設定不備の精査
限界	人的・組織的リスクや設計判断の妥当性まで自動化で完結しにくい	調整・準備が必要で即時性に欠ける場合がある（ペネトレーションは数カ月かかることも）

内製と外部委託の使い分け（現実的な整理）

外部委託は「スポットのイベント」ではなく、内製の定常運用の結果（傾向、再発、例外運用）を持ち込むことで、診断の質が上がります。

経営者・情シス・法務監査で異なる判断基準と、報告書で確認すべき項目

診断結果を意思決定に使うには、関係部門で見たい指標が異なることを前提に、報告書の形を整える必要があります。参照情報では、サイバー被害だけでなく内部からの情報漏えい、組織的・人的リスクも含めた全体的診断の重要性が述べられており、技術所見を統制（ガバナンス）に接続する視点が必要です。

報告書で確認すべき項目（部門横断で使うための最低限）

発見事項の一覧に加え、重要度・緊急度・難易度・効果・コスト・時間の評価軸で優先度が説明されていること
外部公開や共有設定など、第三者が閲覧・ダウンロード可能になり得る経路が明確化されていること
意図しない設定変更の有無や、設定変更日時・操作ログから影響期間を精査できる前提が示されていること
是正手順が具体的で、誰がいつまでに何を直すか（担当と期限）が追えること
例外運用を残す場合の合理性（根拠・期限・代替策）と、残存リスクの説明があること

また、参照情報の優先順位付けの考え方（マトリクスで整理し、過度に厳密にせず、ただし説明可能にする）に沿うと、経営・現場・監査の共通言語になりやすいです。

よくある質問

AWSセキュリティ診断はどのくらいの頻度で実施するべきですか？

頻度は「変更頻度」と「扱う情報の重要性」、そして人的ミスを前提にした監査設計で決めます。参照情報でも、クラウドでは利用者側の問題で情報漏えいが生じ得るため、適宜監査していくのがよいとされています。

頻度設計の考え方（創作数値は置かず、決め方を明確化）

自動スキャンは常時有効化し、変更や新規デプロイの都度、検出結果をレビューする運用にします。
設定診断は、例外運用（公開・共有の一時緩和等）が発生したタイミングで必ず棚卸しし、戻し忘れを監査で潰します。
ペネトレーションテストは計画型で実施し、参照情報のとおり依頼から完了まで数カ月かかることがある前提で、重要リリースや構成更改に合わせて前倒しで手配します。

小規模なAWS環境でもAmazon Inspectorの利用は有効でしょうか？

小規模でも有効です。規模が小さいほど担当者が兼務になりやすく、人的ミスを前提に「適宜監査する」負担を下げる必要があります。Inspectorは検出を継続運用しやすいため、少人数体制の点検を補助します。

ただし、参照情報で強調されているとおり、クラウドの事故は利用者側の設定不備（例：公開権限ミス、共有設定が非公開でない）で起き得ます。Inspectorだけに依存せず、S3の公開・共有、IAMの不要ID削除（退職者対応を含む）など、運用統制の確認を別途回すことが重要です。

ペネトレーションテストではAWSへの事前申請が必要ですか？

参照情報の範囲では、AWSへの事前申請要否を断定できる一次情報が提示されていないため、ここでは「申請が不要／必要」と結論づけません。実務では、実施前にAWSのポリシー（許可されるテスト、禁止行為、対象サービス、負荷試験の扱い、ソーシャルエンジニアリングの扱い等）を確認し、範囲設定と影響評価を行ってから実施判断をしてください。

なお、参照情報ではペネトレーションテストの注意点として、業務への影響を考慮し、診断範囲の設定を中心に関係者調整や事前準備が必要で、一般的に依頼から完了まで数カ月かかる点が示されています。したがって、申請要否以前に、計画と調整を前倒しで組むことが重要です。

AWSセキュリティ診断への対応で次にすべきこと

AWSセキュリティ診断は、責任共有モデルで自社の診断対象（設定・ID・ログ・運用変更管理）を切り出し、脆弱性診断・設定診断・ペネトレーションテストを目的別に組み合わせることが要点です。外部露出や誤公開のように被害が顕在化しやすい論点は、S3やセキュリティグループ、IAMの基本動作（不要ID削除、共有アカウントの扱い）から優先して確認し、修正後の再評価までを運用に含めます。優先順位は、重要度・緊急度・難易度・効果・コスト・時間の軸で説明可能な形に整理し、現場の是正と監査・経営の判断をつなげます。ペネトレーションテストは依頼から完了まで数カ月かかることがある前提で、計画・調整・範囲設定を先行させ、即時に回せる自動スキャンや設定点検と役割分担させるのが現実的です。個別のシステム要件や業務影響が絡む場合は、関係部門（情シス・開発・監査）で前提を揃えたうえで、必要に応じて外部専門組織への相談も検討してください。