در بسیاری از زیرساخت‌ها، حساب‌های سرویس (Service Accounts) با چالش‌های امنیتی جدی روبرو هستند. اغلب، مهندسانی که این حساب‌ها را ایجاد کرده‌اند سال‌ها پیش سازمان را ترک کرده‌اند، اما رمز عبور آن‌ها همچنان در یک Vault یا حتی در فایل‌های پیکربندی (Config Files) ساده باقی مانده است. این حساب‌ها معمولاً دارای مجوزهای گسترده‌ای هستند که برای پروژه‌های قدیمی تعریف شده‌اند و تیم‌های فعلی به دلیل ترس از از کار افتادن سیستم، از تغییر یا محدود کردن آن‌ها خودداری می‌کنند.
طبق بررسی Palo Alto Networks، به ازای هر هویت انسانی، به طور میانگین ۱۰۹ هویت ماشینی (Machine Identity) در سازمان‌ها وجود دارد. نکته نگران‌کننده این است که ۶۱٪ از درخواست‌های دسترسی سطح بالا (Privileged Access) همچنان با مدل Standing Privilege (دسترسی دائمی) انجام می‌شود، به جای اینکه دسترسی‌ها به صورت On-demand (در لحظه نیاز) اعطا شوند. همچنین، نزدیک به نیمی از این هویت‌ها بیش از یک سال قدمت دارند که ریسک امنیتی را افزایش می‌دهد.
استفاده از Vault و چرخش رمز عبور (Password Rotation) گام مثبتی است، اما این روش تنها رمز را تغییر می‌دهد، در حالی که سطح دسترسی (Permissions) ثابت باقی می‌ماند. اگر یک عامل تهدید (Threat Actor) بتواند این اعتبارنامه را سرقت کند، می‌تواند برای مدت طولانی از آن استفاده کند. این مشکل در مورد ادغام‌های OAuth نیز وجود دارد؛ چرا که یک Refresh Token می‌تواند تا مدت‌ها به خود بازسازی شود و دسترسی مهاجم را حفظ کند.
یک نمونه بارز، کمپین Salesloft Drift در اوت ۲۰۲۵ بود. گروه Google Threat Intelligence گزارش داد که عامل تهدید UNC6395 با استفاده از OAuth و Refresh Tokenهای سرقت شده، توانست به داده‌های مشتریان در Salesforce دسترسی پیدا کند. از آنجایی که این توکن‌ها معتبر بودند، هیچ هشدار MFA (احراز هویت چندعاملی) برای سیستم‌های امنیتی ایجاد نکردند و مهاجم توانست به دنبال توکن‌های دیگر در سیستم‌های مختلف بگردد.
مدل Zero Standing Privilege (ZSP) چیست؟
در مدل Zero Standing Privilege (ZSP)، یک هویت ماشینی در زمان بیکاری هیچ دسترسی قابل استفاده‌ای ندارد. تنها زمانی که نیاز به انجام کاری باشد، هویت خود را به یک موتور سیاست‌گذاری (Policy Engine) اثبات کرده و یک اعتبارنامه کوتاه‌مدت (Short-lived Credential) دریافت می‌کند که پس از اتمام کار، به طور خودکار منقضی می‌شود.
برای رسیدن به این هدف، استفاده از Workload Identity Federation (مانند OIDC در GitHub Actions و AWS) بهترین گزینه است. در این روش، هیچ کلید دسترسی (Access Key) دائمی در مخازن ذخیره نمی‌شود. همچنین، برای سیستم‌های قدیمی‌تر که قابلیت Federation ندارند، می‌توان از Dynamic Secrets در ابزارهایی مانند Vault استفاده کرد تا حساب‌های پایگاه داده تنها در زمان شروع نشست (Session) ایجاد و پس از پایان، حذف شوند.
مدیران ارشد (CIO/CISO) باید با ایجاد یک موجودی (Inventory) دقیق از تمام هویت‌های ماشینی، تعیین یک مالک انسانی (Human Owner) برای هر کدام و محدود کردن Scopeهای دسترسی در اپلیکیشن‌های SaaS، فرآیند کاهش سطح دسترسی‌های دائمی را آغاز کنند.
