סקירה כללית של Mutual TLS

‫Mutual TLS, או mTLS, הוא פרוטוקול מקובל בתחום לאימות הדדי בין לקוח לשרת. הוא מבטיח שגם הלקוח וגם השרת מאמתים זה את זה על ידי בדיקה שלכל אחד מהם יש אישור תקף שהונפק על ידי רשות אישורים (CA) מהימנה. בניגוד ל-TLS רגיל, שבו רק השרת מאומת, ב-mTLS הלקוח והשרת צריכים להציג אישורים, כדי לאמת את הזהויות של שני הצדדים לפני שנוצרת התקשורת.

‫mTLS מוגדר במשאב של שרת ה-proxy ל-HTTPS של היעד בכל מאזני העומסים של האפליקציות:

  • מאזן עומסים גלובלי חיצוני של אפליקציות (ALB)
  • מאזן עומסים קלאסי של אפליקציות (ALB)
  • מאזן עומסים חיצוני אזורי של אפליקציות (ALB)
  • מאזן עומסים פנימי אזורי של אפליקציות (ALB)
  • מאזן עומסים פנימי של אפליקציות (ALB) באזורים שונים

ב-mTLS נעשה שימוש בתשתית של מפתח ציבורי (PKI) כדי לאמת את הזהות של הישויות שמתקשרות ברשת. התשתית כוללת שלושה רכיבים: לקוח, שרת ורשות אישורים (CA). פרוטוקול mTLS למאזני עומסים תומך בתכונות הבאות:

  • מוודאים שללקוח שמציג את האישור יש את המפתח הפרטי שלו.

  • מאמתים את אישורי הלקוח באמצעות אחד ממצבי האימות של הלקוח.

  • אימות אישורי לקוח מול עוגן PKI שהועלה (אישור בסיס), עם אפשרות להוסיף כמה עוגנים בנפרד כדי לאפשר העברה חלקה מ-PKI ישן לחדש בלי זמן השבתה.

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

  • יוצרים טביעת אצבע של האישור ומעבירים אותה לקצה העורפי כ-request header בהתאמה אישית.

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

  • מעבירים את תוצאת האימות ואת כל שגיאות האימות לקצה העורפי באמצעות כותרות בהתאמה אישית.

דרישות לאישורים

כשמגדירים אישורים ל-mTLS, צריך לוודא שהם עומדים בדרישות הבאות:

  • כלי קריפטוגרפיה מודרניים הם הבסיס לאימות mTLS. האישורים חייבים להשתמש באלגוריתמים מסוג RSA או ECDSA לחילופי מפתחות.

  • לאישורי לקוח (קצה):

    • התוסף Basic Constraints לא יכול להכיל את הערך CA=true.

    • התוסף שימוש מורחב במפתח חייב להכיל את הערך clientAuth.

    • התוסף Extended Key Usage לא יכול להכיל את השדות codeSigning,‏ timeStamping או OCSPSigning.

    • האישור צריך להיות בתוקף.

    • אישור הלקוח לא יכול להיות אישור עם חתימה עצמית.

  • לאישורי בסיס ואישורי ביניים:

    • התוסף Basic Constraints חייב להכיל את הערך CA=true.

    • התוסף Key Usage צריך להיות מוגדר ל-keyCertSign.

    • התוסף Extended Key Usage צריך להכיל את השדה clientAuth.

    • האישור צריך להיות בתוקף.

ארכיטקטורה של פריסת mTLS

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

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

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

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

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

  • מאגר אישורים. מכיל את ישות העוגן האמינה ואת אישורי הביניים של רשות האישורים (CA) שמשמשים ליצירת שרשרת אמון ולאימות אישור הלקוח. רשות האישורים משמשת להנפקת אישורים מהימנים ללקוח. רשות האישורים מזוהה על ידי ישות העוגן האמינה של מאזן העומסים (אישור בסיס) או אישורי ה-CA של הביניים.

    אפשר להעלות למאגר האישורים את הסוגים הבאים של אישורי בסיס ואישורי ביניים:

  • אימות לקוח (נקרא גם ServerTLSPolicy). מציין את מצב אימות הלקוח ואת משאב הגדרת האמון שבו צריך להשתמש כשמאמתים אישורי לקוח. כשהלקוח מציג למאזן העומסים אישור לא חוקי או לא מציג אישור בכלל, מצב האימות של הלקוח קובע איך לטפל בחיבור של הלקוח. אתם יכולים לציין את כל הפרמטרים שקשורים לאימות mTLS בכללי מדיניות ה-TLS של השרת. משאב אימות הלקוח (ServerTLSPolicy) מצורף למשאב של שרת ה-Proxy ל-HTTPS.

