Welche Berechtigungen sollten Entwickler in der Dev-Datenbankinstanz haben

Question

... und wie sollten diese Berechtigungen gewährt werden. Ich arbeite in einer großen IT Abteilung mit über 70 Anwendungen, einige in SQL Server und die meisten in Oracle. Jedes System hat eine Prod-, QA- und Dev-Instanz. Wir (ich bin ein Entwickler) haben nur Lesezugriff auf prod/qa, womit ich einverstanden bin. In SQL-Serverentwicklungsinstanzen erhalten Entwickler db_owner, was völlig gut funktioniert. Die Debatte ist darüber, welche Berechtigungen ich in den DEV-Oracle-Datenbanken haben sollte.

Ich weiß, dass der beste Fall wäre, dass jeder Entwickler seine eigene Instanz auf seiner Workstation zur Entwicklung laufen lässt, aber wegen der Größe der Datenbanken wurde dies nicht als eine Option betrachtet.

Ich bin auch daran interessiert, wie diese Berechtigungen angewendet werden sollten. In Oracle-Berechtigungen, die über eine Rolle erteilt werden, sind sie während der PL/SQL-Ausführung nicht aktiv, so dass Rollen (selbst die "dba" -Rolle) nicht nützlich sind. Das lässt ein eingebautes Konto (System) oder das Erstellen von Dutzenden von Benutzern über Dutzende von Datenbanken und direkte Gewährung von Dutzenden von Berechtigungen für jeden. In meinem Verstand macht es einfach Sinn, die Entwickler als System anmelden zu lassen, aber unsere DBAs behaupten, dass das eine schlechte Idee ist.

Answer 1

Früher haben wir Entwicklern nur den Zugriff auf das Anwendungskonto ermöglicht. Dies funktioniert für kleine Läden, gerät aber schnell außer Kontrolle, wenn die Anzahl der Entwickler steigt.

Hier ist, was wir jetzt tun:

1. die Anwendung hat ein eigenes Konto (auch bekannt als Schema).
2. Entwickler haben ihre eigenen Konten
3. Daten befinden sich im Anwendungsschema
4. Wir haben eine Ameise Build-Skript Code in welchem ​​Schema Sie wollen zu bauen.
   • Code enthält Ansichten, die Pakete, Objekte etc ..
   • der Build-Skript einen Schritt um eine gespeicherte Prozedur zu gewähren explizite Rechte für Entwickler zu den Anwendungsdaten
5. Entwickler Änderungen in ihrem läuft eigenes Schema
6. Wenn sie glücklich sind, überprüfen sie das in Subversion
7. Das dev Schema der Anwendung wird vom neuen subversion Aufbau gebaut.
8. Entwickler können ihre eigenen Umgebungen auschecken und neu erstellen.
9. DDL Änderungen an Tabellenstrukturen werden über das DBA getan
   • diese auch scripted werden können

Dies den Vorteil sicherzustellen, hat jeden vorderen Aufbringende gebrochen wird nicht von Datenbank-Entwickler ständig alles neu aufbauen.

Answer 2

Einer der DBA-Aufträge besteht darin, Benutzerberechtigungen zu verwalten. Ich glaube nicht, dass System aus mehreren Gründen eine gute Idee ist, nicht zuletzt die Möglichkeit, ein ganzes Schema zu löschen, von dem ich sicher bin, dass es nicht gewünscht wird. Ich denke, es ist völlig in Ordnung, all Ihren Benutzern die Berechtigung zu erteilen und die Datenbankadministratoren diese Berechtigungen verwalten zu lassen, unabhängig davon, wie viele Konten vorhanden sind. Die meisten Datenbankadministratoren verfügen über Skripts, mit denen sie diese Berechtigungen trotzdem verwalten können.

Hören Sie auf Ihre DBAs, sie wissen im Allgemeinen, wovon sie reden.

Answer 3

Wenn es nur eine dev-Instanz ist; Ich hätte allen Benutzern individuelle Konten, die der Administratorrolle hinzugefügt wurden. Auf diese Weise können Sie Aktivitäten immer noch für einzelne Benutzer protokollieren. aber geben Sie den Entwicklern genügend Raum zum Atmen, um ihr Ding zu machen.

Answer 4

Ich nehme an, dass es eine relativ kleine Anzahl von Anwendungskonten gibt, die die tatsächlichen Objekte besitzen. Eine oder mehrere logische Anwendungen bestehen also aus Tabellen, die einem bestimmten Oracle-Benutzer gehören. Dies wäre nicht von SYSTEM oder SYS, es wäre keines der Konten, die Oracle das Unternehmen liefert. Es wäre ein Konto, das von Ihren DBAs erstellt wurde. Wenn Sie mit den Oracle-Beispielschemas vertraut sind, besitzt der HR-Benutzer alle Tabellen im HR-Schema, aus denen das Backend für eine HR-Anwendung besteht.

