動画 https://www.youtube.com/watch?v=fuDZq-EspNA

テナント分離は、SaaS アーキテクチャーの最も基本的な側面の 1 つです。すべての SaaS プロバイダーは、提供するテナントリソースの分離と安全を確保する手段について考察する必要があります。その際の課題となるのは、各リソースタイプ（コンピューティング、ストレージ、その他）で、異なる分離アプローチが要求されるということです。このセッションでは、分離オプションの全体像を概観できる、明確なロードマップを作成します。さまざまなマルチテナントモデルと AWS のサービスに広がる分離を達成するための、戦略についてもハイライトしていきます。SaaS ソリューションに分離を導入する際のアプローチに影響を与え得る考慮事項についての、包括的な理解を得ることを目標にします。

descriptionより

Authentication and authorization ≠ isolation

認証認可とは異なる新たなテナント分離のレイヤを追加することにより、各テナントのリソースを分離する

Isolation strategy drivers

Tiering Strategy: 複数の方法でテナント分離する
Noisy neighbor: あるテナントのアクセス(DoS等?) を他のテナントに影響させない
Compliance requirements: 金融とかで各種レギュレーションに従うため、テナント分離の方法に制約がかかるかもしれない。設計に影響するのでよく確認してね
Legacy architecture: 現在の実装も考慮してね

Multiple flavors of isolation

Silo model: リソース全部分離する。VPCとかも
Pool model: リソースを共有する。ポリシーで分離する

メモ：なるほどなあ。顧客によって要求が違うから、サービスによっては両方の方式でテナント分離を提供できないといけないと
メモ：両方の方式で提供はかなりハードになるだろうな

Silo isolation strategies

Silo modelの戦略。それぞれメリデメあるが、VPCレベルが一番common

統合すべきところと分離すべきところ

Pool-based isolation adds a new wrinkle

ベストプラクティスとは言えない
自然には全く分離されてない。コンプライアンス的にもよくない。分離されるかどうか開発者に委ねられる。

認証レイヤや各リソースで分離ポリシーを共有することによりテナントを分離する（いったん概念のみ）

Runtime scoped access with IAM

実装の概要（ビデオ 19:47 あたりから）

動的ポリシー生成

現実的には、顧客は自分のデータは自分が持っていると思っている。SiloだろうとPoolだろうとどんなテナント分離戦略を取ったとしても、このシステムは他のテナントにデータが保存されたり、他のテナントのデータが見えたりすることがないということをことを保証しないといけない。

API-enfoced access

API GatewayにLambdaカスタム認証を入れることでテナントポリシーを付与

Silo compute isolation patterns

Silo modelでやるにしてもIAMで制御すべき

Using roles for silo compute isolation

コンピュートリソースの分離

コンテナの場合も同様

ポリシーをリソースをまたいで連動 (cascading) させることでテナント分離の管理がシンプルになる

Pool requires a broader scope

Poolの場合、IAMポリシーはSiloの場合よりも許可の範囲が広くなる

Pool compute patterns for Amazon EC2 and AWS Lambda

EC2とLambdaでpoolするパターン

CognitoからEC2やLambdaを実行するIAMポリシー取ってくる（多くのテナントで利用できるよう幅広なポリシーが設定されてる）
分離コンテキストの外にあるRDSやDynamoDBといったリソースにアクセスする時は別のアクセスコンテキストが適用される

コンテナだと違った分離の方法になる

テナントそれぞれにnamespaceをつくる

Storage isolation patterns

ストレージ（DB）の分離はもっとシンプル

分離戦略がパフォーマンスやスケーリングのためのpartitioning戦略に影響するので注意

Pool isolation with Amazon DynamoDB

DynamoDBでpool分離するときのIAMポリシー

Pool with RLS and Amazon Aurora PostgreSQL

Aurora PostgreSQLでpool分離するときのポリシー

Isolation with Amazon S3

S3の分離はIAM tag policyで実現できる

その他のストレージはそれぞれ色々方法あるので試してみてね

Application-enforced isolation (conceptual model) / Applicationによる分離の概念モデル

IAMを使わない場合の分離の代替手段
リソースへのアクセスポリシーの適用をアプリケーションで強制する
JavaやNode.jsで実装したり、ツールやライブラリ、フレームワークなどを用いて実現する

Weighing your options / 分離方法の選び方

Siloは顧客の厳しい要件にも耐えられるしツールも色々あるが、管理コストや費用が増える
ポリシーによる分離はSiloよりも細かい単位での分離ができ運用も柔軟になるが、顧客の要望に応えられなかったり、技術の発展に依存したり、複数の技術を組み合わせたりと実装が大変
サービスやリソースごとに分離方法を変えるハイブリッドもあるよね

How do we know ouri isolation model is working? / テナント分離のテスト（検証）について　

6ヶ月かけて分離のテストのシナリオとtesting framework作った（マジか）
テナント1のポリシーでアクセスし、テナント2のコンテキストを注入する（メモ：SQLならwhere文に tenant_id = 2 等を仕込む感じなのかな）

まとめ

所感

確かに、厳密にデータを分離するよう顧客からの強い要求があった場合、Siloモデルを取らざるを得ないのかな
- 運用がハードすぎるので、非常に高額なエンタープライズプランとかでないと対応するのは難しそう
SOCとか取ってデータ保護の安全性が認証されてる場合でも、Siloモデルによるデータ分離が求められることあるんだろうか？
PoolでSQLのWhere句だけによって分離されてる場合でも、PostgreSQLのRLS (Row Level Security) やMySQLのViewテーブル、S3のタグベースでのアクセスポリシーなど、着手しやすいテナント分離の方法は早期に実施しておいた方が良さそう
- 事故が起きてから信頼を取り戻すのは難しい