Wie die Identität einer Person aus seinen persönlichen Daten zu trennen?

https://stackoverflow.com/questions/3691348

02-10-2019
|

Frage

Ich schreibe eine App, den Hauptzweck ist die Liste der Benutzer zu halten Einkäufe.

Ich möchte, dass, um sicherzustellen, selbst ich als Entwickler (oder jemand mit voller Zugriff auf die Datenbank) konnte nicht herausfinden, wie viel Geld ein bestimmte Person ausgegeben hat oder was er gekauft hat.

Ich kam zunächst mit dem folgenden Schema auf:

    --------------+------------+-----------
    user_hash     | item       | price
    --------------+------------+-----------
    a45cd654fe810 | Strip club |     400.00
    a45cd654fe810 | Ferrari    | 1510800.00
    54da2241211c2 | Beer       |       5.00
    54da2241211c2 | iPhone     |     399.00

Benutzer meldet sich mit Benutzernamen und Passwort ein.
Aus dem Passwort berechnen user_hash (ggf. mit Salzen usw.).
Verwenden Sie die Hash-Access-Benutzer Daten mit normalen SQL-Abfragen.

Mit genügend Anwender, sollte es fast unmöglich sein, viel zu sagen, wie Geld ein bestimmte Benutzer hat verbringt nur durch seinen Namen zu kennen.

Ist das eine vernünftige Sache zu tun, oder bin ich ganz dumm?

Lösung

Das Problem ist, dass, wenn jemand bereits vollen Zugriff auf die Datenbank hat, dann ist es nur eine Frage der Zeit, bevor sie die Datensätze auf bestimmte Menschen verbinden. Irgendwo in Ihrer Datenbank (oder in der Anwendung selbst) erhalten Sie die Beziehung zwischen dem Benutzer und den Elementen zu machen. Wenn jemand vollen Zugriff hat, dann werden sie den Zugang zu diesem Mechanismus haben.

Es gibt absolut keine Möglichkeit, dies zu verhindern.

Die Realität ist, dass durch vollen Zugriff haben wir in der Lage, von Vertrauen sind. Dies bedeutet, dass das Unternehmen Manager Vertrauen haben, dass, obwohl Sie die Daten sehen können, können sie nicht in irgendeiner Art und Weise handeln. Dies ist, wo kleine Dinge wie Ethik ins Spiel kommen.

Nun, das sagte, trennen viele Unternehmen die Entwicklung und Produktion Personal. Der Zweck ist, Entwicklung zu entfernen, von einem direkten Kontakt mit lebenden (dh: real) Daten. Dies hat eine Reihe von Vorteilen mit der Sicherheit und Zuverlässigkeit der Daten an der Spitze des Haufens zu sein.

Der einzige wirkliche Nachteil ist, dass einige Entwickler glauben, sie können ein Problem nicht ohne Produktionszugriff beheben. Dies ist jedoch einfach nicht wahr.

Mitarbeiter in der Produktion dann wären die einzigen, die Zugang zu den Live-Servern. Sie werden in der Regel auf einen größeren Grad (Vorstrafen und andere Hintergrund-Kontrollen) überprüft werden, die commiserate mit der Art der Daten, die Sie haben zu schützen.

Der Punkt des Ganzen ist, dass dies ein Personalproblem; und nicht eine, die kann wirklich mit technischen Mitteln gelöst werden.

UPDATE

hier Andere scheinen einen sehr wichtigen und entscheidenden Teil des Puzzles zu fehlen. Das heißt, dass die Daten in das System wird aus einem Grund eingegeben. Dieser Grund ist fast universell, so dass sie gemeinsam genutzt werden kann. Im Fall einer Kostenabrechnung, werden diese Daten eingegeben, so dass die Rechnungslegung, die zurück zu zahlen wissen kann.

Das bedeutet, dass das System, auf einer bestimmten Ebene, werden ohne die Dateneingabe Benutzer und Elemente entsprechen Person müssen. (Dh: ein Verkäufer) angemeldet werden

