Sicurezza del database 101:comprensione dei privilegi di accesso al database

I dati sono il nuovo oro per le grandi aziende e organizzazioni Sono considerati la linfa vitale della maggior parte delle aziende moderne e c'è una miniera di opportunità per vendere o commercializzare per il vasto pubblico di Internet. Per le grandi società di e-commerce o social media, i dati guidano la loro capacità di generare grandi entrate e guadagni per i quali i dati sono strettamente protetti e hanno una protezione sofisticata contro qualsiasi attacco dannoso e intrusione online.

Quindi i dati come l'oro, il loro stato prezioso inizia una volta elaborati. Il suo valore grezzo è pieno di confusione come se fosse un gigantesco bocconcino non ordinato Una volta strutturata la sua essenza, il valore dei dati si moltiplica. Immagina, se hai un sito di istruzione che consente agli utenti di pagare. Una volta che hai tonnellate di lezioni e moduli che il tuo pubblico di destinazione può imparare, sviluppare e guadagnare un certo grado di produttività, hai colto il gusto dell'opportunità e del successo poiché hai la possibilità di regolare le tariffe prima che possano ottenere i dati strutturati che desiderano . Anche se questo suona come il sogno di successo di tutti, quando si tratta di big data e della sua essenza sottostante, ci sono un sacco di complicazioni per elaborarli e un'importante preoccupazione sono le minacce al tuo database.

Le minacce ai database in generale hanno numerosi ed estesi settori da esaminare ed esaminare. Tuttavia, le cause più comuni sono il furto di dati e le violazioni dei dati. Un'altra minaccia comune sono i privilegi estesi o l'accesso a database assegnati e/o forniti in modo errato a un utente. La protezione dell'intero host del server è una preoccupazione per chiunque gestisca un database. Hai rafforzato la tua sicurezza e affronta tutti i tipi di attacchi applicabili come intercettazioni, alterazioni, riproduzione e denial of service (DDoS) non solo per il database ma anche per l'intero stack sottostante che ha accesso o che si interfaccia con l'archiviazione dei dati.

In questo blog, discuteremo della portata della necessità e del motivo per cui è necessario comprendere e disporre dei privilegi di accesso al database.

Pericoli dei privilegi di accesso errati

Dobbiamo inevitabilmente condividere o almeno creare un utente sia a livello fisico che tecnico. Mentre, fornire l'accesso a qualcun altro significa che ti fidi della persona. Ciò significa anche che la persona autorizzata deve comprendere il pericolo e il pericolo della condivisione dell'accesso e dei dati dal mondo esterno.

Il punto più importante per proteggere i tuoi privilegi di accesso è il livello di comprensione della sicurezza tra i tuoi ingegneri come un amministratore di database, un tecnico della sicurezza o un amministratore del server. Se la comprensione è scarsa o manca di conoscenza ed esperienza, in particolare delle vulnerabilità e delle esposizioni più aggiornate, può essere un problema per l'organizzazione o l'azienda.

Ci sono cose di base che devono essere comprese e prese in considerazione in modo che sia minimo o almeno non possa essere intromesso o esposto. In caso contrario, ciò potrebbe mettere a rischio i tuoi dati dal mondo esterno o almeno per la persona o le persone sbagliate. Forse per rubare i tuoi dati e usarli per il loro bene per guadagnare finanziariamente o possono riscattarli da te e chiedere denaro in cambio della tua scarsa implementazione della sicurezza.

In questa sezione, vediamo alcune cause comuni di queste minacce alla sicurezza.

Condivisione del privilegio di accesso root

Per un ambiente on-premise, un normale caso di violazione del database si basa principalmente sul rischio di concedere l'accesso come root a livello di sistema operativo oa livello di software del database. Ci sono casi in cui la password di root viene distribuita ed esposta a più persone che dovrebbero essere limitate solo agli amministratori che lavorano esclusivamente sul sistema. Ciò potrebbe verificarsi a causa della mancanza di una checklist di sicurezza o di misure nel protocollo prima di implementare i privilegi di accesso. Avere un elenco di controllo di sicurezza aiuta a tenere traccia di eventuali accessi e privilegi che potrebbero esporre rischi e pericoli, specialmente quando un utente specifico del sistema operativo è esposto a un intruso. L'elenco di controllo ti aiuta anche a discutere o avere una panoramica delle misure di sicurezza in atto e implementate come protocollo per la tua organizzazione.

