אסימון API של Cloudflare דלף? Roll משאיר את אותן ההרשאות

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

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

מזהים את האסימון בלי לעכב את הביטול

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

הבחינו בין דליפת אסימון לבין חשד להשתלטות על החשבון. ביטול הפעלה של משתמש בדפדפן אינו מבטל אסימון API, ו־Roll אינו מוציא משתמשים מהחשבון. אם זיהיתם גם פעילות חשודה בחשבון, פתחו My Profile > Sessions ובטלו הפעלות שאינן ההפעלה הנוכחית. בדקו גם את סיסמת החשבון ואת הגדרת האימות הדו־שלבי, כחלק מהטיפול הנפרד בגישת המשתמש.

מבצעים Roll ומחליפים את הסוד בשירותים

עבור אסימון משתמש, פתחו ב־Cloudflare את My Profile > API Tokens. ליד האסימון שנחשף פתחו את תפריט האפשרויות, בחרו Roll ואשרו את הפעולה. האסימון הקודם מפסיק להיות תקף, ולכן בקשות שעדיין משתמשות בסוד הישן ייכשלו. שמרו את הסוד החדש במקום המאובטח שממנו השירותים המורשים מקבלים את פרטי הגישה שלהם.

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

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

יוצרים אסימון מצומצם כשהגישה רחבה מדי

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

ליצירת אסימון משתמש, פתחו My Profile > API Tokens ובחרו Create Token. אפשר להתחיל מתבנית ולשנות אותה, או לבנות אסימון מותאם; בשני המקרים בדקו את סיכום ההרשאות והמשאבים לפני היצירה. אם האינטגרציה אמורה לפעול בשם החשבון ולא בשם משתמש מסוים, בחנו אסימון חשבון רק לאחר שווידאתם שנקודות הקצה הדרושות תומכות בו. שינוי סוג האסימון אינו פותר את הדליפה אם האינטגרציה אינה יכולה להשתמש בתחליף.

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

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

בודקים שינויים ביומן הביקורת

פתחו Manage Account > Audit Logs ובחרו טווח שמתחיל לכל המאוחר במועד החשיפה האפשרי ומסתיים אחרי החלפת האסימון. תיעוד Audit Logs של Cloudflare מתאר סינון לפי פעולה, גורם מבצע, שיטה ומשאב, וכן פרטים על שיטת האימות ועל ביצוע הפעולה דרך ה־API או לוח הבקרה. התמקדו בשינויים במשאבים שהאסימון הורשה לשנות, והשוו אותם לפעולות המתוכננות של הצוות.

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

קראו גם:

• OpenAI API או Gemini API: החשבון משתנה לפי אורך הקלט, לא רק המודל
• Docker או Podman: הביצועים כמעט זהים, ההרשאות לא
• Cloudflare Workers או AWS Lambda: חמש דקות ריצה משנות את הבחירה