מדריך קלאודפלייר בעברית
לאתר הראשי כל המדריכים קלוד קוד קלוד דסקטופ גרוק CLI גרוק בוט MCP קרסור וואטסאפ OpenClaw n8n בענן n8n בהתקנה עצמית

תיעוד 80

TLS הדדי

זמינות

mTLS של Access זמין בתוכניות Zero Trust מסוג Enterprise ו-pay-as-you-go. הוא אינו כלול בתוכנית Free. לקוחות Free יכולים להשתמש באסימוני שירות כדי לאמת מערכות אוטומטיות.

העמוד הזה עוסק ב-mTLS של Access עבור מדיניות Service Auth. mTLS ברמת האזור הוא יכולת נפרדת עם זמינות תוכניות שונה.

אימות TLS הדדי (mTLS) מחייב גם את הלקוח וגם את השרת להציג אישורים במהלך לחיצת היד של TLS. במימוש של Cloudflare Access, ה-CA שמעלים משמש לאימות אישור הלקוח (אימות אישור השרת מטופל על ידי TLS רגיל). ל-mTLS של Access שני תפקידים:

  • אימות מכשירים שאינם משתמשים בספק זהות: מערכות אוטומטיות ומכשירי IoT יכולים להוכיח את זהותם על ידי הצגת אישור לקוח במקום התחברות דרך IdP.
  • הוספת גורם אימות שני: חברי צוות שמתחברים דרך IdP יכולים להידרש גם להציג אישור לקוח תקף, וכך לספק שכבת אבטחה נוספת.

כשמעלים רשות אישורים (CA) ראשית אל Access, רק בקשות ממכשירים עם אישור לקוח תואם מורשות לעבור. כשבקשה מגיעה ליישום, Access מבקש מהלקוח להציג אישור. אם הלקוח אינו יכול להציג אישור תקף, הבקשה נחסמת. אם הלקוח מציג אישור תקף, Access משלים החלפת מפתחות כדי לאמת.

תרשים לחיצת יד של mTLS

חשוב

אישור ה-mTLS משמש רק לאימות אישור הלקוח. הוא אינו שולט באישור ה-SSL שמוצג במהלך server hello.

#אכיפת אימות mTLS

#דרישות מוקדמות

  • יישום Access עבור שם המארח שרוצים לאבטח באמצעות mTLS.
  • CA שמנפיק אישורי לקוח למכשירים.
    • אישור ה-CA יכול להיות מ-CA מהימן ציבורית, או בחתימה עצמית.
    • ב-Basic Constraints של האישור, המאפיין CA חייב להיות מוגדר ל-TRUE.
    • האישור חייב להשתמש באחד מאלגוריתמי החתימה המפורטים להלן:

אלגוריתמי חתימה מותרים:

  • x509.SHA1WithRSA
  • x509.SHA256WithRSA
  • x509.SHA384WithRSA
  • x509.SHA512WithRSA
  • x509.ECDSAWithSHA1
  • x509.ECDSAWithSHA256
  • x509.ECDSAWithSHA384
  • x509.ECDSAWithSHA512

#הוספת mTLS ליישום Access

  1. בלוח הבקרה של Cloudflare, עבור אל Zero Trust > Access controls > Service credentials > Mutual TLS.

  2. בחר Add mTLS Certificate.

  3. הזן שם כלשהו עבור ה-CA הראשי.

  4. ב-Certificate content, הדבק את התוכן של ה-CA הראשי.

    אם אישור הלקוח חתום ישירות על ידי ה-CA הראשי, צריך להעלות רק את השורש. אם אישור הלקוח חתום על ידי אישור ביניים, חובה להעלות את כל שרשרת ה-CA (ביניים ושורש). לדוגמה:

    -----BEGIN CERTIFICATE-----
