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

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

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

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

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

שימו לב כי המאמר נוגע באופן כללי באפשרויות של Azure Key Vault ובאפשרויות תקיפה והגנה בודדות והינו מאמר הקדמה. 

עד כאן הקדמה כללית לגבי תשתית ומנגנון Vault. היכולות של מנגנון Azure Key מכילות מספר אפשרויות של מנגנון Vault שמאפשרים לעבוד עם מפתחות, סיקרטים, תעודות דיגיטליות, הרחבת אפשרויות לרכיב HSM ועוד שלל אפשרויות.

מי אתה Azure Key Vault?

אומנם Azure Key Vault נראה מרחוק כמנגנון שולי אבל מדובר על רכיב שנמצא בכל מימוש, הטמעה, וורקלואד, אפליקציה ופונקציה שהיא ב Azure. מקרוב מדובר על מנגנון מרכזי שיכול להיות נקודת כשל או מנגנון להריץ תקפיות שונות, אפילו כאלה שמכילות privilege escalation.

הדוקס במיקרוסופט של Azure Key Vault מכיל המון תוכן אך עדיין לא יורד לרזולוציות עמוקות

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

השירות של Azure Key Vault יכול לאחסן שלושה סוגים מרכזיים של אובייקטים:

Secrets – ניתן להשתמש בכדי לאחסן ולשלוט באופן מאובטח בגישה לטוקנים, סיסמאות, אישורים, מפתחות API וסיקרטים אחרים. סיקרט הם רצף של בתים מתחת ל-10 KB וסטרינגים, מפתחות חשבון, או סיסמאות עבור PFX. אפליקציה מורשית יכולה לאחזר סיקרט לשימוש ברגע שהיא מופעלת.

Keys – רכיב KMS שמאפשר לנהל, ליצור ולשלוט במפתחות ההצפנה המשמשים להצפנת הנתונים.מפתחות כרוכים בחומר הצפנה שמיובא ל Key Vault, או שנוצר כאשר אפליקציה מבקשת מתוך Key Vault לבצע זאת. אפליקציה, מערכת או שירות יכולים לבקש מתוך Key Vault לבצע פעולה קריפטוגרפית אחת או יותר עם מפתח ייעודי.

Certificate – מאפשר פריסה, הטמעה וניהול של אישורי TLS/SSL ציבוריים או פרטיים לטובת אפליקציות ומערכות Azure וכן המשאבים המחוברים. בעקרון מדובר על תעודת X.509 מנוהלת, ולכן ההבדל הוא שמנגנון Azure Key Vault מציע אפשרויות ניהול מחזוריות. בדומה למפתחות (Keys) גם כאן אפשר לשלוח בקשות ליצירת אישורים, ובמידה ויש אישור, נוצרים מפתח וסיסמה פרטיים של הבקשה לטובת האפליקציה.הסיסמה מאוחסנת בתור Azure Secret ואילו המפתח הפרטי מאוחסן כמפתח Azure. אישורים שפג תוקפם יכולים לבצע Roll-Over עם הודעות לפני שפעולות אלו מתרחשות.

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

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

לצב האובייקטים הקיימים של Azure Key Vault יש תמיכה שני סוגי מפתחות: RSA או HSM.

RSA – פעולות קריפטוגרפיות נעשות באמצעות מפתחות RSA Key Vault בתוכנה. מפתח הצפנת מאוחסן במודול של אבטחת חומרה (HSM) והוא מגן על המפתח בפועל בזמן מנוחה.

HSM – פעולות קריפטוגרפיות באמצעות מפתחות HSM Key Vault ולעולם לא "עוזבות" את גבולות ההגנה של HSM, כלומר, כל פעולות ההצפנה במפתחות מוגני HSM מתרחשות בתוך המודול של HSM.

כמו שהוזכר קודם לכן הניהול של Azure Key Vault אינו מסובך וניתן לנהל באמצעות הפורטל, באמצעות פווארשל, או Azure CLI וכן באמצעות ARM או Rest ובדרכים נוספות.

לאחר שיוצרים Key Vault ניתן להוסיף סיקרט, מפתחות מוגני אפליקציה ומודול HSM מוגן מפתח – כל המפתחות והסיקרטים קריאים ונגישים ע"י URI ייעודי.

תהליך גישה לכספת

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

– מפתח האפליקציה צריך לרשום את האפליקציה בתוך Azure AD

