טוקניזציה של נתונים רגישים של בעלי כרטיסים לצורך עמידה בתקן PCI DSS

Last reviewed 2025-04-28 UTC

במאמר הזה מוסבר איך להגדיר שירות טוקניזציה של כרטיסי אשראי וכרטיסי חיוב מיידי עם בקרת גישה בפונקציות Cloud Run. כדי להגדיר את השירות, הפריסה במסמך הזה משתמשת בשירותי Google Cloud הבאים: ניהול זהויות והרשאות גישה (IAM) ו-Cloud Key Management Service (KMS).

טוקניזציה היא תהליך שבו מחליפים מידע רגיש, כמו נתונים של כרטיסי אשראי, בערך זמני לשמירת מקום (פלייסהולדר) לא מזיק, או בטוקן. חלק 3 בתקן אבטחת הנתונים המקובל בתעשיית כרטיסי תשלום (PCI DSS) מחייב להתייחס לרוב הנתונים שמאוחסנים בכרטיס אשראי כמידע רגיש.

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

שירות לטיפול במידע רגיש

יש הרבה אפשרויות לפלטפורמה או לשירות לאירוח סביבת הנתונים של בעלי הכרטיסים (CDE). במאמר הזה נסביר איך לפרוס פתרון לדוגמה באמצעות פונקציות Cloud Run, ואיך להמשיך משם לפתרון שמוכן לייצור.

פונקציות Cloud Run הן פלטפורמה ללא שרת (serverless) שמארחת ומריצה קוד, וזה מקום נוח להפעיל במהירות אפליקציה שמתרחבת בלי התערבות. חשוב לזכור: בסביבת CDE שתואמת לתקן PCI DSS, צריך להגביל את כל התנועה הנכנסת והיוצאת לחיבורים מורשים. אמצעי בקרה כאלה ברמת פירוט גבוהה לא זמינים כרגע לפונקציות Cloud Run. לכן, עליכם להטמיע אמצעי בקרה מפצים במקום אחר (למשל באפליקציה שלכם) או לבחור פלטפורמה אחרת. אפשר להריץ את אותו שירות טוקניזציה בקונטיינר, כמו קבוצת מופעי מכונה מנוהלים עם התאמה לעומס (autoscaling) או אשכול Kubernetes. אלה סביבות ייצור מועדפות עם אמצעי הבקרה המלאים של רשת ה-VPC.

‫Cloud KMS הוא שירות ניהול המפתחות של Google Cloud. ב-Cloud KMS מתארחים מפתחות ההצפנה, מתבצעת רוטציה שלהם באופן קבוע ומוצפנים או מפוענחים נתוני החשבון שמאוחסנים.

במאמר הזה אנחנו משתמשים ב-IAM כדי לספק אמצעי בקרה הדוקים על כל המשאבים שמשמשים בשירות הטוקניזציה. כדי לתת גישה ל-Cloud KMS ולהפעיל את ה-tokenizer, צריך חשבון שירות מיוחד עם אסימונים שתוקפם פג לעיתים קרובות.

באיור הבא מוצגת ארכיטקטורת האפליקציה ליצירת אסימונים שיוצרים במסמך הזה.

ארכיטקטורה של אפליקציית הקצאת טוקנים

מטרות

  • יוצרים חשבון שירות.
  • מגדירים את Cloud KMS.
  • יוצרים שתי פונקציות Cloud Run.
  • יוצרים טוקן אימות.
  • קוראים ל-tokenizer.

עלויות

במסמך הזה משתמשים ברכיבים הבאים של Google Cloud, והשימוש בהם כרוך בתשלום:

בעזרת מחשבון העלויות אתם יכולים להעריך את העלויות בהתאם לשימוש הצפוי.

משתמשים חדשים של Google Cloud ? יכול להיות שאתם זכאים לתקופת ניסיון בחינם.