Ad esempio, un utente che ha accesso come root può causare molti danni come rimuovere tutti i dati dall'unità di archiviazione fisica, reimpostare la password di root, creare il proprio utente/password che sembri come un utente legittimo (può essere utilizzato per molto tempo per raccogliere dati a meno che non venga catturato in anticipo), sudo a un utente del sistema operativo diverso come l'utente postgres e molte cose più spaventose per l'intruso.

Se stai usando MongoDB, un utente con accesso root può accedere al tuo server di database. Finché l'intruso può individuare il tuo /etc/mongod.conf o il tuo file di configurazione mongodb e individuare il percorso della tua chiave, è facile accedere. Ad esempio, l'utilizzo di questo comando consente di accedere,

[[email protected] ~]# mongo -u __system -p "$(tr -d '\011-\015\040' < /etc/mongo-cluster.key)" --authenticationDatabase local --eval "db.adminCommand( { listDatabases: 1, nameOnly:1 } )"

Considera una normale installazione di MySQL, un accesso root può essere lasciato senza una password per l'accesso a localhost. È facile ottenere l'accesso una volta che sei root. L'accesso a file come $HOME/.my.cnf o la visualizzazione del contenuto di /etc/my.cnf ti consentirà di accedervi facilmente.

Si consiglia vivamente di limitare o semplicemente concedere l'accesso come root y al minor numero di persone che lavorano direttamente con il server per aggiornare i pacchetti, gli aggiornamenti di sicurezza e applicare le patch richieste da il team di sviluppo.

Uso corretto dei sudoer

Il software di database open source mainstream come PostgreSQL, MySQL/MariaDB, MongoDB richiede la creazione di un utente del sistema operativo specifico. L'utente del sistema operativo richiede un ruolo specifico limitato per consentire la gestione delle sue capacità all'interno delle funzionalità del database. È necessario impostare autorizzazioni di lettura e scrittura adeguate per il percorso del dispositivo di archiviazione sottostante. Tuttavia, ci sono casi in cui alcuni che utilizzano questi utenti specifici per il software del database hanno privilegi sudo che sono anche in grado di accedere all'utente designato esclusivamente per l'accesso al database. I privilegi dell'utente nel sistema operativo devono essere limitati ed è meglio limitarne l'accesso in base al ruolo. Ad esempio, per Percona Server CVE-2016-6664, sebbene ciò sia stato corretto, questo tipo di vulnerabilità è un esempio di un possibile attacco da parte di un utente specifico che ha accesso all'account MySQL e ottiene l'accesso come root. Gli utenti di Sudo devono essere esaminati e fatti capire che il ruolo è limitato solo a svolgere un lavoro specifico.

L'abilitazione del sistema di auditing Linux come auditd può aiutare a migliorare la sicurezza poiché aumenta i privilegi di accesso trascurati a livello di sistema operativo che potrebbero portare a vulnerabilità di sicurezza del database. SELinux e AppArmor sono buoni esempi di moduli di sicurezza per il tuo ambiente Linux che ospitano il tuo sistema di database per aiutare a migliorare la tua sicurezza contro intrusi o violazioni che metterebbero a rischio i tuoi dati.

Concessione dei privilegi di accesso al database

I database open source tradizionali offrono un elenco granulare di privilegi che possono essere personalizzati per essere assegnati solo a un'azione specifica per un utente specifico. Questo è un modo completo per aiutare gli amministratori di database ad avere in modo sicuro la separazione dei dati e l'azione mirata in base a privilegi specifici.

privilegi di accesso comuni

I tuoi privilegi più comunemente usati si basano su queste tre categorie:

In grado di leggere/trovare come SELECT, SHOW VIEW, FIND
In grado di inserire/aggiornare/eliminare come INSERT, UPDATE, DELETE, REMOVE
In grado di eseguire azioni amministrative come CREATE USER, CREATE ROLE, ALTER, REPLICATION, DROP USER/TABLES/ SCHEMA, operazioni di uccisione, ecc.

