[SQL 2000/2005] Rechten Structuur

[Acid__Burn]

Als project ben ik bezig met het herzien van rechten op alle SQL servers binnen het bedrijf. Het gaat om een Dev, Test en Live omgeving (nu NAS). Voorlopig wil ik alleen de Live omgeving aanpassen.

Nu wil ik dit zo inrichten dat dit makkelijk te beheren is door systeembeheerders (ikzelf ben soort van Junior DBA). Ik zit te denken aan O.U. in de Active Directory. Maar het gaat om een redelijk groot bedrijf met 150+ medewerkers. Die moeten allemaal rechten krijgen. Dus zo gemakkelijk is het niet.

Is het verstandig om voor iedere server een O.U. te maken voor Bulkadmin, DBCreator, Diskadmin, enzovoort? Een gebruiker kan namelijk ook rechten hebben op 1 database, maar op de server staan 10 databases.

Op dit moment staan overal losse inlogs, en die moeten uiteraard verdwijnen. Ik zoek dus een manier om centraal rechten te geven. De gebruiker moet normaal met NT Auth. kunnen blijven inloggen.

Ik hoop op tips van jullie kant.

[Edit]:
Het gaat nu om een SQL 2000 (NAS) omgeving, die binnen enkele maanden overgaat op SQL 2005 (ook NAS). Op dat moment willen we rechten aanpassen.

[ Voor 10% gewijzigd door Acid__Burn op 22-08-2007 13:37 ]

[whoami]

Hmm, dit is geen Software Engineering.

Ik move 'm naar DevTools
-> DTE

[Acid__Burn]

whoami schreef op woensdag 22 augustus 2007 @ 13:43:
Hmm, dit is geen Software Engineering.

Ik move 'm naar DevTools
-> DTE

Sorry... Mijn fout...

[Acid__Burn]

subtiel schopje

Heeft iemand tips? Ik heb nog geen reply gehad, maar hoop toch dat iemand hier iets vanaf weet?

[sanfranjake]

Ik zou alle servers in een OU hangen, of laten staan waar ze nu staan. Zo te zien wil je alleen de rechten/toegang tot databases aanpassen.

Waarom koppel je dan geen rechten aan een Active Directory Group waar je de betreffende gebruikers weer lid van maakt?

Er wordt verder geen SQL authenticatie gebruikt?

[Creepy]

Subtiel schopje? Kicken zien we liever niet binnen de 24 uur...niet iedereen zit elke 5 minuten op het forum

Gezien de vraag over rechten e.d. en een post van een WSS mod een move naar WSS

Move -> WSS

[Acid__Burn]

sanfranjake schreef op woensdag 22 augustus 2007 @ 20:19:
Ik zou alle servers in een OU hangen, of laten staan waar ze nu staan. Zo te zien wil je alleen de rechten/toegang tot databases aanpassen.

Waarom koppel je dan geen rechten aan een Active Directory Group waar je de betreffende gebruikers weer lid van maakt?

Er wordt verder geen SQL authenticatie gebruikt?

Daar zat ik dus ook aan te denken. Maar het probleem is, dat user X wel rechten moet hebben op server1..database 1, maar niet op server1..database2.

Geen SQL authenticatie voor users. Wel voor beheerders.

Creepy schreef op woensdag 22 augustus 2007 @ 20:27:
Subtiel schopje? Kicken zien we liever niet binnen de 24 uur...niet iedereen zit elke 5 minuten op het forum

Gezien de vraag over rechten e.d. en een post van een WSS mod een move naar WSS

Move -> WSS

Sorry... Ben alleen zo enthousiast over dit project, dat ik zo veel mogelijk wil doen in korte tijd.

* I'm not worthy... I'm not worthy *

[The Eagle]

Zoveel mogelijk doen in zo weinig mogelijk tijd is een leuk streven, alleen leidt het helaas maar al te vaak tot fouten. Relax, werk gewoon door en zorg dat je planning goed is. werkt een stuk relaxter en geeft vaker betere resultaten

Tot zover deze wijze les

Verder nog wel een opmerking: waarom wil je de rechten aanpassen op de live omgeving en niet op dev/tst Lijkt me niet dat gebruikers zitten te wachten op grappen als ineens niet kunnen werken ivm fout toegekende rechten Als ik jou was zou ik om een kopie van productie vragen voor ik aan de slag ging

Wellicht is vistualiseren van de niet productieservers een optie om e.e.a. te versnellen btw...dan heb jij 1 machine waarom je een compleet systeemlandschap hebt en waarop je al je tests kunt doen zonder de live omgeving te raken

Tot slot: maak het bij je opdrachtgever duidelijk dat een standaard systeemlandschap bestaat uit BOTAP:
Baseline (basisomgeving, zonder verdere gegevens)
Ontwikkel
Test
Acceptatie
Productie

[Acid__Burn]

The Eagle schreef op donderdag 23 augustus 2007 @ 08:24:
Zoveel mogelijk doen in zo weinig mogelijk tijd is een leuk streven, alleen leidt het helaas maar al te vaak tot fouten. Relax, werk gewoon door en zorg dat je planning goed is. werkt een stuk relaxter en geeft vaker betere resultaten

Tot zover deze wijze les

Je hebt gelijk... En bedankt voor de wijze les

Verder nog wel een opmerking: waarom wil je de rechten aanpassen op de live omgeving en niet op dev/tst Lijkt me niet dat gebruikers zitten te wachten op grappen als ineens niet kunnen werken ivm fout toegekende rechten Als ik jou was zou ik om een kopie van productie vragen voor ik aan de slag ging