Und weil diese Daten gebunden werden muss, zusammen, ohne alle Beteiligten stehen dort in einem Sicherheitscode auf „Freigabe“ die Daten, dann ein DBA absolut in der Lage geben Sie die Abfrage-Logs zu überprüfen, um herauszufinden, wer wer ist. Und sehr leicht möchte ich hinzufügen, unabhängig davon, wie viele Hash-Zeichen Sie in sie werfen wollen. Triple-DAS wird nicht speichern Sie entweder.

Am Ende des Tages alles getan, was Sie haben, ist make Entwicklung härter mit absolut null Sicherheit profitieren. Ich kann gar nicht genug betonen dieses genug: der einzige Weg zu verbergen Daten von einem dba für beide 1 sein würde, dass die Daten auf nur durch die sehr Person zugänglich sein, die es eingegeben oder 2. für sie nicht gibt es in dem ersten Platz.

In Bezug auf die Option 1, wenn die einzige Person, die jemals zugreifen kann es die Person, die er eingegeben .. na ja, es hat keinen Sinn für sie in einer Unternehmensdatenbank sein.

Andere Tipps

Ich habe Angst, dass, wenn Ihre Anwendung eine Person, seine Daten verknüpfen kann, jeder Entwickler / Administrator kann.

Das einzige, was Sie tun können, ist es schwieriger macht den Link zu tun, um den Entwickler / admin zu verlangsamen, aber wenn Sie es schwieriger, Link-Nutzer Daten machen, werden Sie es schwieriger zu für Ihren Server machen.

Idee basiert auf @No Idee:

Sie können eine klassische Benutzer / Passwort-Login zu Ihrer Anwendung (gehashte Passwort, oder was auch immer), und ein speziellen „pass“ verwendet, um Ihre Daten geheim zu halten. Dieses „passieren“ würde nicht in der Datenbank gespeichert werden.

Wenn Ihr Client-Protokoll in Ihrer Anwendung würde ich Benutzer / Passwort / Pass bereitzustellen. Der Benutzer / Passwort wird mit der Datenbank überprüft, und der Pass würde Lade- / Schreibdaten verwendet werden.

Wenn Sie zu Schreibdaten benötigen, machen Sie einen Hash Ihres „username / pass“ Paar, und speichern Sie es als Schlüssel Ihre Kunden, um Ihre Daten zu verknüpfen.

Wenn Sie zum Laden von Daten benötigen, machen Sie einen Hash Ihrer „username / pass“ Paar, und laden Sie diese Hash alle Daten übereinstimmen.

Auf diese Weise ist es unmöglich, eine Verbindung zwischen Ihren Daten und dem Benutzer zu machen.

In einer anderen Hand (wie ich in einem Kommentar zu @No sagte) Vorsicht vor Kollisionen . Plus, wenn Ihre Benutzer Schreib eine schlechte „pass“ Sie können es nicht überprüfen.

Update:. Für den letzten Teil, ich hatte eine andere Idee, können Sie in Ihrer Datenbank speichern, einen Hash Ihres „Pass / Passwort“ Paar, auf diese Weise können Sie überprüfen, ob Ihr „Pass“ in Ordnung ist,

Erstellen Sie eine Benutzer-Tabelle mit:
1. user_id: eine Identitätsspalte (automatisch generiert id)
2. username
3. Kennwort: sicherstellen, dass es gehasht
Erstellen Sie eine Produkttabelle wie in Ihrem Beispiel:
1. user_hash
2. Element
3. Preis

Die user_hash wird aus der Basis User_id werden, die sich nie ändert. Benutzername und Passwort ist zu ändern frei nach Bedarf. Wenn sich der Benutzer anmeldet, Sie Benutzername / Passwort vergleichen Sie die user_id zu bekommen. Sie können für die Dauer der Sitzung oder einer verschlüsselten / indirekte Version des Hash (könnte eine Session-ID, wo speichert der Server die user_hash in der Sitzung).

die user_hash zurück an den Client senden

