קטלוג זיהוי ישויות וספר חוקי אכיפה (Entity Detection Catalog & Rulebook)

פרויקט: zer0pii.ai - Enterprise AI Security Gateway & DLP

גרסה: 1.0.0-CATALOG

סיווג: מפרט טכני ומדריך הגדרות אכיפה (Detection Specification & Configuration Reference)

יעד: מהנדסי אבטחת מידע, ארכיטקטי DLP, צוותי SOC ומהנדסי פיתוח Gateway

1. ארכיטקטורת מנוע הזיהוי התלת-שכבתי (Three-Tier Detection Pipeline)

שער zer0pii.ai אינו מסתמך על מודל בודד או על רג'קסים עיוורים. כל פיסת טקסט מעובדת דרך שלוש שכבות סריקה מקבילות וטוריות המותאמות לתקציב שיהוי כולל של פחות מ-15ms:

                      [ Incoming Text Stream / Prompt ]
                                      │
                                      ▼
             ┌─────────────────────────────────────────────────┐
             │ Layer 0: AST & Code Syntax Boundary Protection  │
             │ (Exempts variables, imports, schemas, backticks)│
             └────────────────────────┬────────────────────────┘
                                      │
                 ┌────────────────────┴────────────────────┐
                 ▼                                         ▼
   ┌───────────────────────────┐             ┌───────────────────────────┐
   │ Layer 1: Deterministic    │             │ Layer 2: Structural &     │
   │ Algorithmic Engine        │             │ High-Entropy Scanner      │
   │ • Regex + Checksums       │             │ • Shannon Entropy (>4.3)  │
   │ • Luhn, ISO stdnum        │             │ • Connection Strings URIs │
   │ • Runtime: 0.2ms - 1.2ms  │             │ • Cloud Provider Patterns │
   │ • Confidence: 0.95 - 1.00 │             │ • Runtime: 0.3ms - 0.8ms  │
   └─────────────┬─────────────┘             └─────────────┬─────────────┘
                 │                                         │
                 └────────────────────┬────────────────────┘
                                      │
                                      ▼
             ┌─────────────────────────────────────────────────┐
             │ Layer 3: Semantic NER Engine (GLiNER ONNX FP16) │
             │ • Multilingual: Hebrew, English, Arabic, EU     │
             │ • Contextual: Names, Locations, Organizations   │
             │ • Runtime Budget: 8.0ms - 12.0ms (Timeout: 20ms)│
             │ • Confidence: 0.60 - 0.95                       │
             └─────────────────────────────────────────────────┘

אלגוריתם חישוב מדד הסיכון (Composite Risk Index)

כל מופע שזוהה מקבל ניקוד המשקלל את רמת הוודאות של המנוע עם חומרת הנזק לארגון:

$$\text{Risk Score} = \text{Confidence} \times \text{Severity}$$

• Confidence (0.00 - 1.00): רמת הוודאות האלגוריתמית (1.00 = Checksum מתמטי מאומת; 0.70 = זיהוי שמי מבוסס הקשר מודל).
• Severity (1 - 100): מוגדרת מראש בספר החוקים (סודות תשתית = 100, מספרי זהות = 90, שמות פרטיים = 30).
• מדיניות אכיפה:
• Risk Score >= 80: מיסוך קשיח או חסימה אקטיבית מיידית.
• 50 <= Risk Score < 80: מיסוך שקט ורישום א-סינכרוני ל-Review Queue בדשבורד.
• Risk Score < 50: מעבר ללא שינוי (Pass-Through) למניעת שבירת פרומפטים.

2. מזהים ממשלתיים ואזרחיים (National & Government IDs)

זיהוי מזהים ממשלתיים נשען תמיד על אימות מתמטי (Checksum Validation) באמצעות מודולי python-stdnum. אם מספר מתאים לתבנית אך נכשל בספרת הביקורת, הוא מסווג כסתם רצף ספרות ואינו ממוסך.

3. נתונים פיננסיים, כרטיסי אשראי ובנקאות (Financial & Payments)

4. תשתיות ענן, מפתחות סודיים וקובצי תצורה (Secrets & Credentials)

קטגוריה זו מוגדרת ברמת חומרה 100. ברירת המחדל בשער היא חסימה מוחלטת של הבקשה (HTTP 403) או מיסוך ללא תלות בספים סטטיסטיים.

4.1 מפתחות ספקים מובנים (High-Confidence Heuristics)

4.2 מחרוזות חיבור (Connection Strings & Database URIs)

השער מפעיל מפענח URI ייעודי שמחלץ את הסיסמה בלבד וממסך אותה, מבלי לפגוע במבנה הכתובת כדי לא לשבור בדיקות קוד:

• תבנית קלט:

postgresql://db_admin:P@ssw0rd123!@postgres.internal.corp:5432/finance_db

• פלט ממוסך המועבר ל-LLM:

