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

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

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

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

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

מטרות

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

עלויות

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

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

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

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

  1. Ensure that you have the Project Creator IAM role (roles/resourcemanager.projectCreator). Learn how to grant roles.
  2. In the Google Cloud console, go to the project selector page.

    Go to project selector

  3. Click Create project.

  4. Name your project. Make a note of your generated project ID.

  5. Edit the other fields as needed.

  6. Click Create.

  7. Verify that billing is enabled for your Google Cloud project.

  8. Enable the Cloud Build, Cloud Run functions, and Cloud KMS APIs.

    Roles required to enable APIs

    To enable APIs, you need the Service Usage Admin IAM role (roles/serviceusage.serviceUsageAdmin), which contains the serviceusage.services.enable permission. Learn how to grant roles.

    Enable the APIs

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

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

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

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

    לדף Service accounts

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

  3. לוחצים על יצירת חשבון שירות.

  4. בשדה שם חשבון השירות, מזינים Tokenization Service User. השדה Service account ID במסוף 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 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

  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 שפרסתם באמצעות האסימון.

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

  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 על המשאבים שבהם השתמשתם בדוגמה הזו של פריסה, אתם יכולים למחוק את הפרויקט שמכיל את המשאבים.

  1. In the Google Cloud console, go to the Manage resources page.

    Go to Manage resources

  2. In the project list, select the project that you want to delete, and then click Delete.
  3. In the dialog, type the project ID, and then click Shut down to delete the project.

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