2026.08.22

クラウドセキュリティ診断の進め方と選び方

経営リスクナビ編集部

クラウドセキュリティ診断は、AWS・Azure・Google CloudやSaaS（Microsoft 365、Google Workspace等）を使う中で、設定が適切か、情報漏えいリスクがどこに残っているかを第三者目線で把握するための実務手段です。設定の棚卸しが曖昧なままだと、ストレージ公開や外部共有などの誤設定が見過ごされ、監査対応や取引先からの説明要求で手戻りや是正コストが増えやすくなります。特にTCPポート3389（RDP）のような管理系ポートの開放や、共有設定の戻りは「気づいた時には外部から到達できる」状態になり得ます。以下では、クラウド特有のリスクの判断材料として診断の種類・対象範囲・進め方と見積りの見方を示します。

クラウドセキュリティ診断とは
- 目的とクラウド特有のリスク
- 共有責任モデルで切り分ける診断対象の決め方
クラウド診断の種類と評価軸
- 設定・脆弱性・準拠評価の整理
- CISベンチマークで見る評価
クラウド環境の診断対象
クラウド設定診断の確認項目
診断の進め方と社内準備
費用感とベンダー選定
診断後の活用とよくある質問
クラウドセキュリティ診断への対応で次にすべきこと

クラウドセキュリティ診断とは

目的とクラウド特有のリスク

クラウドセキュリティ診断は、AWS・Azure・Google CloudやSaaS（Microsoft 365、Google Workspace等）の利用に伴い、利用者側の設定不備（誤設定）や運用上の抜け漏れを第三者目線で洗い出し、情報漏えい・不正アクセス・設定改ざんの発生確率と影響を下げるために実施します。クラウドは短時間で構成変更できる反面、設定を誤ると資産がインターネットに露出しやすく、境界防御だけでは管理しきれない点が特徴です。

参照情報でも、クラウド移行後は「サービス側の問題」ではなく利用者側のセキュリティの問題で事故が起き得ることが示されています。典型例は、クラウドストレージの公開権限ミスにより、機密情報が公開情報としてネット上から閲覧・ダウンロード可能になってしまうケースです。また、業務系SaaSでも共有設定が非公開になっておらず、ゲストアカウント等の簡易アカウントで意図せず閲覧できる状態が発生し得ます。さらに、ストレージのURLリンクが分かれば第三者でも閲覧できる状態に置いてしまう、といった「人的ミス前提」でのリスクがあるため、適宜監査（定期点検）する設計が重要です。

クラウド診断で典型的に狙う事故の入口（例）

ストレージや共有フォルダの公開権限ミスにより機密データが外部から閲覧可能になる
リモート接続の入口としてTCPポート3389（RDP）がインターネットに開放されたままになり侵入を誘発する
ゲストアカウントや外部共有の設定不備により意図しない相手が資料にアクセスできる

このような状況を、外部専門組織による第三者チェックとして確認する（クラウド環境診断、外部公開サーバや通信機器に対する脆弱性診断、ネットワーク環境診断等）ことは、安全性担保の実務上の選択肢になります。

共有責任モデルで切り分ける診断対象の決め方

診断スコープは、クラウド事業者と利用者の責任を分けて考える共有責任モデルで整理します。クラウド事業者が担うのは主に基盤（物理設備等）であり、利用者はクラウド上でのID管理、アクセス制御、共有設定、ログ取得設定、運用手順などを自社責任として管理します。参照情報でも、クラウド利用時は「利用者側の問題」により情報漏えいが生じ得ること、そしてその前提で適宜監査していくことが推奨されています。

実務では、まず「自社の重要情報資産」と「想定インシデント」を置き、リスク分析として「発生可能性のあるインシデントに対するセキュリティ対策状況を評価する」観点で、診断対象を決めます。さらにクラウドでは、サービス種別により取得できるログが異なるため、「自組織の利用サービスでどのログが取れるか」を先に確認し、責任範囲に含まれる設定（例：ログ取得の有効化）を診断対象に入れるのが合理的です。

クラウド診断の種類と評価軸

設定・脆弱性・準拠評価の整理

クラウドのセキュリティ評価は、主に設定診断・脆弱性診断・準拠評価（監査観点）を分けて整理すると、社内説明やベンダー選定がしやすくなります。

