it-swarm.com.de

Was ist eine gute Sicherheitspraxis zum Speichern einer kritischen Datenbank auf Entwickler-Laptops?

Wir haben ein paar Gegebenheiten:

  1. Entwickler benötigen eine Replik der Produktionsdatenbank auf ihren Maschinen.
  2. Entwickler haben das Kennwort für diese Datenbank in den App.config-Dateien.
  3. Wir möchten nicht, dass die Daten in dieser Datenbank kompromittiert werden.

Einige Lösungsvorschläge und ihre Nachteile:

  1. Vollplattenverschlüsselung. Dies löst alle Probleme, beeinträchtigt jedoch die Leistung des Laptops, und wir sind ein Start-up. Sie haben also kein Geld für Powerhorses.
  2. Erstellen eines VM mit verschlüsselter Festplatte und Speichern der Datenbank darauf. Es funktioniert gut, aber es hilft nicht viel, da es in Web.Config ein Kennwort gibt.
  3. Lösung Nummer 2 + erfordert, dass der Entwickler das Datenbankkennwort jedes Mal eingibt, wenn er etwas ausführt. Es löst alle Probleme, ist aber für Entwickler, die die Anwendung manchmal mehrmals pro Minute starten, sehr umständlich. Außerdem haben wir mehrere Anwendungen, die eine Verbindung zu derselben Datenbank herstellen, und die Implementierung eines Kennwortbildschirms muss sich in jedem unterscheiden.

Meine Frage ist also, ob es eine gemeinsame Lösung für ein solches Problem gibt oder Vorschläge, wie eine der oben genannten Lösungen praktikabel gemacht werden kann.

33
Svarog

Sie möchten nicht nur keine Kopie der Produktionsdatenbank, sie ist möglicherweise auch illegal. In den USA können Sie beispielsweise Produktionsdaten nicht aus der Produktionsumgebung verschieben, wenn sie regulierte Informationen wie persönliche Gesundheitsdaten, Finanzdaten oder sogar Daten enthalten, die bei Identitätsdiebstahl verwendet werden könnten. Wenn Sie dies tun, können Sie mit einer Geldstrafe belegt werden, Ihre Compliance-Berechtigung verlieren und daher aggressiveren Audits unterzogen werden oder sogar in einem Rechtsstreit genannt werden.

Wenn Sie zum Testen Daten im Produktionsmaßstab benötigen, haben Sie mehrere Möglichkeiten:

  1. Generieren Sie alle Dummy-Daten. Das ist schwieriger als es sich anhört. Es ist überraschend schwierig und arbeitsintensiv, sinnvolle imaginäre Daten zu generieren.
  2. Anonymisieren Sie Ihre Produktionsdaten. Dies mag einfacher sein, aber seien Sie vorsichtig.

Für Option 2

  • In der Produktionsumgebung erstellt ein autorisierter Datenbankadministrator eine Kopie der Produktionsdaten.
  • Noch in der Produktionsumgebung führt derselbe autorisierte Administrator eine Routine aus, die alle vertraulichen Daten anonymisiert. Im Zweifelsfall anonymisieren.
  • Nur dann sollten die Daten in eine andere Umgebung verschoben werden.
100
Corbin March

Können Sie den Entwicklern in Ihrem Rechenzentrum zumindest VMs geben, in die sie für diese Arbeit RD-fähig sind? Während sie eigentlich mit nicht produktiven Daten arbeiten sollten, wäre dies sicherer, bis Sie dorthin gelangen, da die Daten nicht auf leicht gestohlenen Laptops gespeichert würden.

9
Brian Knoblauch

Ändern Sie nach Möglichkeit Ihre Arbeitsweise.

Wie andere betont haben:

  • Die Verwendung von Produktionsdaten für die Entwicklung ist keine gute Praxis.
  • Es ist keine gute Praxis, ein Passwort im Klartext zu speichern.

