1. Fonti in sola lettura
Le fonti SQL sono aperte in sola lettura. Una scrittura è rifiutata dal motore, non solo dall'interfaccia; la protezione è dimostrata da un caso valido, un caso violato e un sabotaggio deliberato.
2. Identità federata, nessun account locale
L'accesso passa da Idenva (SSO). Un token di un altro emittente, o scaduto, viene rifiutato, e la riattivazione di una password locale viene rilevata. Dashvia non tiene un proprio database di utenti.
3. Diritti riga per riga
I gruppi Idenva stabiliscono quali righe sono visibili. Il filtro è parametrizzato, mai costruito interpolando valori, e si applica anche ai filtri incrociati, al drill-down, alle esportazioni e ai report pianificati.
4. Un'IA che mostra la propria query
Il text-to-SQL risponde con una query SQL leggibile. Ogni lettura fuori dallo schema e ogni scrittura sono rifiutate prima dell'esecuzione. Senza l'hub Kopilvia, Dashvia passa a una modalità degradata esplicita: corpus locale e rifiuto di rispondere fuori da esso, invece di inventare.
5. Registro di audit
Chi ha consultato, esportato o modificato quale report è annotato in un registro di sola aggiunta: il database rifiuta qualsiasi modifica o cancellazione di una riga già scritta.
6. Base rafforzata e bloccata
Dashvia poggia su Apache Superset (Apache-2.0), bloccato alla versione 6.1.0. Una chiave segreta predefinita o un account admin/admin vengono rifiutati all'avvio, e gli avvisi di sicurezza pubblicati sono verificati rispetto alla versione bloccata.
7. Ospitabile da voi
La base si installa sulla vostra infrastruttura. I vostri schemi e i vostri risultati non devono uscirne.