SAML چیست؟ بررسی امنیت SAML در سیستم‌های احراز هویت سازمانی

SAML یا Security Assertion Markup Language یک استاندارد مبتنی بر XML برای تبادل اطلاعات احراز هویت و هویت کاربران میان سامانه‌های مورد اعتماد است. این استاندارد به سازمان‌ها اجازه می‌دهد با استفاده از یک سرویس مدیریت هویت مرکزی، قابلیت ورود یکپارچه یا Single Sign-On را پیاده‌سازی کنند. امنیت SAML به اعتبارسنجی امضاهای دیجیتال، مدیریت گواهی‌ها، کنترل نشست‌ها و بررسی دقیق پیام‌های احراز هویت وابسته است.

مقدمه: چرا امنیت SAML در سازمان‌ها اهمیت دارد؟

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

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

در چنین شرایطی، راهکارهای مدیریت هویت متمرکز و ورود یکپارچه اهمیت پیدا می‌کنند.

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

با این حال، متمرکزسازی احراز هویت یک تناقض امنیتی مهم ایجاد می‌کند.

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

برای مثال، نقص امنیتی در اعتبارسنجی پیام‌های SAML می‌تواند باعث شود یک برنامه، اطلاعات هویتی غیرمعتبر را بپذیرد یا در شرایط خاص، نشست کاربری اشتباهی ایجاد کند.

بنابراین، شناخت SAML صرفاً برای متخصصان مدیریت شبکه اهمیت ندارد؛ توسعه‌دهندگان وب، کارشناسان امنیت، مدیران زیرساخت، تیم‌های DevOps و مسئولان مدیریت دسترسی نیز باید با معماری و خطرات آن آشنا باشند.

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

SAML چیست و چه کاربردی دارد؟

SAML مخفف عبارت Security Assertion Markup Language است که می‌توان آن را «زبان نشانه‌گذاری ادعاهای امنیتی» ترجمه کرد.

این استاندارد توسط سازمان OASIS توسعه یافته و نسخه SAML 2.0 آن یکی از استانداردهای تثبیت‌شده در حوزه مدیریت هویت فدرال یا Federated Identity محسوب می‌شود.

هدف اصلی SAML فراهم‌کردن روشی استاندارد برای انتقال اطلاعات امنیتی میان دو سامانه مستقل است که از قبل رابطه اعتماد مشخصی با یکدیگر دارند.

این اطلاعات می‌توانند شامل موارد زیر باشند:

• هویت کاربر احراز هویت‌شده
• زمان انجام احراز هویت
• اطلاعات مربوط به روش احراز هویت
• شناسه منحصربه‌فرد کاربر
• ویژگی‌های هویتی مانند واحد سازمانی
• اطلاعات گروه‌ها یا نقش‌های کاربر
• محدودیت‌های زمانی و مقصد مجاز پیام

برای درک بهتر، فرض کنید کارمندی قصد دارد وارد سامانه حسابداری شرکت شود.

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

سامانه حسابداری پس از اعتبارسنجی پیام، می‌تواند برای کاربر نشست ایجاد کند.

در این معماری، سامانه حسابداری همچنان مسئول تعیین مجوزهای دسترسی است؛ اما برای تأیید هویت اولیه به یک مرجع مورد اعتماد تکیه می‌کند.

مفهوم Federated Identity در SAML

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

این مدل لزوماً به معنای قرارگرفتن تمام سامانه‌ها در یک شبکه داخلی نیست.

برای مثال، یک سازمان می‌تواند از سرویس مدیریت هویت داخلی یا ابری خود برای احراز هویت کاربران در نرم‌افزارهای SaaS استفاده کند.

در چنین حالتی، سرویس ابری نیازی ندارد رمز عبور سازمانی کاربر را نگهداری کند.

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

آیا SAML یک سیستم احراز هویت است؟

SAML در اصل یک استاندارد تبادل اطلاعات احراز هویت و هویت است، نه یک روش مستقل برای بررسی رمز عبور یا اثر انگشت.

برای مثال، خود SAML تعیین نمی‌کند کاربر باید با رمز عبور، کلید امنیتی یا اثر انگشت وارد شود.

این وظیفه بر عهده Identity Provider است.

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

این تفاوت یکی از مهم‌ترین نکات برای درک معماری امنیت SAML است.

اجزای اصلی معماری SAML

معماری SAML معمولاً از سه نقش اصلی تشکیل می‌شود: کاربر، ارائه‌دهنده هویت و ارائه‌دهنده سرویس.

در کنار این اجزا، پیام‌های XML، گواهی‌های دیجیتال و اطلاعات پیکربندی نیز نقش حیاتی دارند.

۱. کاربر یا Principal

Principal موجودیتی است که هویت آن در فرآیند احراز هویت بررسی می‌شود.

در کاربردهای رایج سازمانی، Principal معمولاً یک کارمند، مدیر یا کاربر تجاری است.

کاربر از طریق مرورگر خود به یک سرویس سازمانی دسترسی پیدا می‌کند و در صورت نیاز به احراز هویت، وارد جریان SAML می‌شود.

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

۲. ارائه‌دهنده هویت یا Identity Provider

Identity Provider که به اختصار IdP نامیده می‌شود، مسئول احراز هویت کاربر و صدور اطلاعات هویتی قابل اعتماد است.

این سرویس می‌تواند با زیرساخت‌هایی مانند دایرکتوری سازمانی، سامانه مدیریت کاربران یا روش‌های احراز هویت چندمرحله‌ای یکپارچه شود.

وظایف اصلی IdP عبارت‌اند از:

• احراز هویت کاربران براساس سیاست‌های سازمان
• اعمال کنترل‌های امنیتی هنگام ورود
• ایجاد پیام‌ها و Assertionهای SAML
• امضای دیجیتال اطلاعات احراز هویت
• ارائه ویژگی‌های هویتی مجاز
• مدیریت بخشی از چرخه نشست‌های هویتی

نمونه‌هایی از محصولات دارای قابلیت IdP شامل Microsoft Entra ID، Okta، Ping Identity و برخی راهکارهای مبتنی بر Keycloak هستند.

انتخاب محصول مناسب باید براساس نیازهای سازمان، قابلیت‌های امنیتی و مدل استقرار انجام شود.

۳. ارائه‌دهنده سرویس یا Service Provider

Service Provider یا SP سامانه‌ای است که کاربر قصد استفاده از آن را دارد.

این سامانه می‌تواند یک نرم‌افزار داخلی، پورتال سازمانی، سرویس ابری یا برنامه تجاری باشد.

SP معمولاً مسئول بررسی پیام دریافتی از IdP، ایجاد نشست برنامه و اعمال مجوزهای دسترسی کاربر است.

برای مثال، نرم‌افزار مدیریت منابع انسانی می‌تواند یک Service Provider باشد.

نکته مهم این است که اعتماد SP به IdP نباید نامحدود باشد.

SP باید بررسی کند پیام از مرجع مجاز صادر شده، برای همین سرویس در نظر گرفته شده، منقضی نشده و تمام الزامات امنیتی آن برقرار است.

۴. مفهوم SAML Assertion

Assertion مهم‌ترین بخش اطلاعاتی استاندارد SAML است.

یک Assertion مجموعه‌ای از ادعاهای امنیتی درباره یک موجودیت مشخص را حمل می‌کند.

برای مثال، ممکن است اعلام کند کاربری با یک شناسه سازمانی مشخص در زمان معینی احراز هویت شده است.

Assertion می‌تواند سه نوع اطلاعات اصلی داشته باشد:

Authentication Statement: اطلاعات مربوط به احراز هویت انجام‌شده، از جمله زمان و زمینه احراز هویت.

Attribute Statement: ویژگی‌های هویتی مانند شناسه کاربری، واحد سازمانی یا گروه‌های مشخص.

Authorization Decision Statement: اطلاعات مربوط به تصمیم‌های مجوزدهی که در برخی سناریوهای SAML قابل استفاده هستند.

وجود اطلاعات مجوزدهی در استاندارد به این معنا نیست که هر برنامه باید تمام تصمیم‌های دسترسی خود را مستقیماً از Assertion استخراج کند.

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

۵. اطلاعات Metadata

SAML Metadata اطلاعات لازم برای ایجاد ارتباط اعتماد میان سرویس‌ها را در قالبی استاندارد توصیف می‌کند.

