責任共有モデルの全体像を理解する

AWSが守る基盤と、利用者が設定・管理するデータやアプリを区別し、サービスを変えると責任範囲がどう変わるかを学びます。

この単元で学ぶこと

  • クラウド自体とクラウド内の保護を区別する
  • EC2・S3・RDS・Lambdaの管理範囲を比較する
  • 共有される統制と利用者に残る業務責任を説明する

本文解説

1. 二者で分担する 責任共有モデルではAWSと利用者が異なる範囲を担います。AWSはサービスを動かす物理設備、基盤のハードウェアやネットワーク等を保護します。利用者は選んだサービスでデータや設定、アプリを安全に扱います。単に両者が半分ずつ同じ作業をする意味ではありません。

2. 基盤側の保護 AWSのデータセンターへの入退室、施設の環境管理、物理ホスト等はAWS側です。利用者がEC2を使うために施設の扉を管理する必要はありません。一方、そのEC2へ誰がログインできるかは利用者側の設定に関係し、物理施設の入退室と分けて考えます。

3. EC2で残る管理 通常のEC2では利用者がゲストOSの更新、インストールしたアプリ、セキュリティグループ等を管理します。AWSがホスト側を管理することと、利用者のOSやアプリを全て更新することは違います。ホストOSとゲストOSという層を区別すると責任が明確になります。

4. 保存サービスを使う場合 S3等の抽象化されたサービスでは、利用者が保存基盤のOSへパッチを当てる作業は行いません。代わりに、どのデータを保存するか、機密性をどう分類するか、どの主体へ読取りや書込みを許すか等を管理します。基盤運用が減ってもデータ公開の責任は残ります。

5. RDSへの移行 DBをEC2で自主管理する場合とRDSを使う場合では、任せられる基盤管理の範囲が変わります。RDSでもDBへの接続許可、DB内の利用者やデータの扱い等を利用者が設定します。選んだサービスに合わせて責任を見直し、古い運用手順をそのまま移すだけにしません。

6. Lambdaにも利用者の作業がある Lambdaではサーバー基盤管理が抽象化されますが、関数コード、依存ライブラリ、権限、データの扱い等は利用者の責任です。ランタイム更新も方式で異なり、コンテナイメージ方式では公開された新ベースイメージで再構築し再配備する作業が利用者に残ります。

7. 同じ統制を異なる層で行う パッチ管理はAWSが基盤に行い、利用者は自分のゲストOSやアプリへ行う場合があります。教育もAWSはAWS従業員、利用者は自社従業員に行います。このように共通の統制名でも対象が違います。共有とは自分の担当を相手へ丸ごと任せることではありません。

8. コンプライアンスを判断する AWSの統制に関する証跡は、自社の評価を進める資料になります。しかし自社データの分類、権限、利用法、該当要件を評価する作業は残ります。サービスや地域を選び直した場合も責任の範囲を確認します。基盤側の認証だけを自社システム全体の適合証明とはみなしません。

図解

管理する層で担当を分ける
担当範囲はサービスによって変わるため、作業名だけでなく対象層を確認します。

重要ポイント

  • 基盤の保護と利用者のデータ・設定を分ける。
  • 選んだサービスで管理範囲が変わる。
  • 同じ統制名でも対象層が異なる。

間違えやすい点

  • ホストOSとゲストOSを混同する。
  • マネージド化をデータ権限管理の免除と考える。

用語解説

Security of the Cloud
AWSがクラウド基盤そのものを保護する責任。
Security in the Cloud
利用者がクラウド上のデータ・設定等を保護する責任。
ゲストOS
仮想サーバーの中で利用者が使うOS。
共有統制
AWSと利用者がそれぞれの範囲で実施する同種の統制。

関連教材

参考資料

教材データに登録された参考リンクです。リンク先の内容や更新日は提供元でご確認ください。

確認問題の出題・採点や学習履歴の保存にはログインが必要です。