PII-Shield 🛡️

Zero-Code-Logbereinigung als Sidecar für Kubernetes. Verhindert Datenlecks (DSGVO/SOC2), indem es PII aus Logs bevor sie den Pod verlassen, schwärzt.

PII-Shield läuft prozessintern — als CLI, Sidecar oder WASM. Es gibt keine gehostete API und keinen Server, an den Ihre Daten gesendet werden.

„Lassen Sie nicht zu, dass PII Ihre KI-Modelle vergiftet.“ PII-Shield stellt sicher, dass sensible Daten niemals Ihren Trainingsdatensatz erreichen, und bewahrt Sie vor einem durch die DSGVO erzwungenen erneuten Modelltraining.

[!WARNING] Upgrade auf v2.0.0? Wir haben die Endnutzer-Distribution auf Helm-basierte Installationen und Distroless Native Sidecars umgestellt. Kustomize ist für Produktionsnutzer kein unterstützter Release-Installationspfad mehr, obwohl das Operator-Repository weiterhin Kustomize-Scaffolding für lokale Entwicklung und Manifest-Generierung bereithält. /bin/sh-Zugriff innerhalb des PII-Shield-Sidecars wird nicht mehr unterstützt. Lesen Sie den Migrationsleitfaden.

Zwei Bereitstellungsmodelle

PII-Shield bietet zwei verschiedene Möglichkeiten, in Ihren Stack integriert zu werden:

1. Kubernetes-Operator (Zero-Code): Unser Flaggschiff-Bereitstellungsmodell. Ein vollautomatisierter K8s-Operator, der einen hochsicheren Distroless-Sidecar in Ihre Pods injiziert, um Logs im laufenden Betrieb abzufangen und zu bereinigen.
2. In-Process-WASM (für Kernintegrationen): Für extreme Leistung kann die Kern-Engine direkt per WASM eingebettet werden, was <1ms Latenz ohne Netzwerk-Hops bietet.

Projektstatus & Roadmap

PII-Shield ist ein aktiv entwickeltes Open-Source-Sicherheitstool in der Produktions-Härtungsphase. Die v2.x-Release-Linie liefert nutzbare CLI-, Container-, Helm/Operator- und WASM-SDK-Artefakte. Die Kern-Schwärzungspfade sind für kontrollierte Bereitstellungen bereit, während einige Kubernetes-Bereitstellungsmodi und Lieferketten-Garantien noch stabilisiert werden.

Siehe KNOWN_LIMITATIONS.md für die aktuellen Grenzen der Produktionshärtung.

Warum PII-Shield?

Entwickler vergessen oft, sensible Daten zu maskieren. Herkömmliche Regex-Filter in Fluentd/Logstash sind langsam, schwer zu warten und verbrauchen teure CPU auf Log-Aggregatoren.

PII-Shield sitzt direkt neben Ihrem App-Container:

• Produktionsgehärtete Kern-Engine: Optimiert für Kubernetes-Sidecars mit geringen Speicherzuweisungen auf heißen Pfaden und deterministischem Regex-Matching.
• Kontextbewusste Entropieanalyse: Erkennt High-Entropy-Geheimnisse auch ohne Schlüssel (z. B. Error: ... 44saCk9...), indem es Kontextschlüsselwörter analysiert.
• Benutzerdefinierte Regex-Regeln: Deterministische Schwärzung für strukturierte Daten (UUIDs, IDs), die Entropieprüfungen für bekannte Muster überschreibt.
• Regressions- und Fuzz-Testabdeckung: Getestet gegen Stressfälle wie Binärmüll, JSON-Verschachtelung und mehrsprachige Logs.
• Deterministisches Hashing: Ersetzt Geheimnisse durch eindeutige Hashes (z. B. [HIDDEN:a1b2c]), sodass QA Fehler korrelieren kann, ohne die Rohdaten zu sehen.
• Drop-in: Keine Codeänderungen erforderlich. Funktioniert mit jeder Sprache (Node, Python, Java, Go).
• Whitelist-Unterstützung: Erlaubt ausdrücklich sichere Muster (z. B. Git-Hashes, System-IDs) mithilfe von PII_SAFE_REGEX_LIST, um Fehlalarme zu vermeiden.

