מדריך לרשומות CAA ואבטחת תעודות לדומיינים מנוהלים

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

CAA הוא קיצור של Certification Authority Authorization. זו רשומת DNS שמצהירה אילו רשויות אישורים מורשות להנפיק תעודות TLS עבור דומיין מסוים. כשגוף מנפיק מקבל בקשה לתעודה, הוא נדרש לבדוק את מדיניות ה-CAA לפני ההנפקה. אם הרשומה אוסרת עליו להנפיק, הבקשה אמורה להידחות.

השליטה אינה מוחלטת: CAA לא מחליף הגנה על חשבון ה-DNS, אימות רב-שלבי, ניהול הרשאות או ניטור תעודות. אבל הוא מוסיף מחסום ברור, סטנדרטי וקל יחסית לאכיפה. בפורטפוליו של עשרות או מאות דומיינים, זו בדיוק ההגנה שמונעת מחריגה קטנה להפוך לאירוע רחב.

מה רשומת CAA עושה בפועל

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

`example.co.il. CAA 0 issue "ca.example"`

במקרה הזה, רק רשות האישורים המזוהה כ-`ca.example` רשאית להנפיק תעודה רגילה עבור הדומיין. חשוב להבין שהערך אינו בהכרח שם המותג שמופיע בממשק שבו רכשתם את התעודה. יש להשתמש במזהה ההנפקה המדויק שמפרסם גוף האישורים הרלוונטי.

שלושת התגים שתפגשו בדרך כלל הם `issue`, `issuewild` ו-`iodef`. התג `issue` מגדיר מי רשאי להנפיק תעודות רגילות. `issuewild` מטפל בנפרד בתעודות Wildcard, כגון `*.example.co.il`. `iodef` מגדיר כתובת לדיווח על הפרות או ניסיונות הנפקה שלא עומדים במדיניות.

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

מדריך לרשומות CAA ואבטחת תעודות: תכנון לפני DNS

הטעות הנפוצה היא להוסיף רשומת CAA רק לאחר שהנפקת תעודה נכשלת. הגדרה נכונה מתחילה במיפוי. לפני שמכניסים רשומה לאזור ה-DNS, צריך לדעת מי מנפיק כיום תעודות, אילו דומיינים ותתי-דומיינים משתמשים בתעודות Wildcard, ואילו מערכות מבצעות חידוש אוטומטי באמצעות ACME או כלי CI/CD.

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

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

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

`example.co.il. CAA 0 issue ";"`

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

היררכיית DNS משנה את התוצאה

CAA נבדק בהיררכיה. אם אין רשומת CAA בשם המדויק שעבורו מתבקשת התעודה, גוף ההנפקה בודק ברמות האב של הדומיין. לכן רשומה ב-`example.co.il` יכולה להשפיע על `app.example.co.il`, `api.example.co.il` ותתי-דומיינים נוספים.

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

יש לתת תשומת לב מיוחדת לרשומות CNAME. אם שם הדומיין מפנה ב-CNAME ליעד אחר, בדיקת ה-CAA עשויה לעקוב אחרי שרשרת ההפניה בהתאם לכללי התקן. בסביבות שבהן תתי-דומיינים מנוהלים על ידי ספקים שונים, אל תניחו שהמדיניות בדומיין האב מכסה אוטומטית כל מקרה. בדקו את שרשרת ה-DNS ואת שיטת ההנפקה בפועל.

הגדרה בטוחה בלי לשבור חידושים

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

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

אם אתם משתמשים באוטומציית ACME, ודאו מראש איזה גוף מנפיק בפועל. כלי האוטומציה הוא לא בהכרח גוף האישורים. בדקו גם אם תהליך האימות משתמש ב-HTTP-01, ב-DNS-01 או בשיטה אחרת. CAA אינו מחליף את אימות השליטה בדומיין, אבל הוא יכול לעצור את ההנפקה עוד לפני שהאימות הופך לרלוונטי.

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

`iodef` הוא ערוץ התרעה, לא ביטוח

תג `iodef` מספק כתובת שאליה גופי הנפקה יכולים לשלוח דיווח כאשר הם מזהים בעיה במדיניות או בקשת הנפקה שנחסמה. אפשר להגדיר כתובת דוא"ל בפורמט `mailto:` או כתובת שירות בפורמט `https:`.

לדוגמה:

`example.co.il. CAA 0 iodef "mailto:[email protected]"`

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

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

כשלים נפוצים בניהול CAA

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

הכשל השני הוא התעלמות מ-Wildcard. ארגונים מגדירים `issue` אך לא `issuewild`, ואז מניחים שהמדיניות מכסה גם תעודות כלליות. הגדירו במפורש את המדיניות הרצויה ל-Wildcard, כולל איסור אם אין בו צורך.

הכשל השלישי הוא שינוי DNS ללא בקרת שינוי. רשומת CAA שנמחקה בפעולת bulk, הוחלפה בייבוא zone או נדרסה בהעברת ניהול יכולה לבטל שכבת הגנה בלי שאיש יבחין. ניהול דומיינים בקנה מידה דורש הרשאות לפי תפקיד, תיעוד שינויים ובדיקות תקופתיות - לא זיכרון של אדם אחד בצוות.

הכשל הרביעי הוא בלבול בין CAA ל-DNSSEC. DNSSEC מגן על שלמות התשובות ב-DNS ומקטין סיכוני זיוף בדרך. CAA מבטא מדיניות הנפקת תעודות. אלה מנגנונים משלימים, לא חלופות. גם נעילת דומיין, הגנת WHOIS, אימות רב-שלבי והפרדת הרשאות מטפלים בשכבות אחרות של אותו סיכון.

מדיניות שחיה עם הפורטפוליו

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

קבעו בדיקה תקופתית למדיניות: האם כל גוף שמופיע ב-CAA עדיין נדרש, האם יש תעודות Wildcard שלא אמורות להתקיים, האם כתובת ה-`iodef` פעילה, והאם תהליכי החידוש האוטומטיים נבדקו מאז שינויי תשתית. במדיניות אבטחה טובה, הרשאה אינה נשארת לנצח רק מפני שפעם היה בה צורך.

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