PII-Shield 🛡️

Kubernetes向けゼロコード・ログサニタイズサイドカー。 PIIをログからポッドの外部に出る前に編集することで、データ漏えい（GDPR/SOC2）を防ぎます。

PII-Shieldはインプロセスで動作します — CLI、サイドカー、またはWASM。ホスト型APIも、データが送信されるサーバーもありません。

「PIIをAIモデルに混入させないでください。」PII-Shieldは、機密データがトレーニングデータセットに届かないようにし、GDPRによるモデル再トレーニングの強制からあなたを守ります。

[!WARNING] v2.0.0にアップグレードしますか？ エンドユーザー向け配布をHelmベースのインストールとDistroless Native Sidecarに移行しました。Kustomizeは本番ユーザー向けのリリースインストール経路としてはサポートされなくなりましたが、オペレーターリポジトリにはローカル開発とマニフェスト生成用のKustomize足場が引き続き維持されています。PII-Shieldサイドカー内の/bin/shアクセスはサポートされなくなりました。移行ガイドをお読みください。

2つのデプロイモデル

PII-Shieldは、スタックに統合するための2つの異なる方法を提供します:

1. Kubernetes Operator（ゼロコード）: 主力のデプロイモデル。完全自動化されたK8s Operatorが、高度にセキュアなDistrolessサイドカーをポッドに注入し、ログをその場で傍受・サニタイズします。
2. プロセス内WASM（コア統合向け）: 極限のパフォーマンスを求める場合、コアエンジンをWASM経由で直接埋め込むことができ、ネットワークホップなしで<1msのレイテンシを実現します。

プロジェクトステータスとロードマップ

PII-Shieldは、本番強化段階にある活発に開発されたオープンソースのセキュリティツールです。v2.xリリースラインは、実用的なCLI、コンテナ、Helm/Operator、WASM SDKのアーティファクトを出荷しています。コアの編集パスは管理されたデプロイに対応していますが、一部のKubernetesデプロイモードとサプライチェーン保証はまだ安定化中です。

現在の本番強化の境界については、KNOWN_LIMITATIONS.mdを参照してください。

PII-Shieldを選ぶ理由

開発者は機密データのマスキングを忘れがちです。Fluentd/Logstashの従来の正規表現フィルターは低速で、メンテナンスが難しく、ログ集約サーバーで高価なCPUを消費します。

PII-Shieldはアプリコンテナのすぐ隣に配置されます:

• 本番強化コアエンジン: Kubernetesサイドカー向けに最適化されており、ホットパスでのメモリ割り当てが少なく、決定的な正規表現マッチングを実現します。
• コンテキスト認識エントロピー分析: キーがなくても高エントロピーのシークレット（例: Error: ... 44saCk9...）を、コンテキストキーワードを分析して検出します。
• カスタム正規表現ルール: 構造化データ（UUID、ID）に対する決定的な編集。既知のパターンに対するエントロピーチェックを上書きします。
• 回帰テストとファジングカバレッジ: バイナリゴミ、JSONのネスト、多言語ログなどのストレステストケースに対してテスト済みです。
• 決定論的ハッシュ: シークレットを一意のハッシュ（例: [HIDDEN:a1b2c]）に置き換え、QAが生データを見ずにエラーを関連付けられるようにします。
• ドロップイン: コード変更は不要です。任意の言語（Node、Python、Java、Go）で動作します。
• ホワイトリストサポート: PII_SAFE_REGEX_LISTを使用して安全なパターン（例: gitハッシュ、システムID）を明示的に許可し、誤検知を防ぎます。

数十のクラスターにわたってPII-Shieldを管理していますか？

集中管理されたルール管理、Slackアラート、編集分析を備えたホスト型コントロールプレーンを構築中です。

統合

PII-Shieldのプロセス内WASMビルドは、オープンソースのAIコードガバナンスGitHub ActionであるGuardSpine Codeに同梱されており、このActionはバイナリをベンダリングし、そのNOTICE内でクレジットを記載しています。

パフォーマンスに関する考慮事項

PII-Shieldは高度に最適化されていますが、複雑なログの深い検査には設定への細心の注意が必要です。

• テキストログ: 非常に高速（>10万行/秒）。
• JSONログ: ゼロアロケーション解析（encoding/jsonのオーバーヘッドなし）。スキャナーはJSON構造を手動で解析し、メモリスパイクなしで高スループット（約7MB/秒）を確保します。
• 推奨事項: 高スループットでの使用は安全です。深くネストされたJSONでのスタックオーバーフローを防ぐために、再帰セーフガードを使用しています。

インストール

Helmチャート（Kubernetes Operator）

