هویتهای غیرانسانی به بزرگترین سطح حمله مدیریتنشده در امنیت ابر تبدیل شدهاند

در یک محیط ابری سازمانی معمولی امروز، هویتهای ماشینی — حسابهای سرویس، کلیدهای API، توکنهای OAuth، اعتبارنامههای CI/CD و هویتهای workload — با نسبتی بین ۴۵ به ۱ تا ۹۰ به ۱ از حسابهای کاربری انسانی بیشتر هستند. تیمهای امنیتی دو دهه را صرف ساختن مدیریت هویت و دسترسی حول محور انسانها کردهاند: ورود، خروج، احراز هویت چندمرحلهای، بازبینی دورهای دسترسی. تقریباً هیچکدام از این زیرساختها برای ماشینها ساخته نشده است و این موضوع کاملاً آشکار است. هویتهای غیرانسانی (NHI) بیسروصدا به بزرگترین سطح حمله مدیریتنشده در امنیت ابر تبدیل شدهاند و بیشتر سازمانها نمیتوانند به یک سؤال اساسی پاسخ دهند: چند اعتبارنامه ماشینی در محیط آنها وجود دارد، مالک هر کدام چه کسی یا چه چیزی است و آخرین بار چه زمانی استفاده شده است.

چرا IAM سنتی ماشینها را پوشش نمیدهد

حاکمیت هویت انسانی بر فرضهایی استوار است که برای ماشینها صادق نیست. یک فرد مدیری دارد که میتواند نیاز مستمر به دسترسی را تأیید کند. یک فرد هنگام خروج، مصاحبه خروج و چکلیست ترک سازمان دارد. درخواست دسترسی یک فرد از چرخه بازبینی عبور میکند. حسابهای سرویس، در مقابل، اغلب بهصورت موردی توسط توسعهدهندهای ساخته میشوند که یک میکروسرویس جدید را راهاندازی میکند؛ به آنها مجوزهای گسترده داده میشود تا از خطاهای مجوز در آینده جلوگیری شود و سپس هرگز بازبینی نمیشوند. اعتبارنامه از پروژه، از توسعهدهندهای که آن را ساخته و اغلب از دلیل اولیه وجودش بیشتر عمر میکند. این الگو را در هر Pipeline مربوط به CI/CD، هر یکپارچهسازی SaaS شخص ثالث و هر سرویس داخلی که به سرویس داخلی دیگری فراخوانی میدهد ضرب کنید و مسئله موجودی به مسئلهای عظیم تبدیل میشود.

اعتبارنامههای ماشینی چگونه واقعاً نفوذ میکنند

الگوهای نفوذ در گزارشهای حوادث بهطرز چشمگیری یکسان هستند. کلیدهای API با عمر طولانی توسط توسعهدهندگانی که فراموش میکنند آنها را به فایل .gitignore اضافه کنند، در مخازن عمومی GitHub منتشر میشوند — اسکنرهای خودکار این کلیدها را در عرض چند دقیقه پس از افشا پیدا و بهرهبرداری میکنند. حسابهای سرویس با مجوز بیش از حد، که به این دلیل دسترسی سطح مدیر گرفتهاند که سریعتر از تنظیم دقیق مجوزها بوده، یک اعتبارنامه در معرض خطر را به دسترسی کامل به محیط تبدیل میکنند. توکنهای OAuth قدیمی از یک یکپارچهسازی SaaS که هجده ماه پیش از رده خارج شده، همچنان معتبر هستند چون هیچکس آنها را باطل نکرده است. و در محیطهای cloud-native، هویتهای workload که باید کوتاهعمر و محدود به یک Pod یا تابع خاص باشند، در عوض بهصورت اسرار ایستا و بلندمدت در تصاویر کانتینر جاسازی میشوند.

هیچکدام از اینها تکنیکهای حمله عجیب و غریب نیستند. آنها شکستهای بهداشتی پایه در مقیاس بزرگ هستند و مهاجمان این را میدانند. حملات مبتنی بر اعتبارنامه به هویتهای ماشینی به یکی از مطمئنترین بردارهای دسترسی اولیه تبدیل شدهاند، دقیقاً به این دلیل که ابزارهای دفاعی که میتوانند ورود مشکوک انسانی را شناسایی کنند — موقعیت جغرافیایی غیرعادی، زمان دسترسی غیرمعمول، اثر انگشت دستگاه — اغلب بهطور تمیز برای اسکریپتی که ساعت ۳ صبح از یک مرکز داده به API فراخوانی میدهد کاربرد ندارند؛ این رفتار کاملاً طبیعی برای ماشین است.

