תיקון בהסכמה: לתקן בלי לחצות גבול

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

האנטומיה של הצעת-תיקון

כל בעיה ניתנת-לתיקון לא מופעלת מעצמה — היא מוצעת. האופרטור רואה שלושה כפתורים: אשר / תקן, לא עכשיו, התעלם. הקשה על אשר שולחת פעולה ממודלת ומ-allow-list — לא פקודת-shell שרירותית — ואז המערכת מאמתת מחדש את המצב ומריצה את הלולאה שוב עד שהבעיה נפתרה או נדחתה. אין "תקן הכול בלחיצה" שרץ באפלה; יש שרשרת קצרה של הצעה → אישור → פעולה → אימות.

למה אין shell חופשי — מודל-האמון

הסוד הוא בכך שהפעולות אינן "הרץ את הפקודה הזו". פעולות מול שרת נשלחות מעל ערוץ-שליטה חתום ומקובע-TOFU (Trust On First Use): הצורה הקנונית של הפקודה נחתמת, כך ששחזור (replay) או שיבוש מזוהים מיד. אין shell חופשי — קיימות רק פעולות מרשימה-לבנה בשמן המפורש. המשמעות המעשית: גם אם ענן או מסד-נתונים נפרצו, תוקף לא יכול לזייף פקודה ולהפוך אותה ל-RCE על הצי. הגבול בין "לזהות" ל"להריץ קוד על מכשיר" נשמר בקנאות.

אירוע קריטי → כפתור-הכלה

התיקון-בהסכמה מתחבר ישירות למנוע האירועים. כשמנוע ה-SIEM-lite מקפל התראות מרובות לאירוע מתואם בחומרה high/critical, הוא מציע אוטומטית כפתור הכלה (containment). אישור הכפתור פועל מעל אותו ערוץ-שליטה חתום — אותו מודל-אמון, אותה רשימה-לבנה, אותו audit. כך שרשרת-המתקפה לא רק מזוהה ומתויגת — היא מקבלת פעולת-תגובה הפיכה במרחק הקשה אחת.

למה זה קריטי לעסק קטן

עסק קטן לרוב אין לו מהנדס-אבטחה במשרה מלאה. תיקון-בהסכמה נותן לבעל-עסק לא-מומחה כפתור "תקן את זה" בטוח — עם תיעוד מלא — במקום להזדקק ל-SOC יקר. וכשמדובר במשהו בעל-משמעות, האדם נשאר בלולאה; בהמשך אפשר לגדר את זה גם במדיניות עם אישור-2FA (push-approval) כך שרק אחרי אימות פעולה מסוכנת יוצאת לדרך.

← חזרה לבלוג · איך זה עובד →