GitLab Secrets Manager ADR 004: ステートレス鍵管理サービス
ADR-002 において、私たちは秘密の暗号化鍵を保存するために Google の Cloud Key Management Service を使用することを決定しました。これにより、さまざまなコンプライアンス要件をより容易に満たせるようになります。
この ADR では、GitLab Secrets Management Service の望ましいアーキテクチャを説明します。このサービスをステートレスなサービスとして設計し、一時的なローカルストレージ以外の永続的なデータストアには接続しない構成にします。
コンテキスト
決定
GitLab Secrets Management Service をステートレスなアプリケーションとし、リレーショナルデータベースや NoSQL データベースのようなグローバルデータストレージには接続しないようにします。
ローカルブロックストレージのみをサポートし、主にキャッシュ目的での利用に限定します。
復号化コストを適切に管理するために、多層保護を実装し、保護ティアに応じてキャッシュ TTL を持つインメモリのインスタンスごとの対称復号化鍵キャッシュを導入します。Google の Cloud KMS では、ティアに応じてハードウェアまたはソフトウェア鍵を使用できます。
結果
- すべての秘密鍵は Google の Cloud KMS に保存されます。
- 多層保護を実装し、上位ティアほど高い保護を提供します。
- 保護ティアは GitLab Rails Service 側でそれぞれの組織レベルで定義されます。
- 使用する保護レベルに応じて、対称復号化鍵をインメモリにキャッシュできます。
- 対称鍵のキャッシュは 24 時間以上有効であってはなりません。
- 最上位の保護ティアはハードウェアセキュリティモジュールを使用し、キャッシュは行いません。
- GitLab Secrets Management Service はアクセス制御メタデータを保存しません。
- アイデンティティの多重化解除は GitLab Rails Service 側で行います。
- 復号化リクエストは組織の公開鍵で署名されます。
- サービスは署名を確認することで復号化リクエスト者のアイデンティティを検証します。
代替案
リレーショナルデータベースや NoSQL データベース（自己管理型およびクラウドプロバイダーによる管理型の両方）の使用を検討しましたが、これらはサービスの複雑さを大幅に増加させ、セキュリティ態勢を弱めることになると結論付けました。