בסיום תהליך הרישום מונפקים לאפליקציה מזהה עם ערך של Client ID ומפתח אימות שידוע כ Auth Key.

לצורך אימות מול Key Vault, היישום מבקש קוד (authorization code) או טוקן מתוך Azure AD. הפעולה מתרחשת על ידי הצגת מזהה Client ID והמפתח שהוא מקבל במהלך הרישום.

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

כדאי לדעת

כמו בכל תשתית לניהול מפתחות גם בתשתית של Azure Key Vault ישנם דגשים, המלצות ודברים שכדאי לדעת. כמה נקודות כלליות שכדאי לדעת:

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

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

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

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

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

לתקוף ולהגן

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

לתקוף

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

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

allintext:accountkey blob filetype:config -site:sourceforge.net

סנריו תקיפה  – Vault & Token – אחת האפשרויות לעבוד עם אפליקציות וטוקנים היא באמצעות זהות מנוהל (MSI).

כאשר עובדים עם MSI ומנהלים טוקן עם זהות אנו יכולים לעשות פיבוטינג על גבי אובייקטים רבים של Azure Key Vault. בכדי לאחזר ערכים מתוך Key Vault אנו צריכים את הטוקן שנמצא בטווח של  vault.azure.net. למשל, באפליקציה מסוימת, במידה האפשרות של MSI צריכה להיות מוצמדת לאפליקציה עם מפתח. במצב של אפליקציה שהיא Compromised אנו חייבים לגנרט טוקן.

איך משיגים טוקן? ישנם אינספור פקודות ברמת MSI, או Header ונוספות.

MSI Secret

curl "%MSI_ENDPOINT%?resource=https://management.azure.com&api-version=2017-09-01" -H secret:%MSI_SECRET% -o token.txt type token.txt

X-IDENTITY-HEADER

curl "%IDENTITY_ENDPOINT%?resource=https://management.azure.com&api-version=2019-08-01" -H X-IDENTITY-HEADER:%IDENTITY_HEADER% -o token.txt type token.txt

טעות קריטית ונפוצצה היא ליצור מפתח עם האפשרות לאחזר במצב Plain Text.

המגן

ישנם דרכים רבות להגן על Key Vault ועל האובייקטים השונים.החל מהקשחת מפתחות וסידקרטים, דרך הורדת הרשאות ועד סגמנטציה ברמת Endpoint. לצד זה Defender For Endpoint מציע את האפשרויות של זיהוי מיסקונפיגורציות, חשיפות, התראה על חריגות ועוד הרבה. לצד זה תמיד אפשר להזרים לוגים (Diagnostic settings) אל Microsoft Sentinel וליצור חוקי זיהוי על אנומרציה, נגיעה בגדר ועוד שלל תקיפות.

מימוש Private Link – לחבר את Private Endpoint אל הכספת – מה נותן לנו החיבור של Private Link/Endpoint?

– מאפשר לך לגשת לשירותי Azure ובפרט אל Key Vault דרך נקודת קצה פרטית באמצעות Vnet
– מצמצם את התנועה בין Vnet לבין IP פרטי
– PL יכול להשתמש בכתובת IP פרטית של Vnet ותמפה אותה לשירות Azure
– אם יש VPN שהוקצה ל Vnet, אז מאפשר לגשת לשירותי Azure דרך אותו PL
– בעת הגדרת PL, שירות DNS של Azure יכול לארח PL עם Azure עבור שאילתת חיבור

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

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

מעבר להמלצות השונות ישנה אפשרות להגן על Azure Key Vault עם Defender for Cloud ולבצע Threat Detection. האפשרויות ניטור והגנה של MDC מתבססות על מזהים שונים:

Access from a TOR exit node to a Key Vault
Suspicious policy change and secret query in a Key Vault
Suspicious secret listing and query in a Key Vault
Unusual user-application pair accessed a Key Vault
Unusual application accessed a Key Vault
Unusual user accessed a Key Vault
Unusual operation pattern in a Key Vault
High volume of operations in a Key Vault
User accessed high volume of Key Vaults

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

ביום שלישי הקרוב, 24.5 בשעה 11:00 בבוקר אני אדבר יחד עם מעיין (Microsoft Services) על Azure Key Vault.
פרטים נוספים בקישור Security is the Key ~ Azure Key Vault ~ AzSecOps Track

המאמרים הבאים ימתקדו כל אחד מהם בתקיפה, הגנה וניטור Azure Key Vault.