KVS セキュリティ - KVS セキュリティ

DynamoDB / Firestore / Cosmos DB 等の KVS（Key-Value Store）特有のセキュリティ。IAM ベースのアクセス制御、データ暗号化、パーティションキー設計によるデータ漏洩リスクを解説。

概念図

実例

Firestore のセキュリティルールによるアクセス制御

bash

// Firestore セキュリティルール: ユーザー自身のドキュメントのみ読み書き許可
rules_version = '2';
service cloud.firestore {
  match /databases/{database}/documents {
    match /users/{userId} {
      allow read, write: if request.auth != null
        && request.auth.uid == userId;
    }
  }
}

DynamoDB の CMK による暗号化設定

bash

// DynamoDB: サーバーサイド暗号化（SSE）の設定
aws dynamodb create-table \
  --table-name SensitiveData \
  --attribute-definitions AttributeName=pk,AttributeType=S \
  --key-schema AttributeName=pk,KeyType=HASH \
  --sse-specification Enabled=true,SSEType=KMS,KMSMasterKeyId=alias/mykey \
  --billing-mode PAY_PER_REQUEST

KVS のアクセス制御モデル

KVS は RDB の GRANT/REVOKE とは異なり、クラウドプロバイダの IAM やセキュリティルールでアクセスを制御します。

DynamoDB: IAM ポリシーでテーブル単位・アイテム単位（LeadingKeys 条件）のアクセス制御が可能。Fine-Grained Access Control で特定のパーティションキーのみ許可できる
Firestore: セキュリティルールでドキュメント単位のアクセス制御を定義する。ルールがないと全拒否。クライアントから直接アクセスされるため、ルール設計が特に重要
Cosmos DB: Azure RBAC またはリソーストークンでアクセス制御。マスターキーは管理操作にのみ使用し、アプリケーションにはリソーストークンを発行する

RDB の「全テーブルに SELECT 権限」のような広範な権限は KVS でも同様に危険です。

テーブル・コレクション・アイテム単位で最小権限を設定しましょう。

パーティションキー設計とデータ漏洩

パーティションキーの設計ミスは、意図しないデータアクセスを招きます。

予測可能なキー: 連番や日付のような予測可能なパーティションキーを使うと、攻撃者が他ユーザーのデータにアクセスしやすくなる（IDOR: Insecure Direct Object Reference）
テナント分離の不備: マルチテナント環境でテナント ID をパーティションキーに含めない場合、IAM 条件キーによるテナント分離が困難になる
ホットパーティション: 特定のキーにアクセスが集中すると、スロットリングが発生し、正規ユーザーがサービスを利用できなくなる（一種の DoS）
GSI（グローバルセカンダリインデックス）の過剰公開: GSI のキー設計によっては、本来アクセスできないデータがインデックス経由で参照可能になる場合がある

KVS のデータ暗号化

主要な KVS サービスはサーバーサイド暗号化をサポートしますが、設定内容を理解する必要があります。

DynamoDB: デフォルトで AWS 所有キーによる暗号化が有効。顧客管理キー（CMK）を使用すると、鍵のローテーションやアクセス制御をより細かく管理可能
Firestore: Google が管理する暗号化が自動適用。顧客管理暗号鍵（CMEK）も利用可能
Cosmos DB: Microsoft 管理キーで自動暗号化。顧客管理キーで追加の暗号化レイヤーを追加可能

クライアントサイド暗号化を併用すると、クラウドプロバイダからもデータを保護できます。

機微情報を扱う場合は、AWS Encryption SDK や同等のライブラリでアプリケーション層の暗号化を検討しましょう。

概念図

実例

KVS のアクセス制御モデル

パーティションキー設計とデータ漏洩

KVS のデータ暗号化

関連トピック