- 物理機リージョン/AZ今ここ
- ハイパーバイザVM exit で捕まえる今ここ
- VMゲストOS今ここ
- コンテナnamespace / cgroup
- プロセスアプリ / DB
借りる層が上がるほど、線の下が提供者に移る。線の上は常に自分。
まず結論
借りる層が上がるほど、線の下(物理・ハイパーバイザ・OS)は提供者に移ります。しかし線の上——データ、設定、暗号化を有効にするか、誰に何を許すか——は、どこまで上がっても自分に残ります。
そして線の位置はサービスごとに違います。AWS の公式文書は利用者の責任範囲を "varies based on many factors, including the AWS services and Regions they choose" と書いています。「マネージドだから全部おまかせ」は、その文書自身が否定しています。
マネージドなデータベースを使えば、バックアップと暗号化はどちらも提供者がやってくれるでしょうか。
当てることが目的ではありません。外した予測ほど記憶に残るので、直感で選んでください。
借りる層が上がると、線が上がる
前回、借りた機械には物理的な置き場所があることを見ました。今回はどこからが自分の担当かを扱います。
一次ソースは NIST SP 800-145 です。3つのサービスモデルの定義文には毎回ほぼ同じ形の一文が現れます。「利用者は基盤を管理も制御もしない。ただし◯◯は制御する」。この◯◯が層ごとに違うだけです。
- IaaS —
The consumer does not manage or control the underlying cloud infrastructure but has control over operating systems, storage, and deployed applications - PaaS —
The consumer does not manage or control the underlying cloud infrastructure including network, servers, operating systems, or storage, but has control over the deployed applications - SaaS —
The consumer does not manage or control the underlying cloud infrastructure including network, servers, operating systems, storage, or even individual application capabilities, with the possible exception of limited user-specific application configuration settings
IaaS で握っていた OS が PaaS では相手側へ移り、PaaS で握っていたアプリ本体が SaaS では相手側へ移る。線が1段ずつ上がるのです。
それでも SaaS に limited user-specific application configuration settings が残ります。設定を選ぶ行為は、どの層でも利用者側にあります。
- ・NIST の脚注では cloud infrastructure は物理層と抽象化層から成る
- ・線が上がっても、データ・設定・権限付与は上に残る
前置詞1つで分けている
公式文書はこの分け方を前置詞で表します。
As shown in the chart below, this differentiation of responsibility is commonly referred to as Security “of” the Cloud versus Security “in” the Cloud.
クラウドのセキュリティは提供者側です。
AWS is responsible for protecting the infrastructure that runs all of the services offered in the AWS Cloud. This infrastructure is composed of the hardware, software, networking, and facilities that run AWS Cloud services.
クラウド内のセキュリティは利用者側で、範囲は固定されません。
Customer responsibility will be determined by the AWS Cloud services that a customer selects. This determines the amount of configuration work the customer must perform as part of their security responsibilities.
同じページは、抽象化されたサービスでも利用者側に残るものを挙げます。
Customers are responsible for managing their data (including encryption options), classifying their assets, and using IAM tools to apply the appropriate permissions.
これは S3 と DynamoDB を例にした文脈の一文で、特定のデータベースサービスの記述ではありません。しかし列挙された3つ——データの管理(暗号化の選択を含む)・資産の分類・権限の付与——は、基盤も OS もプラットフォームも提供者が運用する状況で残った項目です。
NIST SP 800-145 の IaaS の定義で、利用者が制御するとされるのはどれですか。
線はサービスごとに違う、と文書自身が書いている
ここが実務で一番外しやすい点です。責任共有モデルは1枚の概念図で共有されますが、その図を載せる文書自身が、線は固定されないと明記します。
Customer responsibility varies based on many factors, including the AWS services and Regions they choose, the integration of those services into their IT environment, and the laws and regulations applicable to their organization and workload.
「責任範囲はこの図のとおり」は、図が正しくてもそのサービスは何も確認していない状態になりえます。
マネージドなデータベースの表を、実際に開く
マネージドなリレーショナルDBの公式ガイドには、オンプレミス・仮想マシン・マネージドの3列で担当を並べた表があります。
Feature On-premises Amazon EC2 Amazon RDSApplication optimization Customer Customer CustomerScaling Customer Customer AWSHigh availability Customer Customer AWSDatabase backups Customer Customer AWSDatabase software patching Customer Customer AWSDatabase software install Customer Customer AWSOperating system (OS) patching Customer Customer AWSOS installation Customer Customer AWSServer maintenance Customer AWS AWSHardware lifecycle Customer AWS AWSPower, network, and cooling Customer AWS AWS
読み方を2行に絞ります。
1行目(Application optimization)は3列すべて Customer です。 どこまで借りても移らない唯一の行で、同ページはクエリチューニングと呼びます。
You are responsible for query tuning, which is the process of adjusting SQL queries to improve performance. … Monitoring and tuning are highly individualized processes that you own for your RDS databases.
Database backups の行はマネージドの列で AWS です。 同ページ冒頭も Amazon RDS manages backups, software patching, automatic failure detection, and recovery. とあります。
「うちはマネージド中心なので、責任共有モデルは1枚の表で説明できます」という言い方は妥当ですか。
TLS終端の位置(第33週)
暗号化された通信はどこかで必ず復号され、その場所が終端点です。終端をロードバランサに置けば、そこから先は復号済みのデータが流れます。RFC が保証するのは終端までで、内側は規格の外側の設計判断です。
終端をLBに置く クライアント === TLS ===> LB ---平文---> アプリ保証される区間 終端までの区間だけ内側の扱い RFC の外側の設計判断
責任共有の線(今回)
基盤は提供者、その上に置いたものは自分。線の位置は選ぶサービスで変わると公式文書も明記します。線より下に自分で対策を置くことはできず、線より上を提供者が代わりに決めてもくれません。
IaaS を選ぶ OS のパッチは自分の担当マネージドDBを選ぶ OS と DB のパッチは提供者の列どちらでも変わらない データ・設定・権限付与は自分の側
TLS終端の位置と、責任共有の線。片方は暗号、片方は契約の話です。共通する構造は何でしょうか。
どちらも「守る手段を選ぶ」より先に決めていることがあります。
この章のまとめ
- NIST SP 800-145 の3モデルは同じ形の一文で書かれる。IaaS は OS 以上、PaaS は配備したアプリ以上、SaaS は限定的な設定のみが利用者の制御下で、SaaS にも
limited user-specific application configuration settingsが残る。 - 公式文書は of と in で分ける。of は基盤(hardware, software, networking, facilities)、in は「選ぶサービスで決まる」。
- 概念図で分かるのは分類の仕方まで。分かれ目はそのサービスの文書にしかない。文書自身が
varies based on many factorsと書いている。 - マネージドDBの比較表では OS/DB パッチ・バックアップ・スケーリングが提供者の列。3列すべて利用者なのは Application optimization だけ。
- 暗号化の選択と権限付与を利用者側に置く根拠は、比較表ではなく責任共有モデルのページにある。出典を混ぜると、表に無い行を表の権威で語ることになる。
- 線は文書で決まり、技術で動かせない。順序は読み取る → その上で守る。
問題で詰めるなら、クイズ群『開発とツール』の「AWSの基礎」「クラウドとコンテナ」、『セキュリティ:クラウド・インフラ・ネットワーク』の「クラウドセキュリティとDevSecOps」が対応します。マネージドサービスの中身は AWSサービスの内部原理 コースの『マネージドサービスの正体 — 中身は普通のコンピュータ』へ。次回は、この線の上で自分が決める設定——増やすか減らすかの判断——を見ます。
自分の現場で確かめる
読んだだけでは身につきません。手元の環境で実際に見てみてください。
理解度チェック
読んだ直後は「分かった」と感じやすいものです。実際に解いて確かめてください。
AWS の "Security of the Cloud" と "Security in the Cloud" の区別として、公式文書に沿うのはどれですか。
用語集(4語)
- 責任共有モデル
- 基盤を提供する側と、その上に自分のものを置く側で担当範囲を分ける取り決め。AWS の文書は Security “of” the Cloud と Security “in” the Cloud で区別する。
- IaaS / PaaS / SaaS
- NIST SP 800-145 が定義する3つのサービスモデル。IaaS は OS 以上、PaaS は配備したアプリ以上、SaaS は限定的な利用者固有の設定のみが利用者の制御下。
- Shared Controls
- 同じ項目を提供者と利用者が別の層で分担するもの。公式の例はパッチ管理と構成管理。基盤側は提供者、ゲストOSとアプリ側は利用者。
- 抽象化されたサービス
- 公式文書が abstracted services と呼ぶもの。基盤・OS・プラットフォームまで提供者が運用し、利用者はエンドポイント経由でデータを出し入れする。