מדוע הצפנת כל נתוני המשתמש חשובה
נתוני שחקן אינם רק דואר אלקטרוני וסיסמה. אלה מסמכי KYC, אסימוני תשלום, רישומי הימורים, התקנים, IP, מדדי התנהגות. כל דליפה פוגעת במוניטין, ברישיון וב- P & L. הצפנה מלאה (בדרך, באחסון ובאופן חלקי ”בשימוש”) מצמצמת את ההשלכות של אירועים: מזבלה גנובה או תנועה מיורטת הופכת לסט חסר משמעות של בייטים ללא מפתחות.
1) מודל איום: מאיזו הצפנה מגן עלינו
יירוט תנועה (MITM, רשתות חסרות ביטחון) * TLS 1. 2+/1. 3.
גניבה של גיבויים/תמונות דיסק * הצפנה על אחסון (disk/db/object).
גישה לשגיאות/זכויות שגויות * הצפנת שדה, אסימון, מיסוך.
פשרה של התעללות בחשבונאות/פנימית * הפרדת מפתחות ונתונים, RBAC/ABAC.
אובדן פיזי של מדיה/התקנים של עובדים * FDE/MDM.
חשוב: משלים הצפנה, לא תחליפים, בקרת גישה, כריתת עצים וקטעי רשת.
2) שלוש שכבות הצפנה (יחד, לא בנפרד)
1. במעבר: HTTPS/TLS 1. 2+/1. 3, MTLS בין שירותים, HSTS, חתימות webhook (HMAC) + אנטי-replay (”חותמת זמן”, nonce).
2. במנוחה:- דיסקים/כרכים: LUKS/BITLocker/eCryptfs, מערכת אוטומטית עם KMS.
- בסיסי נתונים/אובייקטים: AES-256-GCM, מפתחות בודדים על ידי תחומי נתונים (PII, פיננסים, יומנים).
- גיבויים/תמונות: מדיניות מפתח נפרדת, offsite/Geo, בדיקת התאוששות.
- 3. בשימוש: הצפנת שדה של שדות רגישים, מיסוך בלוגים UI/logs, הגבלת ביטול הצפנה בצד היישום; לחישובים קריטיים במיוחד - TEE/סודיים.
3) מפתחות - חשובים יותר מצפנים: KMS/HSM ומבצעים
KMS/HSM: דור/אחסון של מפתחות שורש, סיבוב, ביקורת פעולות.
Hierarchy: CMK (root) # DEK (data) ach for domains שונים (ארנק/KYC/logs).
סיבוב: מתוכנן (90-180 ימים) ולא מתוכנן (פשרה), קריפטו-קרס לאחר החזרה.
הפרדת חובות (SoD): למנהל DB אין גישה למפתחות; קצין ההצפנה לא רואה את הנתונים.
זמן דרישת גישה (JIT) + MFA לניהול.
4) מה בדיוק להצפין (וכמה עמוק)
פיי: שם מלא, כתובת, תאריך לידה, אנשי קשר.
מסמכים, סלפי, לביאה = אחסון/מפתחות נפרדים, שימור קצר.
תשלומים: לעולם אל תשמור על פאן; tokenization, PCI DSS צמצום היקף, PSP אירח עמודים.
מגזיני משחק/כנות: צדדים/נונס, בקרת גירסה - קריאה בלבד, חתימות.
טלמטריה ו-BI: אנוניזציה/פסאודונימיזציה, פרטיות דיפרנציאלית במקום המתאים.
5) אלגוריתמים והגדרות ברירת מחדל
סימטרי: AES-256-GCM/ChaCha20-Poly1305 (AEAD, הגנה על יושרה).
החלפת מפתח/הפעלה: ECDHE עם PFS.
קריפטוגרפיה: ECDSA P-256/P-384 או RSA-3072 חתימה.
הססמה hash: Argon2id (או scrypt/bcrypt עם פרמטרים נכונים), לא SHA-256.
TLS: 1. 3, 1. 2 כתאימות; צפנים רק AEAD, לנטרל CBC/RC4.
IV/nonce: ייחודי, שאינו ניתן לחזרה; חנות עם הטקסט הצופן.
6) ביצועים: איך לא ”לרדת” FPS וקופאית
השתמש בהוראות חומרה (AES-NI) ובריכות מפתח.
הצפן שדות, לא את המחרוזת כולה, היכן שיש צורך בחיפוש/אינדקסים.
עבור נכסים סטטיים - TLS + CDN (מטמון קצה), HTTP/2/3.
אין להצפין מידע חם פעמים רבות על כל הופ - לבנות מסוע קריפטו.
פרופיל: לעתים קרובות יותר ”מאט” לא קריפטו, אלא I/O/serialization.
7) יומנים, גיבויים וסביבות בדיקה
יומנים: אסימונים מסכה/PII, לאחסן אחסון תולעת לא משתנה, ארכיון הצפנה.
גיבויים: הצפנה עם מפתחות נפרדים, מבחני DR תקופתיים (חזרה חוזרת), שמירה על ידי מדיניות.
Dev/Stage: לעולם אל תשתמש ב-PII אמיתי; סינתטיים/מיסוך, מפתחות אישיים ורשתות.
8) פרטיות וציות
אנלוגיות GDPR/מקומיות: בסיסי עיבוד חוקיים, DSR (גישה/הסרה/תיקון), מזעור.
PCI DSS: אסימון כרטיסים, הצפנת תחבורה, הפרדה של לולאת התשלום.
חוזי מעבד: DPIA, SCC/DTIA בהעברה חוצה גבולות.
מדיניות השמירה: ”אין צורך למחוק, למחוק” כחלק מעלייה למטוס.
9) טעויות אופייניות (וכיצד למנוע אותן)
אנחנו להצפין את הנתונים, והמפתחות נמצאים בקוד/מאגר. שמור מפתחות בקמ "מ/כספת, סרוק סודות.
מפתח אחד "לכל דבר. "חלוקה לפי תחומים וסביבות.
TLS הוא, אבל אין חתימות HSTS/pinning/webhook. הוסף HSTS טעון מראש, HMAC ואנטי-חזרה.
יומנים עם מח "ש בטקסט ברור. מיסוך + מרחב מפתח נפרד עבור ארכיונים.
אין סבב מפתח וביקורת מפתח. הגדרת לוח הזמנים, התראות ויומן הפעילות.
בדיקות עם מסמכים אמיתיים. סינתטיים/אנונימיים בלבד.
10) ”הצפנת ברירת מחדל” רשימת מימושים
[ ] TLS 1. 2+/1. 3 בכל מקום (קצה, בין שירות), HSTS, 'wss ://"
[ ] KMS/HSM, היררכיית מפתח, סיבוב וביקורת
[ ] בסיס נתונים/אובייקט/הצפנת גיבוי + הצפנת שדה PII
[ אסימון כרטיס ], צמצום היקף PCI
[ ] חשיש Argon2id סיסמאות, מלח למשתמש
[ ] PII מסווה ביומנים, אחסון תולעת, SIIM
[ ] Dev/Stage ללא PII אמיתי; מפתחות/רשתות בודדות
[ מדיניות שימור ]/קריפטו-קרס, תהליכי DSR (GDPR)
[ ] חתימות Webhook (HMAC), אנטי-שידור חוזר, MTLS בפנים
[ ] בדיקות התאוששות ד "ר, גיבויים מחוץ לאתר, ניטור דליפה
11) מיני ־ FAQ
הצפנה בדיסק מספיקה? לא, זה לא יש צורך בהצפנת שדה + TLS + ניהול מקשים.
ההצפנה תאט את המשחק? עם הארכיטקטורה הנכונה, לא: צווארי בקבוק הם בדרך כלל ברשת/מעבד.
למה אסימון אם יש הצפנה? אסימונים מחסלים את אחסון ה-PAN ומפחיתים את היקף ה-PCI.
אני צריך להצפין טלמטריה? כן, נסיעה מינימלית וארכיון; פלוס אנונימיות.
מה לעשות כשהמפתח בסכנה? סיבוב/החזרה מיידית, קריפטו-קרס, ניתוח גישה, הודעת מדיניות אינפרא-חמצני.
הצפנת כל נתוני המשתמש היא שכבת אבטחה בסיסית הפועלת רק בשיתוף עם ניהול מפתח תקין, הפרדת גישה, מזעור נתונים ודיסציפלינת DevSecOps. בנה ארכיטקטורת הצפנה ”כברירת מחדל”, סבב אוטומטי ומבחני DR, הצפן גיבויים ויומנים, מסכת PII - ואפילו במקרה של תקרית, תשמור על אמונם של שחקנים, רגולטורים ושותפים, והגבלת ההשלכות לניהול.