Verwalten Sie PII-Shield über Dutzende von Clustern?

Wir bauen eine gehostete Control Plane mit zentralem Regelmanagement, Slack-Benachrichtigungen und Schwärzungsanalysen.

Integrationen

Die prozessinterne WASM-Variante von PII-Shield wird in GuardSpine Code ausgeliefert, einer Open-Source-GitHub-Action für KI-Code-Governance, die die Binärdatei bündelt und sie in ihrer NOTICE aufführt.

Leistungsüberlegungen

Obwohl PII-Shield hochoptimiert ist, erfordert die tiefe Inspektion komplexer Logs sorgfältige Aufmerksamkeit bei der Konfiguration.

• Text-Logs: Extrem schnell (>100k Zeilen/s).
• JSON-Logs: Parsing ohne Speicherallokation (kein encoding/json-Overhead). Der Scanner analysiert JSON-Strukturen manuell, um einen hohen Durchsatz (~7MB/s) ohne Speicherspitzen zu gewährleisten.
• Empfehlung: Die Nutzung ist bei hohem Durchsatz sicher. Wir verwenden Rekursionsschutz, um Stack-Overflows bei tief verschachteltem JSON zu verhindern.

Installation

Helm-Chart (Kubernetes-Operator)

Der offizielle und empfohlene Weg, PII-Shield in Kubernetes bereitzustellen, ist über unseren vollautomatisierten Operator:

helm repo add pii-shield https://pii-shield.github.io/pii-shield/
helm repo update
helm install pii-shield-operator pii-shield/pii-shield-operator -n operator-system --create-namespace

Dies stellt den PII-Shield-Operator bereit, der automatisch hochsichere, distroless Sidecars in Ihre Pods injiziert, ohne dass Code- oder Dockerfile-Änderungen erforderlich sind.

Docker

Holen Sie sich das neueste schlanke Image von Docker Hub oder GHCR:

docker pull thelisdeep/pii-shield:2.2.0
# OR from GitHub Container Registry (Enterprise):
docker pull ghcr.io/pii-shield/pii-shield:2.2.0

Aus dem Quellcode erstellen

Sie können die Binärdatei direkt aus dem Quellcode erstellen:

go build -o pii-shield ./cmd/cleaner/main.go

Konfiguration

Eine vollständige Liste der Umgebungsvariablen finden Sie in CONFIGURATION.md, darunter:

• PII_SALT: Benutzerdefiniertes HMAC-Salt (für die Produktion erforderlich).
• PII_ADAPTIVE_THRESHOLD: Dynamische Entropie-Basislinien aktivieren.
• PII_DISABLE_BIGRAM_CHECK: Für nicht-englische Logs optimieren.
• PII_CUSTOM_REGEX_LIST: Benutzerdefinierte Regex-Regeln für deterministische Schwärzung.
• PII_SAFE_REGEX_LIST: Whitelist-Regex-Regeln, die ignoriert werden (Übereinstimmungen werden unverändert zurückgegeben).

Tabelle zur Entropie-Empfindlichkeit (Standard-Schwellenwert: 3.6)

Schnellstart

1. Lokal testen (CLI) Sie können jede Log-Ausgabe durch PII-Shield leiten, um es sofort in Aktion zu sehen:

# Emulate a log with a sensitive password
echo "Error: User password=MySecretPass123! failed login" | docker run -i --rm ghcr.io/pii-shield/pii-shield:2.2.0

# Output: Error: User password=[HIDDEN:8f3a11] failed login

2. Kubernetes (automatische Sidecar-Injektion) Mit installiertem PII-Shield-Operator ist der Schutz einer Anwendung so einfach wie das Erstellen einer PiiPolicy und das Labeln Ihrer Pods.

Eine Policy erstellen:

apiVersion: core.pii-shield.io/v1alpha1
kind: PiiPolicy
metadata:
  name: strict-policy
  namespace: default
spec:
  injectionMode: "file"

