هویت‌های ماشینی به مسئله واقعی احراز هویت سازمانی تبدیل شده‌اند

اشتراک‌گذاری:
هویت‌های ماشینی به مسئله واقعی احراز هویت سازمانی تبدیل شده‌اند

هویت‌های ماشینی بی‌سروصدا به یکی از سخت‌ترین مسائل احراز هویت در سازمان تبدیل شده‌اند. امنیت ورود کاربران انسانی با MFA قوی‌تر، آگاهی بیشتر و دسترسی مشروط بهتر پیشرفت کرده است، اما تعداد هویت‌های غیرانسانی در ابر، CI/CD، Kubernetes، SaaS، APIها و اتوماسیون داخلی به‌سرعت افزایش یافته است. گواهی‌ها، service accountها، OAuth tokenها، API keyها و workload identityها اکنون سهم بزرگی از اقدامات حساس را احراز هویت می‌کنند.

این مقیاس، مدل امنیتی را عوض می‌کند. احراز هویت انسانی قابل مشاهده و دوره‌ای است، اما احراز هویت ماشینی پیوسته، توزیع‌شده و اغلب در دل تصمیم‌های زیرساختی پنهان است. ریسک اصلی دیگر فقط این نیست که آیا کاربر امن وارد می‌شود یا نه. مسئله این است که آیا هر workload و هر سرویس فقط به همان دسترسی لازم می‌رسد و می‌تواند اعتماد خود را بدون اختلال در تولید بچرخاند.

چرا این مسئله سریع‌تر از حاکمیت رشد کرد

بیشتر برنامه‌های امنیتی حول حساب‌های تعاملی انسان‌ها ساخته شده بودند. معماری cloud-native این فرض را شکست. امروز برنامه‌ها از microserviceهایی تشکیل شده‌اند که مدام با هم حرف می‌زنند. build systemها کد را امضا می‌کنند، image منتشر می‌کنند و استقرار را خودکار جلو می‌برند. هر اتصال در این زنجیره به نوعی هویت ماشینی وابسته است.

مشکل فقط حجم نیست، بلکه تکه‌تکه بودن است. یک تیم از IAM role استفاده می‌کند، تیمی دیگر از service accountهای بلندعمر، و تیمی دیگر از گواهی‌های PKI یا secretهای vault. نتیجه این است که رهبران امنیت با مدل‌های اعتماد پراکنده، مالکیت نامشخص و موجودی ناقص روبه‌رو می‌شوند.

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

اعتبارنامه‌های ماشینی جذاب‌اند چون معمولاً امتیاز بالا و نظارت کم دارند. یک workload token دزدیده‌شده یا service account بیش از حد مجاز می‌تواند مهاجم را آرام از pipelineها، control plane ابری و سرویس‌های تولیدی عبور دهد. اگر سازمان نداند چه هویت‌هایی وجود دارند، به چه چیزی وصل می‌شوند، چگونه صادر شده‌اند و چه کسی مالک آنهاست، خود فرایند احراز هویت مبهم می‌شود. همین ابهام، بستر ماندگاری مهاجم و حرکت جانبی است.

عادت‌های قدیمی در سیستم‌های جدید دوام نمی‌آورند

بسیاری از سازمان‌ها هنوز با عادت‌های legacy کار می‌کنند. یک service account ساخته می‌شود، مجوزهای گسترده می‌گیرد و سال‌ها باقی می‌ماند. گواهی‌ها با عمر زیاد صادر می‌شوند چون تیم‌ها از اختلال تمدید می‌ترسند. tokenها برای راحتی در pipelineها جمع می‌شوند. نتیجه این است که زیرساخت موقت با اعتماد دائمی پشتیبانی می‌شود.

سیستم‌های cloud-native به هویتی کوتاه‌عمر، زمینه‌مند و خودکار نیاز دارند. هرچه وابستگی به اعتبارنامه‌های ثابت بیشتر باشد، نقطه شکست پنهان بیشتر می‌شود. مسئله فقط سرقت نیست، بلکه سردرگمی هم هست. اعتبارنامه‌های قدیمی فعال می‌مانند، مالکیت عوض می‌شود و کسی مطمئن نیست چه چیزی را می‌توان خاموش کرد.

هویت ماشینی حالا مسئله زنجیره تأمین نرم‌افزار هم هست

بحث احراز هویت سازمانی دیگر فقط به دسترسی تولید محدود نیست. هویت ماشینی اکنون بر اعتماد زنجیره تأمین نرم‌افزار هم اثر می‌گذارد. build runnerها، artifact signing، registryها و deployment botها همگی به هویت‌های قابل‌راستی‌آزمایی نیاز دارند. اگر مهاجم بتواند خود را به‌جای build system جا بزند یا از token انتشار سوءاستفاده کند، پیش از رسیدن نرم‌افزار به تولید آن را آلوده می‌کند.

کنترل بهتر چه شکلی دارد

سازمان‌ها به یک ابزار جادویی نیاز ندارند، بلکه به مدل عملیاتی دقیق‌تر نیاز دارند. هر هویت ماشینی باید مالک، هدف روشن و عمر محدود داشته باشد. هرجا ممکن است باید به‌جای secretهای بلندعمر از اعتبارنامه‌های موقتی، workload federation، صدور خودکار گواهی و managed identity استفاده شود. مجوزدهی هم باید زمینه‌مندتر شود و logging و detection باید احراز هویت ماشینی را سیگنال درجه‌یک بدانند.

گام‌های عملی

  • موجودی بسازید: service accountها، گواهی‌ها، workload identityها، signing keyها و tokenهای اتوماسیون را فهرست کنید.
  • ریسک را دسته‌بندی کنید: مشخص کنید کدام هویت‌ها به داده تولید، تغییر زیرساخت یا امضای artifact دسترسی دارند.
  • دسترسی دائمی را کم کنید: مجوزهای گسترده را با roleهای محدود و اعتبارنامه‌های منقضی‌شونده جایگزین کنید.
  • چرخش را خودکار کنید: تمدید گواهی، refresh token و تعویض کلید را به workflowهای آزمایش‌شده بسپارید.
  • مالکیت را شفاف کنید: هر اعتبارنامه باید به یک تیم و سرویس مشخص وصل باشد.

سازمان‌های موفق، هویت ماشینی را دیگر plumbing نمی‌بینند. آنها آن را زیرساخت اصلی احراز هویت می‌دانند، عمرش را کوتاه می‌کنند، آن را به context وصل می‌کنند و با پایان کارش سریع حذفش می‌کنند. مسئله احراز هویت سازمانی دیگر فقط این نیست که چه کسی وارد می‌شود، بلکه این است که آیا ماشین‌های فعال در محیط اصلاً قابل اعتماد هستند یا نه.

اشتراک‌گذاری:
هویت‌های ماشینی به مسئله واقعی احراز هویت سازمانی تبدیل شده‌اند | AIO APEX