לפני שמתחילים

  1. מוודאים שיש לכם את תפקיד ה-IAM 'יצירת פרויקטים' (roles/resourcemanager.projectCreator). איך מקצים תפקידים

  2. נכנסים לדף לבחירת הפרויקט במסוף Google Cloud .

    כניסה לדף לבחירת הפרויקט

  3. לוחצים על Create project.

  4. נותנים שם לפרויקט. רושמים או זוכרים את מזהה הפרויקט שנוצר.

  5. עורכים את שאר השדות לפי הצורך.

  6. לוחצים על יצירה.

  7. מוודאים שהחיוב מופעל בפרויקט Google Cloud .

  8. מפעילים את ממשקי ה-API של Cloud Build, פונקציות Cloud Run ו-Cloud KMS, אם הם עדיין לא מופעלים.

    התפקידים שנדרשים כדי להפעיל ממשקי API

    כדי להפעיל ממשקי API, צריך את ההרשאה serviceusage.services.enable. אם יצרתם את הפרויקט, סביר להניח שכבר יש לכם את ההרשאה הזו דרך התפקיד "בעלים" (roles/owner). אחרת, תוכלו לקבל את ההרשאה הזו דרך התפקיד "אדמין בממשק 'שימוש בשירות'" (roles/serviceusage.serviceUsageAdmin). איך מקצים תפקידים

    הפעלת ממשקי ה-API

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

יצירת חשבון השירות

חשבון השירות שמוגדר כברירת מחדל בסביבת זמן הריצה של פונקציות Cloud Run כולל את התפקיד "עריכה", שמאפשר גישה נרחבת להרבה שירותי Google Cloud . למרות שזו הדרך המהירה ביותר לפתח פונקציות, Google ממליצה להשתמש בחשבון השירות שמוגדר כברירת מחדל רק לבדיקות ולפיתוח. יוצרים חשבון שירות כדי להגביל את ממשקי ה-API שהפונקציה יכולה להשתמש בהם בהתאם לעיקרון של הרשאות מינימליות. כדי ליצור חשבון שירות:

  1. נכנסים לדף Service Accounts במסוף Google Cloud .

    לדף Service accounts

  2. בוחרים את הפרויקט הרצוי.

  3. לוחצים על Create Service Account.

  4. בשדה Service account name, מזינים Tokenization Service User. המסוף Google Cloud ממלא את השדה מזהה חשבון שירות בהתאם לשם הזה.

  5. אופציונלי: בשדה Service account description, מזינים תיאור לחשבון השירות.

  6. לוחצים על Create and continue.

  7. לוחצים על Select a role (בחירת תפקיד) ואז בוחרים באפשרות Cloud KMS CryptoKey Encrypter/Decrypter (הצפנה/פענוח של מפתח הצפנה ב-Cloud KMS).

  8. כדי לסיים את יצירת חשבון השירות, לוחצים על Done.

    עכשיו יש לכם משתמש בחשבון שירות עם כתובת האימייל הבאה:

    tokenization-service-user@YOUR_PROJECT_ID.iam.gserviceaccount.com

הגדרת Cloud KMS

  1. במסוף Google Cloud , פותחים את Key Management.

    כניסה לדף Cryptographic Keys

  2. לוחצים על ‎+ Create key ring. בתיבת הדו-שיח שמופיעה, מבצעים את הפעולות הבאות:

    1. נותנים לאוסף המפתחות את השם tokenization-service-kr.
    2. בקטע Key ring location, בוחרים באפשרות global. זו בחירה נפוצה שמספיקה לפריסה בדוגמה הזו. לפני שאתם מקבלים החלטות לגבי ארכיטקטורת הייצור, חשוב שתבינו את ההבדלים בין המיקומים השונים של Cloud KMS.
    3. חשוב לבדוק היטב את הבחירות שלכם, כי אי אפשר לשנות את השם של אוספי המפתחות אחרי שהם נוצרים.
    4. לוחצים על יצירה.

    המערכת יוצרת את אוסף המפתחות ומעבירה אתכם לדף ליצירת מפתחות.

  3. בתיבת הדו-שיח Create key (יצירת מפתח):

    1. נותנים למפתח את השם cc-tokenization.
    2. בשדה מטרה, בוחרים באפשרות Symmetric encrypt/decrypt.

    3. מגדירים את תקופת הרוטציה לערך הרצוי ולוחצים על יצירה.

יצירת פונקציות Cloud Run

