Secure Key Injection and Management
[!NOTE] 最新の実装状況は 機能実装ステータス (Remaining Functionality) を参照してください。
作成日: 2026-03-04
目的: EVOSPIKENET_DATA_ENCRYPTION_KEY（DB/ファイル保存データ暗号化で使用）を安全に運用環境へ注入するための推奨手順を示します。
前提: アプリケーションは EVOSPIKENET_DATA_ENCRYPTION_KEY 環境変数を参照して AES-256-GCM 用の鍵（32バイト以上）を読み込みます。
推奨オプション:
1) HashiCorp Vault (推奨) - Vault に鍵を格納し、アプリケーションは起動時に Vault API から秘密を取得する。 - 利点: 動的ローテーション、アクセス制御、監査ログ。 - 簡易手順: - Vault にシークレットを書く:
vault kv put secret/evospikenet data_key=0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef
- アプリ起動時に Vault から取得（例:スタートアップスクリプト）:
export EVOSPIKENET_DATA_ENCRYPTION_KEY=$(vault kv get -field=data_key secret/evospikenet)
uvicorn evospikenet.api:app --port 8000
- Kubernetes では
vault-agentまたはvault-k8sを利用して Pod に注入する。
2) AWS Secrets Manager / KMS
- 利点: マネージド、KMS で鍵を管理し高い可用性。
- 手順:
- Secrets Manager にシークレットを作成。
- EC2/ECS/EKS のインスタンスプロファイルや IAM ロールに SecretsManager:GetSecretValue 権限を付与。
- 起動時に aws CLI または SDK で取得して環境変数に設定。
export EVOSPIKENET_DATA_ENCRYPTION_KEY=$(aws secretsmanager get-secret-value --secret-id evospikenet/data_key --query SecretString --output text)
3) GCP Secret Manager - GKE 環境では Workload Identity を使って Pod にシークレットを注入する。
4) Kubernetes Secrets / External Secrets
- 短期的な手段として Kubernetes の Secret を利用可能。
- 長期運用では external-secrets や secrets-store-csi-driver と Vault/KMS を連携することを推奨。
運用上の注意: - 鍵は 32 バイト（256 ビット）以上を使用してください。 - 環境変数はプロセスメモリに平文で残るため、可能であればプロセス内で最小限の期間だけ保持しメモリからゼロ化する戦略を検討してください。 - 定期ローテーションとローテーション計画を用意すること（影響調査、再暗号化、ロールアウト順序）。 - 運用手順をドキュメント化し、CI/CD にシークレットの参照を直接埋め込まない。
検証手順（簡易）:
- ローカルで Vault を立て、鍵を登録する。
- スクリプトで
EVOSPIKENET_DATA_ENCRYPTION_KEYを注入してアプリを起動。 - アーティファクトを保存し、DB 上の
dataカラムが暗号化されていること（バイナリ長が増えている等）を確認。 evospikenet.db.load_artifact_dataを使って復号できることを確認。
必要なら、このドキュメントを docs/ の適切な場所へ組み込み、Vault の例を具体的な Terraform / Kubernetes manifest と共に追加します。