Schutz sensibler Daten vor Entwicklern

61

Ich verwende eine Unternehmensanwendung, die sowohl MySQL- als auch MongoDB- Datenspeicher verwendet. Mein Entwicklungsteam hat alle SSH- Zugriff auf den Computer, um Anwendungsfreigaben, Wartungsarbeiten usw. durchzuführen.

Ich habe kürzlich das Risiko in der Branche aufgeworfen, als Benutzer damit begannen, hochsensible Daten in der Anwendung zu speichern, dass die Entwickler indirekt auf diese Daten zugreifen, was zu einem leichten Sturm führte. Daher wurde ich jetzt beauftragt, die Daten so zu sichern, dass dies nicht der Fall ist zugänglich.

Dies scheint mir nicht möglich zu sein, da ein Entwickler mit Zugriff auf die Maschine und die Anwendungsquelle immer auf die Daten zugreifen kann, wenn die Anwendung Zugriff auf die Datenbank hat.

Clinton Bosch
quelle
30
Benutzer sollten sensible Daten nur in verschlüsselter Form speichern. Es sollte kein großes Problem geben, wenn Entwickler auf das verschlüsselte Formular zugreifen können, solange die entsprechenden Schlüssel ordnungsgemäß von ihnen abgeschirmt sind.
MSalters
3
@Clinton Haben Sie separate Administrations- und Entwicklerteams? Der Serveradministrator kann die Daten immer lesen, und die Verschlüsselung hilft nicht weiter, da er den Schlüssel leicht erhält.
CodesInChaos
14
Um ganz ehrlich zu sein, ist dies eine komplizierte Angelegenheit, und um es richtig zu machen, ist viel Fachwissen in Sachen Datensicherheit erforderlich. Selbst wenn Sie genau wüssten, was zu tun ist, werden Sie mit geschäftlichen, politischen und technischen Hindernissen konfrontiert sein. Ich schlage vor, dass Sie einen Berater für Datensicherheit hinzuziehen. Sie wissen nicht nur, was hier zu tun ist, das obere Management schenkt in der Regel mehr Vertrauen, wenn ein Dritter ihnen sagt, dass sie sich ändern sollen. Das obere Management legt im Allgemeinen nicht so viel Wert darauf, was seine internen Experten ihnen sagen.
maple_shaft
3
Fragen Sie nach Information Security Stack Exchange. Es gibt einige verwandte Informationen zu dieser Frage
paj28
23
Warum berühren Menschen den Server und stellen Code bereit?
Wyatt Barnett

Antworten:

89

Sicherheit ist kein Zauberstab, mit dem Sie am Ende eines Projekts winken können. Sie muss ab dem ersten Tag berücksichtigt und eingebaut werden. Sie ist kein Bolt-On, sondern die konsequente Anwendung einer Reihe von Lösungen, die iterativ angewendet und überprüft werden regelmäßig als Teil eines ganzen Systems, das nur so stark ist wie das schwächste Glied.

So wie es aussieht, haben Sie ein Sicherheitsproblem gemeldet, was ein guter erster Schritt ist. Als Minimum müssen Sie nun definieren:

  • Welche Daten möchten Sie schützen?
  • Vor wem möchten Sie diese Daten schützen?
  • Wer braucht eigentlich Zugriff auf was (und wann)?
  • Welche rechtlichen, finanziellen und geschäftlichen Auswirkungen hat eine Gefährdung dieser Daten?
  • Was ist der rechtliche, finanzielle oder geschäftliche Bedarf für eine Person / Gruppe, die Zugriff auf die Daten hat?
  • Welches Budget ist das Unternehmen bereit, einer Strategie "Get Secure Stay Secure" zuzuweisen, als dies zuvor keine Geschäftsanforderung war?
  • Welchen Zugang benötigt das System zu den Daten?
  • Worauf beruhen dieser Prozess und die Systeme, auf denen diese Anwendung basiert?
  • Was wird unternommen, um diese Umgebungen zu sichern?
  • Wer ist für die Umsetzung und Überprüfung des gesamten Prozesses verantwortlich?