במסמך הזה מניחים שתשתמשו ב-Cloud Shell. אם אתם משתמשים בטרמינל אחר, ודאו שמותקנת אצלכם הגרסה העדכנית של Google Cloud CLI.

  1. פותחים את Cloud Shell במסוף Google Cloud :

    כניסה ל-Cloud Shell

  2. משכפלים את מאגר הפרויקט ב-GitHub ועוברים לתיקיית העבודה:

    git clone https://github.com/GoogleCloudPlatform/community gcp-community
cd gcp-community/tutorials/pci-tokenizer/

    התיקייה gcs-cf-tokenizer מכילה את הקובץ index.js, שהוא המקור לשתי פונקציות Cloud Run שונות שתיצרו. הוא מכיל גם את package.json, שמציין לפונקציות Cloud Run אילו חבילות להריץ.

  3. מחילים את ההגדרה של KMS: מעתיקים את קובץ תבנית ההגדרה ופותחים אותו לעריכה:

    cp config/default.json config/local.json
nano config/local.json

    בסביבת זמן הריצה של Node.js צריך להגדיר במפורש את מזהה הפרויקט ב- Google Cloud :

    "project_id":              "YOUR_PROJECT_ID"

  4. מוצאים את הגדרת ה-KMS ומחילים את ערכי ה-KMS שיצרתם בקטע הקודם:

    "location":                "global",
"key_ring":                "tokenization-service-kr",
"key_name":                "cc-tokenization"

  5. פורסים את הפונקציה tokenize.

    gcloud functions deploy tokenize --runtime=nodejs18 --trigger-http \
    --entry-point=kms_crypto_tokenize --memory=256MB \
    --service-account=tokenization-service-user@YOUR_PROJECT_ID.iam.gserviceaccount.com \
    --no-allow-unauthenticated --source=.

    הפונקציה הזו הופכת את פרטי כרטיס האשראי לטוקן.

  6. מחפשים את הערך של כתובת ה-URL בקטע httpsTrigger בפלט של הפקודה gcloud functions deploy. שומרים את הערך של כתובת ה-URL במשתנה הסביבה TOK_URL:

    TOK_URL="TOK_URL"

    תשתמשו במשתנה הסביבה TOK_URL כדי לקרוא לפונקציה tokenize.

  7. פורסים את הפונקציה detokenize במצב KMS.

    gcloud functions deploy detokenize --runtime=nodejs18 --trigger-http \
    --entry-point=kms_crypto_detokenize --memory=256MB \
    --service-account=tokenization-service-user@YOUR_PROJECT_ID.iam.gserviceaccount.com \
    --no-allow-unauthenticated --source=.

    הפונקציה הזו הופכת את תהליך הטוקניזציה.

  8. מחפשים את הערך של כתובת ה-URL בקטע httpsTrigger בפלט של הפקודה gcloud functions deploy. שומרים את הערך של כתובת ה-URL במשתנה הסביבה DETOK_URL:

    DETOK_URL="DETOK_URL"

    תשתמשו במשתנה הסביבה DETOK_URL כדי לקרוא לפונקציה detokenize.

    יצרתם שתי פונקציות Cloud Run נפרדות: אחת להמרת מספר הכרטיס לטוקן, והשנייה להפיכת התהליך. נקודות הכניסה השונות מפנות את ההפעלה לפונקציית ההתחלה המתאימה בקובץ index.js.

  9. אחרי שפורסים את פונקציות Cloud Run, פותחים את מסוף פונקציות Cloud Run.

    פתיחת מסוף פונקציות Cloud Run

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

יצירת אסימון אימות

האפשרות no-allow-unauthenticated בפקודה gcloud functions deploy מציינת שמי שמפעיל את הפונקציות צריך להציג אסימון אימות כדי לאשר את הזהות שלו. למבצע הקריאה החוזרת צריכה להיות ההרשאה cloudfunctions.functions.invoke. התפקידים המוגדרים מראש הבאים כוללים את ההרשאה הזו: Cloud Functions Invoker,‏ Cloud Functions Admin ו-Cloud Functions Developer.

  • יוצרים את טוקן האימות:

    AUTH_TOKEN=$(gcloud auth print-identity-token)
echo $AUTH_TOKEN