Nun müssen Sie einen Weg, um Hash das user_id in user_hash und halten Sie sie geschützt.

Wenn Sie es clientseitige tun, wie @No vorgeschlagen, muss der Client User_id haben. Große Sicherheitslücke (vor allem, wenn es ein Web-App) kann Hash leicht manipuliert werden und Algorithmus ist frei für die Öffentlichkeit zur Verfügung.
könnten Sie haben es als eine Funktion in der Datenbank. Schlechte Idee, da die Datenbank alle Stücke hat die Datensätze zu verbinden.
Für Web-Sites oder Client / Server-Anwendungen Sie es auf Ihrem serverseitigen Code haben könnten. Viel besser, aber dann ein Entwickler hat Zugang zu dem Hashing-Algorithmus und Daten.
Haben Sie eine andere Entwickler schreiben die Hashing-Algorithmus (die Sie haben keinen Zugriff auf) und Stick auf einem anderen Server als TCP / Web-Service (die Sie nicht auch den Zugang haben). Ihre serverseitigen Code würde dann passieren die Benutzer-ID und einen Hash zurück. Sie würden den Algorithmus nicht haben, aber Sie können wieder alle die Benutzer-IDs bis hin zu bekommen alle ihre Hashes senden. Nicht viele Vorteile # 3, obwohl der Dienst Protokollierung haben könnte und so zu versuchen, das Risiko zu minimieren.
Wenn es einfach eine Client-Datenbank-Anwendung, Sie nur die Wahl haben # 1 und 2. würde ich dringend eine andere schlagen vor, das Hinzufügen [Business] Schicht, die Server-Seite ist, getrennt von dem Datenbankserver.

Edit: Dies überlappt einige der vorherigen Punkte. Habe 3-Server:

Authentication Server : Mitarbeiter Ein Zugriff hat. Behält Benutzertabelle. Hat Web-Service (mit verschlüsselter Kommunikation), die Benutzer / Passwort-Kombination nimmt. Hashes Passwort, sieht user_id in der Tabelle nach oben, erzeugt user_hash. Auf diese Weise kann man nicht einfach alle benutzerkennungen senden und die Hashes zurück. Sie haben das Passwort haben, die nicht überall gespeichert und ist nur während des Authentifizierungsprozesses zur Verfügung.
Hauptdatenbankserver : Mitarbeiter B Zugriff hat. Nur Stores user_hash. Kein Benutzer-ID, keine Passwörter. Sie können die Daten verknüpfen die user_hash verwenden, aber die tatsächliche Benutzer-Info ist woanders.
Website-Server : Mitarbeiter B Zugriff hat. Ruft Login-Infos, geht auf Authentifizierungs-Server, bekommt Hash zurück, dann Login-Info verfügt. Hält Hash in der Sitzung für das Schreiben / Abfragen auf die Datenbank.

So Mitarbeiter A hat user_id, Benutzername, Passwort und Algorithmus. Mitarbeiter B hat user_hash und Daten. Es sei denn, ein Mitarbeiter von B ändert die Webseite des rohen Benutzer / Passwort zu speichern, hat er keine Möglichkeit, auf die realen Benutzer zu verknüpfen.

Mit SQL Profilierung würde Mitarbeiter A erhalten user_id, Benutzername und Passwort-Hash (seit user_hash später im Code generiert wird). Mitarbeiter B würde user_hash und Daten.

Der einzige Weg, um sicherzustellen, dass die Daten nicht an der Person verbunden werden, gehört es ist nicht die Identitätsinformationen an erster Stelle (make alles anonym) aufzeichnen. Dadurch würde jedoch höchstwahrscheinlich Ihre App sinnlos machen. Sie können dies schwieriger zu tun, aber man kann es nicht unmöglich machen.