postgresql://db_admin:[PASSWORD_01_7c2b]@postgres.internal.corp:5432/finance_db

• נתמך עבור פרוטוקולים: postgres://, mysql://, mongodb://, mongodb+srv://, redis://, rediss://, amqp://, mssql://.

4.3 מנוע אנטרופיה לאיתור סודות חופשיים (Shannon Entropy Engine)

מחרוזות שאינן מתאימות לתבנית של ספק ספציפי נסרקות באמצעות חישוב אנטרופיית המידע של שאנון:

$$H(X) = -\sum_{i=1}^{n} P(x_i) \log_2 P(x_i)$$

• תנאי סף לסיווג כ-GENERIC_HIGH_ENTROPY_SECRET:

1. המחרוזת מורכבת מתווים רציפים ללא רווחים באורך של 20 תווים ומעלה.
2. ציון האנטרופיה H(X) >= 4.30 (עבור ערכת תווים אלפא-נומרית) או >= 4.75 (עבור ערכת Base64 מורחבת).
3. המחרוזת אינה מילה מוכרת במילון אנגלי/עברי ואינה כתובת Hash של Git Commit (40 תווים הקסדצימליים ללא תווים מיוחדים מקבלים החרגה ייעודית).

5. מידע בריאותי מוגן (HIPAA / Protected Health Information - PHI)

התאמה מלאה לתקן Safe Harbor של חוק ה-HIPAA האמריקאי, הדורש סילוק של 18 מזהים ספציפיים:

6. פרטי התקשרות ומידע אישי רב-לשוני (General PII & Contact Data)

7. מטריצת אסטרטגיות מיסוך ושימור טיפוסי נתונים (Masking & Type-Preservation Matrix)

שער zer0pii תומך בשלוש אסטרטגיות מיסוך שונות הנבחרות אוטומטית בהתאם להקשר הבקשה:

8. מטריצת חריגות תחביריות והגנת מפתחים (AST & Code Block Exceptions)

כדי להבטיח מהימנות של 100% עבור מפתחים ולמנוע שבירת קוד, מחרוזות הנמצאות בתוך ההקשרים הבאים אינן ממוסכות לעולם, אלא אם הן מציגות אנטרופיה קיצונית (H >= 4.8) המעידה על מפתח ענן קשיח:

┌─────────────────────────────────────────────────────────────────────────────┐
│                          EXEMPTION CONTEXT RULES                            │
├─────────────────────────────────────────────────────────────────────────────┤
│ 1. Markdown Fenced Code Blocks (```python ... ```, ```json ... ```)        │
│    • שמות משתנים (user_id, client_name, email) אינם נסרקים כ-PII.         │
│    • שמות פונקציות ומחלקות (def get_customer_records) מוגנים לחלוטין.       │
│                                                                             │
│ 2. Inline Code Spans (`import pandas as pd`, `const id = 123`)              │
│    • כל טקסט התחום בגרש בודד (Backtick) מוגן ממיסוך שמי או מספרי.          │
│                                                                             │
│ 3. Package Imports & System Dependencies                                    │
│    • שורות המתחילות ב-import, from, require, #include לעולם אינן נסרקות.    │
│    • שמות ספריות מוכרות (כגון "requests", "numpy") מוחרגים אוטומטית.       │
│                                                                             │
│ 4. JSON Schema Keys & Field Identifiers                                     │
│    • במבני JSON, רק הערך (Value) נסרק. המפתח (Key) מוגן באופן מוחלט.       │
└─────────────────────────────────────────────────────────────────────────────┘

דוגמת אימות מעשית: קוד מפתח לפני ואחרי המיסוך

• פרומפט מפתח מקורי שנשלח לשער:

import os
import requests

# User complaint from David Cohen, ID: 012345672
user_name = "David Cohen"
user_email = "david@corp.com"
AWS_KEY = "AKIAIOSFODNN7EXAMPLE"

def fetch_data():
    return requests.get(f"https://api.corp.com/users/{user_name}")

• הטקסט שמגיע בפועל לספק ה-LLM החיצוני:

import os
import requests

# User complaint from [PERSON_01_a8f9], ID: [IL_ID_01_7c2b]
user_name = "[PERSON_01_a8f9]"
user_email = "[EMAIL_01_3d1e]"
AWS_KEY = "[AWS_KEY_BLOCKED]"

def fetch_data():
    return requests.get(f"https://api.corp.com/users/{user_name}")

הערה: מבנה הקוד, שמות המשתנים (user_name, user_email), שמות הפונקציות ופקודות ה-import נותרו ללא שינוי. רק הנתונים הרגישים מוסכו באופן שקוף.

הערה מקומית (build): בטבלת 4.1 המקורית, מספר תאי Regex הגיעו קטועים בשל שבירת טבלת Markdown על תווי | בתוך הביטויים - הושלמו כאן לפי התבניות המקובלות של הספקים מבלי לשנות את הכוונה.