secrets-management

シークレット管理

使用するタイミング

認可されたシステムに対して、シークレットの取得、CI 認証情報、ワークロード ID、アクセスポリシー、ローテーションを設計または修正するとき。

入力

シークレットの名前と所有者、利用者、環境、認証メカニズム、ローテーション/リカバリポリシーを特定します。値を表示せずに構成を調査します。

手順

1. 既存のサポートされているバックエンドを選択します。Vault、クラウドのシークレットマネージャー、またはホストの保護されたシークレットストアです。環境の境界と最小権限を明確に保ちます。
2. Vault の場合は、references/vault-setup.md を参照してください。開発モードと root トークンは本番構成ではありません。
3. GitHub Actions の場合は、references/github-secrets.md を参照してください。プルリクエストの検証は特権ジョブから分離しておきます。値は利用するプロセスに渡し、生成されたシェルソースに展開したり、デバッグのために出力したりしないでください。
4. バックエンドがサポートしている場合は、短命なワークロード ID を優先します。取得を有効化する前に、発行者、対象者、ワークロード/環境の制限、拒否されるアクセスを確認します。
5. 準備、利用者の切り替え、検証、古い認証情報の失効という流れでローテーションします。バックエンドがサポートするローテーションプロトコルを使用してください。リトライによってデータベースとシークレットストアが異なる認証情報のままになることがあってはなりません。
6. ログ、エラーパス、成果物、クラッシュレポートを合成のシークレットマーカーで調査します。値ではなく、操作、主体、結果などのメタデータを記録します。

例

あるデプロイメントがデータベースの認証情報を必要としています。信頼されたジョブが構成済みの ID を通じてそれを取得し、マイグレーションプロセスにのみ渡します。ステージングで、アクセスの欠如と期限切れの ID をテストします。出力に認証情報が現れないこと、および失敗したローテーションが復旧可能な動作状態を残すことを検証します。

検証

• 認可された取得は成功し、異なるワークロードまたは環境は拒否されます。
• 認証情報の欠如は、値を露出せずにフェイルクローズします。
• ローテーションとロールバックは合成データで実行されます。
• ログと成果物には、失敗時も含めてシークレットマーカーが含まれていません。
• 露出した認証情報は失効またはローテーションされます。ログエントリを削除するだけでは不十分です。

制限事項

マスキングによってシークレットのログ記録が安全になるわけではありません。シークレットデータはインフラストラクチャの状態、サブプロセスの環境、バックアップに残存する可能性があります。これらの境界を明示的に確認してください。認可なく実際の認証情報を変更したり、シークレットインフラストラクチャをデプロイしたりしないでください。

出典

• GitHub secure workflow guidance
• Vault production hardening