PCI DSS Die Abschnitte 6, 7 und 8 befassen sich alle mit dieser Frage.

Zum Beispiel Teil von 6.3.2, der eine Codeüberprüfung erfordert:

Codeänderungen werden von anderen Personen als dem Autor des Ursprungscodes sowie von Personen überprüft, die sich mit Codeüberprüfungstechniken und sicheren Codierungspraktiken auskennen.

6.4 mit Änderungskontrolle:

Eine Aufgabentrennung zwischen Personal, das der Entwicklungs- / Testumgebung zugewiesen ist, und Personal, das der Produktionsumgebung zugewiesen ist.

7.1 Kontrolle des Zugriffs ... in vielen Umgebungen der Entwickler, der Code schreibt Greift niemals auf die Betriebssysteme, auf denen es mit Live-Daten verwendet wird:

Beschränken Sie den Zugriff auf Systemkomponenten und Karteninhaberdaten nur auf diejenigen Personen, deren Job einen solchen Zugriff erfordert.

Und ein Hauch von 8.7, um die Personen mit Zugriff einzuschränken:

Überprüfen Sie die Einstellungen für die Datenbank- und Anwendungskonfiguration, um sicherzustellen, dass alle Benutzer a Der Zugriff auf, die Benutzerabfragen und die Benutzeraktionen für die Datenbank (z. B. Verschieben, Kopieren, Löschen) erfolgen nur über programmatische Methoden (z. B. über gespeicherte Prozeduren).

Nun, das Kann ein vertrauenswürdiger Insider perfekt verteidigt werden? Nein, wegen der Definition von "vertrauenswürdig". Dies gilt an allen Orten (wie vielen Spionen wurde "vertraut"? John Anthony Walker fällt ein). Es gibt jedoch bewährte Methoden, um sich gegen eine solche Bedrohung zu verteidigen und sie zu mindern, und das PCI-DSS formalisiert eine Reihe von Anforderungen Diese Praktiken (für Kreditkarten ... andere Geheimnisse sind für sich allein!)

(Und @ Stephen-Touset weist darauf hin, dass 3.5.2 Folgendes erfordert:

Geheimnis speichern und private Schlüssel, mit denen Karteninhaberdaten jederzeit in einer (oder mehreren) der folgenden Formen verschlüsselt / entschlüsselt werden:

Eine dieser Möglichkeiten ist:

Innerhalb eines sicheren kryptografischen Geräts (z. B. eines Host-Sicherheitsmoduls) (HSM) oder PTS-zugelassenes Point-of-Interaction-Gerät)

Dies hat den Vorteil, dass das eigentliche Schlüsselmaterial von alltäglichen Benutzern und Administratoren ferngehalten wird.) P. >

In nicht unerheblichem Maße handelt es sich hierbei (wie Sie bereits erwähnt haben) um ein Vertrauensproblem, nicht um ein technisches. Wir versuchen, so weit wie möglich vorsichtig zu sein und vertrauenswürdige Leute einzustellen, die ihre Positionen nicht missbrauchen.

Es gibt jedoch eine Reihe von Kontrollen, die implementiert werden können, um entweder den nicht autorisierten Zugriff einzuschränken und / oder um zu überprüfen, ob das Vertrauen in Einzelpersonen gut platziert ist und tatsächlich nicht missbraucht wird.

Hier sind einige dieser Steuerelemente:

Es gibt unzählige andere Steuerelemente, die möglicherweise aufgelistet werden könnten, aber dies sind einige der Hauptkategorien, in die die meisten fallen.

Die Kosten, um dies zu verhindern, sind enorm und werden daher selten außerhalb großer, gut finanzierter Entwicklungsgruppen durchgeführt. Die obigen Erwähnungen von Codeüberprüfung, Sicherheitsüberprüfung usw. sind alles gute Ideen, aber in der Praxis sind Kunden mehr daran interessiert, funktionierenden Code zu erhalten, als die Verwendung ihrer Assets um Monate zu verzögern, während Überprüfungsprozesse stattfinden.