این اطلاعات معمولاً شامل شناسه موجودیت، آدرس سرویس‌های ارتباطی، Bindingهای پشتیبانی‌شده و کلیدهای عمومی مرتبط با امضا یا رمزگذاری است.

Metadata به کاهش خطاهای پیکربندی کمک می‌کند، اما تنها در صورتی قابل اعتماد است که منشأ و یکپارچگی آن نیز بررسی شده باشد.

دریافت خودکار Metadata از یک آدرس نامعتبر می‌تواند باعث ورود اطلاعات اعتماد نادرست به سامانه شود.

SAML چگونه کار می‌کند؟ بررسی فرآیند ورود یکپارچه

برای شناخت امنیت SAML باید بدانیم پیام‌های احراز هویت در چه مراحلی میان کاربر، SP و IdP منتقل می‌شوند.

یکی از رایج‌ترین سناریوها، ورود یکپارچه‌ای است که از سمت Service Provider آغاز می‌شود.

به این روش SP-Initiated SSO گفته می‌شود.

مرحله اول: درخواست دسترسی کاربر

کاربر نشانی یک برنامه سازمانی را در مرورگر باز می‌کند.

برنامه بررسی می‌کند آیا کاربر نشست معتبر و مجوز لازم برای دسترسی دارد یا خیر.

اگر نشست احراز هویت وجود نداشته باشد، برنامه فرآیند ورود یکپارچه را آغاز می‌کند.

مرحله دوم: ایجاد درخواست AuthnRequest

Service Provider یک درخواست احراز هویت با عنوان AuthnRequest تولید می‌کند.

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

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

این ارتباط برای جلوگیری از پذیرش پاسخ‌های نامرتبط اهمیت زیادی دارد.

مرحله سوم: هدایت کاربر به Identity Provider

مرورگر کاربر به سرویس هویت سازمان هدایت می‌شود.

یکی از روش‌های رایج انتقال درخواست، HTTP Redirect Binding است.

در این مرحله ممکن است درخواست SAML و پارامترهای مرتبط، با قالب مشخصی از طریق مرورگر منتقل شوند.

هرگونه اطلاعات همراه درخواست باید مطابق قواعد Binding مربوط پردازش شود.

مرحله چهارم: بررسی هویت کاربر

IdP وضعیت احراز هویت کاربر را بررسی می‌کند.

اگر کاربر قبلاً نشست معتبری در سرویس مدیریت هویت داشته باشد، بسته به سیاست‌های امنیتی ممکن است نیازی به ورود مجدد نباشد.

در غیر این صورت، IdP فرآیند احراز هویت را آغاز می‌کند.

این فرآیند می‌تواند شامل رمز عبور، احراز هویت چندمرحله‌ای، کلید امنیتی یا روش‌های دیگر باشد.

برای دسترسی به سامانه‌های حساس، سیاست‌های سازمان ممکن است احراز هویت مجدد یا استفاده از روش قوی‌تر را الزامی کنند.

مرحله پنجم: تولید SAML Response

پس از احراز هویت موفق، IdP یک SAML Response ایجاد می‌کند.

این پاسخ معمولاً حاوی اطلاعات لازم برای اثبات نتیجه احراز هویت نزد Service Provider است.

Response می‌تواند شامل یک Assertion باشد که اطلاعات هویت، شرایط اعتبار و زمان‌های مجاز را مشخص می‌کند.

بسته به تنظیمات و پروفایل مورد استفاده، امضای دیجیتال ممکن است روی Response، Assertion یا هر دو قرار گیرد.

SP باید براساس سیاست امنیتی تعیین‌شده، وجود و اعتبار امضاهای مورد انتظار را بررسی کند.

مرحله ششم: انتقال پاسخ به Service Provider

یکی از روش‌های رایج ارسال پاسخ، HTTP POST Binding است.

در این حالت، مرورگر کاربر یک فرم HTML حاوی پیام SAML کدگذاری‌شده را به آدرس تعیین‌شده در SP ارسال می‌کند.

این آدرس معمولاً Assertion Consumer Service یا ACS نامیده می‌شود.

وجود مرورگر در مسیر انتقال به معنای اعتماد به محتوای پیام نیست.

SP باید فرض کند هر پیام دریافتی از مرورگر ممکن است دست‌کاری شده باشد و اعتبار آن را به‌صورت مستقل بررسی کند.

مرحله هفتم: اعتبارسنجی امنیتی پیام

این مرحله حساس‌ترین بخش فرآیند ورود SAML است.

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

برای مثال، اگر Assertion برای برنامه دیگری صادر شده باشد، نباید صرفاً به دلیل معتبر بودن امضای آن پذیرفته شود.

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

مرحله هشتم: ایجاد نشست و اعمال مجوزها

پس از تأیید تمام الزامات، برنامه هویت کاربر را به حساب داخلی مناسب مرتبط می‌کند.

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

نکته مهم این است که موفقیت در احراز هویت الزاماً به معنای مجاز بودن تمام عملیات نیست.

برای مثال، کاربری که با SAML وارد سامانه مالی شده است، نباید بدون بررسی نقش‌ها و سیاست‌های دسترسی، امکان مشاهده اطلاعات محرمانه تمام واحدهای سازمانی را داشته باشد.

تفاوت SP-Initiated و IdP-Initiated SSO

SAML از الگوهای مختلفی برای شروع ورود یکپارچه پشتیبانی می‌کند.

دو الگوی شناخته‌شده آن SP-Initiated و IdP-Initiated هستند.

ورود آغازشده از سمت SP

در مدل SP-Initiated، کاربر ابتدا به برنامه مقصد مراجعه می‌کند.

برنامه یک AuthnRequest ایجاد می‌کند و کاربر را برای احراز هویت به IdP می‌فرستد.

در این مدل، SP می‌تواند پاسخ دریافتی را با درخواست قبلی مرتبط کند.

این ارتباط معمولاً با استفاده از شناسه درخواست و ویژگی InResponseTo بررسی می‌شود.

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

ورود آغازشده از سمت IdP

در مدل IdP-Initiated، کاربر معمولاً از یک پورتال هویت سازمانی، برنامه مورد نظر خود را انتخاب می‌کند.

در این حالت، IdP می‌تواند بدون دریافت AuthnRequest از برنامه مقصد، یک پاسخ احراز هویت برای آن صادر کند.

این الگو در برخی محیط‌های سازمانی رایج است، اما از نظر امنیتی محدودیت مهمی دارد.

چون SP درخواست اولیه‌ای تولید نکرده است، امکان تطبیق پاسخ با یک شناسه درخواست از پیش ثبت‌شده وجود ندارد.

در نتیجه، پیاده‌سازی باید کنترل‌های دیگری برای جلوگیری از Login CSRF، جابه‌جایی نشست و پذیرش پاسخ‌های ناخواسته در نظر بگیرد.

برای برنامه‌های حساس، استفاده از SP-Initiated SSO همراه با ارتباط دقیق درخواست و پاسخ معمولاً انتخاب قابل دفاع‌تری است.

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

ساختار پیام‌های SAML و عناصر مهم امنیتی

برای تحلیل امنیت SAML، شناخت عناصر اصلی پیام‌های XML ضروری است.

هر عنصر اطلاعات مشخصی دارد و برخی از آن‌ها مستقیماً در جلوگیری از جعل هویت یا استفاده مجدد از پیام‌ها نقش دارند.

عنصر Issuer

Issuer مشخص می‌کند کدام موجودیت SAML پیام یا Assertion را صادر کرده است.

Service Provider باید بررسی کند Issuer با هویت IdP مورد اعتماد در پیکربندی مطابقت دارد.

صرف وجود نام یک IdP شناخته‌شده در پیام کافی نیست.

هویت صادرکننده باید در کنار اعتبارسنجی رمزنگاری و اطلاعات اعتماد بررسی شود.

عنصر Subject و NameID

Subject موجودیتی را مشخص می‌کند که Assertion درباره آن صادر شده است.

NameID می‌تواند شناسه کاربر را در قالب‌های مختلف ارائه دهد.

در سامانه‌های سازمانی ممکن است از ایمیل، شناسه پایدار یا شناسه مستعار استفاده شود.

استفاده از ایمیل به‌عنوان تنها کلید شناسایی کاربر همیشه انتخاب مناسبی نیست؛ زیرا ایمیل ممکن است تغییر کند، واگذار شود یا در شرایط خاص با حساب دیگری ارتباط پیدا کند.

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

ویژگی AudienceRestriction

