Supabaseが検索可能な暗号化を発表

Supabase向けのCipherStash統合が利用可能になりました。CipherStashは、Postgres上で構築されたアプリケーション向けのデータレベルアクセス制御（DLAC）プラットフォームです。 DLACは、通常行またはテーブルレベルで機能する従来のアクセス制御を、個々の暗号化された値まで拡張します。これにより、クエリレイヤーではなく復号化時にポリシーが強制されます。 CipherStashを使用すると、チームはアプリケーションレイヤーで機密フィールドを値ごとに一意のキーで暗号化し、データを復号化せずに暗号化されたデータに対して検索や結合を実行できます。また、CipherStashのゼロ知識キー管理サービスであるZeroKMSを通じて、キーを自身の管理下に置くことができます。キーが管理下を離れることはないため、CipherStashもSupabaseもプレーンテキストデータにアクセスすることはできません。 Supabase統合により、チームは暗号化されたSupabase SDKラッパーを使用して、スキーマを変更することなく、あらゆるSupabaseプロジェクトにフィールドレベル暗号化を追加できます。セットアップは1つのCLIコマンドで行えます：npx stash init --supabase。 規制対象ワークロードにとってなぜ重要か 規制対象データを扱うほとんどのチームは、2つの悪い選択肢のいずれかを選択することになります。 従来のフィールドレベル暗号化を使用する：Postgresにとっては、暗号化された値はランダムなバイトです。WHERE email = ? は何も一致せず、インデックスは機能せず、結合は失敗します。検索する唯一の方法は、すべての行を取得し、アプリケーションで復号化し、メモリ内でフィルタリングすることです。チームは高価な回避策を構築するか、機能を完全にドロップすることになります。 暗号化をスキップする：アプリケーションは高速ですが、侵害が発生した場合、プレーンテキストの機密データが監査人が最初に尋ねることになります。 CipherStashは3番目の選択肢を提供します。 DLACはアクセス制御を個々の暗号化された値まで拡張します。暗号化は、データがデータベースに到達する前にアプリケーション内で発生します。各値は、暗号文と検索可能な暗号化メタデータ（SEM）を含む単一のJSONペイロードとして保存されます。これはPostgresがフィルタリング、ソート、結合を行うには十分ですが、元の値を復元するには不十分です。 クエリは入力時にSEMに変換され、Postgresは保存されたSEMと照合し、アプリケーションが復号化を許可されている暗号文のみが返されます。各暗号化された値には、誰がどのような条件でそれを読み取れるかを示すポリシーが付随しています。そのポリシーは、クエリレイヤーではなく復号化時に強制されます。 HIPAA、GDPR、またはSOC 2の対象となるチームは、Postgres、Supabase、および検索機能を維持しながら、コンプライアンスレビュー期間を短縮し、侵害の表面積を小さくすることができます。 統合の仕組み CipherStash Stackを使用して、既存のTypeScriptアプリケーションにDLACを追加します。これはSupabase.js、Drizzle、およびPrismaとネイティブに連携します。 暗号化と復号化は、アプリケーション内で透過的に行われます。暗号化対象としてマークした列はSDKを通過し、それ以外のすべてはこれまで通り動作します：WHERE句、あいまいテキストマッチング、ORDER BY、さらにはJSONクエリも暗号化されたデータに対して引き続き機能します。 暗号化キーはZeroKMSを通じて管理されます。各暗号化された値には独自のキーがあり、オンデマンドで派生します。キーは、FedRAMPやIL4などのフレームワークを含むデータ居住性要件を満たすために、複数のリージョンに分割できます。 SDKが適さない場合（分析ジョブ、管理ツール、他の言語のバックグラウンドワーカー、または直接データベースアクセスが必要な場合など）は、CipherStash Proxyが安全なエスケープハッチを提供します。 プロキシはPostgresワイヤプロトコルを話し、暗号化と復号化を透過的に処理するため、既存のツールやSQLクライアントはコード変更なしで暗号化されたデータを使用できます。 開始方法 → CipherStashをSupabaseプロジェクトに追加する