📘 תיעוד 75

תאימות ל-PCI DSS

עודכן לאחרונה: 14 בספטמבר 2026

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

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

#הסמכת PCI DSS של Cloudflare

Cloudflare מוסמכת כספק שירות PCI DSS ברמה 1, רמת ההסמכה הגבוהה ביותר. אפשר לקבל את אישור התאימות (AOC) העדכני של Cloudflare מ-Cloudflare Trust Hub.

הערה

ה-AOC של Cloudflare מכסה את התשתית של Cloudflare עצמה. הוא לא חל אוטומטית על האזור או היישום שלכם. באחריותכם להגדיר את Cloudflare נכון ולאבטח את המערכות שלכם.

#אחריות משותפת

#הגדרת TLS

שלבים 1 ו-2 נדרשים לתאימות ל-PCI DSS. שלב 3 הוא המלצה של Cloudflare להגדרה חזקה יותר, אבל הוא לא מחייב לפי PCI DSS v4.0, שקובע את TLS 1.2 כמינימום. סריקת PCI בודקת כל שכבה בנפרד: השלמת שלבים 1 ו-2 בלבד מספיקה כדי לעמוד בתקן.

#שלב 1: הגדרת גרסת TLS מינימלית ל-1.2

דרישה 4.2.1 של PCI DSS מחייבת הצפנה חזקה לנתוני בעל הכרטיס במעבר, כאשר TLS 1.2 היא הגרסה המינימלית הקבילה. TLS 1.0 ו-TLS 1.1 לא נחשבים להצפנה חזקה לפי PCI DSS.

1. בלוח הבקרה של Cloudflare, עברו אל SSL/TLS > Edge Certificates. מעבר אל Edge Certificates
2. עבור Minimum TLS Version, בחרו TLS 1.2 או גבוה יותר.

ראו Minimum TLS Version לאפשרויות API ו-Terraform.

#שלב 2: הגדרת חבילות צופן של PCI DSS

PCI DSS אוסר אלגוריתמי צופן חלשים ומיושנים. חובה להגביל את האזור לרשימת הצפנים המאושרת ל-PCI DSS.

דרישת קדם

התאמה אישית של חבילות צופן דורשת מנוי ל-Advanced Certificate Manager.

הערה

• אי אפשר להגדיר חבילות צופן ספציפיות של TLS 1.3. כשמפעילים TLS 1.3, Cloudflare משתמשת אוטומטית בכל חבילות הצופן הנתמכות של TLS 1.3, וכולן עומדות בדרישות PCI DSS. רשימת הצפנים בשלב הזה חלה על חיבורי TLS 1.2 בלבד.
• עדכון חבילות צופן מפעיל פריסה מחדש של האישור, שעשויה לקחת כמה דקות. המתינו לפני הרצת סריקת אימות.

בצעו את השלבים ב-Customize cipher suites (dashboard) ובחרו את חבילות הצופן מפרופיל PCI DSS שמפורט ב-Compliance standards. לחלופין, השתמשו ב-API:

הרשאות נדרשות לאסימון API

נדרשת לפחות אחת מהרשאות האסימון הבאות:

• Zone Settings Write

Edit zone settingbash

curl "https://api.cloudflare.com/client/v4/zones/$ZONE_ID/settings/ciphers" \
	--request PATCH \
	--header "Authorization: Bearer $CLOUDFLARE_API_TOKEN" \
	--json '{
		"value": [
				"ECDHE-ECDSA-AES128-GCM-SHA256",
				"ECDHE-RSA-AES128-GCM-SHA256",
				"ECDHE-ECDSA-AES256-GCM-SHA384",
				"ECDHE-RSA-AES256-GCM-SHA384",
				"ECDHE-ECDSA-CHACHA20-POLY1305",
				"ECDHE-RSA-CHACHA20-POLY1305"
		]
	}'

#שלב 3: הפעלת TLS 1.3 (מומלץ)

TLS 1.3 נותן ערבויות אבטחה חזקות יותר מ-TLS 1.2, מבטל כמה דפוסי לחיצת יד ישנים, ומומלץ לצד TLS 1.2 להגדרה חזקה יותר ועמידה לעתיד. הוא לא נדרש לתאימות ל-PCI DSS, שמחייב TLS 1.2 כמינימום.

1. בלוח הבקרה של Cloudflare, עברו אל SSL/TLS > Edge Certificates. מעבר אל Edge Certificates
2. הפעילו את TLS 1.3.

ראו TLS 1.3 לאפשרויות API ו-Terraform.

#אימות ההגדרה