Queste categorie possono essere estese a privilegi più raffinati in base alla tua lista di controllo di sicurezza. È bene definire un utente specifico da creare con privilegi specifici per un'attività specifica. Ad esempio, un'applicazione può avere più utenti con i propri privilegi designati assegnati. Sebbene l'applicazione possa essere complessa con questo tipo di implementazione. Ci sono casi in cui la connettività per utente può richiedere molte risorse, come l'utilizzo di ORM come Hibernate, ad esempio. D'altra parte, dipende dalla progettazione architettonica dell'applicazione. Lo scopo di una base per utente in un'applicazione può aiutare a mantenere un privilegio di accesso al database più raffinato ed evitare di danneggiare i tuoi dati da eliminazioni, aggiornamenti indesiderati o un'iniezione SQL che attacca il tuo database.

Nella maggior parte dei casi, un'applicazione utilizza un utente per connettersi al database che è limitato solo alle sue azioni specifiche per l'esecuzione dell'applicazione. È meglio progettare il privilegio utente dell'applicazione solo per l'accesso in lettura-scrittura. Mentre se sono richieste azioni amministrative, uno specifico script, demone o modulo nell'accesso all'applicazione deve essere separato dagli utenti normali.-.

Accesso al database da evitare

PostgreSQL e MySQL/MariaDB hanno questa opzione per concedere a un utente TUTTI i privilegi. Per PostgreSQL, è anche meglio avere il tuo utente con NOSUPERUSER. Se possibile, questo deve essere evitato a tutti i costi. Questo privilegio può eseguire la maggior parte di ogni azione che può potenzialmente distruggere o danneggiare i tuoi dati preziosi. Puoi utilizzare TUTTI i privilegi per il tuo accesso come amministratore o root, ma sono limitati solo agli utenti che richiedono i super privilegi per svolgere attività amministrative e gestire i dati.

Accesso per tabella o per schema

È buona norma fornire l'accesso a un utente solo per le tabelle richieste. . Pertanto, anche se l'utente dispone di alcuni privilegi di amministratore, qualsiasi danno riguarda solo un insieme limitato di tabelle. O puoi impostare su uno schema a livello; fornire l'accesso a una tabella limitata fornisce un tipo granulare di privilegi e ti aiuta a proteggere i tuoi dati.

Accesso limitato al solo host

La connessione tramite l'indirizzo IP della sua risorsa aiuta a limitare l'accesso ai tuoi dati. Evita di usare '%' in modo tale che in MySQL, ad esempio,

GRANT SELECT, INSERT, DELETE ON mydb TO [email protected]'%' IDENTIFIED BY 'password';

L'entità del danno è esposta a qualsiasi host a cui connettersi e non è quello che volevi accadesse. Impone vulnerabilità e la sfida per intromettersi nel tuo database è molto bassa.

Per PostgreSQL, assicurati di aver impostato il tuo pg_hba.conf e l'utente solo al suo limite specifico di host. Questo vale anche per MongoDB per il quale puoi impostarlo nel tuo file di configurazione MongoDB o /etc/mongodb.conf. In MongoDB, puoi giocare con le restrizioni di autenticazione e impostare rispettivamente clientSource o serverAddress, ma solo per cui stai richiedendo al client o all'utente di connettersi o di essere convalidato.

Controllo dell'accesso basato sui ruoli

Il controllo dell'accesso basato sui ruoli (RBAC) nei database fornisce un modo conveniente per gestire l'utente o un modo semplice per raggruppare un utente con il suo privilegio designato collegato a un elenco di utenti o a un gruppo di utenti.

Anche se devi tenere presente che i ruoli sono gestiti in modo diverso in qualsiasi database open source. Ad esempio, MySQL ha definito i ruoli come segue,

Un ruolo MySQL è una raccolta denominata di privilegi. Come gli account utente, ai ruoli possono essere concessi e revocati privilegi.

A un account utente possono essere assegnati ruoli, che concede all'account i privilegi associati a ciascun ruolo. Ciò consente l'assegnazione di insiemi di privilegi agli account e fornisce una comoda alternativa alla concessione di privilegi individuali, sia per concettualizzare le assegnazioni di privilegi desiderate che per implementarle.

