Ogni web app aziendale che funziona davvero — non un semplice sito vetrina — ha bisogno di parlare con altri sistemi: un database, un servizio di pagamento, un’API esterna, una casella email, un server di backup. Per farlo usa credenziali: password, chiavi API, token, certificati. La gestione dei secrets è il modo in cui queste credenziali vengono create, distribuite, ruotate e protette lungo tutto il ciclo di vita dell’applicazione. Farlo male è uno degli errori più comuni — e più pericolosi — che vedo quando prendo in carico l’infrastruttura di un cliente.
Cosa sono davvero i secrets in una web app aziendale
Un secret è qualsiasi informazione che, se finisse nelle mani sbagliate, permetterebbe a qualcuno di accedere a dati o servizi che non dovrebbe. Nella pratica quotidiana di sviluppo di una web app significa:
- Credenziali del database (utente, password, stringa di connessione)
- Chiavi API di servizi terzi (pagamenti, email transazionali, mappe, AI)
- Token di autenticazione tra microservizi
- Chiavi private per firmare sessioni utente (JWT secret) o certificati SSL
- Chiavi SSH per il deploy automatico sui server
Il problema non è avere questi dati — è impossibile farne a meno — ma dove e come vengono conservati. Ho visto, non di rado, chiavi API scritte direttamente nel codice sorgente e finite su repository pubblici, oppure password condivise via chat aziendali senza alcun controllo su chi le abbia lette.
L’errore più comune: secrets nel codice
Il primo passo di una gestione dei secrets aziendali corretta è semplice da enunciare e spesso trascurato nella fretta: nessuna credenziale deve mai comparire nel codice sorgente, nei commit Git o nei log dell’applicazione. Quando sviluppo una web app, che sia un gestionale come apicco.app o una piattaforma di prenotazioni come indelio.eu, separo sempre in modo netto il codice dalla configurazione:
- Le variabili d’ambiente (file
.env, mai committato, con relativo.env.examplecome traccia per il team) contengono i valori reali solo sull’ambiente di produzione. - I container Docker ricevono i secrets tramite variabili d’ambiente iniettate a runtime o tramite Docker secrets, mai “bakati” dentro l’immagine.
- Un
.gitignoreben configurato blocca a monte qualsiasi rischio di commit accidentale.
Questa disciplina sembra banale finché non si scopre — troppo tardi — che una chiave API è rimasta esposta per mesi in uno storico Git pubblico, anche dopo essere stata “rimossa” dall’ultimo commit.
Rotazione, permessi minimi e ambienti separati
Un secret statico che non cambia mai è un rischio che cresce nel tempo: più tempo passa, più persone e sistemi lo hanno visto, più è probabile che finisca da qualche parte in cui non dovrebbe essere. Nelle infrastrutture che gestisco applico tre criteri:
Rotazione periodica
Le chiavi API e le password dei servizi critici vanno rigenerate a intervalli regolari, e immediatamente ogni volta che una persona con accesso lascia il progetto o l’azienda.
Permessi minimi (least privilege)
Ogni chiave dovrebbe poter fare solo quello che serve. Una chiave usata per leggere dati analytics non deve avere anche permessi di scrittura sul database di produzione. Quando configuro l’accesso SSH ai server — che gestisco tramite HestiaCP, Docker e Portainer — ogni servizio ha il proprio utente con permessi ristretti, mai un unico account root condiviso.
Ambienti separati
Sviluppo, staging e produzione devono avere credenziali diverse. Una chiave di test compromessa non deve mai poter toccare dati reali di clienti.
Dove conservare i secrets in pratica
Per progetti di piccole e medie dimensioni, un approccio solido e sostenibile combina alcuni strumenti concreti, senza bisogno di infrastrutture complesse quanto quelle delle grandi aziende:
- Variabili d’ambiente gestite a livello di server, con accesso ristretto via SSH con chiavi (mai password) e permessi file a 600.
- Secrets manager Docker/Portainer per orchestrare container che hanno bisogno di credenziali diverse senza esporle nei log dei deployment.
- Backup cifrati delle configurazioni sensibili, separati dai backup applicativi ordinari.
- Reverse proxy con SSL automatico per garantire che anche il traffico che trasporta questi dati sia sempre cifrato end-to-end.
Per un cliente con più applicazioni interconnesse — penso a un caso come tandemops.app, dove PSA, RMM e CRM condividono dati e devono autenticarsi a vicenda — questa disciplina diventa ancora più importante: un solo punto debole nella gestione delle credenziali può compromettere l’intero ecosistema di strumenti collegati.
Perché questo lavoro non si vede, ma conta
La gestione dei secrets è, per definizione, un lavoro invisibile quando fatto bene: nessuno se ne accorge finché non succede un incidente. È esattamente per questo che va progettata fin dall’inizio, non aggiunta in fretta dopo un problema. Quando sviluppo una web app per un cliente, non mi limito a scrivere il frontend e il backend: penso all’infrastruttura che la ospita, alla cifratura dei dati in transito e a riposo, ai backup, e — appunto — a come vengono trattate le credenziali che tengono insieme tutto il sistema. È lo stesso approccio “full-stack, end-to-end” che applico su ogni progetto che gestisco, dai siti WordPress su misura alle applicazioni self-hosted come cloud.cornelcaba.com.
Serve una web app costruita bene, anche sotto il cofano?
Se la tua azienda ha bisogno di una web app su misura — o vuole verificare che l’infrastruttura esistente sia davvero sicura — posso occuparmene io, dallo sviluppo del codice alla gestione dei server, dei backup e delle credenziali che la fanno funzionare in sicurezza. Contattami per parlare del tuo progetto, oppure dai un’occhiata a cornelcaba.com per vedere altri esempi di applicazioni che ho sviluppato e che gestisco ogni giorno.
