it-swarm.com.de

Fügt der Kennwortschutz einer Datenbank, die sich neben der Anwendung befindet, zusätzliche Sicherheit hinzu?

Ich habe Setups gesehen, bei denen sich eine kennwortgeschützte Datenbank auf demselben Server befand wie eine Anwendung, die die Anmeldeinformationen für diese Datenbank im Klartext enthält.

Was sind die Vorteile eines solchen Setups gegenüber einer einfach ungeschützten Datenbank?

Abgesehen von einer gewissen Verschleierung scheint die Konfiguration von Datenbank und Anwendung für diese Anmeldeinformationen nur die Komplexität zu erhöhen, nicht jedoch die tatsächliche Sicherheit. Ein Angreifer mit Zugriff auf den Server kann die Anmeldeinformationen immer nur in der Konfigurationsdatei der Anwendung finden.

Bearbeiten : Ich spreche von einer Datenbank, die nur auf demselben Computer sichtbar und nicht nach außen sichtbar ist.

40

Es ist sinnvoll, die Datenbank mit einem Kennwort zu schützen, wenn Sie den Zugriff auf die Konfigurationsdatei der Anwendung sichern, die die Klartextanmeldeinformationen enthält. Wenn Sie den Lesezugriff nur auf das Konto der Anwendung beschränken, benötigt der Angreifer Root-Zugriff, um das Kennwort anzuzeigen. Falls er ein anderes (weniger privilegiertes) Konto verletzt hat, kann er keinen Zugriff auf die Datenbank erhalten.

52
Stef Heylen

Das ist eine Art Zwiebelschutz (auch bekannt als " Layered Security " "oder" Tiefenverteidigung ", wie zum Beispiel in SANS '" Layered Security) : Warum es funktioniert "Whitepaper). Wenn ein Angreifer die Maschine (n) erreichen kann, kann er keinen vollständigen Datenbankzugriff erhalten. Die Anwendung sollte einen eingeschränkten Zugriff haben, der nur auf die erforderlichen Tabellen beschränkt ist, und alles, was nicht geschrieben werden muss, sollte schreibgeschützt sein. Für jeden höheren Zugriff sollte ein anderes Kennwort erforderlich sein, das in der Anwendung niemals verwendet wird.

21
Serge Ballesta

Der Vorteil besteht darin, dass sich ein Angreifer, der Netzwerkzugriff auf die Datenbank, jedoch keinen Dateisystemzugriff auf den Server hat, nicht tatsächlich bei der Datenbank anmelden kann.

12
Mike Scott

Vorteile des Passwortschutzes für die Datenbank

  • Wenn es nicht möglich ist, es unsicher zu verwenden, verringert sich das Risiko, dass DB und Server, wenn sie zu einem späteren Zeitpunkt aufgeteilt werden müssen, auf unsichere Weise belassen werden, was zu zukünftigen Exploits führt.

  • Wenn ein Angreifer mit einem eingeschränkten Konto gegen den Computer verstoßen kann, kann er möglicherweise eine Verbindung zu lokalen Diensten herstellen, das Datenbankkennwort jedoch nicht zurücksetzen. Wenn der Angreifer sich authentifizieren muss, wird der Schaden, den er anrichten kann, begrenzt.

  • Wenn ein Angriff verwendet werden kann, um Datenverkehr zu reflektieren/weiterzuleiten, kann sich ein entfernter Gegner auf dem lokalen Computer befinden (ein Beispiel wäre ein Proxy, der davon überzeugt werden kann, eine DB-API zu laden, oder ein Dienst, der empfangene Daten bei einer Verbindung anzeigt schlägt auf eine bestimmte URL fehl)

  • Wenn Kennwörter verwendet werden, können verschiedene Systeme und Benutzer daran gehindert werden, die Konten des jeweils anderen zu verwenden. Andernfalls kann ein Angreifer eines beliebigen Systems vorgeben, ein anderes System zu sein.

4
jrtapsell

