Toegangsbeheer vir gebruikers en rolle in SQL

Sekuriteit is uiters belangrik vir databasis administrateurs wat hul gigabyte van belangrike besigheidsdata beskerm teen die gierige oë van ongemagtigde buitestaanders en insiders wat hul gesag probeer oorskry. Alle relasionele databasis bestuurstelsels bied 'n soort van intrinsieke sekuriteits meganismes ontwerp om hierdie bedreigings te verminder. Hulle wissel van die eenvoudige wagwoordbeskerming wat Microsoft Access bied aan die komplekse gebruiker / rolstruktuur wat ondersteun word deur gevorderde relasionele databasisse soos Oracle en Microsoft SQL Server. Hierdie artikel fokus op die veiligheidsmeganismes wat algemeen is vir alle databasisse wat die gestruktureerde navraagstaal (of SQL ) implementeer. Saam sal ons die proses van versterking van toegang tot data beheer en die veiligheid van u data verseker.

gebruikers

Server-gebaseerde databasisse ondersteun almal 'n gebruikersbegrip soortgelyk aan dié wat in rekenaarbedryfstelsels gebruik word. As jy bekend is met die gebruiker / groep hiërargie wat in Microsoft Windows NT en Windows 2000 gevind word, sal jy vind dat die gebruiker / rolgroeperings wat deur SQL Server en Oracle ondersteun word, baie ooreenstem.

