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

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

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

מתחילים ממיפוי, לא מהעברה עיוורת

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

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

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

הפרידו בין בעלות של הלקוח לבין הרשאות של הצוות

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

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

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

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

DNS צריך להיות מתועד כמו קוד תשתית

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

לכל אזור DNS חשוב להחזיק תיעוד קצר וברור: מהי מטרת כל רשומה קריטית, איזה שירות מנהל אותה, מי אחראי עליה, ומהו שינוי בטוח לעומת שינוי שמחייב בדיקה. רשומות MX, SPF, DKIM, DMARC, CAA, רשומות אימות ורשומות API אינן "טקסט טכני" שאפשר להעתיק בלי הקשר. שינוי לא מדויק באחת מהן עלול לפגוע במשלוח דוא"ל, בהתחברות לשירותים או באבטחת המותג.

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

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

קבעו מדיניות לשינויים קריטיים

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

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

חידושים הם תהליך, לא תזכורת ביומן

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

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

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

נקו כפילויות והפכו הפניות לחלק מהניהול

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

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

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

אבטחה: חסמו את מסלול התקיפה הפשוט

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

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

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

איך לסדר תיק דומיינים של לקוחות בקנה מידה

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

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

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

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