AudienceRestriction تعیین می‌کند Assertion برای کدام سرویس یا مجموعه مجاز از سرویس‌ها صادر شده است.

این ویژگی مانع مهمی در برابر استفاده از Assertion یک برنامه در برنامه‌ای دیگر است.

برای مثال، اگر یک Assertion برای سامانه مدیریت پروژه صادر شده باشد، سامانه مالی نباید همان Assertion را به‌عنوان مجوز ورود بپذیرد.

حتی اگر امضای دیجیتال صحیح باشد، کنترل Audience همچنان ضروری است.

ویژگی Recipient

Recipient مقصد مجاز ارائه Assertion را مشخص می‌کند.

این ویژگی معمولاً در اطلاعات SubjectConfirmationData قرار می‌گیرد.

Service Provider باید آن را با آدرس ACS مورد انتظار مقایسه کند.

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

ویژگی Destination

Destination در پیام Response مشخص می‌کند پیام برای کدام مقصد ارسال شده است.

این مقدار باید مطابق الزامات پروفایل و سیاست پیکربندی با آدرس مورد انتظار تطبیق داده شود.

برنامه نباید صرفاً به دلیل معتبر بودن ساختار XML، یک Destination ناشناخته یا ناسازگار را بپذیرد.

ویژگی InResponseTo

InResponseTo شناسه درخواست احراز هویتی را مشخص می‌کند که پاسخ به آن مربوط است.

در جریان SP-Initiated، اعتبارسنجی این ویژگی باید با اطلاعات درخواست ثبت‌شده در سمت سرور انجام شود.

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

محدودیت‌های NotBefore و NotOnOrAfter

این ویژگی‌ها بازه زمانی معتبر Assertion یا بخش‌های مرتبط آن را مشخص می‌کنند.

NotBefore نشان‌دهنده زمانی است که اعتبار نباید پیش از آن آغاز شود.

NotOnOrAfter نیز حد بالای زمانی را مشخص می‌کند که با رسیدن به آن، اعتبار پایان می‌یابد.

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

این تلورانس باید متناسب با نیاز عملیاتی باشد و نباید به پذیرش طولانی‌مدت Assertionهای منقضی‌شده منجر شود.

SAML Binding چیست و چه تأثیری بر امنیت دارد؟

Binding در SAML مشخص می‌کند پیام‌های پروتکل چگونه از طریق فناوری‌های ارتباطی انتقال پیدا کنند.

انتخاب Binding می‌تواند بر سطح حمله، شیوه محافظت پیام و پیچیدگی پیاده‌سازی تأثیر بگذارد.

HTTP Redirect Binding

در این روش، پیام SAML از طریق مکانیزم تغییر مسیر HTTP منتقل می‌شود.

این Binding معمولاً برای انتقال AuthnRequest کاربرد دارد.

بسته به نوع پیام و تنظیمات امنیتی، حفاظت از یکپارچگی درخواست اهمیت دارد.

همچنین باید از ثبت یا افشای اطلاعات حساس موجود در آدرس‌ها و لاگ‌ها جلوگیری شود.

HTTP POST Binding

این Binding پیام SAML را از طریق فرم HTML و درخواست POST منتقل می‌کند.

ارسال Response از IdP به ACS اغلب با این روش انجام می‌شود.

مقدار SAMLResponse معمولاً به‌صورت Base64 کدگذاری می‌شود.

Base64 رمزگذاری امنیتی نیست و محرمانگی اطلاعات را تضمین نمی‌کند.

بنابراین، امنیت انتقال به TLS و امنیت خود پیام به کنترل‌هایی مانند امضای دیجیتال وابسته است.

HTTP Artifact Binding

در این روش، به‌جای انتقال مستقیم پیام کامل در مرورگر، یک مرجع کوتاه با عنوان Artifact منتقل می‌شود.

سرویس دریافت‌کننده می‌تواند از طریق یک ارتباط جداگانه پیام مربوط را بازیابی کند.

این مدل در برخی معماری‌ها امکان کاهش میزان اطلاعات عبوری از مرورگر را فراهم می‌کند.

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

SOAP Binding

SOAP Binding امکان تبادل پیام‌های SAML را از طریق پیام‌های SOAP فراهم می‌کند.

این روش معمولاً در برخی ارتباطات مستقیم میان سرویس‌ها یا فرآیندهای خاص پروتکل استفاده می‌شود.

در محیط‌های جدید، پیکربندی امن ارتباطات، اعتبارسنجی موجودیت‌های طرف مقابل و محدودکردن سرویس‌های در معرض دسترس اهمیت ویژه‌ای دارد.

SAML و Single Sign-On چه تفاوتی دارند؟

SAML و SSO دو مفهوم مرتبط اما متفاوت هستند.

SSO یا Single Sign-On یک قابلیت معماری است که به کاربران اجازه می‌دهد پس از احراز هویت در یک زمینه مشخص، به چند برنامه مرتبط دسترسی پیدا کنند.

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

برای مثال، سازمانی ممکن است از SAML برای ورود کاربران به سرویس‌های ابری استفاده کند، اما یک برنامه دیگر همان سازمان از OpenID Connect بهره ببرد.

هر دو برنامه می‌توانند بخشی از تجربه ورود یکپارچه باشند.

بنابراین، SSO هدف یا قابلیت مورد نظر است، در حالی که SAML یکی از ابزارهای استاندارد برای تحقق آن محسوب می‌شود.

نکته دیگر اینکه ورود یکپارچه به معنای ایجاد یک نشست مشترک و کاملاً یکسان میان تمام برنامه‌ها نیست.

هر Service Provider ممکن است نشست مستقل خود را نگهداری کند و سیاست‌های متفاوتی برای انقضا یا خروج داشته باشد.

این مسئله هنگام طراحی امنیت نشست‌ها اهمیت زیادی پیدا می‌کند.

تفاوت SAML با OAuth 2.0 و OpenID Connect

SAML، OAuth 2.0 و OpenID Connect در حوزه هویت و دسترسی کاربرد دارند، اما اهداف و مدل‌های فنی آن‌ها یکسان نیست.

اشتباه‌گرفتن این فناوری‌ها می‌تواند باعث تصمیم‌های معماری نادرست شود.

تفاوت SAML و OAuth 2.0

OAuth 2.0 اساساً یک چارچوب Authorization یا واگذاری مجوز دسترسی است.

برای مثال، یک برنامه ممکن است با دریافت مجوز مناسب بتواند به بخشی از داده‌های کاربر در یک API دسترسی پیدا کند.

وجود Access Token به‌تنهایی به معنای اثبات استاندارد هویت کاربر نزد برنامه نیست.

اگر برنامه‌ای از OAuth 2.0 بدون طراحی هویتی مناسب برای ورود کاربران استفاده کند، ممکن است با مشکلاتی مانند اشتباه در تشخیص هویت یا ارتباط توکن با کاربر مواجه شود.

تفاوت SAML و OpenID Connect

OpenID Connect یا OIDC یک لایه هویتی مبتنی بر OAuth 2.0 است.

OIDC سازوکارهای مشخصی برای احراز هویت و ارائه اطلاعات هویتی فراهم می‌کند.

در بسیاری از برنامه‌های جدید، OIDC به دلیل هماهنگی با APIها، معماری‌های مبتنی بر JSON و کتابخانه‌های مدرن انتخاب مناسبی است.

با این حال، SAML همچنان در بسیاری از زیرساخت‌های سازمانی، به‌خصوص نرم‌افزارهای تجاری و سامانه‌های قدیمی‌تر، کاربرد گسترده‌ای دارد.

انتخاب میان این دو باید براساس نوع برنامه، الزامات امنیتی، زیرساخت موجود و قابلیت‌های سرویس مدیریت هویت انجام شود.

تفاوت SAML با LDAP و Kerberos

LDAP معمولاً برای دسترسی و مدیریت اطلاعات دایرکتوری استفاده می‌شود.

Kerberos نیز یک پروتکل احراز هویت مبتنی بر Ticket است که در بسیاری از محیط‌های شبکه سازمانی کاربرد دارد.

SAML جایگزین مستقیم تمام قابلیت‌های LDAP یا Kerberos نیست.

یک سازمان می‌تواند از دایرکتوری مبتنی بر LDAP برای نگهداری حساب‌ها، از Kerberos برای برخی سناریوهای شبکه داخلی و از SAML برای احراز هویت فدرال در سرویس‌های وب استفاده کند.

این فناوری‌ها در معماری مناسب می‌توانند مکمل یکدیگر باشند.

