Skip to content
עברית

פעילות מפתחות ספק ב־Cloudflare: בדקו תלויות לפני ניקוי

לפי הודעת Cloudflare מ־6 בנובמבר, AI Gateway מציג פעילות של מפתחות ספק שמורים: קיבוץ לפי ספק, תצוגה מוסווית, כינויים ותאריכי שימוש ועדכון אחרונים. אזור Key security מדגיש פעילות מתועדת מלפני יותר מ־90 יום. המעקב מתחיל בנובמבר 2026.

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

מנגנונים קיימים שמשפיעים על הבדיקה

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

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

אימות מול השער נשאר נושא נפרד: Cloudflare מתעדת את cf-aig-authorization לנקודות הקצה הייעודיות לספק, ואת כותרת Authorization הרגילה ל־REST API שלה. אל תסירו את האימות מול השער בזמן בדיקת פרטי האימות לספק. תיעוד האימות.

בדיקה שמובילה להחלטה שימושית

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

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

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

Read this article in English

Post a Comment

Previous Post Next Post