소개: 비밀 관리와 비판이 필요한 이유
공개 저장소에 노출된 단일 API 키는 단 몇 분 만에 수천 유로의 비용이 들 수 있습니다. 자동화된 봇은 GitHub에서 커밋된 자격 증명을 지속적으로 검색합니다. 실수: AWS 키, Firebase 토큰, 데이터베이스 비밀번호. 비밀 관리는 그렇지 않습니다. CI/CD 파이프라인의 옵션이자 절대적인 필요성입니다.
이 기사에서는 보안 비밀을 안전하게 관리하는 방법을 자세히 살펴보겠습니다. GitHub Secrets에서 시작하여 다음과 같은 엔터프라이즈 솔루션까지 CI/CD 파이프라인 HashiCorp 금고. 각 전략은 다음에 대한 구체적인 실제 사례를 통해 설명됩니다. 각도 애플리케이션.
이 기사에서 배울 내용
- 비밀 관리는 보안의 기본이기 때문입니다.
- GitHub Secret 작동 방식(리포지토리, 환경, 조직)
- 환경 변수와 비밀의 차이점
- 파일 보안을 관리하는 방법
.env - 런타임 비밀과 빌드 타임 비밀의 차이점
- 비밀 순환 전략
- Vault 솔루션: HashiCorp Vault, AWS Secrets Manager, GCP Secret Manager
- git-secrets 및 사전 커밋 후크를 사용하여 비밀 유출을 방지하는 방법
- 감사 추적 및 규정 준수 모범 사례
1. GitHub Secrets: 비밀 관리의 기초
GitHub는 각각 다른 가시성 범위를 갖는 세 가지 수준의 비밀을 제공합니다. 이해하다 각 수준을 언제 사용할지는 효과적인 관리에 매우 중요합니다.
GitHub 비밀 레이어
| 수준 | 범위 | 사용 사례 | 액세스할 수 있는 사람 |
|---|---|---|---|
| 저장소 | 단일 저장소 | 프로젝트별 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 솔루션 비교
Vault 솔루션 비교
| 특성 | GitHub 비밀 | HashiCorp 금고 | AWS 비밀 관리자 | GCP 비밀 관리자 |
|---|---|---|---|---|
| 비용 | 무료 | 자체 호스팅 또는 클라우드 | 사용량에 따라 지불 | 사용량에 따라 지불 |
| 자동 회전 | No | Si | Si | Si |
| 감사 로그 | 제한된 | 완벽한 | CloudTrail | 클라우드 감사 |
| 복잡성 | 낮은 | 높은 | 평균 | 평균 |
| 다음에 이상적입니다. | 소규모 팀 | 기업 | 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
Husky를 사용한 사전 커밋 후크
# 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에서 어린아이들을 위한 솔루션의 전체 스펙트럼을 살펴보았습니다. 팀에서 고급 규정 준수 요구 사항이 있는 조직을 위한 엔터프라이즈 저장소로 이동합니다.
기억해야 할 기본 원칙은 저장소에 비밀을 커밋하지 말고 레이어를 사용하는 것입니다. 스테이징과 프로덕션을 분리하는 환경, 예방을 위한 사전 커밋 후크 구현, 비밀의 정기적인 순환을 계획하고 항상 비상 절차를 마련하십시오. 누출에 대비해 준비되어 있습니다.
다음 기사에서는 다음 내용에 중점을 둘 것입니다. 성능: 구성하겠습니다 각 배포가 유지 관리되도록 파이프라인에 성능 예산과 Lighthouse CI를 포함합니다. 높은 품질 기준.