בתרשימים הבאים מוצגים הרכיבים השונים של mTLS שמצורפים למשאב של שרת ה-Proxy ל-HTTPS של היעד, במאזני עומסים של אפליקציות גלובליים ואזוריים.

גלובלית

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

‫Mutual TLS עם רכיבים של מאזן עומסים גלובלי חיצוני של אפליקציות (ALB).
‫Mutual TLS עם רכיבים של מאזן עומסים גלובלי חיצוני של אפליקציות (לחצו כדי להגדיל).

אזורי

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

‫Mutual TLS עם רכיבים של מאזן עומסים פנימי אזורי של אפליקציות (ALB).
‫Mutual TLS עם רכיבים של מאזן עומסים פנימי אזורי של אפליקציות (לחצו כדי להגדיל).

מצבי אימות לקוח

המאפיין clientValidationMode במשאב Client Authentication (ServerTLSPolicy) מציין איך מאזן העומסים מטפל בחיבור של הלקוח. המצב קובע אם אישורי לקוח לא תקינים או חסרים נדחים באופן מחמיר (REJECT_INVALID), נדחים למעט בדיקות X.509 ספציפיות ופחות מחמירות (ALLOW_VALIDATION_RELAXATIONS) או מועברים לקצה העורפי (ALLOW_INVALID_OR_MISSING_CLIENT_CERT).

אלה מצבי האימות השונים של הלקוח:

  • אישור אישורי לקוח לא תקינים או חסרים (ALLOW_INVALID_OR_MISSING_CLIENT_CERT)
  • דחיית אישורי לקוח לא חוקיים (REJECT_INVALID)
  • אישור הקלות באימות (ALLOW_VALIDATION_RELAXATIONS)

אישור לקוח לא תקין או חסר

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

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

דחיית אישור לקוח לא תקין

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

הקלות באימות

במצב ALLOW_VALIDATION_RELAXATIONS מתבצע אימות של אישורי הלקוח, אבל אפשר להקל על בדיקות אימות ספציפיות – לדוגמה, במהלך העברה כשאישורי לקוח מדור קודם לא עומדים בכל הדרישות המחמירות של האישורים. אם יש לכם משאב ServerTLSPolicy קיים במצב REJECT_INVALID, אתם יכולים לעדכן אותו כדי להשתמש במצב ALLOW_VALIDATION_RELAXATIONS ולציין את רשימת ההקלות באימות שאתם רוצים לאפשר.

אפשר לציין ערך אחד או יותר מהערכים הבאים בשדה clientValidationRelaxations:

  • ‫ALLOW_MISSING_EKU: מאפשר להשמיט מאישור הלקוח את התוסף Extended Key Usage (EKU)‎.

    ALLOW_MISSING_EKU מאפשר רק אישור שאין לו תוסף EKU בכלל, ולא מתעלם מתוסף EKU שקיים עם מטרה שגויה. לדוגמה, אם תוסף ה-EKU קיים באישור הלקוח, הוא עדיין צריך לכלול את מטרת המפתח clientAuth (OID 1.3.6.1.5.5.7.3.2) כפי שצוין בדרישות האישור. אם לאישור יש תוסף EKU שמציין מטרה אחרת (כמו serverAuth) אבל לא את clientAuth, החיבור נדחה.

  • ‫ALLOW_SHA1_HASHING: מאפשרת אימות של שרשראות אישורי לקוח שנחתמו באמצעות תמציות הודעות SHA-1 מדור קודם.

  • ‫ALLOW_EXPIRED_LEAF_CERTIFICATE: מאפשרת לאמת אישור קצה של לקוח שפג תוקפו. מאזן העומסים מאמת את אישור הקצה של הלקוח שפג תוקפו כאילו השעה הנוכחית הייתה שנייה אחת לפני סיום תקופת התוקף שלו (notAfter פחות שנייה אחת). כך אישור הקצה של הלקוח יעבור את בדיקת התפוגה. ההקלה הזו חלה רק על אישור הקצה של הלקוח, ולא על אישורי ביניים או אישורי בסיס בשרשרת. אישורי קצה של לקוחות שעדיין לא תקפים (כשהשעה הנוכחית היא לפני חותמת הזמן notBefore) עדיין נדחים.

