it-swarm.com.de

Keine zentrale Datenbank

Ich habe einen Kunden, der eine Website/mobile Apps/Desktop-Apps erstellen möchte, die mit sehr sensiblen Daten umgehen (sensibler als Bank-/Kartendaten). Aufgrund der Vertraulichkeit der Daten möchten sie diese nicht in einer zentralen Datenbank speichern, möchten jedoch, dass ihre Apps synchronisiert werden (sagen wir, ich füge meiner mobilen App einige Daten hinzu und möchte dann zu meiner gehen können Desktop-App und sehen die gleichen Daten).

Ich kann mir keinen netten, zuverlässigen Weg vorstellen, und ich bin mir nicht sicher, ob es einen gibt. Deshalb bin ich hier. Weiß jemand, wie ich mit diesen Daten umgehen kann?

Eine Lösung, über die ich nachgedacht habe, war, auf jeder App eine clientseitige Datenbank zu haben, die sich irgendwie zwischen Apps synchronisieren lässt. Ich kann jedoch sehen, dass dies sehr unzuverlässig ist und unordentlich wird.

31
user2424495

Viele vertrauliche Informationen werden in Datenbanken gespeichert. In der Tat ist eine zentrale Datenbank wahrscheinlich die sicherste Möglichkeit, diese Daten zu speichern. Große Unternehmensdatenbanken verfügen über eine Vielzahl von Funktionen, mit denen beispielsweise vertrauliche Informationen verschlüsselt, geprüft werden können, wer darauf zugreift, um Personen, einschließlich Datenbankadministratoren, die Anzeige der Daten einzuschränken oder zu verhindern usw. Professionelle Sicherheitsexperten überwachen die Umgebung und professionelle Datenbankadministratoren überwachen die Sicherungen dass Sie keine Daten verlieren. Es wäre mit ziemlicher Sicherheit viel einfacher, auf dem Mobilgerät oder Laptop eines zufälligen Benutzers gespeicherte Daten zu kompromittieren, als in eine gut gestaltete Sicherheitsinfrastruktur einzudringen und eine ordnungsgemäße zentrale Datenbank zu kompromittieren.

Sie können das System mit einer zentralen Datenbank entwerfen, in der nur verschlüsselte Daten und der private Schlüssel des Benutzers auf dem Gerät des Benutzers gespeichert werden. Auf diese Weise können die Daten nur vom Benutzer verwendet werden, selbst wenn die zentrale Datenbank vollständig gefährdet ist. Das bedeutet natürlich, dass Sie die Daten des Benutzers nicht wiederherstellen können, wenn er seinen Schlüssel verliert (sagen wir, die einzige Kopie befand sich auf seinem Telefon und sein Telefon wurde beschädigt). Und wenn jemand den Schlüssel und vermutlich seine Anmeldeinformationen kompromittiert, kann er die Daten sehen.

60
Justin Cave

Sie müssen ein paar Schritte sichern und in Absprache mit Ihrem Kunden ein Bedrohungsmodell ausarbeiten. (Ja, das ist ein Link zu einem 600-seitigen Buch. Ja, ich empfehle Ihnen ernsthaft, das Ganze zu lesen.)

Ein Bedrohungsmodell beginnt mit Fragen wie

  • Warum muss die App diese vertraulichen Daten überhaupt speichern?
    • Können Sie es vermeiden, es überhaupt zu speichern?
    • Kann es nach kurzer Zeit weggeworfen werden?
    • Muss es wirklich für mehr als ein Gerät zugänglich sein?
    • Wenn es auf mehr als einem Gerät zugänglich sein muss, muss es auf mehr als einem Gerät gespeichert sein?
  • Wer sind die Personen, die die sensiblen Daten jedes Benutzers sehen dürfen?
    • Kann diese Liste kürzer gemacht werden?
  • Wer sind die Personen, die möglicherweise mit den sensiblen Daten jedes Benutzers in Kontakt kommen, während sie versuchen, ihre Arbeit zu erledigen, dies aber nicht wissen müssen?
    • Kann this Liste kürzer gemacht werden?
    • Können die Daten für sie unzugänglich gemacht werden, ohne ihre Fähigkeit zu beeinträchtigen, ihre Arbeit zu erledigen?
    • Wenn es nicht unzugänglich sein kann, kann es zumindest unverständlich gemacht werden? (Dies ist, was die Verschlüsselung abstrakt macht: Sie macht Daten unverständlich.)
  • Wer sind die Leute, die wollen die sensiblen Daten sehen, aber nicht dürfen?
    • Welche Möglichkeiten haben sie, um an die Daten zu gelangen?
    • Was wollen sie mit den Daten machen, wenn sie sie haben?
    • Wie wütend werden sie sein, wenn sie nicht bekommen, was sie wollen?
    • Wie viel Geld, Zeit, CPU-Zyklen und menschlichen Aufwand sind sie bereit, auszugeben?
    • Interessiert es sie, wenn jemand weiß die Daten gesehen hat?
    • Wollen sie auf bestimmte Benutzer sensible Daten zugreifen, oder wird dies jemand tun?
    • Was wissen sie schon?
    • Zu was haben sie bereits Zugang?

