RBAC gebruiken met ABAC

Op rollen gebaseerd toegangsbeheer (RBAC) en op kenmerken gebaseerd toegangsbeheer (ABAC) in Unity Catalog zijn aanvullende besturingselementen die zijn ontworpen om samen te werken. Ze beantwoorden verschillende vragen:

• RBAC bepaalt welke identiteit een gebruiker fungeert als voor een sessie. Een gebruiker neemt een rol op zich om gebruik te maken van de machtigingen van die rol in plaats van zijn of haar eigen machtigingen. Gebruik RBAC om één gebruiker verschillende machtigingensets te geven, waarbij ze expliciet schakelen, bijvoorbeeld het scheiden van toegang tot klinische proeven, projecten of gevoeligheidslagen.
• ABAC bepaalt welke gegevens de actieve identiteit kan zien, rij per rij of kolom per kolom. Beleidsregels worden gekoppeld aan gegevens via beheerde tags en zijn van toepassing op de identiteit waarop de query wordt uitgevoerd. Gebruik ABAC voor consistente filters of maskering in veel tabellen die worden aangestuurd door gegevenskenmerken.

RBAC stelt de actieve identiteit voor de sessie in en ABAC evalueert het beleid op basis van die identiteit. Op deze pagina wordt beschreven hoe deze interactie in de praktijk wordt afgespeeld, het gedrag van identiteitsgerelateerde SQL-functies en patronen voor gecombineerd gebruik.

Hoe identiteitsfuncties zich gedragen wanneer een rol wordt aangenomen

De identiteitsgerelateerde SQL-functies van Unity Catalog worden bepaald op basis van de in de sessie actieve identiteit, niet van de onderliggende geverifieerde gebruiker. Wanneer een gebruiker een rol aanneemt, wordt de identiteit van de actieve sessie die van de rol:

ABAC-beleid dat naar deze functies verwijst, wordt geëvalueerd op basis van de aangenomen rol, niet de gebruiker. De aangenomen rol is de actieve identiteit voor ABAC-beleidsevaluatie, het oplossen van Unity Catalog-machtigingen en de toeschrijving van auditgegevens. Daardoor verandert het aannemen van een rol het gedrag van bestaande beleidsregels en weergaven die zijn gebaseerd op de identiteit van individuele gebruikers.

Veelvoorkomende valkuil: beveiligingsweergaven op rijniveau die zijn gebouwd op current_user()

Een veelvoorkomend patroon bij ABAC en rijfilters op tabelniveau is het filteren van rijen door deze te koppelen aan een provisioningstabel (ook wel een mappingtabel of toegangsbeheerlijst genoemd) met als sleutel de gebruikersnaam die wordt geretourneerd door current_user(). Voorbeeld:

CREATE OR REPLACE FUNCTION facility_filter(facility_id STRING)
RETURN EXISTS (
  SELECT 1
  FROM governance.user_facility_provisioning p
  WHERE p.user = current_user()
    AND p.facility_id = facility_id
);

Wanneer dezelfde gebruiker een rol aanneemt, retourneert current_user() niet langer zijn gebruikersnaam. De naam van de rol wordt geretourneerd. Omdat de rol niet in de provisioningstabel staat, geeft het filter geen rijen terug en lijkt de gebruiker de toegang te verliezen tot gegevens waartoe hun toegang was verleend.

Voeg de rol toe aan de provisioningstabel

Behandel de rol als een andere principal in uw inrichtingsgegevens: voeg één rij per rol in met de faciliteiten (of andere kenmerken) die de rol moet zien. Het filter komt vervolgens overeen met of de actieve identiteit de gebruiker of de aangenomen rol is.

Gecombineerde gebruikspatronen

Hier volgen voorbeelden van hoe klanten RBAC en ABAC samen gebruiken om echte problemen met toegangsbeheer op te lossen. Dit zijn uitgangspunten, niet uitputtende recepten.

Rijfilters per project die zijn gebaseerd op de aangenomen rol

Het filteren van rijen op project is een veelvoorkomende behoefte aan klinisch onderzoek, contractmarketing, clientadvies en andere instellingen waarbij één team in verschillende geïsoleerde projecten werkt. In het volgende voorbeeld wordt gebruikgemaakt van klinische studies, maar het patroon generaliseert naar elke gegevensisolatie per project.

Een klinische onderzoeksorganisatie voert verschillende gelijktijdige proeven uit, elk in een eigen toegangsrol. Tag elke tabel met de project-id. Gebruikers zien alleen de rijen voor het project waarvan ze de rol hebben aangenomen.

