هر پلتفرمی میگوید امنیت را جدی میگیرد. هیچکس در گزارش پس از نشت اطلاعات هم این را نمیگوید — آن لحظهای است که سرانجام معماری را توضیح میدهند، نه صفتها را. پس بیایید مستقیم برویم سراغ معماری. سادهترین راه برای توضیح ایزولهسازی مستأجران، بررسی سه اشتباه رایج تیمها و نتیجه آنها است.
اشتباه اول: فیلتر کردن بر اساس شناسه مستأجر در کد برنامه
این رویکرد پیشفرض است چون نوشتنش بدیهیترین کار است: هر کوئری یک بند WHERE user_id = ? میگیرد، و تا زمانی که هر توسعهدهندهای آن را به خاطر داشته باشد، هر درخواست در دیوارهای خودش باقی میماند. خرابی بعداً ظاهر میشود، وقتی کدبیس چهارصد endpoint دارد بهجای چهار. یک نفر یک کوئری گزارشگیری اضافه میکند که دو جدول را join میکند و فیلتر روی جدول دوم را فراموش میکند. یک نفر دیگر یک ابزار مدیریتی «فقط برای استفاده داخلی» میسازد که بدون هیچ محدودسازی مستأجری کوئری میزند، چون آنموقع احساس امن بودن میکرد. هیچکدام از این اشتباهات یک تست را فعال نمیکند، چون کوئری همچنان ردیفهای معتبر برمیگرداند — فقط ردیفهای معتبر مستأجر اشتباه.
ما به این اعتماد نمیکنیم که هر کوئری یادش بماند مؤدبانه سؤال کند. امنیت در سطح ردیف در لایه پایگاهداده اجرا میشود، پس خود پایگاهداده از بازگرداندن ردیفهای مستأجر دیگر خودداری میکند، صرفنظر از اینکه کد فراخواننده چه چیزی خواسته است. هیچ دسترسی ویژهای هم در مسیر درخواست وجود ندارد که بتوان از آن عبور کرد — این قاعده همیشه اعمال میشود، حتی در مسیرهایی که وسوسه میشویم آنها را قابلاعتماد فرض کنیم.
اشتباه دوم: رفتار با سندباکس بهعنوان بهینهسازی، نه مرز امنیتی
ایجنتها در اینجا کد واقعی اجرا میکنند — این دقیقاً هدف اصلی محصول است — و راه میانبر وسوسهانگیز این است که آن کد را در جایی راحت اجرا کنیم و بعداً «اگر وقت شد» قفلش را ببندیم. نتیجه این رویکرد میتواند یک وابستگی آسیبپذیر باشد که در حین یک ساخت وارد شده و به اینترنت باز دسترسی دارد، یا اجرای ایجنت یک مستأجر که فایلهای متعلق به فضای کاری دیگری را میخواند که هرگز نباید میدید، چون سیستم فایل بهطور پیشفرض مشترک بوده و محدودیتها استثنا بودند.
بارهای کاری ایجنت بهجای آن در محیطهای ایزوله اجرا میشوند:
- سیستم فایل قفلشده.
- خروجی شبکهای که بهجای درِ باز، فهرست مجاز است.
ایجنتی که روی ساخت شما کار میکند فقط فضای کاری شما را میبیند، همین و تمام. کد غیرقابلاعتماد — حتی ساختهای اپلیکیشن خودتان — درون کانتینرهایی کامپایل میشود که ایزولهسازی در آن ساختاری است، نه تنظیمی که کسی باید یادش بماند روشن کند.
اشتباه سوم: سپردن اعتبارنامهها به ایجنت
این ظریفترین اشتباه است و گمان میکنم بیشترین تیمها را غافلگیر میکند. اگر ایجنت نیاز دارد روی سرور شما مستقر شود یا در فروشگاه شما پست بگذارد، کوتاهترین راه این است که توکن OAuth یا کلید SSH را در محتوای آن قرار دهیم و بگذاریم از آنها استفاده کند. همین کوتاهترین راه به سوی فاجعه هم است: یک دستور تزریقشده از طریق پرامپت، یک اقدام توهمی، اعتبارنامهای که سرانجام در جایی که نباید در یک لاگ گفتگو میماند. لازم نیست ایجنت بدخواه باشد تا این اتفاق بیفتد — کافی است فقط یک بار اشتباه کند، در حالی که کلیدهای واقعی در دست دارد.
به همین دلیل ایجنت هرگز کلیدها را در دست ندارد. اعتبارنامههای متصل با محدوده مستأجر شما ذخیره میشوند و فقط برای همان اقدامی که برای آن متصل کردهاید استفاده میشوند:
- حسابهای فروشگاه
- توکنهای OAuth شبکههای اجتماعی
- کلیدهای استقرار
- حسابهای سرویس گوگل
وقتی ایجنتی لازم است چیزی را مستقر کند یا بارگذاری کند، از پلتفرم میخواهد این کار را انجام دهد؛ پلتفرم اعتبارنامه را نگه میدارد و خود اقدام را انجام میدهد. ایجنت هرگز رمز مخفی را که برای استفادهاش درخواست میدهد نمیبیند. و در بخش تحلیل، جایی که پراپرتیهای گوگل گاهی بین سایتها مشترک هستند، هر فراخوانی GA4 بر اساس نام میزبان فیلتر میشود، تا داشبوردتان سهواً اعداد کسی دیگر را نمایش ندهد، حتی وقتی پراپرتی زیرین برای چند دامنه داده جمعآوری میکند.
چیزی که واقعاً قبل از هر انتشار بررسی میشود
دو قاعده در همهجای این پلتفرم اعمال میشود، و درست همینجا بیشترین اهمیت دارند:
- ایجنتها نمیتوانند پول شما را خرج کنند.
- ایجنتها نمیتوانند به جای شما پست بگذارند.
هر دوی اینها به کلیک شما نیاز دارد. یعنی بدترین روزی که هر جزء خودکار میتواند داشته باشد، باز هم به کیف پول یا اعتبار شما دست نمیزند — دامنه آسیب از طراحی محدود شده، نه با قضاوت خوب ایجنت. جزئیات کامل درباره نگهداری و حذف دادهها در سیاست حفظ حریم خصوصی آمده است؛ درخواستهای حذف ظرف ۳۰ روز اجرا میشوند.
