API: ההבדל בין טוקניזציה, הצפנה ואסימוני גישה

פורסם 08/05/2026 · עודכן 07/11/2026 · ממשקי API ואינטגרציות · 5 דקות קריאה · מאת Cyber Intelligence Embassy

בקצרה

אסימון שמחליף מידע רגיש ואסימון שמציג הרשאת גישה ממלאים תפקידים שונים. תחום השימוש ובדיקות הרשאה בשרת נשארים חיוניים.

במאמר זה

ערך חלופי עדיין עלול ליצור סיכון

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

להגן על הערוץ ולבדוק כל פעולה

TLS מגן על תעבורה בין נקודות הסיום שלו, אך אינו מתקן הרשאות לקויות או שרת שנפרץ. JWT חתום אינו בהכרח מוצפן ותוכנו עשוי להיות קריא. יש לאמת חתימה, מנפיק, נמען ותוקף לפי הפרוטוקול, ואז לבדוק זכויות לאובייקט. ב־OAuth יש להסתמך על RFC 9700 ולקבוע משך חיים, ביטול והגנה משימוש חוזר בהתאם למבנה.

שלושה מנגנונים וגבולות ההגנה

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

מקורות ותחום תחולה

בדיקה עריכתית: 31 באוקטובר 2026.

אין לבלבל נתונים מוגנים עם פעולות מורשות.

הצפנה וטוקניזציה מפחיתות חלק מחשיפת הנתונים אך אינן מחליטות האם קריאה ל-API עשויה לקרוא אובייקט או להפעיל פעולה. OWASP מפרט הרשאה ברמת האובייקט והפונקציה בין סיכוני ה-API העיקריים.

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

מקור ראשוני: OWASP API Security Top 10 — 2023. שיטה קשורה: קריאת המדריך המעשי.

Passkeys: הכנה לשינוי דומיין ו־RP ID

להפריד בין חשבון, מקור אינטרנט ו־RP ID כדי למנוע קישור מחדש שקט של פרטי הזדהות.

תעדו מקורות ישנים וחדשים, RP ID וחשבונות קשורים. שם חשבון זהה אינו הופך passkey לתקף עבור RP ID אחר. בדקו צירופים מותרים ב־WebAuthn ונתיבי גישה זמינים בזמן המעבר.
בסביבת בדיקה מורשית בדקו challenge, מקור, RP ID ושיוך חשבון בספרייה מתאימה. נסו מקור לא צפוי ואתגר חוזר. שינוי RP ID דורש רישום חדש לאחר אימות; העתקת שורה אינה מעבירה מפתח.
בדקו משתמש עם פרטי הזדהות ישנים בלבד, שחזור וסשנים פתוחים. קבעו פתיחת נתיבים וסגירתם עם חזרה שנבדקה. רישום בדומיין חדש אינו מוכיח ביטול כל הסשנים הישנים.

מקרה קבלה שניתן לשחזר

דוגמה בדיונית: הנתונים אינם מתארים לקוח או תוצאה שנצפתה.

הצגת נתוני המקרה

{
    "old_origin": "https://login.old.example",
    "old_rp_id": "old.example",
    "new_origin": "https://login.new.example",
    "new_rp_id": "new.example",
    "same_service_account": true,
    "expected": "authenticated_new_registration"
}

החלטה צפויה

דוגמה בדיונית: החשבון זהה, אך old.example נעשה new.example עם RP ID אחר. אין לקשר מחדש בשקט את פרטי ההזדהות הישנים; הרישום החדש עובר בנתיב האימות המתוכנן.

W3C — Web Authentication Level 2

האם שינוי במסד יכול לשנות RP ID של passkey?

לא. RP ID הוא חלק מהתחום המאומת של פרטי ההזדהות. הכינו רישום תקף בתחום החדש ושיוך חשבון לאחר אימות.

מקור ראשוני: W3C — Web Authentication Level 2. שיטה קשורה: קריאת המדריך המעשי.

חידוש TLS: לבדוק את התעודה המוגשת בפועל

לעקוב אחרי חידוש עד נקודות TLS והלקוחות לפני סיום השינוי.