مدل امنیتی SAML چگونه کار می‌کند؟

امنیت SAML بر یک اصل کلیدی استوار است: یک سامانه تنها زمانی باید اطلاعات هویتی را بپذیرد که بتواند منشأ، یکپارچگی، اعتبار زمانی و مقصد مجاز آن را تأیید کند.

در این مدل، چند کنترل امنیتی مکمل یکدیگر هستند.

امضای دیجیتال یا Digital Signature

امضای دیجیتال یکی از مهم‌ترین سازوکارهای امنیت SAML است.

Identity Provider می‌تواند پیام یا Assertion را با کلید خصوصی مرتبط امضا کند.

Service Provider نیز با استفاده از کلید عمومی مورد اعتماد، اعتبار امضا را بررسی می‌کند.

این فرآیند به شناسایی تغییرات غیرمجاز در محتوای امضاشده کمک می‌کند.

اما یک نکته بسیار مهم وجود دارد:

امضای معتبر تنها زمانی ارزش امنیتی دارد که برنامه دقیقاً همان داده‌های امضاشده را برای تصمیم‌گیری استفاده کند.

اگر سامانه امضای یک بخش XML را بررسی کند اما اطلاعات هویتی را از بخش دیگری بخواند، همچنان ممکن است آسیب‌پذیر باشد.

رمزگذاری Assertion

رمزگذاری یا Encryption برای محافظت از محرمانگی اطلاعات کاربرد دارد.

در برخی پیکربندی‌های SAML، Assertion می‌تواند برای Service Provider رمزگذاری شود.

این قابلیت به کاهش خطر مشاهده محتوای حساس توسط طرف‌هایی کمک می‌کند که نباید به آن دسترسی داشته باشند.

امضا و رمزگذاری دو هدف متفاوت دارند.

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

رمزگذاری Assertion جایگزین اعتبارسنجی امضا، کنترل مخاطب یا محدودیت زمانی نمی‌شود.

نقش گواهی‌های X.509

گواهی‌های X.509 در بسیاری از پیاده‌سازی‌های SAML برای معرفی کلیدهای عمومی مرتبط با امضا یا رمزگذاری استفاده می‌شوند.

Service Provider باید کلید اعتبارسنجی را از رابطه اعتماد پیکربندی‌شده به دست آورد.

نکته مهم این است که یک گواهی موجود در پیام ورودی، صرفاً به دلیل داشتن قالب X.509، قابل اعتماد نیست.

در بعضی استقرارها، گواهی امضای SAML به‌صورت مستقیم در تنظیمات اعتماد ثبت می‌شود و الزاماً از مدل گواهی‌های عمومی وب پیروی نمی‌کند.

بنابراین، اعتبارسنجی باید مطابق سیاست اعتماد و مدیریت کلید همان سامانه انجام شود.

مهم‌ترین آسیب‌پذیری‌ها و حملات امنیتی علیه SAML

استاندارد SAML سازوکارهای امنیتی مهمی دارد، اما پیاده‌سازی نادرست می‌تواند خطرات جدی ایجاد کند.

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

۱. حمله XML Signature Wrapping

XML Signature Wrapping یا XSW یکی از شناخته‌شده‌ترین دسته‌های آسیب‌پذیری مرتبط با پردازش پیام‌های XML امضاشده است.

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

مشکل اصلی، ناهماهنگی میان داده اعتبارسنجی‌شده و داده مصرف‌شده توسط برنامه است.

پیامد احتمالی این نقص، پذیرش اطلاعات هویتی غیرمعتبر در شرایط خاص است.

برای پیشگیری، برنامه باید:

• از کتابخانه معتبر و به‌روز SAML استفاده کند.
• ساختار XML را مطابق قواعد مورد انتظار اعتبارسنجی کند.
• مرجع امضای دیجیتال را به عنصر صحیح مرتبط سازد.
• شناسه‌های تکراری یا مبهم را رد کند.
• تنها از داده‌ای استفاده کند که اعتبار امضای آن تأیید شده است.

بهتر است توسعه‌دهندگان از طراحی اختصاصی منطق XML Signature خودداری کنند؛ زیرا ظرافت‌های ساختاری و رمزنگاری این حوزه بسیار زیاد است.

۲. حملات Replay یا استفاده مجدد از Assertion

در حمله Replay، مهاجم تلاش می‌کند از یک پیام احراز هویت معتبر که قبلاً صادر شده است، دوباره استفاده کند.

اگر SP صرفاً امضای دیجیتال را بررسی کند، ممکن است متوجه نشود که پیام پیش‌تر مصرف شده است.

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

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

در سامانه‌های توزیع‌شده، کنترل بازپخش باید میان نمونه‌های مختلف برنامه نیز هماهنگ باشد.

برای مثال، اگر یک Service Provider پشت چند سرور اجرا شود، ثبت وضعیت مصرف Assertion تنها در حافظه یکی از سرورها ممکن است کافی نباشد.

۳. حملات Login CSRF

Login CSRF زمانی مطرح می‌شود که یک جریان ورود بتواند باعث شود مرورگر قربانی به حسابی وارد شود که انتظار آن را ندارد.

این مشکل با CSRF کلاسیک که روی عملیات حساس یک کاربر واردشده تمرکز دارد، تفاوت دارد.

در برخی سناریوها، پذیرش پاسخ‌های ورود بدون ارتباط مناسب با درخواست اولیه می‌تواند خطر Login CSRF را افزایش دهد.

این موضوع به‌خصوص در طراحی جریان‌های ورود ناخواسته اهمیت دارد.

استفاده از SP-Initiated SSO، ارتباط دقیق درخواست و پاسخ، کنترل وضعیت نشست و بررسی مقصد ورود از راهکارهای مهم کاهش این خطر هستند.

۴. نقص در اعتبارسنجی Audience

اگر SP بررسی نکند که Assertion واقعاً برای همان برنامه صادر شده است، ممکن است اطلاعات متعلق به سرویس دیگری را بپذیرد.

این مسئله می‌تواند در محیط‌هایی که چند برنامه به یک IdP اعتماد دارند، خطرناک باشد.

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

بررسی AudienceRestriction باید بخشی جدانشدنی از اعتبارسنجی باشد.

۵. ضعف در مدیریت گواهی‌های دیجیتال

گواهی‌ها و کلیدهای مرتبط با SAML بخش مهمی از زنجیره اعتماد هستند.

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

شدت این حادثه به پیکربندی، مجوزهای موجود و سایر کنترل‌های حفاظتی بستگی دارد.

از سوی دیگر، پایان اعتبار عملیاتی گواهی یا تغییر ناهماهنگ کلیدها می‌تواند باعث اختلال در ورود کاربران شود.

سازمان‌ها باید برای نگهداری امن کلیدهای خصوصی، محدودسازی دسترسی، چرخش برنامه‌ریزی‌شده و واکنش به افشای کلید سیاست مشخص داشته باشند.

۶. استفاده از الگوریتم‌های رمزنگاری ضعیف

برخی استقرارهای قدیمی ممکن است همچنان با الگوریتم‌های امضای مبتنی بر SHA-1 یا تنظیمات منسوخ کار کنند.

پذیرش این الگوریتم‌ها می‌تواند سطح امنیت رمزنگاری را کاهش دهد.

در استقرارهای جدید، بهتر است الگوریتم‌های مورد تأیید سیاست امنیتی سازمان، مانند ترکیب‌های مناسب مبتنی بر SHA-256 یا قوی‌تر، استفاده شوند.

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

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

۷. آسیب‌پذیری‌های پردازش XML

SAML به‌صورت گسترده از XML استفاده می‌کند و به همین دلیل امنیت پردازشگر XML اهمیت زیادی دارد.

از جمله خطرات شناخته‌شده این حوزه می‌توان به XML External Entity یا XXE و مصرف بیش از حد منابع هنگام پردازش ساختارهای پیچیده اشاره کرد.

اگر پردازشگر XML به شکل ناامن تنظیم شده باشد، ممکن است امکان دسترسی ناخواسته به منابع یا اختلال در دسترس‌پذیری سامانه ایجاد شود.

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

۸. ضعف در مدیریت RelayState

RelayState معمولاً برای حفظ وضعیت یا اطلاعات مربوط به مسیر بازگشت کاربر در جریان SAML استفاده می‌شود.

اگر برنامه بدون اعتبارسنجی، از این مقدار برای هدایت کاربر به نشانی دلخواه استفاده کند، ممکن است آسیب‌پذیری Open Redirect ایجاد شود.

