סקירה כללית של אישורי SSL

‫SSL/TLS הוא פרוטוקול ההצפנה הנפוץ ביותר באינטרנט. מבחינה טכנית, TLS הוא המחליף של SSL, אבל לפעמים משתמשים במונחים האלה לסירוגין, כמו במסמך הזה.

‫Transport Layer Security ‏ (TLS) משמש להצפנת מידע בזמן שהוא נשלח ברשת, ומספק פרטיות בין לקוח לשרת או למאזן עומסים. מאזן עומסים של אפליקציות או מאזן עומסי רשת בשרת proxy שמשתמש ב-SSL דורש לפחות מפתח פרטי אחד ואישור SSL.

שיטות להגדרת אישורים

‫Google Cloud מציע שלוש שיטות להגדרת אישורים למאזני עומסים של אפליקציות באמצעות שרתי proxy של HTTPS ליעדים, ולמאזני עומסים של רשתות באמצעות שרתי proxy של SSL ליעדים.

  • הפניה ל-SSL ב-Compute Engine באמצעות Proxy יעד: בשיטה הזו, ה-Proxy היעד של מאזן העומסים יכול להפנות ל-15 משאבי אישור SSL של Compute Engine לכל היותר. כל משאב של אישור SSL ב-Compute Engine מכיל את המפתח הפרטי, את האישור התואם וגם אישורי CA (אופציונלי).

  • הפניה ל-proxy ליעד היא מיפוי אישורים ב-Certificate Manager: בשיטה הזו, ה-proxy ליעד של מאזן העומסים מפנה למיפוי אישורים יחיד. כברירת מחדל, מפת האישורים תומכת באלפי רשומות, ויכולה להתרחב למיליוני רשומות. כל רשומה מכילה מפתח פרטי ונתוני אישור.

  • שרת proxy ליעד מפנה ישירות לאישורים של Certificate Manager: בשיטה הזו, שרת proxy ליעד של מאזן העומסים יכול להפנות ל-100 אישורים של Certificate Manager לכל היותר.

תמיכה במאזן עומסים

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

מאזן עומסים שיטת ההגדרה של האישור
אישורי SSL ב-Compute Engine Certificate Manager (מפת אישורים) Certificate Manager (אישורים פרטיים)
מאזני עומסים של אפליקציות (proxy ל-HTTPS עם יעד)
מאזן עומסים גלובלי חיצוני של אפליקציות (ALB) בניהול עצמי
בניהול Google 		בניהול עצמי
בניהול Google
מאזן עומסים קלאסי של אפליקציות (ALB) בניהול עצמי
בניהול Google 		בניהול עצמי
בניהול Google
מאזן עומסים חיצוני אזורי של אפליקציות (ALB) בניהול עצמי
בניהול Google 		בניהול עצמי
בניהול Google
מאזן עומסים פנימי אזורי של אפליקציות (ALB) בניהול עצמי
בניהול Google 		בניהול עצמי
בניהול Google
מאזן עומסים פנימי של אפליקציות (ALB) שפועל בכמה אזורים בניהול עצמי
בניהול Google
מאזני עומסי רשת לשרת proxy (שרתי proxy יעד ל-SSL)
מאזן עומסי רשת גלובלי חיצוני בשרת proxy בניהול עצמי
בניהול Google 		בניהול עצמי
בניהול Google
מאזן עומסי רשת קלאסי בשרת proxy בניהול עצמי
בניהול Google 		בניהול עצמי
בניהול Google

כללים לשיטת ההגדרה

הקודGoogle Cloud אוכף את הכללים הבאים של שיטת הגדרת האישורים:

  • למאזני עומסים שתומכים גם באישורי SSL של Compute Engine וגם במיפוי אישורים של Certificate Manager: פרוקסי היעד של מאזן העומסים יכול להפנות בו-זמנית גם למיפוי אישורים וגם לאישור SSL אחד או יותר של Compute Engine.

  • למאזני עומסים שתומכים גם באישור SSL של Compute Engine וגם באישור של Certificate Manager שמצורף ישירות: אפשר להגדיר את שרת ה-proxy של מאזן העומסים כך שיפנה ל-15 אישורי SSL של Compute Engine לכל היותר, או ל-100 אישורים של Certificate Manager לכל היותר, ולא לשילוב של שניהם.

סוגי אישורים

Google Cloud תומך באישורים בניהול עצמי ובאישורים שמנוהלים על ידי Google.

