AWSの設定不備をどう見つける？セキュリティ診断の種類と進め方

AWSでは、過剰な権限の付与やリソースの意図しない公開、ログ設定の不足、OS・ミドルウェアの脆弱性が不正アクセスや情報漏えいにつながります。

Amazon InspectorやAWS Security Hub CSPMを利用すると、既知の脆弱性やセキュリティ基準から外れた設定を継続的に検出できます。ただし、基準から外れた設定の中にも、システムの用途上必要なものがあります。対応の要否や緊急度は、運用状況を踏まえて判断します。

この記事では、AWSセキュリティ診断の種類と主な確認項目、AWSサービスと外部診断の使い分けを整理します。検出した問題を整理し、設定の修正と再診断を進める手順も解説します。

AWSセキュリティ診断とは

AWSセキュリティ診断は、クラウド環境の設定や稼働中のソフトウェアを調べ、不正アクセスや情報漏えいにつながる問題を洗い出す取り組みです。

対象には、アカウントや権限、ネットワーク、リソースの公開設定、暗号化、ログ取得などが含まれます。Amazon Elastic Compute Cloud（Amazon EC2）上のOSやミドルウェア、Webアプリケーションの脆弱性を調べる診断もあります。

診断の種類によって、目的や対象は異なります。AWSの設定不備を調べる診断、既知の脆弱性を検出する診断、実際の攻撃を想定したペネトレーションテストでは、調査範囲や実施方法が変わります。 

AWS環境の設定不備と脆弱性を確認する

AWSでは、利用者やサービスの追加、システム改修、担当者の変更に伴い、環境の構成が変化します。構築時には適切だった設定も、運用を続けるうちに現在の利用状況と合わなくなることがあります。

管理者権限を持つIAMユーザーが増えている、使われていないアクセスキーが残っている、管理用ポートが広い範囲へ公開されている、操作ログを取得していないといった状態が代表例です。

クラウド側が適切に構成されていても、Amazon Elastic Compute Cloud（Amazon EC2）上のOSやミドルウェア、コンテナイメージ、アプリケーションに既知の脆弱性が残ることがあります。AWSセキュリティ診断では、AWSの設定と稼働中のソフトウェアを調べ、攻撃の起点となる箇所を洗い出します。

AWS環境診断との違い

AWS環境診断は、システム構成、可用性、パフォーマンス、コスト、監視、バックアップ、運用体制などを幅広く評価する取り組みです。

一方、AWSセキュリティ診断では、リソースの外部公開、アクセス権限、暗号化、ログ取得、ソフトウェアの脆弱性などを詳しく調べます。

コストの増加や障害に備えた構成、運用負荷まで含めて見直す場合は、環境全体を対象とした診断が適しています。不正アクセスや情報漏えいにつながる問題を特定したい場合は、セキュリティに特化した診断を実施します。

AWS環境診断でセキュリティ上の課題が見つかった場合は、対象を絞って詳しい診断を追加することもあります。

AWSセキュリティ診断の種類

AWSセキュリティ診断は、対象と目的によって次のように分かれます。

AWSのセキュリティ設定診断

AWSのセキュリティ設定診断では、AWSアカウントや各リソースが、社内基準や採用しているセキュリティ標準に沿って構成されているかを調べます。

主な確認対象は、IAMの権限、セキュリティグループの通信制御、Amazon Simple Storage Service（Amazon S3）の公開状態、暗号化、操作ログの取得状況です。

AWS Security Hub CSPMやAWS Configによる自動評価に加え、システムの用途や社内ルールに照らして個別に確認することもあります。

OS・ミドルウェアの脆弱性診断

OS・ミドルウェアの脆弱性診断では、Amazon Elastic Compute Cloud（Amazon EC2）などで稼働するソフトウェアに、既知の脆弱性や未適用のセキュリティ更新が残っていないかを確認します。

対象は、OS、Webサーバー、データベース、アプリケーションサーバー、コンテナイメージに含まれるパッケージなどです。

Amazon Inspectorを利用すると、対応するワークロードを継続的にスキャンできます。新たな脆弱性の公表やリソースの変更に応じて、自動的に再評価されます。

アプリケーションの実装に起因する脆弱性は、Webアプリケーション診断で別途調べます。

Webアプリケーション診断

Webアプリケーション診断は、AWS上で稼働するWebサイト、業務システム、APIの実装を対象とします。

実際にリクエストを送り、認証や認可、入力値の処理、セッション管理、APIのアクセス制御に問題がないかを確認します。クラウド基盤やOSが適切に構成されていても、アプリケーションに脆弱性が残っていれば、不正操作や情報漏えいにつながります。

診断前には、対象となる画面やAPI、使用するアカウント、実施時間帯、禁止する操作を決めておきます。

ペネトレーションテスト

ペネトレーションテストでは、攻撃者の視点からAWS環境やアプリケーションへの侵入を試みます。

設定診断や脆弱性診断が個別の問題を検出するのに対し、ペネトレーションテストは、複数の問題を組み合わせた攻撃が成立するかを検証するものです。

