Puoi aver notato che hai rilasciato una versione in orario notturno, hai lanciato un'alert e hai notato 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 della memorizzazione.
Questo si verifica in tutti i sistemi reali. Le squadre abilitano l'encryption una volta e si aspettano di essere finite. Conservano backup ma non testano il ripristino. Creano un account di servizio amministrativo per comodità e dimenticano che esiste. Bloccano la produzione, poi lasciano la produzione di staging piena di dati dei clienti copiati. Se stai costruendo app mobili o web, la memorizzazione dei dati di database sicuri deve coprire tutto: il database primario, le copie, gli esporti, i log, i backup e le chiavi che controllano tutto.
Se lavori anche tu attraverso risolvi l'autenticazione 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 hai previsto. Per le squadre che stanno spedito app faccia a faccia con i clienti, è anche utile allineare le decisioni di archiviazione con controlli adiacenti come API standard di sicurezza per la conformità degli store di app.
La urgenza non è teorica. La produzione globale dei dati raggiunse 64,2 zettabyte nel 2020 e fu proiettato salire a 180 zettabyte entro il 2025 secondo Edge Delta's summary di archiviazione dei dati. A quel livello, l'archiviazione sicura smette di essere una task di hardening e diventa architettura.
Indice
- Perché la sicurezza dei database è più che solo una password
- Capire il Modello di Minaccia del Database
- I Pilastri Fondamentali di un Database di Archiviazione Sicuro
- Modelli di Implementazione Pratici per l'Encryptione
- Gestione della chiave e della chiave segreta: il punto di forza
- Progettare una strategia di backup e ripristino resiliente
- Checklist per sviluppatori per il storage di database sicuro
- Domande Frequenti
Perché la sicurezza del database è più di una semplice password?
Una password protegge un punto di ingresso. 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 del database deve essere stratificata.
Il vecchio modello mentale era semplice: mettere il database dietro un firewall, richiedere una password forte e tenere lontani gli esterni. Quel 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 diverse infrastrutture. 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 archiviazione non sembrano drammatiche all'inizio. Sembrano ordinarie.
- Una comodità per lo sviluppatore diventa un rischio di produzione: Un credenziale di amministrazione condiviso viene riutilizzato da uno script perché rotarlo sarebbe stato dannoso per la distribuzione.
- A un dataset copiato sfugge al controllo: Il registro di produzione viene clonato in staging per consentire alla QA di riprodurre un bug.
- Un backup diventa il punto debole: La produzione ha controlli robusti, ma la politica del bucket di ripristino o la politica dei snapshot non lo sono.
Regola pratica: Se l'unico ostacolo tra un attaccante e dati leggibili è un credenziale, non hai un storage sicuro. Hai un punto di fallimento unico.
La difesa deve sopravvivere all'abuso delle credenziali
La guida cloud di Microsoft raccomanda un 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 nei suoi principi di sicurezza dei dati cloud. Questo è il baseline giusto perché gli incidenti reali spesso iniziano con l'accesso valido utilizzato in modo sbagliato.
Ciò che funziona nella pratica è noioso e coerente. Cifra i file del database. Cifra le connessioni. SPLITTA I RUOLI DEI SERVIZI. Rimuovi l'accesso amministrativo in piedi dove puoi. Registra le operazioni sensitive. Avvisa sui modelli di accesso che non si adattano all'uso normale. Nessuna di queste cose è glamour, ma previene vere violazioni.
Un modo utile per pensarci è un deposito fisico. La porta del deposito conta. Lo stesso vale per le serrature delle cassette, la registrazione delle telecamere, il registro dei visitatori e la politica per chi può aprire quale cassetta. Il storage dei database sicuro funziona nello stesso modo. Le password sono solo la porta d'ingresso.
Understanding Your Database Threat Model
Prima di scegliere i controlli, mappa le modalità con cui il tuo sistema può fallire. Un modello di minaccia per il storage dei database non deve essere accademico. Ha bisogno di dirti chi potrebbe toccare dati sensibili, come lo farebbero e cosa accadrebbe se riuscissero.
I dati sensibili vivono raramente in un database di produzione ordinato. La guida moderna enfatizza la scoperta e la gestione della posizione perché l'informazione sensibile finisce spesso in copie, backup, log e ambienti di sviluppo, quindi i fallimenti accadono spesso fuori dal database primario, come notato in La panoramica di Sentra sulla sicurezza dei dati in cloud e sulla gestione della posizione. Quindi, il piano di emergenza dovrebbe includere scenari come l'esposizione del fornitore e i dataset copiati. Questo è anche dove diventano pertinenti i libri di procedure di risposta più ampi, come le migliori pratiche di risposta a violazioni di terze parti.
Inizia con gli asset, non con gli strumenti
Elencare ciò che conta prima di elencare i prodotti.
Per la maggior parte delle squadre di app, gli asset critici sono chiari:
- I registri dei clienti ad esempio, i profili, la storia degli ordini, i metadati relativi ai pagamenti o i contenuti relativi alla salute.
- Materiali di autenticazione ad esempio, hash di password, registrazioni di sessione, token di refresh o API segreti.
- Dati operativi ad esempio, registrazioni di audit, code di lavoro, note di amministrazione e esportazioni di supporto.
- Risorse di ripristino ad esempio, snapshot, dump logici, registrazioni a un punto nel tempo e chiavi di crittografia.
Quell'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 ripristino crolla.
I tre contenitori di minaccia che contano di più
Un modello semplice che utilizzo con gli sviluppatori ha tre contenitori.
Attaccanti esterni
Questo è il contenitore che tutti pensano per primo. Iniezione SQL, token API rubati, credenziali di cloud divulgate, pannelli di amministrazione 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 potrebbe leggere più di un servizio necessita?
- 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 le righe di produzione anche se il suo lavoro non lo richiede.
Ciò che aiuta è la separazione dei compiti, l'accesso basato su ruoli e le tracce di audit che rendono visibili le letture sensibili.
Se non puoi rispondere a chi ha acceso un record del cliente, quando l'ha acceso e perché quel accesso è stato consentito, i controlli del tuo database sono più deboli di quanto sembri.
Esposizione accidentale
Questo è la categoria più comune in team che si muovono velocemente. Un bucket di archiviazione configurato male. Un ambiente di staging seedato con dati live. I 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 lo risolvi con una impostazione. Lo risolvi con la classificazione dei dati, i guardianie, la revisione e la pulizia di routine.
I Pilastri fondamentali della sicurezza della memorizzazione dei dati del database
A una rottura raramente si arriva con un fallimento drammatico. Di solito arriva da una catena di errori ordinari. Una copia di backup viene copiata nella cassetta sbagliata. Un servizio ottiene permessi più ampi di quelli di cui ha bisogno. Una vecchia chiave rimane attiva per mesi perché la rotazione è stata continuamente rimandata. La memorizzazione dei dati di database sicura 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 finiscono, chi può leggerli e quali chiavi possono decrittografarli.
La crittografia riduce il valore dei dati rubati
La crittografia acquista tempo e riduce l'impatto. Se qualcuno ottiene una snapshot del disco, un file di backup raw o traffico da una rete interna, i dati crittografati sono molto più difficili da trasformare in registri dei clienti.
Al riposo, la crittografia protegge i file di database, le snapshot e gli artefatti di backup. In transito, TLS protegge le connessioni tra server di applicazione, proxy e 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 relative alle raccomandazioni sui dati in riposo.
The trade-off è operativo, non teorico. L'encryption aiuta solo se il trattamento delle chiavi è separato dal percorso dei dati e viene mantenuto nel tempo. L'encryption dell'invio funziona come una chiave master 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 vita 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 chiave senza dover riscrivere tutto in una volta.
Il team entra in difficoltà quando abilita l'encryption una volta e smette lì. Controlla dove vivono le chiavi, chi può utilizzarle, se è programmata la rotazione e se gli archivi vecchi dipendono da versioni di chiave dimenticate.
Il controllo degli accessi limita il raggio d'azione
Il permesso dovrebbe seguire i confini dell'applicazione, non le organigrammi.
Il ruolo del database per un checkout API non dovrebbe poter leggere i dati del salario. Un lavoratore in background non dovrebbe avere 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'app 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 dataset curati con identificatori diretti rimossi dove possibile.
- Ruolo amministrativo di emergenza: accesso breve e approvato con registrazione e revisione forte.
Questa colonna si rafforza quando viene associata alla trasformazione dei dati. Se un team può svolgere il suo lavoro con dati mascherati o ridotti, fornire quella versione invece dei valori di produzione completi. Per i dati sanitari regolamentati, la de-identificazione dei dati PHI è spesso la differenza tra un accesso utile e un'esposizione inutile.
I segreti intorno 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, nei costruttori mobili o nei script di supporto lasciano ancora un ampio percorso di attacco. Le stesse abitudini operative si applicano anche alla API chiave di sicurezza per la conformità degli store di app, soprattutto quando le app mobili e i servizi backend condividono confini di fiducia.
Gli audit mostrano 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. Quali chiavi sono state utilizzate 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.
Gli archivi di audit utili includono:
- Attività di autenticazione: accessi riusciti, accessi falliti, utilizzo di token e sessioni amministrative.
- Cambiamenti di autorizzazione: concessioni, revocazioni, creazione di ruoli, modifiche alle politiche e modifiche allo schema.
- Pattini 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 relativi alla 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 è anche la revisione. Se i log scadono prima che qualcuno li esamini, o se nessuno controlla 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 di sicurezza per il minor sforzo di ingegneria.
Riduci le informazioni. Conservale per un tempo più breve. Copiala in pochi posti. Se una funzione ha bisogno solo di un'età di riferimento, non memorizzare la data di nascita completa. Se il supporto ha bisogno solo degli ultimi quattro caratteri di un identificatore, evita di esporre il campo completo. Se gli ambienti di test non hanno bisogno di dati personali in tempo reale, non ripristinare i backup di produzione in essi e chiamalo temporaneo.
Questa è anche una disciplina operativa. Le scadenze di conservazione hanno bisogno di un controllo. Le esportazioni vecchie hanno bisogno di cancellazione. I sistemi downstream hanno bisogno di una revisione 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-sql-rapido possono fornire un'archiviazione persistente criptata sul lato dell'app, ma ancora devi decidere cosa non deve essere archiviato localmente per niente.
Il punto di questi pilastri non è la perfezione il giorno uno. È costruire un sistema di archiviazione che rimane difendibile dopo le rotazioni delle chiavi, i cambi di personale, la risposta agli incidenti, i ripristini dei backup e la crescita del prodotto. È lì che l'archiviazione dei database sicuri riesce o fallisce.
Modelli di Implementazione Pratica per la Crittografia
Non esiste un modello di crittografia per ogni sistema. La scelta giusta dipende da cosa si sta proteggendo, chi ha bisogno di interrogarlo e quanto complessità il team può supportare. L'errore è scegliere il modello più forte che sembra e poi implementarlo male.
TDE è la linea di base più veloce
L'encryption dei dati trasparentiL'encryption dei dati trasparenti, o TDE, è di solito 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 hanno bisogno di code modifiche.
Questo è un forte baseline per:
- Protezione della base di dati completa
- Requisiti di conformità di livello di archiviazione
- Riduzione del rischio da dischi rubati, snapshot o accesso diretto ai file
TDE non protegge contro tutto. Se un attaccante ottiene accesso valido alla base di dati, l'engine servirà ancora dati decifrati. È per questo che TDE aiuta con il compromesso di archiviazione, non l'abuso di credenziali legittime.
L'encryption livello applicazione protegge i campi più importanti
L'encryption livello applicazione avviene prima che i dati raggiungano la base di dati. Il tuo code cifra i campi selezionati, quindi scrive ciphertext in archiviazione. Funziona bene per colonne particolarmente sensibili come ID del governo, dettagli bancari, segreti di recupero o note private.
Quell'ulteriore controllo comporta sacrifici:
- Hai più complessità: la selezione delle chiavi, le librerie di crittografia, il comportamento della rotazione e l'elaborazione degli errori.
- La query diventa più difficile: la corrispondenza esatta, la ricerca parziale e l'indicizzazione diventano problemi di progettazione.
- I sviluppatori hanno bisogno di disciplina: un singolo trucco in uno script di migrazione può eludere tutto il modello.
Un semplice pattern di pseudocodice assomiglia a questo:
| Passo | Azione |
|---|---|
| 1 | Leggi il campo di testo in chiaro dalla richiesta |
| 2 | Chiedi alla chiave del servizio una 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 assumere che lo storage mobile sia sicuro per impostazione predefinita. Utilizza modelli consapevoli della piattaforma come quelli discussi in memorizzazione sicura per token offline in Capacitor.
L'encryption in busta è un sicuro dentro un sicuro
L'encryption in busta sembra intimidatorio, ma l'idea è semplice. Cifri i dati con una chiave, poi cifra quella chiave con un'altra, meglio protetta, chiave.
Pensa a esso come a un documento chiuso in un piccolo cassaforte. La chiave di quella piccola cassaforte è poi chiusa all'interno di un deposito bancario. Se qualcuno ruba il layer di archiviazione dei documenti, ancora devono avere accesso alla chiave del deposito bancario 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.
- Avvolgi la chiave dati utilizzando una chiave master in un KMS o HSM.
- Memorizza il testo cifrato più i metadati della chiave avvolta con il record o l'oggetto.
- Decifra solo durante le letture autorizzate.
Consiglio del campo: Usa l'encrittura in un involucro 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 dati a breve durata per il lavoro di crittografia 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 | Miglior per |
|---|---|---|---|
| Criptazione di disco o volume | Basso | Basso | Protezione a livello di infrastruttura per server e archiviazione collegata |
| Criptazione dei dati trasparente | Basso a moderato | Basso a moderato | Protezione del database intero con minimi cambiamenti di app |
| Criptazione a livello di applicazione | Moderato a alto | Varia in base all'uso dei campi e alla progettazione delle query | Colonne molto sensibili e separazione rigorosa necessarie |
| Crittografia in busta | Moderato-alto | Moderato | Sistemi che richiedono isolamento chiave più forte e controllo chiave scalabile |
La regola pratica è semplice. Inizia con una base di partenza forte come TDE o crittografia gestita in stato di riposo. Aggiungi la crittografia a livello di campo o in busta 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 invecchiata 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 una stanza 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 questo
Il pattern è familiare nelle revisioni degli incidenti:
- Segreti nel codice sorgente code: credenziali hardcoded, certificati incorporati o script di utilità che diventano gradualmente dipendenze di produzione.
- Segreti in file di configurazione copiati: file passati tra laptop, memorizzati in cartelle condivise o commessi durante una rapida correzione.
- Variabili di ambiente con controlli deboli: facili da utilizzare, ma spesso esposti attraverso log di build, storia della shell, rapporti di crash o ampi permessi di esecuzione.
- Assenza di proprietà per la rotazione: le chiavi esistono per anni perché nessun team possiede il piano di rilascio, di rotazione e di rollback.
- Segreti di alta privatazza condivisi: una credenziale utilizzata da applicazioni, ingegneri e automazione, il che rende l'audit e la contenimento molto più difficile.
Se stai standardizzando come vengono memorizzati i segreti delle app e dell'infrastruttura, una guida pratica per gestirli ambiente di sicurezza delle variabili può aiutare le squadre a spostarsi lontano dalla dispersione di segreti ad hoc.
Cosa significa una buona gestione delle chiavi
Usa un KMS quando la politica centralizzata, il controllo degli accessi, i registri di audit e la rotazione programmata sono più importanti del controllo personalizzato dell'hardware. Usa un HSM quando i requisiti di rischio, di conformità o le regole di firma e protezione delle chiavi giustificano dei confini di hardware dedicati. Molte squadre non hanno bisogno di un HSM in ogni posto. 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 queste azioni vengono valutate.
L'encryption a pacchetto è un buon modello mentale qui. Funziona come tenere il denaro in una piccola cassaforte chiusa, poi mettere quella cassaforte dentro una cassaforte di banca. L'applicazione gestisce le chiavi di dati a breve vita per il lavoro di cifratura. La chiave della cassaforte rimane nel KMS o HSM, e l'accesso ad essa è fortemente limitato.
I controlli che prevenivano gli incidenti reali sono operativi:
- Rimuovi 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 job e le ripristinazioni funzionano comunque dopo.
- Dividi le responsabilità: il servizio che legge i dati dei clienti non dovrebbe poter anche modificare la politica chiave o disabilitare la registrazione degli eventi.
- Registra gli eventi chiave sensibili: la creazione di chiavi, la rotazione, le richieste di decrittazione, gli accessi falliti e le modifiche della politica dovrebbero essere tutti visibili.
- Testa i percorsi di re-encryptazione: rotare una chiave di avvolgimento è spesso più facile che re-encryptare i dati dell'applicazione, ma entrambi richiedono procedure di rollback e runbook.
- Disabilita e ritira deliberatamente le vecchie segrete: lascia tempo per il cutover, poi elimina le credenziali obsolete affinché non diventino una porta di servizio silenziosa.
Il 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 fuga di segreti. Le squadre che sono serie su questo formalizzano la gestione delle segrete nei pipeline CI/CD al posto di 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 per l'ambiente.
The progettazione più sicura dell'encryption nel tuo stack non conta più una volta che un sviluppatore, un flusso di lavoro o uno strumento di supporto può 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 livello di protezione della produzione perché gli incidenti di ransomware e malware lasciano spesso i backup sicuri e testati come l'unica via di ripristino possibile, secondo La guida di Hypertec sulla memorizzazione dei dati sicura.
Il backup ha bisogno del suo proprio confine 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 della cancellazione e della conservazione sono più difficili da abusare rispetto all'accesso normale all'applicazione.
- Il target di ripristino non diventa un ambiente di produzione temporaneo con controlli deboli.
Un modo di fallimento comune è quello di memorizzare i backup crittografati lasciando che lo stesso ruolo di produzione compromesso possa eliminarli. 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.
Restaura le prove di testing è il controllo reale
Un backup non testato è solo una speranza di archiviazione.
Le squadre che si riprendono bene non verificano solo che le attività di backup siano state completate. Prova che la ripristino funziona, che i dati recuperati sono utilizzabili e che le chiavi di decrittazione, le impostazioni di connessione e i servizi dipendenti sono tutti allineati quando servono.
Un programma di ripristino pratico include:
- Esercitazioni di ripristino routine in ambienti isolati.
- Verifica della funzionalità dell'applicazione dopo il recupero del database, non solo la restaurazione dei file.
- Controlli per la disponibilità delle chiavi affinché i backup crittografati possano essere decrittati.
- Recensione dell'accesso ai sistemi ripristinati per prevenire che i dati sensibili diventino visibili a tutti durante un incidente.
I backup non ti salva. Le ripristini riusciti ti salveranno.
Se testi solo la creazione dei 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 vorrei che le squadre utilizzassero 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.
Implementazione
- E' il dato criptato in stato di riposo e in transito: per il database, replica e percorsi di backup.
- Sono i ruoli dell'applicazione e dei servizi limitati strettamente: nessun superutente condiviso per il traffico normale dell'app.
- Sono i segreti e le chiavi di crittografia gestiti al di fuori di code e configurazione flessibile: con accesso controllato e tracciabilità.
- Registriamo le modifiche di accesso e privilegi sensibili: in un luogo centrale da cui i difensori possono interrogare.
Operazioni
- La rotazione delle chiavi e la revisione dei segreti fanno parte delle operazioni normali: non è un caos annuale.
- Do ci testiamo i ripristini regolarmente: Includendo la decrittazione, l'avvio dell'applicazione e la revisione dell'accesso sui sistemi ripristinati.
- Do ci monitoriamo lo spreco di dati continuamente: Copie di staging, esportazioni di supporto, set di dati di sviluppo e ubicazioni di backup dimenticate.
Una buona conservazione dei dati in database non è un progetto di fase. È una disciplina ricorrente.
Domande frequentemente poste
È abbastanza buona l'encryption di default dei provider cloud?
È una buona base, non una strategia completa. L'encryption di default aiuta a proteggere i media di archiviazione e i servizi gestiti, ma non risolve l'accesso troppo ampio, i dati copiati, i controlli di backup deboli o la cattiva governance delle chiavi.
La crittografia danneggia il rendimento del database
Sì, a volte. L'impatto dipende dal modello. L'encryption dell'infrastruttura e del database di solito ha una complessità di applicazione inferiore. La crittografia a livello di campo offre un controllo più forte per i dati selezionati, ma può complicare l'indicizzazione, la filtrazione e la ricerca. Misura il 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 chiavi e i sistemi relazionali espongono modelli di accesso e comportamento di query diversi.
Come differisce la tokenizzazione dalla crittografia
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'app, ma aggiunge complessità di progettazione del sistema e non elimina la necessità di controlli di archiviazione robusti.
Capgo aiuta le squadre a distribuire riparazioni a Capacitor e Electron app velocemente, con consegna di bundle web firmati, controlli di rilascio, protezione del rollback e osservabilità dei rilasci. Se il piano di risposta agli incidenti dipende dal fatto di distribuire riparazioni client-side velocemente dopo un errore di archiviazione, autenticazione o API Capgo è degno di valutazione come parte del lato operativo della ripresa.
