Wie kann ich verhindern, dass Programmierer von Benutzern eingegebene Daten erfassen?


10

Ich entwickle eine Webanwendung mit einem starken Fokus auf Sicherheit. Welche Maßnahmen können ergriffen werden, um zu verhindern, dass diejenigen, die an der Anwendung arbeiten (Programmierer, Datenbankadministratoren, Mitarbeiter der Qualitätssicherung), vom Benutzer eingegebene Werte erfassen, die gut geschützt sein sollten, wie z. B. Kennwörter, Sozialversicherungsnummern usw.?


3
Ich würde vorschlagen, dass Sie die Frage in: security.stackexchange.com/?as=1
NoChance

"Verhindern" ist ein sehr starkes Wort. Sie können schlechte Schauspieler nicht daran hindern , schlechte Dinge zu tun. Was Sie tun können , ist, grundlegende Sicherheitsprinzipien wie "geringste Privilegien", "Aufgabentrennung" und "implizite Verweigerung" zu lernen und anzuwenden, Dinge auf sichere Weise zu entwerfen und Mitarbeiter einzustellen, denen Sie vertrauen können. Haben Sie praktikable Pläne, um den Schaden zu mindern, wenn das Unvermeidliche schließlich eintritt.
Robert Harvey

Die Fachbegriffe für die Technologien, die Sie benötigen: Hashing und Verschlüsselung.
Robert Harvey

Antworten:


22

Das ist ganz einfach. Banken machen es die ganze Zeit.

Sie haben drei Gruppen von Personen beteiligt. Dies sind Sicherheitsgruppen. Mit eindeutigen Berechtigungen.

Entwickler können keine Sicherheitsberechtigungen zuweisen und keine Produktionsdaten anzeigen.

Bediener können keine Sicherheitsberechtigungen zuweisen und keine Software erstellen.

Sicherheitsleute, die die Berechtigungen festlegen und weder Software erstellen noch die Software bedienen können.

Die Entwickler erstellen Software. Die Bediener installieren und betreiben es. Die Sicherheitsleute versichern, dass die beiden Gruppen getrennt bleiben.


8
OK, aber ein Entwickler könnte dem System noch etwas hinzufügen, das Produktionsdaten per E-Mail an sein privates Konto sendet. oder schreibt Produktionsdaten auf einen Server, auf dem er sie abholt. Ich denke, der einzige Weg, dies zu umgehen, ist ein strenges Code-Review-Regime.
Dawood ibn Kareem

3
Es gibt immer das Maß an Vertrauen, das den Mitarbeitern entgegengebracht wird. Jemand muss die Schlüssel zum Palast haben, und wenn Sie nicht darauf vertrauen können, dass sie die Macht verstehen, die ihnen gegeben wird, sollten wir diese Schlüssel vielleicht gar nicht erst dieser Person geben.
Chris

1
Ja, aber Schlüssel zu haben, für die mehr als eine Person erforderlich ist (wie das Code-Überprüfungsregime), bedeutet, dass Sie zwei benötigen, um "in die Irre" zu gehen, bevor Sie kompromittiert werden. Dies ist weniger wahrscheinlich als "nur ein" Mitarbeiter, der in die Irre geht und den Schlüssel missbraucht Sie. Es geht darum, das Vertrauen und die Folgen des Missbrauchs dieses Vertrauens in Einklang zu bringen. Und vergessen Sie nicht, dass sich Menschen und Umstände ändern. Eine Person, die vertrauenswürdig ist, wenn die Schlüssel gegeben werden, kann Dinge im Leben passieren lassen, durch die sie weniger vertrauenswürdig wird ...
Marjan Venema

1
@EmmadKareem: Richtig. Die Sicherheitsperson legt Gruppen und Kennwörter fest und setzt sie zurück, kann jedoch keine Daten sehen. Nur Bediener können reale Daten sehen. Stellen Sie sich Daten wie das tatsächliche Geld vor, mit dem die tatsächlichen Kassierer umgehen. Programmierer berühren das Geld nicht; nur Erzähler dazu. Ebenso berühren Sicherheitsleute kein Geld; Nur Kassierer berühren Geld.
S.Lott

1
@EmmadKareem: DBAs sind keine Entwickler. Es gibt zwei Gruppen: Sicherheit und Daten. Daten-Datenbankadministratoren sind ein besonderer Bestandteil von "Operationen". Sie sollten nicht berechtigt sein, die Sicherheit zu ändern. Sie können keinen Code schreiben. Sie sehen jedoch Daten und müssen wie Operatoren und nicht wie Entwickler behandelt werden.
S.Lott

2

Die Programmierer haben keinen Zugriff auf die Produktionsserver. Aber jemand muss Zugang haben. Daran führt kein Weg vorbei. Und es besteht immer die Möglichkeit, dass jemand verrückt wird und seinen Zugang missbraucht.

Daten, die gehasht / gesalzen sind, sind theoretisch sicher, selbst für die Personen, die vollen Zugriff haben, um sie anzuzeigen. Die meisten Daten sind jedoch nicht für das Hashing geeignet.

Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.