בחודש שעבר כתבתי מאמר על הדרך שבה פלטפורמות עם קוד נמוך/ללא קוד מציעות שיתוף אישורים כשירות, למה הן עושות את זה ואיך זה נראה נקודת מבט של תוקף. במאמר זה, אתמקד בהשלכות של אותה פשרה וכיצד היא משפיעה על ארגונים כיום.
הנה הסיבה ששיתוף האישורים של הארגון שלך עם מישהו אחר הוא מנהג רע. נניח שאני רוצה להעביר את האישורים שלי לעמית כדי לבצע שאילתות ביומני ייצור לניתוח התנהגותי משתמש חד פעמי. בארגון טיפוסי, הענקת הרשאות למישהו לבצע שאילתות במקור נתונים חדש עשויה להיות תהליך ארוך של סקירת גישה, במיוחד כשמדובר בייצור או נתונים רגישים. הקולגה שלי יכול בקלות להיות מתוסכל. "כל מה שרציתי זה לעשות את השאילתה הקטנטנה החד-פעמית הזו, וכבר חיכיתי חודש!" הם יכלו לומר. יכולתי פשוט להריץ את השאילתה עבורם, אבל אני מוצף במשימות היומיומיות שלי, ושאילתות חד פעמיות נוטות להסתבך.
נשאר לי פתרון אחד מהיר: אני יכול פשוט לשתף את שם המשתמש/סיסמה שלי עם עמית שלי. אם הם יקבלו אתגר MFA, אני אאשר בשמחה. אני לא צריך לבזבז את הזמן בהפעלת השאילתה, והחסימה של עמית שלי בוטלה. כולם מנצחים! ימין?
ובכן, אתה צודק בניתוח שלך, אבל אתה מפספס את התמונה הגדולה יותר. למרות שחשוב לארגון שהקולגה שלך יבצע את ניתוח התנהגות המשתמשים שלו, חשוב באותה מידה, אם לא יותר, שהארגון שלך יישאר תואם לשורה שלמה של תקני פרטיות ואבטחה וישמור על אמון הלקוחות על ידי שמירה על מחויבות החברה לאבטחה .
אם יעדים ארגוניים ברמה גבוהה לא משכנעים אותך, שקול את צוותי הניהול המרכזיים בתחום ה-IT או האבטחה. צוותים אלה מבססים את הפעולות והאבטחה שלהם על העובדה שלכל משתמש יש את הזהות הייחודית שלו. צוותי IT מגדירים מדיניות רשת וגישה המניחים שכל משתמש יהיה מחובר מ-IP ארגוני אחד או מחשב נייד ארגוני בבת אחת; צוותי אבטחה מתאמים אירועים על סמך מזהה משתמש; צוותי כספים יכולים לצבור דוחות עלויות לכל משתמש וסביבת הענן האישית שלו. שיתוף אישורים מערער בין היתר את כל ההנחות הללו. זה מסיר את המשמעות הבסיסית של זהות מקוונת.
דוגמה בעולם האמיתי
בואו נפנה לעולם של קוד נמוך/ללא קוד ונבחן תרחיש בעולם האמיתי. במפעל גדול, ג'יין, עובדת בהשראת צוות שירות הלקוחות, הבינה שכאשר עובדים ברחבי הארגון לוקחים חלק במקרה של לקוח, בדרך כלל חסר להם מידע מפתח על הלקוח, כגון היסטוריית תיקי התמיכה והרכישות האחרונות שלהם. זה מדרדר את חווית הלקוח, שכן הוא צריך להסביר את הבעיה שלו שוב ושוב תוך כדי ניתוב התיק לעובד הנכון שיוכל לטפל בבעיה.
כדי לשפר זאת, ג'יין יצרה אפליקציה המאפשרת לעובדי החברה להציג מידע מפתח זה על לקוחות כאשר אותם עובדים הם חלק מהצוות האחראי לטיפול במקרה התמיכה של הלקוח. ראשית, בואו ניקח רגע להכיר בכוחו של קוד נמוך/ללא קוד, המאפשר לג'יין לזהות צורך ולטפל בו בעצמה, מבלי לבקש תקציב או להמתין להקצאת משאבי IT.
בזמן בניית האפליקציה, ג'יין נאלצה לעקוף בעיות מרובות, כשהגדולה ביותר היא הרשאות. לעובדים ברחבי הארגון אין גישה ישירה לשאילתות במסד הנתונים של הלקוחות כדי לקבל את המידע שהם צריכים. אם כן, אז ג'יין לא הייתה צריכה לבנות את האפליקציה הזו. כדי להתגבר על בעיה זו, ג'יין נכנסה למסד הנתונים והטמיעה את ההפעלה המאומתת שלה ישירות באפליקציה. כאשר האפליקציה מקבלת בקשה ממשתמש אחד, היא תשתמש בזהות של ג'יין כדי לבצע את השאילתה ולאחר מכן תחזיר את התוצאות למשתמש. תכונה זו של הטבעת אישורים, כפי שחקרנו בחודש שעבר, הוא מאפיין מפתח של פלטפורמות עם קוד נמוך/ללא קוד. ג'יין הקפידה להגדיר בקרת גישה מבוססת תפקידים (RBAC) באפליקציה כך שכל משתמש יוכל לגשת רק למקרים של לקוחות שהם מוקצים אליהם.
האפליקציה פתרה בעיה עסקית חשובה, וכך היא זכתה במהירות לאימוץ משתמשים ברחבי הארגון. אנשים שמחו שהם יכולים לספק שירות טוב יותר ללקוחות שלהם על ידי ההקשר הנכון לשיחה. גם הלקוחות היו מרוצים. חודש לאחר שג'יין יצרה את האפליקציה, היא כבר הייתה בשימוש על ידי מאות משתמשים ברחבי הארגון, כאשר שיעורי שביעות רצון הלקוחות עלו.
בינתיים ב-SOC, הופעלה התראה בחומרה גבוהה המציגה פעילות חריגה סביב מסד הנתונים של לקוחות הייצור והוקצתה לאיימי, אנליסטית אבטחה מנוסה. החקירה הראשונית של איימי הראתה שמשתמש פנימי ניסה לגרד את כל מסד הנתונים, תוך שאילתות מידע על לקוחות מרובים ממספר כתובות IP ברחבי הארגון. דפוס השאילתה היה מורכב מאוד; במקום דפוס ספירה פשוט שהיית מצפה לראות בעת גירוד של מסד נתונים, הנתונים של אותו לקוח נבדקו מספר פעמים, לפעמים דרך כתובות IP שונות ובתאריכים שונים. האם זה יכול להיות תוקף שמנסה לבלבל את מערכות ניטור האבטחה?
לאחר חקירה מהירה, איימי חשפה פיסת מידע חיונית: כל השאילתות הללו בכל כתובות ה-IP והתאריכים השתמשו בזהות משתמש בודדת, מישהי בשם ג'יין מצוות שירות הלקוחות.
איימי הגיעה לג'יין לשאול אותה מה קורה. בהתחלה, ג'יין לא ידעה. נגנבו לה את האישורים? האם היא לחצה על הקישור הלא נכון או סמכה על האימייל הנכנס הלא נכון? אבל כשג'יין סיפרה לאיימי על האפליקציה שבנתה לאחרונה, שניהם הבינו שאולי יש קשר. איימי, האנליסטית של SOC, לא הכירה קוד נמוך/ללא קוד, אז הם פנו לצוות AppSec. בעזרתה של ג'יין, הצוות הבין שבבקשתה של ג'יין מוטבעים האישורים של ג'יין. מנקודת המבט של מסד הנתונים, לא היה יישום - הייתה רק ג'יין, שהוציאה לפועל הרבה מאוד שאילתות.
ג'יין, איימי וצוות AppSec החליטו לסגור את האפליקציה עד שיימצא פתרון. משתמשי אפליקציות ברחבי הארגון היו מתוסכלים מאז שבאו להסתמך עליו, וגם הלקוחות הרגישו זאת.
בעוד איימי סגרה את הנושא ותיעדה את הממצאים שלה, סמנכ"ל שירות הלקוחות לא היה מרוצה לראות את שיעור שביעות הרצון של הלקוחות יורד, אז הם ביקשו מג'יין לחפש פתרון קבוע. בעזרת התיעוד של הפלטפורמה וצוות מרכז המצוינות של הארגון, ג'יין הסירה את זהותה המוטבעת מהאפליקציה, שינתה את האפליקציה כך שתשתמש בזהות של כל משתמש כדי לבצע שאילתות במסד הנתונים, והבטיחה למשתמשים לקבל הרשאות רק למקרים של לקוחות שהם משויכים אליהם . בגרסה החדשה והמשופרת שלה, האפליקציה השתמשה בזהות של כל משתמש כדי לבצע שאילתות במאגר הלקוחות. ג'יין ומשתמשי האפליקציה שמחו שהאפליקציה חזרה לאינטרנט, איימי וצוות AppSec שמחו שהזהות של ג'יין אינה משותפת יותר, והארגון ראה את שיעור שביעות הרצון של הלקוחות מתחיל לעלות שוב. הכל היה טוב.
שבועיים לאחר מכן, ה-SOC קיבל התראה נוספת על גישה חריגה למאגר לקוחות הייצור. זה נראה דומה באופן חשוד להתראה הקודמת באותו מסד נתונים. שוב, כתובות IP מכל הארגון השתמשו בזהות של משתמש יחיד כדי לבצע שאילתות במסד הנתונים. שוב, המשתמש הזה היה ג'יין. אבל הפעם, צוות האבטחה וג'יין ידעו שהאפליקציה משתמשת בזהות המשתמש שלה. מה קורה?
החקירה העלתה שיש לאפליקציה המקורית משותף באופן מרומז סשן מסד הנתונים המאומת של ג'יין עם משתמשי האפליקציה. על ידי שיתוף האפליקציה עם משתמש, אותו משתמש קיבל גישה ישירה ל- הקשר, מעטפת סביב הפעלת מסד נתונים מאומתת שסופקה על ידי הפלטפורמה של ה-low code/no-code. באמצעות החיבור הזה, משתמשים יכלו למנף את הפגישה המאומתת ישירות - הם כבר לא היו צריכים לעבור דרך האפליקציה. מסתבר שכמה משתמשים גילו זאת, וחשבו שזו ההתנהגות המיועדת, השתמשו בהפעלה של מסד הנתונים המאומת של ג'יין כדי להפעיל את השאילתות שלהם. הם אהבו את הפתרון הזה, שכן השימוש ישירות בחיבור העניק להם גישה מלאה למסד הנתונים, לא רק למקרים של לקוחות שהם מוקצים אליהם.
הקשר נמחק, והאירוע הסתיים. אנליסט ה-SOC פנה למשתמשים שהשתמשו בחיבור של ג'יין כדי להבטיח שהם השליכו כל נתוני לקוחות שהם אחסנו.
התמודדות עם אתגר האבטחה של Low-Code/No-Code
הסיפור למעלה הוא תרחיש מהחיים האמיתיים של חברת B2C רב לאומית. חלק מהפרטים הושמטו או הותאמו כדי להגן על הפרטיות. ראינו כיצד עובד בעל כוונות טובות יכול בלי משים לחלוק את זהותו עם משתמשים אחרים, ולגרום למגוון שלם של בעיות ב-IT, באבטחה ובעסק. כפי שבדקנו בחודש שעבר, שיתוף אישורים הוא מאפיין מפתח של קוד נמוך/ללא קוד. זה הנורמה, לא היוצא מן הכלל.
As קוד נמוך/ללא קוד ממשיך לפרוח בארגון, במודע או שלא, חיוני שצוותי אבטחה ו-IT יצטרפו לשיחת הפיתוח העסקי. אפליקציות בעלות קוד נמוך/ללא קוד מגיעות עם א סט ייחודי של אתגרי אבטחה, ואופיים הפורה פירושו שהאתגרים הללו הופכים חריפים מהר יותר מאי פעם.
