רשימת החסימה של Nebula: הפיצו אותה, המגדלור לא יעשה זאת
רשומת חסימה חלה רק על מארחים שטענו אותה. השוו הפצת הרשימה לסיבוב ה-CA, ואז אמתו עמית שנדחה ועמית שעובד.
אכיפת רשימת החסימה היא תכונה של המארח שמבצע את הבדיקה, לא של התעודה הנבדקת. מכונה שמעולם לא טענה את הרשומה ממשיכה לקבל את הזהות, ושום דבר בלחיצת היד לא מזהיר אתכם ששני עמיתים חלוקים. התיקון הזול והתיקון היקר לאותו אישור שנחשף נבדלים בהיקף ובאפשרות לחזור בהם, ולכן בחרו בכוונה. הסעיפים שלהלן מכסים מה הרשומה עושה, היכן חייבים למסור אותה, מתי סיבוב הוא התשובה הטובה יותר, וכיצד להוכיח שכל אחד מהם עבד.
מה רשומת חסימה באמת עושה
תצורת ה-PKI מפרטת טביעות אצבע שהמארח חייב לדחות למרות שהתעודה חתומה כחוק ולא פגה. האכיפה מתרחשת מקומית, מול הרשימה שהמארח טען כשהשירות עלה. שום דבר מהרשומה לא נוסע בתוך התעודה, ולכן עמית לא יכול ללמוד את ההחלטה מהאישור שמוצג לו. זו הסיבה שמגדלור אינו ממלא כאן תפקיד: מגדלורים עוזרים לעמיתים למצוא זה את זה ולהעביר תעבורה במקום שנתיב ישיר נכשל. הם שכבת גילוי והעברה, לא ערוץ להפצת תצורה.
עדכון מכונה אחת משנה את ההחלטות של אותה מכונה ומשאיר כל עמית אחר בדיוק כפי שהיה. לעמית שסומך על רשות החתימה ומעולם לא ראה את הרשומה אין סיבה לסרב לשום דבר. לכן בדיקת ביטול על ידי התבוננות במגדלור אינה מוכיחה דבר, כי מהרכיב שאתם מתבוננים בו מעולם לא התבקש לאכוף את הרשימה.
זהו את התעודה, לא את המכשיר
השתמשו בטביעת האצבע של האישור שאתם מתכוונים לדחות, כי שם מארח, תווית מכשיר או כתובת נוכחית מזהים מכונה היום ומשהו אחר בחודש הבא. אף אחת מהמחרוזות האלה לא מופיעה ברשימת החסימה, ואף אחד מהם לא שורד התקנה מחדש. הדפיסו את התעודה, קראו את טביעת האצבע, ובדקו שהיא שייכת לאישור שיוצא משימוש ולא למחליפו. קריאת שני הקבצים חשובה כשכבר הונפק מחליף, מפני שהתעודה הישנה והחדשה יכולות לחלוק שם ולהיות שונות בכל שדה אחר.
תעדו איזו טביעת אצבע נחסמה ומתי, כדי שביקורת מאוחרת תפריד בין שינוי שהושלם לשינוי שהתכוונתם לו. שימו לב גם למה הרשומה אינה עושה: היא אינה מבטלת את רשות החתימה, והיא אינה מונעת קבלת תעודה עתידית מאותה רשות. חסימת תעודת מארח והחלפת רשות שנפרצה הן פעולות שונות עם השלכות שונות.
nebula-cert print -path /etc/nebula/host.crt
pki:
blocklist:
- "a1b2c3d4e5f6"הפיצו אותה כמו כל תצורה אחרת
התייחסו לרשימה כתצורה עם מנגנון מסירה ולא כקובץ שמישהו עורך כשהוא נזכר. דחפו את הרשימה כולה ולא דלתא, כדי שמארח שהחמיץ עדכון קודם יתכנס במקום לצבור פערים. תיעוד ה-PKI של Nebula ממליץ בדיוק על כך, וכדאי לפעול לפי העצה כלשונה ולא לנסח אותה מחדש לתהליך ידני.
אשרו שהשירות הפועל טען מחדש את התוכן, ולא רק שהקובץ בדיסק השתנה. עקבו אחרי אילו מכונות יישמו את השינוי והשאירו את הרשימה הפתוחה גלויה עד שתתרוקן. מחשב נייד סגור לשבוע הוא עמית שמעולם לא למד את ההחלטה, והוא עלול להתחבר מחדש מרשת שאיש לא ציפה לה. תעדו את שיטת המסירה לצד טביעת האצבע, כי הביטול הבא יעשה בה שימוש חוזר והראשון הוא המקום שבו התהליך מאותר.
רשימת חסימה או סיבוב רשות
רשומת חסימה היא צרה: זהות אחת מפסיקה לעבוד וכל השאר ממשיך. סיבוב רשות החתימה הוא רחב: כל תעודה שהיא הנפיקה הופכת לא מהימנה, וכל מארח זקוק לאישור חדש ולעוגן אמון חדש. הראשון הוא ביטול ממוקד והשני הוא הגירה, ולכן הם דורשים אישורים שונים וחלונות תחזוקה שונים. הטבלה מעמידה את השניים זה לצד זה בהיקף, במאמץ ובאפשרות לחזור בהם.
| Question | Blocklist entry | Authority rotation |
|---|---|---|
| What stops working | One identity | Every certificate from that authority |
| Fleet work | Push one file and confirm a reload | New credentials and a new trust anchor everywhere |
| Reversible | Yes, remove the line | No, the old authority stays distrusted |
| Fits | A lost or stolen device | A leaked authority key |
מחשב נייד שאבד מחייב את רשימת החסימה, כי רדיוס הפגיעה הוא זהות אחת והשינוי הפיך אם חסמתם את טביעת האצבע הלא נכונה. מפתח רשות שדלף מחייב סיבוב, כי רשימת החסימה אינה יכולה לעזור בתעודות שטרם הונפקו. בין הקצוות האלה, שאלו אם האישור שנחשף יכול היה לחתום על משהו אחר, מפני שרשות היא יותר ממארח אחד.
כתבו את ההחלטה לפני תקרית, כי בחירה תחת לחץ נוטה להפיק את האפשרות הרחבה כברירת מחדל. בכל נתיב שתבחרו, פריט העבודה שנותר זהה: להוכיח שהאכיפה התרחשה במארחים החשובים. תיעוד טביעת האצבע והתאריך באותו רגע הוא מה שמאפשר את ההוכחה מאוחר יותר.
אמתו את הדחייה ואת השאר
התחברו מהזהות החסומה ואשרו את הכשל, ואז התחברו מעמית מורשה ואשרו שהוא עדיין מגיע למה שהוא צריך. שינוי שקורס לכולם אינו ביטול מוצלח. עשו את שניהם מהפעלות חדשות, כי מצב שמור במטמון יכול להסתיר את התוצאה.
בדקו אם הפעלה קיימת מסתיימת לאחר השינוי, ותעדו את ההתנהגות לגרסה ולתצורה שלכם במקום להניח שעריכת קובץ מסיימת משהו. האפשרות disconnect_invalid מכסה לקוחות שהתעודות שלהם פגו או אינן תקפות, לכן אשרו כיצד היא חלה על המקרה שלכם לפני שתסתמכו עליה. אם סיום מיידי הוא דרישה, בדקו אותו ספציפית ותעדו מה ראיתם. לאחר מכן חזרו על הבדיקה לאחר הפעלה מחדש, כי מארח שאוכף את הרשימה רק עד האתחול הבא סובל מבעיית מסירה שהבדיקה הראשונה הסתירה. מגדלור בריא אומר לכם שהגילוי עובד, לא שעמית כלשהו יישם מדיניות.