Alt relationelt databasestyringssystemer give en slags iboende sikkerhedsmekanismer designet til at minimere truslerne om datatab, datakorruption eller datatyveri. De spænder fra den enkle adgangskodebeskyttelse, der tilbydes af Microsoft Access til den komplekse bruger / rolle struktur understøttet af avancerede relationsdatabaser som Oracle ogMicrosoft SQL Server. Nogle sikkerhedsmekanismer er fælles for alle databaser, der implementererStruktureret forespørgselssprog.
Sikkerhed på brugerniveau
Serverbaserede databaser understøtter a bruger koncept svarende til det, der anvendes i computeroperativsystemer. Hvis du er fortrolig med bruger- / gruppehierarkiet i Microsoft Windows NT og Windows 2000, finder du ud af, at de bruger- / rollegrupperinger, der understøttes af SQL Server og Oracle, er ens.
Opret individuelle databasebrugerkonti for hver person med adgang til din database.
Undgå at tilvejebringe generiske konti, der er tilgængelige for flere forskellige personer. For det første eliminerer denne praksis individuel ansvarlighed - hvis en bruger foretager en ændring i din database (lad os sige ved giver sig selv $ 5.000 hævning), vil du ikke kunne spore det tilbage til en bestemt person ved hjælp af revision logfiler. For det andet, hvis en bestemt bruger forlader din organisation, og du ønsker at fjerne hans eller hendes adgang fra databasen, skal du ændre den adgangskode, som alle brugere er afhængige af.
Metoderne til oprettelse af brugerkonti varierer fra platform til platform, og du bliver nødt til at konsultere din DBMS-specifikke dokumentation for den nøjagtige procedure. Microsoft SQL Server-brugere bør undersøge brugen af sp_adduser gemt procedure. Oracle-databaseadministratorer finder OPRET BRUGER kommando nyttig. Det kan også være en god idé at undersøge alternative godkendelsesordninger. For eksempel understøtter Microsoft SQL Server brugen af Windows NT Integrated Security. Under denne ordning identificeres brugerne til databasen af deres Windows NT-brugerkonti og er ikke forpligtet til at indtaste et ekstra bruger-id og en adgangskode for at få adgang til databasen. Denne tilgang er populær blandt databaseadministratorer, fordi den skifter kontobelastningen ledelse til personalet på netværksadministrationen, og det giver en enkel pålogning til slutbruger.
Rollesikkerhed
Hvis du er i et miljø med et lille antal brugere, vil du sandsynligvis opdage, at det er tilstrækkeligt at oprette brugerkonti og tildele tilladelser direkte til dem. Men hvis du har et stort antal brugere, bliver du overvældet af vedligeholdelse af konti og korrekte tilladelser. For at lette denne byrde understøtter relationsdatabaser roller. Databaseroller fungerer på samme måde som Windows NT-grupper. Brugerkonti tildeles til rolle (r), og tilladelser tildeles derefter rollen som en helhed snarere end de individuelle brugerkonti. For eksempel kan du oprette en DBA-rolle og derefter tilføje brugerkonti for dit administrative personale til denne rolle. Derefter kan du tildele en bestemt tilladelse til alle nuværende (og fremtidige) administratorer ved blot at tildele tilladelsen til rollen. Igen varierer procedurerne for oprettelse af roller fra platform til platform. MS SQL Server-administratorer bør undersøge sp_addrole gemt procedure, mens Oracle DBA'er skal bruge OPRET ROLLE syntaks.
Tilladelse
Nu hvor vi har føjet brugere til vores database, er det tid til at begynde at styrke sikkerheden ved at tilføje tilladelser. Vores første skridt bliver at give vores brugere passende databasetilladelser. Vi opnår dette ved hjælp af SQL GRANT-sætningen.
Her er syntaksen for udsagnet:
GIVE.
[PÅ.
TIL.
[MED TILVALGMULIGHED]
Lad os nu se på denne erklæring linje for linje. Den første linje, GIVE , giver os mulighed for at specificere de specifikke tabeltilladelser, vi giver. Disse kan enten være tilladelser på tabelniveau (såsom SELECT, INSERT, UPDATE og SLET) eller databasetilladelser (såsom CREATE TABLE, ALTER DATABASE og GRANT). Mere end én tilladelse kan gives i en enkelt GRANT-sætning, men tilladelser på tabelniveau og tilladelser på databaseniveau kombineres muligvis ikke i en enkelt erklæring.
Den anden linje, PÅ
Endelig, den fjerde linje, MED TILVALGMULIGHED, er valgfri. Hvis denne linje er inkluderet i erklæringen, har den berørte bruger også tilladelse til at give de samme tilladelser til andre brugere. Bemærk, at MED GRANT-MULIGHEDEN ikke kan specificeres, når tilladelserne tildeles en rolle.
Eksempel på databasetilskud
Lad os se på et par eksempler. I vores første scenario har vi for nylig ansat en gruppe på 42 dataindtastningsoperatører, der vil tilføje og vedligeholde kundeoptegnelser. De skal få adgang til oplysninger i tabellen Kunder, ændre disse oplysninger og tilføje nye poster til tabellen. De skulle ikke være i stand til helt at slette en post fra databasen.
Først skal vi oprette brugerkonti til hver operatør og derefter føje dem alle til en ny rolle, Indtastning af data. Dernæst skal vi bruge følgende SQL-sætning til at give dem de relevante tilladelser:
GRANT VÆLG, INDSÆT, OPDATER.
TIL Kunder.
TIL DataEntry.
Lad os nu undersøge en sag, hvor vi tildeler tilladelser på databaseniveau. Vi vil tillade medlemmer af DBA-rollen at tilføje nye tabeller til vores database. Desuden ønsker vi, at de skal kunne give andre brugere tilladelse til at gøre det samme. Her er SQL-sætningen:
TILSKUD OPRET TABEL.
TIL DBA.
MED TILVALGsmulighed.
Bemærk, at vi har inkluderet linjen WITH GRANT OPTION for at sikre, at vores DBA'er kan tildele denne tilladelse til andre brugere.
Fjernelse af tilladelser
SQL inkluderer kommandoen REVOKE for at fjerne tidligere tildelte tilladelser. Her er syntaksen:
TILBAGEVALD [TILVALGMULIGHED FOR]
PÅ.
FRA.
Du bemærker, at syntaksen for denne kommando svarer til den for GRANT-kommandoen. Den eneste forskel er, at MED GRANT OPTION er specificeret på REVOKE kommandolinjen snarere end i slutningen af kommandoen. Lad os som et eksempel forestille os, at vi vil tilbagekalde Marys tidligere tildelte tilladelse til at fjerne poster fra kundedatabasen. Vi bruger følgende kommando:
TILBAGEGANG SLET.
TIL Kunder.
FRA Mary.
Der er en yderligere mekanisme understøttet af Microsoft SQL Server, der er værd at nævne - DENY-kommandoen. Denne kommando kan bruges til eksplicit at nægte en bruger tilladelse, som de ellers måtte have gennem et nuværende eller fremtidigt rollemedlemskab. Her er syntaksen:
NÆGTE.
PÅ.
TIL.