Michael Johnsonבדיקה פנימית של OpenRouter גילתה יותר מ-1,000 מפתחות API פעילים בקרב 85 עובדים; לפי החברה, 168 מפתחות לא היו בשימוש במשך חודשים. אלה נתונים מבדיקה עצמית של OpenRouter, ולא מחקר ענפי עצמאי. אבל גם כדוגמה נקודתית הם ממחישים מלכודת הנדסית מוכרת: אפשר לשכוח מפתח, אבל לא את היישום שתלוי בו. החברה תיארכה את ההכרזה על Security Center ל-28 בספטמבר 2026.
הבעיה אינה מסתכמת באיתור פרטי הגישה הישנים ביותר ומחיקתם. הצוות צריך לזהות את הבעלים, לברר היכן משתמשים במפתח ולהבין איך להחליף אותו בלי להשבית משימה נדירה או שירות שנשכח. בלי המידע הזה, ביטול הגישה הופך מניקיון לניסוי מסוכן.
מה מופיע ב-Security Center — ומה זה לא מוכיח
לפי התיאור של OpenRouter, מרכז האבטחה מאגד את המפתחות בחשבון ומציג את הבעלים, מועד השימוש האחרון, תקרת ההוצאות ותאריך התפוגה; מנהלי הארגון רואים את כל המפתחות, ואילו חברי הארגון רואים את המפתחות שיצרו. אפשר לבחור עד 500 מפתחות לפעולות מרובות: להשבית, להעביר לארכיון או להגדיר תקרת הוצאות. השבתה הפיכה, ואילו העברה לארכיון אינה הפיכה. אלה מאפייני הכלי כפי שהספק עצמו מתאר אותם, ולא הערכה עצמאית של יעילותו.
חשוב במיוחד להתייחס לסטטוס «אפשר למחוק» כרמז לבדיקה, ולא כהוכחה שאין תלויות. מדד השימוש מראה בקשות מהעבר, אך לא בהכרח מסביר לאיזו משימת cron, תרחיש חירום או תהליך עונתי שייך המפתח. OpenRouter עצמה ממליצה לוודא את המחיקה מול הבעלים; גם התיעוד להגדרות אבטחה מזהיר שיש לבדוק תלויות לפני השבתה או העברה לארכיון.
להגבלות רשת יש הסתייגות נפרדת: רשימת הכתובות המותרות (IP allowlist) זמינה למנהלי מערכת בתוכנית Enterprise וחלה על כל מפתחות הארגון. בקשות מכתובות שאינן ברשימה נדחות בשגיאת 403, והשינויים נכנסים לתוקף מיד. לכן לפני הפעלת ההגבלה צריך להביא בחשבון את כתובות שרתי הייצור, רשת המשרד וסוכני CI; אחרת אמצעי ההגנה עצמו עלול להפסיק קריאות לגיטימיות.
סדר ניקוי: קודם הבעלים, אחר כך הביטול
- בנו מצאי. תעדו לכל מפתח את הבעלים, המטרה, הסביבה, הצרכנים, תקרת ההוצאות ותאריך התפוגה. אם המערכת מציגה את הבעלים רק כאדם, הקצו גם צוות או שירות שיקבלו אחריות במקרה שהוא יעזוב.
- בדקו שימוש ותלויות. השוו את מועד הבקשה האחרונה ללוחות זמנים של משימות רקע, תרחישי גיבוי, צינורות הפצה ואינטגרציות חיצוניות. היעדר פעילות לאחרונה הוא סיבה לשאול את הבעלים, ולא בסיס מספיק למחיקה מיידית.
- צמצמו את הסיכון לפני ההעברה. במקומות שבהם הדבר נתמך, הגדירו תקרת הוצאות סבירה ותאריך תפוגה. בדקו את עקרון ההרשאות המזעריות ואת כללי אחסון הסודות: מדריך OWASP לניהול סודות מתייחס לרישום, לגישה ולמחזור החיים של פרטי גישה כחלקים נפרדים בתהליך.
- צרו תחליף והעבירו אליו את הצרכנים. עדכנו את הסוד במאגר או בתצורת הפריסה, ואז העבירו את היישומים בהדרגה. אל תכניסו את ערך המפתח לכרטיסי משימה, ליומנים או לקוד המקור.
- בדקו את סביבת הייצור לפני הביטול. ודאו שהמפתח החדש פועל בכל הצרכנים הידועים, כולל CI ומשימות נדירות. לאחר מכן השביתו תחילה את המפתח הישן, אם יש פעולה הפיכה זמינה; העבירו אותו לארכיון או מחקו אותו רק לאחר אישור ההעברה ותקופת ניטור שנקבעה.
הרצף «יצירת מפתח חדש ← העברת היישומים ← בדיקת הפעולה ← מחיקת המפתח הישן» תואם להנחיות הרוטציה של OpenRouter. זהו סדר הפעולות המומלץ, ולא ערובה לכך שלא תהיה השבתה: התוצאה תלויה בשאלה אם איתרתם את כל המערכות שמשתמשות בפרטי הגישה.
מפתחות שירות אינם כל הסודות של הארגון
לוח הבקרה של ספק מסוים מסייע לנהל את המפתחות של אותו שירות, אך כשלעצמו אינו מרכז סודות מענן, ממסדי נתונים, מ-CI/CD ומממשקי API אחרים. ההמלצה הכללית של OWASP למחזור חיי הסודות כוללת אחסון מרכזי, בקרת גישה, ביקורת, רוטציה וביטול. בנפרד, ההמלצות של Google Cloud מציעות להגביל את היקף השימוש במפתחות, להסיר פרטי גישה מיותרים ולעקוב אחר השימוש.
OpenRouter גם טוענת ש-Security Center משתמש במטא-נתונים של מפתחות, בהוצאות ובתאריכי תפוגה, ולא קורא את ההנחיות והתשובות. זו הצהרה של הספק עצמו; במקורות שנבדקו לא נמצאה בדיקה טכנית עצמאית. ובאופן כללי, עצם קיומו של לוח בקרה אינו מוכיח שהצוות כבר צמצם את מספר התקריות או את ההוצאות: בחומרים שנבדקו לא נמצאו תוצאות פומביות לאחר ההשקה.