区分	主対象	目的	例（参照情報に基づく具体例）
設定診断	クラウドの管理設定（ID、共有、公開、ログ等）	誤設定・運用不備の検出	クラウドストレージの公開権限ミス、業務SaaSの共有が非公開でない、URLリンクで第三者閲覧可能など
脆弱性診断	外部公開サーバ、通信機器、OS、ミドルウェア、アプリ	既知の脆弱性の把握と悪用可能性の評価	外部公開されているサーバや通信機器に対する脆弱性診断（第三者チェックの一類型）
準拠評価	組織・ルール・監査証跡	対外説明・監査対応の根拠作り	ログ取得の推奨、是正記録を監査エビデンスとして残す運用など

クラウド診断の主な類型（実務上の使い分け）

なお、脆弱性診断の実務は「スキャンして終わり」ではなく、参照情報にあるとおり、公開脆弱性に対して検証環境でパッチ適用の影響や修正の妥当性、場合によっては攻撃コードの有効性まで確認する「脆弱性分析」を伴うことがあります。クラウド設定診断とは対象も手順も異なるため、発注時に区別しておくことが重要です。

CISベンチマークで見る評価

クラウド設定を客観評価する枠組みとしてCISベンチマークが用いられることがありますが、実務では「基準に照らす」だけでなく、人的ミス前提の監査や、実際の運用（権限付与・共有・ログ取得）に落とし込める形で評価指標を設計することが重要です。

参照情報では、クラウドは利用者側の設定ミスで情報漏えいが起き得る（例：公開権限、共有設定、URLリンク）ため、「このようなことが発生する前提で適宜監査していく」ことが推奨されています。したがって、CIS等の基準を使う場合も、

基準適合の評価で見落としやすい運用論点

共有設定や公開設定が運用変更で戻っていないかを定期的に監査できるか
ゲストアカウント等の簡易アカウントの扱いが、ポリシーと実設定で一致しているか
ログ取得がデフォルト無効のサービスが混在しても検知できる設計になっているか

のように、継続運用でズレが出るポイントまで評価軸に含めると、監査対応や取引先説明に耐える診断になりやすいです。

クラウド環境の診断対象

IaaSとSaaSの対象範囲

IaaSとSaaSでは、利用者が実質的にコントロールできる範囲が異なるため、診断対象も変わります。

形態別に「利用者側の責任」として診断に入れやすい領域

IaaSでは外部公開サーバや通信機器の脆弱性診断、ネットワーク環境診断、OSやミドルウェア設定の確認が論点になりやすい
SaaSでは共有設定が非公開になっているか、ゲストアカウント等で意図せず閲覧できないか、公開リンク（URL）で第三者閲覧が成立しないかが論点になりやすい

参照情報でも、クラウド移行後は利用サービスの設定不備がないか確認することが重要とされており、SaaSの場合は特に「共有・公開」起因の事故形が目立つため、診断対象に明示しておくと現場が動きやすいです。

AWS・Azure・Google Cloudの着眼点

主要クラウドの診断では、共通論点（ID、公開、ログ、監視）を押さえつつ、プロバイダーごとの設定経路・用語差に合わせて確認します。ここでは参照情報の具体例（公開・共有・ログ・RDPポート）に沿って、診断観点を「現場で確認可能な形」に寄せます。

3大クラウドで共通して優先度が上がりやすい確認観点（例）

ストレージや公開リンクの扱いが、第三者閲覧・ダウンロード可能な状態になっていないか（URLリンクで閲覧できる状態を含む）
インターネット向けの入口が必要最小限か（特にTCPポート3389のような管理系ポートが開放されたままになっていないか）
サインイン、リソースアクセス、設定変更のログが取得できているか（サービスごとに取得可否が異なる点を前提に確認する）

また、メール基盤をSaaS（Google WorkspaceやMicrosoft 365ビジネスプラン）に寄せている場合、参照情報のとおり、ウィルス対策や迷惑メールフィルタ、危険メールの警告などの機能面でセキュリティ差が出ます。ただし、診断では「機能がある」ことよりも、有効化状況・運用状況（例：警告や隔離の運用、共有設定の管理）が意図どおりかを確認対象に含めるのが実務的です。

サーバーレス・コンテナ利用時に診断項目が増える境界線

サーバーレスやコンテナでは、従来の「サーバ単位の境界」だけでなく、実行単位（関数、ワークロード、IAM権限）での設定ミスが事故につながります。参照情報が示す「人的ミス前提で適宜監査する」という考え方は、クラウドネイティブほど重要になります。

クラウドネイティブ構成で増えやすい診断観点（例）

公開エンドポイントや共有設定が意図せず外部に開いていないか（URLリンクで第三者閲覧が成立しないかを含む）
実行権限や委任の設計が過剰になっていないか（設定変更の影響範囲が広がりやすい点を踏まえる）
不正なサインインや設定変更を追えるログが取れているか（サービスによりログ取得設定がデフォルト無効の可能性がある）

