سیستم هویت مشتری و مدیریت دسترسی (Customer Identity and Access Management)
دسترسی دیجیتال مشتری در یک نقطهٔ عطف قرار دارد. برای سالها، سیستم هویت مشتری و مدیریت دسترسی (CIAM) چندان مورد توجه قرار نمیگرفت. شرکتها یک مجموعه مدیریت هویت و دسترسی (IAM) مانند Okta Workforce Identity یا Microsoft Active Directory را برای کارکنان داخلی مستقر میکردند و بهصورت غیررسمی بخشهایی از اطلاعات مشتری را همراه با جفتهای نامکاربری-رمزعبور در پایگاههای دادهٔ ایستا، برای هر پروژهٔ جدید کاربرمحور، قرار میدادند. اما در عصر پیچیدگی روبهافزایش دیجیتال، این رویکرد برای مدیریت هویت مشتری در مقیاس کافی نیست.
مدیران محصول میخواهند به ارائه خدمات دیجیتال مصرفکننده ادامه دهند، اما پس از یک نقطه، هویت مانع کار میشود، جیکوب ایدِسکوگ، CTO شرکت Curity میگوید. «مردم واقعاً درباره CIAM فکر نمیکنند تا زمانی که به نقطهای برسند که متوجه شوند به آن بخش نیاز دارند»، او میگوید. «شما متوجه میشوید که هویت باید روی پای خودش بایستد، بهعنوان یک مؤلفهٔ مجزا.»
در این عصر، هویت مشتری باید فراتر از راهحلهای خانگی و موردی مرتبط با عملکردهای خاص تکامل یابد. در عوض، سازمانهای هوشمند در حال بازنگری نحوهٔ مدیریت هویت مشتری و جدا کردن آن هستند، پیروی از یک «رویکرد جداسازی نگرانیها»، ایدسکوگ میگوید. این میتواند مزایای تجاری به همراه داشته باشد، مانند بازکردن چابکی توسعه و استانداردسازی دسترسی امن مشتری.
آمادهسازی برای پیادهسازی CIAM
وضعیت شرکتهای بزرگ مدرن را در نظر بگیرید. کسبوکارهای امروزی ردپای دیجیتال گستردهای دارند و از طریق نقاط تماس گوناگون با مصرفکنندگان خارجی تعامل میکنند. زمانی یکپارچه، سیستمهای دیجیتال مشتری با گذر زمان بهطور فزایندهای تجزیه شدهاند، عمدتاً به دلیل فشار برای افزایش سرعت و چابکی. آنها در حال تبدیل شدن به API-محور هستند و بر میکروسرویسهای متصل مختلف برای قدرتدهی به برنامهها در پلتفرمهای موبایل، وب و دیگر پلتفرمها تکیه دارند.
علاوه بر این، انتظار میرود برنامههای نرمافزاری شخصیسازی عمیق مشتری، امتیازهای منحصربهفرد، و سطوح مختلف اشتراک ارائه دهند. همهٔ اینها بر اطلاعات پیچیده هویت مشتری و استانداردهای بالا برای احراز هویت و مجوزدهی در هسته خود تکیه دارند. برای مثال، احراز هویت چندعاملی به تکهتکه شدن و پیچیدگی سیستم هویت مشتری و مدیریت دسترسی اضافه میکند، ایدسکوگ میگوید.
تعریف نکردن یک نقطهٔ ورود واحد میتواند بهطور جدی تلاشهای توسعه را تخلیه کند. شما همچنین نمیخواهید پیچیدگی را به کاربر منتقل کنید — مصرفکنندگان نباید مجبور شوند با چندین هویت و ورود جداگانه در عملکردهای مختلف کسبوکار ثبتنام کنند. «اگر آن را کنار هم جمع نکنید، پیچیده و پراکنده میشود»، ایدسکوگ میگوید.
بنابراین، جدا کردن هویت برای پشتیبانی همزمان از چندین سایت یا برنامه لازم است بدون آنکه مسیر کاربر بیش از حد پیچیده شود. ایدسکوگ از این موضوع بهعنوان برخورد با هویت بهعنوان یک محصول مستقل یاد میکند. «هر سیستمی که میسازید در طول زمان آسانتر نگهداری میشود اگر اصل جداسازی نگرانی را دنبال کنید»، او میگوید.
چرا IAM سنتی کافی نیست؟
مدیریت هویت و دسترسی (IAM) در محیطهای شرکتی تثبیت شده است. بیشتر سیستمهای کسبوکار از سیستمهای کنترل دسترسی مبتنی بر نقش داخلی (RBAC) برای نگاشت مجوزها به نقشهای کارکنان استفاده میکنند. اما، «در اینجا واقعاً هیچ نوآوری جدیدی پذیرفته نمیشود»، ایدسکوگ میگوید. بدتر اینکه، سمت مصرفکننده سرمایهگذاری قابلمقایسهای در مدیریت هویت نداشته است.
«در گذشته، صنعت تلاش بسیار بیشتری را روی مجوزهای مبتنی بر نقش کارکنان گذاشته است»، او میگوید. بهطور سنتی، مشتریان فقط ورودیهایی در پایگاه داده بودند بدون زنگوسفیلهای سیستمهای کامل هویت. و زمانی که سرانجام سیستمهای مصرفکننده ساخته شدند، معمولاً سنگین و درهمتنیده با سیستمهای یکپارچه بودند، ایدسکوگ میگوید. سپس موبایل و ورود یکپارچه (single-sign-on) سرانجام هویت جداشده را معرفی کردند. اکنون، حرکت به سیستمهای مبتنی بر استاندارد مانند OAuth و OpenID Connect بسیار منطقی است.
اما هنوز، بیشتر سازمانهای بزرگ در یک رویکرد جداشده و قدرتمند به CIAM سرمایهگذاری نکردهاند، به هر دلیلی. تناقض اینجاست که، چه آن را بپذیرند یا نه، اکثر سازمانها در حال مدیریت هویتهای مصرفکنندگان هستند — آنها با نامکاربریها، subjects و بیشمار ویژگیها سروکار دارند.
تعریف CIAM
اگرچه تعاریف زیادی در بازار وجود دارد، ایدسکوگ CIAM را اینگونه تعریف میکند: «احراز هویت و مدیریت حساب کاربران زمانی که کاربران مصرفکنندگان یا مشتریان خارج از سازمان باشند.» پروفایلهای هویت مصرفکننده ویژگیهایی مانند آدرس، سطح اشتراک، تاریخچه خرید، ترجیحات و موارد دیگر را ذخیره میکنند — دادهای که بهشدت حیاتی شده است. «برای صدور مجوز درخواستها، ۸۰٪ APIها به اطلاعات هویت مرتبط با کاربر شما علاقهمند هستند»، او میگوید.
در چشمانداز API، یک طیف از موارد استفاده و مصرفکنندگان وجود دارد، و گاهی، همان سرویس باید هم به هویت سازمانی و هم به هویت مصرفکننده خدمترسانی کند. همچنین نیازهای مشابهی هنگام مدیریت هویتهای مصرفکننده خارجی برای یک رابطه B2B یا شریک وجود دارد، که یک زیرشاخه جدید به نام مدیریت هویت و دسترسی شریک (PIAM) ایجاد میکند.
ایدسکوگ همچنین امنیت API را زیر چتر CIAM میداند. «هدف احراز هویت دسترسی به چیزی است، و تقریباً همیشه یک API است»، او میگوید. «آن API به اطلاعات هویت نیاز دارد تا پردازش کند. اگر همهٔ اینها را با هم در نظر نگیرید، تنها چیزی که به دست میآورید یک ورود است.»
سیستمهای هویت اساساً بزرگتر از CIAM هستند زیرا میتوانند بهعنوان یک قرارداد مشترک برای هر نوع API عمل کنند. سیستم OAuth باید بیطرف باشد و از اطلاعات موجود در یک توکن هویت برای مسیریابی درخواست استفاده کند، بدون توجه به اینکه کارمندان یا مصرفکنندگان آن تماس را انجام میدهند. جدا کردن به این شکل میتواند کمک کند همان سیستم داخلی برای هر نوع کاربر بهسادگی در دسترس باشد.
مزایای پیادهسازی CIAM
دادن توجه لازم به CIAM منجر به چندین مزیت تجاری میشود، ایدسکوگ میگوید. یکی افزایش چابکی است — CIAM زمان رساندن به بازار را برای برنامههای کاربرمحور و APIهایی که آنها را پشتیبانی میکنند افزایش میدهد. از آنجا که مؤلفه هویت کاربر استاندارد و از نیازهای توسعه جدا شده است، افزودن آن برای برنامههای جدید آسانتر است و از تکرار تلاشها بین پروژهها جلوگیری میکند.
اگرچه CIAM ممکن است اصطکاک را مستقیماً در فرایند ورود کاهش ندهد، اما میتواند تجربه مشتری را به شیوههای دیگر بهبود دهد. برای مثال، متمرکزسازی مدیریت دسترسی به شما اجازه میدهد گزینههای جدید احراز هویت مانند passkeyها را در همه استقرارها با یکبار تغییر معرفی کنید. همچنین میتواند امکان تست A/B برای مسیرهای مشتری را از یک مکان واحد فعال کند.
اما یک مزیت اصلی، امنیت بهبودیافته است. بهطور طبیعی، مجوزهای کاربر مؤثرتر نگاشت میشوند، که از افشای بیشازحد داده جلوگیری کرده و یک رویکرد zero-trust را ترویج میدهد. قدرت متمرکزسازی کنترل دسترسی مزایای جانبی نیز به همراه دارد، مانند قابلیت ممیزی بهتر برای اهداف انطباق، و توانایی سازگاری با فناوریهای آینده مانند مدارک قابلتأیید. «شما تابآوری بهتری به دست میآورید چون میتوانید بهتر تغییر کرده و با نیازهای جدید سازگار شوید»، ایدسکوگ میگوید.
چه کسانی به CIAM نیاز دارد؟
سازمانهای بزرگ و بسیار دیجیتالیشده، یا آنهایی که در حال گذار دیجیتال هستند، سناریوهای اصلی هستند که واقعاً میتوانند از CIAM بهره زیادی ببرند. «و دیجیتالیشدهٔ سنگین معمولاً یعنی شما API-محور هستید یا در حال تبدیل شدن به API-محور هستید»، ایدسکوگ میگوید. «اگر این تکنیکها را وارد نکنید، کار بسیار سخت خواهد بود.»
علاوه بر اندازه و پیچیدگی، ردپای جغرافیایی نیز وجود دارد. سازمانهای جهانی با سیستمهای چندمنطقهای معمولاً از جدا کردن لایه هویت برای جلوگیری از مشکلات انطباق داده بهره میبرند. «وقتی سیستمهای ناهمگن با تعداد زیادی پیکان جلو و عقب مشاهده میکنید، نشانهای است که باید چیزی را بیرون بکشید»، ایدسکوگ میگوید. «و اغلب آن قطعه هویت است.»
همچنین خوب است به یاد داشته باشید که تنها شرکتهای کاربرمحور نهایی نیستند که برنامههای خارجی تولید میکنند — بسیاری از سازمانهای B2B به قابلیتهای مشابه CIAM برای شرکای خود نیاز دارند. یا شرکتهای پلتفرم نرمافزاری ممکن است به یک سیستم هویت مصرفکننده یکپارچه برای کاربران مشتریان خود نیاز داشته باشند. بنابراین، موارد استفاده برای CIAM گستردهتر از آن چیزی است که در ابتدا تصور میکنید.
CIAM: بیشتر از یک ابزار
از نظر سازمانی، تیم IAM معمولاً مسئول CIAM نبود، که از نیاز به مدیریت هویت مصرفکننده تکامل یافته است. سیستمهای خانگی مدیریت هویت و دسترسی میتوانند موانع نگهداری قابلتوجهی ایجاد کنند و نیازمند توجه یک محصول مستقل باشند. این میتواند چابکی را محدود کند زیرا توسعهدهندگان برنامه خدمات جدید ایجاد میکنند.
اگرچه CIAM برای مدتی یک «اسباببازی» بوده است، ایدسکوگ میگوید اکنون زمان آن است که شروع به جدی گرفتن آن کنیم — برای او، این شامل جدا کردن فرایند سفارشی هویت کاربر مشتری و جایگزینی آن با یک سازوکار مبتنی بر استاندارد جداشده است.
با وجود مشکلات فراگیر دسترسی API و مسائل مجوزدهی در رخدادهای نقض بزرگ امروز، کنترل دسترسی بهتر برای محافظت از سازمان ضروری است. شکست در این کار میتواند منجر به تلاشهای تکراری، شکافهای امنیتی، و عدم انطباق شود. برعکس، برخورد با CIAM بهعنوان یک ابزار میتواند نوآوری هوشمندتر در نرمافزار مصرفکننده را آغاز کند.
