Sicurezza dei dati nelle applicazioni web non è solo una questione di scegliere password robuste. Per i team di ingegneria è fondamentale gestire correttamente le chiavi segrete – dalle chiavi API, ai token JWT, fino alle credenziali dei database. In questo articolo presentiamo il modello di minaccia, descriviamo il funzionamento di AWS Secrets Manager e Docker Secrets e mostriamo un’integrazione pratica con il framework Next.js e l’ambiente Node.js. Tutto basato sulle linee guida OWASP A3 – Sensitive Data Exposure e sul principio del least‑privilege.
Modello di minaccia – dove trapelano più spesso i segreti?
In uno stack tipico Next.js/Node.js i segreti possono trapelare a diversi livelli: nel codice sorgente (ad esempio nel repository Git), nelle variabili d’ambiente impostate sul server, nelle immagini Docker e anche nei log dell’applicazione. Un attaccante che ottiene l’accesso a uno di questi elementi può prendere il controllo dei servizi esterni, sostituire dati o eseguire operazioni non autorizzate. Il modello di minaccia prevede tre principali vettori:
- Memorizzazione inappropriata dei segreti nel repository (ad es. in file
.env). - Rivelazione delle variabili d’ambiente nei container Docker, non criptate.
- Mancanza di controllo degli accessi ai servizi di gestione dei segreti (ad es. policy IAM errate in AWS).
Come funziona AWS Secrets Manager?
AWS Secrets Manager è un servizio gestito per l’archiviazione e la rotazione dei segreti. I segreti sono criptati usando KMS e l’accesso è controllato tramite policy IAM. Elementi chiave:
- Encrypt‑at‑rest – ogni segreto è criptato a riposo.
- Secure transmission – l’accesso avviene tramite HTTPS con firma AWS Signature V4.
- Automatic rotation – rotazione opzionale ogni 30‑90 giorni, che riduce la finestra di vulnerabilità.
Nel contesto di Next.js, solitamente recuperiamo i segreti durante l’avvio del server (ad es. con next start) o nelle funzioni API, per non conservarli nel codice.
Docker Secrets nelle applicazioni Node.js
Docker Swarm consente di trasferire in modo sicuro i segreti ai container come file virtuali sotto /run/secrets. I segreti sono criptati a riposo e decriptati nella memoria del container, minimizzando il rischio di perdita tramite lo strato dell’immagine. Nei contesti Kubernetes la funzione analoga è svolta da Secret e sealed‑secrets, ma in questo articolo ci concentriamo su Docker Swarm, poiché si integra naturalmente con il processo di build delle immagini in CI/CD.
Integrazione di AWS Secrets Manager con Next.js
Di seguito presentiamo un esempio minimale di recupero di un segreto da AWS Secrets Manager in un’app Next.js scritta in TypeScript. Supponiamo che il ruolo IAM assegnato all’istanza EC2 o al task ECS abbia i permessi secretsmanager:GetSecretValue per il segreto specificato.
import { SecretsManagerClient, GetSecretValueCommand } from "@aws-sdk/client-secrets-manager";
const client = new SecretsManagerClient({ region: "eu-west-1" });
export async function getDatabaseCredentials() {
const command = new GetSecretValueCommand({
SecretId: "prod/dbCredentials"
});
const response = await client.send(command);
if (!response.SecretString) {
throw new Error("Secret is binary or empty");
}
return JSON.parse(response.SecretString);
}
// Esempio di utilizzo in una route API
export default async function handler(req, res) {
const creds = await getDatabaseCredentials();
// usa creds.username e creds.password per connettersi al DB
res.status(200).json({ status: "ok" });
}
È fondamentale che la chiamata non avvenga durante la fase di build delle pagine statiche (next build), poiché in tal caso il segreto potrebbe essere salvato nell’artefatto di build. Perciò lo recuperiamo solo al momento dell’esecuzione del codice lato server.
Docker Secrets in pratica – Node.js come backend API
nelle applicazioni Node.js eseguite in container Docker, i segreti possono essere montati come file e letti sincronicamente all’avvio dell’applicazione. Esempio di Docker‑Compose che definisce un segreto:
version: "3.8"
services:
api:
image: myorg/api:latest
secrets:
- api_key
environment:
- NODE_ENV=production
command: ["node", "dist/index.js"]
secrets:
api_key:
external: true
Nel codice Node.js leggiamo il segreto:
import fs from "fs";
const apiKey = fs.readFileSync("/run/secrets/api_key", "utf8").trim();
// usa apiKey per le chiamate API esterne
È importante sottolineare che i segreti non compaiono nelle variabili d’ambiente, riducendo il rischio di perdita tramite i log dei processi.
"La migliore protezione dei segreti è non inserirli nel codice – ma solo nei servizi che controllano l’accesso e auditano l’utilizzo."
Checklist‑a di mitigazione – cosa deve fare il team?
- Crea politiche IAM di tipo least‑privilege per l'accesso a segreti specifici.
- Abilita la rotazione automatica in AWS Secrets Manager (ad es. ogni 60 giorni).
- Utilizza Docker Secrets invece delle variabili d'ambiente nei file
.env. - Assicurati che CI/CD non registri i valori dei segreti nei log (mascheramento).
- Esegui audit dell'accesso ai segreti – CloudTrail per AWS, eventi Docker per Swarm.
Errori comuni e compromessi
1. Hard‑coding dei segreti – l'errore più frequente, facilmente individuabile dagli scanner di codice. Usa invece funzioni che recuperano i segreti a runtime.
2. Memorizzazione dei segreti in repository pubblici – anche i valori criptati possono rivelare la struttura dell'applicazione. Usa git‑ignore per i file .env e secrets/.
3. Impostazione di autorizzazioni IAM troppo ampie – concedere AdministratorAccess all'applicazione viola il principio del least‑privilege. Definisci politiche precise.
4. Mancanza di rotazione – i segreti utilizzati per lunghi periodi aumentano il rischio di perdita. Automatizza la rotazione e l'aggiornamento nel codice.
5. Registrazione dei valori dei segreti – alcune librerie eseguono il debug dell'intera configurazione. Disattiva la modalità debug in produzione e maschera i campi sensibili.
Riepilogo e prossimi passi
L'implementazione di una gestione sicura dei segreti nello stack Next.js e Node.js richiede la combinazione di due soluzioni collaudate: AWS Secrets Manager per l'archiviazione centrale e auditabile e Docker Secrets per l'isolamento nei container. Seguendo la checklist, evitiamo le trappole più comuni e soddisfiamo i requisiti OWASP A3 e i principi del least‑privilege. Se hai bisogno di supporto per l'implementazione di questa architettura, l'ottimizzazione CI/CD o un audit di sicurezza, contatta Coderia.it – ti aiuteremo a introdurre le migliori pratiche e a garantire tranquillità al tuo team di ingegneria.
