Produktion, Test, Entwicklerumgebungen versus Sicherheit

Question

Welche Verfahren werden derzeit angewendet, damit Entwickler Systeme mit privaten Daten erstellen können? Kann jemand auf eine "Best Practices" Anleitung für diese Art von Sache verweisen?

Wir haben hier eine Catch-22, in der Entwickler Anwendungen schreiben müssen, die gegen Systeme mit Daten arbeiten, die als "privat" gelten. Die IT-Administration möchte, dass Entwickler keinen Zugriff auf die Daten haben (dh ein Schema oder eine Datenstruktur bereitstellen, aber nicht die Daten selbst), während die meisten Entwickler (ich selbst eingeschlossen) gerne Zugriff auf die Produktionsdaten haben würden Ein repräsentativer Datensatz kann zu falschen Annahmen (z. B. das Format der Daten) und später zu Fehlern führen.

Hat jemand formalisierte "Best Practices" für diese Art von Sache? Vor allem offizielle Gilden von einigen "BigCo" (zB Microsoft, IBM) könnten helfen, das Management zu überzeugen.

Answer 1

Oftmals wird eine Untergruppe von bereinigten Daten bereitgestellt, die für die privaten Daten repräsentativ sind, nicht jedoch die privaten Daten selbst.

Answer 2

Bei MediumCo entfernen wir proprietäre Daten aus unseren Produktionsdaten in Test und Dev. Es hat uns in der Vergangenheit ein wenig geschadet, nicht genau repräsentative Daten zu haben, aber die Kunden haben zuvor nach diesem Punkt gefragt, und das ist normalerweise kein Problem, da die Umgebungen mit vielen gefälschten proprietären Daten gefüllt sind.

Answer 3

In meiner Firma begannen wir mit dem Datengenerator Red-gate, um Testdaten zu generieren. Es gibt ein bisschen Setup, aber Sie können die Tools verwenden, um sehr brauchbare Testdaten zu generieren. Ja, ich würde lieber Live-Produktionsdaten verwenden, aber es ist nicht machbar (vor allem, wenn Sie in HIPAA berücksichtigen müssen). Es verwendet Regex für jede Spalte und ermöglicht die Verwendung von Nachschlagetabellen für verwandte Tabellen.

Answer 4

Ich habe keine Best Practices-Papier oder irgendetwas. Aber ich würde denken, dass, wenn Sie aus einer Umgebung entwickeln, die als geschützt ist als die Umgebung, die die Daten in der Produktion hostet, würde es nicht viel Argument dagegen gemacht werden.

Das heißt, wenn Ihre Produktionsdatenbank in einem Rechenzentrum von Ihren IT-Mitarbeitern gehostet und kontrolliert und gesichert wird, wenn Sie eine Entwicklungsdatenbank haben, die im exakt gleichen Szenario lebt und keine neuen Möglichkeiten bietet, auf die Informationen zuzugreifen - Sie wären in guter Verfassung. Als ein zusätzliches Zeichen des guten Willens - es wäre nett zu bieten, allen, die sich Sorgen um Sicherheit machen, die Möglichkeit zu geben, einen Penetrationstest durchzuführen, um sicherzustellen, dass Sie die Wahrheit über Sicherheit sagen. Die andere Seite davon ist natürlich die Analyse der Kosten für die Nichtverwendung der Daten: Das heißt, es wird zu einem Buggy-Code führen, der $ xxxxxx.xx in der Entwicklungszeit im Vergleich zu praktisch keinen Kosten kostet damit ein kleiner Teil Ihres Entwicklungsteams auf diese Daten zugreifen kann.

Answer 5

Um das manuelle Bereinigen/Anonymisieren von Daten zu vermeiden, können Sie einen zufälligen Textersatz verwenden, um jedes alphanumerische Zeichen in jedem Textfeld durch ein zufälliges alphanumerisches Zeichen zu ersetzen. Dies:

• hält die Daten in Länge, Größe usw. ähnlichin Bezug auf Zeiträume und Mengen vom Standpunkt des Entwickler Ansicht
• verursacht keine Probleme mit Charakter
• setzt verlässt Datum und Nummernfelder unberührt, die die meisten Datenschutzanforderungen befriedigen

für genaue Prüfung ermöglicht

Wenn Sie ein wenig weiter gehen wollten, könnten Sie eine zufällige Nummer-für-Nummer-Ersatz für Telefonnummern und Postleitzahlen ausführen, während Sie alphanumerische Ersetzung für andere Textfelder verwenden.

Mit einem automatisierten Ersetzungsskript können Sie regelmäßig aktuelle Datenauszüge vom Live-System abrufen, sodass Ihre Tests in Bezug auf die Größe und Variabilität der Daten in der Praxis auf dem neuesten Stand sind.

Es bedeutet, dass eine kleine Anzahl von Operationen nicht realistisch sein wird (z. B. Indizierung auf Namensfeldern, die im wirklichen Leben um gewöhnliche Buchstaben gruppiert sind), aber diese sollten begrenzt sein.

Answer 6

Mein Blick auf die Welt mag anders sein, da ich in Großbritannien ansässig bin, aber in den letzten 20 Jahren habe ich hauptsächlich im öffentlichen Sektor mit sensiblen Daten gearbeitet. Die Regeln sind ** vollständig ** geschnitten und getrocknet. Auf dem Entwicklungsgelände sind keine Produktionsdaten erlaubt.

Grundsätzlich möchten wir nicht für den Verlust sensibler Daten verantwortlich sein. Die Nutzer sind darin vollkommen gut.

Innerhalb der letzten 12 Monate ist meine Frau aus dem gleichen Regime zu einem im privaten Sektor geworden, wo sie den Entwicklern Zugriff auf Produktionsdaten gewährt und sie ist entsetzt darüber. Die rechtlichen Folgen (zumindest im Vereinigten Königreich) können schwerwiegend sein.

Entwickler ** brauchen ** keinen Zugriff auf Produktionsdaten. Es ist einfach Faulheit. Definieren und erstellen Sie Testdaten, um definierte Testfälle (einschließlich Edge Cases) auszuführen, und verlassen Sie sich nicht auf die zufällige Art von Produktionsdaten.

Wenn Sie ** Produktionsdaten verwenden müssen ** (d. H., Sie schaffen es, jemanden zu überzeugen, der nicht mehr weiß, dass es akzeptabel ist), stellen Sie sicher, dass die Daten anonymisiert werden ** bevor ** der Entwicklungsbereich erreicht wird.