web-dev-qa-db-ja.com

CI / CD環境内の資格情報管理

セットアップ:現在、サーバーに手動で展開しているアプリケーションがあります。 gpgで暗号化されたファイルに現在保存しているいくつかの資格情報(外部サービスのクライアントシークレット、トークン、AESキーとIVなど)が必要です。アプリケーションを再起動するたびに、コンソールでgpg- keyのロックを解除すると、サービスがアプリケーションスクリプト内からファイルを再度復号化します(gpg-agentは、パスフレーズを一定期間メモリに保持し、パイプを介してそれらを解析します。

この方法の利点は、資格情報やそれらにアクセスするために必要なgpg- passphraseがディスクに永続化されず、メモリにのみ保持されることです。したがって、完全なrootアクセスがあっても、資格情報を回復することは不可能です。唯一のチャンスは、gpg- keyのロックが解除されたままの短い時間枠でアクセスすることです。

不利な点は、(a)他のユーザーがサービスを開始できない(アカウントを共有しない限り)、(b)アプリケーションを自動化された方法で開始できないことです。

Githubに creds プロジェクトがあります。これは私がやっていることと似ていますが、それでも上記の欠点を共有しています。複数のgpgキーを使用してファイルを暗号化し、成功するまですべてのキーを使用してファイルの暗号化を解除することが可能です。

質問:(a)キーまたはアカウントを共有せずに複数のユーザーがアクセスできる、(b)CIがアクセスできる資格情報を処理するためのより良い方法は何ですか/ CDシステム(展開が行われるたびにコンソールがない場合)、および(c)パスワードデータのみをメモリに保持しますか?複数のgpgキーを使用する「回避策」は複雑なハックのように見え、CI/CDシステムでは機能しません。

5
user8472

保護したい他の機密情報があるかもしれないので、クレデンシャルの代わりに秘密について話します。質問がCI/CDシステムに向けて具体的に書かれていることは問題ではありません。認証にX.509証明書を使用すること、データベース資格情報を保存すること、ビルドエージェントのアクセストークンを保護することのいずれについても、問題は同じです。

アプリケーションと組織のニーズは、何がシークレットを構成し、どのようにそれらを処理するかについて異なるため、これを処理する正規の方法はありません。アプリケーションによっては、シークレットをファイルに保存する以外の方法がない場合があります。

一部のアプリケーションはディスク上のシークレットを暗号化しますが、多くの場合は対称的であるため、多少装飾的です。

それで、あなたは何ができますか?

  • 最初の防御線は、オペレーティングシステムのDAC(任意のアクセス制御)とMAC(必須のアクセス制御)です。Linuxの場合、POSIXのアクセス許可はDACであり、App Armor、SELinux、GRSecurityなどのLSMはMACです。

  • [〜#〜] cis [〜#〜] または DISA STIG のような適切な標準に合わせてOSを監査します。

  • [〜#〜] hsm [〜#〜] または OpenPGP smartcard を使用して、ディスクの秘密を暗号化するために使用するPGPキーを格納します。このようなデバイスは、キーがハードウェアを離れることを保証します。

HSMのキーを安全に保つ手段は1つもないことに注意してください。物理的なアクセスによってキーが危険にさらされる可能性があります。ハードウェアキーストレージデバイスは、物理的なセキュリティと適切な運用手順と組み合わせて、セキュリティを強化する必要があります。

主要なブラウザのルートCAポリシー( ChromeFirefoxEdge/IE )を確認します。それらは、ハードウェア暗号デバイスの使用と、それらを操作する方法および合格しなければならない監査に関するいくつかの制限とルールを適用します。

  • Vault などのソフトウェアを使用してオンデマンドでシークレットを取得しますが、アプリケーションのサポートが必要です。それ以外の場合は、再びディスクに保存するだけです。 Vaultがミックスに追加できるのは、シークレットを強制するTTLで、シークレットを独自にローテーションする機能です。
3
fuero