Prevenire la manomissione del record del database?

La prima cosa che noterei è che la maggior parte dei database di produzione ha un giornale che registra ogni modifica apportata al DB. Suppongo che qualcuno possa potenzialmente modificare il diario. In genere, mi aspetto che il journal venga archiviato offline utilizzando le istantanee o eseguendo il backup su base regolare. Quindi tirare fuori un cambiamento in tali scenari richiederebbe molta sofisticazione tecnica. Questo è probabilmente il modo più comune per "proteggere" da tali elementi oltre alla gestione dell'accesso. Naturalmente, se nessuno guarda il diario, questi cambiamenti potrebbero passare. Se si voleva veramente rafforzare questo, è possibile eseguire lo streaming del journal e provare a rilevare modifiche sospette. Ad esempio, un buon modo per gestire un libro mastro è di non aggiornare mai alcuna riga. Basta inserire nuove righe che rappresentano le modifiche all'account. Quindi se vedi un aggiornamento o cancella su una riga in questa tabella nel diario, sai che qualcosa non funziona. Se l'attore cattivo ha inserito una nuova riga, la modifica non verrà nascosta.

So che un altro tassello di questo è che tutto deve essere aggiunto in un senso contabile del doppio libro. Se il denaro entra o esiste un conto, un cambiamento uguale e opposto deve essere contabilizzato altrove. Se i numeri non riescono a bilanciare molte persone andranno fuori di testa.

Immagino che l'unico grosso problema potenziale con la metodologia che descrivi sia: se posso modificare la riga, cosa mi impedisce di calcolare una firma per la mia riga fraudolenta e di modificare anche quel campo? Come nota a margine, una delle cose che ha entusiasmato la gente sulla blockchain è che risolve il problema che stai chiedendo. Potresti voler saperne di più su come funziona.

OK, supponiamo che il modello di minaccia sia un amministratore non autorizzato con accesso a un database di importanza critica, come le transazioni bancarie. Cosa dovrei fare, data una grande quantità di tempo e denaro?

• L'accesso amministrativo al DB e l'accesso all'app che funziona con quel DB sono completamente disaccoppiati. Le persone che ne hanno uno non hanno l'altro. Se hanno bisogno di risolvere un problema, devono farlo insieme.
• L'app, quando aggiorna un record, firma crittograficamente il contenuto dell'intero record. Ciò esclude l'uso di qualsiasi chiave di autoincremento, valori generati dopo l'inserimento / dopo i trigger di aggiornamento, ecc. L'intera serie di campi importanti nel record dovrebbe provenire dall'app e firmata. Se il tempo di inserimento / aggiornamento è importante, quindi entrambi l'app e il DB dovrebbe fornire campi separati, il campo generato dall'app deve essere incluso nella firma.
• Ogni transazione eseguita sulle tabelle importanti viene immediatamente replicata dai mezzi del DB in un database di standby. Avrai comunque bisogno di un database di standby.
• La firma dei dati di ogni transazione effettuata sulle tabelle importanti è anche posta in modo indipendente su una casella remota dall'app. Questo è qualcosa che l'operatore DB non può controllare.
• Un processo di watcher indipendente continua a guardare sia i nuovi record nel database di standby, sia il flusso di firme provenienti dall'app. Se entrambi i componenti della coppia (transazione dal DB e firma dall'app) non arrivano entro un tempo ragionevole l'un l'altro, solleva un avviso. Se arrivano con lo stesso ID della transazione ma con valori di firma diversi, solleva anche un avviso.
• Un altro processo di osservazione esegue la scansione della tabella nel DB (può utilizzare lo standby) e controlla la data / ora della transazione della app e il tempo di aggiornamento fornito dal DB; se differiscono in modo significativo, solleva un avviso.
• Come ulteriore misura di sicurezza, l'app utilizza un dongle hardware (qualcosa come un yubikey, ma probabilmente un dispositivo più performante) per generare le firme dei dati. Il dispositivo non rivela mai la chiave privata che utilizza per generare le firme; la sua chiave pubblica è ben nota. Ciò impedisce a un operatore DB dannoso di rubare una chiave e quindi di creare / aggiornare una transazione nel DB e di creare una firma corrispondente per essa.
• L'archiviazione delle informazioni sulle transazioni critiche in un DB solo per aggiunta che tecnicamente non supporta gli aggiornamenti aiuta anche; può essere un DB separato se è necessario un DB aggiornabile per altre operazioni. Tale suddivisione, ovviamente, aumenta la complessità, ma consente di separare ulteriormente i diritti di accesso o persino l'accesso fisico ai database.

Quanto sopra non include alcuna considerazione di un operatore di app dannoso che potrebbe fornire dati falsi all'app. Per questo, generalmente viene utilizzato un altro (o più), a seconda della natura dell'app; questo è il motivo per es. una carta di credito ha un chip crittografico che canta le sue informazioni sulla transazione.