این نقص می‌تواند در سناریوهای فیشینگ و هدایت کاربران به صفحات نامعتبر مورد سوءاستفاده قرار گیرد.

بهتر است مقصدهای بازگشت محدود و کنترل‌شده باشند و از پذیرش آزادانه نشانی‌های خارجی جلوگیری شود.

همچنین RelayState نباید به‌عنوان محلی برای نگهداری اطلاعات حساس استفاده شود.

۹. خطا در نگاشت حساب‌های کاربری

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

فرض کنید یک برنامه هنگام اولین ورود، حساب کاربری را صرفاً براساس آدرس ایمیل ایجاد یا شناسایی کند.

اگر سیاست تغییر ایمیل، واگذاری مجدد شناسه یا تأیید مالکیت به‌درستی طراحی نشده باشد، امکان ارتباط نادرست هویت فدرال با حساب محلی وجود دارد.

در سامانه‌های حساس باید نگاشت حساب‌ها براساس شناسه‌های پایدار، مرجع هویت معتبر و قواعد مشخص انجام شود.

تغییر ویژگی‌های هویتی نیز باید با کنترل‌های مستقل همراه باشد.

۱۰. ضعف در مدیریت نشست‌های SSO

موفقیت در اعتبارسنجی SAML به معنای امن بودن تمام نشست‌های بعدی نیست.

اگر Service Provider پس از ورود، نشست ضعیفی ایجاد کند یا شناسه نشست را به‌درستی مدیریت نکند، خطراتی مانند Session Hijacking و Session Fixation همچنان مطرح هستند.

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

به همین دلیل، امنیت SAML باید همراه با امنیت نشست و سیاست‌های خروج بررسی شود.

چگونه امنیت SAML را در سازمان افزایش دهیم؟

ایمن‌سازی SAML به مجموعه‌ای از کنترل‌های فنی، مدیریتی و عملیاتی نیاز دارد.

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

اعتبارسنجی کامل پیام‌ها

Service Provider باید برای هر پاسخ دریافتی، تمام کنترل‌های امنیتی لازم را اجرا کند.

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

همچنین برنامه باید وضعیت موفقیت پروتکل را بررسی کند و در صورت مشاهده خطا، فرمت غیرمنتظره یا ابهام در ساختار پیام، ورود را رد کند.

اصل مناسب در این بخش Fail Closed است.

یعنی هنگامی که اعتبار پیام مشخص نیست، سامانه نباید به‌صورت پیش‌فرض دسترسی صادر کند.

استفاده از کتابخانه‌های معتبر

پیاده‌سازی دستی پروتکل SAML، XML Signature و قواعد مربوط به Canonicalization می‌تواند احتمال بروز خطا را افزایش دهد.

Canonicalization فرآیندی است که نمایش XML را برای عملیات رمزنگاری به شکل استاندارد تبدیل می‌کند.

اشتباه در تفسیر ساختار XML یا مرجع امضا ممکن است باعث اختلاف میان نتیجه اعتبارسنجی و داده واقعی مورد استفاده برنامه شود.

بنابراین، استفاده از کتابخانه‌های شناخته‌شده، نگهداری فعال و نسخه‌های به‌روز اهمیت زیادی دارد.

در عین حال، نصب کتابخانه معتبر جایگزین پیکربندی صحیح آن نیست.

محافظت از کانال ارتباطی با HTTPS

تمام نقاط حساس مرتبط با انتقال پیام‌ها، از جمله Endpointهای احراز هویت و ACS، باید از ارتباط امن استفاده کنند.

استفاده از TLS به محافظت از اطلاعات هنگام انتقال کمک می‌کند.

در محیط‌های جدید، استفاده از نسخه‌ها و مجموعه رمزهای امن TLS، با اولویت TLS 1.3 و پشتیبانی مناسب از TLS 1.2 در صورت نیاز، قابل توصیه است.

گواهی HTTPS باید معتبر باشد و برنامه نباید خطاهای امنیتی ارتباط را نادیده بگیرد.

با این حال، TLS جایگزین امضای دیجیتال Assertion نیست؛ زیرا پیام ممکن است از طریق مرورگر کاربر منتقل شود.

فعال‌سازی احراز هویت چندمرحله‌ای

MFA یا Multi-Factor Authentication یکی از کنترل‌های مهم برای کاهش وابستگی امنیت به رمز عبور است.

در معماری SAML، این قابلیت معمولاً در سمت Identity Provider اعمال می‌شود.

برای برنامه‌های حساس بهتر است سازمان از روش‌های مقاوم در برابر فیشینگ، مانند احراز هویت مبتنی بر FIDO2 و WebAuthn، در صورت پشتیبانی زیرساخت استفاده کند.

همچنین باید مشخص باشد که برنامه مقصد چه سطحی از اطمینان احراز هویت را نیاز دارد.

صرف مشاهده یک Assertion معتبر نباید به معنای انجام MFA تلقی شود.

مدیریت دقیق نشست‌ها

پس از ورود موفق، برنامه باید یک نشست امن ایجاد کند.

کوکی‌های نشست باید متناسب با معماری از ویژگی‌هایی مانند Secure و HttpOnly استفاده کنند.

تنظیم SameSite نیز باید با جریان ورود فدرال سازگار باشد.

برای مثال، برخی جریان‌های SAML مبتنی بر POST میان دو سایت ممکن است با تنظیمات سخت‌گیرانه SameSite با مشکل مواجه شوند.

اگر استفاده از SameSite=None ضروری باشد، کوکی باید Secure باشد و کنترل‌های مستقل ضد CSRF و مدیریت وضعیت ورود نیز رعایت شوند.

همچنین پس از ورود موفق بهتر است شناسه نشست به‌صورت امن بازتولید شود.

محدودکردن زمان اعتبار Assertion

Assertionها معمولاً برای استفاده در بازه زمانی محدودی صادر می‌شوند.

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

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

بنابراین، مدت اعتبار باید براساس نیاز عملیاتی و ارزیابی ریسک تنظیم شود.

همگام‌سازی ساعت سرورها با سرویس زمانی قابل اعتماد نیز ضروری است.

اجرای اصل حداقل دسترسی

اصل Least Privilege بیان می‌کند هر کاربر باید تنها به منابعی دسترسی داشته باشد که برای انجام وظایفش ضروری هستند.

در معماری SAML، انتقال موفق هویت نباید باعث اعطای دسترسی گسترده شود.

برای مثال، اگر IdP اعلام کند کاربری عضو واحد مالی است، برنامه مقصد همچنان باید بررسی کند این ویژگی دقیقاً چه مجوزی ایجاد می‌کند.

استفاده از Role-Based Access Control یا RBAC و در صورت نیاز Attribute-Based Access Control یا ABAC می‌تواند به مدیریت دقیق‌تر مجوزها کمک کند.

نقش‌های مدیریتی و دسترسی‌های حساس باید با کنترل‌های بیشتری همراه باشند.

چک‌لیست امنیت SAML برای تیم‌های فنی

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

کنترل‌های سمت Identity Provider

1. روش‌های احراز هویت کاربران با حساسیت سرویس‌های متصل متناسب باشند.

1. احراز هویت چندمرحله‌ای برای حساب‌های حساس و مدیریتی اعمال شود.

1. کلیدهای خصوصی امضا با دسترسی محدود و سازوکار محافظتی مناسب نگهداری شوند.

1. چرخه عمر گواهی‌ها و برنامه چرخش کلیدها مستند باشد.

1. Assertionها تنها برای مخاطبان مجاز صادر شوند.

1. مدت اعتبار پیام‌ها محدود و متناسب با سطح ریسک باشد.

1. تنها ویژگی‌های هویتی ضروری در پیام‌ها قرار گیرند.

1. رویدادهای مهم ورود، خطا و تغییرات تنظیمات ثبت و پایش شوند.

کنترل‌های سمت Service Provider

1. امضای دیجیتال پیام‌های مورد انتظار به‌صورت کامل اعتبارسنجی شود.

1. شناسه Issuer با ارائه‌دهنده هویت مورد اعتماد تطبیق داده شود.

1. ویژگی AudienceRestriction بررسی شود.

1. Destination و Recipient با مقصدهای مجاز مطابقت داشته باشند.

1. InResponseTo برای جریان‌های درخواست‌محور اعتبارسنجی شود.

1. محدودیت‌های زمانی Assertion بررسی شوند.

