אפשר להשתמש ב-Public Certificate Authority כדי להקצות ולפרוס אישורי X.509 שזוכים לאמון רחב, אחרי אימות השליטה של מבקש האישור בדומיינים. בעזרת CA ציבורי אפשר לבקש באופן ישיר ותוך שימוש בתכנות אישורי TLS מהימנים באופן ציבורי, שכבר נמצאים בבסיס של מאגרי האישורים המהימנים שמשמשים דפדפנים, מערכות הפעלה ואפליקציות מרכזיים. אפשר להשתמש באישורי TLS האלה כדי לאמת ולהצפין את הטראפיק באינטרנט.
רשות אישורים ציבורית מאפשרת לכם לנהל תרחישי שימוש בנפח גבוה שרשויות אישורים אחרות לא הצליחו לתמוך בהם. אם אתם לקוחות של Google Cloud , אתם יכולים לבקש אישורי TLS לדומיינים שלכם ישירות מרשות אישורים ציבורית.
רוב הבעיות שקשורות לאישורים נובעות מטעות אנוש או מהשמטה, ולכן מומלץ להפוך את מחזורי החיים של האישורים לאוטומטיים. רשות אישורים ציבורית משתמשת בפרוטוקול ACME (סביבה לניהול אוטומטי של אישורים) כדי לספק, לחדש ולבטל אישורים באופן אוטומטי. ניהול אוטומטי של אישורים מפחית את זמן ההשבתה שאישורים שפג תוקפם עלולים לגרום לו, ומצמצם את עלויות התפעול.
רשות אישורים ציבורית מספקת אישורי TLS לכמה שירותים, כמו App Engine, Cloud Shell, Google Kubernetes Engine ו-Cloud Load Balancing. Google Cloud
למי כדאי להשתמש ב-CA ציבורי
אפשר להשתמש ב-CA ציבורי מהסיבות הבאות:
- אם אתם מחפשים ספק TLS עם זמינות גבוהה, יכולת הרחבה, אבטחה ואמינות.
- אם אתם רוצים שרוב אישורי ה-TLS, אם לא כולם, לתשתית שלכם, כולל עומסי עבודה מקומיים והגדרות של ספקי שירותי ענן שונים, יגיעו מספק שירותי ענן יחיד.
- אם אתם צריכים שליטה וגמישות בניהול אישורי TLS כדי להתאים אותם לדרישות התשתית שלכם.
- אם רוצים להפוך את ניהול אישורי ה-TLS לאוטומטי, אבל אי אפשר להשתמש באישורים מנוהלים בשירותים כמו GKE או Cloud Load Balancing. Google Cloud
מומלץ להשתמש באישורים מהימנים באופן ציבורי רק אם דרישות העסק לא מאפשרות אפשרות אחרת. בהתחשב בעלות ההיסטורית ובמורכבות של תחזוקת היררכיות של תשתית מפתח ציבורי (PKI), הרבה ארגונים משתמשים בהיררכיות של PKI ציבורי גם כשנכון יותר להשתמש בהיררכיות פרטיות.
השמירה על היררכיות ציבוריות ופרטיות הפכה לפשוטה הרבה יותר עם מגוון Google Cloud הצעות. מומלץ לבחור בקפידה את סוג ה-PKI שמתאים לתרחיש לדוגמה שלכם.
אם יש דרישות לאישור שלא גלוי לכולם, Google Cloud מציע שני פתרונות קלים לניהול:
Anthos Service Mesh: Cloud Service Mesh כולל הקצאה אוטומטית מלאה של אישורי mTLS לעומסי עבודה שפועלים ב-GKE Enterprise באמצעות רשות האישורים של Cloud Service Mesh.
Certificate Authority Service: Certificate Authority Service מאפשר לפרוס, לנהל ולאבטח רשויות אישורים פרטיות מותאמות אישית ביעילות, בלי לנהל את התשתית.
היתרונות של רשות אישורים ציבורית
היתרונות של שימוש ב-CA ציבורי:
אוטומציה: דפדפני האינטרנט שואפים להצפין את כל תעבורת הנתונים ולהקטין את תקופות התוקף של האישורים, ולכן קיים סיכון בשימוש באישור TLS שתוקפו פג. תפוגה של אישור עלולה לגרום לשגיאות באתר ולהפסקות זמניות בשירות. רשות אישורים ציבורית מאפשרת לכם להגדיר את שרת ה-HTTPS כך שיקבל ויחדש באופן אוטומטי את אישורי ה-TLS הנדרשים מנקודת הקצה (endpoint) של ACME, וכך נמנעת הבעיה של תפוגת האישורים.
תאימות: רשות אישורים ציבורית עוברת באופן קבוע ביקורות קפדניות ובלתי תלויות של אמצעי הבקרה בתחומי האבטחה, הפרטיות והתאימות. החותמות של Webtrustשניתנות כתוצאה מהביקורות השנתיות האלה מראות שהרשות לאישור חתימה דיגיטלית (CA) עומדת בכל תקני התעשייה הרלוונטיים.
אבטחה: הארכיטקטורה והפעולות של Public CA מתוכננות בהתאם לסטנדרטים הגבוהים ביותר של אבטחה, ובמסגרת השירות מתבצעות באופן קבוע הערכות עצמאיות כדי לוודא שהתשתית הבסיסית מאובטחת. רשות אישורים ציבורית עומדת בכל הדרישות של אמצעי הבקרה, השיטות התפעוליות ואמצעי האבטחה שמפורטים במסמך המידע בנושא אבטחה של Google, או עולה עליהן.
ההתמקדות של רשויות אישורים ציבוריות באבטחה מתרחבת לתכונות כמו אימות דומיין מנקודות מבט שונות. התשתית של רשות אישורים ציבורית מפוזרת ברחבי העולם. לכן, רשות אישורים ציבורית דורשת הסכמה ברמה גבוהה בין נקודות מבט מגוונות מבחינה גיאוגרפית, שמספקת הגנה מפני חטיפת פרוטוקול Border Gateway (BGP) והתקפות של חטיפת שרת DNS.
אמינות: השימוש בתשתית הטכנית המוכחת של Google הופך את Public CA לשירות זמין וניתן להתאמה.
זמינות בכל מקום: הזמינות הרחבה של Google Trust Services בדפדפנים עוזרת לוודא ששירותים שמשתמשים באישורים שמונפקים על ידי רשות אישורים ציבורית פועלים במגוון רחב ככל האפשר של מכשירים ומערכות הפעלה.
פתרונות TLS יעילים להגדרות היברידיות: רשות אישורים ציבורית מאפשרת לכם לבנות פתרון מותאם אישית לאישור TLS שמשתמש באותה רשות אישורים לתרחישים ולמקרים שונים. רשות אישורים ציבורית מתאימה לתרחישי שימוש שבהם עומסי עבודה פועלים בסביבה מקומית או בסביבה של ספק חוצה-ענן.
התאמה לגודל: לעיתים קרובות, קשה להשיג אישורים, לספק אותם ולתחזק אותם, והעלויות שלהם גבוהות. הגישה לכמויות גדולות של אישורים שמתאפשרת באמצעות רשות אישורים ציבורית מאפשרת לכם להשתמש באישור ולנהל אותו בדרכים שבעבר נחשבו ללא מעשיות.
שימוש ב-CA ציבורי עם Certificate Manager
כדי להשתמש בתכונה 'רשות אישורים ציבורית' ב-Certificate Manager, צריך להכיר את המושגים הבאים:
לקוח ACME. לקוח ACME (סביבה לניהול אוטומטי של אישורים) הוא לקוח לניהול אישורים שמשתמש בפרוטוקול ACME. לקוח ה-ACME שלכם צריך לתמוך בקישור חיצוני של חשבונות (EAB) כדי לעבוד עם רשות אישורים ציבורית.
קישור חשבונות חיצוניים (EAB). צריך לקשר כל חשבון ACME שבו אתם משתמשים עם רשות אישורים ציבורית של Certificate Manager לפרויקט היעד Google Cloud באמצעות קישור חשבון חיצוני. כדי לעשות זאת, צריך לרשום כל חשבון ACME באמצעות סוד שמקושר לפרויקט המתאים. Google Cloud מידע נוסף זמין במאמר קישור חשבון חיצוני.
אתגרים של רשות אישורים ציבורית
כשמשתמשים ברשות אישורים ציבורית כדי לבקש אישור, הכלי לניהול אישורים מבקש להוכיח שיש לכם שליטה בדומיינים שמפורטים באישור. כדי להוכיח שיש לכם שליטה בדומיין, אתם יכולים לפתור אתגרים. רשות אישורים ציבורית מאשרת את שמות הדומיינים אחרי שמוכיחים שיש לכם שליטה בדומיינים של היעד.
אחרי שתקבלו את ההרשאות הנדרשות, תוכלו לבקש אישורים שתקפים רק למשך זמן מסוים. אחרי התקופה הזו, תצטרכו לאמת מחדש את שם הדומיין על ידי פתרון של אחד משלושת סוגי האתגרים כדי להמשיך לבקש אישורים.
סוגים של שיטות אימות
רשות אישורים ציבורית תומכת בסוגי האתגרים הבאים:
אתגר HTTP. האתגר הזה כולל יצירת קובץ במיקום מוכר בשרת HTTP (יציאה 80) כדי שרשות ציבורית שמנפיקה אישורים (CA) תוכל לאחזר ולאמת אותו. מידע נוסף אפשר למצוא במאמר בנושא אתגר HTTP.
אתגר של משא ומתן על פרוטוקול שכבת האפליקציה (ALPN) של TLS. נדרש ששרת יספק אישור ספציפי במהלך משא ומתן על TLS ביציאה 443 כדי להוכיח שליטה בדומיין. מידע נוסף זמין במאמר בנושא ACME TLS-ALPN challenge extension.
אתגר DNS. כדי להוכיח שליטה בדומיין, צריך להוסיף רשומת DNS ספציפית במיקום מוגדר. מידע נוסף זמין במאמר בנושא אימות באמצעות DNS.
אם משתמשים באתגר HTTP או באתגר TLS-ALPN כדי לאמת שם דומיין, הלקוח יכול לבקש לכלול באישור רק את שמות הדומיינים שאומתו. אם משתמשים באתגר DNS, הלקוח יכול גם לבקש לכלול באישור שמות של תת-דומיינים של שם הדומיין הזה.
לדוגמה, אם מאמתים את *.myorg.example.com באמצעות אימות DNS, האימות של subdomain1.myorg.example.com ושל subdomain2.myorg.example.com מתבצע באופן אוטומטי באמצעות תעודת wildcard. עם זאת, אם מאמתים את myorg.example.com באמצעות אתגר HTTP או TLS-ALPN, הלקוח יכול לבקש לכלול את myorg.example.com באישור, ואי אפשר לאמת את *.myorg.example.com באמצעות אתגרים שאינם DNS.
לוגיקה של פתרון האתגר
הלוגיקה של האתגר של רשות אישורים ציבורית היא כזו:
- רשות אישורים ציבורית מספקת טוקן אקראי.
- הלקוח מאפשר גישה לאסימון במיקום מוגדר היטב. המיקום תלוי באתגר.
- הלקוח מציין לרשות האישורים הציבורית שהוא הכין את האתגר.
- באימות CA ציבורי, המערכת בודקת אם הטוקן שמופיע במיקום הצפוי תואם לערך הצפוי.
שם הדומיין יאושר אחרי שהתהליך הזה יושלם. הלקוח יכול לבקש אישור עם שם הדומיין הזה. צריך לפתור רק אתגר אחד לכל שם דומיין.