SCIM چیست؟ بررسی امنیت مدیریت و Provisioning هویت کاربران با SCIM

SCIM چیست؟ SCIM مخفف System for Cross-domain Identity Management و یک استاندارد باز برای مدیریت خودکار هویت کاربران میان سامانه‌های مختلف است. این استاندارد با استفاده از APIهای مبتنی بر HTTP، امکان ایجاد، به‌روزرسانی، غیرفعال‌سازی و مدیریت حساب‌ها و گروه‌های کاربری را فراهم می‌کند. مهم‌ترین کاربرد امنیتی SCIM، کاهش حساب‌های رهاشده، هماهنگ‌سازی مجوزها و کنترل چرخه عمر دسترسی کاربران در سرویس‌های سازمانی است.

امنیت SCIM زمانی به‌درستی تأمین می‌شود که ارتباطات رمزنگاری شوند، دسترسی API محدود باشد، توکن‌های مدیریتی محافظت شوند و عملیات Provisioning و Deprovisioning به‌شکل قابل‌ردیابی و کنترل‌شده انجام شوند.

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

تصور کنید یک شرکت ۵۰۰ کارمند دارد و برای فعالیت روزانه از سرویس‌های مختلفی مانند ایمیل سازمانی، فضای ذخیره‌سازی ابری، سامانه مدیریت پروژه، پنل مالی، نرم‌افزار CRM و ابزارهای ارتباط داخلی استفاده می‌کند.

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

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

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

این وضعیت با مفهومی به نام Orphaned Account یا حساب کاربری رهاشده ارتباط دارد؛ حسابی که مالکیت، ضرورت یا وضعیت دسترسی آن دیگر با ساختار واقعی سازمان هماهنگ نیست.

مدیریت دستی هویت همچنین می‌تواند باعث مشکلات دیگری شود:

• ایجاد حساب‌های تکراری برای یک فرد
• اختصاص مجوزهای بیش‌ازحد
• فراموش‌شدن حذف دسترسی کارکنان سابق
• تأخیر در اعمال تغییرات سازمانی
• ناسازگاری اطلاعات کاربران میان سرویس‌ها
• افزایش بار کاری تیم فناوری اطلاعات
• نبود تاریخچه قابل‌اعتماد از تغییرات حساب‌ها
• دشوارشدن بررسی رویدادهای امنیتی

استاندارد SCIM برای کاهش چنین مشکلاتی طراحی شده است.

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

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

بنابراین، استفاده از SCIM باید همراه با طراحی امنیتی مناسب انجام شود.

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

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

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

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

مفهوم System for Cross-domain Identity Management

عبارت System for Cross-domain Identity Management به مدیریت هویت میان دامنه‌های مدیریتی مختلف اشاره دارد.

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

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

SCIM امکان انتقال اطلاعات هویت میان این محیط‌ها را فراهم می‌کند.

استاندارد SCIM 2.0 چیست؟

SCIM 2.0 نسخه شناخته‌شده این استاندارد است که اجزای اصلی آن در مشخصات IETF تعریف شده‌اند.

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

دو بخش مهم آن عبارت‌اند از:

SCIM Core Schema: ساختار منابعی مانند User و Group و ویژگی‌های مربوط به آن‌ها را مشخص می‌کند.

SCIM Protocol: عملیات استاندارد مدیریت منابع، جست‌وجو، ویرایش و حذف را از طریق HTTP تعریف می‌کند.

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

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

خیر.

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

برای مثال، SCIM می‌تواند حساب یک کارمند را در نرم‌افزار سازمانی ایجاد کند، اما فرایند ورود آن کارمند ممکن است با SAML، OpenID Connect یا روش دیگری انجام شود.

این تفاوت در طراحی امنیت هویت اهمیت بسیار زیادی دارد.

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

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

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

کاهش حساب‌های کاربری رهاشده

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

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

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

کاهش خطاهای انسانی

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

Provisioning خودکار می‌تواند این خطاها را کاهش دهد؛ به‌شرط آنکه Mapping یا نگاشت ویژگی‌ها به‌درستی تنظیم شده باشد.

کنترل بهتر تغییرات سازمانی

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

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

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

افزایش قابلیت حسابرسی

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

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

معماری SCIM چگونه کار می‌کند؟

معماری SCIM معمولاً شامل یک سامانه ارسال‌کننده درخواست و یک سرویس دریافت‌کننده است.

SCIM Client چیست؟

SCIM Client سامانه‌ای است که درخواست‌های مدیریت هویت را ارسال می‌کند.

این نقش معمولاً توسط یک Identity Provider یا سامانه مدیریت هویت سازمانی انجام می‌شود.

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

SCIM Server چیست؟