1. پیام‌های تکراری و Assertionهای قبلاً مصرف‌شده رد شوند.

1. داده‌های استخراج‌شده دقیقاً همان داده‌های اعتبارسنجی‌شده باشند.

1. پردازشگر XML در برابر قابلیت‌های ناامن و مصرف غیرعادی منابع محافظت شود.

1. ایجاد نشست و نگاشت حساب‌های کاربری مطابق سیاست امنیتی انجام شود.

کنترل‌های مدیریتی و عملیاتی

1. فهرست تمام برنامه‌های متصل به IdP مشخص باشد.

1. مسئول هر ارتباط اعتماد و هر Service Provider تعیین شود.

1. تغییرات پیکربندی SAML در فرآیند مدیریت تغییر ثبت شوند.

1. گواهی‌ها پیش از پایان دوره عملیاتی بررسی شوند.

1. سناریوی افشای کلید امضا در برنامه پاسخ به حادثه وجود داشته باشد.

1. سیاست حذف دسترسی کارکنان جداشده از سازمان اجرا شود.

1. آزمون‌های امنیتی پس از تغییرات مهم تکرار شوند.

1. حساب‌های دارای دسترسی ویژه به‌صورت دوره‌ای بازبینی شوند.

1. راهکار بازیابی دسترسی در زمان اختلال IdP مشخص باشد.

1. تنظیمات اعتماد، مستند و قابل ممیزی باشند.

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

نقش SAML در معماری Zero Trust

Zero Trust یا اعتماد صفر یک رویکرد امنیتی است که بر اعتبارسنجی مستمر، محدودسازی دسترسی و پرهیز از اعتماد ضمنی تأکید دارد.

در این رویکرد، قرارگرفتن کاربر در شبکه داخلی یا موفقیت در یک مرحله احراز هویت، به‌تنهایی مجوز نامحدود ایجاد نمی‌کند.

SAML می‌تواند یکی از اجزای معماری Zero Trust باشد، زیرا امکان استفاده از یک مرجع هویت مشخص را برای برنامه‌های متعدد فراهم می‌کند.

با این حال، SAML به‌تنهایی یک معماری Zero Trust کامل نیست.

برای پیاده‌سازی مؤثر این رویکرد، سازمان باید کنترل‌های دیگری نیز داشته باشد؛ از جمله:

• ارزیابی وضعیت امنیتی دستگاه
• احراز هویت متناسب با ریسک
• محدودسازی دسترسی به برنامه‌ها
• پایش رفتارهای غیرعادی
• بازبینی و لغو مجوزهای غیرضروری
• مدیریت ایمن نشست‌ها
• حفاظت از حساب‌های مدیریتی

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

وجود Assertion معتبر در زمان ورود اولیه، امنیت تمام فعالیت‌های بعدی را تضمین نمی‌کند.

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

مدیریت چرخه عمر کاربران در سیستم‌های مبتنی بر SAML

یکی از برداشت‌های اشتباه این است که فعال‌سازی SAML تمام مشکلات مدیریت کاربران را برطرف می‌کند.

در واقع، احراز هویت فدرال تنها بخشی از مدیریت چرخه عمر هویت است.

سازمان باید برای ایجاد حساب، تغییر نقش، انتقال واحد سازمانی و حذف دسترسی نیز فرآیند مشخص داشته باشد.

فرآیند Joiner

هنگامی که کارمند جدید وارد سازمان می‌شود، حساب او باید در سامانه مدیریت هویت ایجاد شود.

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

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

فرآیند Mover

زمانی که کاربر از یک واحد سازمانی به واحد دیگر منتقل می‌شود، مجوزهای قبلی باید بازبینی شوند.

یکی از خطرات رایج در سازمان‌ها، انباشته‌شدن دسترسی‌ها در طول زمان است.

ممکن است کاربر نقش جدیدی دریافت کند اما مجوزهای قبلی او حذف نشوند.

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

فرآیند Leaver

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

نکته مهم این است که غیرفعال‌سازی حساب در IdP الزاماً تمام نشست‌های فعال در Service Providerها را بلافاصله از بین نمی‌برد.

برای مدیریت این مشکل باید وضعیت نشست‌های موجود، قابلیت خروج و امکان لغو دسترسی در سرویس‌های مقصد بررسی شود.

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

SCIM جایگزین SAML نیست، بلکه می‌تواند فرآیند Provisioning و مدیریت حساب‌ها را تکمیل کند.

آیا Single Logout در SAML امنیت را تضمین می‌کند؟

Single Logout یا SLO قابلیتی است که برای هماهنگ‌سازی خروج کاربر از نشست‌های مرتبط طراحی شده است.

از نظر نظری، این قابلیت می‌تواند به مدیریت بهتر خروج از چند برنامه کمک کند.

اما پیاده‌سازی عملی آن همیشه ساده نیست.

برخی برنامه‌ها ممکن است تمام الگوهای SLO را پشتیبانی نکنند یا در شرایطی مانند اختلال شبکه، خروج هماهنگ به‌صورت کامل انجام نشود.

همچنین ممکن است کاربر در چند دستگاه یا مرورگر نشست مستقل داشته باشد.

بنابراین، سازمان نباید صرفاً به SLO برای لغو فوری تمام دسترسی‌ها تکیه کند.

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

در زمان وقوع حادثه امنیتی، تیم پاسخ‌گویی باید بداند چگونه نشست‌های فعال را در هر Service Provider شناسایی و مدیریت کند.

تست امنیت SAML چگونه انجام می‌شود؟

تست امنیت SAML باید در محیط مجاز و با هدف شناسایی ضعف‌های پیکربندی و پیاده‌سازی انجام شود.

این فرآیند تنها به بررسی موفقیت ورود کاربران محدود نیست.

یک سامانه ممکن است در شرایط معمول به‌درستی کار کند، اما در مواجهه با پیام‌های نامعتبر یا وضعیت‌های غیرمنتظره، رفتار ناامن داشته باشد.

بررسی معماری و نقاط اعتماد

اولین مرحله، مستندسازی مسیرهای ارتباطی میان IdP، SP و مرورگر است.

تیم امنیت باید مشخص کند کدام سرویس‌ها مسئول صدور Assertion هستند، کدام کلیدها مورد اعتماد قرار گرفته‌اند و پیام‌ها از چه Endpointهایی عبور می‌کنند.

همچنین باید مشخص شود چه کسانی مجوز تغییر Metadata یا تنظیمات اعتماد را دارند.

این بررسی به شناسایی نقاط شکست مشترک کمک می‌کند.

بررسی تنظیمات امضای دیجیتال

در این مرحله باید مشخص شود کدام عناصر پیام امضا می‌شوند و Service Provider دقیقاً چه الزاماتی را بررسی می‌کند.

برای نمونه، اگر سیاست سازمان امضای Assertion را الزامی کرده است، برنامه نباید پیام فاقد این امضا را صرفاً به دلیل امضاشدن Response بپذیرد.

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

بررسی سیاست‌های زمانی

تیم امنیت باید مدت اعتبار Assertionها و سیاست اختلاف ساعت را بررسی کند.

پذیرش پیام‌های خارج از بازه معتبر نباید امکان‌پذیر باشد.

همچنین لازم است مشخص شود آیا شناسه Assertionهای مصرف‌شده برای جلوگیری از Replay ثبت می‌شوند یا خیر.

بررسی مدیریت حساب و مجوز

تست امنیت باید ارتباط هویت فدرال با حساب داخلی و نقش‌های کاربری را نیز پوشش دهد.

برای مثال، تغییر ایمیل، حذف کاربر از گروه سازمانی یا غیرفعال‌سازی حساب باید نتایج قابل پیش‌بینی و امنی داشته باشد.

در این مرحله، بررسی دسترسی‌های مدیریتی اهمیت ویژه‌ای دارد.

بررسی سناریوهای خطا

یک ارزیابی مناسب باید رفتار سامانه را هنگام رخداد خطاهای مشروع و کنترل‌شده بررسی کند.

از جمله این وضعیت‌ها می‌توان به پایان اعتبار گواهی آزمایشی، اختلال IdP، عدم تطابق تنظیمات و خطاهای زمان‌بندی اشاره کرد.

هدف این است که برنامه در زمان بروز خطا، به وضعیت ناامن تغییر نکند.

ثبت و تحلیل نتایج

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

در محیط‌های عملیاتی، هرگونه آزمون باید با مجوز، محدوده مشخص و هماهنگی مسئولان سامانه انجام شود.

