クラウドの責任共有モデル|自社に残る運用と担当の決め方

クラウドの責任共有モデルは、クラウド事業者と利用者が、どの範囲を管理するかを整理する考え方です。サービスを利用しても、データの扱い、利用者の権限、設定の確認など、自社で決めて運用する事項は残ります。

導入時には「事業者が管理する範囲」を読むだけでなく、残る作業を社内の誰が担うのか、委託先へどこまで任せるのかまで確認しましょう。本記事は運用分担を整理するための解説です。契約上の責任や個別の障害についての法的判断を示すものではありません。

責任共有モデルは、管理範囲を確かめる出発点

AWSは、クラウドの基盤を保護する責任と、クラウド上で利用者が行う設定や管理を区別しています。また、利用者側の責任範囲は選択するサービスによって変わると説明しています。AWSの責任共有モデル

Microsoftも、IaaS・PaaS・SaaSで分担が変わることを説明し、このモデルを、設定・運用・監視を誰が行うかという管理上の整理と位置付けています。説明図だけで契約条件が変更されるわけではありません。Microsoftの責任共有モデル

「クラウドだから任せられる」という一括りの理解ではなく、使うサービスごとに管理対象を確認することが重要です。同じシステムでも、仮想サーバー、マネージドデータベース、業務用SaaSを組み合わせていれば、対象ごとに確認する範囲が変わります。

IaaS・PaaS・SaaSで何が変わるか

Microsoftの説明をもとに、最初に確認する違いを簡潔に整理すると次のようになります。個別サービスの設定や契約を置き換える一覧ではありません。

区分 利用のイメージ 利用者が確認することの例
IaaS 仮想マシンなどの基盤を利用する ゲストOSやアプリケーションの管理、通信設定
PaaS OS等の管理を事業者に任せ、アプリケーションを動かす 自分で配置するコードや設定、アクセス制御
SaaS 用意されたアプリケーションを利用する 利用者、権限、データの扱い、サービス内の設定

例えばAWSは、Amazon EC2では利用者がゲストOSの更新やセキュリティパッチ、導入したアプリケーション、セキュリティグループを管理すると説明しています。一方、Amazon S3やDynamoDBのようなサービスでは基盤側をAWSが管理し、利用者はデータや権限等を管理します。AWSのサービス別説明

この違いを理解したうえで、実際に使うサービスの文書に戻ります。「PaaSなので更新作業は何もない」と決めず、自社のコード、依存ライブラリ、設定など、管理対象を個別に確認してください。

自社側の作業を、対象と確認方法に分ける

Microsoftは、クラウド利用時もデータ、アカウント、アクセス管理などの責任が利用者に残ると説明しています。利用者が保持する責任

自社の運用へ落とす際は、抽象的な「セキュリティ担当」という欄だけではなく、確認する対象と結果を残す方法を決めます。次は整理のための例です。

作業 対象を具体化する例 残す記録の例
利用者の追加・削除 社員、委託先、共有アカウントの扱い 申請、承認、変更結果
権限の確認 誰がどのデータを閲覧・変更できるか 確認日、対象、変更要否
設定の変更 通信経路、公開範囲、サービス設定 変更目的、確認者、適用結果
データの管理 保存対象、分類、保持、削除 管理方針、設定、確認結果
障害時の連絡 社内窓口と事業者への問い合わせ 連絡経路、必要な契約情報

表の項目がすべてのサービスで同じ方法になるわけではありません。設定できない項目は、事業者の提供内容や確認資料を記録します。設定可能なのに担当が決まっていない項目は、未担当として残します。

運用を委託する場合も、判断と実施を分けて決める

利用者側の作業を運用会社へ依頼する場合は、クラウド事業者との分担に加え、自社と委託先の分担を整理します。以下はそのための記入例で、契約条件のひな型ではありません。

作業 実施する人 判断・確認する人
アカウント削除 委託先が申請に基づき操作 自社が対象者と実施時期を確認
OS更新 委託先が検証と適用を担当 自社が業務停止の条件を確認
バックアップ確認 委託先が取得結果を確認 自社と委託先で復元対象・合格条件を確認
障害通知 委託先が通知を受けて一次確認 自社が業務影響と連絡範囲を判断

例えば「監視を委託する」という合意でも、通知を受け取るだけなのか、原因調査や復旧操作まで含むのかで、実際の作業は異なります。受付時間、連絡先、不在時の連絡方法、実行できる操作、追加費用の条件を確認します。

委託先が行う作業と、自社が判断する事項を対応させ、資料や操作結果をどこで確認できるかも決めておきましょう。

サービスや体制が変わったら担当表を見直す

責任共有の整理は、導入時の図を保存して終わりにせず、変更した対象に合わせて更新します。次のような変更は、担当と確認手順を見直すきっかけになります。

  • 仮想サーバーからマネージドサービスへ構成を変えた。
  • 新しいSaaSや外部連携を追加した。
  • 運用委託の範囲や受付時間を変えた。
  • 管理者の異動、退職、担当交代があった。

ここで提案した担当表は、運用の抜けを発見するためのものです。セキュリティ対策が十分であることや、契約上の責任を自動的に確定するものではありません。

まずは利用サービスを一覧にし、公式文書で事業者側と利用者側の範囲を確認してください。対象自体が整理できていない場合は、システムと依存関係の確認項目が出発点になります。基盤の構成や運用分担の整理については、テクノヴァースのインフラ支援をご覧ください。

記事一覧へ戻る

ITの困りごとを、
まずはご相談ください。

何から手をつけるか決まっていない段階でも構いません。ご相談内容に応じて、担当者からご連絡します。

まずは相談する

採用へのご応募は採用エントリーからお願いします。