Ti sposti una versione in uscita di notte, scorri le tue notifiche e notizie, e noti un credenziale che non avrebbe mai dovuto lasciare un repository privato. Forse era una password del database. Forse era una chiave di accesso cloud con permessi più ampi di quelli che qualcuno intendeva. Comunque sia, il problema non è solo che qualcuno potrebbe accedere. Il problema è che la sicurezza dei database continua a essere trattata come un problema di accesso quando in realtà è un problema di ciclo di vita dell'archiviazione.
Questo si verifica in tutti i sistemi reali. Le squadre abilitano l'encryption una volta e si aspettano di essere finite. Conservano i backup ma non li testano per il ripristino. Creano un account di servizio amministrativo per comodità e dimenticano che esiste. Bloccano la produzione, poi lasciano la fase di staging piena di dati dei clienti copiati. Se stai costruendo app mobili o web, l'archiviazione dei dati in modo sicuro deve coprire tutto: il database principale, le copie, gli esporti, i log, i backup e le chiavi che controllano tutto il resto.
Se anche stai lavorando attraverso Solving auth per il tuo prossimo app, ricorda che l'autenticazione e la sicurezza di archiviazione risolvono modi di fallimento diversi. L'autenticazione decide chi dovrebbe entrare. La sicurezza di archiviazione limita i danni quando qualcuno fa, o quando i dati si infiltrano attraverso un percorso che non ti aspettavi. Per le squadre che stanno spedito app faccia a faccia con i clienti, è anche utile allineare le decisioni di archiviazione con i controlli adiacenti come API standard di sicurezza per la conformità degli store app.
L'urgenza non è teorica. La produzione globale dei dati raggiunse 64,2 zettabyte nel 2020 e fu proiettato a salire a 180 zettabyte entro il 2025 secondo Edge Delta's data storage summary. A quel livello, la sicurezza di archiviazione smette di essere un compito di hardening e diventa architettura.
Tavola dei Contenuti
- Ragione per cui la sicurezza del database è più di una semplice password
- Capire il modello di minaccia del tuo database
- I pilastri fondamentali della memorizzazione dei dati sicuri
- Modelli di implementazione pratici per l'encryption
- Gestione della chiave e della chiave segreta
- Progettare una strategia di backup e ripristino resiliente
- Checklist del sviluppatore per la memorizzazione di database sicura
- Domande frequenti
Perché la sicurezza del database è più di una semplice password
Una password protegge un punto di accesso. Non protegge i dati dopo che un credenziale viene rubato, una snapshot viene copiata o un servizio interno con privilegi troppo ampi inizia a leggere le tabelle che non era mai destinato a toccare. È per questo che la memorizzazione dei dati deve essere stratificata.
Il vecchio modello mentale era semplice: mettere il database dietro un firewall, richiedere una forte password e tenere lontani gli esterni. Questo modello si rompe nei sistemi cloud, nei backend mobili e nelle pipeline CI/CD moderne. I dati si muovono tra i servizi. Gli ingegneri creano esportazioni temporanee. Le attività di analisi duplicano i record. I sistemi di backup conservano copie su infrastrutture diverse. Gli attaccanti non devono rompere l'engine del database stesso se possono rubare una chiave, abusare di un token API o trovare una replica con controlli più deboli.
La sicurezza fallisce nelle vie tranquille
Le maggiori insicurezze di memorizzazione non sembrano drammatiche all'inizio. Sembrano ordinarie.
- Un comfort per lo sviluppatore diventa un rischio di produzione: Un credenziale di amministrazione condiviso viene riutilizzato da uno script perché rotarlo sarebbe rotto la distribuzione.
- A un dataset copiato sfugge al controllo: Le registrazioni di produzione vengono copiate nel ambiente di staging affinché la QA possa riprodurre un bug.
- Un backup diventa il punto debole: La produzione ha controlli robusti, ma la politica del bucket di ripristino o la politica delle snapshot non lo sono.
Regola pratica: Se l'unico ostacolo tra un attaccante e dati leggibili è un solo credenziale, non hai un storage sicuro. Hai un punto di fallimento unico.
La difesa deve sopravvivere all'abuso dei credenziali
La guida di Microsoft per le nuvole raccomanda una baseline che include l'encryption in transito e in stato di riposo, controlli di accesso con privilegi minimi e monitoraggio dell'attività non autorizzata, come descritto nelle sue pratiche di sicurezza dei dati nelle nuvole. Questa è la baseline giusta perché gli incidenti reali spesso iniziano con l'accesso valido utilizzato in modo sbagliato.
Cosa funziona in pratica è noioso e coerente. Cifra i file del database. Cifra le connessioni. SPLITTA I RUOLI DEI SERVIZI. Rimuovi l'accesso amministrativo permanente dove puoi. Registra le operazioni sensitive. Allerta sui modelli di accesso che non corrispondono all'uso normale. Nessuna di queste cose è glamour, ma previene vere violazioni.
Un modo utile per pensarci è un deposito di sicurezza fisico. La porta del deposito conta. Lo stesso vale per le serrature delle cassette, la telecamera, il registro dei visitatori e la politica per chi può aprire quale cassetta. Il storage del database sicuro funziona nello stesso modo. Le password sono solo la porta d'ingresso.
Modellare il tuo modello di minaccia per il database
Prima di scegliere i controlli, mappa le modalità in cui il tuo sistema può fallire. Un modello di minaccia per il database di archiviazione non deve essere accademico. Deve dirti chi potrebbe toccare i dati sensibili, come lo farebbe e cosa accadrebbe se riuscisse.
I dati sensibili vivono raramente in un unico database di produzione ordinato. Le linee guida moderne enfatizzano la scoperta e la gestione della postura perché l'informazione sensibile finisce spesso in copie, backup, log e ambienti di sviluppo, quindi i fallimenti avvengono spesso al di fuori del database primario, come notato in L'overview di Sentra sulla sicurezza dei dati in cloud e sulla gestione della postura. Quindi, il piano di incidente dovrebbe includere scenari come l'esposizione del fornitore e i dataset copiati. Questo è anche dove diventano pertinenti i libri di risposta più ampi, come Le migliori pratiche di risposta a una violazione di terze parti.
Inizia con gli asset, non con gli strumenti
Elencare ciò che conta prima di elencare i prodotti.
Gli asset critici per la maggior parte delle squadre di app sono chiari:
- Registro dei clienti ad esempio profili, storia degli ordini, metadati relativi ai pagamenti o contenuti relativi alla salute.
- Materiali di autenticazione ad esempio hash delle password, registri delle sessioni, token di refresh o API segreti.
- Dati operativi ad esempio registri di audit, code delle attività, note degli amministratori e esportazioni di supporto.
- Gli asset di recupero ad esempio snapshot, dump logici, registri a un punto nel tempo e chiavi di cifratura.
L'ultimo elemento conta più di quanto i team pensino. Se un attaccante può cancellare i backup o accedere alle chiavi che li decrittografano, la tua storia di recupero si sgretola.
Gli ultimi tre contenitori di minaccia che contano di più
Un modello semplice che utilizzo con gli sviluppatori ha tre contenitori.
Attaccanti esterni
Questo è il contenitore di cui tutti parlano per primo. Iniezione SQL, token API rubati, credenziali cloud divulgate, pannelli amministrativi esposti, dipendenze vulnerabili. Il filo conduttore è un outsider che ottiene un percorso per i dati.
Domande da porre:
- Qualcuno potrebbe interrogare il database indirettamente attraverso l'applicazione?
- Un credenziale di server rubato può leggere più di un servizio richiede?
- Una copia di snapshot sarebbe leggibile da solo?
Minacce interne
Ciò include gli insider malintenzionati e i dipendenti ben intenzionati con troppo accesso. Un ingegnere di supporto esporta dati per risolvere un ticket. Un contrattista mantiene una copia locale. Un amministratore di piattaforma può leggere righe di produzione anche se il suo lavoro non lo richiede.
Ciò che aiuta qui è la separazione delle funzioni, l'accesso basato su ruoli e i registri di audit che rendono visibili le letture sensibili.
Se non puoi rispondere a chi ha accesso a un record del cliente, quando l'ha accesso e perché quel accesso è stato consentito, i tuoi controlli di database sono più deboli di quanto sembri.
Esposizione accidentale
Questo è la categoria più comune nelle squadre che si muovono velocemente. Un bucket di archiviazione configurato male. Un ambiente di staging seedato con dati in tempo reale. Log di debug che includono token o informazioni personali. Un backup ripristinato collocato in un ambiente di bassa sicurezza per il troubleshooting.
L'esposizione accidentale è il motivo per cui la sicurezza dei dati deve essere operativa. Non la risolvi con una sola impostazione. La risolvi con la classificazione dei dati, i guardiani, la revisione e la pulizia di routine.
I Pilastri fondamentali della sicurezza di archiviazione dei database
A una rottura rara non viene da un fallimento drammatico. Di solito proviene da una catena di errori ordinari. Un backup viene copiato nella cattiva account. Un servizio ottiene permessi più ampi di quelli che necessita. Una vecchia chiave rimane attiva per mesi perché la rotazione è stata continuamente rimandata. La memorizzazione dei dati in database deve interrompere quella catena in diversi punti, e continuare a farlo mentre il sistema cambia.
Raggruppo il lavoro in quattro pilastri: crittografia, controllo di accesso, auditing e minimizzazione. La sicurezza dei backup e della ripristino sono importanti, ma meritano un trattamento operativo separato perché i dati ripristinati spesso diventano un nuovo percorso di esposizione se nessuno verifica dove finisce, chi può leggerlo e quali chiavi possono decrittificarlo.
La crittografia riduce il valore dei dati rubati
La crittografia acquista tempo e riduce l'impatto. Se qualcuno ottiene un disco snapshot, un file di backup raw o traffico su una rete interna, i dati crittografati sono molto più difficili da trasformare in registri dei clienti.
In riposo, la crittografia protegge i file di database, i snapshot e gli artefatti di backup. In transito, TLS protegge le connessioni tra i server di applicazione, i proxy e il motore di database. Il NIST affronta entrambi i controlli nella sua guida sulla crittografia dei dati in riposo e sulla protezione dei dati in transito in SP 800-111 e raccomandazioni correlate La crittografia riduce l'impatto di un attacco.
La trade-off è operativa, non teorica. L'encryption aiuta solo se il trattamento delle chiavi è separato dal percorso dei dati e mantenuto nel tempo. L'encryption dell'invio funziona come una chiave master per l'edificio e una chiave ufficio chiusa. Un servizio di gestione delle chiavi protegge la chiave master, e quella chiave master crittografa le chiavi dei dati a breve termine utilizzate per i record o i file reali. Quel design limita l'esposizione durante la rotazione e rende più facile revocare o sostituire il materiale di chiave senza dover riscrivere tutto contemporaneamente.
Le squadre si mettono in difficoltà quando abilitano l'encryption una volta e si fermano lì. Controlla dove vivono le chiavi, chi può usarle, se è programmata la rotazione e se le vecchie copie di backup dipendono ancora da versioni di chiave dimenticate.
L'accesso controllato limita il raggio d'azione
I permessi dovrebbero seguire i confini dell'applicazione, non gli organigrammi.
Il ruolo del database per un checkout API non dovrebbe poter leggere i dati del pagamento. Un lavoratore in background non dovrebbe avere i diritti di modifica dello schema perché era comodo durante una migrazione iniziale. Gli strumenti di supporto dovrebbero utilizzare viste filtrate o procedure approvate al posto di un accesso tabellare ampio.
Un modello pratico assomiglia a questo:
- Ruolo dell'applicazione web: accesso di lettura e scrittura limitato per le tabelle dietro le richieste degli utenti.
- Ruolo del lavoratore: accesso ai record necessari per i lavori che esegue.
- Ruolo degli analytics: accesso di sola lettura alle set di dati curati con identificatori diretti rimossi dove possibile.
- Ruolo di amministratore di emergenza: accesso breve e approvato con registrazione forte e revisione.
Questa colonna si rafforza quando viene abbinata alla trasformazione dei dati. Se un team può svolgere il suo lavoro con dati mascherati o ridotti, fornigliela in quella versione anziché i valori di produzione completi. Per i dati sanitari regolamentati, de-identificazione dei dati PHI è spesso la differenza tra accesso utile e esposizione non necessaria.
I segreti relativi al database meritano la stessa disciplina. Le squadre che stringono i controlli di archiviazione ma lasciano le credenziali delle macchine sparse nei log di CI, nelle costruzioni mobili o nei script di supporto lasciano ancora un ampio percorso di attacco. Le stesse abitudini operative si applicano anche alla API sicurezza delle chiavi per la conformità degli store di app, soprattutto quando le app mobili e i servizi backend condividono confini di fiducia.
L'audit mostra se i controlli sono reali
Una politica che non può essere verificata è solo una speranza.
Gli archivi di audit rispondono alle domande che contano durante un incidente. Quali identità hanno letto i record. Quali ruoli hanno modificato le autorizzazioni. Quali esportazioni di lavoro hanno spostato i dati. Quale chiave è stata utilizzata per decrittare un archivio. Espongono anche il lento deriva, come un account di servizio che ha iniziato a toccare le tabelle che non aveva mai bisogno prima.
La copertura di audit utile include:
- Attività di autenticazione: accessi riusciti, accessi falliti, utilizzo di token e sessioni amministrative.
- Cambiamenti di autorizzazione: concessioni, revoca, creazione di ruoli, modifiche alle politiche e modifiche allo schema.
- Modelli di accesso sensibili: lettura di massa, esportazioni di grandi dimensioni, percorsi di query insoliti e accesso al di fuori degli orari o delle reti di origine previsti.
- Eventi di gestione delle chiavi: creazione di chiavi, rotazione, tentativi di decrittografia falliti, versioni disabilitate e modifiche alle politiche nel KMS o nel magazzino dei segreti.
La conservazione è importante qui. Lo stesso vale per la revisione. Se i log scadono prima che qualcuno li esamini, o se nessuno verifica le modifiche di privilegio a meno che non ci sia già una violazione, il sistema di audit esiste solo sulla carta più che nella pratica.
Ecco una buona spiegazione prima che i dettagli di implementazione diventino troppo astratti:
La minimizzazione tiene i dati sensibili fuori dai luoghi in cui non si può difendere bene
La minimizzazione è dove molte squadre ottengono il loro più grande successo in termini di sicurezza con il minor sforzo di ingegneria.
Riduci le informazioni. Conservale per un tempo più breve. Copiale in meno posti. Se una funzione richiede solo l'intervallo di età, non memorizzare la data di nascita completa. Se il supporto richiede solo gli ultimi quattro caratteri di un identificatore, evita di esporre il campo completo. Se gli ambienti di test non richiedono dati personali in tempo reale, non ripristinare backup di produzione in essi e chiamalo temporaneo.
Questa è anche una disciplina operativa. Le scadenze di conservazione richiedono un controllo. Le esportazioni vecchie devono essere cancellate. I sistemi downstream devono essere rivisti perché il rischio cresce ogni volta che i campi sensibili vengono replicati negli indici di ricerca, nelle cache, nei laghi di dati, nell'archiviazione mobile e nei file CSV ad hoc. Per le app Capacitor @capgo/capacitor-archiviazione-dati-sqlite e @capgo/capacitor-archiviazione-dati-rapida possono fornire una persistenza crittografata sul lato dell'app, ma è ancora necessario decidere cosa non dovrebbe essere memorizzato localmente per niente.
Lo scopo di questi pilastri non è la perfezione già dal primo giorno. È costruire un sistema di archiviazione che rimanga difendibile dopo le rotazioni delle chiavi, i cambi di personale, la risposta agli incidenti, il ripristino dei backup e la crescita del prodotto. È lì che l'archiviazione dei database sicura riesce o fallisce di solito.
Modelli di Implementazione Pratici per la Crittografia
Non esiste un modello di crittografia per ogni sistema. La scelta giusta dipende da cosa si sta proteggendo, chi deve interrogarlo e quanto complessità il team può supportare. L'errore è scegliere il modello più forte e poi implementarlo male.
TDE è la linea di base più veloce
L'encryption dei dati trasparentiL'encryption dei dati trasparenti, o TDE, è spesso il luogo più facile dove iniziare. L'engine del database cifra i file sul disco e li decifra quando l'engine li legge in memoria. Le applicazioni spesso non richiedono modifiche code.
Questo è un buon punto di partenza per:
- La protezione di tutto il database
- I requisiti di conformità a livello di archiviazione
- La riduzione del rischio di accesso diretto ai dischi, alle snapshot o ai file
TDE non protegge contro tutto. Se un attaccante ottiene accesso valido al database, l'engine servirà comunque dati decifrati. È per questo che TDE aiuta a proteggere la compromissione di archiviazione, non l'abuso di credenziali legittime.
L'encryption a livello di applicazione protegge i campi più importanti
L'encryption a livello di applicazione avviene prima che i dati raggiungano il database. Il tuo code cifra i campi selezionati, quindi scrive il testo cifrato in archiviazione. Funziona bene per colonne particolarmente sensibili come ID del governo, dettagli bancari, segreti di recupero o note private.
Quel controllo extra comporta sacrifici:
- Si possiedi più complessità: la selezione delle chiavi, le librerie di crittografia, il comportamento della rotazione e la gestione degli errori.
- La query diventa più difficile: la corrispondenza esatta, la ricerca parziale e l'indicizzazione diventano problemi di progettazione.
- Gli sviluppatori hanno bisogno di disciplina: un solo trucco in uno script di migrazione può eludere tutto il modello.
Un semplice modello di pseudocodice assomiglia a questo:
| Passo | Azione |
|---|---|
| 1 | Leggi il campo di testo in chiaro dalla richiesta |
| 2 | Chiedi alla chiave del servizio un chiave di crittografia dei dati o utilizza una chiave locale avvolta |
| 3 | Crittografa il campo nell'applicazione |
| 4 | Memorizza il testo cifrato e i metadati nel database |
| 5 | Decifra solo nelle vie di lettura approvate |
Per la persistenza dell'app locale, le stesse domande di progettazione si applicano. Se stai memorizzando token offline o stato di sincronizzazione sensibile su un dispositivo, non supporre che lo storage mobile sia sicuro per impostazione predefinita. Utilizza pattern consapevoli della piattaforma come quelli discussi in secure storage per token offline in Capacitor.
L'enciclopedia è una sicurezza dentro una sicurezza
L'enciclopedia sembra intimidante, ma l'idea è semplice. Cifri i dati con una chiave, quindi cifra quella chiave con un'altra, meglio protetta.
Pensa a questo come a un documento chiuso in un piccolo safe. La chiave di quel piccolo safe è poi chiusa all'interno di un cassaforte di banca. Se qualcuno ruba il layer di archiviazione del documento, ancora devono avere accesso alla chiave di cassaforte a maggiore protezione prima di poter aprire qualcosa utile.
Flusso tipico:
- Genera una chiave dei dati per il record, il file o la batch.
- Cifra i dati con quella chiave dei dati.
- Avvolgere la chiave dei dati utilizzando una chiave master in un KMS o HSM.
- Memorizzare il testo cifrato più i metadati della chiave avvolta con il record o l'oggetto.
- Decifrarla solo durante le letture autorizzate.
Consiglio del campo: Usare l'encrittura in un contenitore quando hai bisogno di una forte compartimentazione senza esporre una chiave master a lunga durata a ogni server di applicazione.
Questo pattern è comune perché bilancia prestazioni e controllo. Le applicazioni utilizzano chiavi dei dati a breve durata per il lavoro di cifratura effettivo, mentre un KMS o HSM protegge la chiave master utilizzata per avvolgere e svolgere.
Comparazione dei modelli di crittografia
| Modello | Complessità di implementazione | Influenza sulla prestazione | Migliore per |
|---|---|---|---|
| Crittografia del disco o del volume | Basso | Basso | Protezione a livello di infrastruttura per server e archiviazione collegata |
| Crittografia dei dati trasparente | Basso a moderato | Basso a moderato | Protezione del database intero con minimi cambiamenti dell'applicazione |
| Crittografia a livello di applicazione | Moderato a alto | Varia a seconda dell'uso dei campi e del design delle query | Colonne molto sensibili e separazione rigorosa necessarie |
| Crittografia a pacchetto | Moderato ad alto | Moderato | Sistemi che richiedono isolamento chiave più forte e controllo chiave scalabile |
La regola pratica è semplice. Inizia con una base solida come TDE o crittografia gestita in stato di riposo. Aggiungi la crittografia a livello di campo o a pacchetto solo dove la sensibilità dei dati e il modello di minaccia giustificano l'ingegneria aggiuntiva.
Gestione delle chiavi e dei segreti
Un'incursione spesso inizia con un errore di gestione di un segreto ordinario. Un database di produzione è crittografato, esistono backup e l'accesso sembra controllato su carta. Poi un job di CI stampa un token nei log, un ingegnere utilizza un credenziale di amministratore per uno script di supporto, o una chiave obsoleta rimane attiva a lungo dopo che il team che l'ha creata si è spostato.
È per questo che la gestione delle chiavi e dei segreti è una pratica operativa, non un compito di configurazione.
Un database crittografato con chiavi gestite male funziona come un'area di servizio chiusa con la targhetta di accesso appesa alla maniglia. Le linee guida governative fanno lo stesso punto. La crittografia da sola non chiude il divario se i team trascurano la gestione delle chiavi basata su KMS o HSM, l'accesso con privilegi minimi e la pianificazione di ripristino, come descritto nelle Linee guida dell'NSA e dei partner per la sicurezza dei dati in cloud.
Dove i team sbagliano
Le modalità sono familiari nelle revisioni degli incidenti:
- Segreti nei file sorgenti code: credenziali hardcoded, certificati incorporati o script di utilità che diventano gradualmente dipendenze di produzione.
- Segreti nei file di configurazione copiati: file passati tra laptop, memorizzati in cartelle condivise o commessi durante una rapida correzione.
- Variabili di ambiente con controlli deboli: conveniente, ma spesso esposto attraverso log di build, storia della shell, rapporti di crash o ampi permessi di esecuzione.
- Assenza di proprietà per la rotazione: le chiavi esistono da anni perché nessun team possiede il piano di rilascio, di reimmissione e di rollback.
- Segreti di alta autorizzazione condivisi: una credenziale utilizzata dagli applicativi, dagli ingegneri e dall'automazione, il che rende l'audit e la contenimento molto più difficile.
Se stai standardizzando come gestire i segreti degli app e dell'infrastruttura, una riferimento pratico per gestire ambiente di sicurezza variabile può aiutare le squadre a spostarsi da una dispersione ad hoc di segreti.
Che cosa rappresenta un buon gestione delle chiavi
Usa un KMS quando la politica centralizzata, il controllo di accesso, i registri di audit e la rotazione programmata sono più importanti del controllo di hardware personalizzato. Usa un HSM quando il rischio, le esigenze di conformità o le regole di protezione e firma giustificano confini di hardware dedicati. Molte squadre non hanno bisogno di un HSM in ogni luogo. Hanno bisogno di regole chiare per i sistemi che possono richiedere operazioni di decrittazione, per gli esseri umani che possono modificare la politica e per come vengono esaminati questi azioni.
La crittografia a pacchetto è un buon modello mentale qui. Funziona come tenere il denaro in una piccola cassaforte chiusa, poi mettere quella cassaforte all'interno di una cassaforte di banca. L'applicazione gestisce le chiavi di dati a breve termine per il lavoro di crittografia. La chiave della cassaforte rimane nel KMS o HSM, e l'accesso ad essa è fortemente limitato.
Il controllo che prevene gli incidenti reali sono operativi:
- Rotare le chiavi su un orario che puoi eseguire in modo sicuro: La rotazione riduce la vita utile di una chiave compromessa, ma solo se le applicazioni, i lavori e le ripristinazioni funzionano comunque dopo.
- Dividi le responsabilità: il servizio che legge i dati dei clienti non dovrebbe poter anche modificare la politica delle chiavi o disabilitare la registrazione degli eventi.
- Registra gli eventi chiave sensibili: la creazione delle chiavi, la rotazione, le richieste di decrittazione, gli accessi falliti e le modifiche delle politiche dovrebbero essere tutti visibili.
- Testa le vie di re-encryptazione: rotare una chiave di avvolgimento è spesso più facile che re-encryptare i dati dell'applicazione, ma entrambi richiedono procedure di rollback.
- Disabilita e ritira deliberatamente le vecchie segrete: lascia tempo per il passaggio, poi elimina le credenziali obsolete affinché non possano diventare una porta di servizio silenziosa.
L'ambiente CI/CD merita la stessa disciplina del runtime di produzione. I sistemi di costruzione hanno spesso accesso ampio e visibilità debole, il che li rende un luogo comune per la perdita di segreti. Le squadre serie su questo formalizzano la gestione delle segrete nei pipeline CI/CD piuttosto che trattare le credenziali dei pipeline come eccezioni temporanee.
Una regola è semplice. L'applicazione code dovrebbe richiedere operazioni crittografiche da sistemi affidabili, non portare chiavi master raw in giro nell'ambiente.
La progettazione di un design di crittografia robusto nella tua pila non conta più una volta che un sviluppatore, un flusso di lavoro o uno strumento di supporto possa copiare la chiave master nel posto sbagliato.
Progettare una strategia di backup e ripristino resiliente
Il backup è parte della memorizzazione dei dati di database sicura, non un compito di amministrazione separato. Se la produzione è protetta e i backup non lo sono, l'attaccante seguirà la strada più facile.
La guida di Hypertec sulla memorizzazione dei dati sicura raccomanda di mantenere i sistemi di backup e ripristino alla stessa protezione del livello di produzione perché gli incidenti di ransomware e malware lasciano spesso backup sicuri e testati come l'unica via di ripristino possibile, secondo La guida di Hypertec sulla memorizzazione dei dati sicura.
Il backup ha la sua propria barriera di sicurezza
Un design di backup resiliente ha alcune proprietà:
- Il backup è crittografato in transito e in stato di riposo.
- Il credenziale di backup sono separate da quelle di produzione.
- Il controllo di cancellazione e di conservazione sono più difficili da abusare rispetto all'accesso normale dell'applicazione.
- Il target di ripristino non diventa un ambiente di produzione temporaneo con controlli deboli.
Un modo comune di fallimento è quello di memorizzare i backup crittografati lasciando che la stessa ruolo di produzione compromessa possa cancellarli. Un altro è quello di ripristinare in un ambiente temporaneo con accesso ampio degli ingegneri e senza registrazione. Le vie di ripristino meritano la stessa attenzione delle vie principali.
La vera verifica di ripristino è il controllo reale
Un backup non testato è solo una speranza di archiviazione.
Il team che si ripristina bene non si limita a verificare che le attività di backup siano state completate. Prova che il ripristino funziona, che i dati recuperati sono utilizzabili e che le chiavi di crittografia, le impostazioni di connessione e i servizi dipendenti sono tutti allineati quando servono.
Un programma di ripristino pratico include:
- Esercitazioni di ripristino regolari nel ambienti isolati.
- La verifica della funzione dell'applicazione dopo il ripristino del database, non solo la restaurazione dei file.
- Controlli per la disponibilità delle chiavi così che i backup crittografati possano essere decrittografati.
- Recensione dell'accesso ai sistemi ripristinati per prevenire che i dati sensibili diventino visibili in modo ampio durante un incidente.
Backup non ti salvano. I restore riusciti a salvarti.
Se testi solo la creazione di backup e non testi mai il ripristino sotto pressione, non hai validato la tua strategia di recupero. Hai validato che i file possano accumularsi in qualche posto.
Un Checklist per i Developer per la Storizzazione di Database Sicura
Questo è il checklist che voglio che le squadre utilizzino durante le revisioni di progetto, le revisioni di rilascio e la pulizia post-incidente.
Design
- Abbiamo identificato i campi sensibili chiaramente: dati personali, materiali di autenticazione, registri finanziari e qualsiasi cosa sia soggetta a regole di conservazione.
- Abbiamo deciso cosa non archiviare: campi che la funzione non richiede e copie che le squadre downstream possono evitare.
- Abbiamo mappato ogni posto in cui i dati vivranno: produzione, staging, log, esportazioni, sistemi di analisi, backup e dispositivi clienti.
Esecuzione
- La crittografia dei dati è attiva durante il riposo e in transito: per il database, le copie e le vie di backup.
- Sono definiti ruoli di applicazione e servizio con un'assegnazione stretta: nessun superutente condiviso per il traffico normale dell'applicazione.
- Sono gestiti segreti e chiavi di crittografia al di fuori di code e configurazione flessibile: con accesso controllato e tracciabilità.
- Vengono registrati accessi sensibili e modifiche di privilegi: in un luogo centrale da cui i difensori possono interrogare.
Esecuzione
- La rotazione delle chiavi e la revisione dei segreti fanno parte delle normali operazioni: non è un caos annuale.
- Testiamo regolarmente le ripristinazioni: incluso la decrittografia, l'avvio dell'applicazione e la revisione dell'accesso sui sistemi ripristinati.
- Auditiamo la dispersione dei dati in modo continuo: copia di staging, esportazioni di supporto, set di dati di sviluppo e ubicazioni di backup dimenticate.
Una buona archiviazione dei dati sicura non è un progetto di fase. È una disciplina ricorrente.
Domande frequentemente poste
Non è abbastanza una crittografia predefinita del provider cloud
È un buon punto di partenza, non una strategia completa. La crittografia predefinita aiuta a proteggere i media di archiviazione e i servizi gestiti, ma non risolve l'accesso privilegiato eccessivo, i dati copiati, i controlli di backup deboli o la cattiva gestione delle chiavi.
La crittografia danneggia il rendimento del database
Sì, a volte. L'impatto dipende dal modello. La crittografia dell'infrastruttura e del database solitamente ha meno complessità di applicazione. La crittografia dei campi offre un controllo più forte per i dati selezionati, ma può complicare l'indicizzazione, la filtratura e la ricerca. Misura sul tuo carico di lavoro prima di una distribuzione ampia.
È diverso per i sistemi SQL e NoSQL
I principi rimangono gli stessi. Ancora avete bisogno di crittografia, privilegi minimi, auditing, gestione delle chiavi e ripristino testato. I dettagli di implementazione cambiano perché i magazzini di documenti, i magazzini di valori chiave e i sistemi relazionali espongono modelli di accesso e comportamento di query diversi.
How is tokenization different from encryption
La crittografia trasforma i dati in modo che i sistemi autorizzati possano decifrarli con la chiave giusta. La tokenizzazione sostituisce i valori sensibili con valori surrogati e mantiene i dati originali separati. La tokenizzazione può ridurre l'esposizione nei flussi di lavoro dell'applicazione, ma aggiunge complessità di progettazione del sistema e non elimina la necessità di controlli di archiviazione robusti.
Capgo aiuta le squadre a inviare riparazioni a Capacitor e agli app Electron velocemente, con la consegna di pacchetti web firmati, controlli di distribuzione, protezione del rollback e osservabilità delle rilasci. Se il piano di risposta agli incidenti dipende dall'invio di riparazioni client-side velocemente dopo un errore di archiviazione, autenticazione o API Capgo è valutabile come parte del lato operativo della ripresa.