MongoDB definisce il ruolo con RBAC come,

MongoDB utilizza Role-Based Access Control (RBAC) per governare l'accesso a un sistema MongoDB. A un utente vengono concessi uno o più ruoli che determinano l'accesso dell'utente alle risorse e alle operazioni del database. Al di fuori delle assegnazioni di ruolo, l'utente non ha accesso al sistema.

Mentre in PostgreSQL,

PostgreSQL gestisce i permessi di accesso al database utilizzando il concetto di ruoli. Un ruolo può essere considerato come un utente del database o un gruppo di utenti del database, a seconda di come è impostato il ruolo. I ruoli possono possedere oggetti di database (ad esempio tabelle e funzioni) e possono assegnare privilegi su tali oggetti ad altri ruoli per controllare chi ha accesso a quali oggetti. Inoltre, è possibile concedere l'appartenenza a un ruolo a un altro ruolo, consentendo così al ruolo di membro di utilizzare i privilegi assegnati a un altro ruolo.

Il concetto di ruoli sussume i concetti di "utenti" e "gruppi". Nelle versioni di PostgreSQL precedenti alla 8.1, utenti e gruppi erano tipi distinti di entità, ma ora ci sono solo ruoli. Qualsiasi ruolo può agire come utente, gruppo o entrambi.

Sebbene questi database implementino i ruoli specifici per il loro utilizzo, condividono il concetto di assegnare ruoli all'utente per assegnare i privilegi in modo conveniente. L'utilizzo dei ruoli consente agli amministratori dei database di gestire gli utenti richiesti per accedere o accedere al database.

Immagina di avere un elenco di utenti che devi gestire o un elenco di utenti che possono essere eliminati o revocati quando non sono più necessari. In alcuni casi specifici, se una determinata attività necessita di lavoro, gli amministratori di database possono creare utenti con ruoli già attivi. Questi utenti creati possono essere assegnati a un ruolo specifico solo per un breve periodo, quindi revocati quando non sono necessari.

Gli audit aiutano anche a separare gli utenti che sospettano di vulnerabilità o esposizione dei dati, quindi in tal caso aiutano a gestire gli utenti con ruoli molto facilmente.

Sistema di gestione degli utenti

Se la sicurezza dei tuoi dati viene gestita e implementata in modo appropriato, ti spiana la strada al successo. Anche se non esiste una soluzione perfetta poiché anche le vulnerabilità e le intrusioni si evolvono sempre. È come un worm mentre cerca di nascondersi tutto il tempo finché non è in grado di raggiungere il suo obiettivo di violare la tua sicurezza e ottenere l'accesso ai tuoi dati. Senza strumenti adeguati come sistemi di avviso o avvisi per eventuali insicurezze e vulnerabilità, sarebbe difficile salvaguardare i tuoi dati.

ClusterControl ti aiuta a gestire i tuoi utenti e verificare o controllare i privilegi dei tuoi utenti dai sistemi di bilanciamento del carico ai principali utenti del database. Offre inoltre consulenti e avvisi in modo che ti avviserà di possibili vulnerabilità o intrusioni.

Ad esempio, l'utilizzo di un MySQL/MariaDB con funzionalità iniziali ProxySQL per l'importazione e l'aggiunta di utenti. Per l'importazione degli utenti, raccoglie l'elenco degli utenti che sono presenti nel tuo attuale cluster MySQL/MariaDB e ti offre di rivedere i suoi attuali privilegi. Vedi sotto,

Anche in questo caso, un utente ProxySQL può essere disattivato rapidamente se tale vulnerabilità è noto per l'utente specifico.

ClusterControl ti offre anche la possibilità di gestire direttamente gli utenti dal tuo database come per MySQL/MariaDB o PostgreSQL. Per MySQL/MariaDB, puoi andare su → Gestisci → Schemi e utenti.

Per PostgreSQL, → Gestisci → Gestione utenti.

Con ClusterControl, puoi personalizzare i tuoi avvisi utilizzando gli advisor. Gli advisor sono entità basate su script modificabili. Ad esempio, questo è in un cluster MySQL/MariaDB come mostrato di seguito, a cui è possibile accedere tramite