הפקודות האלה יוצרות מחרוזת של אסימון אימות, שומרות אותה במשתנה הסביבה $AUTH_TOKEN ומציגות את האסימון. בהמשך מפעילים את פונקציות Cloud Run שפרסתם באמצעות האסימון.

הפעלת ה-tokenizer

  1. יוצרים נתונים לדוגמה כדי להעביר אותם לכלי ההמרה לאסימונים:

    export TOK_CC=4000300020001000
export TOK_MM=11
export TOK_YYYY=2028
export TOK_UID=543210

  2. יוצרים אסימון אימות כמו שמתואר בקטע הקודם, ואז קוראים ל-tokenizer:

    CC_TOKEN=$(curl -s \
-X POST "$TOK_URL" \
-H "Content-Type:application/json" \
-H "Authorization: Bearer $AUTH_TOKEN" \
--data '{"cc": "'$TOK_CC'", "mm": "'$TOK_MM'", "yyyy": "'$TOK_YYYY'", "user_id": "'$TOK_UID'"}' \
)
echo $CC_TOKEN

    מוצגת מחרוזת הטוקניזציה שמייצגת את נתוני כרטיס האשראי. המחרוזת הזו נשמרה במשתנה הסביבה CC_TOK. אפשר לאחזר את פרטי הכרטיס באמצעות הפעלת ה-detokenizer.

  3. מבטלים את הטוקניזציה באמצעות הפקודה הבאה.

    DETOK_DATA=$(curl -s \
-X POST "$DETOK_URL" \
-H  "Content-Type:application/json" \
-H "Authorization: Bearer $AUTH_TOKEN" \
--data '{"user_id": "'$TOK_UID'", "token": "'$CC_TOKEN'"}' \
)
echo -e "$DETOK_DATA\n"

    הפלט אמור להיראות כך:

    {"cc":"4000300020001000","mm":"11","yyyy":"2028","userid":"543210"}

    אלה הנתונים שנשלחו במקור ל-tokenizer, פוענחו ואוחזרו על ידי האפליקציה.

הרחבה של הדוגמה הזו

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

אם תבחרו להשתמש בפונקציות Cloud Run כדי ליצור אסימונים לכרטיסי תשלום, יכול להיות שתצטרכו לבצע פעולות נוספות כדי לעמוד בדרישות של Qualified Security Assessor או של שאלון ההערכה העצמית. בפרט, בסעיפים 1.2 ו-1.3 של PCI DSS נדרשת בקרה הדוקה על תעבורת נתונים נכנסת ויוצאת. בפונקציות Cloud Run וב-App Engine אין חומת אש דו-כיוונית שאפשר להגדיר, ולכן צריך ליצור אמצעי בקרה מפצים או לפרוס את שירות הטוקניזציה ב-Compute Engine או ב-Google Kubernetes Engine. אם אתם רוצים לבדוק את האפשרות של שימוש בקונטיינרים, הקוד ב-GitHub תואם ל-Docker ומכיל מסמכי תיעוד תומכים.

קוד לדוגמה זה גם מושך את התלות ב-npm (כלי לניהול חבילות Node.js) בהטמעה. בסביבת הייצור, תמיד צריך להצמיד את התלויות לגרסאות ספציפיות שנבדקו. לאחר מכן, צריך לצרף את הגרסאות האלה לאפליקציה עצמה או להציג אותן ממיקום פרטי ומהימן. שתי הגישות האלה עוזרות לכם להימנע מהשבתה שנובעת מהפסקת חשמל במאגר npm הציבורי או ממתקפת שרשרת אספקה שמדביקה חבילות שחשבתם שהן בטוחות. אם אתם יוצרים מראש את האפליקציה המלאה ומאגדים אותה, בדרך כלל זמן הפריסה מתקצר, מה שמאפשר השקות מהירות יותר והתאמה חלקה יותר לעומס.

הסרת המשאבים

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

  1. נכנסים לדף Manage resources במסוף Google Cloud .

    כניסה לדף Manage resources

  2. ברשימת הפרויקטים, בוחרים את הפרויקט שרוצים למחוק ולוחצים על Delete.
  3. כדי למחוק את הפרויקט, כותבים את מזהה הפרויקט בתיבת הדו-שיח ולוחצים על Shut down.

המאמרים הבאים