PII-Shield 🛡️

Zero-Code-Log-Sanitisierungs-Sidecar für Kubernetes. Verhindert Datenlecks (GDPR/SOC2), indem PII aus Logs bevor sie den Pod verlassen, geschwärzt wird.

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 erspart Ihnen ein von der GDPR erzwungenes Modell-Retraining.

[!WARNING] Upgrade auf v2.0.0? Wir haben die Endnutzer-Distribution auf Helm-basierte Installationen und Distroless Native Sidecars umgestellt. Kustomize ist kein unterstützter Release-Installationspfad mehr für Produktionsnutzer, obwohl das Operator-Repository weiterhin Kustomize-Gerüst 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 zur Integration in Ihren Stack:

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

Projektstatus & Roadmap

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

Siehe KNOWN_LIMITATIONS.md für die aktuellen Produktions-Härtungsgrenzen.

Warum PII-Shield?

Entwickler vergessen oft, sensible Daten zu maskieren. Traditionelle 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:

• Produktions-Härtungs-Kern-Engine: Optimiert für Kubernetes-Sidecars mit geringen Speicherzuweisungen auf heißen Pfaden und deterministischem Regex-Abgleich.
• Kontextbewusste Entropie-Analyse: Erkennt Geheimnisse mit hoher Entropie auch ohne Schlüssel (z. B. Error: ... 44saCk9...) durch Analyse von Kontext-Keywords.
• Benutzerdefinierte Regex-Regeln: Deterministische Schwärzung für strukturierte Daten (UUIDs, IDs), die Entropieprüfungen für bekannte Muster überschreibt.
• Regressions- & Fuzz-Abdeckung: Getestet gegen Stressfälle einschließlich binärem Müll, JSON-Verschachtelung und mehrsprachigen Logs.
• Deterministisches Hashing: Ersetzt Geheimnisse durch eindeutige Hashes (z. B. [HIDDEN:a1b2c]), sodass die 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 explizit sichere Muster (z. B. Git-Hashes, System-IDs) mithilfe von PII_SAFE_REGEX_LIST, um Fehlalarme zu verhindern.

Verwalten Sie PII-Shield über Dutzende von Clustern?

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

Integrationen

Der In-Process-WASM-Build von PII-Shield wird innerhalb von GuardSpine Code ausgeliefert, einer Open-Source-KI-Code-Governance-GitHub-Action, die die Binärdatei bündelt und in ihrer NOTICE angibt.

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 Allokationen (kein encoding/json-Overhead). Der Scanner parst JSON-Strukturen manuell, um einen hohen Durchsatz (~7MB/s) ohne Speicherspitzen zu gewährleisten.
• Empfehlung: Die Nutzung ist für hohen Durchsatz sicher. Wir verwenden Rekursions-Sicherheitsvorkehrungen, 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.3
# ODER aus der GitHub Container Registry (Enterprise):
docker pull ghcr.io/pii-shield/pii-shield:2.2.3

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

Siehe CONFIGURATION.md für eine vollständige Liste der Umgebungsvariablen, einschließlich:

• PII_SALT: Benutzerdefiniertes HMAC-Salt (Erforderlich für die Produktion).
• PII_ADAPTIVE_THRESHOLD: Aktiviert dynamische Entropie-Baselines.
• PII_DISABLE_BIGRAM_CHECK: Optimiert für nicht-englische Logs.
• PII_CUSTOM_REGEX_LIST: Benutzerdefinierte Regex-Regeln für deterministische Schwärzung.
• PII_SAFE_REGEX_LIST: Whitelist-Regex-Regeln zum Ignorieren (Übereinstimmungen werden unverändert zurückgegeben).

Entropie-Empfindlichkeitstabelle (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:

# Ein Log mit einem sensiblen Passwort emulieren
echo "Error: User password=MySecretPass123! failed login" | docker run -i --rm ghcr.io/pii-shield/pii-shield:2.2.3

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

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

Eine Richtlinie erstellen:

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

Ihr Deployment beschriften:

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 sicher alle Logs!

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

📦 GDPR-Compliance-Paket — jetzt verfügbar (Early Access): 40+ getestete Schwärzungsregeln, DPO-fähige Dokumente, Audit-Trail-Vorlagen. $149 → · HIPAA/PCI auf der Warteliste →

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

Verifizierung

Dieses Projekt wird mit einer wachsenden Testsuite verifiziert, die das Vertrauen vor der Produktionshärtung erhöhen soll:

1. Unit-Tests: Abdecken von Randfällen, mehrsprachiger Unterstützung und JSON-Integrität mit >85% Abdeckung.
2. Fuzzing: Natives Go-Fuzzing gewährleistet Absturzsicherheit gegen ungültige und zufällige Binäreingaben.
3. Smoke-Tests: ./scripts/test-smoke.sh übt 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, stellt den Operator ohne cert-manager bereit, setzt Ziel-Jobs ein und verifiziert die tatsächliche Log-Schwärzung durch Abfangen der Sidecar-Ausgaben.

Leistungs-Benchmarks

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

./benchmark/run_benchmarks.sh

Standardmäßig vergleicht der Benchmark HEAD mit origin/main, aktualisiert origin/main, generiert ein gemischtes Log-Korpus, wechselt die alte/neue Ausführungsreihenfolge ab 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 Scanner-only-Mikrobenchmarks führen Sie Folgendes aus:

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

Operator-Integrationstests

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

cd operator
go test ./...

Um die envtest-basierte 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, sich an 127.0.0.1 zu binden. In eingeschränkten Sandboxes führen Sie sie in einer lokalen Shell, Docker-Umgebung oder einem CI-Runner aus, der Localhost-Bind zulässt.

Unterstützung

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

Anleitungen zur Verifizierung von Release-Checksummen und Image-Digests sind in docs/release-verification.md dokumentiert. Signatur- und Provenienz-gestützte Releases werden als Teil der Supply-Chain-Härtungs-Roadmap verfolgt.

Lizenz

Verteilt unter der Apache-2.0-Lizenz. Siehe LICENSE für weitere Informationen.