クラウドサービスを導入するとき、多要素認証、共有範囲、管理者権限、監査ログ、外部アプリ連携などを慎重に設定します。 しかし、導入判定を通過した設定が、その後も安全であり続けるとは限りません。業務部門による機能追加、組織変更、例外対応、 サービス事業者の仕様変更によって、実際の設定は少しずつ基準から離れていきます。

IPAの「情報セキュリティ10大脅威2026」組織編は、クラウドの仕様変更に伴って意図せず設定が変わる可能性を踏まえ、 更新情報の確認と設定の見直しを対策として示しています。国家サイバー統括室のガイダンスも、クラウドでは利用者から見えない更新や 仕様変更が行われるため、事業者から提供される情報の把握と変更管理が必要だと説明しています。

つまり、クラウドセキュリティは「安全な初期値を決める仕事」だけではありません。変化を発見し、事業上の意味を判断し、 必要な修正または例外承認を行い、その結果を確かめ続ける仕事です。本記事では、特定のクラウド製品に限定せず、 SaaSやIaaSの設定を継続的に保証するための5つのステップを整理します。

具体的な課題：設定は変わるのに、確認は年1回のまま

クラウドでは、管理画面から短時間で機能を有効化できる一方、誰が、どの理由で、どの範囲を変えたかが複数の場所へ分散します。 一度の点検で「問題なし」と判断しても、翌日の変更、翌月の新機能、翌四半期の組織再編で前提が変わります。

  • 基準が曖昧：ベンダーの推奨値をそのまま採用し、自社の情報、利用者、業務影響、契約条件との関係が説明できない。
  • 設定の所有者が不明：IT部門、セキュリティ部門、業務管理者、委託先のうち、誰が変更を判断し、誰が復旧するか決まっていない。
  • 差分を手作業で探す：年次監査の画面キャプチャに依存し、確認の間に生じた変更や短期間だけ有効だった設定を捉えにくい。
  • 例外が期限なしで残る：業務上必要だった緩和設定が、代替策や終了条件を持たないまま恒久設定になる。
  • 検知しても直せない：大量の警告に優先順位がなく、事業影響の大きい設定不備が他の指摘へ埋もれる。
設定一覧を持つだけでなく、「望ましい状態」と「現在の状態」の差を、判断と改善へつなげることが出発点です。

考え方：基準、現在値、例外、証拠を一つの循環にする

CISAのSecure Cloud Business Applications（SCuBA）は、Microsoft 365やGoogle Workspace向けに、最低限の安全な設定基準と 評価ツールを公開しています。主な対象は米国連邦政府機関ですが、CISAは他の組織にも、自組織の要件とリスク許容度に合わせて 基準を検討するよう案内しています。2026年5月公開のScubaGear v1.8.0でも、評価結果の記録や例外を扱う仕組みが継続的に更新されています。

重要なのは、外部基準への一律適合ではありません。基準を出発点に、自社の重要業務とデータに応じて目標状態を決め、 現在値との差分を検知し、修正できない差分は理由・代替策・期限を持つ例外として管理します。さらに、修正後の再評価と経営・管理者への報告までを循環させます。

  1. 基準：何を、なぜ、その値に保つかを明確にする。
  2. 現在値：人の記憶ではなく、取得時点の構成情報として記録する。
  3. 差分：変更の有無だけでなく、影響する利用者、データ、業務を評価する。
  4. 例外：責任者、理由、代替策、期限、再評価条件を持たせる。
  5. 証拠：修正、承認、再確認の結果を追跡可能にする。

実践手順1：重要なクラウドと設定項目を絞り込む

最初から全サービス、全設定を同じ頻度で監視すると、運用負荷と警告量が膨らみます。まず、顧客情報、個人情報、設計情報、 認証情報など重要データを扱うクラウドと、停止・漏えい・不正操作が事業へ大きく影響するサービスを選びます。

そのうえで、外部共有、特権ロール、認証条件、監査ログ、データ保持、暗号化、API連携、ゲスト利用、転送規則、 公開範囲など、影響の大きい設定群を特定します。設定項目には、サービス名、テナント、所有部門、技術管理者、情報の種類、 重要業務、変更元、確認頻度をひも付けます。「設定の棚卸し」ではなく、事業上の優先順位を付けた監視対象表にすることがポイントです。

実践手順2：目標状態と判断理由を基準化する

ベンダー、公的機関、業界団体の基準を参考にしつつ、自社の目標値を決めます。各項目には、望ましい値だけでなく、 保護したい情報・業務、想定する脅威、適用範囲、確認方法、例外を認める条件を記載します。製品名や画面名だけに依存すると、 UI変更で基準が読めなくなるため、「外部共有は承認済みドメインに限定する」のように統制目的も残します。

