Het is geen geheim dat informatie de wereld momenteel doet draaien. Als een onderneming zorg draagt voor haar intellectuele eigendom en elke werknemer gemakkelijk aan de nodige informatie kan komen, mag de onderneming hopen op groei. Als er chaos is in gegevens, zal de onderneming falen ondanks de teamgeest.
In dit artikel gaan we de basisprincipes van databasebeveiliging en voorbeelden van informatiebeveiliging in Oracle onderzoeken. De theoretische basis voor het beschermen van informatie in de database, die we in dit artikel gaan bespreken, is ook nuttig voor mensen die met andere databases werken.
Toegangsrechten
In de meeste bedrijven waarvoor ik werkte, hadden alle beheerders en ontwikkelaars volledige toegang tot databases, evenals een medewerker van de IT-afdeling was een god en kon doen wat ze wilden. Waarom gebeurt het? Hier zijn twee redenen voor:
- Terwijl ze op één afdeling werken, kunnen medewerkers elkaar elke dag 8 uur ontmoeten en vrienden worden. Hoe kunnen ze geen toegang verlenen? Vriendschap is één ding, maar zaken zijn zaken.
- Voor het verlenen van toegangsrechten of het wijzigen van een configuratie zijn mogelijk enkele privileges vereist. Soms denken beheerders dat programmeurs instellingen beter configureren. Zo geven ze programmeurs onnodige toegangsrechten. In plaats daarvan mogen programmeurs niet betrokken zijn bij de administratie en mogen ze hier geen rechten voor hebben.
In mijn ervaring is het tweede probleem heel gebruikelijk, dus we zullen het in detail analyseren.
Bij het ontwikkelen van programma's voor databases kennen programmeurs een superuser-wachtwoord of hebben ze eenvoudig databasebeheerdersrechten. Dit is onnodig en absoluut onveilig. Alleen de databasebeheerder moet volledige rechten hebben. Zelfs het hoofd van de afdeling, directeur en beste vrienden kunnen minder privileges hebben.
Bij het ontwikkelen van programma's is het bijvoorbeeld voldoende om de schema-eigenaarsrechten te hebben in de Oracle-database waarin werktabellen zijn opgeslagen. Deze rechten zijn voldoende om nieuwe tabellen, pakketten, indexen en andere objecten te maken, en om toegangsrechten tot schemaobjecten aan andere gebruikers te verlenen. Je hebt de systeemrechten niet nodig voor fulltime werk.
Als er geen databasebeheerder op fulltime basis is, is het erg slecht. Het is beter als er iemand is die verantwoordelijk is voor databaseprestaties, optimalisatie en beveiliging. U moet in ieder geval één programmeur aanstellen die hiervoor verantwoordelijk is en de exclusieve rechten heeft.
Volgens statistieken veroorzaken werknemers van het bedrijf het vaakst gegevensverlies. Ondanks dit feit blijven de meeste bedrijven deze thread negeren en worden verschillende databases die op schijven zijn opgeslagen met gratis toegang zelfs in de metro verkocht.
Gebruikers en rollen
Er zijn twee objecttypen om toegangsrechten in databases te verlenen:gebruikers en rollen. Rollen zijn enkele groepen die gebruikers combineren die vergelijkbare rechten moeten hebben. Zo kunnen alle accountants toegang nodig hebben tot financiële documenten. Om te voorkomen dat je elke accountant rechten geeft, kunnen we deze combineren tot een rol met de benodigde toegang.
Zoals u kunt zien, is het principe van rollen vergelijkbaar met groepen in het Windows-besturingssysteem. Toch heeft het enkele verschillen. Niet voor niets kunnen alle drie objecttypen zoals gebruikers, groepen en rollen in de database worden geïmplementeerd. In de meeste databases worden echter alleen gebruikers en rollen geïmplementeerd. Het is noodzakelijk om al deze objecten te beheren en te bewaken, zodat elke gebruiker die de rechten verkrijgt die door de rollen worden verleend, toegang kan hebben tot de gegevens die daadwerkelijk nodig zijn om taken op te lossen. Het is noodzakelijk om toegangsrechten te gebruiken als regels voor een firewall. Met deze rechten kunt u hetzelfde probleem oplossen:een gebruiker toestaan om alleen bepaalde taken uit te voeren en mogelijk verlies of corruptie te voorkomen.
Met behulp van rollen is het heel handig om de toegang te regelen, machtigingen te verlenen of de hele groep gebruikers te blokkeren. De ene rol kan worden opgenomen in de andere, waardoor de toegangsrechten worden geërfd. Daarom kunnen we een hiërarchische structuur van rechten creëren.
Alle medewerkers met toegangsrechten tot een bedrijfsdatabase kunnen met de minimale rechten in één rol worden opgenomen. Als u nu extra privileges of toegang tot bepaalde tabellen nodig heeft, moet u een gebruiker aan andere rollen toevoegen (als een groep dezelfde toegang nodig heeft) of een bepaald account de rechten geven.
Om de toegang tot de tabellen te controleren, is het in het programma mogelijk om het resultaat te controleren op fouten na elke poging om de dataset te openen. Als er een toegangsfout optreedt, wordt de toegang tot de opgegeven tabel voor een gebruiker geblokkeerd. Het is dus niet nodig om de toegangsrechten tot de clienttoepassing te implementeren. Als u dit echter wilt implementeren, kan dit geen kwaad. Ik zie hier tenminste niets kritisch in; het lijkt het tegenovergestelde effect te hebben.
Beveiligingsaudit
Als elke gebruiker onder zijn eigen account in uw database werkt, kunt u de gebruikersvariabele aanroepen om de huidige gebruiker te bepalen, bijvoorbeeld:
SELECT user from dual
Deze query retourneert een gebruikersnaam, waaronder de verbinding met de server wordt geopend. Als meerdere mensen met één naam kunnen inloggen, zal deze zoekopdracht voor beide dezelfde naam opleveren en zou het nutteloos zijn voor de audit. Vooral als vergrendelingscontrole plaatsvindt op serverniveau.
Als meerdere gebruikers kunnen inloggen met dezelfde gebruikersnaam, is het ingewikkeld, maar nog steeds mogelijk, om te identificeren wie zich heeft aangemeld bij het account. Met de volgende zoekopdracht krijgt u gedetailleerde informatie over de sessie:
select s.user#, s.username, s.osuser, s.terminal, s.program from sys.v_$session s WHERE username=user
Zoals u kunt zien, heeft de query de gebruikersnaam geretourneerd, verbonden met de database, een naam in het besturingssysteem, een terminal-gebruikersnaam en een programma.
Hier hebt u toegang tot de v_$session-weergave vanuit het sys-systeemschema. Deze weergave retourneert wat informatie over de verbindingen met de server. In de WHERE-component beperken we de uitvoer tot alleen de huidige gebruiker. Als resultaat retourneert de query de gebruikers-ID, naam, naam in het besturingssysteem, de terminal en het programma van waaruit de verbinding tot stand is gebracht.
Als u een gebruikersnaam en een terminalnaam kent, kunt u zeker een gebruiker identificeren. Om te weten aan welke rollen de huidige gebruiker is toegevoegd, kunt u de volgende query uitvoeren:
SELECT GRANTED_ROLE FROM dba_role_privs WHERE grantee=user
Accountbeveiliging
We zullen niet zeggen dat er geen standaardwachtwoorden zouden moeten zijn. Sommige databases, bijvoorbeeld MySQL, doen het verkeerd wanneer ze na de installatie een eenvoudig en bekend systeemwachtwoord maken. We zullen ook niet zeggen dat het wachtwoord ingewikkeld moet zijn. Deze regel is van toepassing op alle IT-gebieden en zou zelfs een beginnende gebruiker moeten kennen. We gaan het hebben over databaseproblemen.
In mijn ervaring gebruiken ontwikkelaars bij het ontwikkelen van bedrijfsprogramma's hetzelfde account om toegang te krijgen tot een database. De parameters van dit account worden rechtstreeks in het programma geregistreerd, terwijl de toegang tot bepaalde modules, waaronder boekhouding, magazijn, personeelsafdeling, enz. op een programmatische manier wordt geïmplementeerd. Aan de ene kant is deze methode handig, omdat het programma met beheerdersrechten verbinding kan maken met de database en niet hoeft te zorgen voor de rollen en toegangsrechten tot de tabellen. Aan de andere kant is deze methode verre van veilig. Het gebruikersniveau stijgt en vrienden van de medewerkers van uw bedrijf kunnen opgeleid worden op het gebied van security en hacking. Na het kennen van de naam en het wachtwoord, waaronder het programma verbinding maakt met de database, kan een gewone gebruiker meer kansen krijgen dan je wilde.
De SQL-taal is geen geheime en gecompliceerde taal. Er zijn veel programma's waarmee u eenvoudig alle gegevens in de database kunt bekijken. Met de gebruikersnaam en het wachtwoord kan iedereen al uw gegevens stelen. Het zal dus worden verkocht in elke kraam die schijven verkoopt.
Een gebruikersnaam en wachtwoord mogen nooit in het programma worden opgeslagen. Ook moet de toegang tot het programma beperkt en onmogelijk zijn voor derden. Het is vrij logisch om beide logins te combineren tot één. Het is noodzakelijk om een apart account aan te maken op de databaseserver met de minimaal benodigde rechten voor elke gebruiker in de organisatie. Deze namen en wachtwoorden moeten worden gebruikt bij het inloggen op het programma. U kunt een gemeenschappelijke en zeer effectieve logica gebruiken - als u zich kunt aanmelden bij de database met de ingevoerde gegevens, is de toegang toegestaan; zo niet, dan moet u het programma afbreken. Dit proces is eenvoudig en effectief omdat we databaseautorisatie hebben gebruikt.
Om te controleren of gebruikers niet tegelijkertijd werken vanaf twee verschillende computers onder dezelfde naam, kunt u de volgende query uitvoeren:
select s.username, s.terminal, count(*) from sys.v_$session s WHERE username=user HAVING count(*)>1 GROUP BY s.username, s.terminal
In feite mag het geen record teruggeven.
Beelden
Views zijn een erg handige manier om de datastructuur uit te schakelen en tegelijkertijd een extra beschermingsniveau op te bouwen. Weliswaar hebben views een negatief effect op de productiviteit, maar ze hebben een positief effect op de veiligheid. We kunnen hun eigen toegangsrechten verlenen, terwijl de tabellen waaruit de gegevens worden opgehaald voor dit account ontoegankelijk kunnen blijven.
Wanneer is het beter om views te gebruiken? Laten we eerst definiëren wat hun nadelen zijn. Een view is een SELECT-instructie om gegevens op te halen. Het heeft toegang tot zowel één als meerdere tabellen. Als u alleen de gegevens uit de weergave selecteert, is er geen prestatieverlies. We kunnen echter views in andere query's gebruiken om gegevens te selecteren en ernaar te verwijzen als naar de tabellen. Bijvoorbeeld:
SELECT list of fields FROM view, table_1, table_2 WHERE some parameters
In dit geval haalt de query gegevens op uit de view en twee tabellen. Daarnaast kunnen we een relatie tussen alle objecten bekijken en kan er een extra voorwaarde worden ingesteld.
Laten we nu eens kijken naar de query zoals de database-optimizer deze ziet:
SELECT list of fields FROM (SELECT ...), table1, table2 WHERE some parameters
In dit geval heb ik de weergave vervangen door een abstracte SELECT-instructie tussen haakjes waaruit de weergave bestaat. Het blijkt dat de server een query ziet met een subquery. Als de subquery dynamische gegevens retourneert in plaats van een statische waarde, zal deze gegevensselectie langzamer werken dan wanneer we dezelfde query zonder de subquery zouden schrijven.
Gegevensbeveiliging
U mag nooit volledige toegang verlenen tot objecten zonder een speciale behoefte. Ik begin altijd alleen rechten te verlenen om de gegevensselectie met de SELECT-instructie toe te staan. Als de gebruiker echt nieuwe records moet invoegen en hij kan de taken die aan hem zijn toegewezen niet uitvoeren, voeg dan de machtiging toe aan de INSERT-instructie van de opgegeven tabel.
De gevaarlijkste bewerkingen voor de gegevens zijn wijziging en verwijdering, namelijk respectievelijk UPDATE en DELETE. U dient deze rechten zorgvuldig toe te kennen. Zorg ervoor dat de gegevens kunnen worden gewijzigd of verwijderd. Selecteer alleen in dit geval de juiste rechten. Sommige tabellen zijn alleen van nature uitgebreid.
Het is noodzakelijk om er zeker van te zijn dat de gegevens vaak worden beïnvloed. Zo kan de tabel met werknemers worden uitgebreid en gewijzigd, maar mag nooit een enkel record worden verwijderd. De verwijdering kan van invloed zijn op de achtergrond van het werk, de rapportage en de gegevensintegriteit van werknemers. Het geval dat een personeelsfunctionaris per ongeluk een extra record toevoegt en deze wil verwijderen, is nog steeds mogelijk. Dergelijke gevallen zijn echter zeldzaam en de fout kan worden verholpen door de databasebeheerder. We begrijpen dat niemand te veel wil werken en het is gemakkelijker om toestemming te verlenen, maar beveiliging is waardevoller.
Het verlenen van rechten wordt uitgevoerd met behulp van de GRANT-operator. Over het algemeen ziet het er als volgt uit:
VERLENEN wat rechten te geven aan ON objecten AAN gebruikers of rollen
De volgende query geeft bijvoorbeeld het recht om de TestTable-tabel in te voegen en te bekijken aan Gebruiker1:
GRANT Select, Insert ON TestTable TO User1
Buitenlandse sleutels
Veel gebruikers zijn bang voor externe sleutels omdat ze meestal niet toestaan dat gegevens worden verwijderd wanneer er een outer join is. Het probleem kan eenvoudig worden opgelost als een cascade-verwijdering wordt vastgesteld. De meeste specialisten houden echter niet van deze mogelijkheid. Eén belachelijke actie kan zeer belangrijke gegevens beschadigen zonder bevestigingsverzoeken. Gelinkte gegevens moeten expliciet worden verwijderd, en alleen als de gebruiker bewust heeft bevestigd dat de gegevens kunnen worden verwijderd.
Wees niet bang voor buitenlandse sleutels. Ze bieden ons een handige manier om de gegevensintegriteit vanaf de databaseserver te controleren, dus dit is beveiliging die nooit kwaad kan. Het feit dat er mogelijk problemen zijn met de verwijdering is slechts een voordeel. Het is beter om de gegevens niet te verwijderen in plaats van ze voor altijd te verliezen. De externe sleutel samen met de index vermindert de prestaties niet. Dit is slechts een kleine controle bij het verwijderen van de gegevens of het wijzigen van het sleutelveld waaraan de gegevens zijn gekoppeld in verschillende tabellen.
Back-up
Back-up is ook een van de beveiligingsfactoren die we negeren vóór het eerste gegevensverlies. Persoonlijk zou ik het echter in de belangrijkste hebben opgenomen. Het gegevensverlies kan niet alleen worden veroorzaakt door hackers en onbekwame gebruikers, maar ook door storingen in de apparatuur. Storingen in de apparatuur kunnen leiden tot databaseverlies, waarvan het herstel uren of zelfs dagen kan duren.
Het is noodzakelijk om vooraf het meest effectieve back-upbeleid te ontwikkelen. Wat wordt daarmee bedoeld? Downtime veroorzaakt door gegevensverlies en tot het moment van herstel van de werkcapaciteit moet minimaal zijn. Het gegevensverlies moet ook minimaal zijn en de back-up mag het werk van de gebruiker niet beïnvloeden. Als er geld en kansen zijn, is het beter om systemen als RAID, cluster of zelfs datareplicatie te gebruiken.
Back-up en herstel zijn een apart en interessant onderwerp. We kunnen er hier niet op ingaan, maar we zullen er niet in detail op ingaan.
Samenvatting
We hebben de basisprincipes van beveiliging overwogen, met name voor Oracle. Vergeet niet dat de bescherming die door de database wordt geboden slechts op één niveau is, terwijl de bescherming op meerdere niveaus moet zijn. Om met een gerust hart een beetje te slapen, is het noodzakelijk om alle beveiligingsfuncties op het netwerk, servers en alle computers te implementeren, inclusief antivirussen, antispyware, VPN, IDS, enz. Hoe meer beschermingsniveaus er zijn, hoe meer het zal moeilijk zijn om ze te overwinnen.
Er moet een duidelijk veiligheidsbeleid en controle zijn. Als een medewerker vertrekt, wordt zijn account verwijderd. Als u gebruikers hebt die met hetzelfde wachtwoord werken of een groepswachtwoord gebruiken om taken uit te voeren, moeten al deze wachtwoorden worden gewijzigd. Als een beheerder bijvoorbeeld vertrekt en alle beheerders dezelfde account gebruiken, moet u het wachtwoord wijzigen.
De beveiliging is nodig. U moet uzelf niet alleen beschermen tegen hackers, maar ook tegen "beginnende" gebruikers, die door hun onervarenheid gegevens kunnen beschadigen. Een goed beveiligingsbeleid helpt dergelijke gevallen te voorkomen en deze mogelijkheid kan niet worden uitgesloten. Het is beter om vooraf de mogelijkheid te bieden om gegevens tegen onervarenheid te beveiligen dan veel tijd te verliezen om gegevens te herstellen en onnodige downtime te krijgen.
Lees ook:
Toegangsrechten voor databases instellen