במצב ALLOW_VALIDATION_RELAXATIONS נדרש אישור לקוח, ושרשרת האישורים מאומתת מול משאב הגדרת האמון שהוגדר, תוך החלת הקלות האימות הספציפיות שציינתם בשדה clientValidationRelaxations.

כשבוחרים באפשרות ALLOW_VALIDATION_RELAXATIONS, צריך לציין לפחות הקלה אחת באימות. אם בוחרים כמה הקלות, כולן מופעלות בו-זמנית. כל עוד הלקוח מספק אישור שתקף אחרי החלת ההקלות שנבחרו, מאזן העומסים מקבל את החיבור. לדוגמה, אם מגדירים את ALLOW_MISSING_EKU ו-ALLOW_SHA1_HASHING, מאזן העומסים מקבל חיבורים מלקוחות שמציגים אישורים תקינים, אבל משמיטים את התוסף Extended Key Usage‏ (EKU) ומשתמשים בגיבוב SHA-1.

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

‫Google Cloud ממליצה להשתמש בהקלות באימות רק כפתרון זמני במהלך העברת אישורים. השימוש ב-ALLOW_VALIDATION_RELAXATIONS בטוח יותר מהשימוש ב-ALLOW_INVALID_OR_MISSING_CLIENT_CERT, כי מאזן העומסים עדיין אוכף את כל בדיקות האימות האחרות ולא דורש לוגיקת אימות מותאמת אישית בקצה העורפי.

הגדרת mTLS במאזן העומסים

כאן מפורטים השלבים העיקריים שצריך לבצע כדי להגדיר mTLS במאזן העומסים:

  1. יוצרים משאב של הגדרת אמינות שמורכב מישות העוגן האמינה (אישור הבסיס) ומאישורי ביניים שמשמשים כ-Root of Trust.

  2. מקשרים את הגדרת האמינות למשאב Client Authentication (ServerTLSPolicy), שמגדיר את מצב האימות של הלקוח.

  3. מצרפים את המשאב Client Authentication (ServerTLSPolicy) למשאב של שרת ה-Proxy ל-HTTPS של מאזן העומסים.

  4. אופציונלי: אתם יכולים להשתמש בכותרות mTLS בהתאמה אישית כדי להעביר מידע על חיבור ה-mTLS לשירות לקצה העורפי או למפת כתובות URL.

במדריכים הבאים מוסבר בפירוט איך להגדיר את זה:

שלבים לאימות אישור הלקוח

במהלך אימות אישור הלקוח, מאזן העומסים מבצע את הפעולות הבאות:

  1. מוודאים שהמפתח הפרטי נמצא אצל הלקוח.

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

  2. אימות שרשרת האמון.

    מאזן העומסים מאמת את שרשרת האמון על ידי אימות של אישור הלקוח מול האישורים שהוגדרו בהגדרת האמון. מצב אימות הלקוח קובע אם אישורי לקוח לא חוקיים או חסרים נדחים באופן מחמיר (REJECT_INVALID), נדחים למעט בדיקות X.509 ספציפיות ופחות מחמירות (ALLOW_VALIDATION_RELAXATIONS) או מועברים לקצה העורפי (ALLOW_INVALID_OR_MISSING_CLIENT_CERT).

    בדיקות האימות כוללות גם את הדברים הבאים:

    • אישורי הלקוח, אישורי הביניים והאישורים הבסיסיים עומדים בדרישות האישורים.
    • השדה "נושא" באישור ההורה תואם לשדה "מנפיק" באישור הצאצא. האימות הזה מוודא שהזהות (הנושא) של אישור ההורה זהה לזהות שרשומה כמנפיק באישור הצאצא.
    • מזהה המפתח של הנושא (SKID) של אישור ההורה תואם למזהה המפתח של הרשות (AKID) באישור הצאצא. ההתאמה הזו מאשרת שהאישור המשני הונפק על ידי רשות הבסיס הנכונה, ושאפשר לסמוך עליו כי המפתח הציבורי של הבסיס מצוין ב-AKID כדי לאמת את תוקף האישור.
    • השם החלופי של הבעלים (SAN) של אישור צאצא לא מפר את השדה NameConstraints באישור ההורה.

  3. העברת הבקשה לקצה העורפי.

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

    עם זאת, אם האימות נכשל, הפעולה שתתבצע תלויה בערך של מצב אימות הלקוח:

    • ‫ALLOW_INVALID_OR_MISSING_CLIENT_CERT: הבקשה מועברת עם כותרות mTLS בהתאמה אישית שמציינות את הסיבה לכשל באימות. במאזני עומסים פנימיים של אפליקציות חוצי-אזורים, במאזני עומסים חיצוניים אזוריים של אפליקציות ובמאזני עומסים פנימיים אזוריים של אפליקציות, בנוסף לכותרות mTLS בהתאמה אישית, אתם יכולים להגדיר שדות אופציונליים של mTLS כדי לבדוק את הסיבה לכשל.

    • ‫REJECT_INVALID ו-ALLOW_VALIDATION_RELAXATIONS: החיבור נסגר והשגיאות נרשמות ב-Cloud Logging.