Dit word sterk aanbeveel dat u individuele databasis gebruikersrekeninge skep vir elke persoon wat toegang tot u databasis sal hê. Dit is tegnies moontlik om rekeninge tussen gebruikers te deel of net een gebruikersrekening te gebruik vir elke tipe gebruiker wat toegang tot u databasis nodig het, maar ek weier om twee redes hierdie praktyk sterk af. Eerstens sal dit individuele aanspreeklikheid uitskakel. As 'n gebruiker 'n verandering in u databasis maak (byvoorbeeld, deur homself 'n $ 5 000 verhoging te gee), kan u dit nie terugvoer na 'n spesifieke persoon deur middel van ouditlogboeke nie. Verder, as 'n spesifieke gebruiker u organisasie verlaat en u wil sy of haar toegang uit die databasis verwyder, sal u gedwing word om die wagwoord te verander waarop alle gebruikers staatmaak.

Die metodes vir die maak van gebruikersaccounts wissel van platform tot platform en u moet u DBMS-spesifieke dokumentasie raadpleeg vir die presiese prosedure. Microsoft SQL Server-gebruikers moet die gebruik van die sp_adduser gestoor prosedure ondersoek. Oracle databasis administrateurs sal die opdrag CREATE USER nuttig vind. U kan ook alternatiewe verifikasie skemas ondersoek. Byvoorbeeld, Microsoft SQL Server ondersteun die gebruik van Windows NT Geïntegreerde Sekuriteit. Onder hierdie skema word gebruikers in die databasis geïdentifiseer deur hul Windows NT gebruikersrekeninge en hoef nie 'n bykomende gebruikers-ID en wagwoord in te voer om toegang tot die databasis te verkry nie. Hierdie benadering is uiters gewild onder databasisadministrateurs omdat dit die laste van rekeningbestuur na die netwerkadministrasiepersoneel verskuif en dit bied die gemak van 'n enkele aanmelding aan die eindgebruiker.

rolle

As jy in 'n omgewing met 'n klein aantal gebruikers is, sal jy waarskynlik vind dat die skep van gebruikersrekeninge en die toekenning van regte direk aan hulle toereikend is vir jou behoeftes. As jy egter 'n groot aantal gebruikers het, sal jy waarskynlik oorweldig word deur die verantwoordelikheid om rekeninge en behoorlike regte te behou. Om hierdie las te verlig, ondersteun relasionele databasisse die konsep van rolle. Databasis rolle funksioneer soortgelyk aan Windows NT groepe. Gebruikersrekeninge word toegeken aan rol (te) en toestemmings word dan aan die rol as geheel toegewys, eerder as die individuele gebruikersrekeninge. Byvoorbeeld, ons kan 'n DBA-rol skep en dan die gebruikersrekeninge van ons administratiewe personeel by hierdie rol voeg. Sodra ons dit gedoen het, kan ons 'n spesifieke toestemming aan alle huidige (en toekomstige) administrateurs toeken deur bloot die toestemming vir die rol toe te ken. Die prosedures vir die skep van rolle wissel weereens van platform tot platform. MS SQL Server administrateurs moet die sp_addrole gestoor prosedure ondersoek, terwyl Oracle DBAs die SKEP-ROL-sintaksis moet gebruik.

Toestaan ​​van Toestemmings

Noudat ons gebruikers aan ons databasis bygevoeg het, is dit tyd om die beveiliging te versterk deur toestemmings toe te voeg. Ons eerste stap sal wees om toepaslike databasis toestemmings aan ons gebruikers toe te staan. Ons sal dit bereik deur die gebruik van die SQL GRANT-stelling.

Hier is die sintaksis van die stelling:

TOELATING
[ON ]
AAN
[MET TOELATING OPSIE]

Kom ons kyk nou na hierdie stelling line-for-line. Die eerste reël, GRANT , stel ons in staat om die spesifieke tabel toestemmings wat ons toestaan, te spesifiseer. Dit kan óf op tabelvlak toestemmings (soos SELECT, INSERT, UPDATE en DELETE) of databasis toestemmings (soos CREATE TABLE, ALTER DATABASE en GRANT) wees. Meer as een toestemming kan toegeken word in 'n enkele GRANT-stelling, maar toestemmings op tabelvlak en databasisvlak mag nie in 'n enkele stelling gekombineer word nie.

Die tweede reël, ON , word gebruik om die betrokke tabel vir tabelvlaktoestemmings te spesifiseer. Hierdie reël word weggelaat as ons toestemmings op databasisvlak verleen. Die derde reël spesifiseer die gebruiker of rol wat toestemmings verleen word.

Ten slotte is die vierde reël, MET TOEKENNINGSopsie, opsioneel. As hierdie lyn in die stelling ingesluit is, kan die gebruiker ook dieselfde toestemmings aan ander gebruikers verleen. Let daarop dat die MET GRANT OPSIE nie gespesifiseer kan word wanneer die regte aan 'n rol toegeken word nie.

voorbeelde

Kom ons kyk na 'n paar voorbeelde. In ons eerste scenario het ons onlangs 'n groep van 42 data-invoeroperateurs gehuur wat kliëntrekords sal byvoeg en onderhou. Hulle moet toegang hê tot inligting in die tabel Klante, verander hierdie inligting en voeg nuwe rekords by die tabel. Hulle behoort nie 'n rekord uit die databasis heeltemal te verwyder nie. Eerstens moet ons gebruikersrekeninge vir elke operateur skep en dan hulle almal by 'n nuwe rol, DataEntry, voeg. Vervolgens moet ons die volgende SQL-stelling gebruik om hulle die regte regte toe te ken:

GRANT SELECT, INSERT, UPDATE
ON Kliënte
AAN DataEntry

En dis alles wat daar is! Kom ons ondersoek nou 'n saak waar ons toewysings op databasisvlak toeken. Ons wil lede van die DBA-rol toelaat om nuwe tabelle by ons databasis by te voeg. Verder wil ons hê hulle moet ander gebruikers toestemming gee om dieselfde te doen. Hier is die SQL-stelling:

TOEWOORD SKEP TAFEL
TOT DBA
MET TOELATING OPSIE

Let op dat ons die MET GRANT OPTION-lyn ingesluit het om te verseker dat ons DBA's hierdie toestemming aan ander gebruikers kan toewys.

Verwyder toestemmings

Sodra ons toestemmings verleen het, is dit dikwels nodig om dit later te herroep. Gelukkig bied SQL ons die REVOKE-opdrag om voorheen verleende toestemmings te verwyder. Hier is die sintaksis:

HERSIEN [TOEGELAAT OPSIE VIR]
AAN
VANAF

U sal merk dat die sintaksis van hierdie opdrag soortgelyk is aan die van die bevel GRANT. Die enigste verskil is dat AANVULLENDE OPSIE gespesifiseer word op die REVOKE-bevellyn eerder as aan die einde van die opdrag. Byvoorbeeld, laat ons voorstel dat ons Mary se voorheen verleende toestemming wil herroep om rekords van die Kliënte-databasis te verwyder. Ons sal die volgende opdrag gebruik:

REVOKE DELETE
ON Kliënte
VANAF Maria

En dis alles wat daar is! Daar is een addisionele meganisme ondersteun deur Microsoft SQL Server wat die moeite werd is om te noem - die bevel van DENY. Hierdie opdrag kan gebruik word om eksplisiet 'n toestemming vir 'n gebruiker te ontken wat hulle andersins deur 'n huidige of toekomstige rolmaatskap kan hê. Hier is die sintaksis:

Ontken
AAN
AAN

voorbeelde

As ons terugkeer na ons vorige voorbeeld, stel ons voor dat Mary ook 'n lid was van die bestuurdersrol wat ook toegang tot die kliënte-tafel gehad het. Die vorige REVOKE-stelling sal nie voldoende wees om haar toegang tot die tafel te ontken nie. Dit sal die toestemming wat aan haar verleen word, verwyder deur 'n GRANT-verklaring wat haar gebruikersrekening rig, maar sal nie die toestemmings wat deur haar lidmaatskap in die Bestuurdersrol verkry word, beïnvloed nie. As ons egter 'n DENY-verklaring gebruik, sal dit haar erfenis van die toestemming blokkeer. Hier is die opdrag:

Ontken DELETE
ON Kliënte
Na mary

Die bevel DENY gee in wese 'n "negatiewe toestemming" in die databasis toegangskontroles. As ons later besluit om vir Mary toestemming te gee om rye uit die kliënte-tabel te verwyder, kan ons nie die TOESTEL-bevel gebruik nie. Hierdie bevel sal onmiddellik deur die bestaande DENY oorskry word. In plaas daarvan sal ons eers die REVOKE-opdrag gebruik om die negatiewe toestemminginskrywing as volg te verwyder:

REVOKE DELETE
ON Kliënte
VANAF Maria

U sal sien dat hierdie opdrag presies dieselfde is as die een wat gebruik is om 'n positiewe toestemming te verwyder. Onthou dat die DENY en GRANT beide werk op 'n soortgelyke manier * mdash beveel; hulle skep albei toestemmings (positief of negatief) in die databasis toegangsbeheer meganisme. Die REVOKE-opdrag verwyder alle positiewe en negatiewe toestemmings vir die gespesifiseerde gebruiker. Sodra hierdie bevel uitgereik is, sal Mary rye van die tafel kan verwyder as sy 'n lid is van 'n rol wat daardie toestemming het. Alternatiewelik kan 'n GRANT-opdrag uitgereik word om die DELETE-toestemming direk op haar rekening te voorsien.

Gedurende die loop van hierdie artikel het jy 'n goeie deal geleer oor die toegangsbeheermeganismes wat deur die standaard navraagstaal ondersteun word. Hierdie inleiding moet u 'n goeie beginpunt gee, maar ek moedig u aan om u DBMS dokumentasie te verwys om die verbeterde veiligheidsmaatreëls wat deur u stelsel ondersteun word, te leer. Jy sal vind dat baie databasisse meer gevorderde toegangsbeheermeganismes ondersteun, soos die toestaan ​​van toestemmings op spesifieke kolomme.