איך הצפנת נתונים עובדת במערכות תשלומים

מערכות התשלום פועלות עם המידע הרגיש ביותר - PAN (מספר כרטיס), תאריך תפוגה, CVV/CVC, אסימונים 3-DS, פרטי בנק, מזהים ארנק. הדליפה שלהם היא קנסות, החזרה של סוחר מבנקים/PSP והפסד כספי ישיר. הגנה נבנית בשכבות: הצפנה בערוץ (TLS), הצפנה ו/או טוקניזציה באחסון, ניהול מפתחות קפדני ומודולים נאמנים לחומרה (HSM). למטה יש את כל האבטחה ”צינור” בשפה פשוטה.

לבנים בסיסיות

קריפטוגרפיה סימטרית

אלגוריתמים: AES-GCM/CTR/CBC (בתשלומים, הסטנדרט דה פקטו הוא AES-GCM).

מקצוענים: מהירות גבוהה, מפתחות קומפקטיים.

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

קריפטוגרפיה אסימטרית

אלגוריתמים: RSA-2048/3072, ECC (P-256/384, Ed25519).

שימוש: החלפת מפתח/עטיפה, חתימות, PKI, תעודות TLS.

זה לא דורש סוד משותף מראש.

חסרונות: לאט יותר מהצפנה סימטרית.

סודיות קדמית מושלמת (PFS)

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

הצפנת מעבר: TLS 1. 2/1. 3

1. לחיצת יד (TLS): הלקוח והשרת מסכימים על גרסאות/צפנים, השרת מציג תעודה (PKI), מחליף מפתחות ephemeral (ECDHE) * נולד מפתח סימטרי הפעלה.

2. נתונים: מועברים במצבי AEAD (AES-GCM/ChaCha20-Poly1305) באמצעות אימות.

3. אופטימיזציה: TLS 1. 3 כדורים חתוכים, תומך חידוש; 0-RTT משמשים בזהירות (שאילתות אידמפוטנטים בלבד).

4. תרגול לתשלומים: אנחנו אוסרים SSLv3/TLS1. 0/1. 1, להפעיל את TLS1. 2/1. 3, הידוק OCSP, HSTS, ראשי אבטחה קפדניים.

