סיכוני פיתוח ללא קוד: אבטחה, ממשל ובקרה

סיכוני פיתוח ללא קוד דורשים תשומת לב משום שצוותים עסקיים יכולים כיום לבנות אפליקציות, טפסים, דוחות ואוטומציות באמצעות פלטפורמות Low-Code, No-Code ו-SaaS (כדוגמאת Base44 ו Loveable) במהירות גבוהה. פיתוח ללא קוד אינו שם נרדף ל-Shadow IT, ואינו בעיית אבטחה מעצם קיומו אך הסיכון מתחיל כאשר הארגון אינו יודע מה נבנה, באיזה מידע הוא משתמש, למי יש גישה, מי רשאי לשנות את הפתרון ומי אחראי עליו לאורך זמן.

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

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

פיתוח ללא קוד הוא דרך עבודה לגיטימית, לא Shadow IT

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

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

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

מלאי פתרונות הוא תנאי לניהול, לא טופס מיותר

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

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

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

ניהול מידע צריך לעקוב אחרי זרימת המידע

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

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

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

הרשאות מינימליות נוגעות לאנשים, לאפליקציות ולחיבורים

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

עקרון ההרשאה המינימלית (PoLP) צריך לחול בכמה שכבות:

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

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

מחברים (plugins), APIs וSecrets דורשים שכבת בקרה משלהם

מחברים (plugins) הם הסיבה לכך שפלטפורמות Low-Code שימושיות כל כך: הם הופכים תהליך עסקי לפעולה בין שירותי SaaS, מערכות ארגוניות ו-API אבל הם גם פותחים נתיבים שבהם מידע יכול לעבור ופעולות יכולות להתבצע. לכן מחבר הוא אינטגרציה לכל דבר, ולא פרט תצורה שולי – ההרשאות שלו, היקף המידע, היעד, הבעלות והיכולת לבקר אותו כולם חשובים.

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

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

ההרשאה צריכה להתאים לפעולה העסקית

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

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

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

לוגים הופכים נראות לאחריות

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

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

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

אוטומציה מבוססת AI מעלה את רף הבקרה

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

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

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

בדיקה ושינוי הם חלק ממחזור החיים

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

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

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

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

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

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

מסלול בטוח שמאפשר עבודה

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

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

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