秘密管理: ソフトウェアにおける秘密の問題
I 秘密 (認証情報、API キー、証明書、アクセス トークン) が要素です ソフトウェアインフラストラクチャよりも機密性が高くなります。単一の秘密が公開されると侵害される可能性があります システム全体、データベース、クラウドアカウント。 GitGuardian の調査によると、2024 年には さらに見つかった 1,200万の秘密 GitHub のパブリック リポジトリで公開されています。
シークレット管理は、単に「コード内でパスワードをコミットしない」だけではありません。完全なシステムです の生成、安全な保管、配布、ローテーション、取り消しをカバーします。 彼らのライフサイクル全体を通して秘密です。
何を学ぶか
- 秘密管理システムのアーキテクチャ
- HashiCorp Vault: セットアップ、構成、統合
- AWS Secrets Manager とクラウドの代替手段
- 資格情報の自動ローテーション戦略
- GitLeaks と TruffleHog を使用したリポジトリ内の秘密の検出
- よくあるアンチパターンとその回避方法
アンチパターン: 秘密を管理しない方法
解決策を検討する前に、暴露につながる最も一般的なエラーを見てみましょう。 資格情報の:
- コード内にハードコードされている: ソースコードに直接記述されたパスワードと API キー
- リポジトリ内の .env ファイル: シークレットを含む設定ファイルが誤ってコミットされました
- 保護されていない環境変数: 暗号化なしで環境変数として渡されるシークレット
- チャットで秘密を共有: Slack、Teams、または電子メールで送信された資格情報
- シークレットは決して回転しない: 決して変更されない静的認証情報
- 広すぎる権限: 必要最小限ではなく、すべてのサービスにアクセスできる API キー
機密漏洩の代償
パブリック リポジトリで公開された秘密は、平均して自動化されたボットによって発見されます 私は入ります 24秒。 1 分以内に悪意のある攻撃者が活動を開始する可能性があります 資格情報を悪用します。問題が発生していない組織における修復までの平均時間 自動化されたプロセスと 327日.
HashiCorp Vault: 参照標準
HashiCorp 保管庫 エンタープライズ シークレット管理のための最も普及しているソリューションです。 安全なストレージ、制御されたアクセス、監査ログ、および動的なローテーションのサポートを提供します。 秘密の。 Vault は、限られた TTL でオンデマンドで認証情報を生成できるため、 静的な秘密の問題。
Docker を使用して Vault をセットアップする
# docker-compose.vault.yml
version: "3.8"
services:
vault:
image: hashicorp/vault:1.15
container_name: vault
ports:
- "8200:8200"
environment:
VAULT_DEV_ROOT_TOKEN_ID: "dev-root-token"
VAULT_DEV_LISTEN_ADDRESS: "0.0.0.0:8200"
cap_add:
- IPC_LOCK
volumes:
- vault-data:/vault/data
volumes:
vault-data:
Vault CLI を使用した基本操作
# Configurare il client
export VAULT_ADDR="http://127.0.0.1:8200"
export VAULT_TOKEN="dev-root-token"
# Abilitare il secrets engine KV v2
vault secrets enable -version=2 kv
# Scrivere un secret
vault kv put kv/myapp/database \
username="dbadmin" \
password="super-secret-password" \
host="db.internal.company.com"
# Leggere un secret
vault kv get kv/myapp/database
# Leggere un campo specifico
vault kv get -field=password kv/myapp/database
# Creare una policy di accesso
vault policy write myapp-read - <<EOF
path "kv/data/myapp/*" {
capabilities = ["read", "list"]
}
EOF
# Creare un token con policy limitata
vault token create -policy=myapp-read -ttl=1h
動的シークレット: オンデマンド認証情報
Vault の最も強力な機能の 1 つは次のとおりです。 動的な秘密: 資格情報 制限された TTL を使用してリクエスト時に生成されます。 TTL の有効期限が切れると、Vault は TTL を取り消します 資格情報を自動的に取得します。これにより、静的シークレットの問題が解消されます。
# Abilitare il database secrets engine
vault secrets enable database
# Configurare la connessione PostgreSQL
vault write database/config/mydb \
plugin_name=postgresql-database-plugin \
allowed_roles="readonly" \
connection_url="postgresql://{{username}}:{{password}}@db:5432/mydb?sslmode=disable" \
username="vault_admin" \
password="vault_admin_password"
# Creare un ruolo con credenziali dinamiche
vault write database/roles/readonly \
db_name=mydb \
creation_statements="CREATE ROLE \"{{name}}\" WITH LOGIN PASSWORD '{{password}}' VALID UNTIL '{{expiration}}'; GRANT SELECT ON ALL TABLES IN SCHEMA public TO \"{{name}}\";" \
default_ttl="1h" \
max_ttl="24h"
# Ottenere credenziali dinamiche
vault read database/creds/readonly
AWS シークレットマネージャー
AWS で実行している組織の場合、 AWS シークレットマネージャー サービスを提供します 統合された自動ローテーションによるシークレット管理のための管理、ネイティブ サポート RDS、Redshift、DocumentDB、および AWS サービスとのシームレスな統合。
機密管理ソリューションの比較
- HashiCorp 保管庫: マルチクラウド、セルフホストまたはマネージド (HCP)、最大限の柔軟性
- AWS シークレットマネージャー: AWS ネイティブ、RDS 自動回転、使いやすい
- Azure Key Vault: ネイティブ Azure、AD 統合、HSM サポート
- GCP シークレット マネージャー: ネイティブ GCP、IAM 統合、バージョニング
- Kubernetes の秘密:base64 エンコード (暗号化されていません!)、external-secrets-operator とともに使用します
リポジトリ内のシークレットの検出
予防と防御の第一線。秘密検出ツールが分析する コードは、リモート リポジトリに到達する前に、公開された資格情報を探します。
GitLeaks: コミット前フック
# .pre-commit-config.yaml
repos:
- repo: https://github.com/gitleaks/gitleaks
rev: v8.18.0
hooks:
- id: gitleaks
# .gitleaks.toml - configurazione personalizzata
[extend]
useDefault = true
[[rules]]
id = "custom-api-key"
description = "Custom API Key pattern"
regex = '''MYAPP_API_KEY\s*=\s*['"]([A-Za-z0-9_-]+)['"]'''
secretGroup = 1
entropy = 3.5
[allowlist]
paths = [
'''test/.*''',
'''.*_test\.go''',
'''.*\.md'''
]
CI/CDの統合
# .github/workflows/secret-detection.yml
name: Secret Detection
on:
push:
branches: [main, develop]
pull_request:
jobs:
gitleaks:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
with:
fetch-depth: 0
- name: GitLeaks scan
uses: gitleaks/gitleaks-action@v2
env:
GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
ローテーション戦略
La 秘密のローテーション 資格情報を定期的に置き換えるプロセス。 回転により、侵害された場合の暴露範囲が縮小され、損傷が制限されます。 まだ発見されていない漏洩秘密。
- 自動回転: AWS Secrets Manager のようなサービスは、設定可能な間隔で認証情報を自動的にローテーションできます
- 動的な秘密: Vault は制限された TTL で認証情報を生成するため、ローテーションの必要がなくなります。
- 計画的な手動ローテーション: 自動的にローテーションできないシークレットについては、四半期ごとのローテーションをスケジュールします。
- 緊急ローテーション: 違反が発生した場合にすべての秘密を取り消してローテーションする手順
シークレット管理のベスト プラクティス
- コードには決して含めないでください: ソース コード、構成ファイル、またはコンテナ イメージにシークレットがありません
- 一元化: 組織全体に対する単一の秘密管理システム
- 最低限の特権: 各アプリケーションは必要なシークレットのみにアクセスします
- 監査ログ: コンプライアンスとフォレンジックのために機密情報へのすべてのアクセスを記録します。
- 自動回転: 最大 TTL 90 日ですべてのシークレットのローテーションを実装します。
- 事前コミットフック: プッシュ前にシークレットをロックするための事前コミットとして GitLeaks または TruffleHog
- 保存時の暗号化: シークレットは使用しないときは暗号化する必要があります
結論
シークレット管理は、DevSecOps の最も重要な柱の 1 つです。秘密が暴露されると、 安全性に対する他のすべての投資を無効にします。安全なストレージの組み合わせ (Vault)、予防的検出 (GitLeaks)、自動ローテーションにより防御システムが作成されます。 認証情報の侵害に対して堅牢です。
次の記事では、詳しく見ていきます コードとしてのポリシー、定義方法を分析する また、OPA/Rego、Kyverno、Sentinel を使用してセキュリティ ポリシーを自動的に適用します。