כותרות mTLS בהתאמה אישית שמועברות לבק-אנד

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

אפשר להגדיר את המשתנים האלה גם במפת URL.

סטטוס אישור הלקוח מצב אימות לקוח כותרות מותאמות אישית

שרשרת אישורי הלקוח ארוכה מדי (יותר מ-10 אישורי ביניים כלולים באישור הלקוח).

 ALLOW_INVALID_OR_MISSING_CLIENT_CERT

client_cert_present: true

client_cert_chain_verified: false

client_cert_error: client_cert_chain_exceeded_limit

client_cert_sha256_fingerprint: <cert hash>

ללקוח או לאישור ביניים יש גודל מפתח RSA לא חוקי.

לא מתבצע אימות.

מפתחות RSA יכולים להיות בגודל של 2,048 עד 4,096 ביט.

 ALLOW_INVALID_OR_MISSING_CLIENT_CERT

client_cert_present: true

client_cert_chain_verified: false

client_cert_error: client_cert_invalid_rsa_key_size

client_cert_sha256_fingerprint: <cert hash>

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

לא מתבצע אימות.

העקומות האליפטיות התקינות הן P-256 ו-P-384.

 ALLOW_INVALID_OR_MISSING_CLIENT_CERT

client_cert_present: true

client_cert_chain_verified: false

client_cert_error: client_cert_unsupported_elliptic_curve_key

client_cert_sha256_fingerprint: <cert hash>

אישור לקוח או אישור ביניים משתמש באלגוריתם שאינו RSA או ECDSA.

לא מתבצע אימות.

 ALLOW_INVALID_OR_MISSING_CLIENT_CERT

client_cert_present: true

client_cert_chain_verified: false

client_cert_error: client_cert_unsupported_key_algorithm

client_cert_sha256_fingerprint: <cert hash>

ב-PKI שמשמש לאימות יש יותר מ-10 אישורים ביניים שחולקים את אותו נושא ואת אותם פרטי מפתח ציבורי (Subject Public Key Info).

לא מתבצע אימות.

 ALLOW_INVALID_OR_MISSING_CLIENT_CERT

client_cert_present: true

client_cert_chain_verified: false

client_cert_error: client_cert_pki_too_large

client_cert_sha256_fingerprint: <cert hash>

אישור ביניים שסופק לאימות כלל יותר מ-10 מגבלות שם.

 ALLOW_INVALID_OR_MISSING_CLIENT_CERT

client_cert_present: true

client_cert_chain_verified: false

client_cert_error: client_cert_chain_max_name_constraints_exceeded

client_cert_sha256_fingerprint: <cert hash>

לאישור הלקוח אין תוסף Extended Key Usage (EKU) שכולל את clientAuth.

 ALLOW_INVALID_OR_MISSING_CLIENT_CERT

client_cert_present: true

client_cert_chain_verified: false

client_cert_error: client_cert_chain_invalid_eku

client_cert_sha256_fingerprint: <cert hash>
הזמן הקצוב פג במהלך הניסיון לאמת את שרשרת האישורים. ALLOW_INVALID_OR_MISSING_CLIENT_CERT

client_cert_present: true

client_cert_chain_verified: false

