Prima di collegare uno strumento BI self-hosted a un database: checklist del minimo privilegio

Inizia mappando la connessione

Questa è una checklist generale di pianificazione, non una descrizione dei controlli disponibili in ogni applicazione BI o database. Per rispondere alle domande qui sotto, consulta la documentazione dei prodotti, delle versioni e del metodo di connessione specifici che intendi utilizzare.

Prima di configurare una connessione, annota quale applicazione BI si collegherà, quale account del database userà, in che modo l’applicazione raggiungerà il database e chi potrà aprire le domande o le dashboard salvate. Esamina separatamente le autorizzazioni dell’applicazione e quelle del database.

• Indica l’istanza dell’applicazione BI e il database o i database a cui si collegherà.
• Annota chi può accedere, creare o modificare report e visualizzare dashboard condivise.
• Individua dove sono archiviate le credenziali di connessione e chi è autorizzato a modificarle.
• Traccia il percorso di rete e annota quali sistemi o team amministrano ciascuna parte.

Esamina separatamente i ruoli dell’applicazione e i permessi del database

Consideralo un’attività di verifica, non dare per scontato come funzionino i ruoli in un determinato prodotto. Consulta la documentazione dell’applicazione BI e verifica cosa possono fare gli account di visualizzazione, di modifica dei report e di amministrazione. Separatamente, controlla quali dati può leggere l’account del database configurato per la connessione.

Se il tuo piano prevede domande salvate, dashboard, esportazioni o query pianificate, includile nella verifica. Non considerare un ruolo dell’applicazione un sostituto del controllo delle autorizzazioni concesse nel database.

• Elenca i ruoli dell’applicazione che intendi usare e le azioni che ciascuno dovrebbe consentire.
• Documenta i privilegi del database concessi all’account di connessione BI.
• Verifica cosa possono vedere utenti rappresentativi tramite i report e i metodi di condivisione che prevedi di usare.
• Annota come quesiti aperti eventuali comportamenti che non riesci a verificare.

Crea un account dedicato con privilegi limitati

