Warum wird die Betriebssystemauthentifizierung als schlechte Sicherheit für Oracle-Datenbanken angesehen?

Question

Oracle lehnt die Betriebssystemauthentifizierung gemäß Oracle Database Security Guide ab

Beachten Sie, dass der Parameter REMOTE_OS_AUTHENT in Oracle Database 11g Release 1 (11.1) veraltet ist und nur aus Gründen der Abwärtskompatibilität beibehalten wird.

Darüber hinaus betrachten die meisten Sicherheitsinformationen und -tools Betriebssystem (externe) Authentifizierung als Sicherheitsproblem. Ich versuche zu verstehen, warum dies der Fall ist. Hier sind einige Vorteile der Betriebssystemauthentifizierung:

Ohne Betriebssystemauthentifizierung müssen Anwendungen Kennwörter in einer Vielzahl von Anwendungen mit jeweils eigenem Sicherheitsmodell und eigenen Sicherheitslücken speichern.
Die Domänenauthentifizierung muss bereits sicher sein, da die Datenbanksicherheit den Zugriff auf die Datenbank nur verlangsamt, aber nicht verhindern kann.
Benutzer, die sich nur ein Domänenkennwort merken müssen, können dazu gebracht werden, sicherere Domänenkennwörter einfacher zu erstellen als noch weniger sichere Datenbankkennwörter, wenn die Anzahl der verschiedenen Datenbanken, mit denen sie eine Verbindung herstellen müssen, zunimmt.

Gaius · Accepted Answer

Stellen Sie sich das folgende Szenario vor:

Auf dem Oracle-Server befindet sich ein Unix-Benutzer mit dem Namen gaius mit externer Authentifizierung. In Oracle gibt es also einen entsprechenden Benutzer mit dem Namen ops$gaius. Wenn ich bei einer Shell angemeldet bin, kann ich mich auch direkt bei meinem Oracle-Schema anmelden, und für meine Cron-Jobs ist auch kein im Skript eingebettetes Kennwort erforderlich.
Die Remote-Betriebssystemauthentifizierung ist zulässig, vorausgesetzt, das LAN ist 100% sicher und die Clients können vertrauenswürdig sein (wie rlogin/rsh, das normalerweise zulässig war).
Ein Angreifer bringt seinen Laptop auf irgendeine Weise in das LAN, weiß, dass ich dort arbeite, erstellt auf seinem Laptop einen lokalen Benutzer namens gaius und führt SQL * Plus als diesen Benutzer aus
Oracle sieht (d. H. OSUSER in V$SESSION) gaius und meldet diesen Remotebenutzer als ops$gaius An.

Das ist nicht nur lächerlich leicht zu fälschen, sondern wenn Oracle den Hut meines Zynikers aufsetzt, kann es kein Geld mehr verdienen, wenn es Ihnen sein schickes Single-Sign-On-Produkt verkauft ... Was übrigens erfüllt alle Punkte, die Sie als Vorteile der Authentifizierung auf Betriebssystemebene ansprechen. Zwei Passwörter, die besser als eines sind, sind völlig falsch. Die meisten Leute werden sie sowieso so einstellen, dass sie gleich sind (es gibt in Oracle keinen Mechanismus, der dies verhindert).

Das allgemeine Prinzip ist, dass es äußerst schwierig ist, sich in Software zu verteidigen, wenn ein Angreifer physischen Zugriff hat. Und vertraue niemals dem Kunden.

Brian Ballsun-Stanton · Answer

Es erhöht einzelne Fehlerquellen und vergrößert die Risikofläche Ihrer Daten.

Ein Angreifer, der Zugriff auf das System erhält, hat mit der Betriebssystemauthentifizierung Zugriff auf die Datenbank. Durch die Anforderung eines sichereren Zugriffs auf die Datenbank muss der potenzielle Angreifer seine Berechtigungen auf dem gefährdeten System erweitern, um Root- oder Oracle-Zugriff zu erhalten, anstatt auf einen Benutzer.

Dieses Problem ist eine Funktion des externen Zugriffs auf die Datenbank. Wenn es keinen externen Zugriff gibt und der Computer vollständig gesichert ist, ist die Frage der Berechtigungen umstritten. Wenn Entwickler jedoch Zugriff haben, erhöhen Benutzerberechtigungen auf Betriebssystemebene den Umfang potenzieller Sicherheitskatastrophen.

Erwägen Sie die Verwendung von mehrschichtiger Zugriff , um den Umfang von Sicherheitsverletzungen einzuschränken und jedem Benutzer, jeder Anwendung oder jedem Client den erforderlichen Zugriff zu gewähren, ohne dass für jede Instanz Konten auf Betriebssystemebene erstellt werden müssen.

Justin Cave · Answer

Gaius hat bereits darauf hingewiesen, warum Remote-Betriebssystemauthentifizierung (im Gegensatz zur Vanilla-Betriebssystemauthentifizierung, bei der lokale Computerbenutzer auf die Datenbank zugreifen können, ohne a anzugeben separates Passwort) ist relativ unsicher.

Ich würde erwarten, dass Oracle sich in diese Richtung bewegt, weil es die Benutzer dazu ermutigen möchte, nternehmensbenutzer (oder die vollwertige Identitätsverwaltungssuite) anstelle von Benutzern zu verwenden, die vom Remote-Betriebssystem authentifiziert wurden. Unternehmensbenutzer haben die gleichen Vorteile wie Benutzer, die vom Remote-Betriebssystem authentifiziert wurden, aber Oracle geht tatsächlich aus und trifft Ihren Active Directory-Server, um den Benutzer zu authentifizieren. Sie erhalten die gleichen Single-Sign-On-Vorteile, ohne die Sicherheitsüberprüfung dem Client-Computer zu überlassen.

Joe · Answer

Sie verweisen ausdrücklich auf die Authentifizierung im Ident-Stil, möchten aber auch darauf hinweisen, dass andere Methoden zum Verknüpfen der Datenbank oder anderer Anmeldungen mit den Anmeldungen des Betriebssystems genauso schlecht sind. (Sei es lokale Passwortdateien, LDAP oder was auch immer für die tatsächliche Speicherung der Anmeldeinformationen)

Wenn Sie Remoteverbindungen zur Datenbank (oder zum Webserver oder was auch immer die Authentifizierung durchführt) zulassen, ignorieren einige Betriebssysteme Regeln, die möglicherweise festgelegt werden, um das Brute-Force-Konto zu erschweren (z. B. Blockieren von IPs, von denen die fehlgeschlagenen Versuche ausgehen; Sperren) Benutzer für einen Zeitraum nach einer festgelegten Anzahl von Fehlern usw.). Normalerweise sind diese Regeln an sshd und nicht das Authentifizierungssystem als Ganzes gebunden.

Sollte jemand in der Lage sein, eine Verbindung zur Datenbank/zum Webserver/was auch immer aus der Ferne herzustellen, kann er das Kennwort brutal erzwingen, da Datenbanken in der Regel nicht über dieselben Mechanismen verfügen, um Versuche zu verlangsamen, und dann ssh einschalten, sobald er die erforderlichen Anmeldeinformationen gefunden hat.