Secret Management: Il Problema dei Segreti nel Software
I secret (credenziali, API key, certificati, token di accesso) sono gli elementi più sensibili di un'infrastruttura software. Un singolo secret esposto può compromettere interi sistemi, database e account cloud. Secondo le ricerche di GitGuardian, nel 2024 sono stati trovati oltre 12 milioni di secret esposti nei repository pubblici su GitHub.
Il secret management non e solo "non committare le password nel codice". E un sistema completo che copre la generazione, lo storage sicuro, la distribuzione, la rotazione e la revoca dei secret durante tutto il loro ciclo di vita.
Cosa Imparerai
- Architettura di un sistema di secret management
- HashiCorp Vault: setup, configurazione e integrazione
- AWS Secrets Manager e alternative cloud
- Strategie di rotazione automatica delle credenziali
- Secret detection nei repository con GitLeaks e TruffleHog
- Anti-pattern comuni e come evitarli
Anti-Pattern: Come NON Gestire i Secret
Prima di esplorare le soluzioni, vediamo gli errori più comuni che portano all'esposizione di credenziali:
- Hardcoded nel codice: password e API key scritte direttamente nel codice sorgente
- File .env nel repository: file di configurazione con secret committati per errore
- Variabili d'ambiente non protette: secret passati come env var senza encryption
- Secret condivisi via chat: credenziali inviate su Slack, Teams o email
- Secret mai ruotati: credenziali statiche che non vengono mai cambiate
- Permessi troppo ampi: API key con accesso a tutti i servizi invece del minimo necessario
Il Costo di un Secret Esposto
Un secret esposto in un repository pubblico viene scoperto dai bot automatici in media entro 24 secondi. In meno di un minuto, attori malevoli possono iniziare a sfruttare la credenziale. Il tempo medio per la remediation nelle organizzazioni senza processi automatizzati e di 327 giorni.
HashiCorp Vault: Il Reference Standard
HashiCorp Vault e la soluzione più diffusa per il secret management enterprise. Offre storage sicuro, accesso controllato, audit logging e supporto per la rotazione dinamica dei secret. Vault può generare credenziali on-demand con TTL limitato, eliminando il problema dei secret statici.
Setup Vault con Docker
# 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:
Operazioni Base con 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
Dynamic Secrets: Credenziali On-Demand
Una delle feature più potenti di Vault sono i dynamic secrets: credenziali generate al momento della richiesta con un TTL limitato. Quando il TTL scade, Vault revoca automaticamente le credenziali. Questo elimina il problema dei secret statici.
# 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 Secrets Manager
Per le organizzazioni che operano su AWS, AWS Secrets Manager offre un servizio managed per il secret management con rotazione automatica integrata, supporto nativo per RDS, Redshift e DocumentDB, e integrazione trasparente con i servizi AWS.
Confronto Secret Management Solutions
- HashiCorp Vault: multi-cloud, self-hosted o managed (HCP), massima flessibilità
- AWS Secrets Manager: nativo AWS, rotazione automatica RDS, semplice da usare
- Azure Key Vault: nativo Azure, integrazione con AD, HSM support
- GCP Secret Manager: nativo GCP, IAM integration, versioning
- Kubernetes Secrets: base64 encoded (non criptato!), usare con external-secrets-operator
Secret Detection nei Repository
La prevenzione e la prima linea di difesa. Gli strumenti di secret detection analizzano il codice alla ricerca di credenziali esposte prima che raggiungano il repository remoto.
GitLeaks: Pre-Commit Hook
# .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'''
]
Integrazione in 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: