۸۸٪ مدیران فناوری: سرعت استقرار هوش مصنوعی از زیرساخت‌های امنیتی پیشی گرفته است

اگر امروز به عامل‌های هوش مصنوعی اجازه می‌دهید به جای شما تصمیم بگیرند، احتمالاً یک بمب ساعتی امنیتی در زیرساخت خود کاشته‌اید. طبق گزارش ۲۰۲۶ «وضعیت هوش مصنوعی و هویت» از شرکت FusionAuth، ۸۸٪ مدیران فناوری اعتراف می‌کنند که سرعت استقرار هوش مصنوعی در حال حاضر از زیرساخت‌های امنیتی و مدیریت هویت آن‌ها پیشی گرفته است. این شکاف یک آسیب‌پذیری بحرانی ایجاد می‌کند؛ در حالی که انسان‌ها با سرعت طبیعی عمل می‌کنند، عامل‌های هوش مصنوعی (AI Agents) — شبیه دستیارهای دیجیتالی که می‌توانند به‌جای شما ابزارها را اجرا کنند — قادرند دسترسی‌های گسترده را هزاران بار در ثانیه به کار بگیرند.

امنیت هویت به‌طور تاریخی برای انسان‌هایی طراحی شده که کلیک می‌کنند، تایپ می‌کنند، لحظه‌ای فکر می‌کنند و در نهایت می‌خوابند. این محدودیت‌های انسانی، سقفی طبیعی برای سرعت استفاده از دسترسی‌ها ایجاد می‌کرد. اما عامل‌های هوش مصنوعی این محدودیت‌های سرعت طبیعی را از بین می‌برند. آن‌ها می‌توانند به‌صورت مداوم فعال باشند، APIها را فراخوانی کنند، به سرویس‌های مختلف دسترسی پیدا کنند و با سایر عامل‌ها و سرورهای مجوز تعامل داشته باشند.

از آنجا که عامل‌ها از اختیارات تفویض‌شده هزاران بار سریع‌تر از شخصی که این اختیارات را به آن‌ها داده است استفاده می‌کنند، مجوزی که حتی کمی بیش از حد گسترده باشد، ممکن است توسط یک انسان در طول یک روز کاری تنها چند بار استفاده شود و خطری ایجاد نکند. اما یک سیستم خودکار می‌تواند همان نقطه ضعف را بارها و بارها با سرعت ماشین هدف قرار دهد. این تغییر به این معناست که کنترل‌های امنیتی دیگر نمی‌توانند صرفاً بر پایه سیاست‌های متنی (Policy) باشند، بلکه باید در تار و پود معماری سیستم تنیده شوند. این خطر زمانی جدی‌تر می‌شود که نظارت انسانی بر خروجی‌های این عامل‌ها ضعیف باشد؛ چنان‌که بررسی‌های اخیر نشان می‌دهد یک‌سوم دستورات خطرناک عامل‌های کدنویس حتی با تایید برنامه‌نویسان اجرا می‌شوند، که لزوم سخت‌گیرانه‌تر کردن لایه‌های مجوز را دوچندان می‌کند.

شکاف احتمالی در برابر قطعیت

هوش مصنوعی ماهیتی احتمالی (Probabilistic) دارد؛ به این معنا که یک مدل ممکن است ۸۷٪ مطمئن باشد که منظور شما چه بوده است یا چه اقدامی را باید انجام دهد. اما مجوز دسترسی (Authorization) باید کاملاً قطعی (Deterministic) باشد. یک سامانه هویت نمی‌تواند «تقریباً مطمئن» باشد یا با ۸۷٪ اطمینان بگوید که یک عامل اجازه دسترسی به پایگاه داده مشتریان را دارد یا خیر.

عامل می‌تواند تصمیم بگیرد که اقدام بعدی‌اش چه باشد، اما این «هویت» است که تعیین می‌کند آیا او اجازه انجام آن کار را دارد یا نه. این اختیار در اصل متعلق به یک شخص یا سازمان است. اگر انسانی به یک عامل اجازه می‌دهد به‌نام او عمل کند، استقلال و خودمختاری عامل نباید باعث گسترش اختیارات تفویض‌شده به او شود.