Ausgehend von dem Prinzip "die einfachste Sache, die möglicherweise funktionieren könnte", wäre mein erster Gedanke zu sehen, ob die Entwickler sich direkt auf diese Anwendungskonten anmelden könnten. Dies ist nicht die sicherste mögliche Konfiguration, und Sie eröffnen die Möglichkeit, dass ein Entwickler versehentlich oder absichtlich etwas Schaden verursacht, der schwer zu verfolgen oder leicht zu beheben ist. Aber es kann abhängig von der Organisation ziemlich gut funktionieren. Die Rechteverwaltung ist trivial - das Konto des Anwendungseigentümers verfügt bereits über alle erforderlichen Berechtigungen. Der nächste Schritt würde jedem Entwickler ein eigenes Schema zum Entwickeln geben, vermutlich in Verbindung mit einer Ladung von öffentlichen Synonymen in der Datenbank und einem Fehlen von Schemaqualifikationsmerkmalen im Anwendungscode, so dass jedes Objekt, das im Das Entwicklerschema überschreibt automatisch die freigegebene Version dieses Objekts. Dies bietet eine viel bessere Isolierung. Berechtigungen werden im Allgemeinen gewährt, indem entweder Skripts erstellt werden, die alle von einem Entwickler benötigten Berechtigungen enthalten, oder indem ein Skript erstellt wird, das alle Berechtigungen von einem "bekannt guten" Konto auf das neue Konto kopiert. Beides ist nicht besonders schwierig zu schreiben - Sie müssen nur sicherstellen, dass alle Entwickler dieselben Berechtigungen erhalten. Dies ist im Allgemeinen nur ein anderes Skript, das ausgeführt wird, wenn eine neue Berechtigung erteilt wird.

Answer 5

Meine Gruppe unterstützt etwa 100 Apps, von denen etwa 20 ein eigenes Oracle-Schema haben. Wir sind den Weg jedes Entwicklers gegangen, haben das Passwort zum Schema und es ist bequem. Im Nachhinein empfehle ich jedem Entwickler, sein eigenes Oracle-Konto zu entwickeln. Der Hauptgrund ist das Auditing.

Answer 6

ich erkennen, dass bester Fall zu haben würde jede dev ihre eigene Instanz auf ihrer Workstation für die Entwicklung läuft, aber wegen der Größe des Datenbanken hat dies nicht eine Option in Betracht gezogen worden.

Gibt es einen Weg, damit umzugehen, vielleicht durch die Reduzierung der Datenmenge in Ihren persönlichen Kopien? Dies scheint die ideale Lösung zu sein, da Sie Änderungen vornehmen können, die Sie benötigen. Dann können Sie sie an den DBA senden, wenn Sie bereit sind, und ihn den gemeinsam genutzten Entwicklungsserver aktualisieren lassen.

Answer 7

Wenn Sie gespeicherte PL/SQL-Objekte entwickeln, benötigt das Schema, das diese Objekte besitzt, explizite Berechtigungen für die verwendeten Objekte. Wenn Sie ein einzelnes "Daten" -Schema haben, aber Code in Ihren eigenen Schemata entwickeln, sollten Sie die Möglichkeit erhalten, Ihren Entwicklungsschemas Zugriff auf die Datenschemaobjekte zu gewähren. Normalerweise würde ich Benutzername/Passwort für das Datenschema erwarten.

In Bezug auf Systemprivilegien (zB CREATE) würde ich CREATE TABLE, TYPE, VIEW, PROCEDURE TRIGGER, SYNONYM erwarten. Je nach dem, was Sie tun, können andere geeignet sein (z. B. KONTEXT). Der DBA kann CREATE DIRECTORY ausschließen, da dies bei falscher Verwendung schädlich sein könnte. Dito für Privilegien mit ANY in ihnen (zB SELECT ANY TABLE, LÖSCHEN JEDER TABELLE)

Für Performance-Tuning/Systemüberwachung, in einer Dev-Datenbank ist SELECT_CATALOG_ROLE gut. Wenn der DBA risikoscheu ist, müssen Sie möglicherweise Zuschüsse für einzelne Ansichten aushandeln. Gehen Sie durch das REFERENCE-Handbuch für Ihre Version und fragen Sie danach, welche Sie verwenden können.