Bis Sie alle Details kennen, haben Sie wirklich nichts zu tun. Diese Informationen definieren, welche Abwehrmaßnahmen für diese Bedrohungen Sie anwenden können (und welche nicht) und warum.

Es kann sein, dass das Beste, was zu tun ist, zu erkennen, dass Sie nicht die erforderliche Erfahrung haben und dass es am besten ist, jemanden mit dieser Erfahrung neu hinzuzuziehen. Ich höre ziemlich oft die Antwort, dass es kein Budget gibt - wenn es für wirklich wichtig gehalten wird, wird das Budget gefunden.

James Snell
quelle
33
Whoa ... das bringt Sicherheit zum Klingen ... nicht trivial. (Entschuldigung für den Sarkasmus; ich habe viele Leute gesehen, die davon überrascht waren.)
Paul Draper
4
Ich glaube, dass einige Leute denken, dass es einen magischen make-application-secureBefehl gibt, den sie nur ausführen müssen.
TMH
27

Du hast recht. Wenn eine Anwendung auf Inhalte zugreifen kann, die auf Unternehmenscomputern gespeichert sind, ohne dass der Benutzer jedes Mal zusätzliche Informationen übermittelt , können die Programmierer, Verwalter, Systemadministratoren usw. des Dienstanbieters auf diese Inhalte zugreifen. Dies ist grundsätzlich unvermeidlich und eine Hauptursache für Unsicherheit (Edward Snowden war ein Systemadministrator und hatte Sonderrechte über "Top Secret", weil es einfach keine Möglichkeit gibt, sie nicht zu gewähren.)

Die einzige Möglichkeit, dies zu vermeiden, besteht darin, den Benutzer zur Angabe von Informationen aufzufordern, die niemals auf die Unternehmenscomputer gelangen. Dies ist mühsam und fehleranfällig, da sich möglicherweise niemand genügend Informationen merken kann, um eine sichere Zugangsbarriere zu bilden. Daher werden die Benutzer ihre Anmeldeinformationen sofort elektronisch an einem bestimmten Ort speichern, der dann zum neuen Angriffsziel (und wahrscheinlich zum neuen Angriffsziel) wird schwächeres Ziel als das, das Sie pflegen). Wenn Sie jedoch aufrichtig behaupten möchten, dass "unsere Mitarbeiter physisch nicht in der Lage sind, auf die Inhalte unserer Benutzer zuzugreifen", ist dies der einzige Weg.

(Beachten Sie auch, dass ein solches Geschäftsmodell politisch unhaltbar zu werden scheint. Unternehmen wurden von Sicherheitsdiensten aus dem Betrieb gezwungen, weil sie genau dies versucht haben. Ich verstehe, dass Datenschutzgarantien geschäftlichen Wert haben, aber möglicherweise nicht mehr Geschäftswert als das grundlegende Ziel, im Geschäft zu bleiben.)

Kilian Foth
quelle
6
Es ist möglich, Hardware so zu gestalten, dass es physisch unmöglich ist, auf bestimmte Daten zuzugreifen, ohne eine permanente Aufzeichnung eines solchen Zugriffs zu erstellen, die ohne die Zusammenarbeit mehrerer unabhängiger Personen nicht zerstört werden kann und die auch bei einer solchen Zusammenarbeit nicht zerstört werden kann ohne klare Hinweise auf vorsätzliche Zerstörung zu hinterlassen. Das Aktualisieren derartiger Systeme, um sich ändernden Anforderungen gerecht zu werden, ist jedoch im Vergleich zum Aktualisieren softwarebasierter Sicherheitssysteme sehr teuer.
Supercat
5
Sie haben Recht, ich habe völlig vergessen, die Überprüfbarkeit als mögliche Alternative zum Zero-Knowledge-Hosting zu erwähnen . Es ist etwas einfacher zu erreichen und oft genug für den Business Case.
Kilian Foth
Dein letzter Absatz. Beziehen Sie sich auf Geschichten vom Typ LavaBit? Ich bin verwirrt.
jpmc26
1
@supercat Man muss auch darauf vertrauen, dass die Macher der Hardware das gemacht haben, was sie gesagt haben.
user253751
2
@immibis: Stimmt, aber ich würde das Design und die Herstellung von sicherer Hardware von mehreren unabhängigen Personen prüfen lassen. Ferner wäre es in einem herkömmlichen System möglich, dass ein "hinterhältiger" Code etwas tut und sich dann spurlos selbst löscht, aber wenn eine sichere Hardware keinen beschreibbaren Kontrollspeicher haben soll, so etwas wäre unmöglich. Entweder müsste sich hinterhältiger Code permanent im Kontrollspeicher befinden, oder der Kontrollspeicher müsste über ein fest verdrahtetes Änderungsmittel verfügen, von dem eines nachträglich erkennbar wäre.
Supercat
15

