CipherStash Stack によるデータレベル・アクセス制御の実装

従来のセキュリティモデルでは、アプリケーションへのアクセスはセッションの背後にいる人間のユーザーを中心としていました。しかし、ツールを連鎖させ、プロンプトを通じてデータを拡散させ、ログやトレースを横断して動作するAIエージェントの台頭により、この前提は崩れつつあります。エージェントがユーザーに代わって行動する場合、エージェントが侵害されたりプロンプト・インジェクションを受けたりすると、広範な権限を継承してしまい、重大なセキュリティリスクを生じさせることがよくあります。

CipherStash Stack は、データレベル・アクセス制御 (DLAC) を導入します。これは、セキュリティを境界や行レベルから、個々のデータ値へと移行させるパラダイムシフトです。機密データの一つひとつが独自の暗号化を持ち、復号の権利が特定のアイデンティティに紐付けられていることを保証することで、CipherStash は、データがどこへ移動しても保護が共に移動することを保証します。

CipherStash Stack の5つの柱

CipherStash Stack は、構成可能なビルディングブロックとして設計されており、チームが「ビッグバン」的な移行ではなく、一度に1つのフィールドずつ、段階的に DLAC を採用できるようにします。

1. 値レベルの暗号化

ディスクを保護する encryption-at-rest とは異なり、CipherStash は個々のフィールドに対して検索可能な暗号化を提供します。EQL を使用することで、Postgres は暗号文に対して直接、フィルタリング、ソート、結合を実行できます。これは、データが保存時や転送時だけでなく、使用時 も暗号化されたままであることを意味します。

2. ZeroKMS キー管理

すべての値に対して一意のデータキーを管理することは、通常、計算コストが高くなります。ZeroKMS は、AWS KMS をバックエンドとして使用する超高速なキーサービスとして機能することで、この問題を解決します。AWS KMS を直接呼び出すよりも最大 14 倍高速であると報告されており、アプリケーション側での複雑なキーキャッシュの必要性を排除します。

3. 透明な SQL プロキシ

コードの変更が不可能なレガシーアプリケーションや BI ツールの場合、CipherStash Proxy がアプリと Postgres の間に位置します。これは SQL ステートメントを透明に書き換え、入力時にパラメータを暗号化し、出力時に結果を復号することで、開発者が DLAC を維持しながらプレーンな SQL を使用できるようにします。

4. アイデンティティ紐付け型認証

CipherStash は OIDC プロバイダー (Auth0 など) と統合し、復号が実際のエンドユーザーのアイデンティティに対して許可されていることを保証します。これにより、共有サービスアカウントや長期的なキーへの依存がなくなります。CipherStash Token Service が、すべての復号リクエストに対してクレームを検証し、マッピングします。

5. エージェント・スキル

開発者（または AI エージェント）が暗号化を「手動で実装」してしまうという一般的な落とし穴を防ぐため、CipherStash は agent skills を提供します。これらは、AI コーディングアシスタントが最初に正しくスタックを実装できるようにするための文書化されたビルディングブロックであり、セキュリティ上の決定がプルリクエスト内でレビュー可能なコードとして記録されることを保証します。

TypeScript での技術的実装

DLAC の実装は、暗号化スキーマの定義から始まります。開発者は、どのフィールドが暗号化され、どのような種類の検索可能な操作が必要かを指定できます。

import { encryptedTable, encryptedColumn } from '@cipherstash/stack/schema';

export const users = encryptedTable('users', { 
  email: encryptedColumn('text').equality().freeTextSearch(),
  meta: encryptedColumn('json').searchableJson(),
});

スキーマが定義されると、SDK が暗号化とクエリのプロセスを処理します。

import { client } from '@cipherstash/stack';
import { users } from './encryption/schema';

// 値の挿入のための暗号化
await db.insert(users).values({
  email: await client.encrypt('alice@example.com', { column: users.email }),
});

// 暗号化された用語によるクエリ
const needle = await client.encrypt('alice@example.com', { column: users.email });
const rows = await db.select().from(users).where(eq(users.email, needle));

DLAC と従来のセキュリティモデルの比較

DLAC を他の一般的なデータベース・セキュリティ戦略と区別することは重要です。

戦略 保護レベル 弱点
Transparent DB Encryption ディスク/物理 盗まれた認証情報に対しては何もできません。DB はログインしているユーザーに平文を渡します。
Row-Level Security (RLS) 行/ポリシー ポリシーは DB 設定に存在します。ポリシーを評価するために、DB は依然として平文を読み取ります。
Tokenization Vaults 外部 すべての読み取りにヴォルトへのラウンドトリップが必要となり、アプリケーション・ロジックを複雑にします。
CipherStash DLAC 値/暗号学的 保護はデータそのものの特性です。設定ミスがあっても、暗号文が返されるだけで、平文の漏洩は起こりません。

AI エージェントのワークフローを保護する

CipherStash モデルでは、エージェントは first-class identities として扱われます。人間のセッションを借りるのではなく、エージェントは独自のキーとポリシーを持っています。強制力は暗号化レイヤーで発生するため、エージェントは明示的にアクセス権限を与えられたフィールドの復号されたバイトのみを見ることができます。

このアーキテクチャは、プロンプト・インジェクションに対する重要な防御策を提供します。エージェントがデータを持ち出すように操作されたとしても、キーを持っていないデータの復号はできません。行レベルのセキュリティ (RLS) はエージェントが取得できる行を制限することはできますが、CipherStash は、その行の中にある何が実際に 読み取れる かを制限します。

パフォーマンスと本番環境でのスケール

CipherStash は、エネルギー分野 (Amber Electric)、ヘルスケア分野 (Journalia)、金融コンプライアンス分野 (BNDRY) を含む、高度に規制された業界において、本番環境で 10 億を超える値を保護していると主張しています。1,000 万行のデータセットに対するパフォーマンス・ベンチマークでは、完全一致クエリで中央値 454μs、範囲クエリで 1.46ms を示しており、値レベルの暗号化が大幅なレイテンシを伴うものではないことを証明しています。

Sources