وقتی یک سازمان تصمیم میگیرد سرویسهایش را بین AWS، Azure و Google Cloud توزیع کند، معمولاً اولین چیزی که برنامهریزی میشود معماری شبکه، هزینهها و سرویسهای ابری است — و آخرین چیزی که به آن فکر میشود، هویت کاربران است. این اشتباه استراتژیک، بعداً به یکی از گرانقیمتترین اشتباهات امنیتی تبدیل میشود.
کنترل هویت کاربران در محیطهای چندابری — که در ادبیات فنی با عنوان Multi-Cloud Identity Management شناخته میشود — تعیین میکند که در دنیایی که منابع سازمانی در چندین پلتفرم ابری پراکنده هستند، چه کسی به چه چیزی، با چه سطح دسترسی و از کجا میتواند وارد شود. این تعریف ساده، اما پیادهسازیاش یکی از پیچیدهترین چالشهای امنیتی دهه اخیر است.
در این مقاله، جامعترین راهنمای فارسیزبان کنترل هویت چندابری را خواهید خواند: از ریسکهای واقعی و معماریهای مختلف Federation تا نقش FIDO در ایمنسازی احراز هویت چندابری، پیادهسازی عملی، و راهکارهای بومی.
حتما بخوانید
برای درک عمیقتر پایههای مفهومی مدیریت هویت و دسترسی پیش از ورود به جزئیات فنی چندابری، این راهنمای جامع IAM و مفاهیم اساسی احراز هویت سازمانی یک نقطه شروع بسیار مناسب است که هر تیم امنیتی باید با آن آشنا باشد.
چرا کنترل هویت در محیط چندابری یک چالش جداگانه است؟
هر بار که یک سازمان یک ابر جدید به معماریاش اضافه میکند، پیچیدگی مدیریت هویت بهشکل تصاعدی افزایش مییابد — نه خطی. اگر یک کارمند در یک ابر یک حساب داشته باشد، مدیریت ساده است. اما وقتی همان کارمند در سه ابر مختلف، چهار سرویس SaaS، و دو سیستم داخلی حساب دارد، مجموعهای از مشکلات هویتی ایجاد میشود که هر کدام میتوانند به یک حادثه امنیتی جدی تبدیل شوند.
مشکل اصلی اینجاست که هر پلتفرم ابری سیستم مدیریت هویت خودش را دارد. AWS IAM، Azure Entra ID و Google Cloud IAM هر کدام مدل داده، زبان سیاستگذاری و ابزار مدیریت متفاوتی دارند. یک تیم امنیتی باید همزمان سه زبان مختلف بلد باشد، سه سیستم را مانیتور کند، و سه دست سیاست را هماهنگ نگه دارد.
مقیاس واقعی مشکل: آماری که تکاندهندهاند
گزارشهای اخیر موسسه Gartner نشان میدهند که تا سال ۲۰۲۵، بیش از ۸۵٪ سازمانهای بزرگ از استراتژی چندابری استفاده میکنند. IBM Security در گزارش Cost of Data Breach 2023 اعلام کرد که متوسط هزینه یک نقض داده به ۴.۴۵ میلیون دلار رسیده — و بیش از ۸۰٪ نقضها شامل اعتبارنامههای لو رفته یا دزدیدهشده بودهاند. Verizon در گزارش DBIR 2023 مشخص کرد که ۷۴٪ نقضها شامل عنصر انسانی هستند — از جمله استفاده از اعتبارنامههای ضعیف یا سرقتشده.
چرا مدلهای سنتی امنیت هویت در محیط چندابری شکست میخورند؟
مدلهای سنتی امنیت هویت روی یک فرض ساده بنا شدهاند: شبکه داخلی امن است و هر کسی که داخل شبکه باشد، قابل اعتماد است. این مدل در محیط چندابری هیچ معنایی ندارد. وقتی منابع در سه قاره پراکنده هستند و کاربران از خانه، دفتر، موبایل و مکانهای مختلف وارد میشوند، هیچ مرزی وجود ندارد که «داخل» و «خارج» را جدا کند.
ریسکهای کنترل هویت در محیط چندابری
شناخت ریسکهای واقعی، اولین گام برای طراحی یک معماری امن است. محیطهای چندابری مجموعه خاصی از آسیبپذیریهای هویتی دارند که در محیطهای تکابری یا داخلی وجود ندارند.
تکثر هویت و Shadow Identity بزرگترین ریسک عملیاتی است. وقتی هر ابر یک دایرکتوری مجزا دارد، حسابهای کاربری ناهماهنگ ایجاد میشوند. اگر یک کارمند سازمان را ترک کند و فرآیند Offboarding فقط Active Directory داخلی را پوشش دهد، حسابهایش در AWS یا Google Cloud فعال میمانند. این «حسابهای یتیم» (Orphaned Accounts) یکی از رایجترین بردارهای حمله هستند.
ریسک Credential Sprawl و مدیریت گسترده اعتبارنامه
در یک محیط چندابری، تعداد اعتبارنامههای مختلف — کلید API، رمز عبور سرویس، توکن دسترسی، گواهی دیجیتال — بهسرعت انفیگر نمیزایش مییابد. Credential Sprawl به وضعیتی گفته میشود که تیم امنیتی دیگر نمیداند چه اعتبارنامههایی وجود دارند، کجا استفاده میشوند، آیا منقضی شدهاند، و آیا در معرض خطر هستند.
این وضعیت در لایههای مختلف ایجاد میشود. در لایه انسانی، کاربران چندین رمز عبور برای ابرهای مختلف دارند و ناگزیر از ضعیف کردن آنها یا تکرارشان استفاده میکنند. در لایه ماشینی، سرویسها و اپلیکیشنها برای ارتباط با هم به کلیدهای API و توکنهای سرویس نیاز دارند که اغلب بدون چرخه عمر مشخص ایجاد میشوند.
ریسک ناهماهنگی سیاستهای دسترسی
هر ابر زبان سیاستگذاری خودش را دارد. یک Policy در AWS بهصورت JSON نوشته میشود، در Azure بهصورت RBAC با مدل داده متفاوت، و در Google Cloud با Resource Hierarchy خاص خودش. وقتی یک تیم امنیتی میخواهد یک قانون ساده مثل «هیچ کاربری نباید به محیط Production بدون MFA دسترسی داشته باشد» را پیاده کند، باید این قانون را در سه سیستم مختلف با سه رویکرد متفاوت پیادهسازی کند.
یک اشتباه کوچک در هر کدام — یک Permission که فراموش شده، یک Exception که ایجاد شده — میتواند یک حفره امنیتی جدی ایجاد کند. بدتر از آن، تشخیص این ناهماهنگیها بدون ابزارهای تخصصی Multi-Cloud IAM تقریباً غیرممکن است.
ریسک Visibility صفر و کور بودن تیم امنیتی
یکی از خطرناکترین ویژگیهای محیطهای چندابری بدون راهکار هویت متمرکز، «کوری» تیم امنیتی است. این تیم نمیداند الان چه کسی در AWS چه کاری میکند، چه کسی در Azure با چه سطح دسترسی فعال است، و آیا یک حساب غیرمعمول در Google Cloud در حال فعالیت مشکوک است. این کور بودن یعنی تشخیص تهدید، واکنش به حادثه، و حسابرسی انطباق همه بهشدت دشوار میشوند.
معماریهای کنترل هویت در محیط چندابری
برای مقابله با این ریسکها، چند معماری اصلی برای کنترل هویت در محیط چندابری وجود دارد. انتخاب معماری مناسب به اندازه سازمان، تعداد ابرها، الزامات انطباق، و سطح بلوغ امنیتی بستگی دارد.
قبل از بررسی معماریها، یک اصل پایه را باید درک کرد: هیچ معماری هویت چندابری مؤثری بدون یک Identity Provider (IdP) مرکزی وجود ندارد. IdP مرکزی ستون فقرات تمام رویکردهای موفق است — جایی که هویتهای معتبر تعریف میشوند و سایر سیستمها برای تأیید هویت به آن مراجعه میکنند.
معماری Hub-and-Spoke: کنترل مرکزی با انعطاف محیطی
در معماری Hub-and-Spoke، یک IdP مرکزی (Hub) تمام هویتها را مدیریت میکند و هر پلتفرم ابری (Spoke) برای احراز هویت به این مرکز مراجعه میکند. این معماری سادهترین رویکرد برای سازمانهایی است که میخواهند کنترل مرکزی داشته باشند.
مزایای این رویکرد واضحاند: یک نقطه مدیریت، یک مجموعه سیاست، یک داشبورد مانیتورینگ. اما یک ریسک مهم هم دارد: Hub نقطه شکست مرکزی (Single Point of Failure) میشود. اگر IdP مرکزی از دسترس خارج شود، تمام ابرها بدون احراز هویت میمانند. برای این مشکل باید از HA (High Availability) و Failover مناسب برای IdP استفاده کرد.
معماری Federated Identity: استقلال با همکاری
در معماری Federation، هر ابر یا سیستم IdP خودش را دارد اما این IdPها از طریق پروتکلهای استاندارد (SAML 2.0، OIDC، WS-Federation) با هم ارتباط برقرار میکنند. کاربری که در IdP سازمان A تأیید شده، میتواند بدون ایجاد حساب جداگانه به منابع سازمان B یا ابر C دسترسی داشته باشد.
این معماری انعطافپذیرتر است و برای سازمانهایی که با شرکای تجاری، مشتریان، یا ابرهایی که هر کدام دایرکتوری مستقل دارند کار میکنند مناسب است. پیچیدگی اصلی این معماری، مدیریت روابط اعتماد (Trust Relationships) بین IdPها است.
پروتکلهای استاندارد Federation چندابری
سه پروتکل اصلی در اکوسیستم Federation چندابری نقش محوری دارند. SAML 2.0 قدیمیترین و پرکاربردترین پروتکل برای سازمانهای Enterprise است. تمام ابرهای اصلی، سرویسهای SaaS، و IdPهای رایج از آن پشتیبانی میکنند. OpenID Connect (OIDC) پروتکل مدرنتری است که روی OAuth 2.0 بنا شده و برای اپلیکیشنهای وب و موبایل مدرن، توسعهدهندگان، و سرویسهای API-محور مناسبتر است. SCIM (System for Cross-domain Identity Management) پروتکلی است که ایجاد، تغییر و حذف حسابها را بین دایرکتوریهای مختلف بهصورت خودکار همگام میکند.
FIDO و نقش آن در کنترل هویت چندابری
تا اینجا درباره معماریها صحبت کردیم — اما معماری بهتنهایی امنیت نیست. وقتی کاربری میخواهد وارد یک محیط چندابری شود، از چه روشی احراز هویت میکند؟ این همان جایی است که استاندارد FIDO2 وارد میشود و همه چیز را تغییر میدهد.
FIDO2 (Fast IDentity Online 2) یک استاندارد باز است که توسط FIDO Alliance — متشکل از Google، Microsoft، Apple، Amazon و صدها شرکت دیگر — طراحی شده و احراز هویت بدون رمز عبور را بهصورت فنی امن، مقیاسپذیر و مقاوم در برابر فیشینگ فراهم میکند. هسته فنی FIDO2 بر رمزنگاری کلید عمومی-خصوصی استوار است: کلید خصوصی هرگز دستگاه کاربر را ترک نمیکند و هرگز از طریق شبکه منتقل نمیشود.
چرا رمز عبور در محیط چندابری یک خطر سیستماتیک است؟
رمز عبور در محیط تکابری هم مشکلساز است، اما در محیط چندابری به یک خطر سیستماتیک تبدیل میشود. کاربران باید برای هر ابر یک رمز عبور جداگانه داشته باشند — یا همان رمز را تکرار کنند. تکرار رمز عبور یعنی اگر یک ابر نقض شود، همه ابرهای دیگر هم در خطر هستند. رمزهای مختلف یعنی فراموشی، استفاده از رمزهای ضعیف، و نوشتن آنها در جاهای ناامن.
فیشینگ در محیط چندابری هم یک تهدید ساختاری است. مهاجم میتواند یک صفحه ورود جعلی AWS یا Azure بسازد، کاربر فریب میخورد و رمز عبور و OTP را وارد میکند، و مهاجم بلافاصله از آنها استفاده میکند. این حمله با رمز عبور و حتی MFA سنتی قابل انجام است.
FIDO2 در معماری Multi-Cloud: چگونه کار میکند؟
در یک پیادهسازی FIDO2 برای محیط چندابری، معماری به این شکل عمل میکند: کاربر با یک دستگاه FIDO2 — کلید سختافزاری، گوشی هوشمند با بیومتریک، یا کارت هوشمند — در برابر IdP مرکزی احراز هویت میکند. IdP یک توکن امضاشده (معمولاً یک JWT یا SAML Assertion) صادر میکند. این توکن سپس از طریق پروتکل Federation به تمام ابرهایی که کاربر مجاز به دسترسی است ارائه میشود. هر ابر بدون نیاز به احراز هویت مجدد، توکن را تأیید میکند و دسترسی میدهد.
این معماری چند ویژگی کلیدی دارد. کاربر فقط یک بار احراز هویت میکند (SSO). احراز هویت مقاوم در برابر فیشینگ است چون کلید FIDO فقط به دامنه IdP واقعی پاسخ میدهد. حتی اگر یک ابر نقض شود، کلید FIDO کاربر لو نمیرود چون هرگز از دستگاه خارج نشده.
امنیت فنی FIDO2: رمزنگاری در خدمت هویت چندابری
وقتی یک کاربر دستگاه FIDO2 را ثبت میکند (Registration)، دستگاه یک جفت کلید رمزنگاری منحصربهفرد برای هر سرویس ایجاد میکند. کلید عمومی در سرور (IdP) ذخیره میشود. کلید خصوصی در دستگاه کاربر، محافظتشده توسط یک عنصر امن سختافزاری (مثل Secure Enclave در iOS یا TPM در Windows) میماند.
در زمان ورود (Authentication)، سرور یک Challenge تصادفی میفرستد. دستگاه کاربر این Challenge را با کلید خصوصی امضا میکند — اما فقط بعد از اینکه کاربر هویتش را به دستگاه ثابت کند (با اثر انگشت، تشخیص چهره، یا PIN). سرور امضا را با کلید عمومی ذخیرهشده تأیید میکند. در این کل فرآیند، هیچ رمز عبوری، هیچ OTPی، و هیچ اطلاعات قابل سرقتی از طریق شبکه منتقل نمیشود.
SSO چندابری: یک ورود، همه دسترسیها
Single Sign-On (SSO) در محیط چندابری نه یک تجمل، بلکه یک ضرورت عملیاتی است. بدون SSO، کاربران باید برای هر سرویس جداگانه وارد شوند — این کار نه تنها خستهکننده است، بلکه امنیت را هم کاهش میدهد چون کاربران تمایل دارند از رمزهای ضعیفتر برای سرویسهایی که مداوم وارد آنها میشوند استفاده کنند.
SSO چندابری به این شکل عمل میکند: کاربر یک بار در برابر IdP مرکزی احراز هویت میکند. IdP یک Session Token صادر میکند. هر بار که کاربر به یک سرویس جدید وارد میشود، آن سرویس کاربر را به IdP هدایت میکند، IdP Session فعال را تأیید میکند و بدون نیاز به ورود مجدد، یک توکن دسترسی برمیگرداند. از دیدگاه کاربر، همه سرویسها بدون ورود جداگانه در دسترس هستند.
SSO و FIDO: ترکیبی که امنیت را به حداکثر میرساند
ترکیب SSO با احراز هویت FIDO یک معادله امنیتی بهینه ایجاد میکند. SSO بهتنهایی تجربه کاربری را بهبود میدهد اما اگر اعتبارنامه ورود به SSO لو برود، مهاجم به همه سرویسها دسترسی دارد. FIDO این ریسک را از بین میبرد چون حتی اگر Session Token دزدیده شود، مهاجم نمیتواند یک احراز هویت جدید FIDO انجام دهد.
در این معماری، کاربر یک بار با FIDO احراز هویت میکند و یک SSO Session میگیرد. تمام دسترسیهای بعدی در چارچوب این Session انجام میشود. اگر Session منقضی شود یا یک رفتار غیرمعمول شناسایی شود، سیستم مجدداً احراز هویت FIDO را درخواست میکند.
مدیریت Session در محیط چندابری
مدیریت چرخه عمر Session در محیط چندابری یک چالش فنی جداگانه است. باید تعادلی بین امنیت و تجربه کاربری برقرار کرد. Session خیلی کوتاه (مثلاً ۱۵ دقیقه) امنیت را بالا میبرد اما کاربران را ناراضی میکند. Session خیلی طولانی (مثلاً ۷۲ ساعت) راحت است اما ریسک دسترسی غیرمجاز را افزایش میدهد.
رویکرد مدرن، Adaptive Session Management است: طول Session بر اساس ریسک رفتار کاربر تنظیم میشود. اگر کاربر از موقعیت جغرافیایی معمول، با دستگاه شناختهشده، در ساعت کاری معمول فعالیت میکند، Session طولانیتر تمدید میشود. اگر موقعیت غیرمعمول، دستگاه جدید، یا رفتار مشکوک تشخیص داده شود، احراز هویت مجدد درخواست میشود.
Zero Trust و کنترل هویت چندابری
معماری Zero Trust و کنترل هویت چندابری دو مفهوم جدانشدنی هستند. Zero Trust بر اساس یک اصل ساده بنا میشود: «هرگز بهصورت ضمنی اعتماد نکن — همیشه صریحاً تأیید کن.» این اصل در محیط چندابری، جایی که هیچ مرز شبکهای وجود ندارد، نه یک انتخاب بلکه یک ضرورت معماری است.
پیادهسازی Zero Trust در محیط چندابری به سه لایه نیاز دارد. لایه اول تأیید هویت قوی است — که با FIDO2 به بهترین شکل محقق میشود. لایه دوم کنترل دسترسی مبتنی بر زمینه است — که نه فقط «این کاربر کیست» بلکه «این کاربر در این لحظه با این دستگاه از این مکان برای این منبع چقدر ریسک دارد» را ارزیابی میکند. لایه سوم مانیتورینگ و تشخیص مداوم است — که تمام فعالیتها را ثبت میکند و ناهنجاریها را شناسایی میکند.
Least Privilege در محیط چندابری
اصل Least Privilege — دادن حداقل دسترسی لازم برای انجام یک کار — در محیط چندابری باید با دقت پیادهسازی شود. در عمل، این یعنی هر کاربر، سرویس، یا اپلیکیشن فقط به منابع خاصی که برای کارش نیاز دارد دسترسی داشته باشد — نه به تمام یک ابر، و نه برای همیشه.
رویکرد Just-in-Time (JIT) Access یکی از مؤثرترین پیادهسازیهای Least Privilege است. در این رویکرد، دسترسیهای ممتاز بهصورت دائمی وجود ندارند. وقتی یک ادمین نیاز به دسترسی سطح بالا دارد، یک دسترسی موقت (مثلاً ۴ ساعته) درخواست میکند، این درخواست تأیید میشود، کار انجام میشود، و دسترسی بهصورت خودکار لغو میشود.
نشانه: راهکار IAM و احراز هویت FIDO برای محیطهای چندابری ایرانی
در دنیایی که فروشندگان خارجی راهکارهای Cloud IAM ارائه میدهند، سازمانهای ایرانی با چالشهای اضافهای روبهرو هستند: محدودیتهای تحریم، نیاز به سرویسدهی داخلی، و الزامات انطباق با مقررات محلی. پلتفرم IAM و SSO نشانه، محصول شرکت رهسا، یک پاسخ بومی به این نیازها است.
نشانه یک راهکار جامع مدیریت احراز هویت بدون رمز عبور مبتنی بر استاندارد FIDO2 است که برای محیطهای سازمانی — از جمله محیطهای چندابری — طراحی شده. محصولات نشانه چند نوع دستگاه احراز هویت را پوشش میدهند.
نشانه موبایل گوشی هوشمند کاربر را به یک کلید FIDO2 تبدیل میکند. کاربر با اثر انگشت یا تشخیص چهره گوشیاش وارد سیستم میشود — بدون هیچ رمز عبوری. این راهکار برای سازمانهایی که کاربران زیادی دارند و میخواهند بدون هزینه سختافزار اضافه، احراز هویت قوی پیاده کنند ایدهآل است.
نشانه توکن یک کلید امنیتی سختافزاری FIDO است که از RFID و NFC هم پشتیبانی میکند. این محصول برای محیطهای با امنیت بالا — مثل دسترسی ادمینهای سیستم، تیمهای توسعه با دسترسی به Production، یا کاربرانی که به منابع حساس دسترسی دارند — مناسب است.
علاوه بر FIDO، نشانه از دستگاههای رمزیاب، توکنهای امضای دیجیتال، و سایر روشهای احراز هویت چندعاملی هم پشتیبانی میکند. قابلیت SSO یکپارچه نشانه اجازه میدهد کاربران با یک احراز هویت FIDO به تمام سرویسهای سازمان — چه داخلی چه ابری — دسترسی داشته باشند.
مدیریت چرخه عمر هویت در محیط چندابری
یکی از پیچیدهترین جنبههای کنترل هویت چندابری، مدیریت کل چرخه عمر هویت کاربران است — از لحظهای که یک کارمند جدید میپیوندد تا لحظهای که سازمان را ترک میکند.
Onboarding در محیط چندابری باید یک فرآیند واحد باشد. با استفاده از پروتکل SCIM، وقتی یک حساب جدید در IdP مرکزی ایجاد میشود و نقشهای مناسب اختصاص مییابند، بهصورت خودکار حسابهای متناظر در تمام ابرهای مرتبط ایجاد میشوند. این اتوماسیون هم سرعت Onboarding را بالا میبرد و هم خطر فراموش شدن یک ابر را از بین میبرد.
Offboarding مهمترین و ریسکیترین فرآیند در چرخه عمر هویت است. وقتی یک کارمند سازمان را ترک میکند، غیرفعال کردن تنها حساب Active Directory داخلی کافی نیست. باید اطمینان حاصل کرد که دسترسی در تمام ابرها، تمام سرویسهای SaaS، و تمام سیستمهای داخلی قطع شده. با یک IdP مرکزی و همگامسازی SCIM، غیرفعال کردن حساب در یک مکان، تمام دسترسیها را بهصورت خودکار قطع میکند.
Access Certification: حسابرسی دورهای دسترسیها
حتی با Onboarding و Offboarding خودکار، دسترسیها در طول زمان «فرسوده» میشوند. یک کارمند از یک تیم به تیم دیگر میرود اما دسترسیهای قبلیاش حذف نمیشوند. یک پروژه تمام میشود اما دسترسی سرویسها باقی میماند. به مرور زمان، هر کاربر دسترسیهای بیشتری از آنچه نیاز دارد جمع میکند — به این پدیده Privilege Creep میگویند.
Access Certification یک فرآیند دورهای است که مدیران و صاحبان منابع را وادار میکند دسترسیهای موجود را بازبینی کنند و تأیید کنند یا رد کنند. در محیط چندابری، این فرآیند باید از یک داشبورد واحد برای تمام ابرها انجام شود — نه یک بازبینی جداگانه برای هر ابر.
انطباق و حسابرسی در Multi-Cloud IAM
مدیریت هویت چندابری نه فقط یک چالش امنیتی، بلکه یک الزام انطباقی هم هست. بیشتر استانداردها و مقررات صنعتی الزامات دقیقی برای مدیریت دسترسی دارند.
ISO/IEC 27001 استانداردی است که سازمانها باید کنترلهای دسترسی منطقی داشته باشند، دسترسیها را بهصورت دورهای بازبینی کنند، و تمام فعالیتهای دسترسی را ثبت کنند. یک Multi-Cloud IAM مناسب باید توانایی تولید گزارشهای قابل حسابرسی برای این الزامات را داشته باشد.
SOC 2 Type II نیازمند کنترلهای امنیتی قابل مستندسازی و Audit Log کامل است. PCI-DSS برای سازمانهایی که با دادههای پرداخت کار میکنند الزامات سختگیرانهای برای MFA و مدیریت دسترسی ممتاز دارد. GDPR به کنترل دقیق اینکه چه کسی به دادههای شخصی دسترسی دارد و ثبت این دسترسیها نیاز دارد.
پرسشهای متداول
Multi-Cloud Identity Management با Cloud IAM چه تفاوتی دارد؟
Cloud IAM اصطلاح گستردهتری است که مدیریت هویت در هر محیط ابری را شامل میشود. Multi-Cloud Identity Management بهطور خاص به چالش مدیریت هویت یکپارچه در چندین پلتفرم ابری بهصورت همزمان اشاره دارد — که نیازمند لایههای اضافی معماری مثل Federation، IdP مرکزی، و SCIM است.
آیا میتوان Active Directory داخلی را با یک استراتژی چندابری ترکیب کرد؟
بله، و در واقع این رایجترین سناریو است. با ابزارهایی مثل Microsoft Entra Connect، Okta AD Agent، یا راهکارهای مشابه، Active Directory داخلی میتواند بهعنوان «منبع حقیقت» هویت (Source of Truth) عمل کند و هویتها را به IdP ابری Federate کند. کاربران با همان اعتبارنامههای داخلیشان به ابر هم وارد میشوند.
چرا MFA سنتی برای محیط چندابری کافی نیست؟
MFAهای سنتی مانند SMS OTP یا اپلیکیشنهای تولید کد یکبارمصرف در برابر حملات فیشینگ بلادرنگ (Real‑Time Phishing) آسیبپذیر هستند. مهاجم میتواند یک صفحه ورود جعلی AWS یا Azure ایجاد کند، کاربر رمز عبور و کد OTP را وارد کند و مهاجم همان لحظه از آن برای ورود واقعی استفاده کند.
استاندارد FIDO2 در برابر این نوع حمله مقاوم است، زیرا کلید امنیتی فقط به دامنه واقعی سرویس پاسخ میدهد و هیچ کد قابل انتقالی تولید نمیکند.
آیا پیادهسازی SSO در چند ابر باعث افزایش ریسک نمیشود؟
اگر SSO بدون احراز هویت قوی پیادهسازی شود، بله. زیرا یک حساب به همه سرویسها دسترسی میدهد. اما در معماری مدرن، SSO معمولاً همراه با موارد زیر استفاده میشود:
- احراز هویت مقاوم در برابر فیشینگ مانند FIDO2
- سیاستهای Conditional Access
- مدیریت نشست تطبیقی (Adaptive Session)
- نظارت مداوم بر رفتار کاربر
در این مدل، SSO هم تجربه کاربری را ساده میکند و هم امنیت را افزایش میدهد.
آیا مدیریت هویت چندابری فقط برای سازمانهای بزرگ لازم است؟
خیر. حتی شرکتهای متوسط هم معمولاً ترکیبی از سرویسها را استفاده میکنند:
- یک یا چند Cloud Provider
- چندین SaaS
- سیستمهای داخلی
به محض اینکه هویت کاربران در چند سیستم توزیع شود، نیاز به یک لایه هویت مرکزی ایجاد میشود.
آیا میتوان احراز هویت بدون رمز عبور را در محیط چندابری پیادهسازی کرد؟
بله. در واقع یکی از بهترین سناریوهای استفاده از Passwordless Authentication همین محیطهای چندابری است. با استفاده از FIDO2:
- کاربر با کلید امنیتی یا موبایل خود در IdP مرکزی احراز هویت میکند.
- IdP یک توکن SSO صادر میکند.
- این توکن به AWS، Azure، Google Cloud یا سرویسهای SaaS ارائه میشود.
در نتیجه کاربر بدون رمز عبور و تنها با یک احراز هویت قوی به همه منابع دسترسی پیدا میکند.
کسب اطلاعات بیشتر
اگر سازمان شما در حال استفاده از چند سرویس ابری است یا قصد پیادهسازی احراز هویت بدون رمز عبور، SSO و IAM چندابری را دارد، بهتر است معماری هویت خود را پیش از بزرگ شدن زیرساخت طراحی کنید.
برای دریافت مشاوره تخصصی پیادهسازی Multi‑Cloud IAM و احراز هویت FIDO در سازمان خود، با تیم متخصص نشانه در neshane.co تماس بگیرید.
📞 ۰۲۱-۹۱۰۹۶۵۵۱
کلیک کنید: نشانه موبایل و نشانه توکن
جمعبندی
رشد سریع معماریهای چندابری (Multi‑Cloud) باعث شده مدیریت هویت به یکی از حیاتیترین لایههای امنیت سازمان تبدیل شود. وقتی کاربران، سرویسها و دادهها در چندین پلتفرم ابری توزیع میشوند، نبود یک استراتژی هویت متمرکز میتواند منجر به:
- پراکندگی حسابها
- افزایش اعتبارنامهها
- عدم دید امنیتی
- و افزایش احتمال نقض داده شود.
راهکارهای مدرن Multi‑Cloud IAM بر چند اصل کلیدی استوار هستند:
- Identity Provider مرکزی
- Federated Identity
- Single Sign‑On
- احراز هویت مقاوم در برابر فیشینگ (FIDO2)
- مدل امنیتی Zero Trust
ترکیب این عناصر باعث میشود سازمان بتواند در عین حفظ انعطاف معماری چندابری، کنترل دقیق و قابل حسابرسی بر هویت کاربران داشته باشد.
در این میان، استفاده از راهکارهای IAM بومی مانند پلتفرم نشانه میتواند برای سازمانهای ایرانی مزایای مهمی داشته باشد: از احراز هویت بدون رمز عبور مبتنی بر FIDO گرفته تا SSO سازمانی، مدیریت چرخه عمر هویت و یکپارچهسازی با سرویسهای ابری و داخلی.