Die Mehrheit Der Fall, mit dem sich mein Unternehmen befasst, sind mittelständische Unternehmen, die bereit sind, Ressourcen für die Erstellung von kundenspezifischer Software für den internen Gebrauch aufzuwenden, sich jedoch nicht auf ein ISO-konformes Entwicklungskomitee mit Gletschertempo konzentrieren, nur damit das Kundenkontakt-Tracking-System oder die Projektmanagement-Datenbank dies können verbessert werden.

In der Praxis gibt es fast keine Möglichkeit, diese Art von Missbrauch zu verhindern, außer sich nur mit Softwareanbietern zu befassen, denen Sie vertrauen. Dies ist natürlich keine Lösung, aber es gibt dem Kunden zumindest die richtige Meinung und kann ihn dazu führen, Geschäftspartner sorgfältig auszuwählen - und ein Softwareanbieter ist ein Geschäftspartner, einer der meisten Intim wird jedes Unternehmen haben, obwohl die Leute die meiste Zeit erstaunlich blind dafür zu sein scheinen.

Betrachten Sie die Skandale, die in den letzten Jahren mit Beteiligung von Google, Apple, Microsoft usw. und der NSA aufgetreten sind. Oder sogar Googles selbstgesteuerte Datenschutzverletzungen. Die Entwickler stellten sicher, dass jemand die Daten ihrer Kunden stehlen konnte, und zwar auf eine Weise, die die Sicherheitsüberprüfungsprozesse - die diese bestimmten Organisationen groß genug sind, um sie sich leisten zu können - nicht erfassten. Es ist wirklich ein "Quis custodiet ipsos custodes?" Problem (lit. "Wer bewacht die Wachen?").

In meinem Fall haben wir festgestellt, dass wir Kundendaten niemals selbst speichern werden. Das bedeutet, dass wir billige kleine Server vor Ort bei Kunden bereitstellen, die das Geschäft direkt bedienen. Dies ist die Ära des wahnsinnig schnellen Internets und der billigen Hardware. Ein kleines Unternehmen benötigt keinen Cloud-Service, um von überall auf der Welt auf seine Daten zugreifen zu können. Um Sicherheit und Datenredundanz zu gewährleisten, bieten wir eine drahtlose Sicherung an, die jedoch alle verschlüsselten Blobs enthält, sodass wir sie nicht lesen können.

Wir könnten mit Sicherheit Löcher in ihren Blobs öffnen Server und missbrauchen ihr Vertrauen, wenn wir wollten. Aber es gibt keine Möglichkeit, jemanden vom Bösen abzuhalten. Als Eigentümer meines Unternehmens habe ich entschieden, dass das beste Gleichgewicht zwischen Sicherheit und Benutzerfreundlichkeit (für uns und den Kunden) darin besteht, dass sie ihre Daten speichern, und dass wir nur verschlüsselte Sicherungen davon aufbewahren.

I. erwähnte die "Wolke" oben. Dies ist wahrscheinlich die größte Bedrohung für die Datensicherheit, die sich bisher jemand vorgestellt hat, und es gibt genau null Möglichkeiten, den Schutz von Kundendaten zu gewährleisten, sobald diese nicht mehr in ihren Händen sind. "Besitz macht 90% des Gesetzes aus" ist eine gute Lektion, denn in der Neuzeit sind es 90% der Datensicherheit.

Für kleine und mittlere Unternehmen, in denen ein Entwickler mehrere Hüte trägt (DBA, Systemadministrator, technischer Support, Webmaster usw.), wäre die Erfüllung der PCI-DSS-Anforderungen zu schwierig. Eine mögliche Lösung, um zu verhindern, dass ein Entwickler vertrauliche Daten erhält, ist die Verwendung einer Drittanbieter-API , bei der die Verarbeitung und Speicherung vertraulicher Daten auf einer vertrauenswürdigen Drittanbieter-Website statt erfolgt Ihre eigene Website.

