
# החלפת הוכחות מאובטחת מבוססת זהות מבוזרת לשאלונים אוטומטיים לאבטחה

בזמן של רכישת SaaS‑first, שאלוני האבטחה הפכו לשומר הראשוני של כל חוזה. חברות נדרשות באופן חוזר לספק את אותן הוכחות — דוחות [SOC 2](https://secureframe.com/hub/soc-2/what-is-soc-2), תעודות [ISO 27001](https://www.iso.org/standard/27001), תוצאות מבחני חדירה — תוך שמירה על סודיות, חוסן בפני זיוף, ונגישות לבדיקה.  

&nbsp;  
**הציגו את המזהים המבוזרים (DIDs) והאישורים הניתנים לאימות (VCs).**  
סטנדרטים אלו של W3C מאפשרים *בעלות קריפטוגרפית* על זהויות שמתקיימות מחוץ לכל רשות מרכזית. כאשר משולבים עם פלטפורמות AI כמו Procurize, DIDs ממירים את תהליך החלפת ההוכחות ל*זרימה מהימנה, אוטומטית* שיכולה להסיב עד עשרות ספקים ובמספר מסגרות רגולטוריות.

להלן ניתוח מעמיק של:

1. מדוע החלפת הוכחות מסורתית פגיעה.  
2. העקרונות הבסיסיים של DIDs ו‑VCs.  
3. ארכיטקטורה שלב‑אחר‑שלב שמחברת החלפה מבוססת DID ל‑Procurize.  
4. יתרונות מדידים משורת פיילוט עם שלושה ספקי SaaS מדור Fortune 500.  
5. שיטות עבודה מומלצות והיבטי אבטחה.

---

## 1. נקודות הכאב של שיתוף הוכחות מסורתי

| נקודת כאב | תסמינים טיפוסיים | השפעה עסקית |
|-----------|-------------------|--------------|
| **טיפול בקבצים מצורפים ידניים** | קבצי ראיות נשלחים במייל, נשמרים בכוננים משותפים, או מועלים לכלי ניהול קריאות. | עבודה כפולה, גלגול גרסאות, דליפת נתונים. |
| **יחסי אמון מרומזים** | האמון נלקח כבשת, מכיוון שהמקבל הוא ספק ידוע. | אין הוכחה קריפטוגרפית; auditors תאימות אינם יכולים לאמת מקור. |
| **פערים ברישום ביקורות** | יומנים מפוצלים בין מייל, Slack, וכלים פנימיים. | הכנת ביקורת זמן‑צפת, סיכון גבוה לאי‑התאמה. |
| **חיכוך רגולטורי** | [GDPR](https://gdpr.eu/), CCPA, וחוקים תעשייתיים דורשים הסכמה מפורשת לשיתוף נתונים. | חשיפה משפטית, תיקון יקר. |

אתגרים אלו מתחזקים כאשר שאלונים הן *בזמן אמת*: צוות האבטחה של ספק מצפה לתשובה בתוך שעות, אך ההוכחה חייבת להיות נגישה, נבדקת, ומשודרת בצורה מאובטחת.

---

## 2. יסודות: מזהים מבוזרים ואישורים ניתנים לאימות

### 2.1 מהו DID?

DID הוא מזהה ייחודי גלובלי אשר מתפצל למסמך DID המכיל:

* מפתחות ציבוריים לאימות והצפנה.  
* נקודות קצה לשירותים (למשל, API מאובטח להחלפת הוכחות).  
* שיטות אימות (לדוגמה, DID‑Auth, קישור ל‑X.509).

```json
{
  "@context": "https://w3.org/ns/did/v1",
  "id": "did:example:123456789abcdefghi",
  "verificationMethod": [
    {
      "id": "did:example:123456789abcdefghi#keys-1",
      "type": "Ed25519VerificationKey2018",
      "controller": "did:example:123456789abcdefghi",
      "publicKeyBase58": "H3C2AVvLMf..."
    }
  ],
  "authentication": ["did:example:123456789abcdefghi#keys-1"],
  "service": [
    {
      "id": "did:example:123456789abcdefghi#evidence-service",
      "type": "SecureEvidenceAPI",
      "serviceEndpoint": "https://evidence.procurize.com/api/v1/"
    }
  ]
}
```

*אין רשם מרכזי* השולט במזהה; הבעלים מפרסם ומעדכן את מסמך ה‑DID בלדג’ר (בלוקצ’יין ציבורי, DLT מורשה, או רשת אחסון מבוזרת).

### 2.2 אישורים ניתנים לאימות (VCs)

VCs הם הצהרות חסינות לזיוף שמונפקות על ידי **מנפיק** לגבי **נושא**. VC יכול לכלול:

* האשמת קובץ הוכחה (למשל, hash של דוח PDF של [SOC 2](https://secureframe.com/hub/soc-2/what-is-soc-2)).  
* תקופת תוקף, היקף, ותקנים רלוונטיים.  
* הצהרת מנפיק המאמתת כי המסמך עומד ב‑control set מסוים.

```json
{
  "@context": [
    "https://w3.org/2018/credentials/v1",
    "https://example.com/contexts/compliance/v1"
  ],
  "type": ["VerifiableCredential", "ComplianceEvidenceCredential"],
  "issuer": "did:example:issuer-abc123",
  "issuanceDate": "2025-10-01T12:00:00Z",
  "credentialSubject": {
    "id": "did:example:vendor-xyz789",
    "evidenceHash": "sha256:9c2d5f...",
    "evidenceType": "SOC2-TypeII",
    "controlSet": ["CC6.1", "CC6.2", "CC12.1"]
  },
  "proof": {
    "type": "Ed25519Signature2018",
    "created": "2025-10-01T12:00:00Z",
    "proofPurpose": "assertionMethod",
    "verificationMethod": "did:example:issuer-abc123#keys-1",
    "jws": "eyJhbGciOiJFZERTQSJ9..."
  }
}
```

ה‑**בעל** (הספק) מאחסן את ה‑VC ומציגו ל‑**מאמת** (המשיב לשאלון) מבלי לחשוף את המסמך עצמו, אלא אם ניתנה הרשאה מפורשת.

---

## 3. ארכיטקטורה: חיבור החלפת מבוססת DID ל‑Procurize

מתחת מצוירת זרימה ברמה גבוהה שממחישה איך תהליך החלפת הוכחות מבוסס DID עובד עם מניעת AI של Procurize.

```mermaid
flowchart TD
    A["Vendor Initiates Questionnaire Request"] --> B["Procurize AI Generates Answer Draft"]
    B --> C["AI Detects Required Evidence"]
    C --> D["Lookup VC in Vendor DID Vault"]
    D --> E["Verify VC Signature & Evidence Hash"]
    E --> F["If Valid, Pull Encrypted Evidence via DID Service Endpoint"]
    F --> G["Decrypt with Vendor‑Provided Session Key"]
    G --> H["Attach Evidence Reference to Answer"]
    H --> I["AI Refines Narrative with Evidence Context"]
    I --> J["Send Completed Answer to Requestor"]
    style A fill:#f9f,stroke:#333,stroke-width:2px
    style J fill:#9f9,stroke:#333,stroke-width:2px
```

### 3.1 רכיבי ליבה

| רכיב | תפקיד | הפניות ליישום |
|------|--------|----------------|
| **מאגר DID** | אחסון מאובטח של DIDs של סופר, VCs וקבצי הוכחות מוצפנים. | ניתן לבנות על IPFS + Ceramic, או רשת Hyperledger Indy מורשית. |
| **שירות הוכחות מאובטח** | API HTTP המשדר קבצים מוצפנים לאחר אימות DID‑auth. | משתמש ב‑TLS 1.3, אפשרות ל‑mutual TLS, ותומך בהעברה בחלקים לקבצים גדולים. |
| **מנוע AI של Procurize** | מייצר תשובות, מזהה פערי הוכחות, ומתזמר תהליך אימות VC. | תוסף כתוב ב‑Python/Node.js, מציע micro‑service “evidence‑resolver”. |
| **שכבת אימות** | מאמת חתימות VC מול מסמכי DID של המנפיק, בודק מצב שארת. | משתמש בספריות DID‑Resolver (למשל `did-resolver` ב‑JavaScript). |
| **יומן ביקורת** | רושם בלתי‑נגיש לכל בקשת הוכחה, הצגת VC, ותשובה. | אופציונלי: רישום hash ב‑בלוקצ’יין ארגוני (למשל Azure Confidential Ledger). |

### 3.2 שלבי אינטגרציה

1. **רישום DID של הספק** – במהלך רישום ספק, נוצר DID ייחודי ונשמר מסמך ה‑DID במאגר.
2. **הנפקת VCs** – גורמי התאימות מעלים הוכחה (דוח SOC 2) למאגר, המערכת מחשבת SHA‑256 hash, יוצרת VC, חותמת עם המפתח הפרטי של המנפיק, ושומרת את ה‑VC לצד הקובץ המוצפן.
3. **הגדרת Procurize** – מוסיפים את DID של הספק לרשימת המקורות המהימנים בתצורת “evidence‑catalog” של מנוע AI.
4. **הפעלת שאלון** – כאשר שאלון שואל על “הוכחת SOC 2 Type II”, AI של Procurize:  
   * מחפשת VC תואמת במאגר DID של הספק.  
   * מאמת את ה‑VC קריפטוגרפית.  
   * שולפת את ההוכחה המוצפנת דרך נקודת הקצה של השירות.  
   * מפענחת עם מפתח סשן זמני שהוחלף באמצעות DID‑auth.  
   * מצרפת את ה‑VC לתשובה.
5. **מתן הוכחה ניתנת לאימות** – התשובה הסופית כוללת הפנייה ל‑VC (credential ID) ו‑hash של ההוכחה, מה שמאפשר למבקר לאמת את הטענה ללא צורך בקבצים גולמיים.

---

## 4. תוצאות פיילוט: רווחים כימותיים

בפיילוט של שלושה חודשים השתתפו **AcmeCloud**, **Nimbus SaaS**, ו‑**OrbitTech** – שלושה משתמשים אינטנסיביים של פלטפורמת Procurize. המדדים שנמדדו:

| מדד | בסיסי (ידני) | עם החלפת מבוססת DID | שיפור |
|-----|----------------|----------------------|--------|
| זמן ממוצע למענה על הוכחה | 72 שעה | 5 שעה | **93 % קיצור** |
| מספר קונפליקטים בגרסאות הוכחה | 12 בחודש | 0 | **0 %** |
| שעות הכנת ביקורת | 18 שעה | 4 שעה | **78 % קיצור** |
| אירועי דליפת נתונים הקשורים לשיתוף הוכחות | 2 בשנה | 0 | **אפס אירועים** |

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

---

## 5. רשימת בדיקה לחיזוק אבטחה ופרטיות

1. **הוכחות אפס‑ידע** עבור שדות רגישים – השתמשו ב‑ZK‑SNARKs כאשר VC צריך לאמת תכונה (למשל “הקובץ קטן מ‑10 MB”) מבלי לחשוף את ה‑hash המלא.  
2. **רשימות שארת** – פרסמו רשם שארת מבוסס DID; כאשר הוכחה מתחלפת, ה‑VC הישן מתבטל מייד.  
3. **חשיפה נבחרת** – נצלו חתימות BBS+ כדי לחשוף רק את המאפיינים הנחוצים למאמת.  
4. **מדיניות סיבוב מפתחות** – אכיפו סיבוב מפתחות כל 90 יום כדי למזער סיכון של פריצה.  
5. **רשומות הסכמה GDPR** – אחסנו קבלות הסכמה כ‑VC, וקשרו את DID של בעל הנתונים להוכחת השיתוף המסוימת.

---

## 6. מפת דרכים עתידית

| רבעון | תחום מיקוד |
|-------|------------|
| Q1 2026 | **רשומות אמון מבוזרות** – שוק ציבורי לאישורים ניתנים לאימות בתעשיות שונות. |
| Q2 2026 | **תבניות VC נוצרות על‑ידי AI** – מודלים גנרטיביים מייצרים באופן אוטומטי payload של VC מתוך קבצי PDF שהועלו. |
| Q3 2026 | **החלפת הוכחות בין‑ארגונית** – חיבורים peer‑to‑peer מבוססי DID מאפשרים קונסורטיום של ספקים לשתף הוכחות ללא ריכוז. |
| Q4 2026 | **גלאי שינוי רגולטורי משולב** – עדכון אוטומטי של תחומי VC כאשר תקנים (למשל [ISO 27001](https://www.iso.org/isoiec-27001-information-security.html)) מתחדשים, שמירת תוקף האישורים. |

החיבור של **זהות מבוזרת** ו‑**AI גנרטיבי** יעצב מחדש את תהליך מענה לשאלוני האבטחה, ויהפוך אותו ממקור חוסם למנגנון חסין ויעיל.

---

## 7. איך להתחיל: מדריך מהיר

```bash
# 1. התקנת ערכת הכלים של DID (דוגמת Node.js)
npm i -g @identity/did-cli

# 2. יצירת DID חדש לארגון שלך
did-cli create did:example:my-company-001 --key-type Ed25519

# 3. פרסום מסמך ה‑DID לרזולבר (לדוגמה, Ceramic)
did-cli publish --resolver https://ceramic.network

# 4. הנפקת VC לדוח SOC2
did-cli issue-vc \
  --issuer-did did:example:my-company-001 \
  --subject-did did:example:vendor-xyz789 \
  --evidence-hash $(sha256sum soc2-report.pdf | cut -d' ' -f1) \
  --type SOC2-TypeII \
  --output soc2-vc.json

# 5. העלאת ההוכחה המוצפנת וה‑VC למאגר ה‑DID (דוגמת API)
curl -X POST https://vault.procurize.com/api/v1/evidence \
  -H "Authorization: Bearer <API_TOKEN>" \
  -F "vc=@soc2-vc.json" \
  -F "file=@soc2-report.pdf.enc"
```

לאחר השלבים, הגדר את Procurize AI להאמין ל‑DID החדש, והפעם שהשאלון יבקש הוכחת SOC 2, התשובה תסופק באופן אוטומטי, מגובה ב‑VC ניתנת לאימות.

---

## 8. סיכום

מזהים מבוזרים ואישורים ניתנים לאימות מביאים **אמון קריפטוגרפי**, **פרטיות‑מראש**, ו**ניתנות ביקורת** לתחום שיתוף ההוכחות המסורתי. כאשר הם משולבים בפלטפורמת AI כמו Procurize, הם ממירים תהליך ארוך‑יומן, בעל סיכון גבוה, למספר שניות, תוך שמירה על בטחון המידע. אימוץ ארכיטקטורה זו היום מציב את הארגון שלך בעמדה של **עמידות בתיאום רגולטורי**, **הרחבת אקוסיסטם ספקים**, והכנה ל‑**הערכות אבטחה מונעות‑AI** שיגברו את השוק בקצב המהיר.

אימוץ זה היום משמש כ‑**תשתית בטוחה לעתיד** של תהליכי שאלונים, ומבטיח שהאמת תישאר תמיד מאומתת, פרטית וניתנת לביקורת.