איך מבטיחים שהדומיין, הדוא״ל וחשבונות הניהול שייכים לעמותה ולא לעובד או ספק?

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

התשובה הקצרה

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

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

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

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

ארבעה דברים שונים שאסור לערבב

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

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

הדומיין חייב להיות רשום נכון

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

בדקו בממשק הרשם ובמסמכי הרישום:

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

בדומיינים שאינם ‎.il, ICANN מגדירה את ה־registrant כאדם או ישות שמתקשרים עם הרשם ומנהלים את שם המתחם. לכן גם שם בודקים שהעמותה היא המחזיקה ולא רק “איש הקשר הטכני”.

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

אילו נכסים חייבים להיכנס למלאי

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

| שכבה | דוגמאות | הראיה שהעמותה שולטת | |---|---|---| | מרשם ודומיין | רשם, שם מחזיק, חידוש, קוד העברה | מסך מחזיק, חשבונית וגישה עצמאית | | DNS ואבטחת קצה | DNS, CDN, WAF, תעודות TLS | הרשאת מנהל, ייצוא zone והתראות | | דואר וזהות | Google Workspace, Microsoft 365, SSO | tenant ארגוני ושני מנהלי־על | | אתר ואחסון | שרת, CMS, בסיס נתונים, גיבויים | חשבון לקוח, ייצוא וגיבוי שחזור | | פיתוח | מאגר קוד, CI/CD, מפתחות פריסה | organization ארגוני ומנהלים | | שירותים עסקיים | סליקה, CRM, דיוור, תרומות | בעל חשבון, הסכם וייצוא מידע | | נוכחות ציבורית | רשתות חברתיות, מפות, פרסום, אנליטיקה | מנהלים מטעם העמותה והיסטוריית גישה | | סודות ושחזור | סיסמאות, API keys, SSH, recovery codes | כספת ארגונית ונוהל גישה |

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

מבנה חשבונות והרשאות

בכל מערכת קריטית הגדירו:

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

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

חשבון חירום אינו סיסמה שמודבקת במגירה:

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

אבטחת חשבונות הבעלות

חשבונות הרשם, הדואר והזהות הם “מפתחות־על”: מי ששולט בדוא״ל יכול לאפס שירותים אחרים, ומי ששולט ב־DNS יכול להפנות אתר או דואר. לכן:

1. מפעילים MFA בכל חשבון מנהל.
2. בחשבונות הקריטיים מעדיפים אמצעי עמיד לדיוג, כגון FIDO/WebAuthn, אם השירות תומך.
3. משתמשים במנהל סיסמאות ארגוני ובסיסמה ייחודית לכל שירות.
4. מבטלים שיטות שחזור ישנות, מספרי טלפון וכתובות של מי שעזב.
5. מגבילים אפליקציות OAuth, מפתחות API, מפתחות SSH וסיסמאות אפליקציה.
6. מפעילים נעילת העברת דומיין והתראות שינוי, אם הרשם מציע אותן.
7. מפעילים DNSSEC רק עם ספק שיודע לנהל אותו נכון ולתכנן החלפה; תצורה שגויה עלולה להשבית פתרון DNS.

CISA מגדירה FIDO/WebAuthn כאפשרות MFA נפוצה שעמידה לדיוג וממליצה לארגונים לתכנן מעבר אליה. איגוד האינטרנט מסביר ש־DNSSEC מאמת שהמענה הגיע מהמקור הנכון ולא שונה בדרך, אך גם מפרט שהחלפת מפתחות דורשת סדר פעולות נכון.

מה חייב להיות בחוזה עם עובד או ספק

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

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

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

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

מבחן השליטה: לא מסתפקים בצילום מסך

לפחות שני נציגים מטעם העמותה מבצעים יחד תרגיל מבוקר:

1. נכנסים לחשבון הרשם ורואים את שם המחזיק ואת מועד החידוש.
2. מפיקים או מאמתים את תהליך קבלת קוד ההעברה בלי להעביר בפועל.
3. נכנסים ל־DNS ומייצאים את כל הרשומות.
4. מוסיפים רשומת TXT זמנית ומסירים אותה לאחר אימות.
5. מנהל אחד מוסיף ומסיר משתמש בדיקה בהרשאות מצומצמות.
6. מורידים גיבוי אתר ומבצעים שחזור בסביבה נפרדת.
7. מייצאים רשימת משתמשים, תפקידים, אפליקציות ומפתחות פעילים.
8. בודקים שהתראת שינוי מגיעה לשני גורמים ארגוניים.
9. בודקים נתיב חירום כאשר הדואר הרגיל אינו זמין.
10. מתעדים תוצאה, פער, אחראי ומועד תיקון.

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

נוהל עזיבת עובד או החלפת ספק

מכינים את הנוהל מראש, לא ביום של סכסוך:

לפני מועד הסיום

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

במועד הסיום

• משביתים את חשבון האדם ולא משתלטים על זהותו האישית.
• מבטלים sessions, tokens, OAuth, API keys, SSH keys וסיסמאות אפליקציה.
• מסירים הרשאות ברשם, DNS, דואר, ענן, קוד, סליקה, CRM ורשתות.
• מחליפים סודות משותפים שאי אפשר לדעת אם הועתקו.
• משמרים יומנים וראיות בלי למחוק פעילות שצריך לחקור.

אחרי הסיום

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

מה עושים אם הספק כבר מחזיק בשליטה

פעלו בלי להסלים סיכון:

1. אספו חוזים, חשבוניות, התכתבויות, פרטי מרשם והוכחות לתשלום ולשימוש.
2. גיבו כל מידע שנגיש לעמותה ושמרו יומנים.
3. מיפו מה הספק יכול להשבית ומה תלוי בדומיין או בדוא״ל.
4. פנו בכתב וביקשו מסירה מסודרת לפי רשימת נכסים ומועד.
5. פתחו חשבונות ארגוניים חלופיים לפני ביטול גישה קיימת.
6. עבדו מול הרשם או ספק השירות בתהליך אימות הבעלות שלו.
7. במקרה של מחלוקת על זכויות, חוב, קוד או שם מתחם — קבלו ייעוץ משפטי לפני שינוי חד־צדדי.
8. אם יש חשד להשתלטות או אירוע סייבר, שמרו ראיות והפעילו נוהל אירוע; אין לבצע “פריצה חזרה”.

רשימת בדיקה לוועד

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

גבולות התשובה

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