همچنین بهتر است داده‌های احراز هویت واقعی کاربران در گزارش‌ها افشا نشوند.

مانیتورینگ و ثبت رویدادهای امنیتی SAML

یکی از ارکان امنیت سازمانی، توانایی شناسایی رویدادهای غیرعادی و بررسی حوادث است.

در زیرساخت SAML، ثبت رویدادهای احراز هویت باید در سمت IdP و SP انجام شود.

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

ثبت تغییرات گواهی‌ها، تنظیمات اعتماد و سیاست‌های احراز هویت نیز اهمیت زیادی دارد.

چه رویدادهایی اهمیت بیشتری دارند؟

رد مکرر پیام‌های دارای امضای نامعتبر، افزایش ناگهانی خطاهای Audience یا Destination و تلاش‌های غیرعادی ورود به حساب‌های مدیریتی می‌توانند نیازمند بررسی باشند.

البته وجود چنین رویدادهایی به‌تنهایی اثبات وقوع حمله نیست.

برای مثال، خطای امضا ممکن است ناشی از چرخش ناهماهنگ گواهی‌ها باشد.

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

جلوگیری از افشای اطلاعات در لاگ‌ها

ثبت کامل و بدون کنترل SAMLResponse در لاگ‌های معمولی می‌تواند باعث نگهداری اطلاعات هویتی و داده‌های حساس شود.

بهتر است اطلاعات ضروری برای عیب‌یابی ثبت شوند و از ذخیره غیرضروری Assertionهای کامل جلوگیری شود.

لاگ‌های امنیتی نیز باید دارای کنترل دسترسی، سیاست نگهداری و محافظت در برابر تغییرات غیرمجاز باشند.

در سازمان‌های بزرگ، ارسال رویدادهای مرتبط به سامانه SIEM می‌تواند به تحلیل متمرکز کمک کند.

مشکلات رایج SAML و روش عیب‌یابی امن

یکی از چالش‌های عملی استفاده از SAML، پیچیدگی عیب‌یابی در زمان اختلال ورود است.

از آنجا که چند سامانه مستقل در فرآیند احراز هویت مشارکت دارند، منشأ خطا همیشه مشخص نیست.

خطای Invalid Signature

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

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

راهکار مناسب، بررسی تنظیمات اعتماد و وضعیت چرخش گواهی است.

غیرفعال‌کردن اعتبارسنجی امضا برای رفع موقت خطا، یک اقدام ناامن است و نباید انجام شود.

خطای Audience Mismatch

این خطا نشان می‌دهد شناسه مخاطب Assertion با شناسه مورد انتظار برنامه تطبیق ندارد.

ممکن است Entity ID در سمت IdP یا SP اشتباه ثبت شده باشد.

برای رفع مشکل باید شناسه‌های پیکربندی‌شده در دو سمت بررسی شوند.

حذف کنترل Audience راهکار مناسبی نیست.

خطای Assertion Expired

این وضعیت می‌تواند ناشی از پایان بازه اعتبار پیام یا اختلاف ساعت سرورها باشد.

بررسی زمان سیستم، همگام‌سازی ساعت و تنظیمات اعتبار Assertion اهمیت دارد.

افزایش غیرضروری زمان اعتبار نباید به اولین راهکار تبدیل شود.

خطای Recipient یا Destination

گاهی آدرس ACS در IdP با آدرس واقعی مورد انتظار Service Provider تفاوت دارد.

این موضوع در معماری‌های دارای Reverse Proxy، Load Balancer یا چند دامنه بیشتر دیده می‌شود.

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

نباید برای حل مشکل، اعتبارسنجی مقصد به‌صورت کلی غیرفعال شود.

ورود موفق بدون دسترسی مناسب

در برخی موارد، کاربر با موفقیت احراز هویت می‌شود اما امکان استفاده از برنامه را ندارد.

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

باید میان Authentication و Authorization تفاوت قائل شد.

موفقیت در احراز هویت صرفاً اثبات می‌کند فرآیند شناسایی طبق سیاست مربوط انجام شده است؛ نه اینکه کاربر مجوز تمام فعالیت‌ها را دارد.

SAML در محیط‌های Cloud و Hybrid چه چالش‌هایی دارد؟

بسیاری از سازمان‌ها از معماری Hybrid استفاده می‌کنند؛ یعنی بخشی از سرویس‌ها در زیرساخت داخلی و بخشی در فضای ابری قرار دارند.

SAML می‌تواند ارتباط هویتی میان این محیط‌ها را فراهم کند.

اما این انعطاف‌پذیری، چالش‌های مدیریتی جدیدی نیز ایجاد می‌کند.

وابستگی به دسترس‌پذیری Identity Provider

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

نشست‌های موجود نیز بسته به سیاست هر برنامه ممکن است همچنان فعال بمانند یا به‌تدریج منقضی شوند.

برای کاهش این خطر، سازمان باید درباره افزونگی، بازیابی بحران و دسترسی اضطراری برنامه‌ریزی کند.

پیچیدگی مدیریت چند Identity Provider

برخی سازمان‌ها به دلیل ادغام شرکت‌ها، همکاری با پیمانکاران یا ساختار چندمستأجری از چند IdP استفاده می‌کنند.

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

همچنین نباید ویژگی‌های هویتی ارائه‌شده توسط تمام IdPها بدون ارزیابی اعتبار و معنای آن‌ها یکسان تلقی شوند.

ریسک تغییرات پیکربندی

تغییر دامنه، مهاجرت سرویس ابری یا چرخش گواهی می‌تواند ارتباط SAML را تحت تأثیر قرار دهد.

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

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

انتخاب راهکار SAML مناسب برای سازمان

انتخاب پلتفرم SAML نباید تنها براساس هزینه یا تعداد قابلیت‌های تبلیغ‌شده انجام شود.

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

سازگاری با برنامه‌های موجود

برخی نرم‌افزارهای سازمانی تنها از پروفایل‌ها یا Bindingهای مشخصی پشتیبانی می‌کنند.

پیش از انتخاب IdP باید سازگاری آن با Service Providerهای اصلی بررسی شود.

همچنین لازم است ویژگی‌هایی مانند نگاشت گروه‌ها، مدیریت حساب‌ها و پشتیبانی از شناسه‌های پایدار ارزیابی شوند.

قابلیت‌های امنیتی

پشتیبانی از MFA، مدیریت امن کلیدها، سیاست‌های دسترسی مشروط و ثبت رویدادها از معیارهای مهم هستند.

محصول باید امکان تعریف دقیق روابط اعتماد و محدودکردن الگوریتم‌های رمزنگاری را فراهم کند.

وجود قابلیت‌های امنیتی کافی نیست؛ سهولت اجرای صحیح آن‌ها و امکان ممیزی تنظیمات نیز اهمیت دارد.

مدیریت و پشتیبانی

چرخه انتشار به‌روزرسانی‌های امنیتی، کیفیت مستندات، امکان دریافت پشتیبانی و قابلیت بازیابی در زمان بحران باید بررسی شوند.

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

حفظ حریم خصوصی

تبادل اطلاعات هویتی باید براساس اصل کمینه‌سازی داده انجام شود.

برای مثال، اگر یک برنامه تنها به شناسه کاربر و گروه سازمانی او نیاز دارد، انتقال اطلاعات شخصی اضافی ضرورتی ندارد.

همچنین باید مشخص باشد داده‌های هویتی در چه سامانه‌هایی ذخیره می‌شوند و چه اشخاصی به آن‌ها دسترسی دارند.

اشتباهات رایج در پیاده‌سازی SAML

برخی تصمیم‌های نادرست در زمان راه‌اندازی SAML ممکن است سال‌ها در زیرساخت سازمان باقی بمانند.

شناخت این خطاها به پیشگیری از مشکلات امنیتی و عملیاتی کمک می‌کند.

اعتماد کامل به هر پیام دارای امضای معتبر

امضای معتبر تنها یکی از شرایط پذیرش پیام است.

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

غیرفعال‌کردن کنترل‌های امنیتی برای رفع خطا

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

این اقدام ممکن است مشکل ظاهری را برطرف کند، اما رابطه اعتماد سامانه را تضعیف می‌کند.

راهکار درست، شناسایی علت ناسازگاری و اصلاح پیکربندی است.

استفاده از گواهی‌های قدیمی بدون برنامه چرخش