אישורי SSL בניהול עצמי

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

  • אימות דומיין (DV)
  • אימות הארגון (OV)
  • אישורים עם אימות מורחב (EV)

אפשר ליצור אישורי SSL בניהול עצמי באמצעות:

אישורי SSL שמנוהלים על ידי Google

אישורי SSL בניהול Google הם אישורים ש-Google משיגה, מנהלת ומחדשת באופן אוטומטי. Google Cloudאישורים שמנוהלים על ידי Google הם תמיד אישורים של אימות דומיין (DV). הם לא מוכיחים את הזהות של ארגון או אדם שמשויכים לאישור.

אישורים שמנוהלים על ידי Google באמצעות תווים כלליים נתמכים רק על ידי Certificate Manager כשמשתמשים באימות DNS.

אפשר ליצור אישורי SSL בניהול Google באמצעות:

  • משאבי אישורי SSL של Compute Engine: רק משאבי Compute Engine גלובליים sslCertificates תומכים באישורי SSL בניהול Google. משאבי regionSslCertificates לא תומכים בהם. אישורי SSL גלובליים של Compute Engine תומכים רק באישורים ש-Google מנהלת ושיש להם אמון ציבורי. מידע נוסף זמין במאמר בנושא שימוש באישור SSL בניהול Google.
  • ‫Certificate Manager: אישורים של Certificate Manager (גלובליים ואזוריים) תומכים באישורים שמנוהלים על ידי Google ומהימנים באופן ציבורי, וגם באישורים שמנוהלים על ידי Google ומהימנים באופן פרטי. מידע נוסף מופיע במאמר אישורים במסמכי התיעוד של Certificate Manager.

סוגי מפתחות נתמכים

מאזני עומסים תומכים באישורים שמשתמשים במפתחות פרטיים מסוגי מפתחות שונים. בטבלה הבאה מוצגת התמיכה בסוגי מפתחות בהתאם לסוג האישורים: גלובליים או אזוריים, בניהול עצמי או בניהול Google.
סוג אישור SSL arrow_forward

סוג מפתח arrow_downward 		אישורי SSL ב-Compute Engine אישורי SSL ב-Certificate Manager
עולמי אזורי גלובלי ואזורי
נהלו את הכל בעצמכם מנוהל על ידי Google ומהימן לציבור נהלו את הכל בעצמכם נהלו את הכל בעצמכם מנוהל על ידי Google ומהימן לציבור פרטי, מהימן, מנוהל על ידי Google
RSA-2048
RSA-3072
RSA-4096
ECDSA P-256
ECDSA P-384
מידע נוסף על אישורים של Certificate Manager זמין במאמרי העזרה של Certificate Manager.

שימוש באישור עם מפתחות ECDSA

בקטע הזה נסביר למה אנחנו ממליצים על ECDSA במקום על RSA כשיטה מומלצת למפתחות לחתימה על אישורים.

באיזה סוג מפתח להשתמש

ECDSA P-256 הוא סוג המפתח המומלץ לרוב אישורי ה-TLS, והוא מספק אבטחה קריפטוגרפית חזקה לצד ביצועים מצוינים לפעולות חתימה ושימוש יעיל ברוחב הפס של הרשת.

אלה כמה מהסיבות האפשריות לשימוש בסוגים אחרים של מפתחות אישורים:

  • אם אתם צריכים לתמוך בלקוחות מדור קודם שלא תומכים באישור ECDSA, אתם יכולים לספק אישורי RSA-2048 בנוסף לאישורי ECDSA P-256.
  • אם יש לכם דרישות תאימות ספציפיות שמחייבות שימוש בגדלים גדולים יותר של מפתחות או בסוגים מסוימים של מפתחות, אפשר להשתמש במפתחות ECDSA P-384,‏ RSA-2048,‏ RSA-3072 ו-RSA-4096.

למה כדאי לבחור ב-ECDSA במקום ב-RSA

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

לדוגמה:

  • מפתח ECDSA של 256 ביט מספק רמת אבטחה דומה למפתח RSA-3072.
  • מפתח ECDSA של 384 ביט מספק רמת אבטחה גבוהה יותר מכל גודל מפתח RSA שנתמך באופן נרחב.

היתרונות העיקריים של ECDSA:

  • ביצועים: פעולות חתימה של ECDSA דורשות הרבה פחות משאבי מחשוב מאשר פעולות של RSA, ומספקות רמת אבטחה שוות ערך. הפעולה הזו מפחיתה את העומס על ה-CPU ואת זמן האחזור, וזה חשוב מאוד למערכות עם תפוקה גבוהה או למערכות שרגישות לזמן האחזור.

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

