דף הבית / מוגדר זה לא נאכף
Authorization and Access Control
מוגדר זה לא נאכף
AWS שחררה ארבעה condition keys ל-DynamoDB ולא בדקה אותם בזמן אמת. ה-policy שלכם היה שם, נראה מצוין בקוד, ולא עשה כלום.
הפוסט הזה הוא הקריאה שלי במחקר שפורסם על ידי 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. — ארז מטולה
להמשיך לקרוא
עוד מהבלוג
Authorization and Access Control
כשה-JWT סומך על הקליינט: איך קיצור דרך אחד הפך למשתמש אדמין
מבדק חדירה שבו ה-JWT נשא את ההרשאות ב-payload והשרת סמך עליהן. שינוי שדה אחד - וגם alg:none מותר - הפך משתמש רגיל…
לקריאהAuthorization and Access Control
טוקן תקף הוא לא הרשאה: ה-scope שאף אחד לא בדק
זרימת Authorization Code מלאה ותקינה, ומולה endpoint ניהולי שקיבל כל טוקן חוקי בלי לבדוק scope.
לקריאהAuthorization and Access Control
„זה GraphQL, זה Typed, זה סגור” – שאילתת introspection אחת אחר כך
introspection החזיר את כל הסכימה. mutation אחד הגדיר isAdmin=true. ה-UI הסתיר את השדה, ה-API לא בדק אותו.
לקריאהספרו לנו מה המערכת עושה ומה מדאיג אתכם.
אם בדיקת חדירה אינה מה שאתם צריכים עכשיו, נאמר זאת.