Gestione dei file .env in produzione: pattern sicuri per Laravel e Symfony

Il 3 ottobre 2025 mi ha chiamato d'urgenza il CTO di una società lombarda attiva nel settore delle soluzioni software per la grande distribuzione, con un fatturato annuo di circa 8,4 milioni di euro e una piattaforma SaaS multi-tenant sviluppata in Laravel 11 che serve 28 catene di supermercati in Italia e nei Balcani. La situazione era grave: poche ore prima era stato rilevato un accesso anomalo alla base dati di uno dei clienti più importanti - un retailer italiano con 180 punti vendita - e la prima ipotesi del team interno era di un attacco compromissivo. L'audit tecnico d'urgenza che abbiamo fatto nelle 48 ore successive ha rivelato una verità molto più prosaica e molto più imbarazzante: il file .env del progetto era stato committato per errore in un repository privato GitLab aziendale circa 14 mesi prima, mai rimosso dalla history. Un ex-sviluppatore che aveva lasciato l'azienda quattro mesi prima aveva ancora accesso al repository perché il processo di deprovisioning degli account GitLab non era stato applicato completamente al momento del suo addio, aveva clonato il repository per "riferimento personale" il mese successivo, e quattro mesi dopo aveva utilizzato una delle credenziali di produzione ancora valide (la password del database MySQL del cliente, mai ruotata dal giorno del commit iniziale) per eseguire query di esplorazione del database dall'esterno. Le sue intenzioni rimangono incerte - l'ex-sviluppatore ha negato qualunque intento doloso sostenendo di "aver dimenticato" di avere ancora i file - ma l'esposizione era reale e grave.

Il CTO aveva davanti quattro emergenze simultanee da gestire in parallelo nelle prime 72 ore: notifica formale al cliente del retailer compromesso, notifica al Garante Privacy ai sensi dell'articolo 33 GDPR, cambio di tutte le credenziali di produzione di quel cliente specifico, audit completo di tutti gli altri 27 clienti del parco per verificare se lo stesso pattern di esposizione fosse presente. In sei giornate di lavoro intensive distribuite nelle prime due settimane dall'incidente, e ulteriori 14 giornate di consolidamento distribuite nel mese successivo, abbiamo condotto l'audit completo del parco clienti (ne sono emersi altri 3 con credenziali in .env committati non ruotate, fortunatamente mai utilizzate da attaccanti), ricostruito da zero l'intera gestione dei secrets dell'azienda sostituendo il pattern .env legacy con HashiCorp Vault self-hosted su infrastruttura dedicata, implementato un processo automatico di rotazione delle credenziali ogni 90 giorni, costruito una pipeline CI/CD che impedisce strutturalmente il commit accidentale di file contenenti secrets, e prodotto la documentazione formale per la notifica al Garante Privacy e ai clienti coinvolti. Il provvedimento del Garante emesso cinque mesi dopo ha chiuso l'istruttoria con prescrizione formativa ma senza sanzione pecuniaria - grazie alla tempestività e completezza della risposta tecnica dell'azienda. Il cliente retailer compromesso è stato mantenuto con un adeguamento contrattuale che includeva un'indennità transazionale per il disagio. Il costo complessivo dell'intervento è stato circa 42.000 euro di consulenza più costi di infrastruttura Vault per circa 180 euro/mese.

Questo articolo è il playbook operativo per una gestione strutturata dei file .env e dei secrets applicativi in contesti PHP di produzione. Il principio guida è uno, molto semplice: il file .env nudo in un repository non è accettabile come strategia di secrets management per un'applicazione in produzione nel 2026. Non lo è legalmente (GDPR, NIS2, ISO 27001), non lo è tecnicamente (rotazione complessa, niente audit, rischio di leak), non lo è operativamente (nessuna separazione fra ambienti, niente emergency revocation). L'articolo descrive i pattern alternativi che applico in contesti PMI italiane, calibrati sulla dimensione e sulla capacità organizzativa del team.

Perché il file .env in repository è la vulnerabilità di sicurezza più diffusa nelle PMI tech italiane