<intermediate.pem>
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
<rootCA.pem>
-----END CERTIFICATE-----

    אל תכלול אישורי שרת SSL/TLS. Access משתמש בשרשרת ה-CA רק כדי לאמת את החיבור בין המכשיר של המשתמש לבין Cloudflare.

  5. ב-Associated hostnames, הזן את שמות המתחם המלאים (FQDN) שישתמשו באישור זה.

    שמות ה-FQDN האלה יהיו שמות המארח של המשאבים המוגנים במדיניות Access. חובה לשייך את ה-Root CA ל-FQDN שבו משתמש היישום המוגן.

  6. שמור את המדיניות.

  7. עבור אל Access controls > Policies.

  8. צור מדיניות Access באמצעות אחד מהבוררים הבאים:

    • Valid Certificate: כל אישור לקוח שיכול להתאמת מול ה-Root CA יורשה להמשיך.
    • Common Name: רק אישורי לקוח עם common name מסוים יורשו להמשיך.

  9. אם זה מיועד ללקוח שאינו צריך להתחבר דרך IdP, הגדר את Action של המדיניות ל-Service Auth.

    דוגמה למדיניות mTLS

    ActionRule typeSelectorValue
    Service AuthIncludeCommon NameJohn Doe

  10. שמור את המדיניות, ואז עבור אל Access controls > Applications.

  11. בחר את היישום שעליו רוצים לאכוף mTLS ובחר Edit. היישום חייב להיכלל ברשימת Associated hostnames משלב 5.

  12. בלשונית Policies, הוסף את מדיניות ה-mTLS.

  13. שמור את היישום.

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

#בדיקת mTLS

#בדיקה באמצעות cURL

כדי לבדוק את היישום המוגן במדיניות mTLS:

  1. תחילה, נסה לבצע curl לאתר בלי אישור לקוח. דוגמת פקודת ה-curl הזו היא עבור האתר example.com שיש לו יישום Access ומדיניות המוגדרים עבור https://auth.example.com:

    curl -sv https://auth.example.com

    בלי אישור לקוח בבקשה, מוצגת תשובת 403 forbidden ולא ניתן לגשת לאתר.

  2. עכשיו, הוסף לבקשה את אישור הלקוח ואת המפתח:

    curl -sv https://auth.example.com --cert example.pem --key key.pem

כשתהליך האימות מסתיים בהצלחה, כותרת CF_Authorization Set-Cookie חוזרת בתשובה.

זהירות

Cloudflare Gateway אינו יכול לבדוק תעבורה אל דומיינים המוגנים ב-mTLS. אם במכשיר מופעל Cloudflare One Client והוא מעביר בקשות HTTP דרך Gateway, הגישה תיחסם אלא אם עוקפים בדיקת HTTP עבור הדומיין.

#בדיקה בדפדפן

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

הדוגמה הבאה מראה איך להוסיף אישור לקוח ל-keychain של מערכת macOS:

חשוב

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

  1. נווט אל התיקייה שמכילה את אישור הלקוח ואת המפתח.
  2. פתח את הקובץ client.pem ב-Keychain Access. אם מתבקשים, הזן את הסיסמה המקומית.
  3. ב-Keychain, בחר באפשרות הגישה שמתאימה לצרכים שלך ובחר Add.
  4. ברשימת האישורים, אתר את האישור שהותקן זה עתה. Keychain Access יסמן את האישור הזה כלא מהימן. לחץ לחיצה ימנית על האישור ובחר Get Info.
  5. בחר Trust. תחת When using this certificate, בחר Always Trust.

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

#יצירת אישורי mTLS

אפשר להשתמש בכלי תשתית מפתחות פרטית (PKI) בקוד פתוח כדי ליצור אישורים לבדיקת יכולת ה-mTLS ב-Cloudflare Access.

#OpenSSL

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

#יצירת ה-CA הראשי

  1. צור את המפתח הפרטי של ה-CA הראשי:

    openssl genrsa -aes256 -out rootCA.key 4096

    כשמתבקשים, הזן סיסמה לשימוש עם rootCA.key.

  2. צור אישור שורש בחתימה עצמית בשם rootCA.pem:

    openssl req -x509 -new -nodes -key rootCA.key -sha256 -days 3650 -out rootCA.pem

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

#יצירת אישור ביניים

  1. צור את המפתח הפרטי של ה-CA הביניים:

    openssl genrsa -aes256 -out intermediate.key 4096

    כשמתבקשים, הזן סיסמה לשימוש עם intermediate.key.

  2. צור בקשת חתימה על אישור (CSR) עבור אישור הביניים:

    openssl req -new -sha256 -key intermediate.key -out intermediate.csr

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

  3. צור קובץ הרחבת CA בשם v3_intermediate_ca.ext. לדוגמה:

    subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid:always,issuer
basicConstraints = critical, CA:true
keyUsage = critical, cRLSign, keyCertSign

    ודא ש-basicConstraints כולל את המאפיין CA:true. מאפיין זה מאפשר לאישור הביניים לפעול כ-CA ולחתום על אישורי לקוח.

  4. חתום על אישור הביניים באמצעות ה-CA הראשי:

    openssl x509 -req -in intermediate.csr -CA rootCA.pem -CAkey rootCA.key -CAcreateserial -out intermediate.pem -days 1825 -sha256 -extfile v3_intermediate_ca.ext

