מפתח API בקבוצת WhatsApp: כך מונעים מכלי AI לקבל גישה קבועה לעסק

עסק מחבר כלי AI למערכת ה-CRM, למייל או למסמכים בענן. המפתח נשלח למפתח ב-WhatsApp, מועתק לקובץ הגדרות ונשמר גם בצ׳אט עם כלי AI כדי "לפתור רגע תקלה". האוטומציה עובדת, כולם מרוצים — והמפתח נשאר שם הרבה אחרי שהרגע חלף.

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

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

הבעיה אינה רק גניבת מפתח

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

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

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

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

מתחילים במיפוי קצר, לא ברכישת מערכת

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

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

אין צורך לרשום את המפתח עצמו בגיליון. מטרת הרשימה היא לתעד את קיומו ואת האחריות עליו, לא להקים כספת סודות חדשה בשם "API-Keys-Final-v7.xlsx".

אם קיימים גם כלים שפותחו בתוך העסק, מומלץ לקרוא את המדריך על בדיקת כלי AI פנימיים וחיבורי API ולחבר את המיפוי לבדיקת ההרשאות הכוללת.

ארבעה כללים שמצמצמים את שטח החשיפה

1. לא מדביקים סודות בצ׳אט או בפרומפט

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

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

2. מפתח נפרד לכל מערכת וסביבה

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

כדאי להפריד לפחות בין:

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

3. נותנים רק את ההרשאה הנדרשת

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

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

4. מתכננים החלפה לפני שיש תקלה

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

החלפה נדרשת במיוחד כאשר:

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

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

מה עושים אם מפתח כבר נחשף?

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

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

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

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

שאלות נפוצות על מפתחות API וכלי AI

האם מפתח API הוא פשוט סיסמה ארוכה?

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

האם עסק קטן חייב כספת סודות ייעודית?

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

כל כמה זמן צריך להחליף מפתחות API?

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

איך יודעים אם כלי AI מבקש הרשאות רחבות מדי?

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

הצעד הבא: להפוך סודות לנכסים מנוהלים

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

נשמע שזה משהו שגל יכול לעזור בו. אפשר לתאם שיחת ייעוץ חינם לבדיקת חיבורי AI, הרשאות ומפתחות API בטלפון 0542395928 או במייל limicompute@gmail.com. לאחר בדיקה קצרה יהיה אפשר להבין אילו חיבורים דורשים טיפול מיידי ואילו יכולים להיכנס לתהליך מסודר בהמשך.