シークレットマネジメント

1）「秘密」とはどのようなものなのか"

秘密-開示がシステムまたはデータの妥協につながる資料：パスワード、APIトークン、OAuth/JWTプライベートキー、SSHキー、証明書、暗号化キー（KEK/DEK）、 Webhook署名キー、DSNデータベース/キャッシュ、ベンダーキー（支払い、メール/SMSプロバイダー）、クッキーソルト/ペッパー、ボット/チャットトークン、ライセンス。
秘密はコード、構成、環境、コンテナイメージ、CI/CD、 Terraform/Ansible、ログ/ダンプに住んでいます-秘密の管理のタスク：アカウント→ストレージ→配信→使用→回転→応答→監査→利用。

2）アーキテクチャの原則

一元化。ストレージ、発行、および監査のための1つの信頼できるレイヤー（Vault/Cloud Secret Manager/KMS）。
最小特権（PoLP）。最低期間、必要なサービス/ロールにのみアクセスできます。
短命だった。TTL/リースでのダイナミック/タイムシークレットが好ましい。
暗号アジリティ。ダウンタイムなしでアルゴリズム/キー長を変更する機能。
秘密をコード/画像から分離します。リポジトリにパスワードはなく、Dockerイメージもありません。
観察可能性と監査。発行/読み取りシークレットの各操作はログ化され、削除されます。
自動ローテーション。回転はパイプライン内のプロセスであり、手動操作ではありません。

3）典型的なソリューションとコンポーネントの役割

KMS/HSM。ルートトラスト、暗号化/キー包装操作（エンベロープ）。
シークレットマネージャー/ヴォールト。シークレットバージョンストア、ACL、監査、動的秘密（DB、クラウドIAM、 PKI）、回転テンプレート。
PKI/CA。短命なmTLS/SSH/JWT署名の発行。
エージェント/サイドカー。runtime （tmpfs、 in-memory k/v、 hot-reloadファイル）への秘密の配信。
CSIドライバ/演算子。Kubernetes （Secret Store CSI Driver、 cert-manager）との統合。
Gitの暗号化レイヤー。SOPS/age、 git-crypt（インフラストラクチャコード用）。

4）分類と方針

クリティカル（P0/P1/P2）とダメージの量（テナントスコープ、環境スコープ、組織全体）による個別の秘密。各クラスには、次のように指定します：

TTL/リースおよび回転頻度；
出力方法（ダイナミクスと静的）、フォーマット、メディア；
アクセスポリシー（who/where/when/why）、 mTLSおよび相互認証要件;
監査（私たちがどれくらい保管しているか、誰がレビューしているかをログに記録すること）；
壊れ目ガラスのプロシージャおよびリコール。

5）秘密のライフサイクル

1.作成：メタデータ（所有者、タグ、スコープ）を持つSecret Manager APIを使用します。
2.ストレージ：暗号化（エンベロープ：KMS/HSMからKEKでラップされたDEK）。
3.配達：承認されたエンティティ（OIDC/JWT、 SPIFFE/SVID、 mTLS）の要求に応じて。
4.使用法：専用メモリ/tmpfs；ロギング/ダンプの禁止。

5.回転： TTLまたはイベントによって（妥協）；並列バージョンのサポート（N-1）

6.リコール/ブロック：リースの即時期限、ターゲットシステムのアカウント/キーの無効化。
7.廃棄：バージョン/マテリアル、明確な監査チェーンの破壊。

6）動的秘密（デフォルトで推奨）

アイデア：秘密は短時間発行され、自動的に期限切れになります。例：

データベース認証情報（Postgres/MySQL）とTTL 15-60 min。
サービスロールによる一時的なクラウドキー（AWS/GCP/Azure）。
SSH証明書（5-30分）、X。509証明書（時間/日）。
署名要求のための一時的なJWT、セッションチケットブローカー。
長所：最小限の爆風半径、単純化されたリコール（世界では何も「残る」ことはありません）。

7）実行時の秘密の配信

Kubernetes：

Secret Store CSI Driver→外部マネージャからPodをファイルとしてマウントする（tmpfs）。
唯一のソースとしてKubernetes Secretを避ける（base64 ≠暗号化）。必要に応じて、KMSプロバイダをetcdに有効にします。
自動リネバルリースとホットリロードを備えたサイドカーエージェント（Vault Agent/Secrets Store）。
VM/ベアメタル：システムエージェント+mTLSからVault/Secret Manager、メモリ内のキャッシュ、最小TCB。
サーバーレス：環境変数/ファイルとしてシークレットを透過的に置き換えるクラウド統合ですが、長寿命のエンバー（好ましくはファイル/メモリ内）は避けてください。

