Diese Visualierung der weltgrössten Datenverluste ist einfach zu schön und muss gezeigt werden:
Check it out:
World biggest data breaches
Tipps, Tricks und Best Practices zu verschiedenen Themen. Im Moment beschäftigen mich die Bereich Security, Cloud, IOS App Development und real-time event streaming am meisten.
23. Juli 2013
16. Juli 2013
DB 12c Security Serie 1: Die Resource Rolle
Mit der Serie der Neuerungen in der 12c Datenbank bezogen auf Security möchte ich nicht mit den großen Veränderungen beginnen.
Natürlich gibt es bahnbrechende Erneuerungen wie die Mandantenfähigkeit (Multitenant), das vervollständigte Information Lifecycle Management (ILM) Konzept, neue Funktionen zur Steigerung der Verfügbarkeit wie Global Data Services, Application Continuity oder Active Dataguard Far Syn und auch neue Konzepte für die Datensicherheit wie Redaction, die Privilege Analysis, die durchgängige implementierte Zwecktrennung und das unified Auditing.
Ich beginne mit den kleinen Veränderungen und Neuerungen, die die bekannte und sehr gute Sicherheit der Oracle Datenbank weiter abrunden.
Ich empfehle schon seit langer Zeit die Nutzung eigener definierter Rollen für die Anwendungen, die in der Datenbank betrieben werden. Der Hintergrund dieser Empfehlung ist sehr einfach:
Mit der aktuellen 12c (12.1) Version hat sich Oracle wieder entschieden, auch die Privilegien diesmal der RESOURCE Rolle zu beschneiden. Es wurde das Privileg "UNLIMITED QUOTA" entfernt. Somit sind ausschließlich folgende Privilegien in der RESOURCE Rolle zu finden:
Natürlich gibt es bahnbrechende Erneuerungen wie die Mandantenfähigkeit (Multitenant), das vervollständigte Information Lifecycle Management (ILM) Konzept, neue Funktionen zur Steigerung der Verfügbarkeit wie Global Data Services, Application Continuity oder Active Dataguard Far Syn und auch neue Konzepte für die Datensicherheit wie Redaction, die Privilege Analysis, die durchgängige implementierte Zwecktrennung und das unified Auditing.
Ich beginne mit den kleinen Veränderungen und Neuerungen, die die bekannte und sehr gute Sicherheit der Oracle Datenbank weiter abrunden.
Ich empfehle schon seit langer Zeit die Nutzung eigener definierter Rollen für die Anwendungen, die in der Datenbank betrieben werden. Der Hintergrund dieser Empfehlung ist sehr einfach:
Oft sehe ich das Rollen wie CONNECT und RESOURCE als Standardrollen vergeben werden, ohne zu prüfen, ob die Berechtigungen in diesen Rollen wirklich dem "least privilege" folgen, also wirklich notwendig sind. Das führte dazu, dass Datenbankbenutzer in älteren Datenbank Versionen z.B. über die Rolle CONNECT ein "ALTER SESSION" Privileg bekamen. Mit diesem Privilge konnten Sessions gedumped werden . Oder ermöglichte die Zuordnung der Rolle RESOURCE einem Datenbankbenutzer ein UNLIMITED TABLESPACE QUOTA, so dass die Datenbankbenutzer mit der RESOURCE Rolle jeden Tablespace unlimiert beschreiben konnten.Bereits in der Datenbank Version 10.2 wurden die Privilegien der CONNECT Rolle auf "CREATE SESSION" reduziert.
Mit der aktuellen 12c (12.1) Version hat sich Oracle wieder entschieden, auch die Privilegien diesmal der RESOURCE Rolle zu beschneiden. Es wurde das Privileg "UNLIMITED QUOTA" entfernt. Somit sind ausschließlich folgende Privilegien in der RESOURCE Rolle zu finden:
SQL> select * from role_sys_privs where role ='RESOURCE' order by privilege; ADMIN ROLE PRIVILEGE OPTION COMMON ---------- -------------------- ------ ------ RESOURCE CREATE CLUSTER NO YES RESOURCE CREATE INDEXTYPE NO YES RESOURCE CREATE OPERATOR NO YES RESOURCE CREATE PROCEDURE NO YES RESOURCE CREATE SEQUENCE NO YES RESOURCE CREATE TABLE NO YES RESOURCE CREATE TRIGGER NO YES RESOURCE CREATE TYPE NO YES
Was bedeutet das?
Mit der Datenbank Version 12c müssen die DBAs und Anwendungsowner QUOTA auf Tablespaces kontrolliert vergeben. Eine Zuordnung der Rolle RESOURCE reicht nicht mehr aus, und wurde sowieso entgegen von Sicherheitsbedenken von mir noch nie empfohlen. Also, bei einer Migration auf 12c bedenken, dass falls RESOURCE genutzt wurde, ein QUOTA Management aufgesetzt werden muss. Darüber hinaus sollte man auch gleich die Gelegenheit prüfen, wenn RESOURCE verwendet wurde, ob die darin verwendeten Privilegien wirklich zur Erfüllung der Aufgabe des Datenbankbenutzer benötigt werden. Es empfiehlt sich immer eigene Rollen entsprechend der notwendigen Privilegien zu erstellen. Eine Nutzung von Standardrollen für Nicht-Admins in der Datenbank sollte vermieden werden. Diese Weisheit erhöht die Kontrolle für das Berechtigungskonzept, denn eine eigene Erstellung bedingt es genau über die notwendigen Privilegien nachzudenken.
Abonnieren
Posts (Atom)