Du liegst richtig; Einige Entwickler benötigen immer Zugriff auf die Live-Daten, um Produktionsprobleme zu diagnostizieren. Das Beste, was Sie tun können, ist, den potenziellen Schaden zu begrenzen, indem Sie die Anzahl der beteiligten Personen verringern.

With great power comes great ... opportunity to really, *really* foul things up. 

Viele Entwickler wollen diese Verantwortung nicht und andere sind einfach nicht "bereit", sie zu übernehmen, und sollten dies auch nicht tun.

Frage: Warum führt Ihr Entwicklungsteam Live- Veröffentlichungen durch ?
Ich würde vorschlagen, dass Sie ein Release-Management- "Team" benötigen (auch wenn dies nur eine Teilmenge Ihres Teams ist, plus Unternehmensvertretung, um alltägliche "Entscheidungen" wie "Go / No-Go" zu treffen). Dies würde viel von der „Notwendigkeit“ entfernen für Entwickler berühren etwas Live.

Haben Sie eine Geheimhaltungsvereinbarung zwischen Entwicklern und Unternehmen? Es ist hartnäckig, aber es könnte etwas Verdienst haben.

Phill W.
quelle
Was immer noch nicht aufhört, bestimmt Unrecht zu tun, indem es die Hintertür in der Anwendung versteckt, aber es verringert die Möglichkeit, die der Dieb macht.
Jan Hudec
Ja, es ist nicht das gesamte Entwicklungsteam, sondern ein Subset- / Release-Management-Team. Wir haben mit Sicherheit eine Klausel im Arbeitsvertrag über das Aufspüren von Daten, die Sie nicht haben sollten. Es ist eine abweisbare Straftat.
Clinton Bosch
@JanHudec Besonders seit dem Hinzufügen von Code hinterlässt die Anwendung Spuren in der Versionskontrolle.
CodesInChaos
@CodesInChaos: Ein guter Programmierer kann die Hintertür wie einen ehrlichen Fehler aussehen lassen. Sie werden sie verdächtigen, aber Sie werden niemals eine Klage gegen sie erheben. Aber ja, es ist eine andere Verteidigungslinie.
Jan Hudec
@Jan: Aus diesem Grund sollten alle Codeänderungen überprüft und abgemeldet werden, bevor sie in den Release-Zweig gelangen.
SilverlightFox
9

Das Problem ist, dass Ihre Entwickler Zugriff auf die Systeme haben. Wenn sie Produktionsdaten zum Debuggen benötigen, geben Sie ihnen einen Datenbank-Dump, in dem alle vertraulichen Informationen entfernt werden. Dann können die Entwickler mit diesem Dump arbeiten.

Das Bereitstellen einer neuen Version sollte keine Entwickler mit einbeziehen - das ist eine reine Administrationsaufgabe oder noch besser - eine vollautomatisierte Aufgabe. Beachten Sie auch, dass das Freigeben und Bereitstellen zwei sehr unterschiedliche Aufgaben sind. Wenn sich Ihr Prozess dessen nicht bewusst ist, ändern Sie ihn entsprechend.

