יש אירועי סייבר שלא מתחילים במייל חשוד, לא בקובץ נגוע ולא בפריצה דרמטית לשרת. הם מתחילים בשורה אחת שנשארה במקום הלא נכון: מפתח API, טוקן, סוד גישה, Client Secret או מחרוזת התחברות למסד נתונים. מבחינת התוקף זו לא שורה טכנית. זה מפתח עסקי. לפעמים הוא פותח גישה למערכת דיוור, לפעמים לענן, לפעמים לכלי AI, לפעמים לסליקה, ולפעמים למאגר לקוחות שלם.
למה דווקא עכשיו זה נהיה מסוכן יותר
פעם היו מעט מערכות, מעט אינטגרציות ומעט מפתחות. היום כל עסק מפעיל ענן, כלי שיווק, מערכות CRM, סליקה, אוטומציות, שירותי AI, ממשקי וובהוק, סקריפטים, דוחות, סביבת בדיקות וחיבורי ספקים. כל חיבור כזה מייצר עוד סוד גישה. ככל שיש יותר סודות, כך קשה יותר לדעת מי יצר אותם, איפה הם נשמרים, מה הם פותחים ומי עדיין צריך אותם.
הנתונים בשטח לא משאירים הרבה מקום לאופטימיות. בדוח State of Secrets Sprawl 2026 של GitGuardian דווח על 29 מיליון סודות חדשים שזוהו ב GitHub בשנת 2025, צמיחה של 152 אחוז מאז 2021. אותו דוח מצביע גם על כך שמאגרים פנימיים נוטים להכיל סודות קשיחים בשיעור גבוה פי שישה ממאגרים ציבוריים, ושכמעט 28 אחוז מאירועי דלף הסודות מתרחשים בכלל מחוץ לקוד, בכלי עבודה כמו מסמכים, צ׳אטים ומערכות ניהול משימות.
זה הנתון שצריך להעיר הנהלות: דלף מפתחות API הוא כבר לא רק בעיה של Git. הוא בעיה של עבודה יומיומית. עובד שולח קובץ הגדרות בקבוצת תמיכה, ספק מבקש גישה זמנית ונשאר עם טוקן קבוע, מפתח מדביק מחרוזת בסביבת AI כדי לפתור באג, או מערכת לוגים שומרת כתובת בקשה עם מפתח בתוך הפרמטרים. אין כאן בהכרח כוונה רעה. יש כאן תהליך לא מנוהל.
מפתח API דולף לא מתנהג כמו סיסמה דולפת
כשסיסמה של עובד דולפת, יש סיכוי שתראו כניסה חריגה, דרישת אימות נוסף או התראה ממערכת הזהויות. במפתחות API הסיפור שונה. הרבה מפתחות הם Bearer Credentials. מי שמחזיק אותם, משתמש בהם. לא תמיד יש אימות נוסף. לא תמיד יש שם משתמש אנושי. לא תמיד יש הקשר עסקי שמסביר למה בוצעה פעולה בשעה שלוש בלילה.
Google Cloud מסבירה ב הנחיות הרשמיות לניהול API Keys שמפתחות שנחשפים עלולים לגרום להוצאות בלתי צפויות או לגישה לא מורשית לנתונים, וממליצה להגביל מפתחות לפי שימוש, לא לשמור אותם בקוד לקוח, למחוק מפתחות שאינם בשימוש ולבצע רוטציה תקופתית. זו לא המלצה תיאורטית. זה ההבדל בין חשיפה מוגבלת לבין מפתח חופשי שמאפשר לתוקף לרוץ.
כך נראית שרשרת תקיפה אמיתית
דמיינו סקריפט קטן שמייצא לידים מהאתר למערכת CRM. המפתח שלו נשמר בקובץ הגדרות. יום אחד הקובץ עולה בטעות למאגר קוד, נשלח לספק או נשאר בתיקיית גיבוי שנפתחה לשיתוף. תוקף שמוצא את המפתח לא צריך לדעת את סיסמת המנכ״ל. הוא בודק מה המפתח מאפשר. אולי קריאת לידים בלבד. אולי גם עדכון רשומות. אולי יצירת משתמשים. אולי גישה לאוטומציות שמפעילות קמפיינים. משם הדרך לדלף מידע, הונאה עסקית או חבלה תפעולית קצרה מאוד.
במקרים אחרים המפתח שייך לשירות AI או ענן. אז התוקף לא תמיד מחפש מידע. לפעמים הוא שורף לכם תקציב, מריץ שאילתות, משתמש בתשתית שלכם כדי לבצע פעולות יקרות, או מנצל את המוניטין של הארגון לצורכי תקיפה. לכן מדד הסיכון הוא לא רק איזה מידע נפתח, אלא גם אילו פעולות אפשר לבצע, באיזה נפח, ובשם מי.
איפה מפתחות API דולפים בפועל
אנחנו רואים שוב ושוב את אותם נתיבים. הם לא נוצצים, אבל הם מסוכנים:
- קוד ומאגרים: קובצי הגדרות, דוגמאות, סקריפטים ישנים וסביבות בדיקה שמועלים למאגר בלי סינון.
- כלי שיתוף פנימיים: צ׳אטים, כרטיסי תמיכה, מסמכי תפעול, תיעוד ספקים ומערכות ניהול משימות.
- לוגים וכתובות בקשה: מפתח שמועבר בפרמטר של כתובת עלול להישמר בלוגים, בדפדפן, במערכת ניטור או אצל צד שלישי.
- קוד לקוח: אפליקציות ואתרים שמכילים מפתח בצד המשתמש חושפים אותו לכל מי שיודע לפתוח כלי פיתוח בדפדפן.
- ספקים ואוטומציות: אינטגרציה שנוצרה לפרויקט זמני נשארת פעילה חודשים אחרי שהפרויקט נגמר.
- כלי AI: הדבקת קובץ סביבה, קטע קוד או לוג לשירות לא מאושר יכולה להפוך סוד גישה לנתון שיצא משליטת הארגון.
מי שרוצה להבין את הסיכון הרחב יותר של עבודה בדפדפן ובכלי ענן יכול להמשיך לקרוא אצלנו את המאמר אבטחת דפדפן: ההאקרים כבר עובדים בטאב שלכם. זה אותו עיקרון: כשהעבודה עברה לענן, גם הסודות עברו לשם.
הטעות הכי נפוצה: סריקה בלי בעלים
הרבה ארגונים מתקינים כלי סריקת סודות ומרגישים שהם פתרו את הבעיה. זו התחלה טובה, אבל היא לא פתרון. אם כלי מוצא 400 ממצאים ואף אחד לא יודע איזה מהם פותח מערכת קריטית, מי אחראי עליו ומה יישבר אם נחליף אותו, הארגון לא מנהל סיכון. הוא מנהל רשימה.
GitHub Secret Scanning מדגיש שכאשר מזוהה דלף Credential צריך לבצע רוטציה מיידית למפתח שנחשף. אבל כדי לעשות רוטציה מיידית, צריך לדעת מראש מי הבעלים של המפתח, איפה הוא מותקן, אילו מערכות תלויות בו, ומה סדר הפעולות כדי להחליף אותו בלי להפיל שירות חי.
כאן נכנס החלק שרוב הארגונים מדלגים עליו: מיפוי. לא מיפוי תיאורטי של שרתים, אלא מיפוי אמיתי של סודות, זהויות מכונה, חיבורי SaaS ואינטגרציות. זו בדיוק הסיבה שאנחנו מתייחסים ל מיפוי נכסים דיגיטליים כנקודת פתיחה לסייבר רציני, ולא כתרגיל תיעוד.
המודל הנכון: פחות סודות, פחות הרשאות, יותר נראות
ניהול מפתחות API צריך להישען על שלושה עקרונות פשוטים ולא מתפשרים.
1. כל סוד חייב בעלים ותכלית
מפתח בלי בעלים הוא מפתח שאף אחד לא יעז לכבות. לכל מפתח צריך להיות שם ברור, מערכת יעד, סביבת שימוש, בעלים עסקי, בעלים טכני, תאריך יצירה, תאריך סקירה ותיעוד של הרשאות. אם אי אפשר להסביר למה המפתח קיים, הוא צריך להיכנס למסלול ביטול.
2. הרשאות מינימום הן לא המלצה, הן ביטוח
מפתח של מערכת דיוור לא צריך גישה לכל הלקוחות אם הוא שולח רק סטטוס הרשמה. מפתח של כלי BI לא צריך כתיבה אם הוא רק קורא דוחות. מפתח של סביבת בדיקות לא צריך גישה לנתוני אמת. ככל שהמפתח מצומצם יותר, כך גם הנזק במקרה דלף קטן יותר.
3. סוד שלא מנוטר הוא סוד עיוור
שימוש במפתח צריך לייצר עקבות. עליה פתאומית בנפח קריאות, שימוש ממדינה לא צפויה, פנייה לנקודות קצה שלא היו בשימוש בעבר, כישלונות מרובים ואז הצלחה, או שימוש במפתח ישן אחרי רוטציה, כולם סימנים שדורשים בדיקה. כאן שירות SIEM SOC נותן ערך אמיתי, כי הוא מחבר בין לוגים, הקשר ותחקור אנושי.
מה עושים בפועל בשבוע הראשון
לא צריך לחכות לפרויקט ענק כדי להקטין סיכון. כך מתחילים נכון:
- מוציאים רשימת מפתחות: ענן, מערכות SaaS, כלי AI, Git, מערכות דיוור, סליקה, CRM, וובהוקים וכלי אוטומציה.
- מסמנים סודות קריטיים: כל מפתח שיש לו גישה לנתוני לקוחות, כסף, תשתית, קוד מקור או יכולת שליחת הודעות בשם הארגון.
- מזהים מפתחות ללא בעלים: אלה המפתחות שהכי מסוכנים, כי אף אחד לא מרגיש אחראי עליהם.
- מפעילים סריקת סודות: במאגרים, בקבצי תצורה, במסמכי תפעול ובכלי שיתוף מרכזיים.
- מגבילים שימוש: לפי כתובות, שירותים, הרשאות, סביבה ונפח פעולה, בהתאם ליכולות הספק.
- מגדירים רוטציה: לא רק לגלות סוד שדלף, אלא לדעת להחליף אותו מהר בלי לשבור תהליך עסקי.
- מחברים לוגים: כל שימוש חריג במפתח קריטי צריך להגיע לניטור ולתגובה, לא להישאר במסך של ספק ענן.
בארגונים שאין להם תמונת מצב, נקודת ההתחלה הנכונה היא סקר סיכונים. בסקר כזה לא מחפשים רק חולשות בשרתים. מחפשים גם תהליכים שמייצרים סיכון: מפתחות ישנים, הרשאות רחבות מדי, שיתופים פתוחים, ספקים עם גישה נשכחת והיעדר ניטור.
מתי DLP רלוונטי למפתחות API
DLP לא נועד רק לעצור קובץ לקוחות. הוא יכול לעזור לזהות יציאה של מידע רגיש גם כשהמידע הוא טכני: מחרוזות התחברות, טוקנים, קובצי הגדרות, קבצי סביבה ומפתחות גישה. אם עובד שולח קובץ כזה החוצה, מעלה אותו לשירות לא מאושר או מדביק אותו במקום לא נכון, זו דליפה לכל דבר.
כתבנו על זה בהרחבה במאמר מניעת דלף מידע DLP היא לא בונוס. בהקשר של מפתחות API, שכבת מניעת דלף מידע צריכה לזהות דפוסים של סודות, לחסום שיתוף לא מאושר ולהפעיל תהליך אישור במקום לאפשר זליגה שקטה.
מה עושים כשמפתח כבר דלף
ברגע שיש חשד שדלף מפתח, לא מתחילים בדיון ארוך. עובדים לפי תרחיש תגובה מסודר:
- מזהים את המפתח, המערכת וההרשאות שהוא מחזיק.
- יוצרים מפתח חדש עם הרשאות מצומצמות יותר, אם אפשר.
- מעדכנים את המערכת שמשתמשת במפתח החדש ובודקים שהיא יציבה.
- מבטלים את המפתח הישן ולא מסתפקים במחיקתו מהקוד.
- בודקים לוגים לאחור כדי להבין האם נעשה שימוש חריג.
- מחליפים סודות קשורים, במיוחד אם אותו מפתח נשמר יחד עם סודות נוספים.
- מתעדים את האירוע ומתקנים את הסיבה שגרמה לדלף.
השלב האחרון הוא החשוב ביותר. אם רק החלפתם מפתח ולא תיקנתם את התהליך שחשף אותו, האירוע הבא כבר בדרך.
הנקודה שחשוב שהנהלה תבין
מפתחות API הם לא בעיה של מפתחים. הם נכס זהות עסקי. הם נותנים גישה למידע, כסף, תשתיות, לקוחות ומוניטין. לכן ניהול שלהם צריך להיכנס לשיח של סיכונים, לא להישאר בתוך ערוץ טכני.
OWASP ממליצה ב Secrets Management Cheat Sheet לרכז, לתעד, לאכוף הרשאות מינימום, לבצע אוטומציה לרוטציה ולהפעיל ניטור. גם רשימת OWASP API Security Top 10 מציבה ניהול מלאי לקוי, תצורה שגויה ואימות שבור כסיכונים מרכזיים בעולם ה API. מחקר עדכני בשם Keys on Doormats אף מצא חשיפות מפתחות API באתרים חיים, כולל מקורות שמגיעים מסביבות JavaScript ומקבצי בנייה.
בעברית פשוטה: מי שלא יודע אילו מפתחות קיימים אצלו, לא באמת יודע מי יכול לפעול בשם הארגון.
איפה 010 נכנסת לתמונה
ב 010 אנחנו לא מסתכלים על מפתחות API כעל סעיף קטן בצ׳ק ליסט. אנחנו מסתכלים עליהם כחלק ממשטח התקיפה המלא של הארגון. לכן העבודה הנכונה משלבת מעטפת הגנת סייבר, מיפוי נכסים, סקר סיכונים, מניעת דלף מידע, מודיעין סייבר וניטור SIEM SOC. כל שכבה עונה על שאלה אחרת: מה קיים, מה מסוכן, מה דולף, מה כבר נחשף, ומה קורה עכשיו.
שירות מודיעין סייבר חשוב במיוחד כאשר קיים חשש שסודות או זהויות כבר מסתובבים ברשת. הוא לא מחליף ניהול סודות, אבל הוא מקצר את הזמן בין חשיפה לבין תגובה. בסייבר, הזמן הזה שווה כסף.
השורה התחתונה
מפתח API שלא מנוהל הוא דלת פתוחה עם שלט קטן שאף אחד לא קורא. הוא לא עושה רעש, לא נראה כמו וירוס, ולא תמיד מפעיל אזעקה. אבל ברגע שתוקף מוצא אותו, הוא יכול להפוך לכלי פעולה שקט ויעיל נגדכם.
הפעולה הנכונה השבוע היא לא לקנות עוד מערכת. הפעולה הנכונה היא להתחיל לשאול שאלות קשות: כמה מפתחות יש לנו, מי מחזיק בהם, מה הם פותחים, מתי הם הוחלפו לאחרונה, ואיזה לוג יספר לנו אם מישהו משתמש בהם לרעה. אם אין תשובה ברורה, זה לא פער תיעוד. זה סיכון פעיל
