תיעוד 87

תעודות לקוח (mTLS)

TLS רגיל מאמת את זהות השרת מול הלקוח. Mutual TLS (mTLS) מוסיף בדיקה שנייה: השרת מאמת גם את זהות הלקוח באמצעות תעודת לקוח. כך אפשר להגביל גישה למכשירים או לשירותים שמציגים תעודה תקינה.

השתמשו בתשתית המפתחות הציבוריים (PKI) של Cloudflare כדי ליצור תעודות לקוח, או הביאו CA משלכם (BYOCA).

אימות Mutual TLS (mTLS) הוא נוהג אבטחה נפוץ שמשתמש בתעודות לקוח כדי לוודא שהתעבורה בין הלקוח לשרת מאובטחת ומהימנה בשני הכיוונים. mTLS גם מאפשר לבקשות שאינן מאומתות דרך ספק זהות, כגון מכשירי Internet-of-things (IoT), להוכיח שהן יכולות להגיע למשאב נתון.

mTLS ב-Cloudflare

התיעוד הזה מתמקד במוצר SSL/TLS. לסקירה רחבה יותר, פנו אל מסלול הלמידה mTLS at Cloudflare.

#איך זה עובד

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

Cloudflare מאמת תעודות לקוח מול רשויות אישורים (CA) שמוגדרות ברמת החשבון. מכיוון שהאימות הוא ברמת החשבון, אותן תעודות פועלות על פני כמה דומיינים תחת החשבון שלכם, כל עוד mTLS מופעל לכל hostname (לדוגמה, host.example.com, name.example.net, secure.anotherdomain.test).

רשויות האישורים ברמת החשבון יכולות להיות:

CA שמנוהל על ידי Cloudflare: זו אפשרות ברירת המחדל. תעודות ושיוכים של hostname מופיעים בלשונית Cloudflare-issued בלוח הבקרה Client Certificates ↗︎.
תעודות BYOCA: זמינות בחשבונות Enterprise. תעודות ושיוכים של hostname מופיעים בלשונית BYOCA בלוח הבקרה Client Certificates ↗︎.

לאחר מכן Cloudflare שומר את תוצאת האימות בשדה שנקרא cf.tls_client_auth.cert_verified:

הצלחה: cf.tls_client_auth.cert_verified הוא true, ואפשר למצוא פרטי תעודת לקוח בשדות mTLS ייעודיים.
כישלון: cf.tls_client_auth.cert_verified הוא false.

#מגבלות

#CA שמנוהל על ידי Cloudflare

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

הגדלת המכסה דורשת חשבון Enterprise עם API Shield. אחרי שההרשאה מוחלת, ברירת המחדל עולה ל-100,000 לכל zone. פנו לצוות החשבון שלכם כדי לבקש הגדלה.

#BYOCA

כל חשבון Enterprise יכול להעלות עד חמש תעודות CA. המכסה הזו משותפת ל-API Shield, ל-Workers mTLS ול-Cloudflare Gateway. היא לא חלה על רשויות אישורים שהועלו דרך Cloudflare Access, שמשתמש במכסה נפרדת.

פנו לצוות החשבון שלכם כדי לבקש הגדלה של מכסת ה-CA ב-BYOCA.

בחירה בין CA מנוהל ל-BYOCA

השתמשו ב-CA שמנוהל על ידי Cloudflare אם יש לכם קבוצה קטנה ויציבה של לקוחות שמאמתים בתדירות נמוכה.

השתמשו ב-BYOCA אם אתם מנפיקים תעודות בנפח גבוה או בקצב החלפה גבוה, כבר מפעילים CA פנימי, או רוצים להנפיק תעודות בלי לקרוא ל-API של Cloudflare עבור כל תעודה.

#מקרי שימוש

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

אבטחת יישומים: הגבלת גישה ליישום הווב שלכם על בסיס תעודות לקוח
mTLS ל-Zero Trust: אימות משתמשים ושירותים דרך Cloudflare Access
mTLS עם API Shield: אימות לקוחות API באמצעות אימות מבוסס תעודה
קישור mTLS ב-Workers: הצגת תעודת לקוח כאשר ה-Worker שלכם מתחבר לשירות חיצוני

מלבד קישור mTLS ב-Workers, כל אחד מהיישומים שלמעלה יכול להשתמש ב-CA שלכם במקום ב-CA שמנוהל על ידי Cloudflare. פנו אל הביאו CA משלכם.

#mTLS ו-Workers

השתמשו בקישור mTLS ב-Workers כאשר אתם צריכים שה-worker שלכם יציג תעודת לקוח לשירות חיצוני. כדי לאמת בקשות מלקוח אל ה-worker שלכם, פנו ליישום הרגיל של mTLS לאבטחת יישומים.

flowchart LR
        accTitle: mTLS from client to worker versus mTLS from worker to external service
        accDescr: Diagram showing two different implementations that can be considered for mTLS with Cloudflare Workers.
        A[Client] <--App security mTLS--> B((Cloudflare))<--mTLS worker binding--> C[(External service)]