Es ist kein Geheimnis, dass Informationen derzeit die Welt bewegen. Wenn ein Unternehmen auf sein geistiges Eigentum achtet und jeder Mitarbeiter leicht an die notwendigen Informationen kommt, kann das Unternehmen auf Wachstum hoffen. Wenn Datenchaos herrscht, scheitert das Unternehmen trotz Teamgeist.
In diesem Artikel werden wir die Grundlagen der Datenbanksicherheit und Beispiele für den Informationsschutz in Oracle untersuchen. Tatsächlich werden die theoretischen Grundlagen zum Schutz von Informationen in der Datenbank, die wir in diesem Artikel betrachten werden, auch für Personen nützlich sein, die mit anderen Datenbanken arbeiten.
Zugriffsberechtigungen
In den meisten Unternehmen, für die ich gearbeitet habe, hatten alle Administratoren und Entwickler vollen Zugriff auf Datenbanken, und ein Mitarbeiter der IT-Abteilung war ein Gott und konnte alles tun, was er wollte. Warum passiert das? Dafür gibt es zwei Gründe:
- Während der Arbeit in einer Abteilung können sich Mitarbeiter jeden Tag 8 Stunden lang treffen und Freunde werden. Wie können sie keinen Zugriff gewähren? Freundschaft ist eine Sache, aber Geschäft ist Geschäft.
- Das Gewähren einiger Zugriffsrechte oder das Ändern einiger Konfigurationen kann einige Privilegien erfordern. Manchmal denken Administratoren, dass Programmierer die Einstellungen besser konfigurieren. Somit verschaffen sie Programmierern unnötige Zugriffsrechte. Stattdessen dürfen Programmierer nicht an der Administration beteiligt sein und keine Rechte dafür haben.
Meiner Erfahrung nach ist das zweite Problem sehr häufig, daher werden wir es im Detail analysieren.
Bei der Entwicklung von Programmen für Datenbanken kennen Programmierer ein Superuser-Passwort oder haben einfach Datenbankadministratorrechte. Das ist unnötig und absolut unsicher. Nur der Datenbankadministrator muss volle Rechte haben. Sogar der Abteilungsleiter, der Direktor und die besten Freunde können weniger Privilegien haben.
Bei der Entwicklung von Programmen reicht es beispielsweise aus, die Schemabesitzerrechte in der Oracle-Datenbank zu haben, in der Arbeitstabellen gespeichert sind. Diese Rechte reichen aus, um neue Tabellen, Pakete, Indizes und andere Objekte zu erstellen sowie anderen Benutzern Zugriffsrechte auf Schemaobjekte zu erteilen. Für eine Vollzeitbeschäftigung benötigen Sie die Systemrechte nicht.
Wenn es keinen Datenbankadministrator auf Vollzeitbasis gibt, ist es sehr schlecht. Es ist besser, wenn es jemanden gibt, der für die Leistung, Optimierung und Sicherheit der Datenbank verantwortlich ist. Zumindest müssen Sie einen Programmierer ernennen, der dafür verantwortlich ist und über exklusive Rechte verfügt.
Laut Statistik verursachen Mitarbeiter des Unternehmens am häufigsten Datenverluste. Trotz dieser Tatsache ignorieren die meisten Unternehmen diesen Thread und verschiedene Datenbanken, die kostenlos auf Festplatten gespeichert sind, werden sogar in der U-Bahn verkauft.
Benutzer und Rollen
Es gibt zwei Objekttypen, um Zugriffsrechte in Datenbanken zu vergeben:Benutzer und Rollen. Rollen sind einige Gruppen, die Benutzer kombinieren, die ähnliche Rechte haben müssen. Beispielsweise können alle Buchhalter Zugriff auf Finanzdokumente verlangen. Um zu verhindern, dass Sie jedem Buchhalter Rechte einräumen, können wir diese zu einer Rolle mit den erforderlichen Zugriffsrechten zusammenfassen.
Wie Sie sehen können, ähnelt das Prinzip der Rollen dem von Gruppen im Windows-Betriebssystem. Dennoch weist es einige Unterschiede auf. Nicht ohne Grund können alle drei Objekttypen wie Benutzer, Gruppen und Rollen in der Datenbank implementiert werden. In den meisten Datenbanken sind jedoch nur Benutzer und Rollen implementiert. All diese Objekte müssen verwaltet und überwacht werden, damit jeder Benutzer, der die durch die Rollen gewährten Rechte erhält, Zugriff auf die Daten hat, die tatsächlich zur Lösung von Aufgaben benötigt werden. Es ist notwendig, Zugriffsrechte als Regeln für eine Firewall zu verwenden. Mit diesen Rechten können Sie dasselbe Problem lösen – einem Benutzer erlauben, nur bestimmte Aufgaben auszuführen und möglichen Verlust oder Beschädigung zu verhindern.
Mit Hilfe von Rollen ist es ganz bequem, den Zugriff zu kontrollieren, Berechtigungen zu erteilen oder die ganze Gruppe von Benutzern zu sperren. Eine Rolle kann in die andere eingebunden werden und so deren Zugriffsrechte erben. Daher können wir eine hierarchische Rechtestruktur erstellen.
Alle Mitarbeiter mit Zugriffsrechten auf eine Unternehmensdatenbank können mit den Mindestrechten in eine einzige Rolle aufgenommen werden. Wenn Sie jetzt zusätzliche Berechtigungen oder Zugriff auf bestimmte Tabellen benötigen, müssen Sie einen Benutzer zu anderen Rollen hinzufügen (wenn eine Gruppe denselben Zugriff benötigt) oder einem bestimmten Konto die Rechte zuweisen.
Um den Zugriff auf die Tabellen zu kontrollieren, ist es im Programm möglich, nach jedem Versuch, den Datensatz zu öffnen, das Ergebnis auf Fehler zu prüfen. Tritt ein Zugriffsfehler auf, wird der Zugriff auf die angegebene Tabelle für einen Benutzer gesperrt. Somit müssen die Zugriffsrechte auf die Client-Anwendung nicht implementiert werden. Wenn Sie dies jedoch implementieren möchten, wird kein Schaden entstehen. Zumindest sehe ich darin nichts Kritisches; es scheint den gegenteiligen Effekt zu haben.
Sicherheitsaudit
Wenn jeder Benutzer unter seinem eigenen Konto in Ihrer Datenbank arbeitet, können Sie die Variable user aufrufen, um den aktuellen Benutzer zu ermitteln, zum Beispiel:
SELECT user from dual
Diese Abfrage gibt einen Benutzernamen zurück, unter dem die Verbindung zum Server geöffnet wird. Wenn sich mehrere Personen mit einem Namen anmelden können, gibt diese Abfrage für beide denselben Namen zurück und wäre für die Prüfung nutzlos. Insbesondere, wenn die Sperrsteuerung auf Serverebene erfolgt.
Wenn sich mehrere Benutzer mit demselben Benutzernamen anmelden können, ist es kompliziert, aber dennoch möglich, zu identifizieren, wer sich bei dem Konto angemeldet hat. Die folgende Abfrage ermöglicht das Abrufen detaillierter Informationen zur Sitzung:
select s.user#, s.username, s.osuser, s.terminal, s.program from sys.v_$session s WHERE username=user
Wie Sie sehen können, hat die Abfrage den Benutzernamen zurückgegeben, der mit der Datenbank verbunden ist, einen Namen im Betriebssystem, einen Terminal-Benutzernamen und ein Programm.
Hier können Sie vom sys-Systemschema aus auf die v_$session-Ansicht zugreifen. Diese Ansicht gibt einige Informationen über die Verbindungen zum Server zurück. In der WHERE-Klausel beschränken wir die Ausgabe nur auf den aktuellen Benutzer. Als Ergebnis liefert die Abfrage die Benutzerkennung, den Namen, den Namen im Betriebssystem, das Endgerät und das Programm, von dem aus die Verbindung aufgebaut wurde.
Wenn Sie einen Benutzernamen und einen Terminalnamen kennen, können Sie einen Benutzer sicher identifizieren. Um zu erfahren, welchen Rollen der aktuelle Benutzer hinzugefügt wurde, können Sie die folgende Abfrage ausführen:
SELECT GRANTED_ROLE FROM dba_role_privs WHERE grantee=user
Kontosicherheit
Wir werden nicht sagen, dass es keine Standardpasswörter geben sollte. Einige Datenbanken, zum Beispiel MySQL, machen einen Fehler, wenn sie nach der Installation ein einfaches und bekanntes Systempasswort erstellen. Wir werden auch nicht sagen, dass das Passwort kompliziert sein sollte. Diese Regel gilt für alle IT-Bereiche und sollte auch einem unerfahrenen Benutzer bekannt sein. Wir werden über Datenbankprobleme sprechen.
Meiner Erfahrung nach verwenden Entwickler bei der Entwicklung von Unternehmensprogrammen dasselbe Konto, um auf eine Datenbank zuzugreifen. Die Parameter dieses Kontos werden direkt im Programm registriert, während der Zugriff auf bestimmte Module, einschließlich Buchhaltung, Lager, Personalabteilung usw., programmgesteuert implementiert wird. Einerseits ist diese Methode praktisch, da sich das Programm mit Administratorrechten mit der Datenbank verbinden kann und sich nicht um die Rollen und Zugriffsrechte auf die Tabellen kümmern muss. Andererseits ist diese Methode alles andere als sicher. Die Anzahl der Benutzer wächst und Freunde der Mitarbeiter Ihres Unternehmens können im Bereich Sicherheit und Hacking geschult werden. Nachdem Sie den Namen und das Passwort kennen, unter denen sich das Programm mit der Datenbank verbindet, kann ein normaler Benutzer mehr Möglichkeiten erhalten, als Sie wollten.
Die SQL-Sprache ist keine geheime und komplizierte Sprache. Es gibt viele Programme, mit denen Sie alle Daten in der Datenbank einfach anzeigen können. Mit dem Benutzernamen und dem Passwort kann jeder alle Ihre Daten stehlen. Daher wird es an jedem Stand verkauft, der Disketten verkauft.
Ein Benutzername und ein Passwort dürfen niemals im Programm gespeichert werden. Der Zugriff auf das Programm muss auch für Dritte beschränkt und unmöglich sein. Es ist durchaus logisch, beide Logins zu einem zusammenzufassen. Es ist notwendig, für jeden Benutzer in der Organisation ein separates Konto auf dem Datenbankserver mit den erforderlichen Mindestrechten zu erstellen. Diese Namen und Passwörter sollten beim Einloggen in das Programm verwendet werden. Sie können eine gemeinsame und sehr effektive Logik verwenden – wenn Sie sich mit den eingegebenen Daten bei der Datenbank anmelden können, wird der Zugriff erlaubt; wenn nicht, müssen Sie das Programm abbrechen. Dieser Prozess ist einfach und effektiv, da wir die Datenbankautorisierung verwendet haben.
Um zu überprüfen, ob Benutzer nicht gleichzeitig von zwei verschiedenen Computern unter demselben Namen arbeiten, können Sie die folgende Abfrage ausführen:
select s.username, s.terminal, count(*) from sys.v_$session s WHERE username=user HAVING count(*)>1 GROUP BY s.username, s.terminal
Tatsächlich darf es keinen Datensatz zurückgeben.
Aufrufe
Views sind eine sehr komfortable Möglichkeit, von der Datenstruktur abzuschalten und gleichzeitig eine zusätzliche Schutzebene aufzubauen. Views wirken sich zwar negativ auf die Produktivität, aber positiv auf die Sicherheit aus. Wir können eigene Zugriffsrechte vergeben, während die Tabellen, aus denen die Daten abgerufen werden, für dieses Konto unzugänglich bleiben können.
Wann ist es besser, Ansichten zu verwenden? Lassen Sie uns zunächst ihre Nachteile definieren. Eine Ansicht ist eine SELECT-Anweisung zum Abrufen von Daten. Es kann sowohl auf eine als auch auf mehrere Tabellen zugegriffen werden. Wenn Sie nur die Daten aus der Ansicht auswählen, gibt es keinen Leistungsverlust. Wir können jedoch Ansichten in anderen Abfragen verwenden, um Daten auszuwählen und auf sie wie auf die Tabellen zu verweisen. Zum Beispiel:
SELECT list of fields FROM view, table_1, table_2 WHERE some parameters
In diesem Fall ruft die Abfrage Daten aus der Ansicht und zwei Tabellen ab. Außerdem können wir eine Beziehung zwischen allen Objekten anzeigen und eine zusätzliche Bedingung festlegen.
Sehen wir uns nun die Abfrage aus der Sicht des Datenbankoptimierers an:
SELECT list of fields FROM (SELECT ...), table1, table2 WHERE some parameters
In diesem Fall habe ich die Ansicht durch eine abstrakte SELECT-Anweisung in Klammern ersetzt, aus der die Ansicht besteht. Es stellt sich heraus, dass der Server eine Abfrage mit einer Unterabfrage sieht. Wenn die Unterabfrage dynamische Daten anstelle eines statischen Werts zurückgibt, funktioniert diese Datenauswahl langsamer, als wenn wir dieselbe Abfrage ohne die Unterabfrage schreiben würden.
Datensicherheit
Sie sollten niemals ohne besonderen Bedarf vollen Zugriff auf Objekte gewähren. Ich fange immer an, Rechte nur zu vergeben, um die Datenauswahl mit der SELECT-Anweisung zuzulassen. Wenn der Benutzer wirklich neue Datensätze einfügen muss und die ihm zugewiesenen Aufgaben nicht ausführen kann, fügen Sie in diesem Fall die Berechtigung für die INSERT-Anweisung der angegebenen Tabelle hinzu.
Die gefährlichsten Operationen für die Daten sind das Ändern und Löschen, nämlich UPDATE bzw. DELETE. Sie müssen diese Rechte sorgfältig erteilen. Stellen Sie sicher, dass die Daten geändert oder gelöscht werden können. Wählen Sie nur in diesem Fall die entsprechenden Rechte aus. Einige Tabellen werden nur von Natur aus erweitert.
Es muss sichergestellt sein, dass die Daten häufig betroffen sind. Beispielsweise kann die Tabelle der Mitarbeiter erweitert und geändert werden, aber ein einzelner Datensatz sollte niemals gelöscht werden. Die Entfernung kann den Hintergrund der Arbeit der Mitarbeiter, die Berichterstattung und die Datenintegrität beeinflussen. Der Fall, dass ein Personalverantwortlicher versehentlich einen zusätzlichen Datensatz hinzufügt und ihn löschen möchte, ist immer noch möglich. Solche Fälle sind jedoch selten und der Fehler kann vom Datenbankadministrator behoben werden. Wir verstehen, dass niemand sich überarbeiten möchte und es einfacher ist, eine Genehmigung zu erteilen, aber Sicherheit ist wertvoller.
Die Rechtevergabe erfolgt mit dem GRANT-Operator. Im Allgemeinen sieht es so aus:
GRANT, um ON-Objekten Benutzern oder Rollen Rechte zu geben
Beispielsweise gewährt die folgende Abfrage Benutzer1 das Recht zum Einfügen und Anzeigen der TestTable-Tabelle:
GRANT Select, Insert ON TestTable TO User1
Fremdschlüssel
Viele Benutzer haben Angst vor Fremdschlüsseln, da sie normalerweise das Löschen von Daten nicht zulassen, wenn ein äußerer Join vorhanden ist. Das Problem lässt sich leicht lösen, wenn eine Kaskadenlöschung eingerichtet wird. Die meisten Spezialisten mögen diese Möglichkeit jedoch nicht. Eine lächerliche Aktion kann sehr wichtige Daten ohne Bestätigungsanforderungen beschädigen. Verlinkte Daten müssen explizit gelöscht werden und nur dann, wenn der Nutzer bewusst bestätigt hat, dass die Daten gelöscht werden können.
Keine Angst vor Fremdschlüsseln. Sie bieten uns eine bequeme Möglichkeit, die Datenintegrität vom Datenbankserver aus zu kontrollieren, also ist dies Sicherheit, die nie schadet. Dass es beim Löschen zu Problemen kommen kann, ist nur ein Vorteil. Es ist besser, die Daten nicht zu löschen, als sie für immer zu verlieren. Der Fremdschlüssel zusammen mit dem Index verringert die Leistung nicht. Dies ist nur eine kleine Überprüfung, wenn Sie die Daten löschen oder das Schlüsselfeld ändern, mit dem die Daten in verschiedenen Tabellen verbunden sind.
Sicherung
Backup ist auch einer der Sicherheitsfaktoren, die wir vor dem ersten Datenverlust ignorieren. Ich persönlich hätte es jedoch in die wichtigsten aufgenommen. Der Datenverlust kann nicht nur durch Hacker und unfähige Benutzer, sondern auch durch Gerätestörungen verursacht werden. Fehler in der Ausrüstung können zu Datenbankverlusten führen, deren Wiederherstellung Stunden oder sogar Tage dauern kann.
Es ist notwendig, im Voraus die effektivste Sicherungsrichtlinie zu entwickeln. Was ist damit gemeint? Die durch Datenverlust verursachte Ausfallzeit bis zum Zeitpunkt der Wiederherstellung der Arbeitsfähigkeit sollte minimal sein. Der Datenverlust sollte ebenfalls minimal sein und die Sicherung sollte die Arbeit des Benutzers nicht beeinträchtigen. Wenn es Geld und Möglichkeiten gibt, ist es besser, Systeme wie RAID, Cluster oder sogar Datenreplikation zu verwenden.
Sicherung und Wiederherstellung sind ein separates und interessantes Thema. Wir konnten es hier nicht ansprechen, aber wir werden es nicht im Detail betrachten.
Zusammenfassung
Wir haben Sicherheitsgrundlagen berücksichtigt, insbesondere für Oracle. Vergessen Sie nicht, dass der von der Datenbank bereitgestellte Schutz nur einstufig ist, während der Schutz mehrstufig sein muss. Um ein bisschen mit klarem Verstand zu schlafen, ist es notwendig, die gesamten Sicherheitsfunktionen auf dem Netzwerk, den Servern und allen Computern zu implementieren, einschließlich Virenschutz, Anti-Spyware, VPN, IDS usw. Je mehr Schutzebenen es gibt, desto mehr schwierig wird es sein, sie zu überwinden.
Es sollte eine klare Sicherheitsrichtlinie und -kontrolle geben. Wenn ein Mitarbeiter ausscheidet, wird sein Konto gelöscht. Wenn Sie Benutzer haben, die mit demselben Passwort arbeiten oder ein Gruppenpasswort verwenden, um Aufgaben auszuführen, müssen alle diese Passwörter geändert werden. Wenn beispielsweise ein Administrator ausscheidet und alle Administratoren dasselbe Konto verwenden, müssen Sie das Kennwort ändern.
Die Sicherheit ist notwendig. Sie müssen sich nicht nur vor Hackern schützen, sondern auch vor „neuen“ Benutzern, die aufgrund ihrer Unerfahrenheit Daten beschädigen können. Eine gute Sicherheitsrichtlinie hilft, solche Fälle zu verhindern, und diese Möglichkeit kann nicht ausgeschlossen werden. Es ist besser, die Möglichkeit bereitzustellen, Daten im Voraus vor Unerfahrenheit zu schützen, als viel Zeit für die Wiederherstellung von Daten zu verlieren und unnötige Ausfallzeiten zu bekommen.
Lesen Sie auch:
Festlegen von Datenbankzugriffsberechtigungen