SCIM Server یا SCIM Service Provider سرویسی است که API استاندارد SCIM را ارائه می‌دهد و درخواست‌ها را پردازش می‌کند.

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

نقش SCIM Server با مفهوم کلی Identity Provider تفاوت دارد. یک محصول مدیریت هویت می‌تواند بسته به سناریو، در یک ارتباط نقش Client و در ارتباط دیگری نقش Server را داشته باشد.

منبع معتبر اطلاعات یا Source of Truth

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

برای مثال:

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

این تفکیک مانع ایجاد تعارض‌های غیرضروری می‌شود.

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

جریان اطلاعات در معماری SCIM

یک جریان رایج به این شکل است:

1. اطلاعات کارمند در سیستم مرجع ایجاد یا تغییر می‌کند.
2. سامانه مدیریت هویت تغییر را شناسایی می‌کند.
3. بررسی می‌شود که کاربر باید به کدام برنامه‌ها دسترسی داشته باشد.
4. داده‌های کاربر به ساختار SCIM تبدیل می‌شوند.
5. درخواست API به سرویس مقصد ارسال می‌شود.
6. سرویس مقصد اعتبار درخواست و مجوز آن را بررسی می‌کند.
7. عملیات ایجاد یا تغییر حساب اجرا می‌شود.
8. نتیجه برای سامانه ارسال‌کننده ثبت می‌شود.

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

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

Provisioning در SCIM چیست؟

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

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

ایجاد خودکار حساب کاربری

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

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

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

به‌روزرسانی اطلاعات کاربران

Provisioning فقط به ایجاد حساب محدود نمی‌شود.

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

SCIM امکان ارسال این تغییرات را فراهم می‌کند تا سامانه مقصد اطلاعات جدید را دریافت کند.

مدیریت عضویت در گروه‌ها

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

SCIM می‌تواند منابع Group و فهرست اعضای آن‌ها را مدیریت کند.

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

بنابراین ایجاد یا تغییر عضویت گروه باید با سیاست کنترل دسترسی هماهنگ باشد.

Deprovisioning چیست و چه نقشی در امنیت SCIM دارد؟

Deprovisioning به فرایند حذف یا لغو دسترسی کاربر به منابعی گفته می‌شود که دیگر به آن‌ها نیاز ندارد.

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

غیرفعال‌سازی حساب با active=false

در ساختار استاندارد SCIM، ویژگی active وضعیت اداری حساب کاربر را نشان می‌دهد.

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

اما باید توجه داشت که غیرفعال‌سازی، حذف دائمی و باطل‌کردن نشست‌های فعال لزوماً عملیات یکسانی نیستند.

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

تفاوت غیرفعال‌سازی و حذف دائمی

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

در حذف دائمی، منبع هویت از سامانه مقصد حذف می‌شود یا وارد فرایند حذف نهایی می‌گردد.

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

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

خطر تأخیر در Deprovisioning

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

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

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

ابطال نشست‌ها و توکن‌های قبلی

یکی از مهم‌ترین نکات امنیت SCIM این است که تغییر active به false الزاماً تمام Sessionها، Refresh Tokenها و API Tokenهای قبلی را باطل نمی‌کند.

برای قطع کامل دسترسی باید رفتار سرویس مقصد بررسی شود.

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

چرخه عمر هویت کاربران با مدل Joiner، Mover و Leaver

مدیریت چرخه عمر هویت معمولاً با مدل Joiner-Mover-Leaver یا JML توضیح داده می‌شود.

Joiner: ورود کاربر جدید

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

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

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

Mover: تغییر سمت یا واحد سازمانی

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

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

یکی از خطرات مهم این مرحله، تجمع تدریجی مجوزها یا Privilege Accumulation است.

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

Leaver: خروج کاربر

در مرحله Leaver، همکاری کاربر با سازمان پایان می‌یابد.

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

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

ساختار داده SCIM و ویژگی‌های مهم هویت کاربران

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

شناخت این ساختار برای جلوگیری از خطاهای امنیتی ضروری است.

شناسه id

ویژگی id شناسه اختصاص‌داده‌شده توسط سرویس مقصد به منبع است.

این شناسه باید در محدوده موردنظر منحصربه‌فرد و پایدار باشد و برای شناسایی منبع استفاده می‌شود.

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

شناسه externalId

ویژگی externalId شناسه‌ای است که توسط سامانه ارسال‌کننده تعیین می‌شود.

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

در محیط‌های چندمستاجری یا Multi-Tenant، شناسه‌های خارجی باید در محدوده سازمان یا Tenant صحیح بررسی شوند.

نباید فرض کرد یک externalId در تمام سازمان‌های مستقل جهان یکتا است.