#יצירת קובץ שרשרת CA

  1. אחד את אישור הביניים ואת אישור השורש לקובץ אחד:

    cat intermediate.pem rootCA.pem > ca-chain.pem

    אישור הביניים צריך להיות בראש הקובץ, ואחריו האישור שחתם עליו.

  2. העלה את התוכן של ca-chain.pem אל Cloudflare Access. להנחיות, ראה הוספת mTLS ליישום Access.

#יצירת אישור לקוח

  1. צור מפתח פרטי עבור הלקוח:

    openssl genrsa -out client.key 2048

  2. צור CSR עבור אישור הלקוח:

    openssl req -new -key client.key -out client.csr

    תתבקש למלא כמה שדות אופציונליים. לצורכי בדיקה, אפשר להגדיר את Common Name למשהו כמו John Doe.

  3. חתום על אישור הלקוח באמצעות אישור הביניים:

    openssl x509 -req -in client.csr -CA intermediate.pem -CAkey intermediate.key -CAcreateserial -out client.pem -days 365 -sha256

  4. אמת את אישור הלקוח מול שרשרת האישורים:

    openssl verify -CAfile ca-chain.pem client.pem
    client.pem: OK

עכשיו אפשר להשתמש באישור הלקוח (client.pem) ובמפתח שלו (client.key) כדי לבדוק mTLS.

#PKI של Cloudflare

המדריך הזה משתמש בערכת כלי ה-PKI של Cloudflare כדי ליצור CA ראשי ואישורי לקוח מקובצי JSON.

#1. התקנת תלויות

התהליך דורש שתי חבילות מערכת כלי ה-PKI של Cloudflare:

  • cf-ssl
  • cfssljson

אפשר להתקין את החבילות האלה ממאגר GitHub של Cloudflare SSL. נדרשת התקנה עובדת של Go, גרסה 1.12 או חדשה יותר. לחלופין, אפשר להוריד את החבילות ישירות. השתמש בהנחיות תחת Installation כדי להתקין את ערכת הכלים, וודא שמתקינים את כל תוכניות העזר שבערכה.

#2. יצירת ה-CA הראשי

  1. צור תיקייה חדשה לאחסון ה-CA הראשי.

  2. בתוך התיקייה הזו, צור שני קבצים חדשים:

    • CSR. צור קובץ בשם ca-csr.json והוסף את גוש ה-JSON הבא, ואז שמור את הקובץ.

      {
    "CN": "Access Testing CA",
    "key": {
        "algo": "rsa",
        "size": 4096
    },
    "names": [
        {
            "C": "US",
            "L": "Austin",
            "O": "Access Testing",
            "OU": "TX",
            "ST": "Texas"
        }
    ]
}

    • config. צור קובץ בשם ca-config.json והוסף את גוש ה-JSON הבא, ואז שמור את הקובץ.

      {
    "signing": {
        "default": {
            "expiry": "8760h"
        },
        "profiles": {
            "server": {
                "usages": ["signing", "key encipherment", "server auth"],
                "expiry": "8760h"
            },
            "client": {
                "usages": ["signing", "key encipherment", "client auth"],
                "expiry": "8760h"
            }
        }
    }
}

  3. עכשיו, הרץ את הפקודה הבאה כדי ליצור את ה-CA הראשי עם הקבצים האלה.

    cfssl gencert -initca ca-csr.json | cfssljson -bare ca

  4. הפקודה תפיק אישור שורש (ca.pem) ואת המפתח שלו (ca-key.pem).

    ls
    ca-config.json ca-csr.json ca-key.pem ca.csr  ca.pem

  5. העלה את התוכן של ca.pem אל Cloudflare Access. להנחיות, ראה הוספת mTLS ליישום Access.

#3. יצירת אישור לקוח

כדי ליצור אישור לקוח שיתאמת מול ה-CA הראשי שהועלה:

  1. צור קובץ בשם client-csr.json והוסף את גוש ה-JSON הבא:

    {
    "CN": "James Royal",
    "hosts": [""],
    "key": {
        "algo": "rsa",
        "size": 4096
    },
    "names": [
        {
            "C": "US",
            "L": "Austin",
            "O": "Access",
            "OU": "Access Admins",
            "ST": "Texas"
        }
    ]
}

  2. עכשיו, השתמש בפקודה הבאה כדי ליצור אישור לקוח באמצעות ערכת כלי ה-PKI של Cloudflare:

    cfssl gencert -ca=ca.pem -ca-key=ca-key.pem  -config=ca-config.json -profile=client client-csr.json | cfssljson -bare client