Instellen:

• Tabellen onder clinical_trials.* hebben een project_id kolom die is gelabeld met de beheerde tagsleutelproject.
• Elk project heeft een bijbehorende toegangsrol met de naam role-<project> (bijvoorbeeld role-alpha, role-beta).
• Gebruikers hebben alleen de machtiging om rollen aan te nemen voor de projecten waaraan ze werken.

Rijfilter UDF:

CREATE FUNCTION project_match(project_id STRING) RETURNS BOOLEAN
DETERMINISTIC
RETURN current_user() = CONCAT('role-', project_id);

Beleid:

CREATE POLICY per_project_row_filter
ON CATALOG clinical_trials
ROW FILTER project_match
TO `account users`
FOR TABLES
MATCH COLUMNS has_tag('project') AS project
USING COLUMNS (project);

Deze UDF correleert de actieve identiteit met de waarde van de tag project van elke rij, dus principal-targeting-clausules zoals TO / EXCEPT kunnen dit niet uitdrukken — die zijn gericht op principals, niet op rijinhoud. Zoals in de handleiding voor principal-targeting wordt uitgelegd, geeft u voor eenvoudige afbakening van principals de voorkeur aan TO / EXCEPT en gebruikt u identiteitsfuncties binnen een UDF alleen voor gevallen zoals dit, waarbij één regel afhankelijk is van zowel de actieve identiteit als de inhoud van de rij.

Eén beleid omvat elk project: USING COLUMNS (project) geeft de tagwaarde van project elke rij door aan de UDF, zodat u geen afzonderlijk beleid per project nodig hebt. Zie Mappingtabellen gebruiken voor dynamisch toegangsbeheer voor de algemene vorm van deze techniek — rijtoegang aansturen via een opzoektabel in plaats van op overeenkomst met rolnamen.

Gedrag:

• Een gebruiker die als gebruikersidentiteit fungeert, ziet geen rijen in een clinical_trials tabel. current_user() retourneert hun gebruikersnaam, die nooit overeenkomt met het role-* naamgevingspatroon. Dit is de beoogde standaardweigering.
• Een gebruiker die ervan uitgaat dat role-alpha ziet alleen rijen waarin project_id gelijk is aan alpha. Als u overschakelt naar role-beta, worden de zichtbare gegevens verwisseld zonder iets anders opnieuw op te vragen.

PII-maskering versoepeld voor gebruikers die optreden als een aangewezen rol

PiI-kolommen (SSN, e-mail, telefoon) worden standaard voor iedereen gemaskeerd. Om de ruwe waarden te zien, moet een gebruiker expliciet een specifiek voor PII geautoriseerde rol op zich nemen. Auditlogboeken registreren de rolaannamegebeurtenis, dus 'Ik moest naar echte PII kijken' wordt een controleerbare opt-in in plaats van een omgevingsmachtiging.

Instellen:

• Gevoelige kolommen worden gelabeld met de beheerde tagsleutelpii (toegestane waarden zoals ssn, email, phone).
• Gebruikers die gemachtigd zijn om onbewerkte PII te bekijken, krijgen de toegangsrol met de naam role-pii-cleared Assume toegewezen.

UDF voor kolommaskering (statisch — het beleid bepaalt welke identiteiten worden gemaskeerd):

CREATE FUNCTION mask_pii(val STRING) RETURNS STRING
DETERMINISTIC
RETURN '***';

Beleid:

CREATE POLICY pii_default_mask
ON CATALOG customer_data
COLUMN MASK mask_pii
TO `account users`
EXCEPT `role-pii-cleared`
FOR TABLES
MATCH COLUMNS has_tag('pii') AS pii_col
ON COLUMN pii_col;

De EXCEPT component sluit role-pii-cleared volledig uit van het beleid, dus de UDF wordt nooit aangeroepen wanneer die rol de actieve identiteit is. Zie Prefer TO/EXCEPT voor principal targeting voor de algemene richtlijnen voor principal targeting via TO / EXCEPT.

Gedrag:

• Een gebruiker die handelt onder zijn/haar gebruikersidentiteit, ziet *** in iedere kolom met PII. Dit is de standaardtoestand voor iedereen, inclusief gebruikers die de machtiging om over te nemen hebben op role-pii-cleared.
• Nadat het beleid is aangenomen role-pii-cleared, is het niet meer van toepassing op de sessie en ziet dezelfde gebruiker de onbewerkte waarden.
• Controlelogboekvermeldingen voor de sessierecord identity_metadata.run_as = role-pii-cleared, zodat revisoren precies kunnen zien wanneer PII is ontmaskerd en door wie.

