3 דרכים שמפתחים ללא קוד יכולים לירות בעצמם ב-Foot PlatoBlockchain Data Intelligence. חיפוש אנכי. איי.

3 דרכים שמפתחים ללא קוד יכולים לירות לעצמם ברגל

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

כַּיוֹם, כל פלטפורמת תוכנה כשירות (SaaS) גדולה מגיעה עם חבילה עם יכולות אוטומציה ובניית אפליקציות המיועדות ומשווקות ישירות למשתמשים עסקיים. פלטפורמות SaaS כמו Microsoft 365, Salesforce ו-ServiceNow מוטמעות פלטפורמות ללא קוד/קוד נמוך לתוך ההצעות הקיימות שלהם, ולהציב אותם ישירות בידי המשתמשים העסקיים מבלי לבקש אישור תאגידי. יכולות שפעם היו זמינות רק לצוותי ה-IT והפיתוח זמינות כעת בכל הארגון.

Power Platform, פלטפורמת הקוד הנמוכה של מיקרוסופט, מובנית ב-Office 365 ומהווה דוגמה מצוינת בשל דריסת הרגל החזקה של מיקרוסופט בארגון והקצב שבו היא מאומצת על ידי משתמשים עסקיים. אולי בלי לשים לב, ארגונים מניחים כוח ברמת המפתחים בידיים של יותר אנשים מאי פעם, עם הרבה פחות אבטחה או ידע טכני. מה יכול להשתבש?

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

מצב 1: ספק חדש? פשוט עשה זאת

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

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

צוות שירות הלקוחות המסוים הזה היו מומחי Microsoft Power Platform. במקום לחכות למשאבים או לאישור, הם פשוט המשיכו ובנו את האינטגרציה בעצמם: איסוף נתוני לקוחות משרתי SQL בייצור, העבירו את כולם לשרת FTP שסופק על ידי הספק, והחזרה של נתונים מועשרים משרת ה-FTP ל מאגר הייצור. התהליך כולו בוצע באופן אוטומטי בכל פעם שלקוח חדש נוסף למסד הנתונים. כל זה נעשה באמצעות ממשקי גרירה ושחרור, המתארחים ב-Office 365 ושימוש בחשבונות האישיים שלהם. הרישיון שולם מכיסו, מה שהרחיק את הרכש מהמעגל.

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

מצב 2: אה, האם זה לא נכון לאסוף כרטיסי אשראי?

צוות משאבי אנוש של ספק IT גדול התכונן למסע פרסום של "Give Away" פעם בשנה, שבו עובדים מעודדים לתרום לצדקה האהובה עליהם, כשהחברה משתתפת על ידי התאמה לכל דולר שנתרם על ידי העובדים. הקמפיין של השנה הקודמת נחל הצלחה עצומה, אז הציפיות היו מעל הגג. כדי להניע את הקמפיין ולהקל על תהליכים ידניים, עובד HR יצירתי השתמש ב-Power Platform של מיקרוסופט כדי ליצור אפליקציה שהקלה על התהליך כולו. כדי להירשם, עובד ייכנס לאפליקציה עם החשבון הארגוני שלו, יגיש את סכום התרומה שלו, יבחר ארגון צדקה ויספק את פרטי כרטיס האשראי שלו לתשלום.

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

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

מצב 3: למה אני לא יכול פשוט להשתמש ב-Gmail?

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

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

קהילת Power Platform אפילו התפתחה תבניות שכל משתמש ב-Office 365 יכול לאסוף ולהשתמש בו.

באחריות רבה מגיעה אחריות רבה

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

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

בול זמן:

עוד מ קריאה אפלה