Allemaal relationeel databasebeheersystemen bieden een soort intrinsieke beveiligingsmechanismen die zijn ontworpen om de dreigingen van gegevensverlies, gegevenscorruptie of gegevensdiefstal te minimaliseren. Ze variëren van de eenvoudige wachtwoordbeveiliging die wordt geboden door: Microsoft Access naar de complexe gebruikers-/rolstructuur die wordt ondersteund door geavanceerde relationele databases zoals: Orakel enMicrosoft SQL Server. Sommige beveiligingsmechanismen zijn gemeenschappelijk voor alle databases die deStructured Query Language.
Beveiliging op gebruikersniveau
Servergebaseerde databases ondersteunen a gebruiker concept vergelijkbaar met dat gebruikt in computerbesturingssystemen. Als u bekend bent met de gebruikers-/groepshiërarchie in Microsoft Windows NT en Windows 2000, zult u merken dat de gebruikers-/rolgroepen die worden ondersteund door SQL Server en Oracle vergelijkbaar zijn.
Maak individuele databasegebruikersaccounts aan voor elke persoon met toegang tot uw database.
Vermijd het inrichten van generieke accounts die toegankelijk zijn voor verschillende personen. Ten eerste elimineert deze praktijk individuele verantwoordelijkheid - als een gebruiker een wijziging aanbrengt in uw database (laten we zeggen door zichzelf een verhoging van $ 5.000 geeft), kun je het niet terugleiden naar een specifieke persoon door middel van audit logboeken. Ten tweede, als een specifieke gebruiker uw organisatie verlaat en u zijn of haar toegang uit de database wilt verwijderen, moet u het wachtwoord wijzigen waarop alle gebruikers vertrouwen.
De methoden voor het aanmaken van gebruikersaccounts verschillen van platform tot platform en u zult uw DBMS-specifieke documentatie moeten raadplegen voor de exacte procedure. Gebruikers van Microsoft SQL Server moeten het gebruik van de sp_adduser opgeslagen procedure. Oracle-databasebeheerders zullen de: GEBRUIKER MAKEN commando handig. Mogelijk wilt u ook alternatieve authenticatieschema's onderzoeken. Microsoft SQL Server ondersteunt bijvoorbeeld het gebruik van Windows NT Integrated Security. Volgens dit schema worden gebruikers in de database geïdentificeerd door hun Windows NT-gebruikersaccounts en hoeven ze geen extra gebruikers-ID en wachtwoord in te voeren om toegang te krijgen tot de database. Deze aanpak is populair onder databasebeheerders omdat het de last van de account verschuift beheer aan het netwerkbeheerpersoneel en het biedt het gemak van een eenmalige aanmelding bij de eindgebruiker.
Beveiliging op rolniveau
Als u zich in een omgeving met een klein aantal gebruikers bevindt, zult u waarschijnlijk merken dat het maken van gebruikersaccounts en het rechtstreeks toewijzen van machtigingen aan hen voldoende is voor uw behoeften. Als u echter een groot aantal gebruikers heeft, wordt u overweldigd door het onderhouden van accounts en de juiste machtigingen. Om deze last te verlichten, ondersteunen relationele databases rollen. Databaserollen werken op dezelfde manier als Windows NT-groepen. Gebruikersaccounts worden toegewezen aan rol(len) en machtigingen worden vervolgens toegewezen aan de rol als geheel in plaats van aan de individuele gebruikersaccounts. U kunt bijvoorbeeld een DBA-rol maken en vervolgens de gebruikersaccounts van uw administratief personeel aan deze rol toevoegen. Daarna kunt u een specifieke machtiging toewijzen aan alle huidige (en toekomstige) beheerders door de machtiging eenvoudig aan de rol toe te wijzen. Nogmaals, de procedures voor het maken van rollen variëren van platform tot platform. MS SQL Server-beheerders moeten de: sp_addrole opgeslagen procedure terwijl Oracle DBA's de ROL MAKEN syntaxis.
Toestemmingen verlenen
Nu we gebruikers aan onze database hebben toegevoegd, is het tijd om de beveiliging te versterken door machtigingen toe te voegen. Onze eerste stap is het verlenen van de juiste databaserechten aan onze gebruikers. We zullen dit bereiken door het gebruik van de SQL GRANT-instructie.
Hier is de syntaxis van de verklaring:
VERLENEN.
[AAN.
NAAR.
[MET SUBSIDIEOPTIE]
Laten we deze verklaring nu regel voor regel bekijken. De eerste regel, VERLENEN , stelt ons in staat om de specifieke tabelmachtigingen te specificeren die we verlenen. Dit kunnen machtigingen op tabelniveau zijn (zoals SELECT, INSERT, UPDATE en DELETE) of databasemachtigingen (zoals CREATE TABLE, ALTER DATABASE en GRANT). In één GRANT-instructie kan meer dan één machtiging worden verleend, maar machtigingen op tabelniveau en machtigingen op databaseniveau mogen niet in één instructie worden gecombineerd.
De tweede regel, AAN
Eindelijk, de vierde regel, MET SUBSIDIEOPTIE, is optioneel. Als deze regel in de instructie wordt opgenomen, mag de betrokken gebruiker dezelfde rechten ook aan andere gebruikers verlenen. Houd er rekening mee dat de WITH GRANT OPTION niet kan worden opgegeven wanneer de machtigingen zijn toegewezen aan een rol.
Voorbeeld databasesubsidies
Laten we een paar voorbeelden bekijken. In ons eerste scenario hebben we onlangs een groep van 42 data-entry operators ingehuurd die klantrecords zullen toevoegen en onderhouden. Ze moeten toegang krijgen tot informatie in de tabel Klanten, deze informatie wijzigen en nieuwe records aan de tabel toevoegen. Ze mogen een record niet volledig uit de database kunnen verwijderen.
Eerst moeten we gebruikersaccounts maken voor elke operator en ze vervolgens allemaal toevoegen aan een nieuwe rol, Gegevensinvoer. Vervolgens moeten we de volgende SQL-instructie gebruiken om hen de juiste machtigingen te verlenen:
GRANT SELECT, INSERT, UPDATE.
ON Klanten.
NAAR gegevensinvoer.
Laten we nu eens kijken naar een geval waarin we machtigingen op databaseniveau toewijzen. We willen leden van de DBA-rol toestaan nieuwe tabellen aan onze database toe te voegen. Bovendien willen we dat ze andere gebruikers toestemming kunnen geven om hetzelfde te doen. Hier is de SQL-instructie:
SUBSIDIE MAAK TAFEL.
NAAR DBA.
MET SUBSIDIEOPTIE.
Merk op dat we de regel WITH GRANT OPTION hebben opgenomen om ervoor te zorgen dat onze DBA's deze toestemming aan andere gebruikers kunnen toewijzen.
Machtigingen verwijderen
SQL bevat de opdracht REVOKE om eerder verleende machtigingen te verwijderen. Hier is de syntaxis:
INTREKKEN [VERLENEN OPTIE VOOR]
AAN.
VAN.
U zult merken dat de syntaxis van deze opdracht vergelijkbaar is met die van de GRANT-opdracht. Het enige verschil is dat WITH GRANT OPTION wordt gespecificeerd op de REVOKE-opdrachtregel in plaats van aan het einde van de opdracht. Laten we ons bijvoorbeeld voorstellen dat we de eerder verleende toestemming van Mary om records uit de klantendatabase te verwijderen, willen intrekken. We zouden het volgende commando gebruiken:
HERROEP VERWIJDEREN.
ON Klanten.
VAN Maria.
Er is nog een extra mechanisme dat wordt ondersteund door Microsoft SQL Server dat het vermelden waard is: het DENY-commando. Deze opdracht kan worden gebruikt om een gebruiker expliciet toestemming te weigeren die hij anders zou hebben via een huidig of toekomstig rollidmaatschap. Hier is de syntaxis:
ONTKENNEN.
AAN.
NAAR.