Puoi pubblicare una versione in orario notturno, dare un'occhiata alle tue notifiche e notare 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 aveva inteso. Comunque sia, il problema non è solo che qualcuno potrebbe accedere. Il problema è che la sicurezza del database continua a essere trattata come un problema di accesso quando in realtà è un problema di ciclo di vita del database.
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 lo staging pieno di dati dei clienti copiati. Se stai costruendo app mobili o web, la sicurezza del database deve coprire tutto: il database principale, le copie, le esportazioni, i log, i backup e le chiavi che controllano tutto.
If sei stai anche lavorando attraverso la risoluzione dell'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 lo fa, o quando i dati si infiltrano attraverso un percorso che non ti aspettavi. Per le squadre che stanno inviando app faccia a faccia con i clienti, è anche utile allineare le decisioni di archiviazione con i controlli adiacenti come i __CAPGO_KEEP_0__ 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 proiettata a salire a 180 zettabyte entro il 2025 API security standards for app store compliance.
Edge Delta's riassunto di archiviazione dei dati . A quel livello, l'archiviazione sicura smette di essere un compito di hardening e diventa architettura. Indice Perché la sicurezza dei database è più di una semplice passwordLa sicurezza fallisce nelle vie silenziose
Table of Contents
- Why Database Security Is More Than Just a Password
- Capire il tuo modello di minaccia per il database
- I pilastri fondamentali dello storage di database sicuro
- 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 lo 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 stato 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 spostano 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 più dannose fallite 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 forti, 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 dei credenziali
La guida cloud di Microsoft raccomanda un baseline che include l'encryption in transito e in stato di riposo, controlli di accesso a 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.
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 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. Lo storage dei dati del database funziona nello stesso modo. Le password sono solo la porta d'ingresso.
Capgo
Prima di scegliere i controlli, mappa le modalità in cui il tuo sistema può fallire. Un modello di minaccia per il storage di database non deve essere accademico. Ha bisogno di dirti chi potrebbe toccare dati sensibili, come lo farebbero e cosa succederebbe se avessero successo.
I dati sensibili vivono raramente in un unico database di produzione ordinato. Le linee guida moderne enfatizzano la scoperta e la gestione della posizione perché l'informazione sensibile finisce spesso in copie, backup, log e ambienti di sviluppo, quindi i fallimenti avvengono spesso fuori dal database primario, come notato in L'overview di Sentra sulla sicurezza dei dati in cloud e sulla gestione della posizioneQuindi i piani di incidente dovrebbero includere scenari come esposizione del fornitore e set di dati copiati. Questo è anche dove diventano pertinenti i libri di strategia di risposta più ampi, come le migliori pratiche di risposta a violazioni di terze partiInizia 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 record dei clienti
- __CAPGO_KEEP_0__ come ad esempio i profili, la storia degli ordini, i metadati relativi ai pagamenti o i contenuti relativi alla salute.
- Materiali di autenticazione come ad esempio hash di password, registri di sessione, token di refresh o API segreti.
- Dati operativi come ad esempio registri di audit, code di lavoro, note di amministrazione e esportazioni di supporto.
- Risorse di recupero come ad esempio snapshot, dump logici, registri di punto-in-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 recupero si sgretola.
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:
- Potrebbe qualcuno interrogare il database indirettamente attraverso l'applicazione?
- Un credenziale di server rubato può leggere più di un servizio necessita?
- Un snapshot copiato sarebbe leggibile da solo?
Minacce interne
Ciò include gli insider maliziosi 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 è 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 tuoi controlli del 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. 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 di archiviazione 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 sicura archiviazione 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 riceve permessi più ampi di quelli che necessita. Una vecchia chiave rimane attiva per mesi perché la rotazione è stata continuamente rimandata. La memorizzazione dei dati di database sicura deve interrompere questa catena in diversi punti, e continuare a farlo mentre il sistema cambia.
Raggruppo il lavoro in quattro pilastri: crittografia, controllo degli accessi, 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 decrittificarli.
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.
A 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 l'engine di database. Il NIST affronta entrambi i controlli nella sua guida sulla crittografia dei dati in storage e sulla protezione dei dati in transito in SP 800-111 e le raccomandazioni relative alle raccomandazioni dei dati in storage.
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 per l'edificio e una chiave bloccata per la stanza. 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 di chiave senza ri scrivere tutto contemporaneamente.
Il problema si verifica quando le squadre abilitano l'encryption una volta e si fermano lì. Controlla dove vivono le chiavi, chi può utilizzarle, se è programmata la rotazione e se le vecchie copie di backup dipendono ancora da versioni di chiave dimenticate.
Il controllo degli accessi limita il raggio di azione di un attacco
Il controllo delle autorizzazioni dovrebbe 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 di 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 di tabella 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 analisti: accesso di sola lettura alle set di dati curati con gli identificatori diretti rimossi dove possibile.
- Ruolo amministrativo 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, fornigli quella versione al posto 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 un lento deriva, come un account di servizio che ha iniziato a toccare le tabelle che non ha mai avuto 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 decrittazione falliti, versioni disabilitate e modifiche alle politiche nel KMS o nel magazzino dei segreti.
Il fatto che i log scadono prima che qualcuno li esamini, o che nessuno controlli le modifiche di privilegio a meno che non ci sia già una violazione, rende il sistema di audit una semplice formalità.
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 con il minimo sforzo di ingegneria.
Riduci le informazioni. Conservale per un tempo più breve. Copiala in pochi posti. Se una funzione richiede solo l'età di appartenenza, 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 necessitano di dati personali in tempo reale, non ripristinare i backup di produzione e chiamalo temporaneo.
Questa è anche una disciplina operativa. Le scadenze di conservazione necessitano di un controllo. Le esportazioni vecchie necessitano di cancellazione. I sistemi downstream necessitano 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. Ad esempio, strumenti come Capgo’s plugin di archiviazione basato su SQLite per Capacitor possono fornire una persistenza app-side, ma ancora devi decidere cosa non dovrebbe mai essere memorizzato localmente.
Il punto di questi pilastri non è la perfezione già dal primo giorno. È costruire un sistema di archiviazione che rimanga difendibile dopo le rotazioni delle chiavi, i cambiamenti del personale, la risposta agli incidenti, i ripristini dei backup e la crescita del prodotto. È lì che il database di archiviazione sicuro riesce o fallisce.
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 lo deve interrogare e quanto complessità il team può sostenere. 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 hanno bisogno di code modifiche.
Questo è un buon punto di partenza per:
- Protezione di tutto il database
- Requisiti di conformità a livello di archiviazione
- Riduzione del rischio in caso di rubatura di dischi, snapshot o accesso diretto a 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ù sensibili
L'encryption a livello di applicazione avviene prima che i dati raggiungano il database. 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'extra controllo comporta sacrifici:
- Hai più complessità: la selezione della chiave, 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.
- I sviluppatori hanno bisogno di disciplina: un singolo trucco in uno script di migrazione può bypassare 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 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 di default. Utilizza modelli consapevoli della piattaforma come quelli discussi in "Memorizzazione sicura dei 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.
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 del documento, 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.
- Avvolgere la chiave 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.
- Decifra solo durante le letture autorizzate.
Consiglio del campo: Usare l'encryption 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 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 cifratura
| Modello | Complessità di implementazione | Influenza sulle prestazioni | Migliore per |
|---|---|---|---|
| Crittografia del disco o 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 modifiche minimale all'applicazione |
| Crittografia a livello di applicazione | Moderato ad alto | Varia a seconda dell'uso del campo e del disegno della 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 attacco spesso inizia con un errore di gestione dei segreti ordinario. Una base di dati di produzione è crittografata, esistono backup e l'accesso sembra controllato su carta. Poi un job di CI stampa un token nei log, un ingegnere reutilizza 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.
Una base di dati crittografata con chiavi gestite male funziona come un'area di servizio chiusa con la targhetta di accesso appesa alla maniglia della porta. 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 esposte attraverso log di build, storia della shell, rapporti di crash o ampi permessi di esecuzione.
- Nessuna proprietà per la rotazione: le chiavi esistono da anni perché nessun team possiede il piano di rilascio, di rotazione e di rollback.
- Segreti di alta autorizzazione condivisi: una credenziale utilizzata da applicazioni, ingegneri e automazione, il che rende l'audit e la contenimento molto più difficile.
Se stai standardizzando come sono memorizzati i segreti delle app e dell'infrastruttura, una guida pratica per gestire ambiente variabili protetti possono 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 di accesso, i registri di audit e la rotazione programmata sono più importanti del controllo hardware personalizzato. Usa un HSM quando i requisiti di rischio, di conformità o le regole di protezione e firma giustificano 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 di 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 termine per l'encryption. La chiave del caveau rimane nel KMS o HSM, e l'accesso ad essa è fortemente limitato.
Il controllo che prevene gli incidenti reali è operativo:
- Rimuovi le chiavi su un orario che puoi eseguire in sicurezza: la rotazione riduce la vita utile di una chiave compromessa, ma solo se le applicazioni, i job e le ripristinazioni funzionano comunque dopo.
- Dividi i compiti: il servizio che legge i dati dei clienti non dovrebbe poter anche modificare la politica di accesso chiave o disabilitare la registrazione degli eventi.
- Registra eventi di 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 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 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 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 fidati, non portare chiavi master raw in giro 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 per la 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 per la memorizzazione dei dati sicura.
Il backup ha bisogno del proprio confine di sicurezza
Un progetto di backup resiliente ha alcune proprietà:
- Il backup è crittografato in transito e in stato di riposo.
- Il credenziale di backup sono separate dalle credenziali di produzione.
- Il controllo di cancellazione e di conservazione è più difficile 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 la stessa ruolo di produzione compromessa 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 vero controllo
Un backup non testato è solo una speranza di archiviazione.
Le squadre che si riprendono bene non verificano solo che le operazioni 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 ripristino 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.
Le copie di backup non ti salvano. Le ripristini riusciti ti salvano.
Se testi solo la creazione di backup e non testi mai il ripristino sotto pressione, non hai validato la tua strategia di ripristino. Hai validato che i file possano accumularsi in qualche posto.
Checklist per i sviluppatori per la memorizzazione di database sicura
Questa è la checklist che voglio che le squadre utilizzino durante le revisioni di progetto, le revisioni di rilascio e la pulizia post-incidente.
Progettazione
- Abbiamo identificato chiaramente i campi sensibili: 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 client.
Implementazione
- La dati sono criptati in stato di riposo e in transito: per le vie del database, delle copie e dei percorsi di backup.
- Gli ruoli di applicazione e servizio sono definiti in modo stretto: nessun superutente condiviso per il traffico normale dell'applicazione.
- I segreti e le chiavi di crittografia sono gestiti al di fuori di code e della configurazione rilassata: con accesso controllato e tracciabilità.
- I cambiamenti di accesso e privilegi sensibili vengono registrati: 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 we test restores regolarmente: Includendo la decrittazione, l'avvio dell'applicazione e la revisione dell'accesso sui sistemi ripristinati.
- Do we audit la dispersione dei dati continuamente: Copia di backup, esportazioni di supporto, set di dati di sviluppo e ubicazioni di backup dimenticate.
Una buona conservazione dei dati in database non è una fase di progetto. È una disciplina ricorrente.
Domande frequentemente poste
È abbastanza buona l'encryption di default del provider cloud
È una linea di base forte, non una strategia completa. L'encryption di default 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 governance delle chiavi.
L'encryption 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. L'encryption 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 encryption, privilegi minimi, auditing, gestione delle chiavi e ripristino testato. I dettagli di implementazione cambiano perché le architetture di documenti, le architetture a chiave-valore 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 ai Capacitor e agli app Electron velocemente, con la consegna di pacchetti web firmati, controlli di distribuzione, protezione del rollback e osservabilità delle rilascio. Se il piano di risposta agli incidenti dipende dal fatto di poter distribuire riparazioni client-side velocemente dopo un errore di archiviazione, autenticazione o API Capgo è degno di valutazione come parte del lato operativo della ripresa.
