שאל כל מהנדס ענן כמה יישומים פועלים בסביבה שלהם, ואתה תקבל מספר כדור ארנק. שאל שוב חמש דקות מאוחר יותר, והם עשויים להכפיל את זה.
קשה להאמין, אבל בין הפעלות מחדש של צינורות CI / CD, עומסי עבודה זומבים, אפליקציות עתיקות בפינות חשוכות של תשתיות, ומספקי זהות רבים מדי (IdPs) כדי לספור, קל לאבד את המסלול.
כאשר אתה לא יודע מה פועל, אתה לא יכול לנהל ולהגן על זה.
עם כל דבר אחר הופך מתמיד - מהאינטגרציה להתפשטות - גילוי צריך להיות גם.
הנושא של פיצול
בארגון טיפוסי כיום, יישומים מופצים ברחבי AWS, Azure, GCP, ואולי ענן פרטי או שניים.
באמצעות Google Cloud Platform (GCP) לדוגמה, יישום ניתן ליישם בדרכים רבות .יש לך אפשרויות הכוללות את App Engine, Cloud Run, Compute Engine, Google Kubernetes Engine ו- Apigee Gateway. פלטפורמות ענן אחרות כמו Azure ו- Amazon Web Services יש גם אפשרויות יישום רבות עבור עומסי עבודה של יישומים.
אפילו Infrastructure-as-Code (IaC), כמו Terraform, לא תמיד מצלם את התמונה כולה, במיוחד כאשר מפתחים לעקוף תבניות עבור יישומים ידניים או לשכוח לעדכן תגיות.
כמובן, יש התפשטות דומה למערכות הזהות אשר שולטים גישה לסביבות יישום אלה.ארגונים יכולים להיות שילוב של Okta, Microsoft Entra ID, ו- Amazon Cognito, כמו גם On-premises Active Directory או מוצרי ניהול גישה אינטרנט עתידיים, מקרים עתידיים של SiteMinder, ו On-prem Active Directory, לעתים קרובות להתקיים יחד.
זהות מבולבלת
יישומים עשויים לאמת אימות נגד IdPs שונים בהתאם למועד או למקום שבו הם התקיימו.לדוגמה, צוות עשוי לבחור Okta עבור יישומים פנימיים, בעוד שמערכות מול לקוחות מסתמכות על Microsoft
התוצאה היא רשת רחבה של אישורים, מדיניות ודפוסי גישה שהופכים את זה כמעט בלתי אפשרי לבדיקת עקביות.
רמה זו של
מדוע הבדיקות המסורתיות לא מקצרות אותו
דוגמה אחת לדוגמה של מודל בדיקה כרוכה ביצירת ייעוץ של ארבעת הגדולים, ביצוע בדיקה, יצירת דוח, וקראו לזה יום.
צינורות CI/CD עשויות להפיץ מחדש יישומים שנמחקו. צוות פיתוח עשוי לפתח משהו חדש מבלי להודיע על אבטחה.או גרוע מכך, יישום שקט עם מדיניות SiteMinder פנויה עשוי עדיין לאפשר לכל אחד עם דואר אלקטרוני @company.com ללכת ישר.
מה שמדאיג יותר הוא שהביקורות האלה הן בקנה מידה נמוכה באופן טבעי.הן מקבלות תמונה קצרה של מערכת המשתנה כל הזמן.כל גילוי משמעותי נמסר לאנשים המעורבים בתהליך הבדיקה ולעתים קרובות מאוחסנים במסמכים סטטיים שאף אחד לא רואה מחדש עד הסיבוב הבא.
אין עקביות, אין אוטומציה ואין הבטחה שהנתונים יישארו מדויקים מעבר ליום שהם נאספו.
דולרים וחוש הביטחון
בואו לא נשכח את העלות.הערכות אלה לוקחות לעתים קרובות שבועות של מאמץ ושל מאות אלפי דולרים.התוצאה היא מצגת יפה, עם תרשימים ונקודות כדורים שנראים נהדרים בחדר המועצה.אבל איזה ערך הן מביאות למהנדס מנסה לעקוב אחר אילו IdP שולט גישה ליישום מעבדה פועל על קבוצת GCP שנשכחה?
בינתיים, התוקפים אינם מחכים למחזור האו"ם הבא שלך.הם סורקים את פני השטח של ההתקפה שלך, מחפשים נקודות קצה שהחשבון שלך לא נתפס.זה למה המעבר לגלות מתמיד הוא הכרחי היום.
איך נראית תגלית מתמשכת?
צוותי אבטחה רבים מוצאים את עצמם מחוברים עם נראות יישום. הם מגלים אפליקציית צל אחת רק כדי למצוא עוד שלושה מסתתרים בשברים. הבעיה היא לא בשל עקשנות או חוסר כלים, זה כי סביבות משתנות כל הזמן. בין צוותי פיתוח לסובב שירותים חדשים, צינורות CI / CD מחדש את הישנים, ותשתית מתפתחת בשבוע, שמירה על מלאי סטטי הוא בלתי אפשרי.
זהו הסיבה מדוע סולם גילוי מתמשך.הוא מעביר את הנראות ממה שאתה עושה פעם רבע למשהו שאתה בונה לתוך הרקמה של הפעילויות שלך.
** סריקה מקורית בענן: ** שיחות ל-API בין פלטפורמות ענן (GCP, Azure, AWS) כדי לרשום פריסות בין שירותי: App Engine, ECS, Lambda, Cloud Run וכו '.
Identity correlationמפות כל אפליקציה ל-IdP שלה, אימות אכיפת MFA, ודפוסי אימות קטלוג (SAML, OIDC, LDAP, מבוסס כותרת וכו ').
CI/CD monitoringלתפוס יישומים המופיעים מחדש לאחר הפסקת הפעולה כי צינור לא קיבל את ההערה.
Tagging and classificationיישום מטא-נתונים כדי לארגן לפי היקף תאימות (למשל, אפליקציות PCI), מחלקה או רגישות נתונים.
גילוי מתמשך מספק את הרקמה המחוברת בין התשתית שלך ואדריכלות הזהות שלך.
זה יוצר את הבמה לניהול עמדות אבטחה בזמן אמת, תאימות פרואקטיבית ותגובה אפקטיבית לאירועים.ללא זה, הפגיעה הבאה הקשורה ליישום עשויה לא לבוא מפיץ מתוחכם, אלא במקום, משהו שהצוות שלך אפילו לא ידע היה פועל.
במקום תרגילים אש תקופתיים, גילוי מתמשך מתייחס נראות היישום כמו תהליך חי.
מקרה השימוש בעולם האמיתי: ההנחה של 2,500 נגד 4,500 אפליקציות
בחברה אחת מ-Fortune 500, נדרש CTO חדש לשאול שאלה פשוטה לכאורה: "כמה יישומים יש בסביבה שלך?"
"2,500", היא ענתה בביטחון, ואז הפסיקה. "חכה, רק רכשה חברה נוספת בערך באותו גודל.
התשובה לא באה ממערכת של רשומות. זה היה ניחוש, המבוסס על מספר ראשי רכישה והנחה קפדנית של שוויון. לא היה רשימת יישומים להתייעץ, לא לוח טכנולוגיית כדי לאשר את הסכום - רק מתמטיקה מאחורי הקופסה.
תסריטים כאלה מדברים כי הם מדגים את היעדר רישום יישומים אמין ומעודכן כל הזמן.ללא אחד, חברות נאלצות להסתמך על זיכרון, גיליונות ידניים וידע גזעני – הכול נכשל בסביבות דינמיות, מבוססות ענן.
אם צוות ההנהלה לא יכול למדוד את מספר האפליקציות במשחק, איך הם יכולים להיות בטוחים שהאפליקציות האלה מאובטחות, תואמות, ומנוהלות כראוי?
למה מהנדסים וצוותים של IAM צריכים לדאוג?
אם אתה מנהל את IAM, ואפליקציה עדיין משתמשת באימות בסיסי ללא MFA, זה תלוי בך, בין אם ידעת על האפליקציה או לא.
- אתה יודע מה יש שם בחוץ
- אתה יודע מי יש גישה
- אתה יודע אם זה בטוח
ואתה יכול להוכיח את זה.
הדרך להתמודד עם עולם של שינויים
גילוי הולך הרבה מעבר להכנת רשימה.הוא משחק תפקיד קריטי בהעלאת סיכונים מוסתרים - אלה
זוויות אפלות של הענן שלך, שבהן יישומים עתיקים, שירותים שגויים או הפצות לא מורשות עדיין עשויים לפעול בשקט וללא הבנה.
התגלות מתמשכת סוגרת את המעגל, ומספקת צוותי אבטחה וזיהוי מפה בזמן אמת של נוף היישום שלהם - מה פועל, איך הוא מאובטח ומי יש גישה - כך שהם יכולים לנקוט פעולות מכריעות לפני שהבעיות מתדרגות.
(כפי שצוין, ג'רי גבל קשור מבחינה מקצועית לחברה הפועלת בתחום ניהול זהויות ובאבטחה, דעותיו משקפות את המומחיות והניסיון שלו בתעשייה.)