AWSが許可対象として定めるサービスへのテストは、原則として事前承認なしで実施できます。ただし、Command and Controlを含むテストや一部の模擬イベントには事前承認が必要です。

禁止されている行為もあるため、AWSのポリシーと利用規約を事前に確認します。対象サービス、試験内容、システムへの影響、停止条件も定めたうえでテストを行います。

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

AWSセキュリティ診断では、クラウド側の設定と、そこで稼働するソフトウェアの両方を確認します。対象範囲は、利用しているサービスやシステム構成によって異なります。

アカウント・権限

アカウントと権限では、AWS Identity and Access Management（IAM）のユーザー、ロール、ポリシー、多要素認証、アクセスキーを調べます。

主な確認項目は次のとおりです。

• 未使用のIAMユーザーやアクセスキーが残っていないか

• 管理者権限が必要以上に付与されていないか

• 人による操作に長期的なアクセスキーを使用していないか

• 多要素認証が必要なアカウントに設定されているか

• IAMロールやポリシーの管理者が明確か

複数のAWSアカウントを運用している場合は、AWS Organizationsを含む管理方法も調査対象です。利用者、システム、支援会社ごとのアクセス経路を整理し、誰がどの操作を行ったのか追跡できる状態にします。

ネットワーク・外部公開設定

ネットワークでは、Amazon Virtual Private Cloud（Amazon VPC）のサブネット、ルートテーブル、セキュリティグループ、ネットワークアクセスコントロールリストなどを調べます。

管理用ポートがインターネット全体へ公開されている、不要な通信が許可されている、公開サブネットに外部公開の必要がないリソースが配置されているといった状態が主な確認対象です。

Amazon Simple Storage Service（Amazon S3）やデータベースでは、リソースポリシーによって意図しない外部アクセスが許可されていないかを調べます。別のAWSアカウントに不要な権限が付与されていないかも確認します。

Webサイトや公開APIでは、公開範囲、認証方式、接続元の制限、AWS WAFなどによる保護状況を確認します。

暗号化・ログ・監視設定

暗号化では、Amazon Simple Storage Service（Amazon S3）、Amazon Elastic Block Store（Amazon EBS）、データベースなどに保存されたデータと、通信経路の保護状況を調べます。

AWS Key Management Service（AWS KMS）を利用している場合は、鍵の管理者と利用者、キーポリシー、ローテーション、削除設定も確認対象です。

ログについては、AWS CloudTrail、各サービスのアクセスログ、VPCフローログなどが取得されているかを調べます。保存期間、保存先の権限、暗号化、削除や改ざんを防ぐ設定も確認します。

監視では、検出結果の通知先、確認担当者、対応条件を整理します。アラートが発生しても、担当者や連絡基準が決まっていなければ、初動が遅れます。

ソフトウェアの診断対象と管理体制

脆弱性診断では、稼働中のソフトウェアを漏れなく対象に含める必要があります。管理台帳に記載されていないAmazon Elastic Compute Cloud（Amazon EC2）、更新されていないコンテナイメージ、担当者が把握していないライブラリが残っていると、診断を実施しても確認漏れが生じます。

まず、稼働中のOS、ミドルウェア、コンテナイメージ、アプリケーションと、それぞれの管理担当者を整理します。脆弱性が見つかった際に対応できるよう、バージョン、サポート期限、更新方法も記録します。

継続的なスキャンを導入する場合は、検出結果を確認する担当者、修正を依頼する相手、対応状況の管理方法も決めます。担当者や更新手順が不明なままでは、脆弱性を検出しても対応が止まります。

Webアプリケーションは、インフラやOSと担当部門が異なる場合があります。開発部門とインフラ運用部門の対象範囲を分け、認証、認可、入力値処理などの実装上の問題が診断から漏れないようにします。

AWSサービスと外部診断の使い分け

AWSのセキュリティサービスを利用すると、あらかじめ定められた基準やルールに沿って、設定不備や既知の脆弱性を継続的に検出できます。

日常的な監視や定型的なチェックには、AWSサービスが適しています。一方、付与された権限が業務上妥当か、複数の問題を組み合わせた侵入経路が存在するかを調べるには、システムの構成や運用を理解した人による確認が必要です。

Amazon Inspectorで脆弱性を検出する

Amazon Inspectorは、AWS上のリソースを継続的にスキャンし、ソフトウェアの脆弱性や意図しない外部公開を検出するサービスです。

主な対象は、Amazon Elastic Compute Cloud（Amazon EC2）、Amazon Elastic Container Registry（Amazon ECR）のコンテナイメージ、AWS Lambda関数です。

新たな脆弱性の公表やリソースの変更に応じて自動的に再評価されるため、一定期間ごとの手作業による診断よりも早く問題を把握できます。 

AWS Security Hub CSPMとAWS Configで設定を評価する

AWS Security Hub CSPMは、セキュリティ標準に含まれるコントロールを使い、AWSリソースが基準に沿って構成されているかを評価します。