クラウド設定診断の確認項目

アクセス制御と公開設定の確認

設定診断で最優先になりやすいのは、アクセス制御（誰が何をできるか）と、公開設定（外部に見えていないか）です。参照情報でも、クラウドストレージの公開権限ミスにより、機密情報が公開され「広く閲覧、ダウンロードできてしまう」こと、業務系SaaSで共有設定が非公開になっていないためにゲストアカウントでも閲覧できてしまうこと、URLリンクが分かれば第三者でも閲覧できることが、具体的な事故形として示されています。

確認項目（公開・共有に直結するもの）

クラウドストレージの公開権限が「機密情報を公開情報として扱う」状態になっていないか
共有設定が非公開になっているか、ゲストアカウント等で意図せず閲覧できないか
URLリンクを知っているだけで第三者閲覧が成立する共有方式が残っていないか

加えて、インターネットから見た「入口」の管理は重要です。参照情報では、TCPポート番号3389が公開されっぱなしの場合は特に危険であり、攻撃者に侵入を誘導するようなものだと指摘されています。従って、公開ポートの棚卸しは、設定診断でも優先的に点検する価値があります。

ログ・暗号化・監視設定の確認

クラウドでは、攻撃者がサインイン、リソースアクセス、設定変更を行う可能性があるため、その有無と内容を確認する目的でログ取得が推奨されます。参照情報でも、クラウド環境やサービスでもログを取得すること、取得できるログはサービスに依存するため「自組織でどのようなログが取得できるのか確認」すること、そしてPaaSでは「デフォルトではログ取得が無効の場合があるため有効化する」ことが述べられています。

ログ設計・運用で実務上つまずきやすい論点（参照情報に基づく）

利用中のクラウドサービスごとに取得可能なログの種類が違うため、まず取得可否を棚卸しする
PaaSではログ取得がデフォルト無効のことがあるため、有効化設定が診断対象になる
ログ保管に別途ストレージが必要となり追加コストがかかる場合があるため、保管設計を前提にする

ログ管理の具体的な運用手段として、参照情報ではZabbix等のログ管理システムが挙げられています。どの製品を採るにせよ、診断では「取れているか」だけでなく、アラート通知や保管、権限（ログ閲覧・改ざん耐性）の運用まで確認できると、監査対応の説明力が上がります。

管理者アカウントの棚卸しで見落としやすい委託先・退職者・兼務者の残存権限

クラウド運用では、権限の付け替えが容易な一方で、不要アカウントや過剰権限が残りやすい点がリスクになります。参照情報にも「ID管理／退職社員や不要なIDを直ちに削除」がクラウド対策項目として明記されています。

棚卸しで最低限確認したい点（参照情報を踏まえた実務観点）

退職社員や不要なIDが残存していないか（直ちに削除できる運用になっているか）
委託先アカウントが契約終了後も残っていないか（共有リンクやゲスト権限も含めて確認する）
兼務や異動で付与した権限が戻っていないケースがないか（定期棚卸しの証跡を残せるか）

診断の進め方と社内準備

事前準備と必要な体制・情報

診断を成功させるには、技術設定だけでなく「何を診断し、何を証跡として残すか」を先に整理します。参照情報では、クラウド移行後に設定不備がないかを確認する目的のクラウド環境診断や、外部公開サーバ・通信機器への脆弱性診断、ネットワーク環境診断など、第三者チェックの重要性が述べられています。したがって、社内準備では「クラウド設定」だけでなく、外部公開資産やネットワークも対象に含めるかを最初に決めるのが実務的です。

事前に揃えると診断の手戻りが減る情報

外部公開されているサーバや通信機器の一覧（脆弱性診断の対象定義に直結）
クラウドストレージや業務SaaSの共有方式（公開リンクの有無、ゲスト利用の有無）
利用中クラウドサービスで取得できるログの種類と、PaaSのログ取得が有効かどうか

また、診断中の対応力は事故抑止に直結します。参照情報には有事の際に冷静に対応できる管理職行動の観点（複数ルートで判断、即決しない、過剰反応しない）が示されていますが、診断プロジェクトでも、検出事項の一次情報を複数経路で確認し、影響を見極めて是正判断する運用は有効です。

ヒアリングから報告書までの流れ

