Allt relationellt databashanteringssystem tillhandahålla någon form av inneboende säkerhetsmekanismer som är utformade för att minimera hoten om dataförlust, datakorruption eller datastöld. De sträcker sig från det enkla lösenordsskydd som erbjuds av Microsoft Access till den komplexa användar- / rollstrukturen som stöds av avancerade relationsdatabaser som Orakel ochMicrosoft SQL Server. Vissa säkerhetsmekanismer är vanliga för alla databaser som implementerarStructured Query Language.
Säkerhet på användarnivå
Serverbaserade databaser stöder a användare koncept som liknar det som används i datoroperativsystem. Om du känner till användar- / grupphierarkin i Microsoft Windows NT och Windows 2000 kommer du att upptäcka att användar- / rollgrupperna som stöds av SQL Server och Oracle liknar varandra.
Skapa enskilda databasanvändarkonton för varje person med åtkomst till din databas.
Undvik att tillhandahålla generiska konton som är tillgängliga för flera olika personer. För det första eliminerar denna praxis individuell ansvarsskyldighet - om en användare gör en ändring i din databas (låt oss säga med ger sig en $ 5000-höjning) kommer du inte att kunna spåra tillbaka till en specifik person genom att använda revision loggar. För det andra, om en specifik användare lämnar din organisation och du vill ta bort hans eller hennes åtkomst från databasen, måste du ändra lösenordet som alla användare litar på.
Metoderna för att skapa användarkonton varierar från plattform till plattform och du måste konsultera din DBMS-specifika dokumentation för exakt procedur. Microsoft SQL Server-användare bör undersöka användningen av sp_adduser lagrad procedur. Oracle-databasadministratörer hittar SKAPA ANVÄNDARE kommando användbart. Du kanske också vill undersöka alternativa autentiseringsscheman. Till exempel stöder Microsoft SQL Server användningen av Windows NT Integrated Security. Enligt detta schema identifieras användare i databasen av sina Windows NT-användarkonton och behöver inte ange ytterligare ett användar-ID och lösenord för att komma åt databasen. Detta tillvägagångssätt är populärt bland databasadministratörer eftersom det förskjuter kontobördan ledning till nätverksadministratörens personal och det underlättar en enkel inloggning på slutanvändare.
Rollsäkerhet
Om du befinner dig i en miljö med ett litet antal användare kommer du förmodligen att upptäcka att det är tillräckligt att skapa användarkonton och tilldela behörigheter direkt till dem. Men om du har ett stort antal användare blir du överväldigad av att ha konton och behöriga behörigheter. För att underlätta denna börda stöder relationsdatabaser roller. Databasroller fungerar på samma sätt som Windows NT-grupper. Användarkonton tilldelas roll (er) och behörigheter tilldelas sedan rollen som en helhet snarare än de enskilda användarkontona. Du kan till exempel skapa en DBA-roll och sedan lägga till användarkonton för din administrativa personal till den här rollen. Därefter kan du tilldela en specifik behörighet till alla nuvarande (och framtida) administratörer genom att helt enkelt tilldela behörigheten till rollen. Återigen varierar procedurerna för att skapa roller från plattform till plattform. MS SQL Server-administratörer bör undersöka sp_addrole lagrade proceduren medan Oracle DBA: er bör använda SKAPA ROLL syntax.
Beviljande av tillstånd
Nu när vi har lagt till användare i vår databas är det dags att börja stärka säkerheten genom att lägga till behörigheter. Vårt första steg blir att ge lämpliga databasbehörigheter till våra användare. Vi kommer att åstadkomma detta med hjälp av SQL GRANT-uttalandet.
Här är syntaxen för uttalandet:
BEVILJA.
[PÅ.
TILL.
[MED TILLVALSALTERNATIV]
Låt oss nu titta på detta uttalande rad för rad. Den första raden, BEVILJA , låter oss ange de specifika tabellbehörigheter som vi beviljar. Dessa kan vara antingen behörigheter på bordsnivå (som SELECT, INSERT, UPDATE och DELETE) eller databasbehörigheter (som CREATE TABLE, ALTER DATABASE och GRANT). Mer än en behörighet kan beviljas i ett enda GRANT-uttalande, men behörigheter på tabellnivå och behörigheter på databasnivå kanske inte kombineras i ett enda uttalande.
Den andra raden, PÅ
Slutligen, den fjärde raden, MED GRANTALTERNATIV, är valfritt. Om den här raden ingår i uttalandet får den berörda användaren också ge samma behörigheter till andra användare. Observera att MED GRANT-ALTERNATIV inte kan anges när behörigheterna tilldelas en roll.
Exempel på databasbidrag
Låt oss titta på några exempel. I vårt första scenario har vi nyligen anställt en grupp med 42 datainmatningsoperatörer som kommer att lägga till och underhålla kundregister. De måste komma åt information i tabellen Kunder, ändra den här informationen och lägga till nya poster i tabellen. De borde inte kunna radera en post helt från databasen.
Först bör vi skapa användarkonton för varje operatör och sedan lägga till dem alla i en ny roll, Datainmatning. Därefter ska vi använda följande SQL-uttalande för att ge dem rätt behörighet:
GRANT VÄLJ, INSÄTT, UPPDATERA.
PÅ Kunder.
TILL DataEntry.
Låt oss nu undersöka ett fall där vi tilldelar behörigheter på databasnivå. Vi vill tillåta medlemmar av DBA-rollen att lägga till nya tabeller i vår databas. Dessutom vill vi att de ska kunna ge andra användare tillstånd att göra detsamma. Här är SQL-uttalandet:
ANVÄND SKAPA TABELL.
TILL DBA.
MED BILAGAALTERNATIV.
Lägg märke till att vi har inkluderat raden WITH GRANT OPTION för att säkerställa att våra DBA kan tilldela denna behörighet till andra användare.
Ta bort behörigheter
SQL inkluderar kommandot REVOKE för att ta bort tidigare beviljade behörigheter. Här är syntaxen:
ÅTERKALKA [TILLVALSALTERNATIV FÖR]
PÅ.
FRÅN.
Du kommer att märka att syntaxen för detta kommando liknar den för GRANT-kommandot. Den enda skillnaden är att MED GRANT OPTION anges på kommandoraden REVOKE snarare än i slutet av kommandot. Som ett exempel, låt oss föreställa oss att vi vill återkalla Marys tidigare beviljade tillstånd att ta bort poster från kunddatabasen. Vi skulle använda följande kommando:
ÅTERKALDA RADERA.
PÅ Kunder.
FRÅN Mary.
Det finns ytterligare en mekanism som stöds av Microsoft SQL Server som är värt att nämna - kommandot DENY. Detta kommando kan användas för att uttryckligen neka en användares behörighet som de annars skulle ha genom ett nuvarande eller framtida rollmedlemskap. Här är syntaxen:
FÖRNEKA.
PÅ.
TILL.