برای حل این مسئله، FusionAuth نسخه ۱.۶۹ را منتشر کرد تا در معماری‌های عامل‌محور قطعیت ایجاد کند. این به‌روزرسانی به پرسش‌های بنیادین امنیتی پاسخ می‌دهد: چه کسی یا چه چیزی درخواست دسترسی داده است؟ آن‌ها از اختیارات چه کسی استفاده می‌کنند؟ به چه چیزهایی اجازه دسترسی دارند و تحت چه شرایطی؟ این مجوز از کجا صادر شده است و آیا تغییرات آن قابل ردیابی است؟

سخت‌سازی لایه کنترل

نسخه ۱.۶۹ لایه کنترل هویت را با افزودن شناسایی صادرکننده، کنترل شدیدتر روی کلیدهای رمزنگاری مورد اعتماد، دید بهتر نسبت به هویت‌های غیرانسانی و تسهیل استفاده از توکن‌های دسترسی محدود به فرستنده تقویت کرده است. این مکانیزم‌ها شکاف امنیتی را از چندین مسیر می‌بندند:

• شناسایی صادرکننده (RFC 9207): در معماری‌های مدرن اغلب چندین سرور مجوز وجود دارد. حملات «ترکیب سرور مجوز» (Authorization Server Mix-up Attack) زمانی رخ می‌دهد که یک کلاینت جریان احراز هویت را با یک سرور شروع می‌کند اما پاسخ سرور دیگری را می‌پذیرد. FusionAuth 1.69 پشتیبانی از RFC 9207 (شناسایی صادرکننده سرور مجوز OAuth 2.0) را اضافه کرده و آن را به‌صورت پیش‌فرض فعال نموده است. با این کار، این شرکت به تنها ارائه‌دهنده تجاری CIAM تبدیل شده که این قابلیت را دارد. این ویژگی به کلاینت اجازه می‌دهد به‌جای فرض کردن، هویت سروری که پاسخ را صادر کرده است تأیید کند.
• انتخاب کلید تأیید امضا: تأیید امضای JWT تضمین می‌کند که توکن توسط یک کلید مورد اعتماد امضا شده است. اگر برنامه‌ای تنها به دو کلید نیاز داشته باشد اما هر توکنی را که توسط هر یک از ۲۰ کلید موجود امضا شده باشد بپذیرد، در واقع ۱۸ رابطه اعتماد غیرضروری ایجاد کرده است. نسخه ۱.۶۹ به برنامه‌ها اجازه می‌دهد به‌طور صریح کنترل کنند که هنگام تأیید امضاهای JWT، کدام کلیدها را بپذیرند و بدین ترتیب محدوده تأیید را دقیقاً به کلیدهای پیکربندی‌شده محدود کنند.
• نوع موجودیت عامل هوش مصنوعی: برای افزایش دید نسبت به هویت‌های غیرانسانی، سیستم اکنون به‌طور صریح عامل‌های AI را از سایر موجودات غیرانسانی تفکیک می‌کند. همچنین وب‌هوک‌های چرخه حیات موجودیت (Entity lifecycle webhooks) برای رویدادهای ایجاد، به‌روزرسانی و حذف اضافه شده است. این قابلیت به سیستم‌های امنیتی و حسابرسی اجازه می‌دهد دقیقاً ردیابی کنند که یک عامل هوش مصنوعی چه زمانی ظاهر شده، چه زمانی پیکربندی‌اش تغییر کرده و چه زمانی حذف شده است.
• توکن‌های محدود به فرستنده (DPoP): توکن‌های حامل (Bearer Tokens) استاندارد مانند پول نقد عمل می‌کنند؛ هر کسی آن‌ها را در اختیار داشته باشد می‌تواند استفاده کند. اگر این توکن‌ها از مرورگر دزدیده شوند، هر مهاجمی می‌تواند آن‌ها را مجدداً ارسال (Replay) کند. استاندارد DPoP (اثبات مالکیت) توکن‌های دسترسی را به‌صورت رمزنگاری‌شده به کلاینتی که آن‌ها را درخواست کرده است گره می‌زند. کلاینت باید در هر درخواست، مالکیت کلید خصوصی خود را اثبات کند. در حالی که FusionAuth از نسخه ۱.۶۳ در سمت سرور از DPoP پشتیبانی می‌کرد، پشتیبانی از SDKهای React، Angular و Vue در ۵ اوت ۲۰۲۶ منتشر شد. این امر DPoP را برای برنامه‌های مرورگر بومی کرد بدون اینکه نیازی به پیاده‌سازی دستی رمزنگاری JOSE باشد.