Ob dies zusätzliche Sicherheit bietet, hängt von Ihrem Bedrohungsszenario und Ihren Sicherheitszielen ab. Ich kenne mindestens zwei Situationen, in denen dies die Sicherheit erhöht:

  • Damit können Sie den legitimen Zugriff genauer steuern auf die Datenbank: Es kann Personen geben, die legitimerweise Zugriff auf die Datenbank benötigen, jedoch nicht auf die darin enthaltenen Daten, z. B. DB-Administratoren, die Wartungsarbeiten durchführen. Eine verschlüsselte Datenbank kann (abhängig vom Setup) die Gewährung des DB-Zugriffs ermöglichen, während die Daten weiterhin geheim gehalten werden.
    In ähnlicher Weise ermöglicht das Verschlüsseln eines Teils der Datenbank (z. B. nur Spalten mit Kennwörtern) einen eingeschränkten Zugriff (z. B. zum Debuggen von Problemen, zum Berichten oder für ein Data Warehouse) beim Schutz kritischer Informationen.
  • Es kann Backups schützen der Datenbank. Wenn die Datenbank auf Dateiebene oder mit einem Sicherungstool gesichert wird, das verschlüsselte Datenbanken unterstützt, wird die Sicherung verschlüsselt. Dies ist nützlich, da Sicherungen eine Quelle für Datenverletzungen sein können, da sie häufig nicht so sicher sind wie die Server, von denen sie stammen (siehe z. B. Schlechte Sicherungssicherheit führt zu Datenverlust bei Ameriprise-Clients ).
4
sleske

Wenn Sie in Zukunft keine größeren Skalierungsprobleme haben, kann es sein, dass möglicherweise keine Sicherheit für ein Kennwort hinzugefügt wird Bitte beachten Sie jedoch, dass "kein Passwort haben" nicht dasselbe ist "jedem vertrauen, der behauptet, Ihre Bewerbung zu sein."

Wenn Ihre Anwendung als eigener Benutzer auf dem Server * ausgeführt wird, können Sie in einigen Datenbanken möglicherweise die Authentifizierung von Drittanbietern verwenden (z. B. die von Postgres als peer bezeichnete Authentifizierung), mit der der Server Netzwerk- oder Betriebssystemmechanismen verwenden kann Bestimmen, welche Benutzer sind, wer sie sagen, dass sie sind. Beispielsweise könnte der Shell-Benutzer "bob" unter der richtigen Konfiguration auf das Datenbankkonto "bob" zugreifen, ohne ein Kennwort anzugeben. Wenn die Dinge einfach sind, kann dies die Sicherung Ihrer Datenbank und Anwendung vereinfachen.

Als jrtapsell 's Antwort Hinweise müssen Sie Ihre Anwendung möglicherweise aus Kosten- oder Leistungsgründen auf einen anderen Server verschieben. In diesem Fall benötigen Sie wahrscheinlich ein gespeichertes Passwort oder ein anderes Geheimnis wie einen privaten Schlüssel, obwohl es einige Methoden gibt, die hauptsächlich in privaten Netzwerken verwendet werden können, um dies zu vermeiden.

Wenn Sie der Meinung sind, dass es eine gute Chance gibt, dass Sie in Zukunft ein Passwort (oder ein anderes gespeichertes Geheimnis) benötigen, sollten Sie die Vorkehrungen jetzt treffen, damit sie später von jemandem mit weniger Zeit oder Erfahrung nicht unsicher getroffen werden.

* Idealerweise sollte dieses Konto stark mit einem Passwort versehen sein oder nur zur Anmeldung über Sudo oder einen gleichwertigen Mechanismus verfügbar sein

2
koyae

Sie kennen all die Datenverletzungen, die kürzlich aufgetreten sind? Diejenigen, bei denen Benutzer nicht passwortgeschützte Datenbanksicherungen in ungesicherten Amazon S3-Buckets gefunden haben? Ja.

Niemals Angenommen, Ihre Datenbank wird immer nur auf Ihrem gesicherten Server hinter 20 Milliarden Firewalls leben. Der kleine Aufwand für ein Passwort in Ihrer Datenbank ist ein geringer Preis für die im Wesentlichen kostenlose Sicherheit.

2
Ian Kemp

Als Ergänzung zu Serge Ballestas Antwort.

Dies wird besonders schwierig, wenn Sie eine NoSQL-Datenbank verwenden, z. MongoDB, da standardmäßig jeder Datenbankbenutzer schreibgeschützt Berechtigungen für alle Datenbanken hat und nicht einmal für einen Datenbankbenutzer konfiguriert ist out of the box. Es gibt einige Schwächen, wie sie von Spider Labs Blog vor einiger Zeit (um 2013) angegeben wurden, aber die Empfehlungen werden normalerweise selbst für große Unternehmen, z. MacKeeper Vorfall (Ende 2015).

In beiden Referenzen finden Sie eine Liste der häufigsten Sicherheitslücken. Wenn Sie lieber 'offizielle' Richtlinien lesen möchten, finden Sie diese hier , sie müssen für SQL-Datenbanken analog sein. Ich denke jedoch gerne, dass es keine Overkills gibt, wenn es um Sicherheit geht.