Sicherheit für Anwendungsentwickler, die PL / SQL ausführen, arbeiten in Oracle


13

Wie gehen Sie mit dem Mangel an Berechtigungen auf Schemaebene in Oracle um? Die Sicherheitsarchitektur von Oracle eignet sich gut für Anwendungen, die nur Berechtigungen auf Objektebene benötigen, und für Datenbankadministratoren, die nur wenige Einschränkungen benötigen. Es scheint jedoch eine große Lücke in der Architektur zu geben, wenn Programmierer mit einer Front-End-Anwendung und PL / SQL in mehreren Schemata entwickeln. Hier sind einige meiner Optionen mit ihren Nachteilen:

  1. Lassen Sie jeden Programmierer in seinem eigenen Schema entwickeln. Der DBA gewährt Programmierern, die sie benötigen, Berechtigungen auf Objektebene. Jede Paketentwicklung muss von einem DBA durchgeführt werden. Der größte Nachteil ist, dass Programmierer die Datenbank wie einen kleinen Eimer zum Nachteil der Datenbankleistung verwenden. Ich möchte, dass sich die Programmierer in der Datenbank entwickeln, aber diese Methode würde sie stark entmutigen.

  2. Geben Sie jedem Programmierer den Benutzernamen / das Kennwort für das etwa ein Dutzend Schemas, in dem er die Entwicklung durchführen muss. Erteilen Sie diesen Anwendungsschemas die Berechtigung zum Erstellen von Prozeduren, Tabellen usw. Einige der Nachteile dieses Ansatzes bestehen darin, dass Programmierer mehrere Anmeldungen verwalten müssen und müssen Selten als sie selbst eingeloggt. Die Entwicklung von Cross-Schemas ist ebenfalls schwierig.

  3. Gewähren Sie den Programmierern Proxy-Authentifizierungsrechte für jedes Schema, für das sie die Entwicklung durchführen müssen. Dadurch bleiben sie als sie selbst angemeldet, ohne ihnen andere Berechtigungen als das Proxy-Privileg erteilen zu müssen. Zu den Nachteilen gehören, dass Programmierer für jedes Schema, für das sie einen Proxy einrichten, separate Verbindungen pflegen müssen, dass die Entwicklung von Cross-Schemas umständlicher ist, da die Verbindungen ständig geändert werden müssen und Pakete, die öffentliche Datenbankverknüpfungen mit übergebener Authentifizierung verwenden, nicht innerhalb von Proxy-Verbindungen kompiliert werden können.

  4. Gewähren Sie jedem Programmierer DBA-Berechtigungen. - Der Nachteil hier ist die Sicherheit. Kein Schema-Programmierer kann von einem Schema ferngehalten werden, und jeder Programmierer kann sich als ein anderer Programmierer (DBA) ausgeben.

Es scheint eine fehlende Option zu geben, um jedem Programmierer SELECT / INSERT / CREATE / etc. Zu gewähren. Berechtigungen für das Schema, in dem sie die Entwicklung durchführen müssen. Sie melden sich als sie selbst an, um ihre Arbeit über eine einzige Verbindung zu erledigen. Neue Objekte im Schema, auf die sie Zugriff haben, sind sofort verfügbar.

Vermisse ich etwas? Wie gehen Sie mit Anwendungsprogrammierern um, die PL / SQL entwickeln?


3
+1 große Frage - dies ist zusammen mit dem Mangel an integrierter Quellcodeverwaltung ein großes Problem bei Oracle in einer Umgebung mit mehreren Entwicklern.
ScottCher

Antworten:


11

In den Tagen, als ich in einem Oracle-Shop arbeitete, hatten wir einen bestimmten Entwicklungsserver, der andere Sicherheitsbeschränkungen hatte als der Produktionsserver. Entwickler konnten alles tun, was sie brauchten, und dann gaben wir die erforderlichen Skripte an den DBA weiter, um sie auf den Produktionsserver anzuwenden.

Bei unseren kritischen Systemen (SCT Banner für die Nachverfolgung von Klassen und Schülern und Oracle Financials) gab es auch Test- und Seed-Server. Der Test diente zum Testen der Benutzerakzeptanz, bevor die Daten von dev auf prod migriert wurden. 'seed' war die Standardinstallation der Software. Sollten wir also einen Fehler finden, können wir überprüfen, ob es sich um etwas handelt, das wir eingeführt haben oder das von SCT oder der Oracle-Software stammt.


+1 Mit unserer Datenbank zur allgemeinen Verwendung arbeiten Entwickler an sehr unterschiedlichen Projekten, sodass sie aufgrund des Prinzips der geringsten Berechtigungen nicht einmal vollständig auf den Entwicklungsserver zugreifen können. ( en.wikipedia.org/wiki/Principle_of_least_privilege )
Leigh Riffel