KubernetesでPII-Shieldをデプロイする公式かつ推奨される方法は、完全自動化された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

これにより、PII-Shield Operatorがデプロイされ、コードやDockerfileの変更を必要とせずに、高度にセキュアなdistrolessサイドカーをポッドに自動的に注入します。

Docker

Docker Hubまたは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

ソースからビルド

ソースコードから直接バイナリをビルドできます:

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

設定

環境変数の完全なリストについてはCONFIGURATION.mdを参照してください。主なものは以下のとおりです:

• PII_SALT: カスタムHMACソルト（本番環境では必須）。
• PII_ADAPTIVE_THRESHOLD: 動的エントロピーベースラインを有効化。
• PII_DISABLE_BIGRAM_CHECK: 非英語ログ向けに最適化。
• PII_CUSTOM_REGEX_LIST: 決定的な編集のためのカスタム正規表現ルール。
• PII_SAFE_REGEX_LIST: 無視するホワイトリスト正規表現ルール（一致したものはそのまま返されます）。

エントロピー感度テーブル（デフォルトしきい値: 3.6）

クイックスタート

1. ローカルでテスト（CLI） 任意のログ出力をPII-Shieldにパイプすると、すぐに動作を確認できます:

# 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（自動サイドカー注入） PII-Shield Operatorがインストールされていれば、PiiPolicyを作成してポッドにラベルを付けるだけでアプリケーションを保護できます。

ポリシーを作成:

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

デプロイメントにラベルを付ける:

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"
# ...

OperatorはNative Sidecarパターン（K8s 1.28+）を使用してpii-shield-agentを自動的に注入し、すべてのログを安全にマスクします!

📋 無料: 25項目のKubernetesログPII監査チェックリスト — PIIがポッドからどこに漏れるか、どのログパスがフィルターを迂回するか、編集が実際に機能することを確認する方法。チェックリストを入手 →

📦 コンプライアンスパック（GDPR/HIPAA/PCI）近日公開 — 早期アクセスを申し込む →

💬 PII-Shieldを使用していますか？ デプロイについて教えてください → — 2分で、次に何を構築するかを形作ります。

検証

このプロジェクトは、本番強化の前に信頼性を高めることを目的とした、拡大を続けるテストスイートで検証されています:

1. ユニットテスト: エッジケース、多言語サポート、JSON整合性を85%以上のカバレッジでカバー。
2. ファジング: ネイティブGoファジングにより、無効かつランダムなバイナリ入力に対するクラッシュ安全性を確保。
3. スモークテスト: ./scripts/test-smoke.shが混合ワークロードを実行し、検出精度を報告。
4. エンドツーエンド（E2E）テスト: operator/tests/run_e2e.shスイートがMinikubeとHelmを使用してフルスタック検証を実行。ローカルイメージをビルドし、cert-managerなしでOperatorをプロビジョニングし、ターゲットJobをデプロイし、サイドカー出力を傍受して実際のログ編集を検証します。

パフォーマンスベンチマーク

現在のブランチとベースラインref間のエンドツーエンドCLIスループットを比較するには:

./benchmark/run_benchmarks.sh

デフォルトでは、ベンチマークはHEADをorigin/mainと比較し、origin/mainを更新し、混合ログコーパスを生成し、新旧の実行順序を交互にし、中央値、p95、最小/最大、およびMiB/秒を報告します:

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

これは完全なstdinからstdoutまでのCLIパスを測定します。スキャナーのみのマイクロベンチマークを実行するには:

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

Operator統合テスト

Operatorは、高速なユニットテストをKubernetes API統合テストから分離しています。通常のOperatorテストはローカルAPIサーバーを起動しません:

cd operator
go test ./...

envtestベースのコントローラー統合スイートを実行するには:

./scripts/test-operator-integration.sh

これらのテストはenvtestを通じてローカルKubernetes APIサーバーとetcdを起動するため、127.0.0.1へのバインド権限が必要です。制限されたサンドボックスでは、localhostバインドを許可するローカルシェル、Docker環境、またはCIランナーで実行してください。

サポート

PII-Shieldは、プライバシーを保護するログのためのオープンソースインフラストラクチャです。このプロジェクトがあなたやあなたの組織にとって有用であるなら、GitHub Sponsorsを通じて開発を支援できます。

リリース検証

リリースのチェックサムとイメージダイジェストの検証手順はdocs/release-verification.mdに文書化されています。署名および来歴に基づくリリースは、サプライチェーン強化ロードマップの一部として追跡されています。

ライセンス

Apache 2.0ライセンスの下で配布されています。詳細についてはLICENSEを参照してください。