גישה מבוססת Shared Access Signatures
כמויות הפערים והבעיות אבטחה בספקי הענן נערמות בצורה פסיכית והנקודה הסופר חשובה עדיין לא הופנמה אצל רבים וטובים – לראייה כמות התקריות, אירועים ומשברים שהיו לאחרונה. רובם המכריע לא נחשף וטוב שכך.
דיפולט קונפיג, מיסקונפיג, חוסר בהגדרות, חוסר הבנה ביישום ועוד שלל ירקות הן מנת חלקן של המגינים ביומיום – וליבי יוצא אליהם כי כמויות הממשקים והכלים שהצוותים צריכים להתמודד איתם ביומיום אינו הגיוני ואינו מאפשר להגיע לעיקר, ולכן אירועים ״נעלמים״ בממשקים, ומשם תקריות של חטיפת שרשרת דואר עם נזק של חצי מיליון שקל או דליפת נתונים רגישים מתוך אחסון בענן זה משהו בשגרה – משום מה אינו מרגש ואינו מפתיע.
שלא נשכח את העובדה שלתוקפים יש יתרון בגלל שאין להם ועדות, תקציבים, חוסר בכ״א, לוחות זמנים להטמעת כלים ועוד שלל סיבות, כמו זאת של בקרות שאינן נמצאות במקום, או כלים שנמצאים בהטמעה חודשים ארוכים וללא מטרה וצפי לסגירת פערים שלשמם הוקמו.
אחת הבעיות בענן מיני רבים היא אחסון בענן, קרי, Azure Storage והאובייקטים שהוא מספק לנו, וכמו שניתן לראות בארכיטקטורה הכללית שהיא בנויה על גבי מספר שכבות ספציפיות.
הבעיה המוכרת של קבצים שנמצאים בחשיפה ציבורית מתוך Azure Blob / AWS S3 Bucket ועננים אחרים היא דבר מוכר וידוע שמופיע בכל סביבה ועם קצת אהבה אפשר למצוא אובייקטים חשופים, להדליף אותם, למצוא סיסמאות ובמקרים מסויימים גם מצאתי מפתחות גישה – כל זאת דרך פעולות חיצוניות. איך הקסם הזה קורה? קצת הבנה בארכיטקטורה, מעט פוורשל, עבודה עם הכלים שזמינים ברשת – הענן הוא לא הגבול.
המאמר המצורף הוא חלק מסדרת מאמרים מתוך הבלוג של מיקסונפיג שמסביר על הארכיטקטורה, איך לתקוף ולהגן על Azure Blob עם כל מיני טיפים ועוד. למאמר של סיכונים ותקיפה בקישור Azure Blob Container Threats & Attacks (misconfig.io)
כאמור, בעיה נפוצה ומרכזית בשירותי הענן השונים היא מיסקונפיגורציה ומניעת חשיפת נתונים ברכיבי אחסון. הבעיה נגרמת ע"י הגדרות גישה ללא אפשרויות אבטחה בסיסיות או בצורה לא נכונה (לעיתים הגדרת vnet לא נכונה דופקת את כל האבטחה), או הגדרת מפתח גישה שמסתובב עם הרשאות גבוהות ללא מעקב וניטור.
למה אני רושם על חתימת גישה? מכיוון שישנם תרסרי דרכים לבצע אביוז לנתונים רגישים מול Azure דרכו, וזה גם חלק מתוך הסייקל של אביוז – לימוד, התנסות במערכת ולהבין ארכיטקטורה, או ליתר דיוק – Study Intent, Design and, Usage of the System.
מהו Shared Access Signatures
הקשחת גישה אל נתונים בשירות Azure יכולה להיעשות ע"י שכבות שונות, וכאשר מדובר על הקשחת גישה אל Azure Stoage ניתן לבצע הקשחה באמצעות Shared Access Signatures (או בקצרה SAS), קרי, חתימת גישה משותפת. האפשרויות של Shared Access Signatures מאפשרות הקשחה ע"י דלגציה, מאפיינים ופרמטרים שונים, וע"י כך להגן על מידע ותוכן ברמת Azure Storage, האפשרויות של SAS נעשות באמצעות Security Controls עם גרנולריות שקובעת איך ניתן להנגיש את המידע. למשל, ניתן לקבוע איך אפשר לצרוך את המידע, מהם ההרשאות הניתנות בגישה למידע, מהו תוקף הגישה למידע ומאפייני אבטחה נוספים.
חתימת גישה משותפת (SAS) היא URI המעניק זכויות גישה מוגבלות למשאבי Azure Storage. ניתן לספק חתימת גישה משותפת למשאבים או נכסים שאין לסמוך עליהם עם מפתח חשבון, אך עדיין זקוקים לגישה למשאבי חשבון אחסון מסוימים. לכן, ע״י הפצת SAS URI, ניתן להעניק גישה למשאב למשך פרק זמן מוגדר, עם קבוצת הרשאות מוגדרת.
פרמטרי שאילתת URI המרכיבים טוקן SAS משלבים את כל המידע הדרוש כדי להעניק גישה מבוקרת למשאב אחסון. למשל, אפליקציה מבוססת SAS יכולה להגיש בקשה מול Azure Storage באמצעות SAS URI בלבד. המידע בטוקן SAS משמש לאישור הבקשה.
ישנם סוגים של חתימות גישה משותפות, למשל:
חשבון SAS שמאציל גישה למשאבים באחד או יותר משירותי האחסון וכל הפעולות הזמינות באמצעות SAS זמינות גם באמצעות אותו חשבון.
שירות SAS שמאציל גישה למשאב רק באחד משירותי האחסון הבאים: Blob / Tables / Files / Queues
חשבון SAS שמאציל גישה להקצאת משתמשים והוא סוג של SAS מאובטח באמצעות אישורי Azure AD והוא נתמך עבור Blob בלבד, וניתן להשתמש בו כדי להעניק גישה לקונטיינרים.
כל הפעולות דלגציה אשר נעשות באמצעות חשבון SAS או באמצעות אותו Service זמינות ויכולות להיעשות על גבי החשבון SAS, בנוסף לזה ניתן לבצע דלגציה לפעולות ברמת השירות כדוגמת Get או Set למאפייני השירות, או פעולות דלגציה של קריאה, כתיבה, מחיקה על גבי BLOB או Queues ועל גבי Files.
טיפ: מומלץ לשלב בכל דלגציה אכיפה באמצעות פרטי חשבון מבוססים Azure AD וזאת בהשוואה אל מול הגדרה שמתבססת רק על מפתח חשבון.
הדיאגרמה הבאה נותנת מבט חטוף על חתימת גישה והאובייקטים שאנו צריכים לדעת בכדי לתקוף, לתחקר ולהגן. אנו יכולים לפרק URL שלם לגורמים ולהבין בצורה מהירה את המבנה והמהות (מתואר בקצרה בהמשך).
גישת SAS
חתימת גישה משותפת יכולה להיות אחת משתי הצורות הבאות:
Ad hoc SAS יכול להיות במצבים כאשר יוצרים Shared Access Signatures מסוג AD-HOC כאשר ישנם מאפיינים כגון זמן התחלה, תוקף הרשאות ותוקף הגישה אשר מוטמעים באותו URI.
Service SAS with stored access policy שיכול להיות במצבים בהם ישנה מדיניות אשר מוגדרת במשאב עצמו ברמת קונטיינר, ולכן יכולה להיות מסוג Blob או Table או File Share, וניתן להשתמש במדיניות הגישה לאכיפה עבור חתימות גישה משותפת לשירות.
כאשר משייכים SAS למדיניות גישה מאוחסנת, אותו SAS יורש את כל אותם אכיפות, כדוגמת – זמן ההתחלה, זמן התפוגה וההרשאות – המוגדרים עבור מדיניות הגישה המאוחסנת.
איך עובד SAS
חתימת גישה משותפת (SAS) היא URI אשר חתום ומצביע על משאב אחסון אחד או יותר אשר כולל טוקן המכיל סט (או קבוצות של סטים) המכילים פרמטרים ושאילתות מסוימות. הטוקן מציין כיצד הגורם החיצוני יכול לגשת למשאבים, וזאת ע"י אחד מאותם פרטמטרים שהוגדרו מבעוד מועד. החתימה, בנויה מהפרמטרים של SAS ונחתים עם המפתח ששימש ליצירת אותו SAS.
חתימה זו משמשת את Azure Storage בכדי לאשר גישה למשאב האחסון.
SAS signature מאפשר לחתום בשני הדרכים הבאות:
- באמצעות מפתח של User Delegation המתבססים על פרטי משתמש של Azure AD
- באמצעות מפתח חשבון האחסון (storage key) על גבי Service SAS או חשבון SAS החתומים באמצעות מפתח חשבון האחסון, וזאת בכדי ליצור SAS שנחתם באמצעות מפתח החשבון. לאפליקציה צריכה להיות גישה למפתח החשבון.
SAS token הוא למעשה מחרוזת שנוצרת בצד הלקוח, למשל באמצעות אחת ממשאבי Azure Storage. הטוקן של SAS אינו עוקב אחר Azure Storage בשום דרך.
ניתן ליצור מספר בלתי מוגבל של טוקנים SAS בצד הלקוח, ולאחר יצירת SAS, ניתן להפיץ את הטוקן ליישומי לקוח הדורשים גישה למשאבים בחשבון האחסון שלך.
כאשר יישום בצד לקוח מספק URI SAS אל Azure Storage כחלק מבקשה, השירות בודק את הפרמטרים והחתימה של SAS בכדי לוודא שהוא תקף לאישור הבקשה, ובמידה והשירות מאמת שהחתימה תקפה – הבקשה אושרה, אחרת הבקשה נדחית עם קוד השגיאה 403.
איך יוצרים SAS
הדרך הפשוטה ביותר ליצור טוקן SAS היא באמצעות פורטל Azure, ובכדי ליצור טוקן SAS, ראשית, ניגש אל חשבון האחסון Azure Storage, הגדרות ומשם ניגש אל חתימת גישה משותפת (SAS).
ישנם הרשאות שונות שניתן להגדיר בטוקן SAS, כדוגמת זמני התחלה לגישה, תוקף זמן לסיום, רמת הרשאות וכן הלאה.
בדוגמה שלפנינו ישנו BLOB ולכן ביצירת טוקן SAS יהיו לנו מספר הרשאות והגדרות בחתימת גישה לאותו משאב ספציפי.
אפשר לומר שמפתח גישה דומה לסיסמת בסיס המספקת הרשאה מלאה על כל אפשרות אחסון בחשבון. אם תוקף מקבל מפתח גישה, הוא יכול לבצע כל פעילות התקפית/זדונית באפשרות אחסון. עם זאת, באפשרותך להגביל את הגישה לאפשרות אחסון באמצעות חתימת גישה משותפת. טוקן SAS מאפשר להגדיר משאבים לגישה, זמן תפוגה והרשאות עבור שירות אחסון.
טוקן SAS מורכב מכמה פרמטרים:
sv — אופציונלי, מתעד את הגרסה של שירות האחסון.
ss — השירותים החתומים הנגישים באמצעות SAS. קונטיינר (b), תור (q), טבלה (t), קובץ (f).
srt — סוגי המשאבים החתומים הנגישים באמצעות SAS. שירות(ים): גישה לממשקי API ברמת השירות; קונטיינר (c): גישה לממשקי API ברמת הקונטיינר; אובייקט (o): גישה לממשקי API ברמת האובייקט עבור קונטיינר, הודעות תור, ישויות טבלה וקבצים.
sp — ההרשאות החתומות עבור SAS. קריאה (r), כתיבה (w), מחיקה (d), רשימה (l), הוספה (a), יצירה (c), עדכון (u) ותהליך (p).
se — הזמן שבו חתימת הגישה המשותפת הופכת ללא חוקית.
st — הזמן שבו טוקן SAS הופך להיות תקף.
spr — הפרוטוקול המותר לבקשה שנעשתה עם החשבון SAS.
sig — Siganture משמש כדי לאשר בקשה לאחסון מחדש.
לסיכום
בכל פעם שאנו מספקים/מקבלים גישה ישירה לחשבונות אחסון של Azure באמצעות חתימת גישה משותפת, עלינו לבחון מקרוב כדי להבין את ההרשאה שלנו. בעוד של SAS יש חלקים רבים, לא קשה מדי לפרק אותו אם מכירים את החלקים החשובים ביותר.
דרכים רבות לעשות אביוז והכלים שנמצאים כיום אינם מונעים מסלול גישה ישיר שעוקף כל מנגנון אבטחה – החלק המעניין איך לעשות אביוז יעלה במאמר הבא.
