クラウドサービスの責任共有モデルとは？ 10分でわかりやすく解説

クラウドサービスを安全に使うには、「クラウド事業者がどこまで守り、利用企業がどこから管理するのか」を明確にする必要があります。この責任範囲を整理する考え方が、クラウドサービスの責任共有モデルです。

責任共有モデルでは、クラウド事業者がデータセンター、物理機器、基盤ネットワーク、仮想化基盤などを管理し、利用者はデータ、ID、権限、設定、ログ、利用ルールを管理します。ただし、責任境界はIaaS、PaaS、SaaSで変わります。契約、サービス仕様、監査資料、管理画面の機能を確認し、自社の運用に反映することが前提です。

クラウドサービスの責任共有モデルとは

責任共有モデルの定義

責任共有モデルとは、クラウドサービスの提供者と利用者が、セキュリティ、可用性、データ保護、運用管理に関する責任範囲を分担する考え方です。クラウド事業者はクラウド基盤を保護し、利用者はクラウド上に配置するデータ、アカウント、設定、アプリケーション、利用方法を管理します。

重要なのは、クラウドを使えばセキュリティ責任がすべて事業者へ移るわけではない点です。利用者がストレージを誤って公開する、不要な管理者権限を付与する、退職者アカウントを残す、監査ログを取得していない、といった状態では、クラウド基盤が安全でも情報漏えいにつながる可能性があります。

提供者が担う責任

クラウドサービス提供者は、一般にクラウド基盤の安全性と安定性を担います。具体的には、データセンター、物理サーバー、ストレージ、基盤ネットワーク、仮想化基盤、基盤ソフトウェア、サービスの可用性確保などです。

ただし、提供者が担う範囲はサービスによって異なります。SaaSではアプリケーション運用まで提供者側が担う場合が多く、IaaSではOS、ミドルウェア、アプリケーションの管理を利用者が担う場合が増えます。

利用者が担う責任

クラウド利用者は、クラウド上で扱うデータ、ID、権限、設定、利用ルールを管理します。特に、データとIDは多くのクラウド利用形態で利用者側の責任として扱われます。

クラウド上の事故は、基盤の障害だけでなく、利用者側の設定ミスや権限管理の不備からも発生します。責任共有モデルを理解することで、利用者側が管理すべき範囲を具体化できます。

責任共有モデルが重要な理由

「クラウドだから安全」という誤解を避ける

クラウド事業者は、基盤の安全性、可用性、物理セキュリティに大きな投資をしています。一方で、利用者が作成したアカウント、保存したデータ、設定したアクセス権限、公開したURLまでは、利用者側の判断に依存します。

例えば、クラウドストレージの公開設定を誤る、管理者権限を広く付与する、ログを無効にする、退職者のIDを残す、といった問題は利用者側の統制不備です。クラウド事業者の基盤が安全でも、利用設定が不適切であれば事故は起こります。

監査や取引先要件に対応しやすくなる

取引先や監査で、クラウド利用時のデータ管理、アクセス制御、ログ取得、委託先管理、バックアップ、インシデント対応を問われることがあります。その際、責任共有モデルを整理していないと、どの管理項目を自社が説明すべきか判断しにくくなります。

情報セキュリティポリシーやクラウド利用規程では、利用者側の責任範囲を明記します。サービス仕様、SLA、監査レポート、ログ機能、サポート窓口も確認対象になります。

事故時の切り分けが早くなる

障害、不正アクセス、設定ミス、データ消失が起きた場合、提供者側の基盤問題なのか、利用者側の設定・運用問題なのかを切り分ける必要があります。責任範囲が曖昧だと、復旧判断、連絡先、証跡確認、顧客説明が遅れます。

責任共有モデルを前提に、障害時の問い合わせ窓口、ログ確認手順、権限停止手順、バックアップ復旧手順を整えておくと、インシデント対応の初動を早められます。

IaaS・PaaS・SaaSで変わる責任範囲

責任共有モデルでは、サービス形態によって利用者が管理する範囲が変わります。一般に、IaaSは自由度が高い分、利用者の責任範囲が広くなります。SaaSは提供者の管理範囲が広い一方で、利用者はアカウント、権限、データ、設定を管理します。

IaaSの責任分担

IaaSでは、仮想サーバー、ストレージ、ネットワークなどのインフラ機能を利用します。クラウド事業者は物理基盤や仮想化基盤を管理し、利用者はOS、ミドルウェア、アプリケーション、データ、ネットワーク設定、アクセス制御を管理する場合が一般的です。

