はじめに: なぜ秘密管理と批判が必要なのか
単一の API キーがパブリック リポジトリに公開されると、わずか数分で数千ユーロの費用がかかる可能性があります。 自動化されたボットは GitHub を常にスキャンしてコミットされた認証情報を探します 間違って: AWS キー、Firebase トークン、データベース パスワード。秘密の管理はそうではありません CI/CD パイプラインのオプションであり、絶対に必要です。
この記事では、シークレットを安全に管理する方法を詳しく説明します。 GitHub Secret から始まり、次のようなエンタープライズ ソリューションまでの CI/CD パイプライン HashiCorp 保管庫。各戦略は、具体的な実践例とともに説明されています。 Angular アプリケーション。
この記事で学べること
- 秘密の管理はセキュリティの基本であるため
- GitHub Secret の仕組み (リポジトリ、環境、組織)
- 環境変数とシークレットの違い
- ファイルのセキュリティを管理する方法
.env - ランタイムシークレットとビルドタイムシークレットの違い
- 秘密のローテーション戦略
- ボールト ソリューション: HashiCorp Vault、AWS Secrets Manager、GCP Secret Manager
- git-secret と pre-commit フックを使用して秘密漏洩を防ぐ方法
- 監査証跡とコンプライアンスのベストプラクティス
1. GitHub Secrets: 秘密管理の基礎
GitHub は 3 つのレベルのシークレットを提供しており、それぞれ公開範囲が異なります。理解する 効果的な管理には、各レベルをいつ使用するかが重要です。
GitHub Secretレイヤー
| レベル | 範囲 | 使用事例 | アクセスできる人 |
|---|---|---|---|
| リポジトリ | 単一リポジトリ | プロジェクト固有の API キー | すべてのリポジトリのワークフロー |
| 環境 | 特定の環境 (ステージング、実稼働) | 本番環境の認証情報 | ワークフローのみ environment 指定された |
| 組織 | 組織のすべてのリポジトリ | 共有トークン (npm、Docker Hub) | 管理者が選択したリポジトリ |
リポジトリでシークレットを構成する
シークレットをリポジトリに追加するには、次の場所に移動します。 設定 > シークレットと変数 > [アクション] > [新しいリポジトリ シークレット]。ワークフローでそれらを使用する方法は次のとおりです。
# Accedere ai segreti del repository
jobs:
deploy:
runs-on: ubuntu-latest
steps:
- name: Deploy to Firebase
env:
FIREBASE_TOKEN: ${{ secrets.FIREBASE_TOKEN }}
run: firebase deploy --token "$FIREBASE_TOKEN"
# I segreti vengono automaticamente mascherati nei log
- name: Debug (il segreto viene mostrato come ***)
run: echo "Token is ${{ secrets.FIREBASE_TOKEN }}"
環境への秘密
環境ごとのシークレットは、ステージング認証情報と認証情報を分離するための最良の選択です。
生産。キーワードが必要です environment 仕事の中で：
# Segreti per ambiente
jobs:
deploy-staging:
runs-on: ubuntu-latest
environment: staging
steps:
- name: Deploy to staging
env:
# Usa il segreto dell'ambiente "staging"
API_KEY: ${{ secrets.API_KEY }}
DEPLOY_URL: ${{ vars.DEPLOY_URL }}
run: |
echo "Deploying to $DEPLOY_URL"
firebase deploy --token "${{ secrets.FIREBASE_TOKEN }}"
deploy-production:
runs-on: ubuntu-latest
environment: production
needs: deploy-staging
steps:
- name: Deploy to production
env:
# Usa il segreto dell'ambiente "production" (diverso!)
API_KEY: ${{ secrets.API_KEY }}
run: firebase deploy --token "${{ secrets.FIREBASE_TOKEN }}"
生産環境の保護
常に設定してください 環境保護規則 実稼働環境の場合:
導入前にレビュー担当者からの手動承認を必要とし、実行できるブランチを制限する
運用環境にデプロイ (のみ main)、待機タイマーを有効にして、
安全バッファ。
2. 環境変数とシークレット
環境変数とシークレットを区別することが重要です。 GitHub Actions は両方をサポートします ただし、異なる特性があります。
変数とシークレット
| 特性 | 変数 (vars) |
秘密 (secrets) |
|---|---|---|
| ログの可視性 | はっきり見える | *** で自分をマスクする |
| 暗号化 | No | はい (リチウムナトリウム密封ボックス) |
| 作成後に読み取り可能 | Si | いいえ（上書きのみ可能） |
| 一般的な使用方法 | URL、環境名、機能フラグ | トークン、パスワード、API キー |
# Esempio: variabili vs segreti
jobs:
build:
runs-on: ubuntu-latest
environment: production
env:
# Variabili: configurazione non sensibile
API_URL: ${{ vars.API_URL }}
APP_NAME: ${{ vars.APP_NAME }}
ENABLE_ANALYTICS: ${{ vars.ENABLE_ANALYTICS }}
steps:
- uses: actions/checkout@v4
- name: Build with environment config
env:
# Segreti: informazioni sensibili
FIREBASE_TOKEN: ${{ secrets.FIREBASE_TOKEN }}
ANALYTICS_KEY: ${{ secrets.ANALYTICS_KEY }}
run: |
echo "Building for $API_URL"
npm run build -- --configuration=production
3. .env ファイルのセキュリティ
ファイル .env 地域の発展には便利ですが、リスクも伴います
管理が不十分な場合は重大です。基本的なルールは次のとおりです。
推奨構造
# Struttura dei file .env nel progetto
project/
.env # MAI committato (in .gitignore)
.env.example # Template SENZA valori reali (committato)
.env.development # Valori di sviluppo (opzionale, in .gitignore)
.env.production # MAI committato, MAI nel repository
# .env.example - Template committato nel repository
# Copiare in .env e compilare con i valori reali
API_URL=https://api.example.com
FIREBASE_PROJECT_ID=your-project-id
ANALYTICS_ID=
SECRET_KEY=
# .env - File locale (DEVE essere in .gitignore)
API_URL=https://api.example.com
FIREBASE_PROJECT_ID=my-actual-project
ANALYTICS_ID=G-XXXXXXXXXX
SECRET_KEY=super-secret-value-123
.gitignore の黄金律
# .gitignore - Escludere SEMPRE i file .env
.env
.env.local
.env.development.local
.env.test.local
.env.production.local
.env.production
# Ma NON escludere il template
!.env.example
4. ランタイムとビルド時の秘密
Angular アプリケーションの場合、現在利用可能なシークレットの違いを理解することが重要です。 実行時に利用可能なビルドとシークレットの情報。 Angular はフロントエンド フレームワークです。そのすべて これはバンドルに含まれており、ブラウザーに表示されます。
フロントエンドの基本ルール
フロントエンド バンドルにはシークレットを決して含めないでください。 ファイル内に存在するすべての値
environment.ts Angular のものであり、開発者ツールを開いた人に表示されます
ブラウザの。公開 API キー (Google マップや Google Analytics など) を使用できます。
ただし、プライベート トークン、暗号化キー、パスワードをフロントエンド コードに含めてはなりません。
// environment.ts - Cosa e sicuro e cosa NO
// SICURO: chiavi pubbliche con restrizioni di dominio
export const environment = {
production: true,
apiUrl: 'https://api.example.com',
googleMapsKey: 'AIza...', // OK: limitata per dominio nella console Google
analyticsId: 'G-XXXXX', // OK: e un identificatore pubblico
sentryDsn: 'https://xxx@sentry.io/123', // OK: limitata per dominio
};
// MAI FARE QUESTO:
// firebaseAdminKey: 'xxxxx', // PERICOLOSO: accesso admin completo
// stripeSecretKey: 'sk_xxxxx', // PERICOLOSO: accesso ai pagamenti
// dbPassword: 'password123', // PERICOLOSO: accesso al database
パイプラインでビルド時のシークレットを管理する
# Iniettare valori sicuri al build time
jobs:
build:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: actions/setup-node@v4
with:
node-version: '20'
# Sostituire i placeholder nell'environment file
- name: Configure environment
run: |
cat > src/environments/environment.prod.ts << 'ENVEOF'
export const environment = {
production: true,
apiUrl: '${{ vars.API_URL }}',
analyticsId: '${{ vars.ANALYTICS_ID }}',
};
ENVEOF
- run: npm ci
- run: npx ng build --configuration=production
5. シークレットのローテーション
シークレットを定期的にローテーションすることは、セキュリティの基本的な実践です。たとえそれが秘密だとしても 損傷を受けていないため、回転により漏れが発生した場合の露出ウィンドウが減少します。 検出されませんでした。
推奨されるローテーション プラン
| 秘密のようなもの | 頻度 | 理由 |
|---|---|---|
| デプロイメントトークン (Firebase、Vercel) | 90日ごと | 実稼働リソースへのアクセス |
| サードパーティサービスのAPIキー | 180日ごと | 時間の経過とともに侵害されるリスク |
| npm/Docker Hub トークン | 90日ごと | パッケージ公開へのアクセス |
| サービスアカウントJSON | 365日ごと | 長期的な認証情報 |
| 秘密が侵害されました | すぐに | セキュリティ上の緊急事態 |
# Workflow per promemoria di rotazione
name: Secret Rotation Reminder
on:
schedule:
- cron: '0 9 1 */3 *' # Primo giorno di ogni trimestre
jobs:
remind:
runs-on: ubuntu-latest
steps:
- name: Check secret age
run: |
echo "Reminder: E il momento di ruotare i segreti del repository."
echo "Segreti da controllare:"
echo "- FIREBASE_SERVICE_ACCOUNT"
echo "- NPM_TOKEN"
echo "- DOCKER_HUB_TOKEN"
echo "Vai su Settings > Secrets per aggiornare i valori."
- name: Create GitHub Issue
uses: actions/github-script@v7
with:
script: |
github.rest.issues.create({
owner: context.repo.owner,
repo: context.repo.repo,
title: 'Rotazione trimestrale dei segreti',
body: 'E il momento di ruotare i segreti CI/CD.',
labels: ['security', 'maintenance']
});
6. Vault エンタープライズ ソリューション
高度なセキュリティ要件がある組織の場合、GitHub Secrets は適切ではない可能性があります。 十分です。 Vault ソリューションは、詳細な監査などの追加機能を提供します。 自動ローテーションと高度な暗号化。
HashiCorp 保管庫
# Integrare HashiCorp Vault con GitHub Actions
jobs:
deploy:
runs-on: ubuntu-latest
permissions:
id-token: write
contents: read
steps:
- name: Import Secrets from Vault
uses: hashicorp/vault-action@v3
with:
url: https://vault.example.com
method: jwt
role: github-actions
secrets: |
secret/data/production/firebase token | FIREBASE_TOKEN ;
secret/data/production/api key | API_KEY ;
- name: Use imported secrets
run: |
echo "Firebase token is available as env var"
firebase deploy --token "$FIREBASE_TOKEN"
ボールト ソリューションの比較
Vault ソリューションの比較
| 特性 | GitHub の秘密 | HashiCorp 保管庫 | AWS シークレットマネージャー | GCP シークレット マネージャー |
|---|---|---|---|---|
| 料金 | 無料 | セルフホストまたはクラウド | 使用ごとに支払い | 使用ごとに支払い |
| 自動回転 | No | Si | Si | Si |
| 監査ログ | 限定 | 完了 | クラウドトレイル | クラウド監査 |
| 複雑 | 低い | 高い | 平均 | 平均 |
| に最適 | 小規模チーム | 企業 | AWSエコシステム | GCP エコシステム |
7. 秘密の漏洩を防ぐ
治療よりも予防が効果的です。それを防ぐためのツールと実践方法は次のとおりです シークレットは最終的にリポジトリに保存されます。
git-secrets: コミット前スキャン
# Installare git-secrets
# macOS
brew install git-secrets
# Linux
git clone https://github.com/awslabs/git-secrets.git
cd git-secrets && make install
# Configurare nel repository
cd my-project
git secrets --install
git secrets --register-aws
# Aggiungere pattern personalizzati
git secrets --add 'FIREBASE_TOKEN[=:]\s*[A-Za-z0-9]+'
git secrets --add 'sk_live_[A-Za-z0-9]+'
git secrets --add 'AIza[0-9A-Za-z\\-_]{35}'
# Scansionare il repository esistente
git secrets --scan
ハスキーによるプリコミットフック
# Installare husky
npm install -D husky
npx husky init
# Creare il pre-commit hook
cat > .husky/pre-commit << 'HOOKEOF'
#!/bin/sh
# Controllare che nessun segreto venga committato
echo "Checking for secrets..."
# Pattern comuni di segreti
PATTERNS=(
'AKIA[0-9A-Z]{16}' # AWS Access Key
'sk_live_[a-zA-Z0-9]+' # Stripe Secret Key
'AIza[0-9A-Za-z\-_]{35}' # Google API Key
'ghp_[a-zA-Z0-9]{36}' # GitHub Personal Token
'xox[bpoas]-[a-zA-Z0-9-]+' # Slack Token
)
for pattern in "${PATTERNS[@]}"; do
if git diff --cached --name-only -z | xargs -0 grep -lP "$pattern" 2>/dev/null; then
echo "ERRORE: Possibile segreto rilevato!"
echo "Pattern: $pattern"
exit 1
fi
done
echo "Nessun segreto rilevato."
HOOKEOF
chmod +x .husky/pre-commit
GitHub シークレット スキャン
GitHub には、次の組み込み機能も提供されています。 シークレットスキャン 検出する プッシュコミット内のシークレットのパターンが自動的に認識されます。パブリックリポジトリの場合は有効にします デフォルトでは;プライベート リポジトリ用で、GitHub Advanced Security で利用できます。
8. 監査証跡とコンプライアンス
コンプライアンス要件 (SOC 2、GDPR、ISO 27001) を持つ組織の場合、以下を維持する必要があります。 誰がいつシークレットにアクセスしたかのログ:
# Workflow con logging dettagliato
jobs:
deploy:
runs-on: ubuntu-latest
environment: production
steps:
- name: Log deployment attempt
run: |
echo "=== DEPLOYMENT AUDIT LOG ==="
echo "Timestamp: $(date -u +%Y-%m-%dT%H:%M:%SZ)"
echo "Actor: ${{ github.actor }}"
echo "Ref: ${{ github.ref }}"
echo "SHA: ${{ github.sha }}"
echo "Workflow: ${{ github.workflow }}"
echo "Run ID: ${{ github.run_id }}"
echo "Environment: production"
echo "==========================="
- name: Deploy
run: firebase deploy --token "${{ secrets.FIREBASE_TOKEN }}"
- name: Log deployment result
if: always()
run: |
echo "Deploy status: ${{ job.status }}"
機密のセキュリティチェックリスト
- すべてのファイル
.env私はその中にいます.gitignore - ファイルがあります
.env.example実際の値がなければ - 本番環境のシークレットは GitHub 環境のシークレットを使用します
- 実稼働環境では保護ルールがアクティブになっています
- コミット前のフックでシークレットパターンをチェックする
- シークレットのローテーションは四半期ごとにスケジュールされます
- チームは漏洩の場合に何をすべきかを知っています（緊急手順）
- フロントエンドコードにはプライベートシークレットは存在しません
結論
機密の管理はセキュリティにおいて無視できない側面です。この中で 解決策の全範囲を調査した記事: 小さなもののための GitHub Secrets より チームから、高度なコンプライアンス要件を持つ組織の Enterprise Vault まで。
覚えておくべき基本原則は次のとおりです。シークレットをリポジトリに決してコミットしないでください。レイヤーを使用してください。 ステージングと本番を分離する環境、予防のための事前コミットフックの実装、 秘密の定期的なローテーションを計画し、常に緊急時の手順を用意する 漏れの場合に備えて。
次の記事では次のことに焦点を当てます パフォーマンス: 設定していきます 各デプロイメントが確実に維持されるように、パイプライン内のパフォーマンス予算と Lighthouse CI 高い品質基準。