Speichern von Benutzerdaten und Identifizierungsinformationen in getrennten Datenbanken (und möglicherweise auf separaten Servern) und die Verknüpfung der beiden mit einer ID-Nummer ist wahrscheinlich die nächste Sache, die Sie tun können. Auf diese Weise haben Sie die beiden Datensätze so viel wie möglich isoliert. Sie müssen nach wie vor, dass die ID-Nummer als Bindeglied zwischen ihnen halten; sonst wäre es nicht möglich die Daten eines Benutzers abgerufen werden.

Darüber hinaus würde ich nicht empfehlen, ein Hash-Passwort als eindeutige Kennung verwenden. Wenn ein Benutzer sein Passwort ändert, würden Sie dann gehen, um durch und alle Ihre Datenbanken zu aktualisieren, um den alten Hash-Passwort-IDs mit den neuen zu ersetzen. Es ist in der Regel viel einfacher, eine eindeutige ID zu verwenden, die nicht auf einem der die Informationen des Benutzers basiert (um sicherzustellen, dass es statisch bleiben wird).

Dies endet mit einem sozialen Problem ist, kein technisches Problem. Die besten Lösungen werden eine soziale Lösung sein. Nach dem Aushärten Ihrer Systeme zum Schutz vor unberechtigtem Zugriff (Hacker, etc.), werden Sie wahrscheinlich in Bezug auf die Datensicherheit bessere Laufleistung arbeiten Vertrauen mit Ihren Benutzern auf den Aufbau und die Implementierung eines Systems von Richtlinien und Verfahren erhalten. Geben Sie spezifische Strafen für Mitarbeiter, die Kundeninformationen missbrauchen. Da eine einzige Verletzung von Kundenvertrauen genug, um Ihren Ruf zu ruinieren und entfernt alle Benutzer fahren, die Versuchung, von denen diese Daten missbräuchlich mit „Top-Level“ Zugang ist weniger, als Sie (seit dem Zusammenbruch des Unternehmens könnten denken, in der Regel schwerer wiegt als jede Verstärkung).

Beachten Sie, dass auch ohne tatsächlich die Person identifizierende Informationen überall zu speichern, nur genügend Informationen, alle mit dem gleichen Schlüssel assoziieren lassen könnten Sie die Identität der Person, mit bestimmten Informationen verknüpft, um herauszufinden. Für ein einfaches Beispiel, könnten Sie den Strip-Club anrufen und fragen, welcher Kunde einen Ferrari fuhr.

