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

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

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

בדף הזה נסביר על אישורי SSL ועל הצפנה במעבר בין מאזן עומסים של אפליקציות (ALB) או מאזן עומסי רשת בשרת proxy שמשתמש ב-SSL לבין הלקוחות שלו. לפרטים על הצפנה במעבר בין מאזן העומסים של Google Cloud לבין הקצוות העורפיים שלו, קראו את המאמר הצפנה לקצוות העורפיים.

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

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

  • שרת proxy לחלוקת העומס מפנה לאישורי SSL של Compute Engine: בשיטה הזו, שרת ה-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: שרת ה-proxy של היעד של מאזן העומסים יכול להפנות בו-זמנית גם למפת אישורים וגם לאישור SSL אחד או יותר של Compute Engine.

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

סוגי אישורים

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

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

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

  • אימות דומיין (DV)
  • אימות ארגון (OV)
  • אישורי Extended Validation‏ (EV)

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

אישורי SSL בניהול Google

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

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

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

  • משאבי אישורי SSL של Compute Engine: רק משאבי sslCertificates גלובליים של Compute Engine תומכים באישורי SSL בניהול Google. משאבי regionSslCertificates לא תומכים בהם. אישורי SSL גלובליים של Compute Engine תומכים רק באישורים בניהול Google שמהימנים באופן ציבורי. מידע נוסף זמין במאמר שימוש באישורי SSL בניהול Google.
  • מנהל האישורים: האישורים של מנהל האישורים (גם גלובליים וגם אזוריים) תומכים באישורים שמנוהלים על ידי 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 מרובים

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

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

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

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

למידע נוסף:

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

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

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

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

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

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

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

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

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

      • ההתאמה מתבצעת גם לפי השם הנפוץ (CN) וגם לפי השם החלופי של הבעלים (SAN) במאפייני האישור. שמות הדומיינים במאפיינים CN ו-SAN יכולים להכיל רק אותיות קטנות. אישורים עם אותיות רישיות בשמות הדומיינים מוחזרים רק כשהם מוגדרים כאישור הראשי בשרת ה-proxy לחלוקת העומס.

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

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

        • התאמה של שם מארח עם תו כללי לחיפוש: אם אין התאמה מדויקת, מאזן העומסים בודק אם יש התאמה של CN או SAN עם תו כללי לחיפוש. תו כללי לחיפוש (*) תואם רק לתת-הדומיין ברמה הראשונה (לדוגמה, *.pets.example.com תואם ל-cats.pets.example.com ולא ל-*.example.com).

        • סוג מפתח האישור: עדיף להשתמש באישורי ECDSA על פני אישורי RSA.

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

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

        • אישור א'

          • ‫CN:‏ cats.pets.example.com
          • ‫SAN:‏ cats.pets.example.com,‏ *.pets.example.com,‏ *.example.com

        • אישור ב'

          • ‫CN:‏ dogs.pets.example.com
          • ‫SAN:‏ 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 נכשל אם הלקוח לא תומך בסט אלגוריתמים להצפנה (cipher suite) שכולל את אלגוריתם המפתח הציבורי (ECDSA או RSA) של האישור שנבחר על ידי מאזן העומסים.

תמחור

למידע על התמחור של אישורי SSL ב-Compute Engine ושל Cloud Load Balancing, קראו את המאמר תמחור רשת: Cloud Load Balancing.

למידע על התמחור של Certificate Manager, קראו את דף התמחור של Certificate Manager.

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

נסו בעצמכם

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

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