Il pattern .env - il file di testo con coppie chiave-valore che ha reso popolare le twelve-factor app - è stato introdotto nel 2011 con le migliori intenzioni architetturali. L'idea originale, documentata nella factor III della metodologia twelve-factor, era semplice e corretta: separare la configurazione dal codice, iniettarla via environment variable, permettere la stessa codebase di funzionare in sviluppo, staging e produzione cambiando solo il .env. Il pattern è perfetto per lo sviluppo locale, dove ogni sviluppatore ha il suo .env con credenziali di sviluppo nel suo checkout, e per ambienti containerizzati semplici dove l'orchestratore inietta variabili d'ambiente dalla configurazione del cluster. Il problema è che Laravel, Symfony e molti altri framework PHP hanno normalizzato l'uso del file .env come meccanismo di configurazione anche in produzione, creando un anti-pattern pervasivo.

Gli errori concreti che trovo nell'80% dei subentri di applicazioni PHP in produzione per PMI italiane sono sempre gli stessi cinque. Primo errore: .env committato sul repository, tipicamente tramite un commit iniziale fatto prima di aggiungere la riga .env al .gitignore, e poi dimenticato nella git history nonostante successive rimozioni dal filesystem. Secondo errore: permessi filesystem errati, il file .env creato con permessi 644 (leggibile da chiunque) invece di 600 (leggibile solo dall'utente proprietario), esponibile a qualunque utente non-root del server. Terzo errore: stessi secrets per staging e produzione, perché "tanto è solo staging" - salvo che staging abbia meno difese e l'attaccante che compromette staging ottiene credenziali che funzionano anche in produzione. Quarto errore: secrets mai ruotati, le credenziali del .env restano identiche dal giorno zero del progetto per anni, con accesso cumulativo di tutti gli sviluppatori passati attraverso il progetto. Quinto errore: nessun audit trail su chi accede al .env, nessun monitoring di accessi anomali, nessun meccanismo di emergency revocation quando un collaboratore lascia l'azienda.

La conseguenza cumulativa di questi errori è che il file .env diventa il single point of failure della security posture aziendale: compromettere quel file significa compromettere l'intero sistema. Nel caso del cliente lombardo, un singolo commit errato di 14 mesi prima più un singolo ex-sviluppatore con accesso residuo al repository hanno messo a rischio l'integrità di dati di un cliente enterprise. La probabilità che questo scenario si realizzi non è trascurabile - la mia esperienza dice che una PMI tech italiana che non applica pratiche strutturate di secrets management ha probabilità cumulativa del 40-60% di subire un incidente simile in un periodo di 5 anni. Nel settore che ha obblighi di conformità NIS2 (dal 2024 la platea si è allargata a gran parte delle PMI di servizi digitali e IT), il rischio regolamentare aggiunge un moltiplicatore significativo al rischio tecnico.

Se stai valutando un audit della tua attuale gestione dei secrets o ti trovi in una situazione post-incidente simile, nel mio profilo professionale trovi il dettaglio degli interventi di secrets management e incident response che ho condotto in contesti PMI italiane, sempre con approccio pragmatico e tempi di implementazione compatibili con le emergenze reali.

Tre livelli di gestione dei secrets per PMI: dal minimo accettabile al production-grade

Non tutte le PMI hanno le stesse esigenze, lo stesso budget, e lo stesso livello di rischio. La strategia che applico nei miei progetti distingue tre livelli di maturità nella gestione dei secrets, ognuno applicabile a un profilo di cliente diverso, con escalation naturale nel tempo man mano che l'azienda cresce e i suoi obblighi regolatori si intensificano.

Livello 1 - Minimo accettabile per PMI sotto i 15 dipendenti tecnici: mai committare .env in repository (riga .env obbligatoria in .gitignore, pre-commit hook di git-secrets o detect-secrets che blocca i commit contenenti chiavi API o pattern di password), file .env su server di produzione con permessi 600 e owner = utente applicativo, rotazione manuale delle credenziali ogni 180 giorni con procedura documentata, separazione netta dei secrets fra sviluppo, staging, produzione (mai condividere valori fra ambienti), deprovisioning completo degli account di collaboratori che lasciano l'azienda entro 24 ore. Questo livello si implementa in 2-3 giornate di lavoro e non richiede infrastruttura aggiuntiva.