ویژگی userName

ویژگی userName نام کاربری مورد استفاده در سرویس مقصد را مشخص می‌کند.

این مقدار ممکن است مشابه ایمیل باشد، اما الزاماً همیشه برابر با آدرس ایمیل نیست.

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

ویژگی active

ویژگی active وضعیت اداری حساب را مشخص می‌کند.

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

منابع Group و members

منبع Group برای نمایش گروه‌ها و اعضای آن‌ها استفاده می‌شود.

ویژگی members می‌تواند شامل ارجاع به منابع کاربر یا گروه باشد.

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

ویژگی‌های سازمانی

SCIM از توسعه‌های ساختاری برای اطلاعات سازمانی مانند موارد زیر پشتیبانی می‌کند:

• شناسه کارمندی
• واحد سازمانی
• بخش یا Division
• مرکز هزینه
• سازمان
• مدیر مستقیم

انتقال هر ویژگی باید دارای ضرورت مشخص باشد.

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

SCIM API چیست و چه عملیاتی انجام می‌دهد؟

SCIM API رابط استانداردی برای مدیریت منابع هویت است.

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

عملیات POST

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

ایجاد حساب کاربری جدید یکی از کاربردهای رایج آن است.

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

عملیات GET

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

برای مثال، یک SCIM Client می‌تواند وجود حساب کاربر را بررسی کند.

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

عملیات PUT

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

در پیاده‌سازی این روش باید ویژگی‌های Read-Only، Immutable و سایر محدودیت‌های Schema رعایت شوند.

عملیات PATCH

روش PATCH برای اعمال تغییرات جزئی به منبع استفاده می‌شود.

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

به دلیل حساسیت تغییرات جزئی، اعتبارسنجی مسیر ویژگی، نوع عملیات و مجوز آن اهمیت دارد.

عملیات DELETE

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

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

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

مسیرهای متداول SCIM

در SCIM 2.0 مسیرهای شناخته‌شده‌ای مانند موارد زیر استفاده می‌شوند:

• /Users برای مدیریت کاربران
• /Groups برای مدیریت گروه‌ها
• /Schemas برای مشاهده تعریف ساختارها
• /ResourceTypes برای شناسایی انواع منابع
• /ServiceProviderConfig برای اعلام قابلیت‌های سرویس

سرویس‌ها معمولاً این مسیرها را زیر یک Base URL نسخه‌دار مانند /scim/v2/ قرار می‌دهند.

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

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

یکی از موضوعات مهم در امنیت مدیریت هویت، تفکیک Provisioning از Authentication و Authorization است.

تفاوت SCIM و SAML

SAML عمدتاً برای تبادل اطلاعات احراز هویت و پیاده‌سازی Single Sign-On استفاده می‌شود.

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

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

تفاوت SCIM و OpenID Connect

OpenID Connect یا OIDC لایه‌ای هویتی بر پایه OAuth 2.0 است که امکان احراز هویت کاربران و دریافت اطلاعات هویت آن‌ها را فراهم می‌کند.

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

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

تفاوت SCIM و OAuth 2.0

OAuth 2.0 چارچوبی برای اعطای دسترسی محدود به منابع است.

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

تفاوت SCIM و LDAP

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

SCIM برای یکپارچه‌سازی مدیریت هویت میان سرویس‌ها از طریق APIهای وب طراحی شده است.

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

جدول مقایسه فناوری‌های مدیریت هویت

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

مهم‌ترین تهدیدات امنیتی SCIM کدام‌اند؟

امنیت SCIM باید با توجه به حساسیت عملیات مدیریتی آن ارزیابی شود.

این API می‌تواند بر تعداد زیادی حساب کاربری و مجوز دسترسی تأثیر بگذارد.

سرقت توکن SCIM

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

شدت پیامد به دامنه دسترسی، محدودیت‌های API و کنترل‌های امنیتی بستگی دارد.

اختصاص مجوزهای بیش‌ازحد

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

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

دسترسی به منابع Tenant دیگر

در برنامه‌های Multi-Tenant، اطلاعات کاربران سازمان‌های مختلف باید از یکدیگر جدا باشند.

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

تغییر غیرمجاز عضویت گروه‌ها

در بعضی برنامه‌ها، عضویت در گروه‌های خاص باعث اعطای مجوز مدیریتی می‌شود.

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

غیرفعال‌سازی گسترده و اشتباهی

تنظیمات نادرست Mapping یا Scope می‌توانند باعث شوند مجموعه بزرگی از کاربران به‌اشتباه خارج از محدوده Provisioning تشخیص داده شوند.

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

افشای اطلاعات شخصی

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