Le migliori pratiche del settore per questo scopo preciso: blockchain.

Tuttavia, questo non è adatto per molte società o sistemi esistenti.

Raccomando quindi che è meglio prevenire la manomissione e anche evitare di essere incolpati per i record manomessi. Ecco le best practice per questo:

• Se non lo hai già fatto, concediti un accesso privilegiato al tuo database usando il tuo account di dominio. Non account di database, non account di servizio, non account di gruppo, account di dominio personale

• Rimuovi tutti gli accessi al tuo database (ad eccezione del tuo account di dominio personale). Letteralmente, tutti e tutti gli account.

• Aggiungi solo quegli account che dovrebbero avere accesso al DB, usando sempre account di dominio personali (come i tuoi pari). Questo deve essere registrato in un logbook esterno, tale foglio di calcolo in un'unità condivisa .

• Questo registro deve contenere gli account che hanno accesso, quando è stato concesso l'accesso, quando dovrebbe essere revocato, la giustificazione per cui questa persona dovrebbe avere accesso, il livello di accesso concesso, il nome delle persone e dei gruppi lavoro per, quale responsabile ha approvato l'accesso (e si assume la responsabilità per l'uso improprio) e, naturalmente, quale dba ha concesso l'accesso e inserito la riga nel logbook.

• Questo logbook deve essere accessibile solo a chi ha accesso sufficiente a concedere / revocare l'accesso ad altri utenti

• Utilizza i privilegi minimi che puoi concedere caso per caso.

• Non aggiungere mai gruppi di domini. Quindi, non aggiungere mai gruppi "myappadmins" o "amministratori di domini".

• Se è necessario disporre di alcuni account di servizio, è necessario controllare la password. Questo significa che dovresti essere in grado di cambiare la password e darla solo alle persone che "ti fidi". Questo deve essere registrato nel logbook esterno, in modo che tu sappia chi conosce la password, così come chi dovresti avvisare quando la password cambia.

  • Ogni team di consumatori deve avere il proprio set di account di servizi PER APPLICAZIONE, in modo che non possano condividerlo con altri team senza essere notato. Inoltre, creale per ambiente (myapp_svc_dev, myapp_svc_prod, ecc.), Quindi solo i leader conoscono la password degli account prod.

Con tutte queste misurazioni succederanno molte cose:

1. Ridurrai la possibilità che le persone cambino i dati. Dal momento che concedi l'accesso solo a coloro di cui ti fidi tecnicamente parlando, è meno probabile che accada (inoltre, non tutti hanno accesso in scrittura).
2. Poiché solo gli account personali sono collegati al sistema, dovresti essere in grado di individuare "chi ha rotto i dati".
3. A causa del giornale di bordo, è possibile rendere facilmente conto a coloro che hanno infranto i dati, se stanno abusando del loro accesso concesso per cose al di fuori della giustificazione originale che hanno fornito. Questo vale anche per i manager che hanno approvato le richieste.
4. Dato che non ci sono accessi ai gruppi, non è come se qualcuno potesse aggiungere persone ai gruppi e farla franca con l'accesso.
5. Se esegui un controllo e rilevi che ci sono account con accesso che non sono nel logbook, puoi immediatamente revocarli tutti senza preavviso (dato che non sono mai stati giustificati a esserci), senza essere accusati (poiché qualcuno ha violato il processo di sicurezza). Inoltre, questo dovrebbe iniziare immediatamente un'indagine per verificare chi sta violando il processo di accesso alla concessione.
6. Poiché gli account di servizio sono controllati dall'utente, è possibile modificare la password in qualsiasi momento dell'anno e solo quelli all'interno del logbook devono essere avvisati. Se sai che c'è una perdita, puoi dire che c'è una perdita e non fornirai più tale accesso all'account (poiché gli account di servizio sono di squadra, interesserebbe solo una squadra).
7. Le persone si rendono immediatamente conto che possono essere segnalate se ci sono documenti modificati (o il malcontento dei conti, perdite sulle password per gli account di servizio, ecc.) e che il loro manager verrà avvisato, ecc., quindi molte persone semplicemente si astengono dal richiedere l'accesso a tutti (al contrario del "non fa male ho accesso a questo sistema"), e persino i dirigenti ci pensano due volte prima di approvare. La burocrazia funziona su questo caso.

Sebbene ciò non impedisca completamente la manomissione, lo riduce molto e non richiede modifiche al codice né penalizzazioni delle prestazioni. Aiuta anche a individuare situazioni di pesce una volta che sono (sono stato in riunioni in cui ho visto qualcuno spiegare qualcosa, quindi accedere ad un account di servizio che appartiene ad un altro team, ad esempio)

Questo ha funzionato molto bene con le grandi aziende, quindi spero che funzioni per te.