Beveiliging

Wat Cataloom leest, en wat het nooit doet

Deze pagina is bedoeld om door te sturen naar je DBA of security-officer. Hij bevat wat zij moeten weten om ja of nee te kunnen zeggen, zonder dat ze eerst het hele product moeten begrijpen.

Read-only, met de datastromen per route benoemd: het taalmodel krijgt schema en code, en bij een live verbinding enkele geaggregeerde signalen (tellingen, datumbereiken, statuswaarden), nooit volledige rijen. In je eigen omgeving gaan de AI-stappen naar je eigen Azure OpenAI-resource; bij de gratis audit komt de metadata bij mij, via de zip van het script of via een read-only login.

Per route

Gratis audit met het script: De zip met catalogus en definities komt per mail bij mij. Ik analyseer hem op mijn eigen werkplek, zonder verbinding met je database. Wat live leest, valt dan af: de verificatie van herschrijvingen, de telqueries en de samenvattingen voor het businessverhaal.
Gratis audit met een read-only login: Ik verbind vanaf mijn werkplek read-only met je database. Omdat dat een live verbinding is, draaien de telqueries, de verificatie en de samenvattingen voor het businessverhaal wel mee.
Doorlopende dienst: Elke run leest dezelfde gegevens als de gratis audit, via het script of een read-only verbinding, en vergelijkt ze met de vorige opname. De AI-stappen gaan naar je eigen Azure OpenAI-resource, met je eigen sleutel.

Rechten

db_datareader en VIEW DEFINITION op de database. Dat is de hele eis voor de basisanalyse.
Zonder VIEW DEFINITION geeft SQL Server de code van views en procedures als leeg terug, zonder foutmelding. Cataloom telt dat en zegt het vooraf, want anders lijkt de analyse compleet terwijl de kern ontbreekt.
VIEW DATABASE STATE voor indexgebruik en voor kosten uit Query Store. Voor kosten of query-historie uit de plancache is op SQL Server VIEW SERVER STATE nodig. Ontbreekt een recht, dan slaat Cataloom dat onderdeel over en zegt in het rapport welk en waarom.
Er is geen schrijfpad in de code. Geen INSERT, geen UPDATE, geen DDL, ook niet als je het zou willen.

Wat er gelezen wordt

De systeemcatalogus: objecten, kolommen, sleutels, foreign keys, triggers, dependencies.
De definities van views, procedures en functies. Dat is de kern: de logica zelf.
Row-Level Security-policies, en met welk account er gemeten is. Staat er RLS op een tabel, dan ziet een beperkt account minder rijen, dus het rapport zegt als wie hij telde.
Geen voorbeeldrijen uit je tabellen: die staan standaard uit en zijn een expliciete opt-in.
Bij de bevestiging van niet-deterministische updates draaien er telqueries. Die tellen rijen en geven geen inhoud terug.
Alleen bij een live verbinding: de verificatie draait het origineel en de herschrijving van een view of procedure read-only en vergelijkt de resultaatsets, tot 100.000 rijen, op de machine waar Cataloom draait. Wijken ze af, dan zet het rapport per vergelijking hooguit twintig afwijkende rijen per kant neer als bewijs. Naar het model gaat daarvan niets.
Voor het businessverhaal draaien er begrensde aggregaties: de waarden van statuskolommen met hun aantallen (hooguit twintig per kolom), het bereik van datumkolommen en gemiddelde doorlooptijden.
Alleen als je het expliciet aanzet: de tekst van ad-hoc queries uit de plancache of Query Store, om te zien wie een tabel buiten de code om leest. Stringliterals worden vervangen voordat de tekst in het rapport komt. In de zip van het script staat hij nog zoals de server hem bewaart.

Wat er naar een AI gaat

Schema-informatie en de definities van views, procedures en functies. Bij een live verbinding komen daar de samenvattingen voor het businessverhaal bij. Nooit volledige rijen.
In de gratis audit naar mijn eigen Azure OpenAI-resource, op mijn kosten. In de doorlopende dienst naar de Azure OpenAI-resource van de klant, met de sleutel van de klant.
Draai je met de AI uit, dan werken alle twaalf SQL-checks en de vier Power BI-checks nog. Je krijgt dan geen lopende beschrijvingen, wel alle bevindingen.
Relaties en lineage worden sowieso deterministisch uit de code gemined en niet door een model bedacht.

Zonder databaseverbinding

cataloom-collect.ps1 draait bij jou, doet alleen SELECT's, standaard alleen op de systeemcatalogus, en schrijft een zip.
Het script is leesbaar en bedoeld om gelezen te worden. Er zit geen obfuscatie in en geen netwerkverkeer buiten de verbinding met je eigen database.
De analyse draait daarna op die zip, zonder ooit met je database te praten. De onderdelen die live lezen, zoals de verificatie van herschrijvingen, vallen dan af.

Wat er met je zip gebeurt

Je mailt hem naar bas@cataloom.io.
Ik draai de analyse op mijn eigen werkplek, niet op een gedeelde server.
De zip en mijn kopie van het rapport verwijder ik 30 dagen na oplevering. Die termijn is er voor je vragen, en voor een tweede run als je doorgaat: dan is de eerste opname het nulpunt van het wijzigingsrapport.

Wat er achterblijft

Na de gratis audit niets. Geen agent, geen service, geen geplande taak, geen tabel in je database.
De output is een map HTML-bestanden zonder externe requests: geen CDN, geen tracking, fonts ingebed.
Open het rapport met je netwerkkabel eruit en het werkt nog steeds.

Blijft er een vraag over die hier niet beantwoord wordt, stel hem dan voordat er iets draait. Dat is een stuk makkelijker dan achteraf.