Livello 2 - Gestione strutturata per PMI fra 15 e 50 dipendenti tecnici: adozione di un secrets manager dedicato che vive separato dal repository e dal server applicativo. Le opzioni più pragmatiche sono AWS Secrets Manager (per chi è già su AWS), Azure Key Vault (per chi è su Microsoft 365), HashiCorp Vault self-hosted (per chi preferisce autonomia e controllo europeo). L'applicazione non ha più un file .env statico: al boot, una shell script o il supervisor del container fa fetch dei secrets dal vault tramite credenziali di accesso ridotte, li scrive in memoria, li passa al processo PHP come environment variable. Rotazione automatica ogni 90 giorni. Audit log centralizzato di ogni fetch dei secrets. Questo livello si implementa in 10-15 giornate di lavoro.

Livello 3 - Production-grade per PMI sopra i 50 dipendenti tecnici con requisiti di compliance elevati: aggiunge al livello 2 zero-trust architecture (ogni applicazione ha la sua identity unica verificata crittograficamente, non una credenziale condivisa), short-lived secrets (i token di accesso scadono in minuti e vengono rinnovati automaticamente), break-glass procedure documentata per emergency access con audit doppio, integrazione con SIEM aziendale per monitoring continuo, compliance documentation pronta per audit ISO 27001 o SOC 2. Questo livello richiede tipicamente 25-40 giornate di lavoro iniziale più governance operativa continua.

Per il cliente lombardo, la scelta è stata Livello 2 - HashiCorp Vault self-hosted su server Hetzner dedicato in VPC privata con le applicazioni PHP, con rotazione automatica a 90 giorni. L'aggiunta di Livello 3 è pianificata per il 2026 in corrispondenza dell'ingresso dell'azienda nel perimetro NIS2 come fornitore di servizi gestiti. L'implementazione tecnica del layer di accesso dal codice Laravel usa il pattern di fetch-at-boot via script bash che popola environment variable, approccio robusto e compatibile con i pattern corretti per Docker Compose in produzione su VPS che ho descritto in un articolo dedicato, dove la gestione sicura dei secrets via Docker Secrets è integrata nativamente nel compose file.

Prevenzione strutturale del commit accidentale: pre-commit hook, secret scanning, policy di repository

Una volta consolidata l'architettura di secrets management basata su vault esterno, il passo successivo è prevenire strutturalmente il commit accidentale di secrets nel repository. La regola operativa è: nessuno sviluppatore può committare un file contenente pattern di secret, nemmeno se lo vuole esplicitamente, senza override consapevole documentato. Questa prevenzione si implementa su tre livelli di difesa in profondità.

Livello A: pre-commit hook locale installato via pre-commit framework Python sull'ambiente di sviluppo di ogni sviluppatore. Ogni git commit esegue automaticamente gitleaks o detect-secrets sui file modificati, rileva pattern come chiavi API AWS, token GitHub, password in chiaro, e blocca il commit se trova match sospetti. Lo sviluppatore riceve un messaggio esplicito e può fixare o bypassare con --no-verify solo se ha giustificazione (e il bypass va tracciato). Livello B: server-side hook nel remote GitLab/GitHub/Bitbucket che ripete la scansione al push - protezione contro sviluppatori che hanno disabilitato i pre-commit hook locali. Ogni push contenente secrets viene rigettato con messaggio esplicito. Livello C: secret scanning continuo dell'intero history del repository, via gitleaks schedulato settimanalmente sulla history completa, che rileva secrets già committati in commit storici che nessun livello precedente ha catturato. Quando il livello C trova match, genera un ticket con severity ALTA e il flusso di remediation parte - rotazione della credenziale compromessa, rewrite della git history per rimuovere lo storico, audit log.