ثبت این اطلاعات در لاگ‌های عمومی یا دراختیارگذاشتن آن‌ها به سرویس‌های غیرضروری خطر نقض حریم خصوصی را افزایش می‌دهد.

حملات مصرف منابع

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

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

امنیت احراز هویت در SCIM API

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

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

استفاده از OAuth 2.0

در برخی معماری‌ها، OAuth 2.0 برای صدور توکن دسترسی به SCIM API استفاده می‌شود.

برای ارتباطات سرویس به سرویس، جریان‌های مناسب ماشین به ماشین مانند Client Credentials قابل‌بررسی هستند.

توکن باید برای API موردنظر صادر شود و فقط عملیات مجاز را پوشش دهد.

خطر استفاده از توکن‌های دائمی

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

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

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

اصل Least Privilege برای توکن‌ها

توکن Provisioning نباید مجوزهایی فراتر از وظایف واقعی خود داشته باشد.

برای مثال، اگر یک Client فقط مجاز به مدیریت کاربران یک سازمان است، نباید بتواند منابع سازمان دیگر را تغییر دهد.

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

نگهداری امن توکن‌ها

توکن SCIM نباید در موارد زیر قرار گیرد:

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

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

استفاده از HTTPS و TLS در امنیت SCIM

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

به همین دلیل، محافظت از کانال ارتباطی ضروری است.

رمزنگاری ارتباطات

SCIM Client و SCIM Server باید از ارتباطات دارای امنیت لایه انتقال استفاده کنند.

در مشخصات اصلی SCIM 2.0، پشتیبانی از TLS 1.2 برای سرویس‌دهنده الزام شده است.

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

اعتبارسنجی گواهی سرور

استفاده از HTTPS زمانی مؤثر است که اعتبار گواهی و هویت سرویس مقصد نیز بررسی شود.

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

استفاده از Mutual TLS

در محیط‌های حساس می‌توان Mutual TLS یا mTLS را بررسی کرد.

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

mTLS یک لایه دفاعی تکمیلی است و جایگزین کنترل مجوز عملیات SCIM نمی‌شود.

محدودسازی دسترسی شبکه

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

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

کنترل دسترسی در SCIM و جلوگیری از Privilege Escalation

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

Authorization در سطح هر درخواست

SCIM Server باید برای هر درخواست بررسی کند:

• چه Client یا هویتی درخواست را ارسال کرده است؟
• این Client به کدام سازمان تعلق دارد؟
• آیا اجازه مشاهده یا تغییر منبع را دارد؟
• آیا عملیات موردنظر مجاز است؟
• آیا مجاز به تغییر ویژگی موردنظر است؟
• آیا درخواست با سیاست‌های امنیتی سرویس سازگار است؟

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

جلوگیری از Broken Object Level Authorization

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

در SCIM، منابع User و Group نمونه‌هایی از اشیای حساس هستند.

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

کنترل دسترسی ویژگی‌ها

تمام ویژگی‌های حساب اهمیت امنیتی یکسانی ندارند.

تغییر نام نمایشی کاربر ممکن است پیامد متفاوتی نسبت به تغییر وضعیت حساب یا ویژگی مرتبط با نقش مدیریتی داشته باشد.

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

جلوگیری از افزایش غیرمجاز سطح دسترسی

SCIM Server نباید اجازه دهد یک Client با سطح دسترسی محدود، از طریق تغییر گروه یا ویژگی حساب، مجوزهای مدیریتی غیرمجاز ایجاد کند.

باید ارتباط میان عضویت گروه و مجوزهای واقعی برنامه به‌صورت شفاف تعریف شود.

امنیت SCIM در محیط‌های Multi-Tenant

در نرم‌افزارهای SaaS، یک سرویس ممکن است هم‌زمان به چندین شرکت خدمات ارائه دهد.

در چنین شرایطی، جداسازی اطلاعات سازمان‌ها یکی از الزامات اصلی امنیت SCIM است.

جداسازی داده‌ها بر اساس Tenant

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

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

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

خطر اعتماد به Tenant ID ارسالی

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

محدوده مجاز باید از هویت احرازشده Client و سیاست دسترسی سمت سرور استخراج شود.

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

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

بنابراین طراحی پایگاه داده و منطق تطبیق حساب باید محدوده Tenant را در نظر بگیرد.

ایمن‌سازی جست‌وجو و فیلتر

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

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

امنیت گروه‌ها و مدیریت نقش‌ها با SCIM

گروه‌ها یکی از حساس‌ترین بخش‌های Provisioning هستند؛ زیرا ممکن است مستقیماً بر مجوزهای کاربران اثر بگذارند.

ارتباط Group با RBAC

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

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

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

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