IaaSでは、OSのパッチ適用、不要ポートの閉鎖、ファイアウォール設定、管理者権限、ログ取得、バックアップ設計を利用者が担う範囲に含めます。自由度が高い分、設定ミスや更新漏れが事故につながりやすくなります。

PaaSの責任分担

PaaSでは、アプリケーション実行環境、データベース、開発基盤などをサービスとして利用します。OSや実行環境の多くは提供者が管理し、利用者はアプリケーション、データ、接続設定、認証・認可、シークレット管理、ログ設計を管理します。

PaaSはIaaSより基盤管理の負担を減らせますが、アプリケーションの脆弱性、API公開範囲、認証設定、データベース接続情報、アクセス権限の管理は利用者側に残ります。

SaaSの責任分担

SaaSでは、アプリケーションそのものをサービスとして利用します。提供者はアプリケーション基盤、運用、可用性、更新を担う場合が多く、利用者はユーザー管理、権限設定、データ入力、共有設定、外部連携、利用ルールを管理します。

SaaSでも、利用者の責任は小さくありません。管理者権限を広く付与する、外部共有リンクを放置する、退職者アカウントを残す、ログを確認しない、といった状態では情報漏えいの原因になります。

サービスモデル別の責任分担

この整理は一般像です。実際の境界はサービスごとに異なります。利用前に、公式ドキュメント、契約、SLA、管理画面、監査資料を確認し、自社の管理項目へ反映します。

クラウド利用者が優先すべきセキュリティ対策

IDとアクセス管理を整える

クラウドでは、IDが重要な防御点になります。IDが侵害されると、正規ユーザーとしてデータ閲覧、設定変更、外部共有、管理操作が行われる可能性があります。

多要素認証、最小権限、特権IDの分離、不要アカウントの削除、退職者アカウントの即時停止、外部委託先アカウントの期限管理を実施します。管理者権限は常時付与せず、必要な作業に限定して使う設計を検討します。

設定ミスを検出できる状態にする

クラウドでは、ストレージの公開、セキュリティグループの許可範囲、APIキーの露出、ログ無効化、暗号化未設定などが事故につながります。設定ミスは一度の点検だけでは防ぎきれないため、継続的に確認します。

CSPMなどの設定監査ツールを使う場合は、検出結果を誰が確認し、どの基準で修正し、どの例外を認めるのかを決めます。検出だけで止めず、修正までの流れを定義します。

ログを取得し、調査に使える形で保管する

監査ログ、認証ログ、操作ログ、APIログ、ネットワークログは、不正アクセス、誤操作、設定変更、情報持ち出しの確認に必要です。ログがなければ、何が起きたのか、どの範囲に影響したのかを追えません。

ログは取得するだけでは不十分です。保存期間、検索項目、アラート条件、閲覧権限、インシデント時の確認手順を決めます。重要システムでは、ログ改ざんや削除に備えて、管理者とは別の保管先に転送する設計も検討します。

データ保護とバックアップを設計する

クラウド上のデータは、分類、暗号化、共有範囲、保持期間、削除、データのバックアップを決めて管理します。個人情報、営業秘密、契約情報、設計資料などは、保存場所とアクセス権限を明確にします。

バックアップは、クラウド事業者の可用性とは別に考えます。誤削除、ランサムウェア、設定ミス、内部不正に備え、復旧できる時点、保存場所、アクセス権限、復旧手順を確認します。

インシデント対応手順を用意する

クラウド上で不正アクセスや設定ミスが見つかった場合、アカウント停止、セッション無効化、共有リンク削除、権限変更、ログ保全、影響範囲調査を行います。これらを発生後に考えると、対応が遅れます。

事前に、誰が判断し、誰がクラウド事業者へ問い合わせ、誰がログを確認し、誰が顧客や取引先へ説明するのかを決めます。事故時の連絡窓口、SLA、通知条件も確認します。

クラウドサービス提供者に確認すべき項目

責任共有モデルでは、利用者側の対策だけでなく、提供者がどの範囲を担うかを確認します。サービス選定時には、価格や機能だけでなく、セキュリティ機能と運用情報も確認対象にします。

責任共有モデルで見落としやすい領域

SaaSの共有設定と外部連携

SaaSでは、提供者がアプリケーション運用を担うため、利用者側の責任が軽く見られがちです。しかし、外部共有リンク、ゲストユーザー、API連携、OAuth連携、管理者権限、退職者アカウントは利用者側の管理対象です。