client_cert_error: client_cert_validation_timed_out

client_cert_sha256_fingerprint: <cert hash>

הגעת למגבלת העומק או האיטרציה בזמן הניסיון לאמת את שרשרת האישורים.

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

 ALLOW_INVALID_OR_MISSING_CLIENT_CERT

client_cert_present: true

client_cert_chain_verified: false

client_cert_error: client_cert_validation_search_limit_exceeded

client_cert_sha256_fingerprint: <cert hash>

הגדרתם mTLS בלי להגדיר משאב TrustConfig.

לא ניתן לבצע אימות, אבל גיבוב האישור מועבר לקצה העורפי.

 ALLOW_INVALID_OR_MISSING_CLIENT_CERT

client_cert_present: true

client_cert_chain_verified: false

client_cert_error: client_cert_validation_not_performed

client_cert_sha256_fingerprint: <cert hash>
אין אישור לקוח. ALLOW_INVALID_OR_MISSING_CLIENT_CERT

client_cert_present: false

client_cert_chain_verified: false

client_cert_error: client_cert_not_provided

client_cert_sha256_fingerprint: <empty>
אישור הלקוח נכשל באימות מול המשאב TrustConfig. ALLOW_INVALID_OR_MISSING_CLIENT_CERT

client_cert_present: true

client_cert_chain_verified: false

client_cert_error: client_cert_validation_failed

client_cert_sha256_fingerprint: <cert hash>
אישור הלקוח עובר את האימות של מאמת האישורים. לא רלוונטי

client_cert_present: true

client_cert_chain_verified: true

client_cert_error: <empty>

client_cert_sha256_fingerprint: <cert hash>

client_cert_serial_number: <serial_number>

client_cert_valid_not_before: <date>

client_cert_valid_not_after: <date>

client_cert_uri_sans: <list>

client_cert_dnsname_sans: <list>

client_cert_issuer_dn: <issuer>

client_cert_subject_dn: <subject>

client_cert_leaf: <certificate>

client_cert_chain: <list>

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

חלק מערכי המשתנים של כותרת mTLS בהתאמה אישית הם ייצוגים של מחרוזות בקידוד Base64 של נתוני אישורים בינאריים של Distinguished Encoding Rules ‏(DER). אפשר לפענח מחרוזות בקידוד Base64 באמצעות כלים או ספריות תוכנה לבחירתכם. הנה כמה דוגמאות:

  • במערכות macOS ו-Linux אפשר להשתמש בכלי שורת הפקודה base64, שהוא כלי ליבה שכלול בשתי מערכות ההפעלה. כדי לפענח מחרוזות בקידוד Base64 באמצעות הכלי base64, מעבירים את המחרוזת המקודדת כקלט סטנדרטי לפקודה base64 ומשתמשים בדגל -d כדי לפענח את המחרוזת, באופן הבא:

    echo BASE_64_ENCODED_STRING | base64 -d

  • ‫Python כולל את המודול base64, שבו אפשר להשתמש כדי לפענח מחרוזות בקידוד Base64 באופן הבא:

    import base64
encoded_string=BASE_64_ENCODED_STRING
decoded_string=base64.b64decode(encoded_string).decode()
print(decoded_string) # Note that a newline character (\n) is added to the end of the string.

טיפול בשגיאות ורישום ביומן

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

שגיאות שנרשמו ביומן במצבים REJECT_INVALID ו-ALLOW_VALIDATION_RELAXATIONS

אם אימות אישור הלקוח נכשל, ומצב אימות הלקוח מוגדר ל-REJECT_INVALID או ל-ALLOW_VALIDATION_RELAXATIONS, החיבור מסתיים והשגיאות נרשמות ב-Cloud Logging. השגיאות האלה מתוארות בטבלה הבאה.

סטטוס אישור הלקוח שגיאה שתועדה ביומן
שרשרת אישורי הלקוח ארוכה מדי (יותר מ-10 אישורי ביניים כלולים באישור הלקוח). client_cert_chain_exceeded_limit

לאישור לקוח או לאישור ביניים יש גודל מפתח RSA לא חוקי.

לא מתבצע אימות.

מפתחות RSA יכולים להיות בגודל של 2,048 עד 4,096 ביט.

 client_cert_invalid_rsa_key_size

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

לא מתבצע אימות.