اهمیت کنترل Group Mapping

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

تغییر ناخواسته این Mapping ممکن است باعث اعطای مجوز گسترده به کاربران شود.

گروه‌های حساس

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

این سیاست‌ها می‌توانند شامل تأیید تغییرات، ثبت رویداد و بازبینی دوره‌ای اعضا باشند.

گروه‌های تو در تو

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

پشتیبانی واقعی از این ویژگی و نحوه محاسبه عضویت مؤثر باید در سرویس مقصد بررسی شود.

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

اعتبارسنجی ورودی‌ها و جلوگیری از آسیب‌پذیری‌های SCIM API

SCIM یک API تحت وب است و در معرض بسیاری از خطرات رایج APIها قرار دارد.

بنابراین رعایت استاندارد داده بدون اعتبارسنجی امنیتی کافی نیست.

اعتبارسنجی Schema

سرور باید ساختار درخواست‌ها و نوع ویژگی‌ها را بر اساس Schema تعریف‌شده بررسی کند.

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

جلوگیری از Injection

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

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

محدودکردن پیچیدگی درخواست‌ها

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

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

محافظت در برابر خطاهای Parsing

پیاده‌سازی باید داده‌های JSON نامعتبر، ویژگی‌های ناشناخته و ساختارهای ناسازگار را مطابق قواعد مشخص مدیریت کند.

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

کنترل ارجاع به منابع

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

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

مدیریت هم‌زمانی درخواست‌ها و جلوگیری از ناسازگاری اطلاعات

در سیستم‌هایی که چند فرایند اطلاعات کاربران را به‌روزرسانی می‌کنند، امکان بروز Race Condition و بازنویسی ناخواسته داده‌ها وجود دارد.

مفهوم ETag در SCIM

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

ETag می‌تواند نشان‌دهنده نسخه فعلی منبع باشد.

Client در پیاده‌سازی‌های سازگار می‌تواند از If-Match برای اطمینان از تغییرنکردن نسخه منبع استفاده کند.

جلوگیری از Lost Update

فرض کنید دو فرایند هم‌زمان اطلاعات گروهی را تغییر دهند.

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

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

مدیریت خطای تعارض

وقتی نسخه منبع با انتظار Client تطابق ندارد، باید خطا به‌شکل مناسب ثبت و مدیریت شود.

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

اهمیت Idempotency

در عملیات Provisioning باید رفتار تلاش مجدد مشخص باشد.

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

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

حفاظت از اطلاعات شخصی و محرمانگی داده‌ها در SCIM

SCIM ممکن است اطلاعات قابل‌شناسایی اشخاص یا PII را میان چند سامانه منتقل کند.

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

اصل Data Minimization

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

برای مثال، یک ابزار ساده مدیریت پروژه ممکن است به نام، ایمیل و وضعیت حساب نیاز داشته باشد، اما دریافت اطلاعات کامل منابع انسانی برای آن ضروری نباشد.

حفاظت از داده‌های حساس

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

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

سیاست نگهداری داده

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

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

SCIM به‌تنهایی سیاست کامل نگهداری یا حذف داده‌های شخصی را تعیین نمی‌کند.

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

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

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

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

مدیریت خطا، Rate Limiting و پایداری سرویس SCIM

امنیت یکپارچه‌سازی SCIM به پایداری و قابل‌اعتمادبودن آن نیز وابسته است.

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

استفاده از Rate Limiting

Rate Limiting تعداد درخواست‌های مجاز در یک بازه زمانی را محدود می‌کند.

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

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

مدیریت خطای HTTP 429

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

در صورت ارائه Retry-After معتبر، رعایت آن می‌تواند از افزایش فشار روی سرویس جلوگیری کند.

تفاوت خطاهای امنیتی و عملیاتی

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

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

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

جلوگیری از توقف پنهان Provisioning

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

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

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

پیاده‌سازی امن SCIM در زیرساخت‌های سازمانی

اجرای SCIM در محیط Production باید مرحله‌ای و همراه با بررسی امنیتی انجام شود.

مرحله اول: شناسایی سیستم‌های هویت

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

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

مرحله دوم: تعیین مرجع هر ویژگی

برای هر ویژگی مهم باید Source of Truth تعیین شود.

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

مرحله سوم: طراحی شناسه پایدار

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

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

مرحله چهارم: تعریف محدوده Provisioning

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

Provisioning نباید بدون ضرورت تمام کاربران سازمان را شامل شود.

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

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

مجوز آن باید به عملیات ضروری محدود باشد و در محل امن نگهداری شود.

مرحله ششم: بررسی امنیت ارتباطات

اعتبار گواهی TLS، مسیرهای شبکه و تنظیمات ارتباط Client و Server بررسی شوند.

