Si spedisce una versione in orario serale, si scorre le notifiche e si nota 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 si erano voluti. 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 dei dati.
Questo si manifesta in tutti i sistemi reali. Le squadre abilitano la crittografia una volta e si aspettano di essere finite. Conservano 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 si stanno costruendo app mobili o web, la sicurezza dei dati deve coprire tutto: il database principale, le copie, gli esporti, i log, i backup e le chiavi che controllano tutto.
Se si sta anche lavorando per risolvere l'autenticazione per il prossimo app, ricordi che l'autenticazione e la sicurezza dei dati di archiviazione risolvono modi di fallimento diversi. L'autenticazione decide chi dovrebbe entrare. La sicurezza dei dati limita i danni quando qualcuno fa, o quando i dati si diffondono attraverso un percorso che non si aspettava. Per le squadre che stanno spedito app con faccia al cliente, è anche utile allineare le decisioni di archiviazione con controlli adiacenti come API standard di sicurezza per la conformità degli store di app.
L'urgenza non è teorica. La produzione globale dei dati ha raggiunto 64,2 zettabyte nel 2020 e si prevede che salirà a 180 zettabyte entro il 2025 secondo la sintesi di archiviazione dei dati di Edge Delta. In scala così grande, lo storage sicuro non è più una questione di hardening e diventa architettura
Indice dei contenuti
- Perché la sicurezza dei database è più di una semplice password
- Capire il modello di minaccia del tuo database
- I pilastri fondamentali dello storage sicuro dei database
- Modelli di implementazione pratici per la crittografia
- Migliorare la gestione delle chiavi e dei segreti
- Progettare una Strategia di Backup e Ripristino Resiliente
- Un Checklist per lo Sviluppatore per la Storizzazione di Database Sicura
- Domande Frequenti
Why La Sicurezza dei Database È Più di una Password
Una password protegge un punto di ingresso. Non protegge i dati dopo che una credenziale viene compromessa, 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 dei 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 silenziose
La maggior parte delle fallite di memorizzazione dei dati più dannose non sembrano drammatiche all'inizio. Sembrano ordinarie.
- Una comodità per lo sviluppatore diventa un rischio di produzione: Una credenziale di amministrazione condivisa viene riutilizzata da uno script perché rotarla sarebbe andata a rompere la distribuzione.
- Un set di dati copiato sfugge al controllo: I record di produzione vengono clonati in staging per poter riprodurre un bug.
- Un backup diventa il punto debole: La produzione ha controlli forti, ma la politica del bucket di ripristino o del snapshot non lo è.
Regola pratica: If 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 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 nelle sue pratiche 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 nella pratica è noioso e coerente. Cifra i file dei database. Cifra le connessioni. SPLITTA i ruoli dei servizi. Elimina l'accesso amministrativo permanente dove puoi. Registra le operazioni sensitive. Avvisa sui modelli di accesso che non corrispondono all'uso normale. Nessuna di queste cose è glamour, ma previene vere infiltrazioni.
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 dei database sicuro funziona nello stesso modo. I password sono solo la porta principale.
Capire il tuo modello di minaccia per i database
Prima di scegliere i controlli, mappa i modi in cui il tuo sistema può fallire. Un modello di minaccia per il storage dei database non deve essere accademico. Deve dirti chi potrebbe toccare i dati sensibili, come lo farebbe e cosa accadrebbe se ci riuscisse.
Dati sensibili sono raramente contenuti in una sola base di dati di produzione ordinata. Le linee guida moderne enfatizzano la scoperta e la gestione della postura perché le informazioni sensibili spesso finiscono in copie, backup, log e ambienti di sviluppo, quindi i fallimenti spesso avvengono al di fuori della base di dati principale, come notato in Panoramica di Sentra sulla sicurezza dei dati cloud e sulla gestione della postura. Per questo motivo, il piano di risposta agli incidenti dovrebbe includere scenari come esposizione del fornitore e set di dati copiati. Questo è anche dove diventano pertinenti i libri di procedure di risposta più ampi, come pratiche di risposta alle violazioni dei terzi 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:
Registri dei clienti
- come profili, storia degli ordini, metadati relativi ai pagamenti o contenuti relativi alla salute. Materiali di autenticazione
- come hash delle password, registri delle sessioni, token di refresh o __CAPGO_KEEP_0__ segreti. such as password hashes, session records, refresh tokens, or API secrets.
- Dati operativi, come registri di audit, code dei job, note amministrative e esportazioni di supporto. Risorse di ripristino, come snapshot, dump logici, registri 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 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 di cui tutti si occupano per primo. L'iniezione SQL, i token __CAPGO_KEEP_0__ rubati, le credenziali cloud divulgate, i pannelli amministrativi esposti, le dipendenze vulnerabili. Il filo conduttore è un outsider che ottiene un percorso ai dati.
Domande da fare:
This is the bucket everyone thinks about first. SQL injection, stolen API tokens, leaked cloud credentials, exposed admin panels, vulnerable dependencies. The common thread is an outsider getting a path to data.
Un credenziale di server rubata può leggere più di un servizio necessita?
- Potrebbe un utente accedere a dati sensibili?
- Potrebbe un utente accedere a dati sensibili?
- Sarebbe leggibile un snapshot copiato da solo?
Minacce interne
Questa include insider maliziosi e dipendenti ben intenzionati con troppo accesso. Un ingegnere di supporto esporta dati per risolvere un ticket. Un contrattista tiene una copia locale. Un amministratore di piattaforma può leggere righe di produzione anche se il suo lavoro non lo richiede.
Cosa aiuta qui è la separazione dei compiti, l'accesso basato sul ruolo 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 di database sono più deboli di quanto sembri.
Esposizione accidentale
Questa è 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 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 di Archiviazione di Database Sicura
Una violazione raramente proviene 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 posticipata continuamente. L'archiviazione di database sicura deve interrompere quella catena in più punti e continuare a farlo mentre il sistema cambia.
Raccogliamo il lavoro in quattro pilastri: crittografia, controllo di accesso, auditing e minimizzazione. La sicurezza dei backup e della ripristino è importante, ma meritano un trattamento operativo separato perché i dati ripristinati spesso diventano un nuovo percorso di esposizione se nessuno verifica dove vengono depositati, 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 da una rete interna, i dati crittografati sono molto più difficili da trasformare in registri dei clienti.
A livello di riposo, la crittografia protegge i file del database, i snapshot e gli artefatti di backup. In transito, TLS protegge le connessioni tra server di applicazione, proxy e motore del 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 le raccomandazioni relative ai dati in riposo.
Il trade-off è operativo, non teorico. La crittografia aiuta solo se il trattamento delle chiavi è separato dal percorso dei dati e viene mantenuto nel tempo. La crittografia con involucro funziona come una chiave master per l'edificio e una chiave dell'ufficio chiusa. Un servizio di gestione delle chiavi protegge la chiave master, e quella chiave master crittografa le chiavi di dati a breve termine utilizzate per i registri o i file reali. Quel design limita l'esposizione durante la rotazione e rende più facile revocare o sostituire il materiale di chiave senza riscrivere tutto contemporaneamente.
Gli squadri si mettono nei guai quando abilitano la crittografia una volta e si fermano lì. Controllate dove vivono le chiavi, chi può utilizzarle, se la rotazione è programmata e se gli archivi vecchi dipendono ancora da versioni di chiave dimenticate.
Limits di accesso di controllo riducono 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 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 di tabella ampio.
Un modello pratico assomiglia a questo:
- Ruolo dell'app web: accesso di lettura e scrittura limitato per le tabelle alle spalle delle richieste degli utenti.
- Ruolo del lavoratore: accesso ai record necessari per i lavori che esegue.
- Ruolo degli analytics: accesso di sola lettura ai dati set 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 accoppiata con la 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 piena. 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, nelle costruzioni 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:
- L'attività di autenticazione: accessi riusciti, accessi falliti, utilizzo di token, e sessioni amministrative.
- Cambiamenti di autorizzazione: autorizzazioni, revocazioni, creazione di ruoli, modifiche alle politiche, e modifiche allo schema.
- Modelli di accesso sensibili: lettura in blocco, esportazioni di grandi dimensioni, percorsi di query insoliti, e accesso al di fuori delle ore o delle reti di origine previste.
- 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 è 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 con il minor sforzo di ingegneria.
Mantieni meno. Conserva per meno tempo. Copia in meno posti. Se una funzionalità ha bisogno di un'età di età, non memorizza 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 viventi, non ripristina i backup di produzione e chiamalo temporaneo.
This is also an operational discipline. Retention schedules need enforcement. Old exports need deletion. Downstream systems need review because risk grows every time sensitive fields are replicated into search indexes, caches, data lakes, mobile storage, and ad hoc CSV files. Per gli Capacitor app @capgo/capacitor-data-storage-sqlite e @capgo/capacitor-fast-sql possono fornire una persistenza crittografata sul lato dell'applicazione, ma ancora devi decidere cosa non dovrebbe essere mai memorizzato localmente.
Il punto di questi pilastri non è la perfezione al 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 dati di database 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 ha bisogno di interrogarlo e quanto complessità il team può supportare. L'errore è scegliere il modello più forte e poi implementarlo male.
La TDE è la base più veloce
Crittografia dei Dati Trasparente, o TDE, è spesso il posto più facile dove iniziare. L'engine del database crittografa i file sul disco e li decrittografa quando li legge in memoria. Le applicazioni spesso non richiedono code modifiche.
This is a strong baseline for:
- Protezione a livello di database
- Requisiti di conformità a livello di archiviazione
- Riduzione del rischio da dischi rubati, snapshot o accesso diretto a file
La TDE non protegge contro tutto. Se un attaccante ottiene accesso valido al database, l'engine servirà ancora dati decrittati. È per questo che la TDE aiuta con il compromesso 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 crittografa i campi selezionati, quindi scrive ciphertext in archiviazione. Funziona bene per colonne particolarmente sensitive come ID governativi, dettagli bancari, segreti di recupero o note private.
Quell'extra controllo comporta sacrifici:
- Si ha più complessità: selezione delle chiavi, librerie di crittografia, comportamento di rotazione e gestione degli errori.
- La query diventa più difficile: ricerca esatta, ricerca parziale e indicizzazione diventano problemi di progettazione.
- Gli sviluppatori hanno bisogno di disciplina: Un singolo atto di scorciatoia in uno script di migrazione può eludere il vostro modello intero.
Un semplice pattern di pseudocodice assomiglia a questo:
| Passo | Azione |
|---|---|
| 1 | Leggi il campo di testo in chiaro dalla richiesta |
| 2 | Chiedi al servizio di chiave una chiave di cifratura dei dati o utilizza una chiave locale avvolta |
| 3 | Cifra 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 uno stato di sincronizzazione sensibile su un dispositivo, non assumere che lo storage mobile sia sicuro di default. Utilizza pattern consapevoli della piattaforma come quelli discussi in secure storage per token offline in Capacitor.
La crittografia dell'invio è una sicurezza all'interno di una sicurezza
La crittografia dell'invio sembra intimidatoria, ma l'idea è semplice. Si crittografano i dati con una chiave, quindi si crittografano quella chiave con un'altra, meglio protetta, chiave.
Pensate a esso come 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 con maggiore protezione prima di poter aprire qualcosa di utile.
Flusso tipico:
- Generare una chiave dei dati Per inciso, per il record, il file o la batch.
- Crittografare 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.
- Unpacka solo durante le letture autorizzate.
Consiglio del campo: Usa 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 di dati a breve durata per il lavoro di cifratura effettivo, mentre un KMS o un HSM protegge la chiave master utilizzata per avvolgerle e svolgerle.
Comparazione dei modelli di cifratura
| Modello | Complessità di implementazione | Impatto sulla prestazione | Migliore per |
|---|---|---|---|
| Cifratura del disco o del volume | Basso | Basso | Infrastruttura di protezione per server e archiviazione associata |
| Chiarificazione della crittografia dei dati | Basso a moderato | Basso a moderato | Protezione totale del database con modifiche minimi all'applicazione |
| Crittografia a livello di applicazione | Moderato a alto | Varia a seconda dell'uso dei campi e del disegno delle query | Campioni altamente sensibili e separazione rigorosa necessarie |
| Crittografia in busta | Moderato a alto | Moderato | Systemi che richiedono un isolamento delle chiavi più forte e un controllo scalabile delle chiavi |
La regola pratica è semplice. Inizia con una linea di base forte come TDE o crittografia gestita in stato di riposo. Aggiungi la crittografia a livello di campo o di involucro solo dove la sensibilità dei dati e il modello di minaccia giustificano l'ingegneria aggiuntiva.
Masterizzare la gestione delle chiavi e dei segreti
Un incidente 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 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.
Una base di dati crittografata con chiavi gestite male funziona come un'area di servizio chiusa con la targhetta di accesso appesa alla maniglia. Le linee guida del governo fanno lo stesso punto. La crittografia da sola non chiude il divario se gli squadre saltano 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 gli squadre sbagliano
- Secrets in source code: Il segreto in __CAPGO_KEEP_0__:
- credenziali hardcoded, certificati incorporati o script di utilità che diventano gradualmente dipendenze di produzione. i file passano tra i laptop, sono memorizzati in cartelle condivise o vengono commessi durante una rapida correzione.
- Le variabili di ambiente con controlli deboli: Convenienti, ma spesso esposti attraverso i log di compilazione, la storia della shell, i rapporti di crash o le ampie autorizzazioni di esecuzione.
- Assenza di proprietà per la rotazione: Le chiavi esistono per anni perché nessun team possiede il piano di rilascio, di rollback e di rilascio.
- Segreti di alta autorità condivisi: Un singolo credenziale utilizzato dagli applicativi, dagli ingegneri e dall'automazione, il che rende molto più difficile l'audit e la contenimento.
Se stai standardizzando come vengono memorizzati i segreti delle app e dell'infrastruttura, una pratica di riferimento per gestire le variabili di ambiente sicure può aiutare i team a spostarsi dall'ad hoc sprawl dei segreti.
Cosa rappresenta un buon gestione delle chiavi
Usa un Quando la politica centralizzata, il controllo degli accessi, i registri di audit e la rotazione programmata contano più del controllo hardware personalizzato. Utilizza un Quando il rischio, le esigenze di conformità o le regole di protezione delle chiavi e della firma 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 con envelope è un buon modello mentale qui. Funziona come tenere il denaro in una piccola cassaforte chiusa, poi mettere quella cassaforte dentro una cassaforte di un banca. L'applicazione gestisce le chiavi di dati a breve vita 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 si può 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 dopo.
- Separare le funzioni: il servizio che legge i dati dei clienti non dovrebbe poter anche modificare la politica delle chiavi o disabilitare i registri.
- Registrare gli eventi chiave sensibili: la creazione delle chiavi, la rotazione, le richieste di decrittazione, gli accessi falliti e le modifiche della politica dovrebbero essere tutti visibili.
- __CAPGO_KEEP_0__ __CAPGO_KEEP_0__
- Test percorsi di riconciliazione: Rotare una chiave di avvolgimento è spesso più facile che riconciliare i dati dell'applicazione, ma entrambi richiedono libri di procedure e passaggi di rollback.
- Disabilita e ritira deliberatamente le vecchie segretezza: Lascia tempo per il passaggio di cutover, quindi elimina le credenziali obsolete affinché non diventino 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 dei segreti nelle pipeline CI/CD al posto di trattare le credenziali delle pipeline come eccezioni temporanee.
Una regola è semplice. L'applicazione code dovrebbe richiedere operazioni crittografiche da sistemi fidati, non portare chiavi master crude nell'ambiente.
La migliore progettazione di crittografia nella tua pila non conta più una volta che un sviluppatore, una pipeline o uno strumento di supporto può copiare la chiave master nel posto sbagliato.
Progettare una Strategia di Backup e Ripristino Resiliente
I backup sono parte della conservazione dei dati di database sicuri, non un compito di amministrazione separato. Se la produzione è protetta e i backup non lo sono, l'attaccante seguirà la strada più facile.
Le linee guida independenti di conservazione dei dati raccomandano di mantenere i sistemi di backup e ripristino al livello di protezione della produzione perché gli incidenti di ransomware e malware lasciano spesso backup sicuri e testati come l'unica via di ripristino possibile, secondo Guida di Hypertec per il storage dei dati sicuri.
Le copie di sicurezza hanno bisogno di un proprio confine di sicurezza
Un design di copia di sicurezza resiliente ha alcune proprietà:
- Le copie di sicurezza sono crittografate durante il trasporto e al riposo.
- Le credenziali delle copie di sicurezza sono separate dalle credenziali di produzione.
- I controlli di cancellazione e di conservazione sono più difficili da abusare rispetto all'accesso normale all'applicazione.
- I target di ripristino non diventano ambienti di produzione ombra con controlli deboli.
Un comune modo di fallimento è quello di memorizzare le copie di sicurezza crittografate lasciando che lo stesso ruolo di produzione compromesso le possa cancellare. Un altro è quello di ripristinare in un ambiente temporaneo con accesso ampio degli ingegneri e senza logging.
I percorsi di recupero meritano la stessa attenzione dei percorsi principali.
Il testing di ripristino è il vero controllo.
Una copia di sicurezza non testata è solo una speranza di archiviazione.
Gli team che si riprendono bene non si limitano a verificare che le attività di copia di sicurezza siano state completate. Provatano che il ripristino funziona, che i dati recuperati sono utilizzabili e che le chiavi di decrittazione, le impostazioni di connessione e i servizi dipendenti siano tutti allineati quando servono.
- Routine restore drills in ambienti isolati.
- Verifica della funzione dell'applicazione dopo il ripristino del database, non solo la restituzione dei file.
- Controlla la disponibilità delle chiavi in modo che i backup crittografati possano essere decrittografati.
- Recensione dell'accesso sui sistemi ripristinati per prevenire che i dati sensibili diventino visibili a tutti durante un incidente.
I backup non ti salvano. I ripristini riusciti ti salvano.
Se testi solo la creazione dei 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 sviluppatori per la memorizzazione di database sicuri
Questa è la checklist che voglio che le squadre utilizzino durante le revisioni di progetto, le revisioni di rilascio e la pulizia post-incidente.
Design
- Abbiamo identificato chiaramente i campi sensibili: dati personali, materiali di autenticazione, registri finanziari e qualsiasi elemento soggetto 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 luogo in cui i dati vivranno: produzione, staging, log, esportazioni, sistemi di analisi, backup e dispositivi clienti.
Implementation
- I dati sono crittografati in stato di riposo e in transito: per il database, repliche e percorsi di backup.
- Le ruoli di applicazione e servizio sono definiti in modo stretto: nessuna superutente condivisa per il traffico normale dell'app.
- Vengono gestiti i segreti e le chiavi di crittografia al di fuori di code e la configurazione rilassata: con accesso controllato e tracciabilità.
- Ricordiamo gli accessi e le modifiche di 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 normali operazioni: non è un caos annuale.
- Testiamo i ripristini regolarmente: compreso 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 localizzazioni di backup dimenticate.
Un database di archiviazione sicuro non è una fase di progetto. È una disciplina ricorrente.
Frequenti domande
È sufficiente 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 solitamente 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 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 recupero 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.
Come è diverso il tokenization dall'encryption
L'encryption trasforma i dati in modo che i sistemi autorizzati possano decifrarli con la chiave giusta. Il tokenization sostituisce i valori sensibili con valori surrogati e mantiene i dati originali separati. Il tokenization può ridurre l'esposizione nelle workflow delle app, ma aggiunge complessità di progettazione del sistema e non elimina la necessità di controlli di archiviazione forti.
Capgo aiuta le squadre a distribuire riparazioni ai Capacitor e agli app Electron in modo rapido, con la consegna di pacchetti web firmati, controlli di rilascio, 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 è degno di essere valutato come parte del lato operativo della ripresa.