Sobald Sie die Antworten auf diese Fragen kennen, sind Sie an einem viel besseren Ort, um herauszufinden, was zu tun ist.

Beachten Sie, dass es möglicherweise mehr als eine Antwort auf jede Reihe von Fragen gibt, insbesondere auf diejenigen, die sich mit den Angreifern befassen (die Personen, die die vertraulichen Daten wollen, diese aber nicht haben dürfen). Wenn Sie sich nicht mindestens ein halbes Dutzend anders archetypische Angreifer mit unterschiedlichen Motivationen, Zielen und Ressourcen vorstellen können, haben Sie wahrscheinlich etwas verpasst.

Denken Sie auch daran, dass die Angreifer, die Sie (und/oder den Client) am meisten Probleme verursachen, am wahrscheinlichsten in den Medien für Furore sorgen, wenn ihr Angriff erfolgreich ist oder wer dies tut Die größte Menge an Aggregat Schaden sind wahrscheinlich nicht die Angreifer, die einzelnen Benutzern den größten Schaden zufügen können, wenn ihr Angriff erfolgreich ist. Das Unternehmen Ihres Kunden kümmert sich rational mehr um Gesamtschäden, aber die Benutzer kümmern sich rational mehr um sich selbst.

38
zwol

Eine Option für die Synchronisierung wäre Peer-to-Peer. Dies erfordert weiterhin einen zentralen Server, aber dieser Server verarbeitet keine der Daten.

Wenn ein Gerät online geht, erhält ein zentraler Server eine Benachrichtigung mit der Benutzer-ID. Wenn ein zweites Gerät desselben Benutzers online geht, sendet der Server beiden Geräten die IP-Adressen des anderen. Die Geräte können dann Daten direkt austauschen. Vorsichtsmaßnahme: Ein Gerät muss als Server fungieren, sodass sich mindestens eines nicht hinter einem NAT Router) befinden kann.

Vergessen Sie nicht, dass Sie sowohl für den Benachrichtigungsmechanismus als auch für den Peer-to-Peer-Austausch eine starke Authentifizierung und Verschlüsselung benötigen.

8
Philipp

Machen Sie es zum Problem eines anderen.

Speichern Sie die Daten lokal in jeder App und geben Sie den Benutzern die Möglichkeit, die Synchronisierung über ihr eigenes Konto mit einem Drittanbieter (Dropbox, Google Drive usw.) zu aktivieren. Denken Sie auch daran, alle Daten zu verschlüsseln, die auf den Dienst eines Drittanbieters hochgeladen wurden (dies hat Vor- und Nachteile).

Dies ergibt das Erscheinungsbild, dass Benutzer ihre eigenen Daten besitzen, da sie sich für die Datensynchronisation anmelden müssen. Dies macht die Apps nützlich für Personen, die keine Freigabe wünschen. Und es macht eine andere Person (technisch und möglicherweise rechtlich) für die anhaltenden Kopfschmerzen verantwortlich, die mit der Sicherheit gemeinsam genutzter Daten verbunden sind.

5
James Mason

Das Anliegen Ihres Kunden scheint die Sichtbarkeit dieser Daten zu sein. Die erste Frage, die Sie Ihrem Kunden stellen müssen, lautet: Wenn die Daten verschlüsselt wurden, wo können sie gespeichert werden? Fragen Sie dann Ihren Kunden, welche Arten von Zugriffskontrollen vorhanden sein sollen, bevor die Daten entschlüsselt und verarbeitet werden können. Wo kann der Entschlüsselungsschlüssel gespeichert werden? Ist ein separater Schlüssel pro Benutzer? usw...

Wenn Ihr Kunde nicht möchte, dass die Daten irgendwo gespeichert werden, möchte er, dass der Benutzer sie jedes Mal in meine Hand gibt?

1
Michael Shaw