Omdat ik een inventarisatie wil maken van de Live omgeving. Zoals eerder vermeld gaat de Live omgeving binnenkort over op SQL 2005. De Dev en Test omgeving zijn nu nog een zooitje, te erg om nu aan te pakken. Daarvoor zou een vervanging moeten komen (Dev, Test, Pre-Live, Live). Dat komt dus later. Bij het overzetten wordt de Live omgeving toch naar test verplaatst, en dan kan ik gaan "klooien".


Maar dan nog een vraag: Moet ik voor alle rechtengroepen een S.G. aanmaken? Ik kan bijvoorbeeld voor Read/Write een groep aanmaken, maar moet dat dan ook voor DenyRead/DenyWrite? Ik zit niet met het probleem dat ik niet weet wat er moet gebeuren (ben ooit begonnen als systeembeheerder), maar wat is verstandig om aan te maken. Wil niet gelijk een hele rechtenstructuur erdoor drukken, die nog ingewikkelder is dan losse rechten op servers/databases. Het moet tenslotte gestructureerd en makkelijk worden.

[sanfranjake]

Ik zou eerst eens gaan inventariseren wat er allemaal precies nodig is, en aan de hand daarvan logisch je groepen indelen. En natuurlijk dan netjes domainlocal>global gebruiken zodat je met losse groepen/rechten combinaties kunt maken en het overzichtelijk blijft.

[Acid__Burn]

Lijkt me wel verstandig ja.

Ben inmiddels iets verder met de inventarisatie, en ben nu aangekomen op het rechten-indeel-moment. Nu komt het moeilijkste deel van het project, het logisch inrichten van rechten. Zat te denken aan de volgende groepen:

S_Servernaam_Databasenaam_Rechten

Dus:
S(ecurity Group)_London_Pubs_R(ead)W(rite).

Is dit verstandig denken jullie? En zo ja, moet ik voor ieder recht een groep aanmaken, of alleen voor de (nu) gebruikte rechten? Het gaat immers om 100+ databases. Dus 100 x 6 (gemiddeld) = 600 groepen in Active Directory...

[Verwijderd]

Je gaat er vanuit dat je of read rechten op de database hebt of write rechten (de db_reader/db_writer role). Echter de rechten structuur op je databases kan veel ingewikkelder zijn... Gebruiker A heeft rechten in database B, maar alleen op tabel X en mag alleen sp X uitvoeren. En als je met views werkt, kan het nog veel meer worden dan die 100 db's.

Het enige voordeel wat ik overigens zie aan zo'n opzet, is dat je de mogelijkheid hebt om rechten te delegeren zonder dat mensen binnen SQL rechten hebben en/of centrale administratie (alleen aanpassingen doen in AD, niet in SQL), maar dat kan ook niet wenselijk zijn als de SQL beheerders geen Administrators zijn in het domain.

[Acid__Burn]

Verwijderd schreef op dinsdag 28 augustus 2007 @ 16:21:
Je gaat er vanuit dat je of read rechten op de database hebt of write rechten (de db_reader/db_writer role). Echter de rechten structuur op je databases kan veel ingewikkelder zijn... Gebruiker A heeft rechten in database B, maar alleen op tabel X en mag alleen sp X uitvoeren. En als je met views werkt, kan het nog veel meer worden dan die 100 db's.

Dat klopt. Daar ben ik ook zo bang voor...

Het enige voordeel wat ik overigens zie aan zo'n opzet, is dat je de mogelijkheid hebt om rechten te delegeren zonder dat mensen binnen SQL rechten hebben en/of centrale administratie (alleen aanpassingen doen in AD, niet in SQL), maar dat kan ook niet wenselijk zijn als de SQL beheerders geen Administrators zijn in het domain.

Dat is ook het voordeel dat ik wil halen. Op dit moment staan overal losse rechten, en daar wil ik / willen we vanaf.

Nu is het zo dat de systeembeheerders ook zorgen voor de databases. Hopelijk gaan we binnenkort over op een DBA (ikzelf misschien...??? )

[Verwijderd]

Acid__Burn schreef op dinsdag 28 augustus 2007 @ 17:12:
[...]


Dat klopt. Daar ben ik ook zo bang voor...

Da's een kwestie van inventariseren. veel werk weliswaar...

Per server per database inventariseren en aanpassen. Iig kleine stukjes tegelijk aanpakken.

[Acid__Burn]

Verwijderd schreef op dinsdag 28 augustus 2007 @ 18:19:
[...]

Da's een kwestie van inventariseren. veel werk weliswaar...

Per server per database inventariseren en aanpassen. Iig kleine stukjes tegelijk aanpakken.

Ik ga er voor het gemak van uit dat een gebruiker rechten heeft op een hele DB. Alle losse rechten ga ik niet eens aan beginnen. Onze rechtenstructuur is niet om over naar huis te schrijven

Maar het probleem is, moet ik voor alle server roles een SG aanmaken? Dus:

1. Read
2. Read/Write
3. DBO
4. BulkAdmin
5. Server Admin
6. Sys Admin
7. Enz. enz. enz.

Daar zit ik over in. Maar ga er maar vanuit dat gebruiker X rechten heeft op de gehele database.

[Verwijderd]

ik zou het niet doen iig. alleen voor db_readers db_writers. Komt er een dbo of sysadmin bij dan voeg je die gewoon handmatig toe (maar waarschijnlijk doe je dat door toe te voegen aan de domain admins/administrators op de sql server).

[Acid__Burn]

Verwijderd schreef op woensdag 29 augustus 2007 @ 11:43:
ik zou het niet doen iig. alleen voor db_readers db_writers. Komt er een dbo of sysadmin bij dan voeg je die gewoon handmatig toe (maar waarschijnlijk doe je dat door toe te voegen aan de domain admins/administrators op de sql server).

Ok, bedankt voor de tips! Ik ga hier verder mee, en hopelijk komt het allemaal goed