Alt relasjonelt databasestyringssystemer gi en slags iboende sikkerhetsmekanismer designet for å minimere truslene om datatap, datakorrupsjon eller datatyveri. De spenner fra den enkle passordbeskyttelsen som tilbys av Microsoft Access til den komplekse bruker- / rollestrukturen støttet av avanserte relasjonsdatabaser som Oracle ogMicrosoft SQL Server. Noen sikkerhetsmekanismer er felles for alle databaser som implementererStrukturert spørrespråk.
Sikkerhet på brukernivå
Serverbaserte databaser støtter a bruker konsept som ligner på det som brukes i datamaskinoperativsystemer. Hvis du er kjent med bruker- / gruppehierarkiet i Microsoft Windows NT og Windows 2000, vil du oppdage at bruker- / rollegrupperingene som støttes av SQL Server og Oracle er like.
Opprett individuelle databasebrukerkontoer for hver person med tilgang til databasen din.
Unngå å skaffe generiske kontoer som er tilgjengelige for flere forskjellige personer. For det første eliminerer denne praksisen individuell ansvarlighet - hvis en bruker endrer databasen din (la oss si av å gi seg en $ 5.000-økning), vil du ikke kunne spore det tilbake til en bestemt person gjennom bruk av revisjon tømmerstokker. For det andre, hvis en bestemt bruker forlater organisasjonen din og du vil fjerne tilgangen hans fra databasen, må du endre passordet som alle brukere er avhengige av.
Metodene for å opprette brukerkontoer varierer fra plattform til plattform, og du må konsultere den DBMS-spesifikke dokumentasjonen for den nøyaktige prosedyren. Microsoft SQL Server-brukere bør undersøke bruken av sp_adduser lagret prosedyre. Oracle-databaseadministratorer finner OPPRETT BRUKER kommando nyttig. Det kan også være lurt å undersøke alternative autentiseringsordninger. For eksempel støtter Microsoft SQL Server bruk av Windows NT Integrated Security. I henhold til denne ordningen blir brukere identifisert til databasen av sine Windows NT-brukerkontoer, og de trenger ikke å oppgi en ekstra bruker-ID og et passord for å få tilgang til databasen. Denne tilnærmingen er populær blant databaseadministratorer fordi den forskyver kontobyrden administrasjon til nettverksadministrasjonspersonalet, og det er enkelt å logge på slutt bruker.
Rollesikkerhet
Hvis du er i et miljø med et lite antall brukere, vil du sannsynligvis oppdage at det er tilstrekkelig å opprette brukerkontoer og tildele tillatelser direkte til dem. Men hvis du har et stort antall brukere, vil du bli overveldet av å opprettholde kontoer og riktig tillatelse. For å lette denne byrden støtter relasjonsdatabaser roller. Databaseroller fungerer på samme måte som Windows NT-grupper. Brukerkontoer tildeles rolle (r), og tillatelser tildeles deretter rollen som en helhet i stedet for de enkelte brukerkontoer. For eksempel kan du opprette en DBA-rolle og deretter legge til brukerkontiene til det administrative personalet i denne rollen. Etter det kan du tildele en spesifikk tillatelse til alle nåværende (og fremtidige) administratorer ved å bare tildele tillatelsen til rollen. Nok en gang varierer prosedyrene for å opprette roller fra plattform til plattform. MS SQL Server-administratorer bør undersøke sp_addrole lagret prosedyre mens Oracle DBA-er bør bruke OPPRETT ROLLE syntaks.
Gi tillatelser
Nå som vi har lagt til brukere i databasen vår, er det på tide å styrke sikkerheten ved å legge til tillatelser. Vårt første skritt vil være å gi passende databasetillatelser til brukerne våre. Vi vil oppnå dette ved bruk av SQL GRANT-setningen.
Her er syntaksen for utsagnet:
STIPEND.
[PÅ.
TIL.
[MED TILVALGsmulighet]
La oss nå ta en titt på denne uttalelsen linje for linje. Første linje, STIPEND , lar oss spesifisere de spesifikke tabelltillatelsene vi gir. Disse kan enten være tillatelser på tabellnivå (som SELECT, INSERT, UPDATE og DELETE) eller databasetillatelser (som CREATE TABLE, ALTER DATABASE og GRANT). Mer enn én tillatelse kan gis i en enkelt GRANT-setning, men tillatelser på tabellnivå og databasenivå kan ikke kombineres i en enkelt uttalelse.
Den andre linjen, PÅ
Endelig, den fjerde linjen, MED TILVALGSALTERNATIV, er valgfritt. Hvis denne linjen er inkludert i uttalelsen, har den berørte brukeren også lov til å gi de samme tillatelsene til andre brukere. Merk at MED GRANT-ALTERNATIV ikke kan spesifiseres når tillatelsene tildeles en rolle.
Eksempel på databasestipend
La oss se på noen få eksempler. I vårt første scenario har vi nylig ansatt en gruppe på 42 dataregistreringsoperatører som vil legge til og opprettholde kundeoppføringer. De må få tilgang til informasjon i kundetabellen, endre denne informasjonen og legge til nye poster i tabellen. De skal ikke kunne slette en post helt fra databasen.
Først bør vi opprette brukerkontoer for hver operatør og deretter legge dem alle til en ny rolle, DataEntry. Deretter bør vi bruke følgende SQL-setning for å gi dem de riktige tillatelsene:
GRANT VALG, INSERT, OPPDATERING.
PÅ Kunder.
TIL DataEntry.
La oss nå undersøke et tilfelle der vi tildeler tillatelser på databasenivå. Vi vil tillate at medlemmer av DBA-rollen legger til nye tabeller i databasen vår. Videre ønsker vi at de skal kunne gi andre brukere tillatelse til å gjøre det samme. Her er SQL-setningen:
TILGANG OPPRETT TABELL.
TIL DBA.
MED TILVALGSALTERNATIV.
Legg merke til at vi har tatt med linjen WITH GRANT OPTION for å sikre at DBA-ene våre kan tildele denne tillatelsen til andre brukere.
Fjerner tillatelser
SQL inkluderer REVOKE-kommandoen for å fjerne tidligere gitt tillatelser. Her er syntaksen:
TILBAKE [TILVALGsmULIGHET FOR]
PÅ.
FRA.
Du vil legge merke til at syntaksen til denne kommandoen er lik den for GRANT-kommandoen. Den eneste forskjellen er at MED GRANT OPTION er spesifisert på REVOKE-kommandolinjen i stedet for på slutten av kommandoen. La oss som et eksempel forestille oss at vi vil tilbakekalle Marys tidligere gitt tillatelse til å fjerne poster fra kundedatabasen. Vi bruker følgende kommando:
TILBAKE SLETT.
PÅ Kunder.
FRA Mary.
Det er en ekstra mekanisme støttet av Microsoft SQL Server som er verdt å nevne - DENY-kommandoen. Denne kommandoen kan brukes til å eksplisitt nekte en tillatelse til en bruker som de ellers kan ha gjennom et nåværende eller fremtidig rollemedlemskap. Her er syntaksen:
BENEKTE.
PÅ.
TIL.