動画 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分離するときのポリシー
- RLSを有効にする
- メモ：MySQLにはRLS機能がないが、View機能を活用することで実現できる
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のタグベースでのアクセスポリシーなど、着手しやすいテナント分離の方法は早期に実施しておいた方が良さそう
- 事故が起きてから信頼を取り戻すのは難しい