基準の強さは一律でなくて構いません。たとえば、全社共通、重要データ取扱い、一般業務、検証環境の層に分ければ、 必要以上に業務を止めずに管理できます。ただし、緩和した層にも最低限守る設定と、昇格・本番移行時の条件を明記します。

実践手順3：差分を定期取得し、変更イベントと照合する

API、設定エクスポート、Infrastructure as Code、クラウド事業者の監査機能などを使い、現在値を決めた周期で取得します。 自動評価ツールを使う場合も、必要権限、取得範囲、保存先、機密情報の扱いを確認します。すべてを即時監視できなくても、 重要設定は日次または週次、その他は月次など、リスクに応じた頻度から始められます。

差分を見つけたら、承認済み変更、緊急対応、事業者の仕様変更、未承認操作のどれかを照合します。 「基準と違う＝直ちに誤り」とは限りません。変更理由と影響範囲を確認し、誤検知、承認済み例外、要修正、緊急対応の状態へ分類します。 NIST SP 800-137も、継続的監視を、資産・脅威・脆弱性とセキュリティ対策の有効性を把握し、リスク判断へ情報を提供する仕組みとして位置づけています。

実践手順4：例外を期限付きのリスク判断として管理する

業務要件、古い連携、ライセンス制約、段階移行などにより、基準どおりにできない設定はあります。その場合は、例外を非公式なメモにせず、 対象、理由、影響、承認者、所有者、代替策、開始日、終了日、見直し条件を記録します。期間が長い例外ほど、アクセス監視、対象者限定、 追加ログ、手動確認など、現実的な代替策を組み合わせます。

期限到来時は自動延長せず、業務がまだ必要か、製品側の制約が解消したか、利用者やデータ範囲が変わったかを再評価します。 例外件数だけでなく、重要度、経過日数、同じ理由の集中を見れば、個別対応では解けない構造的な課題も見つけられます。

実践手順5：修正後の再評価と運用指標まで閉じる

設定を修正したら、再取得して目標状態へ戻ったことを確認します。修正操作が別のサービス、連携、利用者へ影響していないかも確認し、 必要に応じて段階展開とロールバック手順を用意します。緊急度が高い差分でも、変更記録と事後確認を省略しないことが重要です。

月次や四半期のレビューでは、基準適合率だけでなく、重要差分の検知から判断までの時間、修正までの時間、期限切れ例外、 同じ設定の再発、確認不能な項目、取得失敗を見ます。数値を競うのではなく、長く残る差分や繰り返す原因へ改善資源を向けます。 サービスの新機能や廃止予定も基準見直しへ取り込み、監視対象そのものを更新します。

注意点：自動化を「自動修正」から始めない

  • 外部基準をそのまま義務化しない：対象組織、製品版、ライセンス、業務要件、リスク許容度の違いを評価する。
  • 検知と修正を直結しない：事業影響や承認済み変更を確認せず戻すと、業務停止や設定の競合を招く可能性がある。
  • 管理者権限を増やしすぎない：評価ツールには読み取り中心の最小権限を使い、認証情報と結果ファイルを保護する。
  • 画面キャプチャだけを証拠にしない：取得日時、対象、値、評価基準、判断、変更履歴を再現できる形式で残す。
  • 警告量を成果にしない：重要業務への影響と修正可能性で優先順位を付け、担当者が処理できる運用にする。
  • クラウド事業者へ責任を丸投げしない：契約・共有責任・仕様変更通知・問い合わせ経路を確認し、利用者側の運用責任を明確にする。

まとめ：安全な設定を、変化に追随できる運用へ変える

クラウド設定は、導入時に一度決めて保管する文書ではありません。重要サービスと設定を選び、目標状態と理由を定め、 現在値との差分を継続的に検知し、例外を期限付きで管理し、修正後の再評価まで閉じることで、変化に追随できる統制になります。

最初の一歩は、最も重要な一つのクラウドを選び、外部共有、特権権限、監査ログの3領域について、現在値と目標値を比べることです。 差分の理由と所有者を確認し、翌月にもう一度同じ方法で評価できれば、単発の点検から継続運用へ移り始めています。 仕組みの目的は、すべての変更を止めることではなく、安全に変え続けられる状態をつくることです。

参考資料

本記事は公式・公的資料をもとに、一般的なクラウドセキュリティ運用の考え方を整理したものです。 個別組織の法令適合性、契約、監査、クラウド製品の設定その他の法律上・専門上の助言を行うものではありません。 公式資料は2026年8月19日時点で確認しています。実際の運用では、自社の情報資産、サービス構成、契約、適用される法令・規格、 リスク許容度を踏まえ、必要に応じてクラウド事業者、関係部門、専門家へ確認してください。

FW

WRITTEN BYFourthWall Consulting Teamテクノロジーと経営の両面から、企業変革を支援しています。

← 技術ブログ一覧へ戻る