12. September 2013

Nachtrag zu meinem DOAG SIG Security Vortrag am 11.9.2013 in Berlin

Zu meinem Vortrag auf der gestrigen Veranstaltung  möchte ich zwei Ergänzungen nachliefern.

1. Setup Application Owner Setup

Im Vortrag stellte ich aus Sicht der Sicherheit ein richtiges und falsches Setup für Anwendungsowner vor. Ein Anwendungsowner ist dasjenige Schema, welches in der Datenbank die Datenbank-Objekte der Anwendung verwaltet.
Das nachfolgende Bild zeigt das richtige Setup auf.
Anwendungsowner Setup (Richtig)
Hierbei ist es wichtig, dass der Zugriff auf die Objekte im Anwednungsowner Setup über einen sogenannten Awendungsuser stattfindet. Dieser Anwendungsuser hat besondere Rechte, um damit auf den Objekten des Anwendungsowner operieren zu können (least privilege). Der Anwendungsowner ist gesperrt und dient lediglich als Speicher der Objekte. Ein Release Manager deployed neue Release in das Anwendungsowner Schema.
Der Vorteil dieses Setup ist eine Zwecktrennung und natürlich eine zugeschnittene Zugriffskontrolle für den Anwendungsuser, also die Umsetzung eines Least-Privilege Konzept.
In der Veranstaltung kam der Einwand, dass dieses theoretische Setup nicht praktikabel sei, da Anwendungshersteller zum Teil ein anderes Konzept verfolgen, welches ich als falsch betrachte. Diese Aussage ist natürlich richtig und eine Anpassung kann u.U. nicht trival sein, sowie zu einem Supportverlust führen.
Anwendungsowner Setup (falsch)
Wenn man bestehende (u.U. falsche) Anpassungen nicht ändern kann, sollte man zumindest das Risiko einschätzen und geeignete Maßnahmen einleiten, welche das Risiko eines falsches Konzeptes abmildern. Hat man z.B. ein Setup eines Anwendungsowner mit der die Anwendung direkt arbeitet, so kann es zu folgenden Risiken kommen:
  1. Der Anwendungsowner hat sehr mächtige Privilegien wie ANY Grants. Diese mächtigen Privilegien können die Endbenutzer indirekt auf der Datenbanken ausführen, da die Anwendung die Verbindung zur Datenbank über den Anwendungsowner herstellt.
  2. Die Anwendung autorisiert die Endbenutzer in der Anwendung und mildert so die mächtigen Privilegien in der Datenbank bereits in der Anwendung ab. D.h. aber auch, dass die Anwendung Sicherheit garantieren muss und z.B. SQLInjections nicht möglich sind. Das heisst aber auch weiter, dass man garantieren muss, dass nur die Anwendung (denn die autorisiert) mit dem Anwedungsowner-Schema arbeitet.
  3. Zugriffe auf den Anwendungsowner werden auch dazu missbraucht direkt auf den Daten zu arbeiten z.B. für ein Reporting mittels Tools wie MS Excel, Toad, SQL Developer etc.. Hierbei können die mächtigen Privilegien missbraucht werden. Daher ist solch ein Zugriff zu unterbinden.
  4. Es werden Datenintegrationen via DB Links aufgebaut, die direkt mit den Anwendungsowner arbeiten. Das führt u.U. wieder zum Missbrauch der mächtigen Privilegien.
Anwendungsarchitektur eines falsches Anwendungsowner Setups

Kann man das falsche Setup nicht verhindern oder anpassen, muss man sich dem Risiko 1) bewußt sein und Maßnahmen für das Risiko 2) erzwingen, wie z.B. nur die Anwendung darf auf das Schema zugreifen und der Zugriff wird auf Ausführung kritischer Aktivitäten überwacht.
Für die Risiken 3) und 4) agiert man meistens aus eigener Motivation und sollte hier unbedingt, dass richtige Setup umsetzen, also auf die Least Privilege achten und eine richtige Zwecktrennung durchführen.

2. Wann muss gepatched werden?

