מוגדר זה לא נאכף
הפוסט הזה הוא הקריאה שלי במחקר שפורסם על ידי TrustOnCloud. הממצאים שלהם; הטענה על המשמעות שלהם היא שלי. שווה לקרוא את המחקר המקורי במלואו.
תגידו, אתם באמת סומכים על ההרשאות שאתם מגדירים בענן?
כי הרגע התברר משהו שאמור להקפיץ כל אחד שישן בשקט בזכות least privilege. חברת מחקר בשם TrustOnCloud גילתה ש-AWS פשוט לא אכפה תנאי הרשאה שהיא בעצמה שיווקה.
מה קרה
נובמבר 2025, אמזון משחררת ארבעה condition keys חדשים ל-DynamoDB. המטרה: לתת לכם שליטה עדינה מי יכול לגשת לאילו רשומות ב-Global Secondary Index. אתם כותבים policy יפה, מגבילים כל משתמש לדאטה שלו בלבד, ולוחצים deploy. מרגישים אחראים. מרגישים מאובטחים.
רק בעיה אחת קטנה: אמזון בכלל לא בדקה את התנאים האלה בזמן אמת.
כלומר, שחקן שהורשה לגשת רק לפרופיל של עצמו יכול היה בשקט לשלוף את הפרופילים של כל שאר השחקנים. בלי שגיאה. בלי חסימה. בלי שום סימן שמשהו לא תקין. ה-policy שלכם היה שם, נראה מצוין בקוד, ולא עשה כלום.
וכאילו זה לא מספיק, התיעוד הרשמי אפילו טען שאפשר להחליף בין המפתחות האלה למנגנון הרשאה אחר. מידע שגוי, בתיעוד רשמי, על פיצ’ר אבטחה.
עכשיו תעצרו רגע ותחשבו כמה מהאבטחה שלכם בנויה על הנחה
הנחתם שהתנאי נאכף. הנחתם שהתיעוד מדויק. הנחתם שאם לא קיבלתם Access Denied, אז הכל עובד כמו שצריך.
זה בדיוק מה שאני מטיף לו כבר שנים לפנטסטרים אצלנו. מוגדר זה לא נאכף. הרשאה שלא בדקת ידנית, עם תרחיש allow וגם תרחיש deny, היא בגדר משאלת לב.
אצל לקוחות אנחנו רואים את זה כל שבוע. סטק אבטחה מפואר, IAM policies מורכבים, מסמכי ארכיטקטורה מהממים. ואז אנחנו מנסים בפועל לגשת למשהו שאסור לנו, וזה פשוט עובד.
הלקח הוא לא “אמזון פישלה”
ענקיות טכנולוגיה טועות, זה קורה, ופה לפחות זה טופל. הלקח הוא שאתם לא יכולים להאציל את האמון שלכם לספק ואז ללכת לישון בשקט.
אבטחה זה לא מה שכתוב ב-policy. אבטחה זה מה שקורה כשמישהו באמת מנסה לפרוץ.
בדקתם פעם אחרונה שההרשאות שלכם באמת אוכפות, או רק שהן מוגדרות?
פוסט זה פורסם לראשונה בלינקדאין בתאריך 2026-07-21. — ארז מטולה