הפקודה תפיק קובץ אישור לקוח (client.pem) ואת המפתח שלו (client-key.pem). עכשיו אפשר להשתמש בקבצים האלה כדי לבדוק mTLS.

#יצירת רשימת שלילה של אישורים

אפשר להשתמש בערכת כלי ה-PKI של Cloudflare גם כדי ליצור רשימת שלילה של אישורים (CRL). הרשימה הזו תכיל אישורי לקוח שנשללו.

  1. קבל את המספר הסידורי מאישור הלקוח שנוצר קודם. הוסף את המספר הסידורי הזה, או כל מספר אחר שברצונך לשלול, בפורמט הקסדצימלי בקובץ טקסט. הדוגמה הזו משתמשת בקובץ בשם serials.txt.

  2. צור את ה-CRL באמצעות הפקודה הבאה.

    cfssl gencrl serials.txt ../mtls-test/ca.pem ../mtls-test/ca-key.pem | base64 -D > ca.crl

יהיה צורך להוסיף את ה-CRL לשרת, או לאכוף את השלילה ב-Cloudflare Worker. סקריפט Worker לדוגמה נמצא במאגר GitHub של Cloudflare.

#הוספת כותרות Client-Cert ו-Client-Cert-Chain (RFC 9440)

RFC 9440 מגדיר את שדות כותרת ה-HTTP Client-Cert ו-Client-Cert-Chain להעברת מידע על אישור הלקוח לשרתי המקור. אפשר לבנות את הכותרות האלה באמצעות כללי שינוי כותרות בקשה עם שדות Ruleset Engine הבאים:

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

#שיקולי אבטחה

חשוב

לפני בניית כותרות Client-Cert או Client-Cert-Chain, עליכם לטפל בחששות האבטחה הבאים. אי טיפול בהם עלול לחשוף את שרת המקור לנתוני אישור מזויפים או לא מאומתים.

השדות cert_rfc9440 ו-cert_chain_rfc9440 מאוכלסים ללא קשר לתוצאת אימות האישור. המשמעות היא שלקוח יכול להציג אישור לא תקין, שפג תוקפו, או בחתימה עצמית, והשדות עדיין יכילו את נתוני האישור המקודדים. תמיד בדקו את השדות הבאים לפני שסומכים על הערכים:

לקוח יכול גם לכלול כותרות Client-Cert או Client-Cert-Chain משלו בבקשה כדי להזריק ערכים שרירותיים. כמתואר בשיקולי האבטחה של RFC 9440, עליכם להסיר ללא תנאי כל כותרות Client-Cert ו-Client-Cert-Chain קיימות מבקשות נכנסות, ללא קשר לתקפות האישור. זה מונע מלקוח להזריק נתוני אישור מזויפים ששרת המקור שלכם יסמוך עליהם.

ראו הפעלת mTLS לפרטים על אופן הגדרת mTLS ואימות אישורים.

#מגבלות גודל

אישור העלה המקודד מוגבל ל-10 KiB ושרשרת האישורים המקודדת מוגבלת ל-16 KiB. אם הערך המקודד חורג מהמגבלה, השדה המתאים מכיל מחרוזת ריקה. השתמשו בשדות הבאים כדי לבדוק מצב זה:

#דוגמה לכללי Transform

כאן מוצגת דוגמה לשימוש מאובטח בשדות אלה כדי לבנות כותרות Client-Cert ו-Client-Cert-Chain מהימנות שיועברו לשרת המקור שלכם. שרת המקור יכול אז להסתמך על נוכחות הכותרות כדי להיות בטוח שהלקוח הציג אישור תקין. הערה: כותרת Client-Cert-Chain עשויה להיות מושמטת כאשר הלקוח לא הציג אישורי ביניים (רק אישור עלה).

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

#כלל 1: הסרת כותרת Client-Cert

כלל זה מסיר ללא תנאי כל כותרת Client-Cert שנשלחה על ידי הלקוח.

טקסט ב-Expression Editor:

true

פעולה שנבחרה תחת Modify request header: Remove

Header name: Client-Cert

#כלל 2: הסרת כותרת Client-Cert-Chain

כלל זה מסיר ללא תנאי כל כותרת Client-Cert-Chain שנשלחה על ידי הלקוח.

טקסט ב-Expression Editor:

true

פעולה שנבחרה תחת Modify request header: Remove

Header name: Client-Cert-Chain

#כלל 3: הגדרת כותרת Client-Cert

כלל זה מגדיר את כותרת Client-Cert רק כאשר הלקוח הציג אישור תקין, שלא בוטל, ושנמצא בתוך מגבלת הגודל.