SpaceTrucker
quelle
1
Wir brauchen keine Produktionsdaten aus dem Debugging, dafür haben wir einen bereinigten Daten-Dump, aber manchmal erfordert eine Bereitstellung verschiedene Datenmigrationen usw., die von einigen Entwicklern im Release-Management-Team ausgeführt werden (aber sie sind noch Entwickler)
Clinton Bosch
2
@ClintonBosch Dann haben Sie die Rollen von Administratoren und Entwicklern nicht klar getrennt. Eine weitere Frage, die Sie sich stellen sollten, lautet: Wie stellen wir sicher, dass die veröffentlichte Software auch tatsächlich bereitgestellt wird? Sie müssten sich bei der Freigabe anmelden und nur die Bereitstellung signierter Pakete in der Produktion zulassen. Auch wieder Automatisierung ist dein Freund. Migrationen sollten keine manuellen Schritte erfordern.
SpaceTrucker
4
@ClintonBosch Identifizieren Sie, welche Datenfelder streng vertraulich sind, und verschlüsseln Sie sie. Stellen Sie sicher, dass Sie die Sicherheit des Produktionsbetriebssystems aktivieren, damit Sie darauf zugreifen können, welche Benutzer-IDs die Schlüsseldatei lesen, um sicherzustellen, dass nur der Benutzer der Anwendung dies tut. Geben Sie den Entwicklern nicht das App-Benutzerkennwort. Machen Sie sie zu Sudos, um Produktionsrechte zu erhalten und zu protokollieren, was sie tun. Dies ist wahrscheinlich der sicherste Weg, um sicherzustellen, dass Sie die wenigen Personen babysitten, die Zugriff haben, und dass sie nicht zufällig oder versehentlich Daten sehen können, die sie nicht sehen sollen.
maple_shaft
6

Regel 1 der Sicherheit: Wenn jemand Zugriff auf Informationen hat, hat er Zugriff auf diese Informationen

Diese Tautologie ist ärgerlich, aber es ist wahr. Wenn Sie einer Person Zugriff gewähren, haben sie Zugriff auf die Daten. Für Benutzer bedeutet dies normalerweise Zugriffskontrolle, aber für Entwickler ... nun ... sind sie diejenigen, die die Zugriffskontrolle schreiben müssen.

Wenn dies ein großes Problem für Sie ist (und es sich so anhört), ziehen Sie in Betracht, Sicherheit in Ihre Software zu integrieren. Ein gängiges Muster besteht darin, sichere Software in Schichten zu entwerfen. Auf der untersten Ebene entwirft ein vertrauenswürdiges Entwicklungsteam Software, die die nackteste Zugangskontrolle verwaltet. Diese Software wird von möglichst vielen Personen validiert und verifiziert. Jeder, der diesen Code entwirft, hat Zugriff auf alles, daher ist Vertrauen unerlässlich.

Danach können Entwickler eine flexiblere Zugriffskontrolle auf dieser Kernebene aufbauen. Dieser Code muss immer noch V & Vd sein, ist aber nicht ganz so streng, da Sie sich immer auf die Kernebene verlassen können, um das Wesentliche abzudecken.

Das Muster erstreckt sich nach außen.

Der schwierige Teil, in der Tat die Kunst , diese Systeme zu entwerfen, besteht darin, jede Ebene so aufzubauen, dass Entwickler weiterentwickeln und debuggen können, während Ihr Unternehmen dennoch die Sicherheit erhält, die Sie erwarten. Insbesondere müssen Sie akzeptieren, dass das Debuggen mehr Berechtigungen erfordert , als Sie denken, und der Versuch, diese zu sperren, wird einige sehr verärgerte Entwickler zur Folge haben.

Als Nebenlösung sollten Sie erwägen, "sichere" Datenbanken für Testzwecke zu erstellen, in denen Entwickler alle Sicherheitsmechanismen herausreißen und ernsthafte Fehlerbehebungen durchführen können.

Letztendlich müssen sowohl Sie als auch Ihre Entwickler einen wichtigen Grundsatz der Sicherheit verstehen: Alle Sicherheit ist ein Gleichgewicht zwischen Sicherheit und Benutzerfreundlichkeit. Sie müssen als Unternehmen Ihr eigenes Gleichgewicht finden. Das System ist nicht perfekt sicher und kann nicht perfekt verwendet werden. Dieses Gleichgewicht wird sich wahrscheinlich sogar verschieben, wenn Ihr Unternehmen wächst und / oder sich die Anforderungen an Entwickler ändern. Wenn Sie für diese Realität offen sind, können Sie sie ansprechen.