@Leigh - Ich hätte es wahrscheinlich klären sollen ... der Entwickler-Server fiel größtenteils unter das, was Sie als Nummer 1 hatten, nicht unter Nummer 4
Joe

1
Ich erinnere mich, dass DEV-Datenbanken aus der Produktion geklont wurden und dann komplizierte Zuschüsse gewährt wurden, damit Entwickler ohne Einschränkungen arbeiten können. Am Ende war es einfacher, jedem Entwickler einen eigenen Datenbank- und DBA-Zugriff zu gewähren. Würde dann Änderungen über einen Freigabezyklus in Dev einspeisen. Sollte jetzt mit Virtualisierung einfacher sein.
Sumnibot

@Sumnibot - Einfacheres Installieren, Verwalten, Sichern usw. einer separaten Datenbank für jeden Entwickler als Erteilen von Berechtigungen!?! Zusätzlich zu der Zeit, die erforderlich ist, um jedes dieser Produkte auf dem neuesten Stand zu halten, scheinen die Lizenzkosten beträchtlich zu sein, oder haben Sie ihnen nicht die Enterprise-Version gegeben?
Leigh Riffel

1
Enthält keine konkrete Antwort für mich.
Michael-O

3

Verwenden Sie Rollen, um Objektgruppen zuzuordnen, und gewähren Sie dann Zugriff auf die Rollen

Die GRANT- Anweisung ermöglicht dem DBA Folgendes:

Objektberechtigungen für ein bestimmtes Objekt für Benutzer, Rollen und PUBLIC. Tabelle 18-2 listet die Objektberechtigungen und die von ihnen autorisierten Vorgänge auf.

Da einer Rolle Objektrechte erteilt werden können, ist es relativ einfach, allen Tabellen in einem Schema einen Rollenzugriff zu gewähren:

sql> spool privs.sql
sql> wähle 'grant select on scott.' || table_name || ' zu role_select; ' from dba_tables where owner = 'SCOTT';
sql> @ privs.sql
sql> grant role_select für john, sam, peter;

In Verbindung mit der GRANT CREATE TABLEAusgabe durch den entsprechenden Schema-Benutzer für die Rolle bedeutet dies, dass Entwickler Tabellen auswählen und erstellen können. Es ist nicht perfekt, da für eine erstellte Tabelle die erneute Ausführung des Skripts erforderlich ist. Es wird jedoch WITH GRANT OPTIONempfohlen, dass jeder Entwickler der entsprechenden Rolle Zugriff auf die von ihm erstellte Tabelle gewähren kann.

Dies deutet darauf hin, dass Sie Trigger auf DDL-Ebene erstellen können, mit denen der entsprechende Gewährungsprozess ausgeführt werden kann. Obwohl natürlich umfangreiche Tests erforderlich sind, sollte es möglich sein, mit der Anweisung create table den entsprechenden Rollen automatisch die entsprechenden Berechtigungen zu erteilen.

Bearbeiten -

Laut GRANT ist das CREATE TABLEPrivileg:

Erstellen Sie eine Tabelle im Schema des Berechtigten.

Indem Sie ihnen vom richtigen Benutzer die Option "Tabelle erstellen", "Tabelle ändern" usw. geben , sollten sie auf das Schema dieses Benutzers zugreifen können, als ob sie der richtige Benutzer wären.


Ich habe die von Ihnen beschriebene Methode ohne großen Erfolg gesehen. Ich glaube jedoch, dass Sie Recht haben, dass dies mit umfangreichen Tests möglich ist. Das Problem ist, dass dies nur Entwicklern den Zugriff auf Tabellen ermöglicht. Wenn Sie create table direkt oder über eine Rolle gewähren, erhalten sie nur die Berechtigung zum Erstellen von Tabellen in ihrem eigenen Schema. Sie können immer noch keine Tabellen, Prozeduren, Pakete, Trigger oder andere Objekte in einem anderen Schema als ihrem eigenen erstellen, oder möchten Sie, dass sie selbst bei der Entwicklung nur Objekte in ihrem eigenen Schema erstellen?
Leigh Riffel

@Leigh Mit Details aktualisiert.
Brian Ballsun-Stanton

So funktioniert Oracle einfach nicht. Versuchen Sie Folgendes: Erstellen Sie den Benutzer u1, der mit "ThisIsMy1Password" gekennzeichnet ist. erstelle Benutzer u2, der durch "ThisIsMy1Password" gekennzeichnet ist; gewähren Sie dba zu u1; Grant Connect to U2; connect u1 / "ThisIsMy1Password" @db; Gewähren Sie create table für u2. connect u2 / "ThisIsMy1Password" @db; erstelle die Tabelle u1.t1 (c1 varchar2 (10)); Der letzte Schritt schlägt mit unzureichenden Berechtigungen fehl.
Leigh Riffel
Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.