Antwoord.

SQL-server ondersteunt een gelaagd systeem van toegangsrechten via rollen, gebruikersrechten (GRANT/REVOKE) en schema's (schemas). Belangrijke principes:

• Ken een rol toe = een set van machtigingen die de gebruiker vervolgens ontvangt.
• Geef minimale rechten, alleen wat nodig is (principe van minimale privileges).
• Scheid rechten op database-, tabel-, weergave-, en procedure-niveau apart.
• Voor bijzonder belangrijke bewerkingen – gebruik alleen via opgeslagen procedures of weergaven, en niet via directe toegang tot tabellen.

Voorbeeld van het aanmaken van rollen en toekennen van rechten:

-- Rol aanmaken voor analisten
CREATE ROLE Analyst;
-- Alleen SELECT-rechten geven op de benodigde tabellen
GRANT SELECT ON Sales TO Analyst;
-- Wijziging van gegevens verbieden
REVOKE INSERT, UPDATE, DELETE ON Sales FROM Analyst;
-- Rol toekennen aan gebruiker
GRANT Analyst TO user_ivan;

Vaak worden rollen onderscheiden voor lezen (read-only), wijzigen, administratie en afzonderlijke operaties.

Vraag met een val.

Val: "Kan een gebruiker, die alleen toegang heeft tot een weergave (VIEW), de onderliggende tabel via deze weergave wijzigen? Geef een voorbeeld."

Antwoord: Ja, als de VIEW geen aggregatie/groepering bevat en niet alleen-lezen is (WITH CHECK OPTION) – kan men INSERT/UPDATE/DELETE op de VIEW uitvoeren en worden de wijzigingen doorgevoerd naar de onderliggende tabel, mits de machtigingen dat toestaan.

-- Weergave die overbodige kolommen uitsluit
CREATE VIEW SalesAsView AS SELECT id, total, manager_id FROM Sales;
-- Als het is toegestaan, kan de gebruiker wijzigingen aanbrengen als volgt:
UPDATE SalesAsView SET total=1000 WHERE id=42;
-- Dit raakt Sales.total voor id=42

Oplossing: gebruik alleen readonly VIEW of verbied rechten om gegevens via weergaven te wijzigen.

Voorbeelden van echte fouten door onbekendheid met de nuances van het onderwerp.

---

Verhaal

Project: HR-portaal, persoonlijke gegevens van werknemers.

Fout: Operators hadden toegang tot de onderliggende tabel via VIEW zonder beperking op UPDATE – ze wijzigden per ongeluk elkaars salarissen, hoewel de VIEW oorspronkelijk bedoeld was "alleen voor rapportages".

---

---

Verhaal

Project: Boekhouding, externe integraties.

Fout: Gaven het externe systeem rechten om INSERT en SELECT op de hele DB te doen in plaats van alleen INSERT in de benodigde tabellen. Resultaat: kwetsbaarheid voor het lezen van de hele DB en mogelijke schending van de wetgeving rondom GDPR.

---

---

Verhaal

Project: SaaS-platform, multi-user rapportages.

Fout: Alle klanten werkten in één schema met gedeelde rechten: ze zagen per ongeluk en konden elkaars gegevens bewerken. Oplossing – splitsing in schema's, aparte rollen en eigen beperkingen op het niveau van Row Level Security (RLS).

---