Cifratura, isolamento, hosting regionale:
sicuro fin dal design.

La cifratura in SDEN è concreta. In transito, ogni endpoint pubblico termina TLS 1.3 con suite di cifratura moderne (ECDHE per lo scambio di chiavi, cifrari AEAD come AES-GCM e ChaCha20-Poly1305), con preload HSTS richiesto dove la proprietà del dominio lo permette. Anche il traffico interno servizio-a-servizio dentro la nostra infrastruttura gestita è cifrato via TLS; non presumiamo che una rete privata sia una rete di fiducia.

A riposo, i dati sono cifrati con AES-256 tramite i servizi di gestione chiavi gestiti dal fornitore cloud (AWS KMS, GCP KMS o equivalente) di default, con chiavi gestite dal cliente (CMK / BYOK) offerte su richiesta per i progetti in cui il modello di minaccia e il contesto normativo lo esigono. Le chiavi sono ruotate secondo un calendario documentato e su richiesta a seguito di ogni cambiamento di accesso. Non consegniamo prodotti che memorizzano segreti in variabili d'ambiente su una sola macchina virtuale chiamandolo "cifrato a riposo": la distinzione conta e la trattiamo come un veto di code review.

L'autenticazione del personale SDEN è imposta da un fattore multiplo ancorato all'hardware (WebAuthn / FIDO2) per ogni account con accesso ai sistemi di produzione, ai dati cliente o al codice sorgente. Il provisioning degli account passa per un processo documentato di ingresso / cambio ruolo / uscita con revisioni di accesso trimestrali. Non ci sono credenziali condivise verso un sistema di produzione; ogni azione è attribuibile a una persona nominata.

Per le applicazioni che consegniamo, il single sign-on tramite OIDC (Google Workspace, Microsoft Entra ID, Okta, Auth0) è l'opzione di default offerta ai clienti enterprise. Dove il single sign-on non è disponibile, l'autenticazione con password è imposta con l'hashing raccomandato dall'OWASP (Argon2id o scrypt), un rate limiting al livello del credential stuffing, e un fattore multiplo obbligatorio per ogni account con portata amministrativa. Il controllo di accesso per ruoli funziona a minimo privilegio; il permesso di default di ogni nuovo ruolo è zero, e ogni concessione è documentata.

I log di audit sono conservati per almeno dodici mesi e sono a prova di manomissione: il flusso di log stesso è in sola aggiunta ed esportato verso una destinazione isolata, così che una compromissione dell'applicazione non possa riscrivere retroattivamente la traccia di audit. PLACEHOLDER: confermare la finestra di conservazione configurata per ogni ambiente prima della pubblicazione.

Il multi-tenant è il punto in cui avviene la maggior parte delle falle di sicurezza dei SaaS, e quasi sempre perché l'isolamento era imposto nel codice applicativo anziché al livello dei dati. L'architettura di default di SDEN lo impone a entrambi. L'identificatore di tenant si propaga nell'applicazione come un tipo obbligatorio (e non un campo opzionale), così che una query che dimentica di restringersi a un tenant è un errore di compilazione TypeScript anziché una fuga di dati a runtime. Al database, le policy di row-level security di PostgreSQL impongono lo stesso confine: anche un account di servizio che si comporta male non può leggere da un tenant all'altro senza una deroga esplicita e auditata.

Dove il modello di minaccia giustifica il costo, consegniamo chiavi di cifratura a riposo per tenant, così che una compromissione a livello di database dei dati di un tenant non possa decifrare quelli di un altro. I backup sono allo stesso modo ristretti per tenant, con la procedura di ripristino documentata e collaudata. La matrice di accesso inter-tenant è testata per integrazione prima di ogni release: ogni endpoint è invocato con le credenziali di un tenant contro i record di un altro, e i rifiuti attesi sono asseriti automaticamente.