نبود برنامه مدیریت گواهی‌ها می‌تواند هم به اختلال در دسترسی و هم به افزایش ریسک امنیتی منجر شود.

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

یکسان‌دانستن احراز هویت و مجوز دسترسی

SAML می‌تواند اطلاعات هویت یا برخی ویژگی‌های کاربر را منتقل کند، اما برنامه مقصد همچنان مسئول اعمال سیاست‌های مجوزدهی است.

نادیده‌گرفتن این تفاوت می‌تواند باعث اعطای دسترسی بیش از حد شود.

اعتماد به تمام داده‌های Attribute

ویژگی‌های موجود در Assertion باید از نظر منشأ، معنا و نحوه استفاده بررسی شوند.

برای مثال، یک مقدار متنی با عنوان Administrator نباید بدون سیاست نگاشت مشخص و منبع مورد اعتماد، باعث ایجاد دسترسی مدیریتی شود.

نادیده‌گرفتن نشست‌های باقی‌مانده

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

سیاست‌های Session Management باید برای هر برنامه حساس تعریف شوند.

نگهداری اطلاعات حساس در لاگ‌ها

ذخیره بی‌رویه پیام‌های SAML می‌تواند اطلاعات کاربران را در معرض دسترسی غیرضروری قرار دهد.

بهتر است ثبت وقایع براساس نیاز امنیتی و با حداقل داده ضروری انجام شود.

پیاده‌سازی اختصاصی بدون ارزیابی تخصصی

ساخت یک پردازشگر اختصاصی SAML ممکن است در ظاهر ساده به نظر برسد، اما جزئیات رمزنگاری، XML و پروفایل‌های استاندارد پیچیده هستند.

استفاده از پیاده‌سازی‌های معتبر و انجام ارزیابی امنیتی معمولاً ریسک کمتری دارد.

آینده SAML در سیستم‌های احراز هویت سازمانی

با گسترش معماری‌های ابری، برنامه‌های موبایل و APIهای مدرن، استفاده از فناوری‌هایی مانند OpenID Connect افزایش یافته است.

با این وجود، SAML همچنان در بخش مهمی از اکوسیستم سازمانی حضور دارد.

دلیل این موضوع تنها وابستگی به فناوری‌های قدیمی نیست.

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

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

برای مثال، یک سازمان ممکن است برنامه‌های قدیمی خود را با SAML نگهداری کند و برای توسعه سرویس‌های جدید از OIDC استفاده کند.

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

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

سؤالات متداول درباره SAML و امنیت آن

SAML چیست و به زبان ساده چه کاری انجام می‌دهد؟

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

آیا SAML امنیت بالایی دارد؟

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

آیا امکان هک SAML وجود دارد؟

مانند سایر فناوری‌ها، پیاده‌سازی‌های SAML ممکن است دارای آسیب‌پذیری باشند. مشکلاتی مانند XML Signature Wrapping، اعتبارسنجی ناقص پیام‌ها، مدیریت ضعیف کلیدها یا خطاهای نگاشت حساب می‌توانند خطر ایجاد کنند. استفاده از استاندارد به‌تنهایی به معنای نبود آسیب‌پذیری نیست.

آیا SAML جایگزین رمز عبور می‌شود؟

SAML می‌تواند نیاز برنامه مقصد به دریافت مستقیم رمز عبور را حذف کند، اما روش احراز هویت واقعی کاربر توسط IdP تعیین می‌شود. این روش ممکن است شامل رمز عبور، MFA، کلید امنیتی یا احراز هویت بدون رمز عبور باشد.

تفاوت SAML و OAuth چیست؟

SAML عمدتاً برای انتقال اطلاعات هویت و احراز هویت فدرال استفاده می‌شود، در حالی که OAuth 2.0 چارچوبی برای واگذاری مجوز دسترسی است. OpenID Connect نیز برای احراز هویت مدرن بر پایه OAuth 2.0 طراحی شده است.

آیا SAML از احراز هویت چندمرحله‌ای پشتیبانی می‌کند؟

بله. در معماری‌های رایج، IdP می‌تواند MFA را اجرا کند و اطلاعات زمینه احراز هویت را از طریق SAML منتقل کند. با این حال، خود SAML تضمین نمی‌کند که MFA واقعاً انجام شده است. این موضوع به سیاست‌های IdP و اعتبارسنجی مناسب SP بستگی دارد.

SAML Assertion چیست؟

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

آیا SAML برای برنامه‌های موبایل مناسب است؟

SAML عمدتاً در سناریوهای وب و ورود سازمانی رایج است. برای بسیاری از برنامه‌های موبایل جدید، OpenID Connect انتخاب مناسب‌تری محسوب می‌شود؛ زیرا با جریان‌های احراز هویت و معماری‌های مدرن هماهنگی بیشتری دارد. با این حال، انتخاب نهایی به زیرساخت و نیازهای برنامه وابسته است.

آیا غیرفعال‌کردن کاربر در IdP تمام نشست‌های او را می‌بندد؟

خیر، نه لزوماً. برخی Service Providerها نشست مستقل دارند و ممکن است پس از غیرفعال‌سازی حساب در IdP نیز برای مدتی فعال باقی بمانند. سازمان باید سیاست‌های لغو نشست، انقضای دسترسی و مدیریت حساب را به‌صورت جداگانه بررسی کند.

آیا استفاده از HTTPS برای امنیت SAML کافی است؟

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

بهترین روش جلوگیری از حملات Replay در SAML چیست؟

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

آیا SAML برای سازمان‌های کوچک هم مناسب است؟

بله، اما میزان پیچیدگی و هزینه مدیریت باید با نیاز سازمان تناسب داشته باشد. اگر سازمان از چند سرویس دارای قابلیت SAML استفاده می‌کند، یک سرویس مدیریت هویت مناسب می‌تواند مدیریت ورود را ساده‌تر کند. برای برنامه‌های جدید نیز مقایسه با OIDC ضروری است.

جمع‌بندی: چگونه از SAML به‌صورت امن استفاده کنیم؟

SAML یکی از استانداردهای مهم در حوزه احراز هویت فدرال و مدیریت دسترسی سازمانی است. این فناوری امکان تبادل اطلاعات هویتی میان سامانه‌های مستقل را فراهم می‌کند و می‌تواند زیربنای ورود یکپارچه به برنامه‌های سازمانی باشد.

مهم‌ترین مزیت SAML، ایجاد یک مدل اعتماد استاندارد میان Identity Provider و Service Provider است. این مدل می‌تواند مدیریت هویت را ساده‌تر کند و اجرای سیاست‌های امنیتی متمرکز را امکان‌پذیر سازد.

با این حال، امنیت SAML به‌صورت خودکار تضمین نمی‌شود.

ضعف در اعتبارسنجی امضای دیجیتال، پذیرش Assertionهای نامعتبر، مدیریت نادرست گواهی‌ها، نگاشت اشتباه حساب‌های کاربری و کنترل ناکافی نشست‌ها می‌توانند مزایای امنیتی این استاندارد را کاهش دهند.

برای استفاده امن از SAML، سازمان‌ها باید چند اصل اساسی را رعایت کنند:

1. ارتباط اعتماد میان IdP و SP را به‌صورت دقیق تعریف کنند.

1. از کتابخانه‌های معتبر و پیکربندی امن استفاده کنند.

1. تمام شرایط امنیتی پیام‌های SAML را بررسی کنند.

1. کلیدهای خصوصی و گواهی‌های دیجیتال را مطابق چرخه عمر مشخص مدیریت کنند.

1. احراز هویت قوی و مجوزدهی مبتنی بر حداقل دسترسی را اجرا کنند.

1. نشست‌های کاربران و فرآیند حذف دسترسی را مستقل از ورود اولیه مدیریت کنند.

1. ثبت رویدادها، مانیتورینگ و تست امنیتی دوره‌ای را در برنامه عملیاتی قرار دهند.

در نهایت، امنیت SAML حاصل ترکیب استاندارد معتبر، پیاده‌سازی صحیح، مدیریت هویت اصولی و نظارت مستمر است.

سازمانی که تنها به فعال‌سازی SSO اکتفا کند، ممکن است بخش مهمی از ریسک‌های امنیتی را نادیده بگیرد. در مقابل، سازمانی که SAML را بخشی از معماری جامع مدیریت هویت و دسترسی بداند، می‌تواند از مزایای آن برای افزایش امنیت، کنترل بهتر مجوزها و کاهش پیچیدگی عملیاتی استفاده کند.