بهداشت امنیتی و زیرساخت

علاوه بر ابزارهای تخصصی AI، به‌روزرسانی ۱.۶۹ به مسائل «کسل‌کننده» اما ضروری در بهداشت امنیتی می‌پردازد. برخی از حیاتی‌ترین کارها در پشت صحنه انجام شده است تا تضمین شود که پلتفرم با تغییر شیوه‌های رمزنگاری و رشد الزامات حسابرسی، تاب‌آور باقی می‌ماند.

به‌روزرسانی‌های اخیر شامل موارد زیر است:

• افزایش انعطاف‌پذیری در پیکربندی SAML
• به‌روزرسانی پشتیبانی از وارد کردن (Import) هش‌های رمز عبور
• بهبود حسابرسی گروه‌ها (Group Auditing)
• به‌روزرسانی وابستگی‌ها و پشتیبانی از زمان اجرا (Runtime)
• اصلاحات امنیتی کلی در سراسر پلتفرم

از آنجا که کنترل‌های هویت، دسترسی به کاربران، برنامه‌ها، APIها، ماشین‌ها، سرویس‌ها، داده‌ها و عامل‌های هوش مصنوعی را مدیریت می‌کنند، به‌روز نگه داشتن وابستگی‌ها و زمان‌های اجرا یک دفاع اولیه و اساسی است. برای کسانی که از ارائه‌دهندگان هویت خارجی JWT یا SAML یا چرخش‌های فعال کلید (Key Rotations) استفاده می‌کنند، توصیه می‌شود پیش از ارتقا، «راهنمای مهاجرت ۱.۶۹» را به دلیل سخت‌گیرانه‌تر شدن محدوده کلیدهای تأیید بررسی کنند.

تغییر در مفروضات امنیتی

این به‌روزرسانی نشان‌دهنده تغییری بنیادین در نحوه نگاه ما به هویت‌های غیرانسانی است. ما از دنیای کلیدهای API ایستا به دنیای اختیارات پویا و تفویض‌شده‌ای می‌رویم که باید به‌صورت لحظه‌ای نظارت شوند. اصول بنیادین امنیت — یعنی دانستن اینکه چه کسی عمل می‌کند، برای چه کسی عمل می‌کند و اجازه انجام چه کاری را دارد — ثابت مانده‌اند، اما هوش مصنوعی عملاً «محدودیت سرعت» را برای تست این قوانین از بین برده است.

برای متخصصان، این بدان معناست که اصل «حداقل دسترسی» (Least Privilege) دیگر صرفاً یک «بهترین روش» (Best Practice) نیست، بلکه یک شرط بقاست. خطایی در تعریف مجوز که برای یک کارمند انسانی تنها یک مزاحمت کوچک بود، وقتی به یک عامل خودکار که با سرعت ماشین عمل می‌کند سپرده شود، به یک آسیب‌پذیری فاجعه‌بار تبدیل می‌شود.

با افزایش توانمندی عامل‌ها و رشد حجم اختیارات تفویض‌شده، فشار بر زیرساخت‌های هویتی که برای سرعت انسان طراحی شده‌اند، بیشتر خواهد شد. هدف این است که تضمین کنیم در حالی که هوشِ عامل‌ها احتمالی است، مرزهای دسترسی آن‌ها مطلق باقی بماند.

برای ایمن‌سازی استک فعلی خود، مجوزهای تفویض‌شده موجود را بازبینی کنید و ارزیابی کنید که آیا ارائه‌دهنده هویت شما از توکن‌های محدود به فرستنده مانند DPoP پشتیبانی می‌کند یا خیر.

گام بعدی شما

• مجوزهای تفویض‌شده فعلی در سیستم خود را بازبینی کنید و هر دسترسی گسترده‌ای را به حداقل برسانید.
• بررسی کنید آیا ارائه‌دهنده هویت شما از توکن‌های محدود به فرستنده مانند DPoP پشتیبانی می‌کند یا خیر.
• برای هویت‌های غیرانسانی، سیستم مانیتورینگ لحظه‌ای جایگزین بررسی‌های دوره‌ای کنید.

اما تأمین سخت‌افزاری این لایه‌های امنیتی در مقیاس بالا چالش‌های جدیدی ایجاد می‌کند — به تحلیل ما درباره‌ی بهینه‌سازی استنتاج در مراکز داده مراجعه کنید.