در محیط‌های حساس می‌توان Gateway امنیتی و کنترل‌های اضافی را نیز در نظر گرفت.

مرحله هفتم: تنظیم Attribute Mapping

ویژگی‌های مبدأ و مقصد باید با دقت به یکدیگر نگاشت شوند.

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

مرحله هشتم: آزمایش در محیط غیرعملیاتی

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

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

مرحله نهم: اجرای آزمایشی محدود

بهتر است ابتدا Provisioning برای گروه کوچکی از کاربران اجرا شود.

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

مرحله دهم: فعال‌سازی حسابرسی و هشدار

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

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

مرحله یازدهم: طراحی برنامه بازگشت

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

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

مرحله دوازدهم: بازبینی دوره‌ای

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

نمونه ساختار کاربر در SCIM 2.0

برای درک بهتر عملکرد SCIM می‌توان ساختار ساده یک منبع User را بررسی کرد.

نمونه زیر صرفاً آموزشی است و اطلاعات آن واقعی نیستند.

{
  "schemas": [
    "urn:ietf:params:scim:schemas:core:2.0:User"
  ],
  "id": "user-2048",
  "externalId": "employee-105",
  "userName": "[email protected]",
  "name": {
    "givenName": "Sara",
    "familyName": "Ahmadi"
  },
  "active": true
}

در این نمونه، شناسه id توسط سرویس مقصد به منبع اختصاص داده شده و شناسه externalId برای ارتباط با سامانه مرجع استفاده می‌شود.

ویژگی active نشان‌دهنده وضعیت اداری حساب است.

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

مثال آموزشی غیرفعال‌سازی حساب

در یک فرایند Deprovisioning، Client می‌تواند از عملیات PATCH برای درخواست غیرفعال‌سازی استفاده کند.

نمونه ساختاری:

{
  "schemas": [
    "urn:ietf:params:scim:api:messages:2.0:PatchOp"
  ],
  "Operations": [
    {
      "op": "replace",
      "path": "active",
      "value": false
    }
  ]
}

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

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

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

امنیت SCIM برای برنامه‌های وب و سرویس‌های SaaS

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

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

جداسازی SCIM API از API عمومی

بهتر است API مدیریت هویت دارای سیاست‌های مشخص احراز هویت، مجوزدهی و ثبت رویداد باشد.

می‌توان مسیرهای SCIM را از نظر منطقی و امنیتی از APIهای معمول کاربران تفکیک کرد.

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

استفاده از API Gateway

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

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

امنیت پایگاه داده

حساب اتصال SCIM Server به پایگاه داده باید با حداقل مجوز لازم اجرا شود.

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

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

حساب‌های Service Account باید از حساب کاربران انسانی قابل‌تفکیک باشند.

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

جلوگیری از تغییرات مدیریتی ناخواسته

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

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

چک‌لیست کامل امنیت SCIM برای محیط Production

برای ارزیابی یکپارچه‌سازی SCIM می‌توان از چک‌لیست زیر استفاده کرد.

امنیت معماری و هویت

1. سامانه مرجع هویت برای هر ویژگی مهم مشخص باشد.
2. مسئولیت SCIM Client و SCIM Server تعریف شده باشد.
3. چرخه عمر کاربران مستند شده باشد.
4. محدوده Provisioning به کاربران ضروری محدود باشد.
5. شناسه‌های حساب پایدار و قابل‌ردیابی باشند.
6. منطق تطبیق حساب‌ها از ایجاد رکوردهای تکراری جلوگیری کند.

امنیت احراز هویت و API

1. تمام ارتباطات با TLS مناسب محافظت شوند.
2. اعتبار گواهی سرور بررسی شود.
3. درخواست‌های مدیریتی بدون احراز هویت مناسب پذیرفته نشوند.
4. توکن‌ها فقط مجوزهای ضروری داشته باشند.
5. اعتبارنامه‌ها در مخزن امن نگهداری شوند.
6. امکان لغو و چرخش توکن‌ها وجود داشته باشد.
7. توکن‌های حساس در لاگ‌ها ذخیره نشوند.
8. دسترسی به SCIM API از شبکه‌های غیرضروری محدود شود.

امنیت مجوزها و گروه‌ها

1. مجوز هر عملیات در سمت سرور بررسی شود.
2. دسترسی به منابع بر اساس Tenant کنترل شود.
3. تغییر گروه‌های مدیریتی دارای سیاست مشخص باشد.
4. ویژگی‌های حساس بدون مجوز قابل‌تغییر نباشند.
5. نگاشت گروه‌ها به نقش‌ها بازبینی شود.
6. تغییرات شغلی باعث باقی‌ماندن دسترسی‌های غیرضروری نشوند.