Usa un account dedicato per la connessione BI invece di collegarti come root o di usare un account con accesso in scrittura. Una guida di Basedash alla creazione di dashboard basate su dati MySQL (https://www.basedash.com/blog/how-to-build-dashboards-on-mysql-data) consiglia un utente dedicato, di sola lettura e con privilegi minimi.

Stabilisci poi l’ambito di lettura appropriato per le tue esigenze di reporting. Consulta la documentazione del database e chiedi a un amministratore se è possibile limitare l’accesso a schemi, tabelle o viste selezionati. Verifica le autorizzazioni effettive invece di presumere che sia l’applicazione BI a impostare tali limiti.

• Crea un account distinto, utilizzato esclusivamente per la connessione BI.
• Preferisci i privilegi di sola lettura; per il reporting ordinario non usare un account root o abilitato alla scrittura.
• Concedi l’accesso solo ai dati di reporting approvati dal team.
• Chiedi a un amministratore del database di verificare le autorizzazioni effettive, comprese quelle ereditate o più ampie.

Decidi come gestire i campi e le righe sensibili

Individua i campi e i record che non dovrebbero essere ampiamente accessibili tramite gli strumenti di analisi, facendo riferimento alle politiche della tua organizzazione per stabilire quali dati sono sensibili. Questa checklist non prescrive uno specifico standard legale o normativo.

Per ogni elemento, valuta se il progetto dovrebbe escluderlo, esporne un insieme ridotto tramite viste del database oppure mascherarlo, se i tuoi sistemi lo consentono. Se l’accesso deve variare in base alla riga, documenta dove dovrebbe essere applicata la restrizione e verifica i casi consentiti e quelli vietati tramite la connessione BI effettiva.

• Elenca i campi sensibili e i gruppi di record prima di creare i report.
• Decidi se ogni elemento debba essere escluso, ridotto, mascherato o reso disponibile solo a utenti specifici.
• Verifica eventuali restrizioni richieste a livello di riga nel punto in cui devono essere applicate.
• Controlla che report, esportazioni e dashboard condivise non espongano dati in modo imprevisto.

Valuta l’impatto delle query prima dell’uso regolare

Includi nella verifica anche l’impatto sui sistemi di origine: il solo accesso in lettura non basta a stabilire quali conseguenze avrà l’esecuzione dei report nel tuo ambiente. Considera i report che prevedi di eseguire, la loro frequenza e la possibilità che più persone li usino contemporaneamente.

Testa report e schemi di aggiornamento rappresentativi in un ambiente adeguato al tuo livello di rischio. Consulta la documentazione dell’applicazione BI e del database per verificare la disponibilità di limiti alle query, timeout, controlli di pianificazione o altre misure di salvaguardia, quindi verifica come funzionano nella tua configurazione. Se non riesci a valutare un rischio rilevante, risolvilo prima di abilitare il reporting regolare.

• Individua i report che potrebbero esaminare o aggregare grandi quantità di dati.
• Stima la frequenza prevista degli aggiornamenti e le eventuali sovrapposizioni nell’utilizzo.
• Esamina i test rappresentativi insieme alle persone responsabili del database.
• Annota quali controlli sulle query hai verificato e quali restano da chiarire.

Pianifica la modifica delle credenziali e le responsabilità

Annota chi è responsabile della connessione BI e chi è autorizzato a modificare le credenziali del database. Se applicabile, indica quali report o attività pianificate dipendono dalla connessione.

Documenta come il team intende ruotare o revocare le credenziali. Prima di apportare una modifica, consulta la documentazione dell’applicazione pertinente per capire i comportamenti che devi verificare. In seguito, testa la connessione e i report importanti invece di dare per scontato come reagiranno.

• Assegna un responsabile della connessione e uno dei permessi del database.
• Annota lo scopo, l’ambito e la procedura di modifica delle credenziali, senza inserire il segreto nella checklist.
• Individua le dashboard e le query pianificate dipendenti dalla connessione, se utilizzate.
• Verifica la procedura documentata di rotazione o revoca nella tua configurazione.

Usa una matrice di test prima del lancio

Il fatto che la connessione riesca è solo uno dei test. Usa la matrice qui sotto per verificare accessi, visibilità e comportamento dei sistemi di origine rilevanti per il tuo progetto. Registra i risultati e distingui i controlli verificati dai quesiti ancora aperti.

Usa i risultati per decidere se la connessione è pronta per il pubblico previsto. Se non riesci a dimostrare una restrizione importante, rivedi l’ambito dei dati o il progetto prima del lancio.

• Lettura consentita: conferma che la connessione possa accedere ai dati di reporting approvati.
• Lettura negata: se previsto, verifica che non possa accedere a una tabella, uno schema o una vista non approvati.
• Accesso degli utenti: testa account rappresentativi di visualizzazione, modifica e amministrazione rispetto ai report che dovrebbero o non dovrebbero vedere.
• Dati sensibili: verifica che i campi e le righe soggetti a restrizioni non siano esposti nei report testati.
• Impatto sui sistemi di origine: osserva query e comportamenti di aggiornamento rappresentativi insieme al responsabile del database.
• Risposta alle modifiche: verifica la procedura documentata per modificare o revocare le credenziali.
• Registra la data del test, la persona responsabile, l’esito e i quesiti irrisolti.

Considera separatamente hosting e governance dei dati

Una distribuzione gestita può ridurre il lavoro necessario per gestire l’infrastruttura dell’applicazione, ma non determina quali record del database la connessione BI debba leggere né chi debba vedere i risultati. Il tuo team deve comunque prendere e verificare queste decisioni di accesso e governance.

Airbip offre la distribuzione gestita per le applicazioni del suo catalogo pubblico, con istanze applicative eseguite come workload Docker sui server cloud di Airbip. Automatizza il routing e i certificati TLS e include controlli DNS, gestione del ciclo di vita dei servizi e backup giornalieri, settimanali e mensili configurabili. Queste funzionalità infrastrutturali non sostituiscono la progettazione del minimo privilegio per il database né la verifica dei controlli della specifica applicazione BI scelta.