אישורי SSL מרובים

מאזן עומסים של אפליקציות או מאזן עומסי רשת proxy יכולים לארח שני אישורי SSL או יותר בו-זמנית, אם ה-proxy של היעד מוגדר באמצעות שיטה נתמכת להגדרת אישורים. מומלץ להשתמש ב-Certificate Manager כשנדרשים כמה אישורי SSL.

  • במאזני עומסים שתומכים באישורי SSL של Compute Engine: ה-proxy של היעד במאזן העומסים יכול להפנות ל-15 אישורי SSL של Compute Engine לכל היותר. המשאב הראשון של אישור ה-SSL של Compute Engine שאליו יש הפניה הוא אישור ברירת המחדל (הראשי) של ה-proxy של היעד.

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

  • מאזני עומסים שתומכים בהפניה ישירה לאישורים של Certificate Manager: פרוקסי היעד של מאזן העומסים יכול להפנות לעד 100 אישורים של Certificate Manager. המשאב הראשון של אישור ה-SSL של Certificate Manager שאליו יש הפניה הוא אישור ברירת המחדל (הראשי) של ה-proxy של היעד.

למידע נוסף:

תהליך בחירת האישור

תהליך בחירת האישורים הבא חל על מאזני עומסים שבהם הפרוקסי של היעד מפנה לכמה אישורי SSL של Compute Engine או לכמה אישורים של Certificate Manager.

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

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

  • אם הפרוקסי של יעד איזון העומסים מפנה רק לאישור אחד, האישור הזה ישמש לאימות, והערך של שם המארח של SNI שנשלח על ידי הלקוח לא רלוונטי.

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

    • אם הלקוח לא שלח שם מארח של SNI ב-ClientHello, מאזן העומסים משתמש באישור הראשון ברשימת האישורים שלו.

    • אם הלקוח שולח שם מארח של SNI שלא תואם לשם נפוץ (CN) של אף אישור, ושלא תואם לשם נושא חלופי (SAN) של אף אישור, מאזן העומסים משתמש באישור הראשון ברשימת האישורים שלו.

    • בכל מצב אחר: מאזן העומסים בוחר אישור באמצעות תהליך ההתאמה הבא:

      • ההתאמה מתבצעת לפי הסיומת הארוכה ביותר מול השם הנפוץ (CN) ומול שם חלופי של בעלים (subject) של מאפייני האישור, עם עדיפות לאישורי ECDSA על פני אישורי RSA.

      • כדי להמחיש את שיטת ההתאמה, נניח שיש proxy ליעד שמפנה לשני האישורים הבאים:

        • אישור א'

          • ‫CN: cats.pets.example.com
          • ‫SANs: cats.pets.example.com, *.pets.example.com, *.example.com

        • אישור ב'

          • ‫CN: dogs.pets.example.com
          • ‫SANs: dogs.pets.example.com, *.pets.example.com, *.example.com

      • עכשיו נבחן את התרחישים הבאים:

        • אם שם המארח של SNI שנשלח על ידי הלקוח הוא cats.pets.example.com, מאזן העומסים משתמש באישור א'.
        • אם שם המארח של SNI שנשלח על ידי הלקוח הוא ferrets.pets.example.com, אין התאמה מדויקת, ולכן מאזן העומסים בוחר באחד מהאישורים, אישור א' או אישור ב', כי שניהם כוללים את *.pets.example.com ברשימת ה-SAN שלהם. במצב הזה, אין לכם אפשרות לשלוט באישור שנבחר.

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

תמחור

כשמשתמשים במאזני עומסים של Google Cloud , נוצרים חיובים על שימוש ברשת. מידע נוסף זמין במאמר בנושא תמחור של כל שירותי הרשת. למידע על המחירים של Certificate Manager, אפשר לעיין במאמר מחירים במסמכי התיעוד של Certificate Manager. אין חיובים נוספים על שימוש במשאבי אישור SSL של Compute Engine.

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

נסו בעצמכם

אתם משתמשים חדשים ב- Google Cloud? אנחנו ממליצים לכם ליצור חשבון, להתנסות בעצמכם במוצרים שלנו ולבחון אותם באמצעות תרחישים ממשיים. לקוחות חדשים מקבלים בחינם גם קרדיט בשווי 300$ להרצה, לבדיקה ולפריסה של עומסי העבודה.

מתחילים לעבוד בלי לשלם