Cort Ammon
quelle
3

Richten Sie zwei Bereitstellungen der Anwendung ein, die auch getrennte Datenbankbereitstellungen verwenden. Eine ist die Produktionsbereitstellung und eine die Testbereitstellung.

Die Testbereitstellung sollte nur Testdaten enthalten. Dies können entweder Fantasy-Daten sein, die zu diesem Zweck erstellt wurden, oder eine Kopie der Produktionsdaten, die anonymisiert wurden, um die Entwickler daran zu hindern, die tatsächlichen Personen und Entitäten herauszufinden, die hinter den Daten stehen.

Philipp
quelle
Ja, das ist genau das Szenario, das wir haben. Aber irgendwann muss jemand an der Produktionsumgebung arbeiten, um eine Bereitstellung / Datenmigration zu ermöglichen
Clinton Bosch
3

In zwei Finanzunternehmen hatten Entwickler keinen Zugang zu Produktionsmaschinen. Alle Anforderungen zur Änderung von Produktionsmaschinen mussten einen Genehmigungsprozess mit einem Skript durchlaufen und wurden von den Managern genehmigt. Das Entwicklerteam hat die tatsächlichen Bereitstellungen abgeschlossen. Ich nehme an, dieses Team bestand nur aus Mitarbeitern und hat die Zuverlässigkeitsüberprüfung bestanden. Sie hatten auch keine Entwickler-Kenntnisse, konnten also wahrscheinlich nicht schnüffeln, wenn sie wollten. Darüber hinaus würden Sie alle Datenbankeinträge mit einem in den Umgebungsvariablen gespeicherten geheimen Schlüssel verschlüsseln. Selbst wenn die Datenbanken öffentlich durchgesickert wären, könnte niemand sie lesen. Dieser Schlüssel kann durch ein weiteres Passwort geschützt werden (PBKDF), sodass nur ein leitender Angestellter ihn entsperren kann. Ihr System benötigt möglicherweise beim Booten das Executive-Kennwort (oder wird mit größerer Wahrscheinlichkeit an Entwickler oder Entwickler-Manager delegiert). Grundsätzlich besteht die Strategie darin, das Wissen so zu verteilen, dass eine kritische Masse an erforderlichem Wissen nicht bei einer Person vorhanden ist und es zu gegenseitigen Abwägungen kommt. So schützt Coca-Cola seine Formel. Ehrlich gesagt, sind einige dieser Antworten Ausreden.

Chloe
quelle
-1

MongoDB verfügt nur über eingeschränkte Sicherheitskontrollen und ist von einer sicheren Umgebung abhängig. Das Binden an eine bestimmte IP-Adresse und einen bestimmten Port (und SSL seit 2.2) sowie eine grobe Authentifizierung bieten diese Funktionen. MYSQL fügt GRANT o ON db.t TO ... hinzu. In Ruhe befindliche Daten werden nicht verschlüsselt, und ssl wird standardmäßig nicht verwendet. Erstelle einen Zaun. Ein schreibgeschützter Zugriff für Entwickler auf anwendungsbezogene Protokolldateien sollte zum Debuggen ausreichen. Automatisieren Sie den Anwendungslebenszyklus.

Ansible hat uns dabei geholfen, Standardvorgänge (Bereitstellen, Aktualisieren, Wiederherstellen) in vielen Umgebungen mit nur einem Jahr zu automatisieren und dabei verschiedene verschlüsselte Depots zum Speichern vertraulicher Umgebungsvariablen wie Hosts, Ports und Anmeldeinformationen zu verwenden. Wenn jedes Depot nur von verschiedenen Rollen und nur auf einem Bastion-Host für protokollierte Vorgänge entschlüsselt werden kann, bietet die Überprüfbarkeit eine akzeptable Sicherheit. Wenn Sie SSH gewähren, verwenden Sie bitte Selinux, um Schlüsselmanipulationen zu vermeiden. Verwenden Sie einen Bastion-Host mit LDAP / Kerberos-Authentifizierung für die Verwaltung und verwenden Sie Sudo mit Bedacht.

bbaassssiiee
quelle