کانال‌های اشتراکی، جایگزین احراز هویت نیستند: تحلیل خطرات ایجنت‌های خودکار در محیط‌های همکاری

تصور کنید یک پاسخ‌دهنده به حادثه (Incident Responder) خارجی در یک کانال اشتراکی بنویسد: «نسخه تولید را بازگردانی (Rollback) کن، تمام نشست‌های فعال را باطل کن و به‌روزرسانی حادثه را برای مشتری ارسال کن». در این لحظه، یک مدیر مهندسی با ارسال یک ایموجی تایید (Thumbs-up) موافقت خود را اعلام می‌کند. در همین کانال، مشاوران حقوقی و تامین‌کنندگان خارجی نیز حضور دارند. حالا اگر یک ایجنت (Agent) با استفاده از یک حساب سرویس (Service Account) که دسترسی‌های لازم برای هر سه عملیات را دارد، این دستورات را اجرا کند، سوال این است که این ایجنت در واقع از «اعتبار» و «اختیارات» چه کسی استفاده می‌کند؟

تفاوت بین محیط همکاری و هویت دسترسی

در ادبیات کنترل دسترسی (Access Control)، یک پرینسیپال (Principal) به معنای یک هویت (مانند کاربر، ورک‌لود یا گروه) است که سیستم می‌تواند به آن مجوز (Permission) اختصاص دهد. اما یک کانال (Channel) صرفاً مکانی برای همکاری است. اعضای یک کانال اشتراکی در Slack یا Microsoft Teams، صرفاً به دلیل حضور در یک گفتگو، اختیارات جمعی برای مدیریت محیط تولید (Production) یا پرداخت‌های مالی کسب نمی‌کنند.

خطر اصلی زمانی رخ می‌دهد که سازمان‌ها حضور در یک کانال معمولی را به عنوان مجوز کلی برای استفاده از ابزارهای یک ایجنت در نظر بگیرند. مطابق با معماری صفر-اعتماد (Zero-Trust Architecture) استاندارد NIST، اعتماد ضمنی بر اساس موقعیت شبکه مردود است؛ به همین ترتیب، یک شناسه کانال (Channel ID) نباید به عنوان یک زیرشبکه (Subnet) شرکتی جدید تلقی شود که هر کس در آن است، به طور پیش‌فرض مورد اعتماد است.

تفکیک درخواست از حق اجرا

برای جلوگیری از سوءاستفاده، باید «درخواست انجام کار» را از «حق اجرای آن» جدا کرد. در یک سناریوی امن، اگرچه پاسخ‌دهنده حادثه درخواست را مطرح می‌کند، اما اعتبار لازم باید از طریق نقش تعریف‌شده فرمانده حادثه (Incident Commander) یا یک جریان کاری (Workflow) تایید شده توسط مالک کسب‌وکار تامین شود. ایجنت باید تحت هویت حساب سرویس اجرا شود، اما تصمیم‌گیری نهایی باید بر اساس سیاست‌های دسترسی (Access Policies) باشد، نه صرفاً بر اساس یک واکنش در محیط چت.

مدل‌های دسترسی و خطرات ایجنت‌ها

در مدل دسترسی Microsoft Graph، دسترسی تفویض‌شده (Delegated Access) توسط هر دو عامل یعنی مجوزهای اپلیکیشن و دسترسی کاربر وارد شده محدود می‌شود. اما دسترسی‌های App-only از هویت خود اپلیکیشن استفاده می‌کنند. زمانی که یک گفتگو باعث فعال شدن ایجنتی با مجوزهای گسترده‌تر از کاربر ارسال‌کننده می‌شود، یک مسیر برای دور زدن کنترل‌های امنیتی ایجاد می‌گردد. به عنوان مثال، یک کارمند پشتیبانی ممکن است جریانی را آغاز کند که دسترسی‌های مدیریتی دارد، در حالی که خودش شخصاً این دسترسی‌ها را ندارد.

سه کنترل حیاتی برای عملیات حساس

برای مدیریت ایمن ایجنت‌ها در کانال‌های اشتراکی، سه کنترل زیر ضروری است:

• تایید هویت درخواست‌کننده و منبع اعتبار: بررسی هویت پایدار فرستنده و سازمان متعلق به او. همچنین باید از تازگی درخواست (Freshness) اطمینان حاصل کرد تا از حملات بازپخش (Replay Attack) جلوگیری شود.
• مشخص کردن دقیق عملیات: درخواست‌ها باید به عملیات‌های صریح تبدیل شوند (مثلاً دقیقاً کدام سرویس Rollback شود و کدام نسخه بازگردانده شود). تاییدیه باید به این جزئیات گره بخورد و پس از مدت زمان کوتاهی منقضی شود.
• اجرای مجوزها در لحظه اجرا و افشا: اعتبار باید درست قبل از هر اقدام حساس مجدداً بررسی شود. همچنین، مجوز خواندن اطلاعات نباید به طور خودکار به معنای مجوز انتشار آن برای همه اعضای کانال باشد.

نتیجه‌گیری و تست مرزهای امنیتی

پیش از گسترش استفاده از ایجنت‌ها در کانال‌های اشتراکی، سازمان‌ها باید محیط‌های تست را به چالش بکشند. برای مثال، باید بررسی شود که اگر یک شرکت خارجی درخواستی را ارسال کند که مجاز به آن نیست، سیستم چگونه آن را متوقف می‌کند، یا اگر هدف یک عملیات تایید شده تغییر کند، آیا سیستم مجدداً درخواست تاییدیه می‌کند یا خیر. پاسخ «بات دسترسی داشت» یا «یک نفر در کانال تایید کرد»، پاسخ‌های فنی و امنیتی کافی برای یک حسابرسی (Audit) نیستند.