診断の流れは、第三者チェックとしての位置づけを明確にしつつ、対象（クラウド設定／外部公開資産の脆弱性／ネットワーク環境）を合意して進めます。参照情報にある「攻撃者はクラウドサービスへのサインイン、リソースアクセス、設定変更を行うことがある」という前提に立つと、ヒアリング段階で「どのログが取れているか／取れていないか」を確認し、収集フェーズでログ取得設定の有効化も含めて検討対象に入れるのが合理的です。

診断プロセスでの確認ポイント（実務用）

対象の確定としてクラウド設定診断に加え外部公開サーバ・通信機器の脆弱性診断やネットワーク環境診断を含めるか合意します。
利用中サービスで取得できるログ種類を棚卸しし、PaaSでログ取得がデフォルト無効の箇所がないかを確認します。
検証で見つかった「公開権限ミス」「共有が非公開でない」「URLリンクで第三者閲覧が成立」等は、影響範囲を確認したうえで優先度付けします。
ログ保管に別途ストレージが必要で追加コストがかかる場合があるため、是正計画に保管設計を織り込みます。

情シス・開発・法務・監査で事前に集める資料と役割分担

診断を「技術イベント」で終わらせないためには、社内の役割分担と証跡設計が必要です。参照情報の第三者チェックは、クラウドだけでなく、外部公開サーバや通信機器の脆弱性診断、ネットワーク環境診断、さらに内部からの情報漏えい等の人的リスクも含めた全体診断が重要だとしています。この前提に立つと、情シス・開発だけでなく、監査・法務も含めて「どこまでを診断範囲にするか」を文書化することが重要です。

部門別に集めたい資料（参照情報の論点に紐づけ）

情シス：退職社員や不要IDを直ちに削除できているかを示すアカウント棚卸し資料
開発：外部公開資産（サーバ・通信機器）とネットワーク経路の一覧（脆弱性診断・ネットワーク診断の対象定義）
法務：外部専門組織による第三者チェックを依頼する際の委託管理（アクセス範囲・守秘の合意）
監査：クラウドで取得できるログの種類と取得設定のエビデンス（PaaSのログ取得が無効になっていないかを含む）

費用感とベンダー選定

簡易・詳細・継続診断の費用感

費用感は診断対象（クラウド設定だけか、外部公開サーバ／通信機器の脆弱性診断やネットワーク環境診断まで含めるか）で変わります。参照情報でも、第三者チェックとして「外部公開されているサーバや通信機器に対する脆弱性診断」「ネットワーク環境診断」「クラウド環境診断」が並列で挙げられており、スコープ拡張がそのまま工数増につながる点を前提に見積りを読む必要があります。

また、ログ運用はコストに直結します。参照情報のとおり、ログ保管には別途ストレージが必要になり、追加コストがかかる場合があります。診断費用だけでなく、是正でログ取得を有効化した後の保管・監視の運用費も含めて投資計画を立てるのが現実的です。

提供メニューと見積りの見方

見積り比較では、「何を第三者チェックとして確認するのか」を明確にします。参照情報の範囲に沿うと、少なくとも「クラウドの設定不備確認」「外部公開サーバ・通信機器への脆弱性診断」「ネットワーク環境診断」がメニューとして混在し得るため、含まれる／含まれないを分解して確認することが重要です。

見積りで分解して確認したい論点（参照情報を踏まえた例）

クラウドストレージの公開権限、SaaS共有設定、URLリンク共有など「設定不備」まで対象に入っているか
外部公開サーバや通信機器に対する脆弱性診断が含まれるか（含まれない場合は別契約か）
ネットワーク環境診断が含まれるか（拠点間・外部公開経路の確認をどこまでやるか）
PaaSのログ取得がデフォルト無効の可能性を前提に、ログ取得状況の棚卸しや有効化助言が範囲内か
ログ保管に必要な追加ストレージ等のコスト増を前提に、運用設計の助言が含まれるか

対応実績と報告書品質の見極め

ベンダー選定では、診断が「第三者チェック」として機能するか、つまり自社の誤設定・人的ミスを前提にした指摘が出るかを見ます。参照情報にある具体例（公開権限ミス、共有が非公開でない、URLリンクで第三者閲覧、TCPポート3389開放、ログ取得推奨、PaaSログがデフォルト無効の場合がある、ログ保管に追加コスト）を、報告書がどの粒度で扱えるかが実務上の分かれ目です。

報告書サンプルで確認したい「実務に効く」観点

共有設定が非公開でない場合に、ゲストアカウント等で閲覧可能になるリスクを前提に再発防止策まで書けているか
URLリンク共有により第三者閲覧が成立する条件を明確化し、設定変更の手順と影響を示せるか
TCPポート3389等の危険な開放ポートを、外部から見た入口管理として優先度高で指摘できているか
ログ取得がサービス依存である点や、PaaSでデフォルト無効の可能性、ログ保管の追加コストまで含めて助言できているか