Beide setzen Sie einem erheblichen Risiko aus und sollten nach Möglichkeit geändert werden. Sie sollten zumindest ernsthaft abschätzen, wie hoch die Kosten für diese Änderungen sein würden. Wenn es sich um eine externe Abhängigkeit handelt, die Sie nicht ändern können, sollten Sie dies als Anliegen für jeden betrachten, der über diese Befugnis verfügt.

In der realen Welt ist es jedoch möglicherweise nicht möglich, dies zu ändern. Unter der Annahme, dass das, was Sie tun, legal ist, müssen Sie möglicherweise (zumindest vorübergehend) mit dieser Vereinbarung leben.

Wenn dies wirklich notwendig ist, müssen Sie nur die Festplattenverschlüsselung durchführen.

Angesichts der Risiken müssen Sie die beste verfügbare Sicherheitsoption verwenden, und das ist es. Wenn es einen Performance-Hit gibt, leben Sie damit. Die Arbeit mit sensiblen Daten ist mit Kosten verbunden.

Wenn ich Ihr Kunde wäre, wäre ich nicht beeindruckt, dass Sie sich entschieden haben, nicht die beste verfügbare Sicherheitsoption für meine Daten zu verwenden, da Ihre Laptops dadurch etwas langsamer wurden.

8
user82096

Sie geben nicht an, welche Datenbank und welche Umgebung.

Wenn Sie die integrierte Sicherheit verwenden können, kann auf die Datenbank nicht zugegriffen werden, ohne als dieser Benutzer angemeldet zu sein. Ja, wenn sich die Daten auf der Festplatte befinden, können sie gehackt werden, dies ist jedoch eine Verteidigung der ersten Ebene.

App.config lässt mich denken, dass dies ein .NET sein könnte. Legen Sie config in ein USB-Stick und lesen Sie es vom USB-Stick. Wenn das Laufwerk nicht vorhanden ist, geben Sie den Benutzer ein, der das Kennwort eingibt.

Gibt es eine Möglichkeit, das Passwort beim ersten Eingeben und Lesen durch alle im Speicher zu speichern? Wieder geben Sie nicht die Umgebung an. Speicherzugeordnete Dateien

Bei einigen TDE können Sie den Schlüssel auf einem separaten Gerät speichern, sodass sie den Schlüssel nur beim Starten des Datenbank-Servers bereitstellen.

1
paparazzo

Die Antwort von Corbin March ist ziemlich gut. Ich möchte nur ein zusätzliches Detail hinzufügen, dass Ihre Produktionsdatenbank im Allgemeinen zwei Datenklassen enthält: System-/Anwendungsmetadaten; und Client-Benutzerdaten/Transaktionsdaten. Letzteres sollte NIEMALS in einer Entwicklungsumgebung "wie sie ist" verwendet werden.

Es ist in der Tat sehr selten, dass Sie tatsächliche Produktionskundeninformationen benötigen, um mit ihnen zu entwickeln.

Wenn das Problem, das das OP hier beschreibt, jedoch Geschäftsgeheimnisdaten oder anderweitig hoch proprietäre Systemdaten umfasst, die keine Kundendaten enthalten, die von Entwicklern benötigt werden, muss der Sicherheitsansatz ein Schema beinhalten, das nicht vorhanden ist Das Datenbankkennwort wird irgendwo in einer Ressourcendatei im Klartext gespeichert. Es muss einen Mechanismus geben, um beispielsweise ein tägliches Kennwort neu zu generieren, das nicht auf der Festplatte gespeichert ist.

1
dwoz

Eine mögliche Option besteht darin, eine Kopie der Datenbank zu erstellen und diese Kopie mit einem Skript zu bereinigen, sodass Sie andere Daten als die tatsächlich in der Produktion befindlichen erhalten. Sie werden nicht die gleichen Daten wie die Produktion haben, aber Sie werden den gleichen Maßstab haben.

0
Jason Crosby