ログの取得状況、ストレージの公開範囲、暗号化などをチェックし、基準から外れたリソースを検出します。複数のAWSアカウントやリージョンを利用している場合は、各環境の結果を集約して管理できます。

AWS Configは、AWSリソースの構成と変更履歴を記録するサービスです。AWS Configルールを利用すると、社内基準や運用ルールに沿った状態が保たれているかを継続的に確認できます。基準から外れた時期や、その原因となった変更を調べる際にも役立ちます。

AWSサービスによる検出だけでは判断できない問題

AWSサービスは、設定値や既知の脆弱性を効率よく検出できます。ただし、次のような問題は、システムの用途や運用状況を踏まえて個別に判断する必要があります。

• 業務上の用途に対して広すぎる権限や公開範囲

• 複数の設定不備や脆弱性を組み合わせた侵入経路

• アプリケーション固有の認証・認可の不備

• 社内ルールと実際のAWS設定の食い違い

• アラート発生後の連絡、調査、復旧手順の不足

検出結果だけで結論を出さず、システムの役割、扱うデータ、利用者、外部公開の状況も確認します。これにより、優先して対応すべき問題を絞り込めます。

専門会社へ依頼した方がよいケース

次のような場合は、専門会社への依頼を検討します。

• 複数のAWSアカウントやシステムを横断して調査したい

• 個人情報や機密情報を扱っている

• インターネットに公開するシステムを運用している

• 監査や取引先から第三者評価を求められている

• 検出結果が多く、対応の優先順位を決められない

• 設定の修正や再診断まで支援を受けたい

依頼先を選ぶ際は、診断項目の数だけで比較せず、AWS環境の構成や業務への影響まで理解して評価できるかを確認します。修正案の提示、設定変更、再診断まで任せられる会社であれば、診断結果を実際の改善につなげられます。 

AWSセキュリティ診断の進め方

AWSセキュリティ診断では、目的と対象範囲を定め、検出した問題のリスクを評価したうえで、設定の修正と再診断を行います。

診断の目的と対象範囲を決める

最初に、今回の診断で何を明らかにしたいのかを整理します。

AWSの設定不備を調べるなら、IAM、ネットワーク、ストレージ、暗号化、ログなどが対象です。既知の脆弱性を確認するなら、Amazon Elastic Compute Cloud（Amazon EC2）上のOSやミドルウェア、コンテナイメージも含めます。

Webシステムの実装上の問題や侵入経路を調べるときは、Webアプリケーション診断やペネトレーションテストを選びます。

複数のAWSアカウントやリージョンを利用している企業では、診断対象となる環境を一覧化します。構成図、アカウント一覧、利用サービス、扱うデータ、外部公開の状況を準備し、対象の漏れを防ぎます。

検出結果のリスクと対応優先度を判断する

検出された問題は、次の3点を中心に評価します。

• 外部から到達できるか

• 重要なデータや機能に影響するか

• 強い権限や、ほかのリソースへのアクセス経路を持つか

あわせて、既知の攻撃手法や悪用実績、修正による業務への影響、代替策の有無も確認します。

自動診断で示される深刻度は、対応順を決める材料の一つです。表示された深刻度だけで並べず、実際に攻撃へつながる可能性と、問題が発生した際に事業へ及ぶ影響を踏まえて優先順位を付けます。

誤検知や、業務上必要な設定が指摘されることもあります。対応を見送る際は、その理由、承認者、再確認する時期を記録します。

設定を修正して再診断する

優先順位を決めた後は、IAM権限の縮小、外部公開範囲の制限、暗号化やログ取得の有効化、OSやミドルウェアの更新を進めます。

変更前には、対象システムへの影響と復旧方法を確認します。権限や通信設定を変更すると、アプリケーションの動作や業務システムへの接続に影響する可能性があるためです。

修正後は、同じ条件で再診断を実施します。指摘された問題が解消されているか、システムが正常に動作しているかを確かめます。

すぐに修正できない問題には、担当者と対応期限を設定します。通信元の制限、監視の強化、権限の一時的な縮小などを行い、恒久対応までのリスクを抑えます。

AWS環境は、リソースの追加や設定変更によって継続的に変わります。定期診断や継続的な設定評価を運用に組み込み、修正後の状態を維持します。

AWSセキュリティ診断と改善をサーバーワークスとIIJグループが支援

サーバーワークスとIIJグループは、AWS環境の設計・構築・運用に加え、セキュリティ上の課題整理から改善まで支援します。AWSの設定だけでなく、拠点ネットワークや運用体制も含めて診断範囲を定めます。

サーバーワークスは、AWS環境の構成や権限設定、ログ収集、脅威検知の状況を確認し、必要な設定変更や運用改善を提案します。IIJグループは、拠点側のネットワークやIT環境を踏まえ、導入から運用まで担当します。

両社の連携により、診断範囲の整理、AWSの設定変更、ネットワークの見直し、監視・運用まで一貫して対応できます。AWS環境の設定や脆弱性に不安がある場合は、現在の構成や運用状況の確認からご相談ください。