רשמו שמות, CDN, מאזני עומס, פרוקסי וחיבורים פנימיים עם תעודות. תעדו תעודה מוגשת, שרשרת, תפוגה ואחראי. הנפקה אינה מוכיחה התקנה בכל צומת. הגנו על מפתחות פרטיים ואל תכללו אותם ברישום.
בדקו אוטומציה בסביבת בדיקה של הספק אם קיימת. בדקו אתגרי אימות, שמות SAN, אחסון מוגן וטעינה מחדש. הימנעו מהנפקה בכל הפעלה כשקיימת תעודה שימושית לפי מדיניות המפתחות.
בדקו שמות, תאריכים ושרשרת אמון בלקוחות נתמכים ובנתיבים רלוונטיים. השאירו אימות TLS פעיל. נטרו תפוגת תעודה מוגשת ולא רק מתזמן. חזרה דורשת תעודה תקפה ומפתח שלא נחשף; אחרת תקנו או בודדו נקודה.

מקרה קבלה שניתן לשחזר

דוגמה בדיונית: הנתונים אינם מתארים לקוח או תוצאה שנצפתה.

הצגת נתוני המקרה

{
    "issuance_succeeded": true,
    "proxy_count": 2,
    "proxies_serving_expected_certificate": 1,
    "other_proxy_certificate_expired": true,
    "tls_verification_enabled": true,
    "expected": "change_incomplete_fix_and_verify_client_paths"
}

החלטה צפויה

דוגמה בדיונית: החידוש הצליח אך אחד משני פרוקסי מגיש תעודה שפגה. השינוי לא הושלם; תקנו ובדקו נתיבי לקוח בלי לבטל אימות TLS.

Let’s Encrypt — Integration Guide

מקור ראשוני: Let’s Encrypt — Integration Guide. שיטה קשורה: קריאת המדריך המעשי.

מקורות: נתונים, שימושים ומגבלות

מועד בדיקת התיעוד 2026-10-22.

הערות המקורות המפורטות זמינות באנגלית במהדורה זו.

מקורות: נתונים, שימושים ומגבלות
מקור ומטרה	נתון או מדד מאומת	כיצד להשתמש	מגבלה שיש לשמר
MITRE · Common Weakness Enumeration Name classes of software and hardware weakness.	A CWE describes a weakness that can contribute to vulnerabilities. It does not represent a particular incident.	Connect the weakness to the observed mechanism: input, processing and missing control. Use it to fix the cause and plan regression tests. העמקה בשיטה →	A keyword in a report alone does not establish the correct CWE classification.
OASIS · TAXII 2.1 Exchange threat intelligence through an application protocol.	TAXII 2.1 is an OASIS Standard dated 10 June 2021. It includes service discovery and access to collections.	Test authentication, collection permissions, pagination and recovery after interruption. Record which objects were actually received and processed. העמקה בשיטה →	TAXII transports data; it replaces neither the content model nor assessment of reliability.

עיון בקטלוג CISA KEV

הערות המקורות המפורטות זמינות באנגלית במהדורה זו.

One identifier can span several technical layers

An entry may concern a library, server or component embedded in an appliance. Search the exact name, known dependencies and the distributed product’s advisory. Catalogue aliases are not a complete list of affected versions.

Connect the CVE, component supplier and final-product supplier.
Check version, configuration and execution path in the authorised environment.
Do not infer remediation from an empty search result.

עיון בקטלוג ובשיטה →

CISA KEV · 2026.11.06 · Documentary review : 2026-11-07

מדיה: טיהור וראיות

הערות המקורות המפורטות זמינות באנגלית במהדורה זו.

Encryption and erasure require different evidence

Encryption protects access while keys and implementation retain their properties. Cryptographic erase requires suitable encrypted scope and sanitization of relevant keys; it does not follow from API-token removal.

Map data-encryption, wrapping and derivation keys and external copies.
Check whether target sensitive data previously existed in plaintext.
Record technical outcome, limits and validation without retaining secrets in the evidence.

Read the methods, evidence points and annotated situations →

NIST · SP 800-88 Rev. 2 · Guidelines for Media Sanitization · Final · 2025-09-26 · consulted 2026-10-23