امنیت داده‌ها و پردازش

1. ساختار داده‌ها مطابق Schema اعتبارسنجی شود.
2. ورودی‌های فیلتر و جست‌وجو به‌شکل امن پردازش شوند.
3. حجم و پیچیدگی درخواست‌ها محدود شود.
4. فقط اطلاعات ضروری کاربران منتقل شود.
5. مدت نگهداری اطلاعات شخصی تعریف شده باشد.
6. کنترل‌های مناسب برای درخواست‌های هم‌زمان وجود داشته باشد.
7. خطاها بدون افشای اطلاعات محرمانه مدیریت شوند.

امنیت Deprovisioning

1. غیرفعال‌سازی حساب‌ها به‌درستی آزمایش شده باشد.
2. رفتار سرویس مقصد با active=false مشخص باشد.
3. نحوه باطل‌کردن نشست‌ها و توکن‌های قبلی بررسی شود.
4. حذف دسترسی کاربران خارج‌شده قابل‌پیگیری باشد.
5. برای حساب‌های حساس فرایند لغو فوری دسترسی تعریف شود.
6. تغییرات گسترده و ناخواسته قابل‌شناسایی باشند.

نظارت و نگهداری

1. رویدادهای مهم Provisioning ثبت شوند.
2. خطاهای هماهنگ‌سازی هشدار ایجاد کنند.
3. اختلاف وضعیت کاربران میان سامانه‌ها شناسایی شود.
4. نرخ درخواست‌ها و خطاهای API پایش شود.
5. دسترسی توکن‌ها دوره‌ای بازبینی شود.
6. تغییرات پیکربندی دارای سابقه و تأیید مناسب باشند.
7. فرایند بازیابی پس از خطا آزمایش شده باشد.

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

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

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

تصور اینکه SCIM جایگزین SSO است

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

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

فرض حذف فوری تمام دسترسی‌ها

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

رفتار سرویس مقصد باید آزمایش شود.

استفاده از توکن با مجوز کامل

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

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

اعتماد به ایمیل برای شناسایی همیشگی کاربر

آدرس ایمیل ممکن است تغییر کند یا در آینده مجدداً اختصاص داده شود.

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

نادیده‌گرفتن تنظیمات Group Mapping

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

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

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

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

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

ثبت کامل درخواست‌ها

ذخیره بدون پالایش درخواست‌های SCIM ممکن است باعث افشای اطلاعات کارکنان و اعتبارنامه‌ها شود.

Logging باید بر اساس اصول محرمانگی طراحی شود.

بی‌توجهی به خطاهای هماهنگ‌سازی

موفقیت ورود کاربران به برنامه به معنای موفقیت Provisioning نیست.

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

آزمایش امنیت SCIM پیش از انتشار

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

آزمایش ایجاد و به‌روزرسانی حساب

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

آزمایش غیرفعال‌سازی

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

آزمایش جداسازی Tenant

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

آزمایش مجوز تغییر گروه

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

آزمایش خطاهای ارتباطی

قطع موقت ارتباط یا عدم دسترس‌پذیری سرویس مقصد در محیط آزمایشی می‌تواند برای بررسی رفتار Retry و هشدارها مفید باشد.

آزمایش تغییرات گسترده

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

آزمایش بازیابی

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

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

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

سناریوی اول: خروج کارمند از سازمان

فرض کنید کارمندی به چند سرویس ابری دسترسی دارد.

پس از پایان همکاری، سامانه مرجع وضعیت او را تغییر می‌دهد و سامانه مدیریت هویت فرایند Deprovisioning را آغاز می‌کند.

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

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

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

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

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

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

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

سناریوی سوم: افشای توکن Provisioning

فرض کنید احتمال افشای اعتبارنامه SCIM شناسایی شود.

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

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

سناریوی چهارم: اختلال در سامانه مدیریت هویت

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

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

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

شاخص‌های مهم برای پایش امنیت SCIM

ارزیابی امنیت SCIM نباید صرفاً بر فعال‌بودن اتصال API متکی باشد.

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

زمان لغو دسترسی

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

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

نرخ خطاهای Provisioning

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

تعداد حساب‌های ناسازگار

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

تغییرات غیرعادی گروه‌ها

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

وضعیت اعتبارنامه‌ها

سن اعتبارنامه‌ها، آخرین زمان چرخش و میزان دسترسی آن‌ها باید بخشی از فرایند بازبینی امنیتی باشد.

آینده SCIM و نقش آن در Zero Trust

معماری Zero Trust بر این اصل تأکید می‌کند که دسترسی نباید صرفاً به دلیل حضور کاربر یا سرویس در یک شبکه مورداعتماد پذیرفته شود.

