Security Center

Security Center is de selfservice toegangsbeheer-UI van het platform. Product owners registreren hier dataproducten, teams vragen toegang aan en krijgen die, en row-level/column-level beveiligingsbeleid wordt opgesteld, allemaal afgedwongen door de native OPA access-control plugin van Trino (zie de sectie “Querying data” in Aan de slag: Sovereign Data Platform), zonder dat er ooit handmatig Rego geschreven hoeft te worden.

Kernconcepten

Voor een stapsgewijze uitleg met schermafbeeldingen, zie Gebruikershandleiding.

Concept	Wat het is
Product	Een geregistreerde tabel (catalog.schema.table), die leeft in een catalogus en schema van een team. Ofwel direct aangemaakt in Security Center (op de achtergrond geprovisioned), ofwel automatisch ontdekt door een periodieke syncjob en later geadopteerd door een team.
Team	Een groep gebruikers (en applicaties) die producten bezit en/of toegang aanvraagt tot producten van andere teams. Lidmaatschap kan gebruikers, groepen of applicaties omvatten.
Rol	Een benoemd toegangsniveau, gebonden aan één product (bijv. reader, analyst) — geen globale permissie. Elk product heeft een impliciete owner-rol (gereserveerde naam); een product owner kan aanvullende rollen aanmaken.
Toegangsaanvraag	De aanvraag van een team om een van zijn leden een rol op een product toe te kennen. Doorloopt een workflow van aanvraag → goedkeuren/afwijzen; goedgekeurde toegang kan later worden ingetrokken.
RLS-regel	Row-level security: een set predicaten (column, operator, value) gebonden aan een rol. Rijen die niet aan de predicaten voldoen zijn onzichtbaar voor die rol.
CLS-regel	Column-level security: een kolommasker gebonden aan een rol. Een van vier vaste mask-types: full_redact, hash, partial_mask (met parameters, bijv. {"keep_last": 4}), null.

Toegang tot een product aanvragen

Zoek of blader via de Catalogus-boom door de geregistreerde producten. Het aanvragen van toegang tot de rol van een product dient namens je team een toegangsaanvraag in, met een toelichting en contactpersoon — zichtbaar voor de eigenaar van dat product ter goedkeuring. Je openstaande en eerdere aanvragen, in elke status, zie je in je eigen overzicht; er wordt niets verleend totdat een productowner het goedkeurt.

Toegangsaanvragen goedkeuren (product owners)

Op het tabblad Beheer van een product ziet een owner elke openstaande toegangsaanvraag voor de rollen van dat product en kan die goedkeuren, afwijzen of eerder goedgekeurde toegang later intrekken. Owners kunnen ook extra rollen aanmaken naast de gereserveerde rol owner (kleine letters, beginnend met een letter, bijv. analyst) — elke nieuwe rol is direct beschikbaar als aanvraagdoel en als RLS/CLS-scope.

Row-level security-regels opstellen

Op hetzelfde tabblad Beheer kan een owner RLS-regels opstellen voor elke rol van het product: een lijst predicaten, elk bestaande uit een column, een operator (=, !=, >, <, >=, <=, IN) en een waarde. Een rol met één of meer actieve RLS-regels ziet alleen rijen die aan elk predicaat voldoen: rijen die aan een predicaat niet voldoen, worden volledig gefilterd voor leden met die rol. Kolomnamen kunnen worden gekozen uit het echte Trino-schema van het product als kolommetadata beschikbaar is, anders voer je ze als vrije tekst in.

Column-level security-regels opstellen

CLS-regels maskeren een specifieke kolom voor een specifieke rol, in plaats van rijen te filteren:

Mask-type	Effect
full_redact	Vervangt de waarde volledig (bijv. door een vaste placeholder).
hash	Vervangt de waarde door een one-way hash.
partial_mask	Maskeert een deel van de waarde en houdt de rest zichtbaar — parametriseerbaar, bijv. {"keep_last": 4} om alleen de laatste 4 tekens te behouden.
null	Retourneert NULL voor de kolom.

Net als RLS-regels is een CLS-regel gebonden aan één (role, column)-paar en kan deze individueel worden in- of uitgeschakeld zonder te worden verwijderd.

Admintaken

Gebruikers met de adminrol krijgen een menu Beheer met drie onderdelen, stap voor stap beschreven in Beheerderstraject:

• Gebruikersbeheer: platformgebruikers en teams beheren.

• Product synchronisatie en Unity Catalog: catalogusinstellingen, synchronisatie en het verwijderen van een catalogus zonder tabellen (de API-aanroep is DELETE /admin/unity-catalog/catalogs/{catalog}?confirm=<naam>, alleen voor beheerders; de catalogi system en main zijn beschermd).

• Admin panel (producten): een product of team direct verwijderen (het verwijderen van een team verwijdert ook al zijn groepen; mislukt als het team nog afhankelijke state heeft), een product adopteren dat door de Trino-syncjob is ontdekt maar waarvan nog geen team eigenaarschap heeft geclaimd, en handmatig een Trino sync starten om het productregister van Security Center te reconciliëren met wat er daadwerkelijk in Trino bestaat.

Hoe de handhaving daadwerkelijk werkt

Security Center zelf communiceert nooit met Trino tijdens het uitvoeren van een query. Elke via de UI opgestelde RLS/CLS-regel wordt gecompileerd naar Rego en verpakt in een per-klant OPA-bundle; de Trino OPA-plugin van elke klant pollt periodiek zijn eigen /trino/{customer}/bundle.tar.gz-endpoint en neemt regelwijzigingen automatisch over, zonder dat daar een Trino-herstart of handmatige policy-deployment voor nodig is. Dat endpoint wordt geauthenticeerd met een statische bearer-token die eenmalig bij deployment wordt gedeeld tussen Security Center en de OPA-instantie van de klant, niet met een per-request Keycloak-token (OPA heeft geen eigen Keycloak-identiteit om te presenteren).

Spark volgt dezelfde regels. Een gebruiker wiens rol een rijfilter of kolommasker heeft, leest die tabel in een notebook via Trino, zodat het filter en het masker daar ook worden toegepast; zo’n toegang is alleen-lezen.