La documentazione ufficiale di Gitleaks sul suo repository GitHub copre in dettaglio la configurazione e le regole disponibili. Per il cliente lombardo, l'implementazione di questa difesa in tre livelli è stata una delle componenti dell'intervento post-incidente, ed è stata il modo concreto con cui abbiamo dato garanzia al cliente finale (e al Garante) che l'incidente non si sarebbe ripetuto. Il pattern di CI/CD sicuro per proteggere le pipeline da attacchi di injection e supply chain che ho descritto in un articolo dedicato copre in dettaglio l'integrazione di questi hook nella pipeline continua.

Rotazione dei secrets: il processo operativo che separa la conformità dal security theater

La rotazione periodica dei secrets è il pattern più sottovalutato della gestione di produzione. In teoria tutti sanno che i secrets vanno ruotati; in pratica l'85% delle PMI non lo fa sistematicamente perché l'operazione manuale è fragile (rischio di rompere l'applicazione a metà rotazione, necessità di coordinamento operativo) e rimane in coda alle priorità finché non arriva un incidente a forzarla. La soluzione è automatizzare la rotazione, rendendola un'operazione schedulata e sicura che il team non deve ricordarsi di fare.

Il pattern di rotazione automatica che ho implementato per il cliente lombardo è il seguente. Per ogni secret gestito da Vault, è configurata una rotation policy con periodo (90 giorni nel loro caso) e procedura specifica. Per le credenziali di database, Vault crea credenziali dinamiche via backend Database Secrets Engine - invece di avere una singola credenziale statica ruotata periodicamente, ogni applicazione riceve credenziali temporanee uniche generate al volo con TTL di 24 ore, rinnovate automaticamente. Per le credenziali statiche che non possono essere generate dinamicamente (API key di provider esterni, HMAC key condivise con partner), la rotazione è un job schedulato che genera il nuovo secret, lo deposita in Vault, attende un periodo di grazia di 10 minuti per permettere a tutte le istanze applicative di aver fatto fetch del nuovo valore, poi invalida il vecchio secret presso il provider esterno. Questo pattern di "doppio secret valido temporaneamente" elimina il downtime durante la rotazione.

Il risultato finale dell'intervento sul cliente lombardo, misurato a sei mesi dal go-live del nuovo sistema, è stato il seguente. Zero commit accidentali di secrets nei sei mesi di operatività (catturati in pre-commit hook: 14 tentativi, tutti bloccati). Rotazione automatica completata su tutti i 38 secrets gestiti dal vault, con zero downtime operativo. Audit trail completo di 142.000 fetch di secrets registrati e archiviati. Provvedimento del Garante chiuso con archiviazione del procedimento sanzionatorio. Cliente retailer mantenuto in portafoglio con rinnovo contrattuale. Costi operativi infrastrutturali aggiuntivi: 180 euro/mese per il Vault self-hosted. Costo consulenziale dell'intervento: 42.000 euro. Sanzione potenziale evitata: stimata fra 250.000 e 700.000 euro sulla base del fatturato aziendale. ROI puramente difensivo: oltre 6x sulla prima annualità, senza contare il valore strategico del rapporto mantenuto con il cliente retailer.

Se guidi una PMI tech italiana che gestisce dati di clienti enterprise o sensibili e non hai ancora implementato un sistema strutturato di gestione dei secrets al di là del file .env, ti trovi in una posizione di rischio silente che si materializza violentemente al primo incidente. L'implementazione proattiva costa significativamente meno dell'intervento post-incidente, ed è un prerequisito di qualunque certificazione professionale o compliance formale a cui voglia aspirare la tua azienda. Se vuoi confrontarti su una valutazione tecnica del tuo attuale livello di maturità nella gestione dei secrets con un piano di miglioramento prioritizzato sul rischio reale del tuo contesto, contattami per una consulenza preliminare: in una mezza giornata di analisi guidata produciamo insieme un audit dei tuoi attuali pattern di secrets management, un'identificazione precisa dei punti di esposizione più critici, e una roadmap calibrata sui tre livelli di maturità che ho descritto, con stime realistiche di tempo e budget per il tuo contesto specifico.