Verschlüsseln von Verbindungszeichenfolgen, sodass andere Devs nicht entschlüsseln können, aber App immer noch Zugriff hat

Question

Ich habe eine Datenbank, auf die ich über eine .NET-Webanwendung zugreifen möchte. Ich kann die Verbindungszeichenfolge in web.config leicht genug verschlüsseln, aber jeder Entwickler mit Zugriff auf die Box kann es mit ein paar Zeilen Code entschlüsseln - sie haben Zugriff auf die Box, also haben Sie Zugriff auf den in der Maschine gespeicherten Verschlüsselungsschlüssel. Konfig.

Während ich Leute aus der Datenbank sperren kann, indem ich ihren Benutzerkonten den Zugriff verweigere, hilft es nicht, dass die Webanwendung die sprichwörtlichen Schlüssel zum Königreich hat. Wer kennt eine gute Möglichkeit, der Web-App den Zugriff auf die Datenbank zu ermöglichen, ohne dass das SQL-Konto der Web-App für clevere Entwickler verfügbar ist?

Answer 1

Dies ist ein Huhn und Ei Problem. Wenn Ihre Anwendung Zugriff auf das Geheimnis (den Schlüssel zum Verschlüsseln der Verbindungszeichenfolge) hat, hat dies auch jeder Benutzer, der dieselben Rechte wie Ihre Anwendung hat.

Die beste Möglichkeit, dies zu verwalten, ist, kein Geheimnis zu haben und nicht login/pwd in der SQL Server-Verbindungszeichenfolge zu verwenden, sondern integrierte Sicherheit (SSPI) zu verwenden. Auf diese Weise authentifiziert sich Ihre Anwendung bei der Datenbank mit ihren Windows-Anmeldeinformationen (dem Konto, in dessen Namen Ihre Anwendung ausgeführt wird), ohne dass Anmeldeinformationen gesendet werden (bei der regulären Authentifizierung wird bei jedem Öffnen login/pwd zwischen Anwendung und Datenbank übergeben) eine Verbindung) und Sie müssen kein Passwort speichern. Sie müssen nur sicherstellen, dass das Passwort für das laufende Konto nicht leicht zu erraten ist. Danach sind Sie genauso sicher wie der Account sicher ist (worüber man nichts schreiben kann, aber es ist viel besser, als wenn die Anmeldeinformationen zwischen den Prozessen weitergegeben werden).

Beachten Sie, dass alles, das mit denselben Anmeldeinformationen (Code in Ihrer Anwendung) ausgeführt wird, auch mit den Rechten des Dienstkontos ausgeführt wird.

Sie sollten auch die Dinge beschränken, die das Anwendungskonto in der DB tun kann, auf das notwendige Minimum (no admin/dbo).

Answer 2

Wenn ich weiß, wie ein Programm Daten verschlüsselt, und ich weiß, wo sind die Schlüssel, dann kann ich Daten entschlüsseln. ("I" == jeder Entwickler)

Der Schutz der Schlüssel (Unix-Berechtigungen, Windows-ACLs) kann die meisten von ihnen stoppen, aber man kann einfach immer eine Zeile zum Programm hinzufügen, die die Schlüssel (oder nur die unverschlüsselten Daten) an einen geheimen Ort. (Oder ändern Sie die Verschlüsselungsbefehle in ähnlich aussehende, die eigentlich ein einfaches XOR oder gleichwertig sind ...)

Abschließend, wenn ich die Kontrolle über den Quellcode habe, kann ich das Programm etwas tun.

Answer 3

Wenn Sie wirklich glauben, dass Ihre Entwickler ein ernsthaftes Sicherheitsrisiko in dem Sinne darstellen, wie Sie in dieser Frage darstellen, sollten Sie sie sofort FEUER BRAUCHEN und Entwickler einstellen, denen Sie letztendlich vertrauen können.

Ein Entwickler, dem die Schlüssel zu Ihren DBs nicht vertraut werden können, sollte auch nicht mit der Codebasis vertraut werden.

Seitennotiz Was sie von DEL * hält. * auf Ihrem Dateisystem?

Answer 4

Obwohl ich denke, dass Sie eine ganz andere Reihe von Problemen auf Ihren Händen haben können, wenn Sie Ihren Entwicklern nicht vertrauen können, können Sie aspnet_setreg ausprobieren, um zu sehen, ob es helfen könnte.

Oder Sie könnten nur nicht versierte Entwickler einstellen. :)

Answer 5

Sie könnten dies in die falsche Richtung sehen.

In einer Hochsicherheitssituation sollten Entwickler (genau wie alle anderen) keinen Zugriff auf die Produktionsdatenbank haben. Sie können dies mit Firewalls oder was auch immer bewirken.

Wenn Sie SSPI verwenden, wie Yann Schwartz erwähnt, können nur die Produktions-Webserver in die Datenbank gelangen. Wenn dies nicht möglich ist, sollte der Systemadministrator das (verschlüsselte) Kennwort in der Datei web.config zum Zeitpunkt der Bereitstellung manuell eingeben.

Es ist selbstverständlich (oder zumindest sollte es), dass Sie eine separate Datenbank mit unterschiedlicher Authentifizierung für Entwicklung/QA haben sollten.

Answer 6

Die Antwort hier beantwortet die Frage nicht.

Es gibt viele Gründe, warum man die Werte von Konfigurationsdateien verschlüsseln möchte. So stellen Sie sicher, dass die Box bei einer Kompromittierung nicht die Datenbankserver-Box beeinträchtigt.

Wenn diese Datenbank ist etwas anderes als SQL-Server wie Oracle oder Sybase, dann wird die obige Lösung nicht funktionieren.

Es gibt viele Verbindungen in Encrypting Web.Config Values in ASP.NET 2.0 dieses Problem zu lösen: