AWS re:Invent 2019: SaaS Tenant Isolation Patterns（SaaS テナント分離パターン） (ARC372-P)

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

![スクリーンショット 2021-01-23 21.45.04.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2160/f2e70846-da74-7361-c577-61414198f9d8.png)


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

descriptionより

## Authentication and authorization ≠ isolation

認証認可とは異なる新たなテナント分離のレイヤを追加することにより、各テナントのリソースを分離する
![スクリーンショット 2021-01-23 11.08.51.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2160/8a554697-3435-4710-159a-4eae10152940.png)

## Isolation strategy drivers

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

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2160/c31bf0b6-3b0f-60f9-c2b6-e8d918e2e15e.png)

## Multiple flavors of isolation

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

![スクリーンショット 2021-01-23 11.19.35.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2160/fd2e7358-82f4-a880-2cfe-bccffdb495ae.png)

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

![image (1).png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2160/5f01fb71-5c61-9baf-c882-23352a1ada28.png)

## Silo isolation strategies

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

![スクリーンショット 2021-01-23 11.25.45.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2160/75e54716-cd7f-6e4c-09dc-cdc9cefb0d11.png)

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

![スクリーンショット 2021-01-23 11.26.59.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2160/0b606607-d73d-0677-918c-7c5dda7e6349.png)


## Pool-based isolation adds a new wrinkle

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

![スクリーンショット 2021-01-23 11.29.30.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2160/da61516b-c4ad-d8b6-35c2-f094485a1798.png)

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

![スクリーンショット 2021-01-23 11.33.09.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2160/b1358667-c13d-76b0-b250-167b7b9e82b6.png)

## Runtime scoped access with IAM

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

![スクリーンショット 2021-01-23 11.35.51.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2160/ce467efa-6fa4-03b1-b62d-f523d56987aa.png)

動的ポリシー生成

![スクリーンショット 2021-01-23 11.39.22.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2160/6e1deb21-1dba-b3dc-82d0-e1e06d799ccb.png)

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

![スクリーンショット 2021-01-23 11.40.38.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2160/1938ab22-52e3-d1ca-30f5-fe1594212600.png)

## API-enfoced access

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

![スクリーンショット 2021-01-23 11.46.26.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2160/ae7bcbac-0e3b-fdb0-1716-f2bf932fdc10.png)

## Silo compute isolation patterns

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

![スクリーンショット 2021-01-23 11.48.06.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2160/0757fad1-eb06-1855-fbea-4d07be815b6b.png)

## Using roles for silo compute isolation

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

![スクリーンショット 2021-01-23 11.50.25.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2160/f2248dc2-5609-c56d-8d61-a5e266caad51.png)

コンテナの場合も同様

![スクリーンショット 2021-01-23 11.51.16.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2160/e4bdf7ca-7fb1-9cdb-35b9-9a6b21c6bc81.png)

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

![スクリーンショット 2021-01-23 20.24.07.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2160/0f0f29e1-bb48-9e63-ea54-bb567009a3de.png)

## Pool requires a broader scope

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

![スクリーンショット 2021-01-23 20.28.44.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2160/01f7a058-9d71-5f66-8479-8ca5a02891d5.png)

## Pool compute patterns for Amazon EC2 and AWS Lambda

EC2とLambdaでpoolするパターン

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

![スクリーンショット 2021-01-23 20.40.23.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2160/b6da0b0d-de60-9e65-8972-1d43709ff893.png)

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

![スクリーンショット 2021-01-23 20.50.31.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2160/2aaafd82-0d34-5a4d-b6da-e266d617a898.png)

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

![スクリーンショット 2021-01-23 20.52.18.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2160/9aedd539-4f52-69f7-7b7d-a9891dac2a18.png)

## Storage isolation patterns

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

![スクリーンショット 2021-01-23 20.54.18.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2160/9e5a507b-0d41-3912-e14c-83b80d2a359e.png)

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

![スクリーンショット 2021-01-23 20.55.26.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2160/1cebf782-d8f8-a152-547e-e4b69425386a.png)

## Pool isolation with Amazon DynamoDB

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

![スクリーンショット 2021-01-23 20.59.58.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2160/72c46391-fcd5-a340-e440-dd378889d0dd.png)

## Pool with RLS and Amazon Aurora PostgreSQL

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

- RLSを有効にする
- メモ：MySQLにはRLS機能がないが、View機能を活用することで実現できる
  - https://stackoverflow.com/questions/5527129/mysql-how-to-do-row-level-security-like-oracles-virtual-private-database#:~:text=Mysql%20doesn't%20natively%20support,and%20not%20the%20underlying%20tables

![スクリーンショット 2021-01-23 21.02.03.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2160/dc5822ad-c0d9-c16b-f5d4-879547ac0fd8.png)

## Isolation with Amazon S3

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

![スクリーンショット 2021-01-23 21.07.33.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2160/e3b7b64c-b6c2-4034-aa0d-3c6e6efa50e5.png)

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

![スクリーンショット 2021-01-23 21.08.50.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2160/ad0ebaf8-55a4-5844-91a2-8a8767f81c00.png)

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

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

![スクリーンショット 2021-01-23 21.17.34.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2160/0613b6f8-049c-0020-4d23-b095e425387b.png)

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

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

![スクリーンショット 2021-01-23 21.28.43.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2160/9e14f9f7-3bb9-0f9f-3a20-1ac0d312442c.png)

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

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

![スクリーンショット 2021-01-23 21.39.17.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2160/5e2758eb-96fd-6d79-4090-f8722136c9ff.png)

## まとめ

![スクリーンショット 2021-01-23 21.44.02.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2160/a23a9ba7-2a25-f404-2e7b-45251cd8fecc.png)

## 所感

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