بیشتر پروژه‌های نوسازی تنها تا لایه احراز هویت پیش می‌روند و تصور می‌کنند که تغییر هویت زمانی کامل می‌شود که SAML یا OIDC راه‌اندازی شده باشد. اما یکی از حیاتی‌ترین بخش‌های امنیت برنامه، یعنی مدیریت نشست (session management)، اغلب نادیده گرفته می‌شود.

پروتکل‌های SSO فقط درب ورودی را مدیریت می‌کنند. اما پس از ورود، مدیریت نشست همه چیز را از آن لحظه به بعد کنترل می‌کند: مدت زمان ورود به سیستم، لغو نشست‌ها، بازبینی دسترسی‌ها و حفظ زمینه هویت.

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

با ظهور سیستم‌های هویت ابری و پروتکل‌های ورود فدرال، بسیاری از قابلیت‌های داخلی WAM را به خاطر راحتی استانداردهای باز و فدراسیون از دست دادیم. مشکل اینجاست که بیشتر ارائه‌دهندگان هویت ابری خود مدیریت نشست‌ها را داخل برنامه انجام نمی‌دهند و این کار به توسعه‌دهندگان برنامه واگذار می‌شود.

منطق پراکنده مدیریت نشست خطرناک است

در بسیاری از سازمان‌ها، مدیریت نشست با استفاده از قابلیت‌های بومی چارچوب برنامه انجام می‌شود. مثلاً یک برنامه جاوا ممکن است از Spring Security استفاده کند، یک رابط کاربری جاوااسکریپت ممکن است به میدل‌ویر Node.js تکیه کند، و Ruby on Rails شیوه متفاوتی برای نشست‌ها دارد. حتی در میان برنامه‌هایی که از یک زبان یا چارچوب استفاده می‌کنند، تنظیمات اغلب بین تیم‌ها بسیار متفاوت است، به خصوص در سازمان‌هایی که توسعه پراکنده دارند یا اخیراً شرکت‌های دیگر را خریده‌اند.

این پراکندگی مشکلات واقعی ایجاد می‌کند: سیاست‌های نامنظم برای زمان‌بندی خروج، تأخیر در به‌روزرسانی‌ها و شکاف‌هایی در لغو نشست‌ها.

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

تیم‌های امنیتی ممکن است فکر کنند که ارائه‌دهنده هویت می‌تواند دسترسی را فوراً لغو کند. اما مگر اینکه برنامه خودش برای تأیید نشست به آن سیستم هویت مراجعه کند که بیشتر برنامه‌ها این کار را نمی‌کنند این فقط یک تصور است، نه تضمین واقعی.

کنترل متمرکز بیش از همیشه اهمیت دارد

درس مهم این نیست که باید به زیرساخت‌های قدیمی هویت بازگردیم، بلکه باید بخشی از کنترل و دید متمرکزی که سیستم‌های WAM ارائه می‌دادند را به خصوص در زمینه مدیریت نشست بازیابی کنیم.

مدیریت هویت و دسترسی باید به عنوان یک خدمت مشترک دیده شود، نه چیزی که به صورت پراکنده و جداگانه در هر برنامه پیاده شود.

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

• لغو نشست فوری در تمام برنامه‌ها و محیط‌ها
• اجرای سیاست‌های زمان‌بندی خروج یکنواخت و هماهنگ با قوانین امنیتی و انطباق
• ثبت یکپارچه و قابل پیگیری فعالیت‌های مرتبط با هویت
• یکپارچگی لحظه‌ای با پروتکل‌های ارزیابی دسترسی مستمر (CAEP) و داده‌های هوش اعتماد صفر (Zero Trust)

این مسائل صرفاً دغدغه‌های نظری نیستند؛ بلکه پیش‌نیازهای بنیادی برای امنیت سازمانی مدرن‌اند.

نقش استانداردها در هویت چند ابری

به عنوان یکی از نویسندگان اصلی استاندارد SAML، دیده‌ام که پروتکل‌های هویت چگونه تکامل یافته‌اند و در کجا ضعف دارند. وقتی SAML را تعریف کردیم، می‌دانستیم که تمرکز فقط روی ورود یک‌باره است و بخش‌های مهم دیگری مثل مجوزدهی و تأمین کاربر را پوشش نمی‌دهد. به همین دلیل استانداردهای دیگری مثل SPML، AuthXML و اکنون تلاش‌هایی مانند IDQL (زبان پرس‌وجوی هویت) ظهور کردند.

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

مدیران امنیت و معماران هویت چه کاری باید انجام دهند؟

اگر مسئول نوسازی هستید و فکر می‌کنید فقط با راه‌اندازی SAML یا OIDC کار تمام شده، وقت بازنگری است. توصیه من این است:

۱. ممیزی مدیریت نشست انجام دهید
نحوه مدیریت نشست‌ها را در برنامه‌های حیاتی خود بررسی کنید. ناسازگاری‌ها در زمان‌بندی، توانایی لغو و وضعیت به‌روزرسانی‌ها را شناسایی کنید.

۲. کنترل نشست‌ها را متمرکز کنید
چه از طریق پروکسی متمرکز، کیت توسعه نرم‌افزار استاندارد یا لایه هویت آگاه به شبکه سرویس، راهی برای نظارت متمرکز بر نشست‌ها پیدا کنید.

۳. برنامه‌ریزی برای ارزیابی و لغو مداوم
با CAEP ادغام شوید یا مکانیسم‌های مشابه بسازید تا کنترل نشست‌ها بر اساس سیگنال‌های ریسک به صورت پویا انجام شود.

۴. مدیریت هویت را به عنوان زیرساخت در نظر بگیرید
مانند DNS، شبکه یا TLS، خدمات هویت باید به صورت جهانی مدیریت، پیوسته اعتبارسنجی و مقاوم باشند.

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

تا زمانی که مدیریت نشست استاندارد و به صورت مقیاس‌پذیر کنترل نشود، معماری هویت شما مدرن نیست، بلکه ناقص است.