כל פלטפורמה אומרת שהיא מתייחסת ברצינות לאבטחה. אף אחד לא אומר את זה גם בפוסט-מורטם של פריצה — זה הרגע שבו הם סוף סוף מתארים את הארכיטקטורה במקום את שמות התואר. אז בואו נדלג ישר לארכיטקטורה. הדרך הכי פשוטה להסביר בידוד דיירים היא לעבור על שלוש הדרכים שבהן צוותים בדרך כלל טועים בכך, ומה נשבר כשזה קורה.
טעות ראשונה: סינון לפי מזהה דייר בקוד האפליקציה
זו ברירת המחדל כי זה הדבר המובן מאליו לכתוב: כל שאילתה מקבלת סעיף WHERE user_id = ? , וכל עוד כל מפתח זוכר את זה, כל בקשה נשארת בתוך החומות שלה. ההרס מופיע מאוחר יותר, כשלבסיס הקוד יש ארבע מאות נקודות קצה במקום ארבע. מישהו מוסיף שאילתת דיווח שמצרפת שתי טבלאות ושוכח את הסינון על הטבלה השנייה. מישהו אחר בונה כלי ניהול "רק לשימוש פנימי" ששולף נתונים בלי שום הגבלת דיירים כלל, כי זה הרגיש בטוח באותו רגע. אף אחת מהטעויות האלה לא מפעילה בדיקה, כי השאילתה עדיין מחזירה שורות תקינות — רק שורות תקינות של הדייר הלא נכון.
אנחנו לא מסתמכים על כך שכל שאילתה תזכור לבקש בנימוס. אבטחת רמת שורה נאכפת בשכבת מסד הנתונים, כך שמסד הנתונים עצמו מסרב להחזיר שורות של דייר אחר, ללא קשר למה שהקוד הקורא ביקש. אין גם עקיפה מיוחסת שיושבת בנתיב הבקשה — המדיניות חלה תמיד, כולל בנתיבים שהיינו מתפתים להתייחס אליהם כאמינים.
טעות שנייה: להתייחס לסביבת הבידוד כאופטימיזציה, לא כגבול
סוכנים כאן מריצים קוד אמיתי — זו כל המהות של המוצר — והפיתוי הוא להריץ את הקוד הזה במקום נוח ולנעול אותו "כשנגיע לזה". ההרס בגרסה הזו נראה כמו תלות פגומה שנמשכת במהלך בנייה ופונה לאינטרנט הפתוח, או הרצת סוכן של דייר אחד שקוראת קבצים ששייכים לסביבת עבודה שהוא מעולם לא היה אמור לראות, כי מערכת הקבצים הייתה משותפת כברירת מחדל ומוגבלת רק כחריג.
עומסי העבודה של הסוכנים רצים במקום זאת בסביבות מבודדות:
- מערכות קבצים נעולות.
- יציאת רשת שהיא רשימת היתרים ולא דלת פתוחה.
סוכן שעובד על הבנייה שלכם רואה את סביבת העבודה שלכם, ותו לא. קוד לא מהימן — כולל בניות של האפליקציה שלכם עצמכם — מתקמפל בתוך קונטיינרים שבהם הבידוד מבני, לא הגדרה שמישהו זוכר להפעיל.
טעות שלישית: למסור את האישורים לסוכן
זו הטעות העדינה ביותר, וזו שלדעתי תופסת הכי הרבה צוותים לא מוכנים. אם הסוכן צריך לפרוס לשרת שלכם או לפרסם לחנות שלכם, הדרך הקצרה ביותר היא לשים את אסימון ה-OAuth או מפתח ה-SSH בהקשר שלו ולתת לו להשתמש בהם. זו גם הדרך הקצרה ביותר לאסון: הוראה שהוזרקה דרך פרומפט, פעולה שהוזתה, אישור גישה שמסתיים בלוג תמלול איפשהו שהוא לא אמור להיות בו. הסוכן לא צריך להיות זדוני כדי שזה ישתבש — הוא רק צריך לטעות פעם אחת, כשמפתחות אמיתיים בידיו.
אז הסוכן אף פעם לא מחזיק את המפתחות. אישורי גישה מחוברים נשמרים בהיקף מוגבל לדייר שלכם ומשמשים רק לפעולה שאליה חיברתם אותם:
- חשבונות חנות
- אסימוני OAuth לרשתות חברתיות
- מפתחות פריסה
- חשבונות שירות של Google
כאשר סוכן צריך לפרוס או להעלות, הוא מבקש מהפלטפורמה לעשות זאת; הפלטפורמה מחזיקה את האישור ומבצעת את הפעולה. הסוכן אף פעם לא רואה את הסוד שהוא מבקש להשתמש בו. ובצד האנליטיקה, שבו נכסי Google לפעמים משותפים בין אתרים, כל משיכה מ-GA4 מסוננת לפי שם מארח כך שהדשבורד שלכם לא יכול בטעות להציג את המספרים של מישהו אחר, גם כשהנכס הבסיסי אוסף נתונים עבור דומיינים רבים.
מה שבאמת נבדק לפני שמשהו יוצא לאוויר
שני כללים חלים בכל מקום בפלטפורמה הזו, והם הכי חשובים דווקא כאן:
- סוכנים לא יכולים להוציא את הכסף שלכם.
- סוכנים לא יכולים לפרסם בשמכם.
שני אלה דורשים לחיצה מכם. זה אומר שהיום הכי גרוע שיכול לקרות לכל רכיב אוטומטי עדיין לא נוגע בארנק שלכם או במוניטין שלכם — רדיוס הפגיעה מוגבל בתכנון, לא בשיקול הדעת הטוב של הסוכן. פרטים מלאים על שמירה ומחיקה נמצאים במדיניות הפרטיות; בקשות מחיקה נכנסות לתוקף תוך 30 יום.
