クラウド移行後に「後から」気づくセキュリティリスク
「AWSに移行してから2年が経つが、一度もセキュリティ診断をしたことがない」という企業は少なくありません。クラウドはオンプレミスと比べてインフラ構築が容易な反面、設定ミスや権限の過剰付与が気づかれないまま放置されやすいという特性があります。
IBM X-Force 2024によれば、クラウド環境への攻撃の71%は設定ミス・過剰権限・不適切なアクセス制御が原因とされています。また、Gartnerは「2025年までにクラウドセキュリティ障害の99%は顧客側の設定ミスが原因になる」と予測しており、この傾向は2026年も変わっていません。
本記事では、クラウドセキュリティ診断の種類・費用相場・診断で発見される典型的なリスク・ベンダー選定のポイントを解説します。
クラウドセキュリティ診断とは
クラウドセキュリティ診断とは、AWS・Azure・GCPなどのクラウド環境の設定・権限・ネットワーク構成を専門家が評価し、セキュリティリスクを洗い出すサービスです。
大きく以下の3種類に分類されます。
診断種別 | 主な対象 | 特徴 |
|---|---|---|
設定・構成診断 | IAM権限・S3/BlobのアクセスポリシーなどクラウドサービスのConfig | 設定ミス・過剰権限の洗い出しが中心。短期間・低コストで実施可能 |
ネットワーク診断 | セキュリティグループ・VPC・ファイアウォールルール | 不要なポート開放・通信ルールの問題を検出 |
クラウドペンテスト | 上記すべてを対象にした侵入試験 | 実際の攻撃手法で設定ミスの悪用可能性を実証 |
対象別の診断内容と費用相場【2026年版】
AWS（Amazon Web Services）
AWSは国内最大シェアのクラウドサービスであり、診断実績を持つベンダーも多い分野です。
診断内容 | 費用目安 | 期間 |
|---|---|---|
AWS設定診断（IAM・S3・VPCなど） | 30万〜100万円 | 3〜7営業日 |
AWSネットワーク診断（セキュリティグループ・ALBなど） | 50万〜150万円 | 5〜10営業日 |
AWSペネトレーションテスト | 150万〜500万円 | 2〜4週間 |
よく発見される問題:
- S3バケットのパブリックアクセス設定ミス（機密データの誤公開）
- IAMユーザーへの過剰な管理者権限付与
- セキュリティグループの0.0.0.0/0（全IPからの受信）許可
- CloudTrailの無効化・ログ保持期間の不足
- MFAが設定されていないルートアカウント・IAMユーザー
Azure（Microsoft Azure）
Microsoft 365と連携している企業が多く、Entra ID（Azure AD）の設定診断の需要が高まっています。
診断内容 | 費用目安 | 期間 |
|---|---|---|
Azure設定診断（Entra ID・リソース権限・ネットワーク） | 40万〜120万円 | 3〜7営業日 |
Azure Defender / Sentinelの設定評価 | 30万〜80万円 | 2〜5営業日 |
Azureペネトレーションテスト | 150万〜600万円 | 2〜4週間 |
よく発見される問題:
- Entra IDでのゲストアカウントへの過剰な権限付与
- 管理者ロールが多すぎるユーザー（最小権限違反）
- NSG（Network Security Group）のデフォルト設定のまま運用
- Azure Storageのパブリックアクセス有効化
- Defender for Cloudのセキュリティスコアが低い
GCP（Google Cloud Platform）
BigQueryやCloud Storageの設定ミスによるデータ露出が特に多い環境です。
診断内容 | 費用目安 |
|---|---|
GCP設定診断（IAM・GCS・VPCなど） | 30万〜100万円 |
GCPペネトレーションテスト | 120万〜400万円 |
SaaS環境（Microsoft 365・Google Workspace等）
オンプレミスからクラウドに移行した企業で特に需要が高い診断です。
診断内容 | 費用目安 |
|---|---|
Microsoft 365 セキュリティアセスメント | 30万〜80万円 |
Google Workspace セキュリティ設定診断 | 20万〜60万円 |
SaaS全体のシャドーIT調査 | 20万〜50万円 |
クラウドセキュリティ診断で発見される代表的なリスク
リスク1: IAM（Identity and Access Management）の設定ミス
最も多く発見される問題です。「とりあえず管理者権限を付与した」「サービスアカウントに不要な権限が残っている」などのケースが典型的です。
影響： 攻撃者が一つのアカウントを侵害した場合に、クラウド環境全体に横展開できてしまう。
リスク2: パブリックアクセス設定ミス
S3バケット・Azure Storage・GCS（Google Cloud Storage）のアクセス設定を誤って全インターネット公開してしまうケース。機密顧客データ・バックアップデータが外部から丸見えになる重大リスクです。
リスク3: ネットワーク設定の過剰な開放
セキュリティグループ・ファイアウォールルールで全IPからのSSH（22番）・RDP（3389番）接続を許可しているケース。攻撃者のブルートフォース攻撃の入口になります。
リスク4: ログ・監視の不備
CloudTrail・Azure Monitor・Cloud Auditのログが無効化・保持期間が短いケース。インシデント発生時にフォレンジック調査ができなくなります。
リスク5: 秘密情報のハードコーディング
GitリポジトリやLambda/Functionsのコード内にAPIキー・パスワードがハードコーディングされているケース。公開リポジトリに誤って含まれると即座に悪用されます。
クラウドセキュリティ診断ベンダーの選び方
確認すべき5つのポイント
1. 対象クラウドの診断実績
AWSに強いベンダーでもAzureの診断実績が少ない場合があります。自社の利用クラウドでの実績を必ず確認する。
2. CIS Benchmarkなど標準への準拠確認
CIS（Center for Internet Security）が公開するクラウド別のセキュリティベンチマークに準拠した診断を実施しているかを確認。標準に基づいた診断はスコアリングが明確で、改善状況の追跡がしやすい。
3. 自動ツール vs 手動診断の割合
Prisma Cloud・Prowlerなどの自動ツールだけで完結する診断と、エンジニアが手動で評価を加える診断では、検出精度と費用が異なります。コンプライアンス目的では手動評価が含まれる方が信頼性が高い。
4. 診断後の継続サポート
発見した問題の修正方法まで丁寧にサポートしてくれるか、修正後の再確認（リテスト）が費用に含まれているかを確認する。
5. 監査・コンプライアンス対応実績
ISMS・SOC2・PCI DSSなどの認証取得を目的とした診断では、監査人が認める形式のレポートが必要です。
まとめ：クラウド移行後は「設定診断」から始める
クラウドを使い始めて1〜2年が経つ企業の多くは、初期設定のまま運用していることが多く、複数の設定ミスが積み重なっている状態です。まずは「現状把握」を目的とした設定診断を実施し、重要なリスクを特定してから改善計画を立てることをお勧めします。
設定診断は費用が比較的低く（30万〜100万円程度）、短期間（1週間前後）で完了します。投資対効果の観点から、クラウドセキュリティ強化の最初の一手として最適です。
AEVUSでは、AWS・Azure・Microsoft 365を対象としたクラウドセキュリティ診断を提供しています。「どこから始めればいいかわからない」という方はまずお気軽にご相談ください。
関連記事
クラウドセキュリティ診断の具体的なチェック項目
クラウドセキュリティ診断では、クラウド環境特有のリスクを体系的に評価するため、以下の5つのカテゴリーに沿ってチェックを実施します。オンプレミス環境とは異なり、設定ミスが即座に外部からの攻撃経路になり得るため、各項目の網羅的な確認が不可欠です。
IAM設定（Identity and Access Management）
- ルートアカウント・管理者アカウントへのMFA（多要素認証）の適用状況：特権アカウントへの不正アクセスを防ぐ最重要項目です
- 最小権限の原則に基づいたIAMポリシーの設計：不要なワイルドカード権限（*）が付与されていないか確認します
- サービスアカウント・アプリケーションIDの権限スコープ：CI/CDパイプラインや自動化スクリプトに付与された権限が過剰でないかを評価します
- 長期的に使用されていないアカウント・アクセスキーの存在：90日以上未使用のクレデンシャルは即時無効化の対象です
- アクセスキーのハードコーディングおよびリポジトリ露出：ソースコードやIaCテンプレートへの認証情報の埋め込みを検出します
- ロールの引き受け（AssumeRole / Managed Identity）の信頼ポリシー設定：意図しない外部アカウントからのロール引き受けが可能になっていないかを確認します
- パスワードポリシーの強度：文字数・複雑性・有効期限・再利用制限の要件を確認します
- 権限昇格パス（Privilege Escalation Path）の有無：IAM権限の組み合わせによって意図しない管理者権限取得が可能なパスがないかを分析します
ネットワーク設定
- セキュリティグループ・ネットワークACLのインバウンドルール：SSH（22番）・RDP（3389番）・データベースポートへの全インターネット開放（0.0.0.0/0）を重点確認します
- パブリックサブネットへの不必要なリソース配置：データベースや内部APIサーバーがパブリックサブネットに誤配置されていないかを確認します
- VPCフローログの有効化とログ保存期間：ネットワークトラフィックの可視化とインシデント調査への備えを評価します
- WAF（Webアプリケーションファイアウォール）の適用状況：公開Webサービスへのルールセットの適用と定期更新を確認します
- プライベートエンドポイント・VPCエンドポイントの活用状況：マネージドサービスへのアクセスがインターネットを経由しないよう構成されているかを確認します
- TLS/SSLの設定強度（証明書の有効期限・プロトコルバージョン・暗号スイート）：古い規格（TLS 1.0/1.1）の使用継続や脆弱な暗号スイートの有効化を検出します
データ暗号化
- ストレージサービスの暗号化設定（S3・Azure Blob Storage・GCS等）：サーバーサイド暗号化（SSE）の有効化とKMS管理キーの使用状況を確認します
- データベースサービスの暗号化（RDS・Cloud SQL・Azure SQL等）：保存データの暗号化有効化と暗号化キーの管理体制を評価します
- KMS（Key Management Service）のキー管理ポリシー：キーローテーションの設定・キー削除の保護・アクセス制御を確認します
- バックアップデータの暗号化：スナップショット・バックアップファイルが本番データと同水準で保護されているかを評価します
- シークレット管理サービスの活用（AWS Secrets Manager・Azure Key Vault・GCP Secret Manager）：パスワード・APIキー・証明書の安全な管理体制を評価します
ログ管理
- 管理操作ログ（CloudTrail / Azure Activity Log / GCP Audit Log）の有効化：全リージョン・全サービスを対象とした管理操作の記録状況を確認します
- ログの改ざん防止設定（ログファイルの整合性検証）：CloudTrail Log File Validationなどの改ざん検知機能の有効化を評価します
- ログの集約と長期保存設定：複数アカウント・リージョンのログを一元管理するアーキテクチャと保存期間（最低1年以上を推奨）を確認します
- データプレーンログ（S3アクセスログ・VPCフローログ・ALBアクセスログ）の有効化：重要リソースへのアクセス記録が取得されているかを評価します
- アラート・検知ルールの設定状況：特権操作・異常ログイン・設定変更に対するアラートが適切に構成されているかを評価します
コンプライアンス要件
- 個人情報保護法・GDPRへの対応状況：個人データの保存リージョン・保存期間・処理記録の整備状況を確認します
- PCI DSS準拠要件の充足状況：カード情報を扱う環境でのネットワーク分離・暗号化・アクセス管理要件への対応を評価します
- クラウドサービスの責任共有モデルの理解と実装：プロバイダー側とユーザー側の責任範囲を正確に把握し、漏れなく対応しているかを評価します
- 脆弱性管理プロセスの整備：クラウドリソースに対する定期的な脆弱性スキャンとパッチ適用プロセスの整備状況を評価します
クラウドセキュリティ診断の実施フロー
クラウドセキュリティ診断は、単なるツールスキャンにとどまらず、体系的なフェーズを踏むことで実効性の高い結果が得られます。
- フェーズ1：スコーピング（診断範囲の定義）
診断の品質と効率を左右する最初の工程です。対象クラウド環境（AWS・Azure・GCP）の全体像を把握し、対象アカウント数・サブスクリプション数を明確にします。診断手法（構成設定レビュー（CSPM）・ペネトレーションテスト・コードレビュー（IaC））の合意、ビジネスクリティカルな資産の優先度付け、本番環境への影響を避けるための除外対象の明確化を行います。スコーピング完了時には診断範囲を明記した合意文書を作成し、依頼者とベンダー双方が署名・承認する形式が望ましいです。
- フェーズ2：情報収集（インフォメーションギャザリング）
診断専用のIAMロール・ユーザーを作成し、読み取り専用（ReadOnly）権限を最小限付与します。アーキテクチャ図・構成ドキュメントの収集、IaCテンプレート（Terraform・CloudFormation・Bicep等）の収集を行います。過去の診断レポート・インシデント記録の確認により、以前の診断で指摘された未対応項目を把握し診断の重点を絞り込みます。
- フェーズ3：診断実施
CSPM（Cloud Security Posture Management）ツール（Prisma Cloud・Wiz・AWS Security Hub等）を用いた自動スキャンと、ツールが検出できない複雑なリスクを手動で評価する手動分析を組み合わせます。IAM権限の手動分析では権限昇格パスや横断的なアクセス可能性を評価します。診断実施中は本番環境に影響を与える操作（リソースの作成・変更・削除）を厳に禁じます。
- フェーズ4：レポート作成
経営層向けエグゼクティブサマリー・リスク評価サマリー・詳細所見・改善ロードマップ・コンプライアンスマッピングを含む報告書を作成します。各所見に「なぜリスクなのか」「攻撃者にどう悪用されるか」「どう修正すれば解決するか」の3点を具体的に記載することで、経営層の理解と予算確保につながります。
- フェーズ5：是正確認（リメディエーション検証）
検出項目ごとに対応状況をトラッキングする管理表を提供し、定期的な進捗確認を行います。重大度の高い項目については、是正後に実際に修正されているかを再診断で確認します。是正対応が完了した項目を反映した最終版レポートを発行し、コンプライアンス証跡として保管します。
ベンダー選定の5つのポイントとよくある失敗事例
ポイント1：クラウド診断に特化した実績と経験
一般的なWebアプリケーション診断やネットワーク診断の実績とクラウド診断の実績は別物です。対象クラウドプラットフォームでの診断実績件数・期間を確認し、担当予定アナリストのプロフィールと経歴の開示を要求します。失敗事例：大手SIerに依頼したところ、実際の作業はクラウド経験の浅い協力会社に丸投げされており、最終報告書はCSPMツールの自動スキャン結果をそのまま出力したものでした。発注前にアナリストの経歴を確認していれば回避できた失敗です。
ポイント2：資格・認定の保有状況
AWS Certified Security Specialty・Microsoft Certified: Azure Security Engineer Associate等のクラウドプロバイダー認定と、CISSP・CCSP・OSCPなどの実技能力を証明するセキュリティ専門資格の保有状況を確認します。ただし、資格保有者が「診断に実際に関与する」かどうかを提案段階で明確に確認することが重要です。
ポイント3：使用ツールと診断手法の透明性
使用するCSPMツール・スキャナーの名称と手動評価との割合を確認します。業界標準フレームワーク（CIS Benchmarks・NIST CSF・OWASP Cloud等）への準拠を確認し、自動ツールだけでなく手動による権限分析・シナリオベースのテストが含まれるかを確認します。失敗事例：「最新ツールで網羅的にスキャン」と記載されていたが実際にはAWS Trusted Advisorの無料機能とオープンソースツールを組み合わせただけで、手動分析は一切含まれていませんでした。
ポイント4：報告書の品質と実用性
選定前にサンプルレポートの提示を必ず求めます。経営層向けと技術者向けの分離、再現性・根拠の明確さ（「設定が弱い」という指摘にとどまらず攻撃シナリオが具体的に記載されているか）、是正手順の具体性（コンソール操作手順・CLIコマンド・IaC修正例など）を確認します。
ポイント5：是正後のサポート体制とアフターフォロー
報告書の説明会・質疑応答・是正作業への技術的アドバイス提供が含まれるかを契約前に確認します。重大項目の是正後に再確認を行う再診断の費用・回数・期間を事前に合意します。クラウド環境は日々変化するため、単発診断から継続的なCSPM監視サービスへの移行オプションがあるかも確認します。ベンダー選定にあたっては、最低2〜3社から提案を取得して比較評価することを推奨します。