診断後の活用とよくある質問

報告書を改善計画に落とし込む

診断結果は、設定変更をして初めて価値になります。参照情報にある事故形（公開権限ミス、共有設定の不備、URLリンクで第三者閲覧、TCPポート3389の公開）を前提に、まず「外部から到達できるもの」「第三者閲覧が成立するもの」を優先して改善計画に落とし込みます。

改善計画に落とす際の実務ステップ（例）

公開権限ミスやURLリンク共有など、第三者が閲覧・ダウンロード可能になり得る項目を最優先で是正対象にします。
TCPポート3389等の入口が公開されている場合は、業務影響を確認しつつ速やかに閉鎖や制限を検討します。
ログについて、取得できるログ種類の棚卸しと取得設定の有効化（PaaSのデフォルト無効を含む）を計画に組み込みます。
ログ保管に別途ストレージが必要で追加コストがかかる場合があるため、保管期間・保管先・権限を含めて運用設計します。

実施事例の類型と継続評価の考え方

診断の実施形態は、スポットと継続に分けて考えると整理しやすいです。参照情報では、クラウドの設定不備は人的ミスで起き得るため「適宜監査していくのがよい」とされており、継続評価の必要性と親和性があります。

継続評価で押さえるべき観点（参照情報に基づく）

共有設定が非公開に維持されているか、ゲストアカウント等で意図せず閲覧できないかを定期監査する
ストレージの公開権限やURLリンク共有が、運用変更で復活していないかを定期監査する
クラウドのサインイン、リソースアクセス、設定変更のログが継続取得できているかを点検する

無料トライアル診断は活用できますか？

無料トライアルは、レポートの見え方だけでなく、「参照情報で典型例として挙げられている論点」をどの程度拾えるかを見るために活用できます。例えば、ストレージの公開権限や共有設定、URLリンク共有、外部公開ポート（TCPポート3389等）、ログ取得状況（PaaSでデフォルト無効の可能性を含む）といった観点がトライアルで確認できるかを整理して試すと、導入判断の精度が上がります。

どの程度の頻度で実施すべきですか？

頻度は、設定変更頻度と人的ミスの起こりやすさを前提に決めます。参照情報が示すとおり、クラウドでは利用者側の設定ミスで情報漏えいが起き得るため、共有設定や公開権限、URLリンク共有のような「戻りやすい設定」を定期監査する発想が重要です。

頻度設計で基準にしやすい対象（参照情報の事故形に対応）

公開権限や共有設定（非公開維持、ゲスト閲覧の抑止、URLリンク共有の統制）は変更が入りやすいため定期監査が必要です。
外部公開の入口（特にTCPポート3389のような管理系ポート）は棚卸しの頻度を高めると事故抑止に効きます。
ログ取得はサービス依存でありPaaSでデフォルト無効の場合があるため、定期的に取得設定と保管状況を点検します。

サービス停止は必要になりますか？

クラウド設定診断は、管理設定やログ設定、共有設定などを確認する性質が強く、原則として稼働停止を前提としません。ただし参照情報にもあるとおり、ログ保管には別途ストレージが必要で追加コストがかかる場合があるため、診断後の是正でログ取得を有効化する際は、保管先追加や運用変更に伴う影響（権限・保管設計）を事前に確認して進めるのが安全です。

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

クラウドセキュリティ診断は、クラウド特有の誤設定（公開権限・共有設定・URLリンク共有）や、外部から見た入口管理、ログ取得の設計を「第三者チェック」として可視化し、監査や取引先説明に耐える根拠を作る取り組みです。判断の軸は、共有責任モデルの範囲で自社が管理すべき設定（ID・アクセス制御・ログ等）と、外部公開サーバ／通信機器の脆弱性診断やネットワーク環境診断まで含めるかのスコープ設計にあります。特にTCPポート3389（RDP）の開放や、PaaSでログ取得がデフォルト無効の箇所がないかは、優先度を上げて確認しやすい論点です。次のアクションとして、外部公開資産の一覧、共有方式（ゲスト利用・公開リンクの有無）、取得可能なログの棚卸しを揃えたうえで、情シス・開発・法務・監査で役割分担と証跡の残し方を合意すると手戻りが減ります。個別の環境・契約条件により適切な範囲や是正手順は変わるため、必要に応じて外部専門組織や関係部門と相談しながら進めてください。