העקומות התקינות הן P-256 ו-P-384.

 client_cert_unsupported_elliptic_curve_key

הלקוח או אישור ביניים משתמשים באלגוריתם שאינו RSA או ECDSA.

לא מתבצע אימות.

 client_cert_unsupported_key_algorithm

ב-PKI שמשמש לאימות יש יותר מ-10 אישורים ביניים שחולקים את אותם פרטי מפתח ציבורי (Subject Public Key Info) ונושא.

לא מתבצע אימות.

 client_cert_pki_too_large

אישור ביניים שסופק לאימות כלל יותר מ-10 מגבלות שם.

client_cert_chain_max_name_constraints_exceeded

לאישור הלקוח אין תוסף Extended Key Usage (EKU) שכולל את clientAuth.

client_cert_chain_invalid_eku
הזמן הקצוב פג במהלך הניסיון לאמת את שרשרת האישורים. client_cert_validation_timed_out

הגעת למגבלת העומק או האיטרציה בזמן הניסיון לאמת את שרשרת האישורים.

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

 client_cert_validation_search_limit_exceeded
הגדרתם mTLS בלי להגדיר משאב TrustConfig. client_cert_validation_not_performed
הלקוח לא סיפק את האישור המבוקש במהלך לחיצת היד. client_cert_not_provided
אישור הלקוח נכשל באימות עם המשאב TrustConfig. client_cert_validation_failed

שגיאות שנרשמו ביומן לגבי חיבורים שנסגרו

כשמגדירים את מצב אימות הלקוח, שגיאות מסוימות גורמות לסגירת החיבורים ומתועדות ב-Cloud Logging. השגיאות האלה מתוארות בטבלה הבאה.

סטטוס אישור הלקוח בקשה שגיאה שתועדה ביומן
אישור הלקוח לא תואם לחתימה במהלך לחיצת היד. סיום לחיצת היד של SSL ללא
השירות לא יכול לבצע אימות של שרשרת האישורים. סיום החיבור client_cert_validation_unavailable
שגיאה פנימית באימות שרשרת האישורים. סיום החיבור client_cert_validation_internal_error
לא נמצאה התאמה ל-TrustConfig. סיום החיבור client_cert_trust_config_not_found
המטען הייעודי (payload) של אישור הלקוח (כולל אישורי ביניים) גדול מדי (יותר מ-16KB). סיום החיבור client_cert_exceeded_size_limit

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

מגבלות

  • מאזן העומסים לא מבצע בדיקות ביטול של אישורי לקוח.

  • במאזני עומסים של אפליקציות אפשר להעלות הגדרת אמינות עם מאגר אישורים אחד, שמכיל לכל היותר: 200 ישויות עוגן אמינות ואישורי ביניים (מספר אישורי הביניים מוגבל ל-100) ו-500 אישורים שנוספים לרשימת ההיתרים. לכל אישורי הביניים לא יכולים להיות יותר משלושה אישורים שחולקים את אותו נושא ואת אותם פרטי מפתח ציבורי (Subject Public Key Info). מידע נוסף זמין בקטע מכסות ומגבלות.

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

  • המפתחות של האישורים שהועלו והועברו מהלקוח מוגבלים לאלה:

    • מפתחות RSA יכולים להיות בגודל של 2,048 עד 4,096 ביט. מידע נוסף זמין במאמר מכסות ומגבלות.
    • מפתחות ECDSA יכולים להשתמש בעקומות P-256 או P-384.

  • שרשרת האישורים הקבילה שמתקבלת מהלקוח מוגבלת ל-16KB ול-10 אישורים. מידע נוסף זמין במאמר מכסות ומגבלות.

  • אישורי בסיס שמשמשים לאימות לא יכולים להכיל יותר מ-10 מגבלות שם. מידע נוסף זמין במאמר מכסות ומגבלות.

  • ממשקי הקצה של Google‏ (GFE) בשכבה 1 אוכפים זמן קצוב לתפוגה של 10 שניות, שלא ניתן להגדרה, להצגת האישור של הלקוח במהלך לחיצת היד בפרוטוקול TLS. בזמן עומס שיא, יכול להיות שזמן הקצוב לתפוגה יהיה קצר יותר. הלקוחות צריכים להשלים את הצגת האישור בפרק הזמן הזה כדי ליצור חיבור mTLS תקין.

המאמרים הבאים