ファイル共有、チャット、CRM、プロジェクト管理ツールなどでは、部門が独自に設定を変更することがあります。管理者は、外部共有の可否、ゲスト権限、連携アプリ、監査ログを定期的に確認します。

バックアップと復旧責任

クラウドサービスが高可用性を提供していても、利用者の誤削除や不正操作から常に自動復旧できるとは限りません。SaaSでも、削除済みデータの保持期間や復元範囲はサービスごとに異なります。

重要データについては、提供者のバックアップ機能、利用者側のエクスポート、別環境への保管、復旧テストを確認します。バックアップが存在していても、復旧手順を試していなければ、事故時に使えない可能性があります。

委託先・外部ユーザーの管理

外部委託先、協力会社、取引先、派遣社員にクラウドサービスのアカウントを付与する場合、契約終了やプロジェクト終了後の削除漏れが発生しやすくなります。

外部ユーザーには期限付き権限を設定し、定期的に棚卸しします。共有フォルダ、チャットスペース、SaaSのゲスト権限、外部共有リンクを確認し、不要になったアクセスは削除します。

クラウドとオンプレミスの接続点

クラウドと社内ネットワークをVPN、専用線、ID連携、API連携で接続している場合、その接続点が攻撃経路になることがあります。クラウド側とオンプレミス側で管理担当が分かれていると、設定やログの確認が分断されます。

接続点では、認証方式、接続元制限、ルーティング、ファイアウォール、証明書、ログ、障害時の切り戻し手順を確認します。ゼロトラストの考え方を取り入れ、接続元が社内であっても権限と端末状態を確認する設計が有効です。

責任共有モデルを運用に反映する手順

利用中のクラウドサービスを棚卸しする

最初に、IaaS、PaaS、SaaS、部門契約サービス、無料利用サービスを一覧化します。サービス名、契約部門、管理者、利用者数、保存データ、外部共有、ログ機能、認証方式を確認します。

棚卸しを行うと、情報システム部門が把握していないSaaSや、退職者が管理者のまま残っているサービスが見つかることがあります。責任共有モデルは、把握できているサービスにしか適用できません。

責任範囲を表にする

サービスごとに、提供者が担う範囲と利用者が担う範囲を表にします。対象は、データ、ID、権限、ネットワーク、OS、ミドルウェア、アプリケーション、ログ、バックアップ、障害対応、問い合わせ窓口です。

責任範囲を表にすると、利用者側の未対応項目が見えます。例えば、ログ機能はあるが有効化していない、バックアップ機能はあるが復旧テストをしていない、外部共有を許可しているが棚卸ししていない、といった課題を確認できます。

利用者側の管理項目をルール化する

責任範囲を整理したら、利用者側の管理項目をルールにします。アカウント発行、権限変更、特権ID利用、外部共有、ログ確認、バックアップ、退職者対応、例外申請を手順化します。

ルールは細かすぎると守られません。優先度が高い項目から始め、管理者権限、外部共有、退職者アカウント、監査ログ、重要データのバックアップを先に整えます。

定期的にレビューする

クラウドサービスは、機能追加、組織変更、部門利用、外部連携によって状態が変わります。一度確認して終わりではなく、定期的にレビューします。

レビューでは、アカウント、権限、外部共有、ログ取得、バックアップ、SLA、契約、管理者、委託先アクセスを確認します。重大な設定変更や新規サービス導入時にも、責任範囲を再確認します。

まとめ

クラウドサービスの責任共有モデルは、クラウド提供者と利用者がセキュリティと運用の責任範囲を分担する考え方です。提供者はクラウド基盤の安全性と安定性を担い、利用者はデータ、ID、権限、設定、ログ、利用ルールを管理します。

責任範囲は、IaaS、PaaS、SaaSで変わります。IaaSではOSやミドルウェアまで利用者が管理する範囲が広く、SaaSではアプリケーション運用を提供者が担う一方、ユーザー管理、権限設定、外部共有、データ運用は利用者側に残ります。

責任共有モデルを機能させるには、利用中のクラウドサービスを棚卸しし、サービスごとの責任範囲を表にし、アクセス管理、設定棚卸し、ログ取得、バックアップ、退職者対応を手順化します。クラウドの安全性は、提供者の基盤対策と利用者側の運用がそろって初めて確保できます。

FAQ