Erstellen einer weiteren

Question

Ich habe versucht, eine neue Rolle zu erstellen, die alle Privilegien der Rolle PUBLIC hat und danach alle Privilegien aus der Rolle PUBLIC löscht. Dies dient Sicherheitszwecken.

Dies ist das Problem. Ich konnte SYS./1005bd30_LnkdConstant und andere mit demselben Format meiner neuen Rolle nicht zuweisen.

Beispiel:

SYS./10076b23_OraCustomDatumClosur SYS./100c1606_StandardMidiFileRead ORDSYS./1013c29d_PlanarImageServerPro . . .

Brauche ich wirklich diese oder meine neue "öffentliche" Rolle kann ohne diese?

Jede Hilfe wird sehr geschätzt.

Answer 1

Lassen Sie mich eine kurze Vermutung hier. Das Problem, das Sie haben, ist, dass die Objektnamen Groß-und Kleinschreibung beachten. Die schnelle Lösung besteht darin, die Objektnamen in doppelte Anführungszeichen zu setzen.

GRANT EXECUTE ON SYS."/1005bd30_LnkdConstant" TO mynewpublicrole; 

Sie zeigen, dass Sie "nicht gewähren [EXECUTE ON] SYS./1005bd30_LnkdConstant" auf eine Rolle.
Ich nehme das die bedeuten, wenn Sie die Anweisung GRANT liefen, Oracle eine Ausnahme ausgelöst, höchstwahrscheinlich,

ORA-00903: invalid table name 

die objektname in doppelten Anführungszeichen Enclosing (wie im Beispiel) soll das Problem beheben.

Es ist nicht möglich, die Frage zu beantworten, ob Ihre neue Rolle das EXECUTE-Privileg für diese Objekte benötigt oder nicht. Nun, die Rolle braucht sie nicht unbedingt. Die Frage ist, ob der Benutzer sie benötigt oder nicht (ob direkt gewährt oder indirekt über Rollen erteilt). Dies kann durch gründliche Tests festgestellt werden.

---

Einige andere Kommentare.

Wenn Sie eine neue Rolle erstellen und diese Rolle allen Benutzern zuweisen möchten, sehe ich nicht, dass die Sicherheit geändert oder verbessert wird. Also werde ich annehmen, dass das nicht der Fall ist.

Es scheint, dass Sie versuchen, das Prinzip der "geringsten Privilegien" anzuwenden. Ich applaudiere dieser Anstrengung.

Eines der häufigsten Muster, dem Anwendungsentwickler folgen, ist die Verbindung der Anwendung mit der Datenbank als Eigentümer der Schemaobjekte. Das bedeutet, dass die Anwendung alle Arten von Privilegien hat, die sie wahrscheinlich nicht benötigt, z. DROP TABLE, ALTER PROCEDURE usw.

Das Muster, das wir verwenden, ist ein "OWNER" -Benutzer, der die Schemaobjekte besitzt, und ein separater "APP" -Benutzer, der bestimmte Privilegien für die "OWNER" -Objekte hat. und Synonyme für die Objekte "OWNER". (Mit den Synonymen kann das Objekt OWNER.object referenziert werden, ohne dass es mit dem EIGENTÜMER qualifiziert ist.) Es versteht sich von selbst, dass wir PUBLIC keine Privilegien gewähren, wir gewähren Rollen wo nötig.

Ich erwähne das, weil es ein Muster ist, das wir verwenden, um das Prinzip der "geringsten Privilegien" zu implementieren.

---

Für andere Sicherheitsbedenken, empfehle ich Ihnen die „Oracle Sicherheits-Checkliste“ Whitepaper Bewertung:

http://www.oracle.com/technology/deploy/security/database-security/pdf/twp_security_checklist_database.pdf

---

Einige andere mögliche Ausnahmen können Sie begegnet sind, wenn die GRANT-Anweisung ausführen :

ORA-01031: insufficient privileges 

oder

ORA-04042: procedure, function, package, or package body does not exist. 

In beiden Fällen stellen Sie sicher, dass Sie eine Verbindung zur Datenbank als SYS (SYSDBA) herstellen, um die Berechtigungen zu erteilen. Wir erteilen fast immer Privilegien als Eigentümer des Objekts, anstatt einen anderen Benutzer als GRANTEE zu haben. Ich verwende fast nie die "WITH GRANT OPTION" für Objektprivilegien. Es ist ein einfacheres Modell und vermeidet jedes mögliche Problem mit Abhängigkeitsbäumen.