クラウド設定診断とは｜発注前に整理するアカウント・権限・対象範囲

クラウド設定診断を依頼するとき、利用しているクラウド名だけを伝えれば範囲が決まるように感じることがあります。しかし、一つの環境でもアカウント、利用サービス、権限、ログの管理方法が分かれていると、何を確認するかを共有できません。

結論から言うと、クラウド設定診断は、環境名ではなくアカウント・サービス・権限・ログの単位で範囲を決めます。対象環境だけでなく、閲覧できる権限、実施時間帯、変更の可否を発注条件に含めることが重要です。

発注前に構成情報を棚卸ししておくと、対象外の理由、報告書に求める対象時点、修正後に確認する範囲を関係者で整理できます。この記事では、運用担当者が用意する対象表と条件表の作り方を説明します。

本記事で分かること

• クラウド設定診断の対象単位
• アカウント・サービス・権限の整理方法
• 実施時の閲覧権限と変更管理
• 報告書と修正後確認の確認点

結論：アカウント・サービス・権限を分けて決める（早見表）

クラウド設定診断は、環境名だけでなく、アカウント・利用サービス・権限・ログの単位で対象を決めます。対象を一つの大きな領域として扱わず、管理者と確認できる範囲を対応付けます。

診断対象を棚卸しする

クラウド名だけで対象を指定せず、構成単位まで整理します。アカウント、環境、利用サービス、権限の関係を対象表に記載し、今回確認しない範囲も理由とともに残します。

アカウントと環境

対象を整理するときは、利用中のクラウド環境を一つの名前でまとめず、アカウントと環境を分けます。本番、検証、開発などの区分がある場合は、それぞれで確認できる設定や管理者が異なるかを確認します。今回の診断で扱う環境と、対象外にする環境を別の行へ記載します。

環境名だけで判断せず、業務上どの機能に関係するか、変更予定があるか、誰が管理しているかも残します。外部の委託先や別部門が管理するアカウントは、自社の判断だけで対象に含めません。管理者と承諾を得る窓口を確認し、対象にできない場合は理由を記録します。

利用サービス

利用サービスは、一覧を貼り付けるだけでなく、どの業務機能、画面、API、データ連携に関係するかを整理します。サービスの数だけで範囲を判断すると、重要な連携や設定の関係が見えにくくなります。対象表には、サービス名、役割、関連する担当、対象に含める理由を記載します。

利用中でも今回確認しないサービスがある場合は、対象外とする理由と見直す条件を残します。たとえば別の管理者がいる、変更予定がある、今回の目的と関係しないといった条件を明確にします。対象と対象外を分けることで、見積後に追加や除外が発生した際にも説明しやすくなります。

権限と役割

確認に必要な権限は、設定を変更する権限と分けて考えます。誰がどの範囲を閲覧できるか、提供の承諾を誰が行うか、実施中の質問を誰が受けるかを整理します。権限名だけではなく、確認できる対象との対応関係を記録します。

権限を用意できない領域がある場合は、対象外にするのか、別の確認方法を検討するのかを関係者で判断します。発注前に未確認の権限を確定したように扱わず、確認先と期限を残します。権限の条件を明確にすると、対象範囲と実施制約を同じ前提で説明できます。

実施条件をそろえる

閲覧権限と変更可否を分け、運用への影響を管理します。実施に使う環境、避ける時間帯、変更が必要になった場合の連絡方法を条件表にまとめます。

参照権限

参照権限は、診断のために確認できる範囲を決める情報です。提供する権限の種類、利用できる期間、通常の連絡窓口を整理し、対象アカウントと対応付けます。閲覧できることと、設定を変更できることを同じ権限として扱わないようにします。

権限の準備には、管理者の承諾や社内の手続きが必要になる場合があります。準備できる範囲と準備中の範囲を分け、見積書の前提に未確認の条件を含めないことが大切です。提供方法についても、社内の取扱いルールと契約上の条件を確認します。

実施時間帯

実施時間帯は、通常の利用状況、保守予定、変更作業の予定を踏まえて決めます。対象環境が利用される時間帯や、連携先の都合で避ける時間帯がある場合は、依頼先へ共有します。いつでも確認できると仮定せず、確認可能な条件を明記します。

本番環境を対象にする場合は、通常時の連絡先と、判断が必要な場合の連絡先を決めます。別の環境を対象にする場合も、本番と異なる設定や対象外の範囲を記録します。実施時点の前提を残すことで、報告書を読む際にも対象条件を確認できます。

変更管理と連絡

診断中に設定や構成を変更する予定がある場合は、変更を避ける期間と、変更が必要になった場合の連絡方法を決めます。完全に変更を止められない場合も、どの変更を共有するか、誰が対象への影響を判断するかを条件表に書きます。

セキュリティ診断の発注ガイドを参考に、対象、承諾、連絡体制、成果物を見積条件としてそろえます。変更管理の情報を先に共有すると、対象時点がずれたまま報告を受け取ることを避けやすくなります。

報告書で確認する範囲

設定の指摘は対象時点と対象環境をセットで確認します。報告書に記載される対象、優先順位の根拠、修正後に再確認する範囲を、発注時の対象表と照合します。

対象環境の記載

報告書を受け取ったら、対象にしたアカウント、環境、利用サービス、確認した時点が対象表と対応しているかを確認します。対象外にした範囲も分かれば、今回確認していない領域と今後見直す条件を関係者で共有できます。

対象時点の前提が発注時と異なる場合は、どの変更があったかを整理します。環境名だけで一致を判断せず、対象となるサービス、権限、変更予定も照合します。報告書を保管するだけでなく、対象表のどの行に関する結果かを結び付けます。

優先順位の根拠

指摘への対応順を決める際は、設定名だけでなく、関係する業務機能、対象環境、利用者、連携先を確認します。技術的な説明と業務上の判断を分け、事業責任者と情報システムの担当がどの順番で対応するかを決めます。

同じ指摘でも、対象が本番か検証か、公開範囲が異なるかで確認すべきことが変わります。対象表の情報を使って、どの環境に影響するかを整理し、対応の理由を記録します。優先順位を決めた後も、対象や構成に変更があれば見直します。

修正後の確認範囲

修正後の確認では、どのアカウント、サービス、権限を対象にするか、どの時点の設定を確認するかを決めます。修正が別の環境や連携先に関係する場合は、当初の対象表を更新し、追加で確認する範囲を関係者と合意します。

プラットフォーム診断の費用構造と、脆弱性診断の費用構造を参照し、対象単位と成果物の条件を比較表で確認します。再確認の対象、条件、結果の受け方を発注前から整理しておくと、修正後の調整を進めやすくなります。

まとめ

クラウド設定診断では、アカウント、利用サービス、権限、ログを対象表に分け、実施環境と変更管理の条件をそろえます。報告書では対象時点と対象環境を確認し、修正後にどの範囲を再確認するかまで発注前に整理しましょう。

クラウドの対象整理は、プラットフォーム診断の費用構造と、お役立ち記事一覧から確認できます。