در چنین معماری‌ای، وضعیت هویت، مجوزها و شرایط دسترسی باید به‌صورت مستمر ارزیابی شوند.

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

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

بااین‌حال، SCIM به‌تنهایی پیاده‌سازی Zero Trust نیست.

یک معماری کامل ممکن است به احراز هویت چندعاملی یا MFA، کنترل دسترسی مبتنی بر نقش و ویژگی، مدیریت نشست‌ها، ارزیابی وضعیت دستگاه و نظارت امنیتی نیز نیاز داشته باشد.

SCIM را باید یکی از اجزای زیرساخت Identity Governance و مدیریت چرخه عمر هویت در نظر گرفت.

سؤالات متداول درباره SCIM

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

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

SCIM مخفف چیست؟

SCIM مخفف System for Cross-domain Identity Management است. این عبارت به مدیریت استاندارد اطلاعات هویت میان دامنه‌های مدیریتی مستقل اشاره دارد.

آیا SCIM یک پروتکل امنیتی است؟

SCIM یک استاندارد مدیریت هویت است که کاربردهای امنیتی مهمی دارد. امنیت ارتباط و عملیات آن به سازوکارهایی مانند TLS، احراز هویت API، کنترل دسترسی و مدیریت مناسب اعتبارنامه‌ها وابسته است.

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

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

آیا SCIM جایگزین Active Directory می‌شود؟

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

آیا SCIM از OAuth 2.0 پشتیبانی می‌کند؟

بله، می‌توان از توکن‌های مبتنی بر OAuth 2.0 برای محافظت از SCIM API استفاده کرد. بااین‌حال، انتخاب سازوکار احراز هویت و مجوزدهی به پیاده‌سازی بستگی دارد.

آیا SCIM می‌تواند حساب کارمند سابق را حذف کند؟

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

آیا SCIM نشست‌های فعال کاربر را باطل می‌کند؟

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

آیا استفاده از SCIM خطر امنیتی دارد؟

مانند هر API مدیریتی دیگری، SCIM در صورت تنظیمات نامناسب می‌تواند خطرآفرین باشد. سرقت توکن، دسترسی بیش‌ازحد، ضعف جداسازی Tenant و تغییر غیرمجاز گروه‌ها از خطرات مهم هستند.

آیا SCIM برای برنامه‌های SaaS مناسب است؟

بله. SCIM به ارائه‌دهندگان SaaS کمک می‌کند قابلیت مدیریت متمرکز کاربران را به مشتریان سازمانی ارائه دهند. این ویژگی باید همراه با کنترل مجوزها، جداسازی داده‌ها و ثبت رویدادهای امنیتی طراحی شود.

آیا برای استفاده از SCIM به SSO نیاز داریم؟

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

آیا SCIM از مدیریت گروه‌های کاربری پشتیبانی می‌کند؟

بله. SCIM مدل استاندارد Group و ویژگی اعضای گروه را ارائه می‌دهد. البته نحوه تبدیل عضویت گروه به نقش‌ها و مجوزهای واقعی توسط سرویس مقصد تعیین می‌شود.

مهم‌ترین اقدام برای افزایش امنیت SCIM چیست؟

نمی‌توان یک اقدام را برای تمام معماری‌ها کافی دانست؛ اما محدودسازی مجوز توکن‌های API، حفاظت از ارتباطات، اجرای کنترل دسترسی سمت سرور و آزمایش Deprovisioning از مهم‌ترین اولویت‌ها هستند.

هر چند وقت یک‌بار باید تنظیمات SCIM بررسی شوند؟

زمان‌بندی بازبینی باید با حساسیت سامانه هماهنگ باشد. تغییرات گروه‌های حساس، خطاهای Provisioning، وضعیت حساب‌های غیرفعال و اعتبارنامه‌های API باید به‌صورت منظم پایش شوند.

جمع‌بندی: چگونه امنیت مدیریت هویت کاربران با SCIM را تضمین کنیم؟

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

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

بااین‌حال، امنیت SCIM صرفاً به فعال‌سازی Provisioning وابسته نیست.

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

همچنین فرایند Deprovisioning باید فراتر از تغییر وضعیت حساب بررسی شود؛ زیرا ممکن است نشست‌ها، توکن‌ها یا دسترسی‌های مستقل همچنان معتبر باقی بمانند.

برای سازمان‌هایی که از چندین سرویس ابری و تحت وب استفاده می‌کنند، ترکیب SCIM با SSO، MFA، مدیریت نقش‌ها و سامانه حسابرسی می‌تواند به ایجاد زیرساخت هویتی منظم‌تر کمک کند.

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

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