Bei Kreditkartentransaktionen und wiederkehrendem Zahlungsmanagement können Sie PayPal verwenden, das PCI DSS-kompatibel ist, anstatt Ihr eigenes System zu rollen. Natürlich muss der Code noch überprüft werden, um sicherzustellen, dass Kunden während der Transaktion tatsächlich auf die Website eines Drittanbieters umgeleitet werden.

Am Ende des Tages müssen Sie jemandem vertrauen (einem Vertrauenswürdigen) Entwickler oder ein vertrauenswürdiger Dritter), der beauftragt ist, die Arbeit für Sie zu erledigen. Ansonsten musst du alles selbst machen.

Oft hat der Entwickler keinen vollständigen Zugriff auf die Kundendatenbank.

In meinem Unternehmen werden alle unsere Entwicklungen in anonymisierten Datenbanken durchgeführt - Kreditkartennummern, persönliche Daten usw. werden entfernt und Dinge werden durcheinander gebracht oben. Die Live-Datenbanken befinden sich auf den Kundencomputern, und Junior- / Mid-Level-Entwickler haben einfach keinen Lesezugriff auf diese Tabellen.

Wir könnten mit den Systemkennwörtern auf sie zugreifen, aber dazu würden wir protokolliert Sowohl das Abrufen der Datei zum Extrahieren des Kennworts als auch das Anmelden vom "falschen" Computer in der Datenbank.

Andere Systeme, die ich gesehen habe, umfassen das Verschlüsseln der Kreditkartendaten und das Nichtverfügbarkeit des Schlüssels für den Entwickler.

Am Ende des Tages konnte ein ausreichend entschlossener Entwickler auf fast alles zugreifen, aber indem Sie es schwierig machen, vermeiden Sie die gelegentlichen Versuchungen und indem Sie protokollieren, machen Sie deutlich, dass es Auswirkungen geben wird.

Ich bin überrascht, dass niemand DUKPT erwähnt hat, aber vielleicht liegt das daran, dass einige der wichtigsten Zahlungsgateways es nie unterstützt haben, und vielleicht werden sie es jetzt nie tun, da TripleDES Brute-Force-Angriffen ausgesetzt ist . Aber es war zu seiner Zeit eine großartige Idee, und es gibt keinen Grund, warum so etwas mit moderner Verschlüsselung nicht möglich wäre. Einige Anbieter verkaufen immer noch Kartenleser mit DUKPT oder ähnlichem, und es gibt einige kleine Prozessoren, die die Verschlüsselung unterstützen und als Proxys für die größeren fungieren.

Ich kann dem Wiki-Artikel nichts hinzufügen und ich behaupte nicht, vollständig zu verstehen, wie es funktioniert, nur was es tut. Im Wesentlichen ist die Hardware jedoch manipulationssicher und verfügt über eine integrierte Verschlüsselung. Sie gibt die PAN entweder verschlüsselt oder redigiert aus. Nur das Zahlungsgateway kann es entschlüsseln, sodass der Händler oder der Entwickler seiner Software es nicht durch Vorsatz oder Fahrlässigkeit gefährden kann.

Zusätzlich zu allen Antworten, die erklären, wie Entwickler daran gehindert werden können, auf solche geheimen Daten zuzugreifen, gibt es auch eine wichtige indirekte Methode: Zugriffsprotokolle

Abfragen können protokolliert werden, ebenso wie Shell-Befehle usw. . und diese Protokolle sollten so gespeichert werden, dass sie für einen einzelnen Entwickler nicht gelöscht werden können. Selbst wenn sie Zugriff haben, können rote Fahnen gesetzt werden. Warum möchten sie ALLE Kreditkartennummern? in Produktion? - Der wichtige Teil davon ist, dass der Entwickler seine eigenen Anmeldeinformationen für die Arbeit verwendet und dass es keine "freigegebenen Konten" gibt, die nicht zu bestimmten Personen führen, die für ihre Aktionen verantwortlich gemacht werden können.