「クラウドがやってくれる」が終わる地点

一言でいうと

クラウド事業者はインフラのセキュリティ(security of the cloud)に責任を持ち、私たちはその上に載せたもののセキュリティ(security in the cloud)に責任を持ちます。事故の大半は、この境界を誤解した場所で起きます。

なぜ必要なのか

ニュースに出てくる「AWSで顧客データが流出」という事故を開いてみると、ほとんどすべてがS3バケットを公開にしていたものです。AWSが破られたわけではありません。そのように設定したのは顧客です。

逆に、ハイパーバイザーの脆弱性やデータセンターへの物理的な侵入は、私たちが手を出せない領域で、それは事業者の責任です。

境界を知らないと、2つの方向で間違えます。事業者がやってくれることを私たちが重複してやってしまうか(無駄)、私たちがやるべきことを事業者がやってくれると信じてしまうか(事故)です。

どう動くのか

境界はサービスモデルによって動く

        IaaS(EC2)      PaaS(RDS)       SaaS(Workspaces)
데이터        고객           고객              고객      ← 항상 고객
접근 권한     고객           고객              고객      ← 항상 고객
애플리케이션  고객           고객            사업자
런타임        고객           사업자          사업자
OS 패치       고객           사업자          사업자
하이퍼바이저  사업자         사업자          사업자
물리          사업자         사업자          사업자

上の2行(データとアクセス権限)は、どのモデルでも顧客の担当です。「マネージドだから安全」が成り立たない理由が、ここにあります。RDSを使っていても、パスワードをadmin/adminにしていたら、それは私たちの事故です。

よく勘違いする5つのこと

思い込み	実際
「マネージドだからバックアップも勝手にやってくれる」	自動バックアップはたいてい有効にする必要があり、保持期間も私たちが決めます
「暗号化は標準」	保存時の暗号化はオプションであることが多く、通信の暗号化はアプリが強制する必要があります
「パッチは事業者がやる」	IaaSのOSパッチは顧客の担当です。マネージドでも、メンテナンスウィンドウは私たちが決めます
「削除すれば消える」	スナップショット・レプリカ・ログに残ります。バックアップの保持が、そのまま削除の遅れになります
「可用性99.99%を保証」	SLAは返金の基準であって、無障害の約束ではありません

最後の行が特に重要です。SLA 99.99%は、「年間約52分までは正常な範囲で、超えたら料金の一部をクレジットで返す」という契約です。私たちのサービスがその52分に耐えられるかは、私たちが設計しなければなりません。

だから私たちが必ずやること

アクセス権限: 誰が何をできるか。次のコースのテーマです。
データの分類と暗号化: 何が機微かを決め、それから暗号化します。
バックアップと復旧のリハーサル: バックアップを有効にすることと、復旧できることは別です。
設定の監視: 公開されたバケット・開いたセキュリティグループを自動で見つけ出します。
ログの保存: 事故が起きたときに調べる材料です。事業者は残してくれません。

サービスの種類ごとに境界が違う

「責任共有」は1行ですが、実際の境界はサービスごとに変わります。

	自分がやること	提供者がやること
IaaS(EC2)	OSパッチ、ファイアウォール、アプリケーション、データ	ハイパーバイザー、物理セキュリティ、ネットワーク
PaaS(RDS)	スキーマ、アカウント、パラメーター、バックアップポリシー	OS・エンジンのパッチ、ハードウェア
SaaS(S3)	権限、暗号化の選択、ライフサイクル	それ以外のすべて
サーバーレス(Lambda)	コード、依存関係、権限	ランタイム、スケーリング、パッチ

上に行くほど自分の分担は減りますが、データと権限は、どの層でも自分の分担です。この2つが、実際の事故の大半です。

実際に起きる事故の順位

順位	原因	誰の責任か
1	誤った権限設定(公開バケット、過剰なIAM)	自分
2	資格情報の流出(gitコミット、ログ)	自分
3	パッチを当てていないアプリケーションの依存関係	自分
4	バックアップなし・復旧未検証	自分
5	提供者の障害	提供者(それでも影響は自分が受ける)

クラウド提供者の欠陥でデータが漏れることは、まれです。ほとんどは設定です。そのため「クラウドだから安全」という文は危険です。安全になるのは、自分がやっていなかったことの一部にすぎず、新しく生まれること(権限設計、資格情報の管理)のほうが多いのです。

順位5にも備える

提供者の責任だからといって、手を離すことはできません。障害が起きると、ユーザーは私たちに抗議します。

マルチAZは基本。単一AZ構成は、そのAZが落ちると一緒に落ちます。
リージョン障害は計画でしか対処できません。マルチリージョンは高くつきます。RTOを決め、それに合ったレベルを選びます。「数時間以内に別のリージョンで復旧」も有効な答えです。
依存するマネージドサービスのSLAを掛け合わせます。DB 99.95%、キュー99.9%、ストレージ99.99%を直列で使うと、全体は99.84%です。月70分です。

最後の行が設計に影響します。可用性を上げるには、直列の依存を減らすことのほうが、個々の要素を良くするより効果が大きいのです。

現場での姿

監査で「暗号化の有無」を聞かれたのに、誰も答えを知りませんでした。分類がなかったのです。
障害のあと、SLAを根拠に補償を求めましたが、クレジット数ドルがすべてでした。
マネージドDBを使っていたのに復旧できませんでした。自動バックアップがオフになっていたのです。

次に見ること

サービスモデル(IaaS/PaaS/SaaS)が、この境界を具体的にどう動かすかを見ます。