אחרי החלת כל ההגדרות, אשרו שחיבורים לא תואמים נדחים.

#שימוש בסורק TLS מקוון

סורקי TLS מקוונים נותנים מבט חיצוני על ההגדרה, אותה נקודת מבט שסריקת PCI ASV רואה. שתי אפשרויות נפוצות:

• SSL Labs Server Test: הזינו את הדומיין ועברו על הדוח. בדקו ש-TLS 1.0 ו-TLS 1.1 נדחים, ש-TLS 1.2 או גבוה יותר נתמך, ושלא מתבצע משא ומתן על חבילות צופן חלשות או מיושנות.
• SSL Shopper SSL Checker: מאמת את שרשרת האישורים ואת הגדרת TLS מנקודת מבט חיצונית.

הערה

Cloudflare לא ממליצה על כלי צד שלישי מסוים. השתמשו בכל סורק שמתאים לתהליך העבודה שלכם: מה שחשוב הוא לאמת מחוץ ללוח הבקרה של Cloudflare.

#שימוש ב-openssl

openssl s_client מאפשר לבדוק גרסאות TLS ספציפיות משורת הפקודה. חיבורים שמשתמשים ב-TLS 1.0 או ב-TLS 1.1 אמורים להיכשל:

# Should fail , TLS 1.0 rejected
openssl s_client -connect example.com:443 -tls1

# Should fail , TLS 1.1 rejected
openssl s_client -connect example.com:443 -tls1_1

חיבור שנדחה מחזיר שגיאה כגון:

4087F5C1E27F0000:error:0A00042E:SSL routines:ssl3_read_bytes:tlsv1 alert protocol version

כדי לאשר איזו חבילת צופן נקבעת במשא ומתן מעל TLS 1.2:

openssl s_client -connect example.com:443 -tls1_2 2>/dev/null | grep -E "Protocol|Cipher"

הפלט אמור להציג צופן מהרשימה המאושרת ל-PCI DSS, לדוגמה ECDHE-RSA-AES128-GCM-SHA256.

#שימוש ב-curl

כדי לאשר ש-TLS 1.0 ו-TLS 1.1 נדחים:

# Should fail , TLS 1.0 rejected
curl https://example.com --tls-max 1.0 -svo /dev/null

# Should fail , TLS 1.1 rejected
curl https://example.com --tls-max 1.1 -svo /dev/null

חיבור שנדחה מחזיר שגיאה כגון:

* error:1400442E:SSL routines:CONNECT_CR_SRVR_HELLO:tlsv1 alert

#בדיקה מלוח הבקרה

בדף Edge Certificates, בחרו View current ciphers כדי לראות את חבילות הצופן שהוגדרו באזור שלכם.

הערה

לוח הבקרה מציג את חבילות הצופן שהוגדרו. הצפנים שנקבעים בפועל בלחיצת יד של TLS תלויים בלקוח המתחבר ובאלגוריתם האישור (RSA לעומת ECDSA). השתמשו ב-SSL Labs או ב-openssl s_client למבט החיצוני שסורק PCI רואה.

#Cloudflare Pages

אי אפשר להגדיר גרסת TLS מינימלית או חבילות צופן עבור שמות מארח *.pages.dev. ההגדרות האלה חלות רק על אזורים שבשליטתכם בלוח הבקרה של Cloudflare.

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

#דרישות צד לקוח של PCI DSS v4

PCI DSS v4.0 הוסיף שתי דרישות לסקריפטים שרצים בדפדפן של הצרכן בדפי תשלום:

ראו Client-side security and PCI DSS compliance להנחיות הגדרה.

#סריקות PCI ASV

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

#התנהגות פורט מקור TCP

חלק מכלי ASV מדווחים על ממצא TCP Source Port Pass Firewall מול כתובות IP שעוברות בפרוקסי של Cloudflare. זה חיובי כוזב שנגרם מהאופן שבו רשת anycast של Cloudflare מטפלת בחיבורי TCP: ההתנהגות היא מאפיין של תשתית Cloudflare, לא פגיעות בסביבה שלכם.

אם ה-QSA או כלי הסריקה מסמנים את הממצא הזה, ספקו:

• את אישור התאימות (AOC) העדכני של Cloudflare
• תיעוד שהדומיין עובר בפרוקסי דרך Cloudflare כספק שירות PCI DSS ברמה 1

ה-QSA יכול להתייחס לזה כבקרה מפצה או כחריג מתועד על בסיס גבול האחריות המשותפת של Cloudflare.

#WAF ו-DDoS שחוסמים סורקי ASV

