Welche Strategien können angewendet werden, um vertrauliche Daten in Protokolldateien zu sichern?

Arbeiten in stark regulierten Umgebungen Daten werden je nach Empfindlichkeit unterschiedlich klassifiziert. In einigen Fällen ist dies gesetzlich vorgeschrieben und muss anders behandelt werden.

Beispiele für eine Datenklassifizierungsrichtlinie sind:

• Stark eingeschränkte Daten wie Passwörter, private Schlüssel, SAML-Token und Kreditkartennummern.
• Eingeschränkte Daten wie Benutzernamen und Kunden-IDs.
• Uneingeschränkte Daten, so ziemlich alles andere.

Diese Klassifizierung ist mit bestimmten Verpflichtungen verbunden:

• Hoch eingeschränkte Daten dürfen unter keinen Umständen in einer Protokolldatei verfügbar gemacht werden.

• Eingeschränkte Daten können unter bestimmten Bedingungen in Protokolldateien verfügbar gemacht werden. Wenn beispielsweise ein Vorfall mit einem Dienst auftreten sollte, kann der Bereitschaftsingenieur ein Break-Glass- Verfahren durchführen, um auf diese Daten zuzugreifen und das Problem zu diagnostizieren. Das Break-Glass-Verfahren würde wiederum eine Überprüfung, eine Prüfung und möglicherweise einen vorübergehenden Widerruf der Berechtigung dieses Ingenieurs auslösen.

Welche Strategien können eingesetzt werden, um dies zu erreichen, insbesondere angesichts der Tatsache, dass auf dem Markt eine breite Palette von Protokollierungs-, Überwachungs- und Instrumentierungswerkzeugen verfügbar ist, die keine direkte Antwort auf dieses Problem bieten?

Beispielsweise können sowohl Splunk als auch AppDynamics den Bedingungen der Telemetrie unterschiedliche Zugriffskontrollen auferlegen. Dies bedeutet, dass Sie einen Filter erstellen können, der maskiert <customerId>NNNNNNNNNNNN</customerId>. Keines dieser Tools bietet Ihnen jedoch die Möglichkeit, Kreditkartennummern automatisch zu identifizieren und automatisch zu maskieren.

Hinweis : Ich glaube, dies hängt mit DevOps zusammen, da in einem traditionellen abgestuften Support-Modell eine relativ kleine Gruppe von Personen Zugriff auf die Daten haben und diese manuell filtern könnte, indem die Verantwortung für den Betrieb von Plattformen auf Entwicklungsteams übertragen wird, denen diese Daten möglicherweise weit ausgesetzt sind breiteres Publikum.

Ich denke, die Lösung beruht auf einem breiten Spektrum von Ansätzen, die den Datenschutz gewährleisten:

• Datenklassifizierung : Die effizienteste technische Strategie ist konsequent die Daten an der Stelle der Schöpfung zu kategorisieren. Im Kern sind die Entwickler dafür verantwortlich, dass allen protokollierten Informationen eine Kategorie zugewiesen wird. Die Kategorisierung kann beispielsweise über Splunk-Metadaten erfolgen, mit denen wiederum Protokolleinträge basierend auf ihrer Datenkategorisierung in verschiedene Buckets geleitet werden können.

• Ereignispartitionierung : Es besteht häufig der Wunsch, vertrauliche Informationen neben nicht vertraulichen Informationen zu protokollieren. Wenn sich beispielsweise ein neuer Benutzer anmelden sollte, können Sie Folgendes protokollieren:

  • Kunden-ID (eingeschränkt)
  • Kundentyp (eingeschränkt)
  • Erwerbsquelle (uneingeschränkt)
  • Korrelations-ID (uneingeschränkt)

  Es ist möglich, dieses eine "Ereignis" in zwei Teile aufzuteilen, von denen einer die eingeschränkten Informationen und einer die uneingeschränkten Informationen enthält. Dies stimmt mit dem ersten Punkt überein, indem Filterregeln auf verschiedene Buckets geleitet werden können.

• Datenmaskierung : Unter bestimmten Umständen ist es möglicherweise nicht möglich, die Daten an der Quelle zu kategorisieren. Nach meiner Erfahrung ermöglichen Protokollierungslösungen Maskierungsregeln , um vertrauliche Daten auszublenden . Im verknüpften Beispiel wird ein sedBefehl verwendet, um einen regulären Ausdruck auf alle Daten aus einer bestimmten Quelle anzuwenden. Sobald die eingeschränkten Daten ausgeblendet wurden, kann das Ereignis als uneingeschränkt betrachtet werden. Bei der Regel muss darauf geachtet werden, dass Informationen, die für ein Ereignis kritisch sind, z. B. eine Korrelations-ID, nicht mit dem regulären Ausdruck übereinstimmen, der zum Abgleichen vertraulicher Daten verwendet wird.

• Ereignisfilterung : Als letztes Mittel kann es erforderlich sein, alle Ereignisse eines bestimmten Typs oder einer bestimmten Quelle in einen separaten Bucket zu filtern, wenn sie vertrauliche Daten enthalten, die nicht kategorisiert oder maskiert werden können. In diesem Fall konnte auf die Informationen in einem eingeschränkten Bucket nur über einen Break-Glass-Mechanismus zugegriffen werden , um die Zugangskontrollen gemäß den Bestimmungen eines Vorfalls zu umgehen.

Bei jeder dieser Lösungen ist das Testen der Schlüssel, um sicherzustellen, dass nichts durch die Risse rutscht. Protokollierung und Ereignisverwaltung müssen als erstklassige nicht funktionale Anforderung mit dem gleichen Grad an Entwicklungsstrenge betrachtet werden, der für eine Lösung gilt - einschließlich Peer Review und Tests, um sicherzustellen, dass die Daten im Tool Ihrer Wahl ordnungsgemäß kategorisiert und partitioniert werden.

Es hängt davon ab, was Sie unter "Protokolldateien" verstehen, die ich angenommen habe. Wenn Sie die Telemetriedaten meinen, mit denen Sie überprüfen, ob Ihr System ordnungsgemäß funktioniert, würde ich sagen: "Keine sensiblen Felder protokollieren." Sie benötigen diese Art von Informationen nicht, um Sie auf hohe oder niedrige Transaktionsraten, Antwortzeiten auf Ihre abhängigen Dienste usw. aufmerksam zu machen.

Wenn Sie Daten für Abrechnungs- oder Prüfungszwecke meinen, würde ich vorschlagen, dass Sie eine Nur-Schreib-Pipeline einrichten, in der die Daten geschrieben werden, aber vom Verfasser nicht gelesen werden können. Dann wird Ihre Abrechnungs- und Prüfpipeline aktiviert und Sie haben dort die Kontrolle, um zu prüfen, wer einzelne Datensätze betrachtet hat.

Am Ende geht es bei der Sicherheit um dokumentierte Prozesse mit eigenen sicheren Protokolldateien usw. Irgendwann muss man jemandem oder einem Prozess vertrauen, da alle Daten so geschrieben sind, dass sie später gelesen werden können.