Oracle liefert vierteljährlich sogenante Security Patch Updates (SPU) oder Critical Patch Updates (CPU). Eine Übersicht der letztes Updates finden Sie hier.
Nun höre ich oft, dass man Patching einmal oder zweimal im Jahr durchführt. Diese Strategie halte ich für falsch. Die richtige Strategie ist eine interne Entscheidungsgrundlage zu definieren, die aussagt, wann gepatched werden muss. Hierfür muss auch das Buyin der Fachabteilung eingeholt werden, die dann diese Entscheidung mitträgt.
Die Risikomatrix zu einem CPU oder SPU kann hier die notwendige Grundlage schaffen. Es werden die Komponenten dargestellt, die eine Schwachstelle aufweisen und mit einem Risikofaktor versehen. Der Faktor 10 stellt das höchste Sicherheitsrisiko dar. Somit könnte man z.B. folgede Entscheidungsgrundlage formulieren:
"Wenn in unseren Datenbanken mit hohem Schutzbedarf eine genutzte Komponente mit einer Schwachstelle betroffen ist, die einen Risikofaktor > 6.5 hat und zu erheblichen Bedrohungen für das Business führen kann, dann muss gepatched werden. Wenn diese Situation eintritt, muss der entsprechende Patch/CPU innerhalb von einer definierten Zeit (z.B. 2 Monate) deployed werden."
Während meiner Präsentation kam der Einwand, dass diese Strategie nicht praktikabel sei, wenn Kunden tausende von Datenbanken betreiben. Der Aufwand des Patchens wäre zu umfangreich.
Diesen Einwand kann ich verstehen, hat aber nichts mit meiner Strategievorlage zu tun. Der Einwand beschreibt das "WIE". Also wie patche ich u.U. tausende von Datenbankinstances sehr effizient, wenn die interne Entscheidung sagt: "Lt. gegebenen Risiko müssen wir patchen".
Nun könnte man den Einwand auch so verstehen, dass der Einwandgeber sagen wollte: "Ja, eigentlich richtige Strategie, aber wegen der Masse der Datenbanken kann man nicht auch das Risiko betrachten und andauernd patchen."
Die Menge der Datenbanken sollte nicht dazu führen, dass man sich das Risiko nicht bewusst macht. Es ist keine trivale Aufgabe tausende von Datenbanken regelmäßig zu patchen, trotzdem befreit die Menge der Datenbanken sich nicht vor der Entscheidung "wann gepatched werden muss". Natürlich müssen hier die internen Gegebenheiten eingearbeitet werden. Fakt ist, ein nicht-patchen führt automatisch zu einem erhöhten Risiko.
Nachdem man die Entscheidungsgrundlage geschaffen hat, muss man sich über das "WIE" Gedanken machen. Also wie kann der Patch effizient in den betroffenen und schutzbedürftigen Datenbanken deployed werden.
Oracle hat in seinem Datenbank-Administrationsbaukasten Enterprise Manager geeignete Lösungen, um ein Patching zu vereinfachen. Das nachfolgende Bild stellt einen typischen Prozess dar:
Patching Prozess mit Oracle Enterprise Manager Hilfsmitteln


Kommentare:

  1. Zum richtigen Setup:
    Sind bei "Release Managern" personalisierte Accounts anzustreben (im Gegensatz zu den technischen Accounts bei Anwendungsowner und Anwendungsuser)?

    Falls ja und falls diese Release Manager zugleich auch DB-Admin mit personalisierten Accounts sind:
    Sollten diese beiden Aufgaben "Release Manager" sowie "DB-Admin" (z.B. über Rollen) in einem Account kombiniert werden oder auf zwei personalisierte Accounts verteilt werden?

    AntwortenLöschen
  2. Das hängt natürlich immer von der Organisation ab. Oft muss man gezwungenermaßen einfach viele Rollen auf einem Kopf anwenden, da die Personaldecke nichts anderes zulässt. Also man muss immer Situationsbedingt entscheiden.
    Idealerweise haben Sie Recht:
    Auch einen personalisierten Account für den Release Manager und gegebenenfalls ist das eine andere Person als der DBA.

    AntwortenLöschen