Beleidsregels voor gevoeligheidsniveaus die verschillen per overgenomen rol

Gegevens worden geclassificeerd in vertrouwelijkheidslagen (internal, confidential, restricted). Elke laag heeft een bijbehorende toegangsrol, waarbij restricted inhoudt dat er ook toegang is tot confidential en internal. Een enkele UDF voor rijfilters bepaalt de zichtbaarheid van rijen door het niveau van elke rij te vergelijken met de rol die aan de gebruiker is toegewezen.

Instellen:

• Tabellen hebben een sensitivity_level kolom met de beheerde tagsleutelsensitivity (toegestane waarden: internal, , confidentialrestricted).
• Drie toegangsrollen: role-sens-internal, role-sens-confidential, role-sens-restricted.

Rijfilter UDF:

CREATE FUNCTION sensitivity_allowed(row_sensitivity STRING) RETURNS BOOLEAN
DETERMINISTIC
RETURN CASE
  WHEN current_user() = 'role-sens-restricted' THEN TRUE
  WHEN current_user() = 'role-sens-confidential' THEN row_sensitivity IN ('internal', 'confidential')
  WHEN current_user() = 'role-sens-internal' THEN row_sensitivity = 'internal'
  ELSE FALSE
END;

Beleid:

CREATE POLICY sensitivity_filter
ON CATALOG corp_data
ROW FILTER sensitivity_allowed
TO `account users`
FOR TABLES
MATCH COLUMNS has_tag('sensitivity') AS sens
USING COLUMNS (sens);

Omdat een rol geen lid is van zichzelf, vergelijkt deze UDF current_user() met de naam van elke rol in plaats van het lidmaatschap te testen met is_account_group_member(). Zie de bovenstaande opmerking voor waarom lidmaatschapstests niet overeenkomen met de veronderstelde rol. Zie Prestatieoverwegingen voor rijfilter- en kolommaskerbeleid voor prestatiekenmerken van identiteitsfuncties in UDF's.

Gedrag:

• Een gebruiker die handelt onder zijn of haar gebruikersidentiteit, ziet geen rijen. De ELSE FALSE-vertakking is van toepassing op alles wat niet een van de drie rollen is. Net als in het bovenstaande voorbeeld per project is dit het beoogde standaard-weigeren.
• Aangenomen dat role-sens-internal slechts internal rijen toont.
• Ervan uitgaande dat role-sens-confidentialinternal en confidential rijen weergeeft.
• Ervan uitgaande dat role-sens-restricted alle rijen zichtbaar maakt.

Gebruikers gaan ervan uit dat de hoogste laag die ze nodig hebben voor de sessie; het filter sluit automatisch alles boven die laag uit zonder dat de gebruiker hoeft te weten welke tabellen welke classificaties bevatten.

Controletoewijzing

Zowel ABAC-beleidsevaluaties als de onderliggende query's houden rekening met de RBAC-toeschrijving run_as / run_by. Vermeldingen in auditlogboeken registreren identity_metadata.run_by als de verifiërende gebruiker en identity_metadata.run_as als de veronderstelde rol, ongeacht welke ABAC-beleidsregels zijn toegepast tijdens de evaluatie. Raadpleeg de referentie voor de auditlog-systeemtabel voor het volledige auditlogschema.

Volgende stappen 

• Exclusieve toegang modelleren: Pas patronen toe voor het instellen van exclusieve toegang met behulp van een account-lokale groep of een groep die is gesynchroniseerd vanuit Microsoft Entra ID. Bekijk exclusieve toegang tot Model.
• Schakelen tussen rollen: Stel een rol in met behulp van de rolwisselaar, toegewezen toegangsmodusclusters, de CLI, de API of BI-hulpprogramma's van derden. Zie Schakelen tussen rollen.
• Assume-machtigingen beheren: Verleen of trek Assume voor een groep in, zodat gebruikers de bijbehorende rol kunnen aannemen. Zie Machtigingen beheren voor een groep.
• Bekijk abAC-kernconcepten: meer informatie over hoe beheerde tags, beleidsregels en beleidsevaluatie werken. Zie Op kenmerken gebaseerd toegangsbeheer in Unity Catalog.