Ihr Deployment labeln:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: secure-app
spec:
  template:
    metadata:
      labels:
        pii-shield.io/inject: "true"
      annotations:
        pii-shield.io/policy: "strict-policy"
# ...

Der Operator injiziert automatisch den pii-shield-agent mithilfe des Native-Sidecar-Musters (K8s 1.28+) und maskiert alle Logs sicher!

📋 Kostenlos: 25-Punkte-Checkliste für das Kubernetes-Log-PII-Audit — wo PII aus Pods leckt, welche Log-Pfade Ihre Filter umgehen und wie Sie verifizieren, dass die Schwärzung tatsächlich funktioniert. Checkliste herunterladen →

📦 Compliance-Pakete (DSGVO/HIPAA/PCI) in Kürze verfügbar — frühen Zugang sichern →

💬 Nutzen Sie PII-Shield? Erzählen Sie uns von Ihrer Bereitstellung → — 2 Minuten, und es beeinflusst, was als Nächstes gebaut wird.

Verifizierung

Dieses Projekt wird mit einer wachsenden Testsuite verifiziert, die das Vertrauen vor der Produktionshärtung stärken soll:

1. Unit-Tests: Decken Randfälle, mehrsprachige Unterstützung und JSON-Integrität mit >85% Abdeckung ab.
2. Fuzzing: Natives Go-Fuzzing gewährleistet Absturzsicherheit gegen ungültige und zufällige Binäreingaben.
3. Smoke-Tests: ./scripts/test-smoke.sh testet gemischte Workloads und meldet die Erkennungsgenauigkeit.
4. End-to-End (E2E)-Tests: Die Suite operator/tests/run_e2e.sh führt eine Full-Stack-Validierung mit Minikube und Helm durch. Sie erstellt lokale Images, provisioniert den Operator ohne cert-manager, stellt Ziel-Jobs bereit und verifiziert die tatsächliche Log-Schwärzung, indem sie Sidecar-Ausgaben abfängt.

Leistungs-Benchmarks

Um den End-to-End-CLI-Durchsatz zwischen dem aktuellen Branch und einer Basis-Referenz zu vergleichen:

./benchmark/run_benchmarks.sh

Standardmäßig vergleicht der Benchmark HEAD mit origin/main, aktualisiert origin/main, erzeugt ein gemischtes Log-Korpus, wechselt die alte/neue Ausführungsreihenfolge und meldet Median, p95, min/max und MiB/s:

BASE_REF=origin/main RUNS=9 LINES=500000 ./benchmark/run_benchmarks.sh

Dies misst den vollständigen stdin-zu-stdout-CLI-Pfad. Für reine Scanner-Mikrobenchmarks führen Sie aus:

go test -bench=. -benchmem ./pkg/scanner

Operator-Integrationstests

Der Operator hält schnelle Unit-Tests von Kubernetes-API-Integrationstests getrennt. Reguläre Operator-Tests starten keinen lokalen API-Server:

cd operator
go test ./...

Um die auf envtest basierende Controller-Integrationssuite auszuführen:

./scripts/test-operator-integration.sh

Diese Tests starten einen lokalen Kubernetes-API-Server und etcd über envtest; daher benötigen sie die Berechtigung, an 127.0.0.1 zu binden. In eingeschränkten Sandboxes führen Sie sie in einer lokalen Shell, Docker-Umgebung oder auf einem CI-Runner aus, der Localhost-Bindungen erlaubt.

Support

PII-Shield ist eine Open-Source-Infrastruktur für datenschutzerhaltende Logs. Wenn dieses Projekt für Sie oder Ihre Organisation nützlich ist, können Sie seine Entwicklung über GitHub Sponsors unterstützen.

Release-Verifizierung

Hinweise zur Überprüfung von Release-Checksummen und Image-Digests sind in docs/release-verification.md dokumentiert. Signatur- und herkunftsgesicherte Releases werden im Rahmen der Roadmap zur Härtung der Lieferkette verfolgt.

Lizenz

Verteilt unter der Apache-2.0-Lizenz. Weitere Informationen finden Sie in LICENSE.