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

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

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

איך להגן על חשבון רשם: מתחילים בזהות

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

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

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

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

לא כל משתמש צריך לנהל את כל הפורטפוליו

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

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

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

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

נעילת דומיין אינה מגינה על DNS

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

אבל חשוב להבין את הגבול שלה: נעילת דומיין אינה מונעת בהכרח שינוי של רשומות DNS, כתובות אנשי קשר או הגדרות הפניה בתוך החשבון. תוקף עם גישה מלאה עדיין יכול לנסות להפנות את רשומת A, לשנות MX או להחליף Nameservers. לכן נעילה היא בלם להעברה, לא תחליף לבקרת גישה.

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

מגנים על שכבת ה-DNS ועל האוטומציה

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

לפני שינוי ברשומות MX, SPF, DKIM, DMARC, CNAME של שירותים חיצוניים או Nameservers, בצעו בדיקה כפולה של הערך וההשפעה. טעות בתו אחד יכולה לגרום לאובדן דואר, כשל באימות או ניתוב לא נכון. בהגדרות TTL, גם כאן יש תלות בהקשר: TTL נמוך מועיל בזמן מיגרציה או בדיקה, אך משאיר יותר תלות בשאילתות DNS. לאחר שהשינוי התייצב, החזירו אותו למדיניות התפעולית הרגילה שלכם.

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

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

ההתראות שצריכות להגיע לאדם הנכון

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

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

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

פרטיות WHOIS עוזרת, אבל לא מחליפה הגנה על החשבון

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

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

הכינו נוהל לאירוע לפני שתצטרכו אותו

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

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

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