データベースによって強制される分離
テナントデータを保持するすべてのテーブルにはtenant_id があり、PostgreSQL の行レベルセキュリティ (RLS) によって保護されています。
- テーブルでは RLS が有効化かつ強制されている (
FORCE ROW LEVEL SECURITY) ため、ポリシーはすべてのロールに適用されます。それを回避する特権的な経路はありません。 - 単一のポリシーが読み取りと書き込みの両方を管理します。行は、その
tenant_idが現在のリクエストのテナントと一致する場合にのみ表示 (USING) および書き込み (WITH CHECK) が可能です。
境界はデータベースに存在するため、テナントによるフィルタリングを忘れたクエリは、別のテナントから何も返しません。エンジンは、アクティブなテナント以外の行の表示や変更を拒否します。
テナントコンテキストはすべてのリクエストとともに伝わる
- テナントは、ミドルウェアでリクエストのサブドメインから解決されます。解決できない場合、リクエストはハンドラーに到達する前に拒否されます。
- データベーストランザクションごとに、Iru はテナント (実行ユーザーと相関/トレース ID とともに) をトランザクションスコープの設定 (
SET LOCAL) として設定します。トランザクションにスコープされているため、プールされた接続を再利用する次のリクエストに漏れることはありません。 - RLS ポリシーはまさにその設定を読み取るため、セキュリティ境界はアプリケーションが設定したのと同じ値であり、すべての接続でトランザクション的に確立されます。
最小権限により監査履歴は書き換えられない
アプリケーションが実行されるデータベースロールはライブデータの読み取りと書き込みができますが、監査スキーマには読み取りアクセスのみを保持します。万一アプリケーションの SQL が悪用されたとしても、監査履歴を変更または削除する権限はありません。証跡はアプリケーションロジックとは独立して、権限レイヤーで保護されています。 参照整合性もテナントスコープです。外部キーは複合 (tenant_id + id) であるため、レコードは同じテナント内の別のレコードのみを参照できます。
すべての変更はジャーナルに記録される (追記専用)
Iru は、テナントデータへの変更の完全で改ざん検知可能な履歴を保持します。取得される内容
取得される内容
すべての変更可能なテーブルには、挿入、更新、削除時にデータベーストリガーによって書き込まれるミラーの監査 (ジャーナル) テーブルがあります。各エントリには、何が起こったか (アクション)、誰が (実行したデータベースプリンシパルと認証されたユーザーの両方)、いつ、発生元のリクエストに結び付ける相関/トレース ID、および行の変更前後の完全な状態が記録されます。
追記専用である理由
追記専用である理由
証跡は 3 つの独立した方法で保護されています。トリガーはジャーナル行を挿入するだけであること、アプリケーションのデータベースロールは監査スキーマに読み取り専用アクセスを持つこと、およびトリガーは定義者権限で実行されることです。アプリケーションが監査レコードを変更または消去する経路はありません。
黙って乖離することはない
黙って乖離することはない
常設の整合性チェックが、すべてのライブテーブルの列を監査テーブルと比較し、列が欠落している場合は失敗するため、新しいフィールドが監査証跡から密かに漏れることはありません。スキーママイグレーション自体もバージョン管理され、チェックサムで検証され、ジャーナルに記録されます。
機密フィールドには追加のレイヤー
分離に加えて、特に機密性の高い値は、保存前にフィールドレベルで AES-256-GCM (認証付き暗号化) で暗号化され、アプリケーションが読み取るときにのみ復号されます。暗号化キーは、コードやデータベースからではなく、マネージドシークレットストアから実行時に提供されます。全体像との関係
分離はリージョンのデータレジデンシーと連携して機能します。各リージョンには独自のデータベースがあり、テナントのクエリはそのリージョンのデータベースに対してのみ実行されます (プラットフォームアーキテクチャを参照)。そのデータベース内では、RLS が各テナントを分離します。プラットフォームアーキテクチャ
この分離が実行されるリージョン、プレーン、インフラストラクチャ。
認証アーキテクチャ
サインインと API リクエストをフィッシング耐性と改ざん防止を備えたものにする方法。
アクティビティログ
管理者が確認できるよう表示される監査証跡。
セキュリティとプライバシー
これらのメカニズムがもたらす保証。