Wie schützt man ein System von innen (wie im Job)?

Question

Ich habe eine Anwendung in einem beliebten Webhosting-Dienst bereitgestellt. Da sie über Administratorrechte für ihre Computer verfügen, ist es für mich dringend erforderlich, meine Daten über alle Ebenen einschließlich der Datenbank selbst zu schützen.

In der Datenbank denke ich über die Verschlüsselung von sensiblen Informationen wie Benutzernamen und E-Mails, und möglicherweise ihre Telefonnummern usw. Die Repository-Schicht wird alle Anforderungen für die Codierung/Decodierung behandeln.

Ich habe drei DLLs: 1) die Anwendungsschicht (Controller und Ansichten), 2) Business-Schicht (Service-Logik) und 3) Datenschicht (Repository).

Normalerweise werden Benutzer von außen eine Seite anfordern und wenn sie noch nicht authentifiziert sind, werden sie auf die Anmeldeseite umgeleitet, typische Form-Authentifizierungs-Sachen. Das schützt das System vor unberechtigten Benutzern von außen.

Im Inneren können diese DLLs jedoch technisch in jede .NET-Anwendung importiert werden. In diesem Fall kann diese Anwendung direkten Zugriff auf die internen Abläufe des Systems haben.

Answer 1

Wenn die Daten auf einem Computer gehostet werden, auf den ein anderer Benutzer Administratorzugriff hat, können Sie Ihre Daten letztendlich nicht schützen und haben dennoch Zugriff darauf. Jede Verschlüsselung, die Sie verwenden, basiert auf einem Geheimnis, aber Sie müssen das Geheimnis auf der Box speichern, zu welchem ​​Zeitpunkt die Besitzer der Box Zugriff darauf haben werden.

Das funktioniert nur, wenn Ihre Benutzer ihre Daten vor dem Hochladen lokal verschlüsselt haben und der Server dann dieselben verschlüsselten Daten an sie zurückgeschickt hat. Aber zu diesem Zeitpunkt hätten Sie am Serverende keine Möglichkeit, etwas mit diesen Daten zu tun.

Sie müssen sich auf an dem Server-Anbieter der Politik schauen, was sie mit den Daten speichern Sie ihre Server auf und fragen:

1. Haben sie garantieren nicht auf den Daten suchen?
2. Vertrauen Sie diesen Richtlinien?
3. Vertrauen Sie darauf, dass sie ihre Server vor Angriffen schützen können?
4. Werden sie ihre Daten aus rechtlichen Gründen an jemand anderen abgeben müssen, trotz ihrer Politik? Zum Beispiel können verschiedene Regierungen Unternehmen dazu bringen, Daten offenzulegen.

Sie können dann die Risiken abwägen und entscheiden, ob:

1. Sie sind zufrieden mit den Risiken und wollen immer noch mit ihnen sensible Daten zu speichern.
2. Ob Ihre Benutzer mit den Risiken zufrieden sind - Sie müssen Ihre eigenen Datenschutzrichtlinien und Risiken klar kommunizieren, damit sie eine informierte Entscheidung treffen können.

Denken Sie auch darüber nach, ob Sie alle diese Informationen speichern müssen. Warum brauchst du Telefonnummern? Wenn Sie zum Beispiel Zahlungen abwickeln möchten, können Sie das alles an einen vertrauenswürdigen Dritten weitergeben, zum Beispiel Visa oder Paypal. Dann können sie sich damit befassen, die Daten Ihrer Nutzer sicher zu speichern, und Sie müssen nicht mit dem Risiko umgehen.

Answer 2

Eine gute Vorgehensweise besteht darin, Kennwörter in der Datenbank nicht zu verschlüsseln und zu speichern.Sie sollten sie mit einem zufälligen Salt-Hash (verwenden Sie die kryptografische RandomNumberGenerator-Klasse, nicht die mathematische Random-Klasse) gegen Rainbow-Table-Angriffe und nur die Hashes und Salze speichern. Wer diesen Tisch ergreift, wird es immer noch schwer haben, sich als legitimer Benutzer auszugeben. Denken Sie nicht einmal daran, Kreditkartendaten zu speichern, wenn Sie dem DBA nicht vertrauen können. Einige Web-Services ermöglichen es, dass die Zahlung funktioniert, ohne dass Sie jemals vernünftige Anmeldeinformationen wie PayPal-Umleitung und Ähnliches erhalten. Andere sensible Daten (E-Mails) sollten mit anderen Daten auf Benutzerebene wie dem Benutzernamen und einem konstanten Salt wie folgt verschlüsselt werden: "example@email.com+username+AayRUIOH283uID".

All dies sind nur kleine Dinge, die Ihr Leben sehr erschweren, aber auch das Leben eines nicht vertrauenswürdigen Administrators. Ziehen Sie auch in Betracht, Intranetverbindungen nur von Ihrem eigenen Cloud-Cluster (vertrauenswürdige IP-Tabelle) zu akzeptieren, SSL sogar zwischen Ihren eigenen Knoten zu verwenden und Assemblydateien mit asymmetrischen Schlüsseln zu signieren, sodass eine DLL nicht ersetzt werden kann.

Dennoch ist ALLES ein großer Aufwand an Zeit und Aufwand für einen fragwürdigen Sicherheitsvorteil. Wie bei allen Aspekten ist Sicherheit kein Merkmal eines Systems, sondern ein Kompromiss von Kosten/Nutzen.

Die beste Option ist, keine ominösen Entscheidungen zu treffen, sondern alternative, weniger riskante Lösungen zu finden (wie NICHT, die Passwörter speichern). Und denken Sie daran, dass es Tools zum Manipulieren von Binärdateien (DLL) gibt, um freigegebenen MSIML-Code (kompiliertes .NET wie C# auch ohne Debugsymbol-Tabellen) und Tools zum Manipulieren des Speichers während der Ausführung der App zu inspizieren. Es gibt Techniken, um Speichermanipulation sehr kostspielig zu machen, wie nicht sensible Daten (wie Passwörter) in Strings zu speichern, sondern sie in einem einzelnen Zeichen an einem gepinnten Speicherort zu streamen und jedes Mal das gleiche Zeichen zu überschreiben, um den Hash an Ort und Stelle zu rekombinieren "on the fly" mit einem inkrementellen Hash-Algorithmus (SHA-256 wäre gut).

Dennoch kann man sich nicht wirklich vor allen Arten von Angriffen schützen, wenn ein Admin nicht vertrauenswürdig ist. Er wird immer in der Lage sein, Ihre Maschine physisch auszuschalten und nach Hause zu bringen, um Spaß in seinem Keller zu haben ...