چه چیزی واقعاً در حال تغییر است

دسته جدیدی از ابزارهای امنیتی دقیقاً برای پر کردن این شکاف ظهور کرده است. فروشندگانی مانند Astrix Security، Entro، Oasis Security و Token Security محصولاتی ساختهاند که NHIها را در محیطهای ابری و SaaS کشف، فهرستبندی و پایش میکنند — کاری که ابزارهای IAM عمومی هرگز برای آن طراحی نشده بودند. این پلتفرمها معمولاً با ساختن یک فهرست جامع شروع میکنند — چیزی که بیشتر سازمانها هرگز نداشتهاند — سپس امتیازدهی ریسک بر اساس سطح مجوز، سن اعتبارنامه و الگوهای استفاده را اضافه میکنند و در نهایت اصلاح خودکار مانند چرخش اعتبارنامه یا محدودسازی دسترسی را انجام میدهند.

ارائهدهندگان ابر نیز در این زمینه حرکت کردهاند. AWS، Google Cloud و Azure همگی اکنون workload identity federation ارائه میدهند که به یک سرویس اجازه میدهد با توکنهای کوتاهعمر و چرخش خودکار که به هویت زمان اجرای واقعی آن متصل هستند، احراز هویت کند — نه با یک کلید ایستا و بلندمدت. این کار یک دسته کامل از ریسک — یعنی اعتبارنامه ایستای لو رفته — را بهصورت طراحی حذف میکند، اما پذیرش آن نیازمند معماری مجدد یکپارچهسازیهای موجود است؛ به همین دلیل مهاجرت با وجود در دسترس بودن ابزارها برای چندین سال، کند بوده است.

تیمهای امنیتی واقعاً چه باید بکنند

با کشف شروع کنید، نه با اصلاح. نمیتوانید چیزی را که نمیبینید امن کنید و بیشتر سازمانها تعداد NHIهای خود را تا یک مرتبه بزرگی دستکم میگیرند تا زمانی که یک اسکن واقعی در حسابهای ابری، کنسولهای مدیریت SaaS، سیستمهای CI/CD و مخازن کد منبع اجرا کنند. پس از داشتن فهرست، بر اساس شعاع انفجار اولویتبندی کنید: اعتبارنامهای با دسترسی سطح مدیر به ابر مهمتر از کلید API فقطخواندنی برای یک ابزار داخلی با حساسیت پایین است، صرفنظر از اینکه کدامیک قدیمیتر یا بیشتر دیده میشود.

هر جا که پلتفرم پشتیبانی میکند به اعتبارنامههای کوتاهعمر مهاجرت کنید — workload identity federation برای احراز هویت ابربهابر، توکنهای OIDC برای Pipelineهای CI/CD بهجای اسرار ایستا که در تنظیمات Pipeline ذخیره شدهاند. برای اعتبارنامههایی که باید بلندمدت بمانند، چرخش را در یک برنامه زمانی ثابت اعمال کنید بهجای اینکه به یادداشتن کسی بهصورت دستی تکیه کنید و تاریخ انقضا را بهعنوان پیشفرض تعیین کنید، نه استثنا. در نهایت، مالکیت تعیین کنید. هر اعتبارنامه ماشینی باید به یک انسان یا تیم مسئول نگاشت شود، همانطور که هر حساب انسانی به یک کارمند نگاشت میشود. اعتبارنامه بدون مالک، اعتبارنامهای است که هیچکس متوجه قدیمی شدن آن نمیشود، برای استفاده مشکوک علامتگذاری نمیشود یا به فکر باطل کردن آن نمیافتد وقتی سیستمی که به آن خدمت میکند از رده خارج میشود — و این دقیقاً همان شکافی است که مهاجمان در حال حاضر در مقیاس بزرگ از آن بهرهبرداری میکنند.