טקסט ב-Expression Editor:

cf.tls_client_auth.cert_verified
and not cf.tls_client_auth.cert_revoked
and not cf.tls_client_auth.cert_rfc9440_too_large

פעולה שנבחרה תחת Modify request header: Set dynamic

Header name: Client-Cert

Value: cf.tls_client_auth.cert_rfc9440

#כלל 4: הגדרת כותרת Client-Cert-Chain

כלל זה מגדיר את כותרת Client-Cert-Chain רק כאשר הלקוח הציג אישור תקין ושלא בוטל, והשרשרת לא ריקה ונמצאת בתוך מגבלת הגודל.

טקסט ב-Expression Editor:

cf.tls_client_auth.cert_verified
and not cf.tls_client_auth.cert_revoked
and cf.tls_client_auth.cert_chain_rfc9440 ne ""
and not cf.tls_client_auth.cert_chain_rfc9440_too_large

פעולה שנבחרה תחת Modify request header: Set dynamic

Header name: Client-Cert-Chain

Value: cf.tls_client_auth.cert_chain_rfc9440

#Cloudflare Workers

אפשר גם לבנות כותרות RFC 9440 ב-Cloudflare Worker באמצעות מאפייני tlsClientAuth בבקשה הנכנסת.

אותם שיקולי אבטחה שצוינו למעלה חלים.

#העברת אישור לקוח (מדור קודם)

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

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

זהירות

תהליך זה זמין רק בחשבונות עם Cloudflare Access.

#Cloudflare API

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

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

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

  • Access: Mutual TLS Certificates Write

עדכון הגדרות שם המארח של אישור mTLS, bash

curl "https://api.cloudflare.com/client/v4/zones/$ZONE_ID/access/certificates/settings" \
	--request PUT \
	--header "Authorization: Bearer $CLOUDFLARE_API_TOKEN" \
	--json '{
		"settings": [
				{
						"hostname": "<HOSTNAME>",
						"china_network": false,
						"client_certificate_forwarding": true
				}
		]
	}'

לאחר ש-client_certificate_forwarding מוגדר ל-true, כל בקשה בתוך חיבור mTLS תכלול כעת את הכותרות הבאות:

  • Cf-Client-Cert-Der-Base64
  • Cf-Client-Cert-Sha256

הערה

הכותרות Cf-Client-Cert-Der-Base64 ו-Cf-Client-Cert-Sha256 הן מנגנון קנייני של Cloudflare. לגישה תקנית, השתמשו בכותרות Client-Cert ו-Client-Cert-Chain של RFC 9440.

#Managed Transforms

אפשר גם לשנות כותרות תגובת HTTP באמצעות Managed Transforms כדי להעביר כותרות אימות TLS של לקוח.

#Cloudflare Workers

בנוסף, Workers יכולים לספק פרטים בנוגע לאישור הלקוח.

const tlsHeaders = {
	"X-CERT-ISSUER-DN": request.cf.tlsClientAuth.certIssuerDN,
	"X-CERT-SUBJECT-DN": request.cf.tlsClientAuth.certSubjectDN,
	"X-CERT-ISSUER-DN-L": request.cf.tlsClientAuth.certIssuerDNLegacy,
	"X-CERT-SUBJECT-DN-L": request.cf.tlsClientAuth.certSubjectDNLegacy,
	"X-CERT-SERIAL": request.cf.tlsClientAuth.certSerial,
	"X-CERT-FINGER": request.cf.tlsClientAuth.certFingerprintSHA1,
	"X-CERT-VERIFY": request.cf.tlsClientAuth.certVerify,
	"X-CERT-NOTBE": request.cf.tlsClientAuth.certNotBefore,
	"X-CERT-NOTAF": request.cf.tlsClientAuth.certNotAfter,
};

#מגבלות ידועות

mTLS אינו פועל כרגע עבור:

#התראות לאישורי TLS הדדי

Cloudflare תשלח את ההתראות הבאות לפני שתוקף אישורי ה-TLS ההדדי שלכם יפוג:

התראת תפוגה של אישור mTLS של Access

למי זה מיועד?

לקוחות Access שמשתמשים באישורי לקוח לאימות TLS הדדי. התראה זו תישלח 30 ימים ו-14 ימים לפני תפוגת האישור.

אפשרויות אחרות / מסננים

אין.

כלול עם

רכישה של Access ו/או Cloudflare for SaaS.

מה עליכם לעשות אם קיבלתם אחת?

העלו אישור מחודש.