Aus diesem Grunde, wenn Sie de-Identifizierung medizinische Aufzeichnungen (für den Einsatz in Forschung und so weiter), haben Sie die Geburtstage für Menschen über 89 Jahre alt ist (weil die Leute zu entfernen, dass alte selten genug, dass ein spezifisches birth zu einem Punkt könnte Einzelperson) und entfernen Sie die geografische Codierung, die angibt, einen Bereich, weniger als 20.000 Menschen enthält. (Siehe http://privacy.med.miami.edu/glossary/xd_deidentified_health_info.htm )

gefunden AOL auf die harte Tour, wenn sie Daten abrufen freigegeben, dass die Menschen durch das Wissen nur identifiziert werden können, was sucht mit einer anonymen Person zugeordnet ist. (Siehe http://www.fi. muni.cz/kd/events/cikhaj-2007-jan/slides/kumpost.pdf )

Es scheint, als ob du Recht mit diesem auf dem richtigen Weg, aber Sie denken nur darüber (oder ich es einfach nicht verstehen)

Schreiben Sie eine Funktion, die eine neue Zeichenfolge basierend auf dem Eingangs aufbaut (die ihren Benutzernamen oder wird etwas anderes, das kann nicht ändern Überstunden)

Mit dem zurückgegebenen String als Salz beim Erstellen des Benutzer-Hash (wieder würde ich die Benutzer-ID oder Benutzername als Input für die Hash-Builder verwenden, da sie wie das Passwort des Benutzers ändern würden nicht oder E-Mail)

Verknüpfen Sie alle Benutzeraktionen mit dem Benutzer-Hash.

Niemand mit nur Zugriff auf die Datenbank kann bestimmen, was zum Teufel der Benutzer mittlere Hashes. Auch ein Versuch, Brute es, indem Sie versuchen verschiedene Samen zu zwingen, Salzkombinationen nutzlos am Ende wird, weil das Salz als eine Variante des Benutzernamens bestimmt wird.

Ich glaube, Sie Sie eigene Frage mit Ihrem ersten Post beantwortet haben.

Eigentlich ist es eine Möglichkeit, Sie könnte möglicherweise tun, was du redest ...

könnten Sie haben den Benutzer seinen Namen und das Passwort in ein Formular eingeben, das einen rein clientseitige Skript ausgeführt wird, die einen Hash basierend auf den Namen erzeugt und pw. Das Hash als eine eindeutige ID für den Benutzer verwendet wird, und wird an den Server gesendet. Auf diese Weise der Server kennt nur den Benutzer durch Hash, nicht mit Namen.

Damit dies funktioniert, obwohl, würde der Hash anders sein muß, aus dem normalen Passwort-Hash, und der Benutzer erforderlich wäre ihr Name / Passwort ein weiteres Mal eingeben, bevor der Server jedes ‚Gedächtnis‘ haben würde, was das Person gekauft.

Der Server konnte sich daran erinnern, was die Person für die Dauer ihrer Sitzung gekauft und dann ‚vergessen‘, da die Datenbank keine Verbindung zwischen den Benutzerkonten und die sensible Informationen enthalten würde.

Bearbeiten

Als Antwort auf diejenigen, die auf dem Client sagen Hashing ist ein Sicherheitsrisiko: Es ist nicht, wenn man es richtig macht. Es sollte davon ausgegangen werden, dass ein Hash-Algorithmus bekannt ist oder bekannt sein kann. Zu sagen, sonst beträgt „Sicherheit durch Unklarheit.“ Hashing keine privaten Schlüssel beinhaltet und dynamische Hash-Werte verwendet werden könnten, um zu verhindern Manipulationen.

Zum Beispiel, nehmen Sie einen Hash-Generator wie folgt aus:

http://baagoe.com/en/RandomMusings/javascript/Mash.js

// From http://baagoe.com/en/RandomMusings/javascript/
// Johannes Baagoe <baagoe@baagoe.com>, 2010
function Mash() {
  var n = 0xefc8249d;

  var mash = function(data) {
    data = data.toString();
    for (var i = 0; i < data.length; i++) {
      n += data.charCodeAt(i);
      var h = 0.02519603282416938 * n;
      n = h >>> 0;
      h -= n;
      h *= n;
      n = h >>> 0;
      h -= n;
      n += h * 0x100000000; // 2^32
    }
    return (n >>> 0) * 2.3283064365386963e-10; // 2^-32
  };

  mash.version = 'Mash 0.9';
  return mash;
}

Sehen Sie, wie n Änderungen, jedes Mal, wenn Sie einen String Hash erhalten Sie etwas anderes.

Hash der Benutzername + Passwort ein normales Hash algo verwenden. Dies wird das gleiche wie die Schlüssel der ‚geheimen‘ Tabelle in der Datenbank sein, wird aber nichts anderes in der Datenbank übereinstimmen.
Fügen Sie den Hash-Pass auf den Benutzernamen und das Hash es mit dem obigen Algorithmus.
Basis-16 kodieren var n und Anfügen es in dem ursprünglichen Hash mit einem Begrenzungszeichen.

Dies wird eine erstellen eindeutige Hash (wird anders sein, jedes Mal), die durch das System gegen jede Spalte in der Datenbank überprüft werden kann. Das System kann eingerichtet werden nur einmal einem bestimmten eindeutigen Hash erlauben wird (etwa einmal pro Jahr), MITM-Angriffe zu verhindern, und keine der Informationen des Benutzers wird über den Draht geführt. Es sei denn, ich etwas fehle, gibt es nichts unsicher darüber.

Lizenziert unter: CC-BY-SA mit Zuschreibung

Nicht verbunden mit StackOverflow