הגנה בתוך החומות: DevSecOps בסביבות On Premises

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

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

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

אבל יש עולם שלם שבו כל זה פשוט לא עובד.

ארגונים ביטחוניים, תעשיות רגישות, וגופים תחת רגולציה כבדה פועלים בסביבות מבודדות (Air-Gapped) — ללא גישה לאינטרנט, ללא שירותי SaaS, ולרוב עם מגבלות תפעוליות מחמירות.

האם זה אומר ש־DevSecOps לא רלוונטי שם? ממש לא.

זה פשוט אומר שצריך לבנות אותו אחרת לגמרי.

המסר ברור: DevSecOps הוא לא פריבילגיה של הענן,
 הוא המתודולוגיה היחידה שתאפשר לסביבות Air Gapped לשרוד בעולם של איומים משתנים.

גישת ה-DevSecOps הקלאסית לא צלחה בסביבות המבודדות, רוב פתרונות האבטחה יוצאים מתוך נקודת הנחה בסיסית, קיים קישור לאינטרנט, הם נשענים על ספריות ציבוריות, שירותי SaaS כאלו ואחרים, עדכוני CVE בזמן אמת, API, מנגנוני AI ועוד ועוד, אך כשנסתכל על הסביבה המבודדת, הנחות היסוד צריכות להיות אחרות לחלוטין, מסיבות שונות כמו העובדה שאין גישה לספריות ציבוריות למשל Docker Hub, אין PULL ל-pip או nmp אין עדכון חולשות אוטומטי, אין SaaS שרלוונטי לאותן סביבות.

התוצאה לרוב תהיה “העתקה” משיטת ה-DevSecOps הרווחת בענן וזה פשוט נשבר.

האתגרים האמיתיים איתם נפגשים אותם ארגונים עם סביבה סגורה הם:

1. ניהול Dependencies בלי אינטרנט, איך מנהלים חבילות כשאין גישה למערכת ניהול חבילות סטנדרטית (PIP, nmp)? הפתרונות יהיו בדרכ תלויים ברכיבים רבים והארכת זמן פיתוח ובדר”כ יהיו:
   1. הקמת Artifacts Repositories פנימיים שמתעדכנים ידנית.
   2. יצרת Mirror עם מיליון ואחת הקשחות בדרך.
   3. סביבת Sandbox, אזור ביניים לבצע בדיקות לפני הכנסה לסביבת הייצור.
2. ניהול פגיעויות (Vulnerabilities) ו-Patching, אין עדכון אוטומטי של CVE לעומת סביבת הענן, שם עדכוני אבטחה קורים לעיתים מספר פעמים ביום. אז מה עושים:
   1. מייבאים בצורה מבוקרת.
   2. שומרים SnapShots של DB ואבטחה.
   3. מבצעים סריקות Offline על images וחבילות קוד.

האתגר, אין דבר שמבטיח לנו את התיישנות המידע שברשת

3. CI\CD מנותק, אין GitHub Action, מה כן:
   1. GitLab / Jenkins on-prem
   2. pipelines שמבוססים על artifacts מקומיים בלבד
4. אין ניהול מוסדר של secrets Online, פתרונות נפוצים:
   1. כספות On-Prem
   2. שימוש ב- K8s Secrets עם הצפנה
   3. הפרדה מוחלטת בין סביבות.

טעות קריטית: שמירת secrets בתוך קוד או pipeline variables בלי הצפנה.

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

מה עובד בפועל? הארכיטקטורה של המחר. לבנות מרחב טכנולוגי מקצה לקצה:

1. תהליך Pipeline פנימי מקצה לקצה, הכל בתוך הרשת: Build, test, scan, deploy, בלי תלות חיצונית אחת.
2. Single source – artifacts repository

הכל עובר דרך repository פנימי: image, Packages, Binaries, כל Pull מתבצע מול אותו repository.

3. סריקות אבטחה Offline

כלים כמו סורקים ל-containers, SAST\DAST מקומיים (בדיקות אבטחת יישומים סטטיות ודינמיות לאפליקציה), policy engines

כולם עובדים עם DB פנימי שמתעדכן בצורה מבוקרת.

4. אוטומציה, באותו קונספט אבל סגור: ללא APIs חיצוניים, עם Logs מלאים ו-audit.
5. שילוב AI בצורה מאובטחת
   אחד הנושאים הכי מעניינים היום, אבל איך עושים את זה בלי גישה לאינטרנט?

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