סורקי ASV שולחים תעבורה בדפוסי תקיפה, גישושי SQL injection, מטעני XSS וזיהוי טביעת אצבע של פגיעויות, כדי לבדוק את היישום. ה-WAF של Cloudflare חוסם רבים מהגישושים האלה, וזו התנהגות WAF נכונה, אבל זה יכול למנוע מהסורק להשלים את ההערכה.

כדי לאפשר סריקה בלי להשבית את ה-WAF:

1. השיגו את טווחי כתובות ה-IP של המקור שבהם משתמש ספק ה-ASV שלכם.
2. צרו כלל WAF מותאם שמדלג על התאמה ל-managed ruleset עבור טווחי ה-IP האלה, בהיקף של חלון התחזוקה של הסריקה.
3. הסירו או השביתו את הכלל מיד אחרי שהסריקה מסתיימת.

זהירות

שמרו על חריג ה-WAF צר ככל האפשר, בהיקף של טווח ה-IP של הסורק בלבד. הסירו אותו ברגע שהסריקה מסתיימת.

#פורטים לא סטנדרטיים

Cloudflare מעבירה בפרוקסי קבוצה מוגדרת של פורטי HTTP ו-HTTPS. עבור פורטים מחוץ לרשימה הזו, רשת anycast של Cloudflare עשויה לגרום לפורטים האלה להיראות פתוחים בשכבת TCP אף שהם לא עוברים בפרוקסי: חיבור ה-TCP מתקבל בקצה, אבל בקשות HTTP/HTTPS נחסמות בשכבת היישום לפני שהן מגיעות למקור.

אם סריקת ASV מכוונת לפורטים שלא עוברים בפרוקסי, ממצאים עבור הפורטים האלה משקפים את התנהגות הקצה של Cloudflare ולא את המקור שלכם. הגדירו את הסריקה כך שתכוון לפורטים שהיישום באמת מגיש עליהם, וספקו ל-QSA את הפניה לפורטי הרשת כדי לתעד את ההתנהגות הצפויה.

#הפחתות פגיעויות

Cloudflare מיישמת את ההפחתות האלה כברירת מחדל בכל האזורים שעוברים בפרוקסי. לא נדרשת הגדרה.

Cloudflare לא תומכת ב:

• דחיסת כותרות ב-TLS
• דחיסת כותרות ב-SPDY 3.1
• RC4
• SSL 3.0
• משא ומתן מחדש עם לקוחות
• חבילות צופן DHE
• צפנים בדרגת ייצוא

Cloudflare מפחיתה:

• CRIME
• BREACH
• POODLE
• חולשות קריפטוגרפיות של RC4
• התקפות משא ומתן מחדש של SSL
• התקפות הורדת פרוטוקול
• FREAK
• LogJam
• Sweet32: 3DES מושבת עבור TLS 1.1 ו-1.2. עבור TLS 1.0, Cloudflare מסובבת מפתחות שיחה לפני סף 32 GB שנדרש להתקפה מוצלחת

כל שרתי Cloudflare מתוקנים מול Heartbleed, Lucky Thirteen ופגיעות הזרקת CCS.

#חיוביים כוזבים נפוצים של סורקים

#ROBOT

סריקות אבטחה שמדווחות על Return of Bleichenbacher's Oracle Threat (ROBOT) מול דומיין שעובר בפרוקסי של Cloudflare הן חיוביים כוזבים. Cloudflare מאמתת ריפוד RSA PKCS#1 v1.5 בזמן אמת ומחליפה במפתח שיחה אקראי אם הריפוד שגוי, וכך מבטלת כל אורקל שניתן לניצול.

#Sweet32 (CVE-2016-2183)

אם סורק מסמן Sweet32, ודאו ש-TLS 1.0 מושבת באזור שלכם. ראו הגדרת גרסת TLS מינימלית ל-1.2 לשלבים. כש-TLS 1.0 מושבת, חבילות הצופן 3DES שעליהן Sweet32 חל אינן בשימוש, והממצא לא חל על הסביבה שלכם.

#עוגיית _cfuvid בלי דגל Secure

Cloudflare מגדירה את העוגייה _cfuvid בחלק מהאזורים לצורך הגבלת קצב. חלק מהסורקים עשויים לדווח שהעוגייה הזו חסרה את המאפיין Secure אם הם סורקים מעל HTTP. אם ה-ASV מעלה את הממצא הזה, אשרו שה-ASV סורק נקודות קצה HTTPS ושהאזור מפנה תעבורת HTTP אל HTTPS. ראו Always Use HTTPS לשלבי ההגדרה.