אלפי מפתחות AWS שדלפו נותרו פעילים במשך שנים

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

768 מפתחות העניקו שליטה מנהלית מלאה

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

• 526 מפתחות של חשבון root ב־AWS
• 242 מפתחות של משתמשי IAM עם מדיניות AdministratorAccess
• 768 מפתחות בסך הכול שסיפקו שליטה מנהלית מלאה בחשבון AWS של חברה

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

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

Hugging Face הייתה המקור הגדול ביותר לחשיפות

Hugging Face הייתה המקור הבודד הגדול ביותר שזוהה, עם 8,482 חשיפות של פרטי AWS. לפי Truffle Security, 17.9% מפרטי הגישה הללו היו פרטי root.

הממצא משתלב בסריקה רחבה יותר של נתונים ציבוריים ב־Hugging Face. Truffle Security מסרה כי בחנה 7.6 פטה־בייט של מערכי נתונים ציבוריים ומצאה פרטי גישה פעילים באלפי מערכי נתונים. הדבר מדגים כיצד סודות יכולים להישאר זמינים גם מחוץ למאגרי תוכנה רגילים ולהמשיך לעבור בתוך נתונים שמופצים לציבור.

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

רוב המפתחות היו ישנים — וכמעט לא הוחלפו

הגיל החציוני המדווח של מפתח היה כ־1,831 ימים, כלומר בערך חמש שנים. המפתח הוותיק ביותר היה בן 17.4 שנים. רק 13.7% מהרשומות כללו מפתח חדש יותר הקשור לאותו משתמש, נתון שמרמז כי ברוב המקרים לא בוצעה החלפה שגרתית.

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

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

התראות תקציב היו נדירות

Truffle Security הצליחה לקרוא מידע על חשבונות של 2,754 ארגונים, אך רק 262 מהם הפעילו התראות תקציב של AWS.

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

מה ההתראות של AWS פותרות — ומה לא

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

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

מה לעשות מיד לאחר דליפת מפתח AWS

1. לבטל או להחליף את המפתח מיד

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

2. להיפטר ממפתחות root

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

3. לבדוק הרשאות ובעלות

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

4. לחקור לפני הביטול ואחריו

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

5. להחליף מפתחות קבועים בזהויות קצרות־חיים

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

6. להגדיר התראות תקציב ונתיב תגובה

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

הלקח הרחב יותר

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

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