Direct naar content

Blijf in controle over de rechten die je uitdeelt

Of het nu in Microsoft SQL Server is of in een andere databaseomgeving, te veel en te hoge rechten geven kan securityrisico’s met zich meebrengen. Hoe meer mensen alle rechten hebben, hoe groter het risico wordt en hoe groter de kans dat je de grip en controle op je IT-omgeving verliest. Mark van der Haar beschrijft in deze blog een aantal situaties uit de praktijk.

Mark van der Haar

DBA Consultant en Senior Database Reliability Engineer
Mark van der Haar - DBA Consultant en Senior Database Reliability Engineer

Least Privilege Principle

Het Least Privilege-principe verwijst naar een informatiebeveiligingsconcept waarbij gebruikers de minimale rechten krijgen die ze nodig hebben om hun taken uit te voeren, maar zeker niet meer. De vraag om administratorrechten is snel gesteld, maar zelden is dit ook werkelijk nodig.

Eigenlijk is dit alleen nodig als iemand configuratieparameters aan moet passen. Maar die rol is niet voor iedereen weggelegd. Voor je het weet bekijkt iemand de password-hashs, om die naar een andere server te kopiëren en ze daar met brute kracht te kraken. Maar voor het aanmaken en wijzigen van jobs heb je die rechten wel weer nodig.

Een applicatiebeheerder met sysadmin-rechten

Meestal hebben beheerders voldoende aan db_datareader-rechten – of hoe je de leesrechten ook noemt in jouw databaseomgeving – op de user-databases die ze beheren. Wil je toekomstige databases ook gelijk meenemen dan is het bij SQL Server mogelijk om die rol in de modeldatabase mee te nemen. Omdat auditors willen weten wat er buiten de applicatie om in de database gewijzigd wordt (bijvoorbeeld door SOX), dan is db_datawriter al niet toegestaan.

Als de applicatiebeheerder ook jobs moet monitoren, dan kan de rol uitgebreid worden met de msdb role SQLAgentOperatorRole. Draaien er ook SSIS-packages? Dan kunnen de rechten uitgebreid worden met de SSISDB role ssis_admin.

Een account waarmee via een pipeline changes worden deployed met sysadmin-rechten

Het gevaar is hier dat je via zo’n pipeline ook veel meer logins kan creëren met sysadmin-rechten. Een ontwikkelaar vertelde me ooit eens dat dit de enige manier is waarop de DevOps-pipeline van Azure kon werken en dat zelfs Microsoft dit aangaf. De uitdaging is natuurlijk om die informatie op een Microsoft-site terug te vinden.

Niet makkelijk, maar het is me gelukt de juiste info te vinden! Microsoft geeft aan dat je de login de dbcreator-server-rol moet geven, én het ALTER ANY LOGIN recht. Maak de login ook db_owner in de modeldatabase en de login kan ook de eenmaal aangemaakte databases onderhouden.

Een data-engineer met sysadmin rechten

Het ligt eraan of het een database is waaruit gelezen wordt (db_datareader is dan voldoende) of een database waarnaar geschreven wordt. Op de te schrijven database heb je minimaal db_datawriter nodig. Worden er in de database ook structuurwijzigingen aangebracht, dan moet de data-engineer db_owner zijn op deze database.

Moet de data-engineer ook ad-hoc databases aanmaken dan moet hij de dbcreator-server-rol krijgen en de db_owner rol op de modeldatabase. Data-engineers maken vaak gebruik van temporary tables, maar daar zijn geen extra rechten voor nodig.

Een developer met sysadmin-rechten in productie

Er wordt tegenwoordig veel gebruik gemaakt van automatische deployments en dan is er geen noodzaak om het account van een developer veel rechten te geven. Dan gaat het meer om rechten als VIEW ANY DEFINITION. Wordt daar nog geen gebruik van gemaakt, dan is het alleen nodig de developer dezelfde rechten te geven als een deploy-account in de ontwikkelomgeving en eventueel de testomgeving.

In de rest van de OTAP-straat worden de changes aangebracht door een DBA die de scripts krijgt, en liefst via een ticketsysteem. In het ticketsysteem kunnen dan meteen de goedkeuringen van de testers en eigenaren geadministreerd worden.

Een applicatie-account owner – of sysadmin – maken van de user-database

Een applicatie-account kan al genoeg hebben aan de db_datareader en de db_datawriter role. Of nog fijner, voor alle acties stored procedures maken en alleen EXECUTE-rechten uitdelen op het schema. Vaak zie je dat een applicatie-account db_owner-rechten krijgt, maar is het echt nodig dat een applicatie-account het recht krijgt om te backuppen, of erger het droppen van de database?

Het geven van db_owner-rechten door het applicatie-accountowner te maken van de database is gevaarlijk. Mocht er een restore nodig zijn, dan wordt de login die de database heeft gerestored owner en verliest de vorige owner zijn rechten.

Uitbreidingen op de public role

Ieder login en user krijgt de public role toegewezen. Als je de public role extra rechten toekent dan zal dat voor iedereen gelden. Soms is dat handig, als een bepaald recht inderdaad aan iedereen uitgedeeld moet worden. Maar gedurende de lifecycle van een server zijn er uitbreidingen op functionaliteit en komen er meer logins bij. Het wil helemaal niet zeggen dat de nieuwe logins dit recht ook moeten krijgen. Best practice is daarom de public role standaard te laten.

Het lokale administrator-account of de administratorsgroep opnemen als login en zelfs sysadmin maken

Vaak gaat het hier om systeembeheerders die soms wat zaken binnen SQL moeten kunnen. Ik zou hier een ander account voor gebruiken dan het systeembeheerdersaccount. Een account dat zowel veel rechten heeft op Windows-niveau als op SQL Server-niveau is wel een echte super-user. Zo’n account zouden hackers graag hebben om hun losgeld te innen. Ook wordt andersom het serviceaccount van de engine opgenomen in de lokale administratorsgroep. Tevens een gevaarlijke combinatie.

Het account dat voor het monitoring tool wordt gebruikt sysadmin rechten geven

Vaak is dit gekomen omdat niet elke leverancier van de tool even duidelijk is wat de rechten moeten zijn. En dan wordt er besloten om, na wat mislukte pogingen, maar sysadmin te geven. Een gevaarlijke situatie omdat de monitoring tool vaak het gehele server-park moet monitoren, of in ieder geval de productie-servers. En soms is hier alleen VIEW SERVER STATE voldoende. En als er meer rechten nodig zijn, zijn het leesrechten (op de DMV’s b.v.), zeker geen sysadmin.

Samenvattend

Natuurlijk zijn al deze voorbeelden op grote lijnen beschreven en kan alles nog beter gefinetuned worden. Maar sysadmin toekennen omdat even niet gelijk duidelijk is wat de behoeften zijn, dat zie ik nog regelmatig voorkomen. Tegelijkertijd stuit het terugdraaien van sysadmin-rechten vaak op veel weerstand. Het devies: Bezint eer ge begint.

Wil je advies of een review?

Heb je in jouw omgeving ook teveel sysadmin-rechten toegekend en wil je daar eens kritisch doorheen? Heb je behoefte aan objectief advies of hulp daarbij? Neem gerust eens vrijblijvend contact met ons op, we helpen je graag!