התקיפה הבאה לא חייבת להתחיל בעובד שלחץ על קישור. היא יכולה להתחיל בחשבון שירות שפתחו לפני שנתיים בשביל אינטגרציה קטנה, בטוקן של מערכת אוטומציה, ביישום ענן שקיבל הרשאה לקרוא דואר, או בבוט שהמשיך לעבוד גם אחרי שהפרויקט נסגר. זה לא נשמע דרמטי, וזו בדיוק הבעיה. זהויות לא אנושיות לא מתלוננות, לא יוצאות לחופשה, לא מקבלות הדרכת מודעות, ולא תמיד מופיעות בדוח המשתמשים שההנהלה רואה.
מהי זהות לא אנושית ולמה היא שונה ממשתמש רגיל
זהות לא אנושית היא כל ישות דיגיטלית שמקבלת הרשאה לפעול בלי אדם שמקליד סיסמה באותו רגע. היא יכולה להיות חשבון שירות, Service Principal, יישום OAuth, מפתח API, טוקן גישה, בוט, זהות מנוהלת, תהליך אוטומציה או אינטגרציה מול ספק.
בתיעוד של Microsoft Entra Workload ID מוסבר ש Service Principal מגדיר מה יישום יכול לעשות בדייר מסוים, מי יכול לגשת אליו ולאילו משאבים הוא מגיע. זו לא הערת שוליים טכנית. זו הרשאה מעשית לבצע פעולות בשם הארגון.
אם לא מנהלים את מחזור החיים של הזהות, בסוף מישהו אחר ינהל אותה בשבילכם.
למה זה מסוכן יותר מסיסמה של עובד
משתמש אנושי משאיר סימנים ברורים יותר. הוא נכנס ממחשב, פותח דפדפן, עובר אימות, משנה מיקום, מקבל התראות, לפעמים אפילו מתקשר לתמיכה. זהות לא אנושית עובדת אחרת. היא רצה בשקט. היא מבצעת קריאות API. היא מעבירה נתונים. היא מתחברת בשעות מוזרות כי כך האוטומציה תוכננה. לכן גם חריגה יכולה להיראות כמו פעילות שגרתית.
הבעיה השנייה היא שהרבה זהויות לא אנושיות נוצרות עם הרשאות רחבות מדי. מפתח שנועד לקרוא סטטוס מקבל גם כתיבה. יישום שנועד לשלוח הודעות מקבל גישה לתיבות דואר. חשבון שירות שנועד לסביבת בדיקות נשאר עם גישה לנתוני אמת. כאשר ההרשאה רחבה והניטור חלש, לתוקף אין צורך לפרוץ בכוח. הוא פשוט משתמש במה שכבר קיבל אישור.
הבעיה השלישית היא שאין בעלים ברור. עובד עוזב ו HR יודע להפעיל תהליך עזיבה. אבל מי סוגר טוקן שנוצר עבור פרויקט שהוקפא? מי בודק הרשאה של אפליקציה שהותקנה לפני שמונה חודשים? מי מחליף סוד ששמור בתיעוד פנימי? מי מבטל גישה של ספק שכבר לא נותן שירות?
כתבנו על הסיכון של מפתחות וטוקנים במאמר המפתח שכבר דלף: למה API Keys מסכנים את העסק. אבל חשבונות שירות הם שכבה רחבה יותר: לא רק הסוד עצמו, אלא כל מחזור החיים סביבו.
הנתונים כבר צועקים, גם אם הארגון עדיין שקט
בדוח State of Secrets Sprawl 2026 של GitGuardian דווח על 28,649,024 סודות חדשים שנמצאו בקומיטים ציבוריים בשנת 2025. אותו דוח מצביע גם על עליה של 81 אחוז בחשיפות של סודות הקשורים לשירותי AI. זו לא רק בעיה של קוד. זו בעיה של קצב. כל כלי חדש, כל אוטומציה חדשה וכל ניסוי AI חדש מייצרים עוד מפתח, עוד טוקן ועוד הרשאה שצריך לנהל.
כאשר קצב החיבורים עולה מהר יותר מקצב הבקרה, נוצר שטח אפור. בתוך השטח הזה נמצאים קובצי הגדרות, סביבות בדיקה, כלי שיתוף, מערכות ניהול משימות, לוגים, עמדות פיתוח, צ׳אטים פנימיים ותיעוד ספקים. זה המקום שבו סודות דולפים לא בגלל האקר גאון, אלא בגלל תהליך לא סגור.
ההנחיות של Google Cloud לניהול API Keys מדגישות פעולות בסיסיות כמו הגבלת שימוש, מחיקת מפתחות שאינם נחוצים, הימנעות משמירת מפתחות בקוד לקוח, ניטור שימוש ורוטציה תקופתית. אלה לא המלצות נוחות. אלה תנאי בסיס לסיכון נשלט.
כך נראית תקיפה דרך זהות שנשכחה
נניח שספק הטמיע לפני שנה מערכת שמושכת נתונים ממערכת CRM אל כלי דיוור. לצורך ההטמעה נפתח חשבון שירות עם הרשאות קריאה וכתיבה. הספק סיים את הפרויקט, אבל החשבון נשאר פעיל. הסוד נשמר במסמך תפעול, הועתק לצ׳אט פנימי, ואחר כך הגיע לתיבה אישית של עובד. יום אחד התיבה נפרצת או המסמך נחשף. התוקף לא צריך סיסמת מנהל. הוא כבר מחזיק זהות שמוכרת למערכת.
הוא בודק מה אפשר לקרוא. אחר כך מה אפשר לשנות. אחר כך האם אפשר ליצור רשומות, להוציא רשימות לקוחות, להפעיל קמפיין, לשנות כתובות תשלום או להוסיף יעד חדש לסנכרון. אם אין ניטור שמחבר בין קריאות חריגות, נפח פעילות, שעות פעולה, מקור גישה והרשאות, האירוע יכול להימשך ימים בלי להיראות כמו אירוע.
בענן הארגוני זה אפילו שקט יותר. יישום שקיבל הרשאות לדואר, קבצים או משתמשים יכול להמשיך לפעול גם כאשר האדם שאישר אותו כבר לא זוכר שעשה זאת. מי שרוצה להבין את הצד האנושי של הרשאות ענן יכול להמשיך למאמר האורחים שלא יוצאים: הפריצה השקטה ב Microsoft 365. אותו עיקרון חל גם על אפליקציות, בוטים וזהויות מכונה.
חמש טעויות שמייצרות סיכון אמיתי
- אין מלאי: הארגון יודע כמה עובדים יש לו, אבל לא יודע כמה חשבונות שירות, יישומים, טוקנים ואוטומציות קיימים.
- אין בעלים: זהות קיימת, אבל אף מנהל עסקי ואף מנהל טכני לא אחראים להסביר למה היא קיימת.
- אין תוקף: גישה שנפתחה לפרויקט זמני הופכת להרשאה קבועה, כי אף אחד לא קבע תאריך בדיקה.
- אין הרשאות מינימום: הזהות מקבלת גישה רחבה כי זה מקצר הטמעה, ואז נשארת כך גם אחרי שהמערכת כבר יציבה.
- אין לוגים שימושיים: יש לוגים, אבל אין הקשר שמאפשר להבין האם הפעילות רגילה, חריגה או מסוכנת.
מה צריך לדרוש מכל זהות לא אנושית
הכלל שלנו פשוט: זהות בלי בעלים היא סיכון. זהות בלי תכלית היא סיכון. זהות בלי ניטור היא סיכון. אם אי אפשר להסביר למה היא קיימת, מה היא פותחת ומי רשאי לכבות אותה, היא לא אמורה לפעול.
הצ׳קליסט המעשי צריך לכלול לפחות את הסעיפים הבאים:
- שם ברור שמסביר את מטרת הזהות ולא רק מזהה טכני פנימי.
- בעלים עסקי ובעלים טכני.
- מערכת מקור ומערכת יעד.
- רשימת הרשאות מדויקת לפי קריאה, כתיבה, מחיקה וניהול.
- סביבת שימוש נפרדת לייצור, בדיקות ופיתוח.
- תאריך יצירה ותאריך סקירה הבא.
- תהליך רוטציה לסודות, כולל בדיקת יציבות לאחר החלפה.
- תהליך ביטול מיידי כאשר ספק, פרויקט או מערכת יוצאים משימוש.
- לוגים שמציגים מקור גישה, נפח פעולה, שעה, פעולה שבוצעה ותוצאה.
- התראה על שימוש ממקור חדש, פעולה לא צפויה או הרשאה שלא נוצלה זמן רב.
הסעיף האחרון חשוב במיוחד. הרשאה שלא נוצלה תשעה חודשים אינה הוכחה שהכול בסדר. לפעמים זו ההוכחה שאף אחד לא יעז לכבות אותה. וזה בדיוק סוג הזהויות שתוקפים אוהבים.
סריקה לבדה לא תציל אתכם
כלי סריקת סודות הם התחלה חשובה, אבל הם לא תחליף למשילות. מה עושים כאשר הסוד נמצא?
אם אין בעלים, אין סדר עדיפויות. אם אין מיפוי, אי אפשר לדעת מה יישבר. אם אין תהליך החלפה, כולם מפחדים לגעת. אם אין לוגים, אי אפשר לדעת האם כבר השתמשו בסוד לרעה. לכן סריקה בלי תהליך היא רק רשימת ממצאים. ארגון בוגר צריך להפוך כל ממצא לתהליך: זיהוי, הערכת נזק, החלפה, ביטול, בדיקת שימוש לאחור ותיקון שורש הבעיה.
איפה DLP נכנס לתמונה
הרבה מנהלים חושבים על DLP רק בהקשר של קובץ לקוחות או גיליון כספי. זו תפיסה צרה מדי. סוד גישה הוא מידע רגיש. טוקן, מפתח API, קובץ סביבה, מחרוזת התחברות או קובץ הגדרות יכולים לפתוח מערכות שלמות. אם הם נשלחים החוצה, מועלים לכלי לא מאושר או מודבקים בשירות AI ללא בקרה, זה אירוע דלף לכל דבר.
במאמר מניעת דלף מידע DLP היא לא בונוס הסברנו למה עצירת דלף לפני יציאה היא ההבדל בין אירוע קטן למשבר. בהקשר של זהויות לא אנושיות, מניעת דלף מידע צריכה לזהות לא רק מידע אישי, אלא גם דפוסים של סודות טכניים והרשאות גישה.
ניטור נכון לא מחפש רק רעש, אלא כוונה
זהות לא אנושית צריכה להשאיר עקבות. לא מספיק לדעת שהתקיימה קריאה למערכת. צריך להבין האם הקריאה צפויה. האם היא הגיעה מהמקור הרגיל. האם נפח הפעולות השתנה. האם הזהות נגעה במידע שלא נגעה בו בעבר. האם היא ניסתה פעולה שנכשלה ואז הצליחה. האם היא הופעלה אחרי תקופה ארוכה של שתיקה.
כאן SIEM SOC מקבל משמעות אמיתית. לא עוד מאגר לוגים שמישהו אולי יפתח ביום רע, אלא שכבת ניטור, הקשר ותגובה. המטרה היא לא לאסוף הכול כדי לסמן וי. המטרה היא לגלות שינוי התנהגותי בזמן שבו עדיין אפשר לעצור את האירוע.
מודיעין חיצוני משלים את התמונה. אם סוד, טוקן או פרטי זהות כבר מסתובבים ברשת, הארגון חייב לדעת על כך לפני שהתוקף משתמש בהם. שירות מודיעין סייבר עוזר לזהות חשיפות כאלה ולהפוך אותן לפעולת תגובה, לא להפתעה בדיעבד.
הנקודה שהנהלה חייבת להבין
זהויות לא אנושיות הן לא נושא שצריך להישאר בין איש התשתיות למפתח. הן מאפשרות גישה למידע, כסף, לקוחות, קוד, דואר, מערכות ענן ותהליכים עסקיים. לכן הן חייבות להיכנס לשיח הנהלה כחלק מניהול סיכונים.
השאלה אינה האם יש לכם חשבונות שירות. ברור שיש. השאלה היא האם אתם יודעים לענות על חמש שאלות פשוטות:
- כמה זהויות לא אנושיות פעילות קיימות בארגון?
- למי הן שייכות?
- מה הן מסוגלות לעשות?
- מתי הן נבדקו בפעם האחרונה?
- איך תדעו אם מישהו משתמש בהן לרעה?
אם אין תשובה, זו לא בעיית תיעוד. זה סיכון פעיל.
איפה אנחנו נכנסים לתמונה
ב 010 אנחנו מסתכלים על זהויות לא אנושיות כחלק ממשטח התקיפה הכולל של הארגון. לכן נקודת פתיחה נכונה היא סקר סיכונים שממפה לא רק שרתים ועמדות, אלא גם תהליכים, אינטגרציות, הרשאות, חיבורים לספקים, זהויות ענן וסודות שמסתובבים במקומות הלא נכונים.
אחרי שמבינים מה קיים, צריך לצמצם. פחות הרשאות. פחות סודות קבועים. פחות זהויות ללא בעלים. יותר הפרדה בין סביבות. יותר רוטציה. יותר ניטור. וכאשר קיימת חשיפה, צריך תגובה מהירה שמחברת DLP, מודיעין סייבר, SIEM SOC ותהליך ניהולי ברור.
זה לא פרויקט קוסמטי. זו משמעת. ארגונים שנופלים בנושא הזה לא נופלים כי לא הייתה להם עוד מערכת אבטחה אחת. הם נופלים כי אף אחד לא ידע מי פועל בשם הארגון.
השורה התחתונה
הזהויות המסוכנות ביותר בארגון הן לפעמים אלה שלא מופיעות באף רשימת עובדים. הן לא מבקשות העלאה, לא עוזבות את החברה, ולא שוכחות סיסמה. הן פשוט ממשיכות לפעול. שנה אחרי שנה. הרשאה אחרי הרשאה.
הפעולה הנכונה השבוע היא לא להקים ועדה. היא להתחיל ממיפוי. להוציא רשימת חשבונות שירות, יישומים, מפתחות, טוקנים ואוטומציות. לסמן מי הבעלים. לצמצם הרשאות. לבטל את מה שלא צריך. להגדיר רוטציה. לחבר לוגים. ולשאול שאלה אחת חדה: האם היינו שמים את אותה הרשאה גם בידי עובד חדש ביום הראשון שלו?
אם התשובה היא לא, גם זהות לא אנושית לא אמורה לקבל אותה.
