Schutz sensibler Daten vor Entwicklern

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.

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.

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.)

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.

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.

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.

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.

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.

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.