例（Kubernetes+CSI、概念的に）

yaml apiVersion: v1 kind: Pod metadata: { name: app }
spec:
serviceAccountName: app-sa # is associated with a role in Secret Manager volumes:
- name: secrets csi:
driver: secrets-store. csi. k8s. io readOnly: true volumeAttributes:
secretProviderClass: app-spc containers:
- name: app volumeMounts:
- mountPath: /run/secrets name: secrets readOnly: true

8） CI/CDおよびIaCの統合

CI：労働者はOIDC （Workload Identity）に従って短命のトークンを受け取ります。ログに入る「マスクされた」秘密の禁止。ステップ「リークスキャン」（trufflehog/gitleaks）。
CD：展開は、表示時に秘密を取ります、アーティファクトにそれらを書き込みません。
IaC： TerraformはSecret Managerに変数を格納します。状態は暗号化され、アクセスが制限されます。
SOPS/age： reposの場合-KMSの制御下で暗号化されたマニフェスト、キーを保存します。

例（SOPSフラグメント）

yaml apiVersion: v1 kind: Secret metadata: { name: app }
data:
PASSWORD: ENC[AES256_GCM,data:...,sops:...]
sops:
kms:
- arn: arn:aws:kms:...
encrypted_regex: '^(data    stringData)$'
version: '3. 8. 0'

9）アクセスポリシーとワークロード認証

ワークロードのアイデンティティ：SPIFFE/SPIRE、 Kubernetes SA→OIDC→IAM- роль、 mTLS。
一時トークン：短いTTL、狭いスコープ。
ABAC/RBAC in Secret Manager：「Y環境でXシークレットを読める人」と「作成/回転できる人」は別です。
マルチテナント：テナントごとに別々の名前空間/キーリング。個々のポリシーとレポート。

10）回転、バージョンおよび互換性

シークレットIDとバージョン（'secret/app/db#v17'）を分離します。
非停止回転のための2つのアクティブなバージョン（NとN-1）をサポートします。
ローテーションはイベントベースです：解雇、妥協、プロバイダの変更、アルゴリズムの移行。
自動化：Vault/Secret Managerのcron/backend回転+アプリケーションの再起動/renevalのwebhookトリガー。

ミニレシピ「ツーキー」Webhook回転

text
T0: we publish two secrets in the provider: current, next
T1: the application starts accepting signatures by both current and next
T2: external system switches signature to next
T3: we do next -> current, re-release new next

11）オフランタイムストレージ： バックアップとアーティファクト

アーティファクト（画像、ログアーカイブ、ダンプ）に入らないでください。
Secret Managerバックアップ-暗号化、同一ループ外のストレージキー（職務の分離）。
タグとDLPスキャン：S3/Blob/GCS、 Git、 CIアーティファクトの秘密を検出します。

12）観察可能性、監査およびSLO

メトリクス：発行回数/秘密/サービス、期限切れのリースのシェア、平均TTL、回転時間、収束時間（新しいバージョンを「受け入れる」前の秒/分）。
監査ログ：who/what/when/where/why；ストレージは別々に暗号化されています。
SLO： 99％出力<200ミリ秒；0ログのリーク；100％の秘密が所有者/TTL/タグを持っています。100％重要な秘密-30日≤動的または回転。
アラート：secret expires <7 days （staticの場合）、spike in authentication failures to storage、 Ndays （dead）、予期しないgeo/ASNソース。

13）頻繁な間違いとそれらを回避する方法

Git/imageryの秘密。SOPS/ageとスキャナを使用します。「ベアライン」を禁止する方針。
長期的な媒体としてEnvvars。tmpfs/in-memoryファイルを優先します。フォーク/ダンプで環境をきれいにして下さい。
dev/stage/prodの同じ秘密。環境によって分けて下さい。
長寿命の静的パスワード。動的/短命に切り替えます。
すべてのための単一のマスターキー"。"テナント/プロジェクト/サービスで分ける。
ホットリロードなし。アプリケーションは、回転中に再起動→脆弱性ウィンドウを必要とします。

14）統合の例（回路図）

Vaultの動的Postgresアクセス