💡 שיחות פנימיות (PSP # סוחר, עיבוד סוחר, ספרי אינטרנט) לעתים קרובות גם להגן על mTLS: שני הצדדים מראים תעודות הדדיות.

הצפנה ”באחסון”: במנוחה

אפשרויות

הצפנת נפח/בסיס נתונים מלא (TDE): נכנס במהירות, מגן מפני גישה ”קרה” לתקשורת, אך לא מפני דליפה דרך יישום מתפשר.

Bitwise/Field-level (FLE): שדות בודדים (PAN, IBAN) מוצפנים. גרנולרי, אבל קשה יותר ליישם ואינדקס.

הצפנה לשימור תבניות (FPE): שימושי כאשר אתה רוצה 16 ספרות בתור 16 ספרות.

tokenization: PAN מוחלף על ידי מחרוזת חסרת משמעות; ה-PAN הזה מאוחסן בכספת הסמלית תחת הגנה כבדה. כאשר משלמים/חוזרים, נעשה שימוש באסימון = הסוחר אינו מעבד כרטיסים ”גולמיים”.

רעיון מפתח

באחסון, לא ”איזה אלגוריתם” חשוב יותר, אלא היכן נמצאים המפתחות ומי יכול לסלק. לכן...

ניהול מפתחות: KMS, HSM ומעטפות

היררכיית מפתח (הצפנת מעטפה)

Root/KEK (מפתח הצפנה): כיתת הגנה גבוהה, מאוחסנת ומבוצעת ב ־ HSM.

DEK (מפתח הצפנת נתונים): הצפנת נתונים/חבורות/טבלאות ספציפיות; עצמו מוצפן על ידי KEK.

סבב: תקנות לתכנון מתוכנן ולא מתוכנן (במקרה של אירוע) סיבוב של KEK/DEK; גרסת המפתח מצויינת במטאדטה של הצופן.

HSM (מודול אבטחת חומרה)

מודול חומרה מוסמך (לדוגמה, FIPS 140-2/3) המאחסן ומבצע פעולות מפתח בתוך עצמו.

לא מפרסם מפתחות פרטיים מבחוץ, תומך במדיניות הגבלת/שימוש, ביקורת.

משמש ל: דור מפתח, עטיפת DEK, 3-DS מפתח שרת, מפתחות EMV, פעולות PIN, חתימת הודעות.

KMS

מרכזת מדיניות מפתח, ורסינציה, גישה, יומנים, ורכיבי API.

בשיתוף עם HSM, הוא מיישם הצפנת מעטפה וסיבוב אוטומטי.

תקני כרטיס ופרטי תעשייה

PCI DSS (ולוגיקת מזעור)

הרעיון המרכזי: לא לאחסן CVV, למזער את אזור עיבוד ה-PAN (היקף).

היכן שאפשר - לתת קלט PAN לשדות אירוח/Iframe PSP * לסוחר אין גישה לנתונים גולמיים.

יומנים, גיבויים, השלכות - אותם כללים כמו פרוד: מיסוך, הצפנה, שמירה.

EMV, CIN BROUPOS

שבב EMV/ללא מגע: קריפטוגרמות ברמת כרטיס/מסוף, הגנה מפני שיבוט רצועות קוסם.

בלוקים של PIN ושל ISO 9564: PIN מוצפן ממשטח סיכות לעיבוד, עובד עם HSM (העברות סיכות, אזורי מפתח).

DUKPT (DUKPT): כל תשלום מוצפן במפתח ייחודי הנגזר מ-BDK.

PCI P2PE: תוכנת הצפנה ”מקצה אל קצה” מוסמכת.

ביטחון תלת מימדי (2. x)

אימות מחזיק כרטיס = פחות הונאה/צ 'רג' בקס.

קריפטוגרפיה משמשת לחתימות מסרים, החלפת מקשים ACS/DS/3DS Server; מפתחות פרטיים נמצאים בדרך כלל ב-HSM.

ארכיטקטורת הגנת נתונים טיפוסית

אפשרות A (סוחר מקוון עם PSP):

דפדפן # HTTPS * Harved Fields PSP (PAN אינו מגיע לסוחר).
PSP מחזירה אסימון תשלום.
מסד הנתונים של הסוחר מאכסן את האסימון + 4 הספרות האחרונות ו-BIN (עבור UX וחוקים).
חוזר/חוזר - אסימון בלבד.
סודות/מפתחות ב-KMS, מפתחות פרטיים TLS/3-DS ב-HSM.

אפשרות ב '(ארנק/תשלום):

יישום ↔ API - TLS/mTLS.
שדות רגישים - FLE/FPE או אסימון; הכספת מבודדת.
גישה לניתוק - רק לתפקידי שירות עם פעולות ”ארבע עיניים” - באמצעות HSM.

אפשרות C (לא מקוונת-POS):

pin pad # DUKPT/P2PE ac.process.
מפתחות אתחול מסוף - באמצעות מזרקי מפתח מאובטחים/XSM.
כריתת עצים, הגנה נגד חבלה של מכשירים.

סיבוב, ביקורת ותקריות

סיבוב מפתח: מתוכנן (פעם אחת כל X חודשים) ועל ידי אירוע (פשרה). DEK ערוך מחדש תחת KEK החדש מבלי לפענח את נתוני המשתמש.

יומנים בלתי ניתנים לשינוי: מי ומתי לגשת לגלישה/מפתחות; חתימה של יומנים.

רשימת פשרה: ביטול מיידי/סיבוב, הנפקה מחדש של תעודות, בלוק מפתח API, הודעת שותף, רטרוספקטיבה.

טעויות נפוצות וכיצד להימנע מהן

1. ”אנחנו מצפינים את בסיס הנתונים, אז הכל בסדר”.

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

2. אחסון CVV.

אתה לא יכול. CVV לעולם לא מאוחסן, אפילו לא מוצפן (באמצעות PCI DSS).

3. מפתחות ליד נתונים.

אתה לא יכול. מפתחות - ב ־ KMS/HSM, גישה לפי תפקיד, מינימום הרשאות, חשבונות נפרדים.

4. אין סיבוב/גרסאות.

תמיד מפתחות גרסה, לאחסן ”key _ version” במטאדטה ciphertext.

5. TLS בהיקף בלבד.

הצפן מאחורי CDN/WAF ובתוך תוכנית הנתונים (servis _ servis, webhooks).

6. טוקניזציה ”לצפייה”.

אם כל שירות יכול לסלק, זה לא הגנה. שיחות צרות וביקורת.

7. גיבויים נעדרים/העלאות אנליטיות.

הצפנה ומיסוך יחולו על גיבויים, תמונות, תצוגות, יומנים.

רשימת יישום (תקציר)

ערוץ

TLS 1. 2/1. 3, PFS, mTLS לפנים וטלפונים באינטרנט, HSTS, ראשי אבטחה קפדניים.

אחסון

איסור על אחסון CVV.

FLE/FPE עבור שדות קריטיים; TDE כשכבת בסיס.

מפתחות

KMS + HSM, הצפנת מעטפה (KEK/DEK), סיבוב/גרסאות, יומנים בלתי ניתנים לשינוי.

ארכיטקטורה

שדות מארחים/SDK PSP, מזעור אזור PCI.

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

פעולות

צוות מחומש/אדום על היקפי והגיון עסקי.

ניטור DLP/CTI של תעלות ניקוז, אימוני כוח אדם.

פשרת ריצה: לבטל/לסובב/להודיע.

מיני ־ FAQ

האם הצפנה או אסימון הם הטובים ביותר עבור פאן?

במכירות - אסימון (ממזער את היקף). בכספת - הצפנה עם HSM/KMS.

האם אני צריך אישור EV עבור תחום תשלום?

אופציונלי. יותר חשוב פרופיל TLS נכון, mTLS, מפתחות HSM ומשמעת.

אפשר להשתמש 0-RTT ב-TLS 1? 3 עבור תשלומים?

עבור Gets האידימפוטנטי, כן. עבור POST, עדיף לכבות או להגביל.

איך לאחסן את ”4 האחרונים” ו ”בין”?

נפרד מ-PAN; זה לא מידע רגיש עם בידוד נכון, אבל לצפות מיסוך ביומנים/BI.

הצפנה במערכות תשלום אינה מתג טוגל אחד, אלא מערכת אקולוגית: TLS/PFS בערוץ, טוקניזציה ו/או FLE באחסון, ניהול מפתח קפדני באמצעות KMS + HSM, תקני תעשייה (PCI DSS, EMV, 3-DS), סיבוב וביקורת. ארכיטקטורה מרובת שכבות כזו הופכת את דליפת נתוני הכרטיסים לבלתי סבירה בעליל, מפשטת את מעבר הביקורת, והכי חשוב, שומרת על אמון הבנקים, שותפי התשלומים והמשתמשים.