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

Last reviewed 2025-04-28 UTC

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

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

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

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

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

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

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

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

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

מטרות

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

עלויות

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

• Cloud KMS
• Cloud Run functions
• Cloud Build

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

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

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

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

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

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

3. לוחצים על יצירת פרויקט.

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. לוחצים על + יצירת מחזיק מפתחות. בתיבת הדו-שיח שמופיעה, מבצעים את הפעולות הבאות:

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

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

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

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

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

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

יצירה של פונקציות Cloud Run

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

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

   כניסה ל-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. פורסים את הפונקציה ליצירת טוקנים.

   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. פורסים את הפונקציה להסרת הטוקנים במצב 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 Functions.

   פתיחת מסוף Cloud Run functions

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

יצירת טוקן אימות

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

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

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

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

התקשרות לטוקנייזר

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"}
   

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

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

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

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

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

הסרת המשאבים

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

זהירות: כשמוחקים פרויקט:
• התוכן של הפרויקט נמחק כולו. אם השתמשתם בפרויקט קיים כדי לתרגל את המשימות במדריך הזה, כשתמחקו אותו תימחק גם כל העבודה שביצעתם באותו פרויקט.
• מאבדים את מזהה הפרויקט בהתאמה אישית. כשיצרתם את הפרויקט, יכולתם לבחור לו מזהה פרויקט בהתאמה אישית כדי להשתמש בו בעתיד. כדי לשמור על כתובות ה-URL שמשתמשות במזהה הפרויקט, כמו appspot.com, צריך למחוק את המשאבים שנבחרו בפרויקט אבל לא את הפרויקט כולו.
1. במסוף Google Cloud , נכנסים לדף Manage resources.

   כניסה לדף Manage resources

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

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

• תאימות לתקן אבטחת הנתונים של PCI.
• שימוש ב-OAuth 2.0 כדי לגשת אל Google APIs.
• הדרישות של PCI DSS.
• תוסף מידע על טוקניזציה של PCI DSS.
• לדוגמאות נוספות של ארכיטקטורות, תרשימים ושיטות מומלצות, עיינו במאמר Cloud Architecture Center.