La giurisdizione di hosting è una decisione di protezione dei dati, non una decisione di approvvigionamento. Ogni prodotto che consegniamo viene deployato nella regione che il cliente esige, perché la postura SOC 2 / GDPR e l'assenza di meccanismi di trasferimento transfrontaliero sono entrambe più semplici quando i dati non lasciano la loro regione d'origine in primo luogo. I fornitori che usiamo più spesso (AWS (eu-west-1 / eu-west-3 (Parigi)), GCP (europe-west1 / europe-west9 (Parigi)) e Azure nelle regioni UE, Stati Uniti e Svizzera) hanno tutti firmato accordi di trattamento dei dati che possiamo trasmettere ai clienti senza rinegoziazione.

Dove il modello di minaccia o il contesto normativo di un cliente esige un deploy bloccato a una regione (UE, Stati Uniti o Svizzera), lo configuriamo perché resti in quella regione; dove serve un fallback multi-regione, lo configuriamo con confini di residenza documentati. Non cambiamo in silenzio la regione di hosting di un backup o di un nodo edge di CDN senza divulgazione: l'impegno di residenza nel DPA è la residenza in produzione.

I backup sono cifrati (AES-256), eseguiti secondo un calendario adatto all'obiettivo di punto di ripristino (RPO) dei dati, e archiviati in una regione distinta dalla principale, così che un guasto regionale non si porti via il ripristino con sé. PLACEHOLDER: confermare l'RPO configurato e l'obiettivo di tempo di ripristino (RTO) per prodotto prima di ogni pubblicazione esterna: i valori di default tipici sono un RPO ≤ 24 ore e un RTO ≤ 8 ore per i prodotti SaaS che SDEN gestisce.

Le procedure di ripristino sono collaudate. Un backup che non è mai stato ripristinato è una speranza, non un piano di ripristino; conduciamo esercizi di ripristino periodici contro un ambiente di staging e ne documentiamo l'esito. Quando consegniamo un prodotto a un cliente, la guida di ripristino fa parte del deliverable.

Sicuro fin dal design non è uno slogan in SDEN; è un insieme di pratiche imposte dalla stessa pipeline di continuous integration che esegue la suite di test. In fase di design di ogni progetto, il modello di minaccia è messo per iscritto: gli asset che proteggiamo, gli avversari da cui li proteggiamo, i confini di fiducia attraverso cui transitano i dati. Il risultato orienta le decisioni di architettura, il modello di controllo di accesso e le scelte di dipendenze.

Nella pipeline, ogni pull request esegue un'analisi della composizione del software (SCA) contro l'albero delle dipendenze per individuare i pacchetti con vulnerabilità note, test statici di sicurezza applicativa (SAST) contro il codice per i pattern dell'OWASP Top 10, e un rilevamento dei segreti per assicurarsi che credenziali non atterrino mai nel repository. La protezione dei branch esige una build riuscita e l'approvazione di un revisore prima del merge; i commit firmati sono richiesti sul branch principale; le immagini di container sono analizzate e le immagini di base sono ancorate a un tag mantenuto secondo una cadenza di refresh documentata.

Le vulnerabilità di sicurezza trovate in software costruito da SDEN possono essere segnalate in modo confidenziale a security@sden.ai (vedi la sezione di contatto qui sotto). Ci impegniamo a una finestra di risposta definita: un accuso di ricezione entro un giorno lavorativo, un primo triage entro tre giorni lavorativi, e un calendario di divulgazione coordinata concordato con chi segnala prima di ogni comunicazione pubblica.

Internamente, gli incidenti seguono un processo di risposta documentato: un solo incident commander è nominato alla dichiarazione, la comunicazione passa per un canale dedicato con aggiornamenti datati, un aggiornamento di stato destinato al cliente è pubblicato quando l'impatto è visibile al cliente, e un post-mortem scritto è prodotto entro dieci giorni lavorativi dalla risoluzione. Il post-mortem è senza colpa, nomina i fattori contribuenti, e arriva con item d'azione tracciati nello stesso backlog del lavoro di funzionalità. Gli incidenti gravi attivano una notifica ai clienti colpiti con la tempistica e la correzione, in conformità alla finestra di notifica di violazione applicabile (GDPR, 72 ore all'autorità di controllo) dove pertinente.