RLSを実戦投入するための設計判断
全体像: リクエストから RLS ポリシー評価まで Acsim では、1つの HTTP リクエストが RLS で保護されたデータにアクセスするまでに、次の流れを辿ります。 �7 �� テナントコンテキスト（所属テナントやロールなどの情報）は「Middleware → Hono Context → UseCase → PostgreSQL」の順に流れます。Middleware がテナントコンテキストを取得・検証して Hono Context に格納し、UseCase がそれを取り出して PostgreSQL のトランザクション内でセッション変数に注入し、RLS ポリシーが評価します。 ここからは、この構成に至る過程で直面した設計判断を3つ掘り下げます。 設計判断 1: テナントコンテキストをどう取得するか RLS にテナントコンテキストを渡すには、リクエストからテナントコンテキストを取得して
マルチテナントSaaSのテナント分離をRow-Level Securityに移行した - Sansan Tech Blog
こんにちは、クラウド請求書受領サービス「Bill One」の開発に携わっているソフトウェアエンジニアの加藤です。Bill OneはB2BのマルチテナントSaaSであり、データベースとして Cloud SQL 上のPostgreSQLを利用しています。従来はマルチテナントのデータを分離するために、テナントごとにPostgreSQLのスキーマを分けていましたが、2020年12月にRow-Level Securty（行レベルセキュリティ。以降RLSと表記）による分離に移行しました。 本稿では、移行の背景とRLS組み込みにあたって考慮したポイントをご紹介します。 マルチテナントSaaSのテナント分離 マルチテナントSaaSにおけるテナント分離方法はいくつか知られており、大きく次の3つに分けられます。 アプリケーションの実行環境ごと完全に分離する データベースのみをインスタンスやスキーマで分離する
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