hcl
Vault: role -> issues the user to the database with TTL 30m and privileges only to the app path "database/creds/app-role" {
capabilities = ["read"]
}
Application requests/database/creds/app-role -> receives (user, pass, ttl)

リクエストのJWT署名（短期）

秘密鍵はシークレットマネージャに格納されます。サービスは短命の署名トークンを要求し、ローカルエージェントはペイロードに署名します（キーはアプリケーションに文字列として渡されません）。

管理者のSSH証明書

SSO （OIDC）経由でSSH-certを10分間発行し、永久キーを配布しない。

15）端のまわりの安全

ログ/トレイル/メトリクス：サニタイザ、既知のキー/パターンのフィルタ。「秘密」フィールド-APMでのマスキング。
ダンプ/クラッシュレポート：デフォルトでカット；必要ならば-暗号化し、きれいにして下さい。
クライアントアプリケーション/モバイル：オフラインの秘密を最小限に抑え、プラットフォームストレージ（キーチェーン/キーストア）、デバイスバインディング、緊急ローリングによるTLSピニングを使用します。

16）コンプライアンス

PCI DSS：暗号化なしでPAN/secretsを保存することを禁止します。厳密なアクセス管理および回転。

ISO 27001/SOC 2-資産管理、ロギング、アクセス制御、再構成要件

GDPR/ローカルレギュレータ：最小化、必要に応じてアクセス、監査。

17）プロセスとランブック

コミッショニング

1.秘密のインベントリ（リポジトリ、CI、イメージ、ランタイム、バックアップ）。
2.分類とタグ（所有者、環境、テナント、回転ポリシー）。
3.Vault/Cloud SM+KMS/HSMの統合。
4.ワークロードID （OIDC/SPIRE）で出力を設定します。
5.DB/Cloud/PKIの動的シークレットを有効にします。
6.自動回転およびホットリロード；有効期限を通知します。
7.リークスキャナとデータカタログ/ETの設定。

緊急事態のシナリオ

漏洩の疑い：アクセス停止リスト、即時回転、証明書/キーの取り消し、トークンの再発行、監査の増加、RCAを有効にします。
Secret Managerは使用できません。TTLが低いメモリ内のローカルキャッシュ、機能の劣化、新しい接続の制限、手動のブレークガラスステップ。
ルートキーの妥協：キー階層の再生、すべてのDEKのリラップ、リスクウィンドウのすべてのエクスポージャのチェック。

18）チェックリスト

販売する前に

コード/画像から削除された秘密。リークスキャナが含まれています。
重要な秘密のために動的メカニズムが有効になります。
ホットリロードでサイドカー/CSI/tmpfs経由で配信、耐久性のあるエンバーはありません。
IAM/ABACポリシーが設定され、ワークロードIDにバインドされます。
互換性のための自動回転およびデュアルバージョン（N、 N-1）。
メトリック/アラート/監査が有効になっています。劣化テストに合格しました。

操作

マンスリーレポート：所有者、TTL、期限切れの秘密、未使用。
漏れ経路（ログ、ダンプ、アーティファクト）の周期的な回転および浸透試験。
暗号アジリティプランとCA/ルートの緊急交換。

19） FAQ

Q： Secret ManagerはKMSなしで十分ですか？
A：基本的なレベル-はい、しかし、エンベロープ暗号化を使用することをお勧めします：KMS/HSMのKEK、秘密-ラップ。これにより、フィードバックとコンプライアンスが簡素化されます。

Q：静的またはダイナミクスを選択するには？
A：デフォルトはダイナミクスです。サポートされているプロバイダがない場合にのみ静的に放置し、TTLを数日/時間+自動回転まで焼き付けます。

Q：マイクロサービスに安全に秘密を投げる方法か？
作業負荷ID→mTLSシークレットマネージャ→サイドカー/CSI→файлы tmpfs+ホットリロード。ログも、エンバーも「永遠」もありません。

Q： Kubernetes Secretで秘密を守ることはできますか？
A： KMSプロバイダと厳格なポリシーでetcd暗号化が有効になっている場合のみ。外部ストレージとCSIを好みます。

Q：テナントのアクセスを「暗号消去」するには？
A：シークレットマネージャーでポリシーを取り消し/ブロックし、すべてのリース、キーの回転/再生を無効にします。KMSを使用する場合-対応するKEKのunwrapを無効にします。

シークレットマネジメント