از کلیک کاربران تا شتاب عامل‌های هوش مصنوعی؛ مقیاس ۱.۲ میلیارد کاربر OpenAI چه معنایی برای احراز هویت دارد؟
وقتی OpenAI در رویداد DevDay اعلام کرد که تعداد کاربران فعال هفتگی ChatGPT از مرز ۱.۲ میلیارد نفر گذشته است؛ رقمی معادل حدود ۱۵ درصد جمعیت جهان، بخش عمده بحث‌های مهندسی به‌طور طبیعی بر پنجره‌های متنی مدل‌ها، خوشه‌های محاسباتی و استنتاج توزیع‌شده روی پردازنده‌های گرافیکی (GPU) متمرکز شد.
بااین‌حال، پشت هر نشست گفت‌وگو، هر فراخوانی API و هر بار اجرای مدل، چالش زیرساختی عظیم دیگری قرار دارد: مدیریت هویت و دسترسی (IAM) در مقیاس بسیار بزرگ وب.
«پشت هر نشست گفت‌وگو، فراخوانی API و اجرای مدل، چالش زیرساختی عظیم دیگری قرار دارد: مدیریت هویت و دسترسی در مقیاس بسیار بزرگ وب.»
پیش از آنکه OpenAI حتی یک توکن از یک مدل زبانی بزرگ (LLM) در اختیار درخواست‌کننده قرار دهد، سامانه‌های پشتیبان این شرکت باید درخواست را احراز هویت کنند، اعتبار توکن‌های دسترسی OAuth 2.0 را بسنجند، مجوزهای دسترسی جزئی و دقیق را بررسی کنند و زمینه‌های نشست امن را در سراسر جهان حفظ کنند. OpenAI برای مدیریت این حجم عظیم از تراکنش‌ها، بدون ایجاد گلوگاه‌های تأخیر، به سراغ Ory رفت و از موتور احراز هویت سبک و مستقل از سایر اجزای سامانه و زیرساخت OAuth 2.0 و OpenID Connect (OIDC) آن استفاده کرد.
در ادامه، معماری این سامانه بررسی می‌شود تا روشن شود انتقال از ترافیک انسانی به بار کاری عامل‌های هوش مصنوعی چگونه مقیاس موردنیاز برای مدیریت هویت را تغییر می‌دهد، چرا پلتفرم‌های قدیمی IAM در چنین حجمی با مشکل مواجه می‌شوند و معماری مجزای احراز مجوز، سازگار با لبه شبکه، چگونه می‌تواند از پس نرخ پردازش بسیار بالا برآید.
چالش مقیاس: ترافیک انسانی در برابر بار کاری عامل‌های هوش مصنوعی
برای درک علت ناکامی پلتفرم‌های سنتی IAM در مقیاس بسیار بزرگ، کافی است تغییر الگوهای احراز هویت کاربران را هنگام گذار از برنامه‌های وب معمولی به پلتفرم‌های هوش مصنوعی عامل‌محور بررسی کنیم.
«وقتی یک سازمان از کلیک‌های کاربران در رابط کاربری به عامل‌های مستقل هوش مصنوعی روی می‌آورد، نسبت تعداد اعتبارسنجی‌های توکن به تعاملات انسانی به شکلی غیرخطی افزایش می‌یابد.»
با حرکت سازمان‌ها از کلیک‌های کاربران در رابط کاربری به سمت عامل‌های مستقل هوش مصنوعی، مانند مجموعه‌های Work و Codex شرکت OpenAI، نسبت اعتبارسنجی توکن‌ها به تعاملات انسانی به‌صورت غیرخطی افزایش می‌یابد. این تغییر سه پیامد مهم دارد:
- افزایش سرعت تراکنش‌ها: یک درخواست کاربر به عامل هوش مصنوعی می‌تواند ده‌ها وظیفه فرعی، پرس‌وجوی پایگاه داده و فراخوانی ابزارهای مبتنی بر APIهای شخص ثالث را به راه بیندازد. در هر مرحله، نشست باید بررسی و توکن مربوطه اعتبارسنجی شود.
- هزینه اضافی بررسی توکن: ارائه‌دهندگان متمرکز هویت (IdP) در سامانه‌های قدیمی معمولاً توکن‌های دسترسی را از طریق فراخوانی‌های راه‌دور متمرکز (RPC) یا جست‌وجو در پایگاه داده اعتبارسنجی می‌کنند. وقتی حجم درخواست‌ها به میلیاردها مورد در دقیقه برسد، این بررسی متمرکز باعث افزایش شدید رفت‌وآمدهای شبکه‌ای و رقابت بر سر قفل‌های پایگاه داده می‌شود.
- اعتبارسنجی بدون وضعیت در لبه شبکه: برای جلوگیری از تبدیل مجوزدهی به گلوگاه اصلی مسیر پردازش درخواست، اعتبار نشست باید به‌صورت هم‌زمان با دریافت درخواست و در لبه شبکه انجام شود. این کار مستلزم استفاده از روش‌های رمزنگاری سبک، مانند اعتبارسنجی توکن با اتکا به مجموعه کلیدهای وب JSON (JWKS) ذخیره‌شده در حافظه نهان است، نه فراخوانی‌های شبکه‌ای وابسته به وضعیت سامانه.
مقایسه معماری: مدیریت هویت ماژولار و مدرن در برابر نرم‌افزارهای یکپارچه قدیمی
تیم‌های مهندسی هنگام ارزیابی پلتفرم‌های هویت برای پردازش حجم بسیار بالای درخواست‌ها، اغلب با محدودیت‌های عملکردی و هزینه‌ای محصولات سنتی نرم‌افزار هویت چندمستاجری به‌عنوان سرویس (SaaS)، مانند Auth0، Okta و Ping Identity، مواجه می‌شوند.
| بُعد معماری | نرم‌افزارهای یکپارچه قدیمی هویت به‌صورت SaaS | مدیریت هویت ماژولار و خودمیزبان، مانند Ory |
|---|---|---|
| سازوکار اعتبارسنجی توکن | ارتباط رفت‌وبرگشتی با ارائه‌دهنده متمرکز هویت یا استفاده از کیت‌های توسعه نرم‌افزار سنگین در سمت سرور | اعتبارسنجی بدون وضعیت توکن‌های JWT در لبه شبکه و ذخیره محلی اطلاعات نشست در حافظه نهان |
| محل نگهداری و مالکیت داده‌ها | مخزن اطلاعات کاربران در زیرساخت ابری تحت مدیریت فروشنده | حاکمیت کامل بر داده‌ها؛ اجرا مستقیم در ابر خصوصی مجازی (VPC) سازمان یا محیط کوبرنتیز چندابری |
| راهبرد ذخیره‌سازی پایدار داده‌ها | خوشه‌های پایگاه داده اختصاصی فروشنده SaaS که مشمول محدودیت نرخ درخواست هستند | لایه‌های توزیع‌شده SQL با دسترس‌پذیری بالا، مانند CockroachDB، Spanner و PostgreSQL |
| مدل افزایش هزینه | هزینه به‌ازای هر کاربر فعال ماهانه (MAU) یا هر اجرای درخواست API | افزایش هزینه متناسب با زیرساخت؛ هزینه تابع میزان منابع پردازشی و حافظه موردنیاز است |
| سفارشی‌سازی و سرعت توسعه | محدود به وب‌هوک‌ها، قواعد یا محیط‌های محدود اجرای کد سفارشی فروشنده | ریزخدمت‌های مبتنی بر Go با مرزهای مشخص API و امکان یکپارچه‌سازی با رابط کاربری بدون وابستگی به ظاهر یا چارچوب خاص |
«OpenAI به‌دنبال شریکی بود که بتواند به تحقق چشم‌انداز ما برای در اختیار داشتن کنترل فرایندهای هویت، داده‌ها و موفقیت‌مان کمک کند. ما شرکای زیادی داریم و Ory یکی از بهترین آن‌هاست.»
- بنجامین بیلینگز، مدیر مهندسی در OpenAI (مطالعه موردی)
الزامات زیرساختی کلیدی برای سامانه‌های هویت با میلیاردها کاربر
تأمین امنیت هویت در چنین مقیاسی مستلزم تفکیک روشن مسئولیت‌ها در سراسر لایه احراز هویت است. بر اساس تجربه استقرار سامانه‌هایی با توان پردازش بالا، مانند زیرساخت OpenAI، معماری‌های مدرن هویت به چهار اصل اساسی متکی هستند.
۱. جداسازی وضعیت هویت از منطق کسب‌وکار
چارچوب‌های یکپارچه اغلب اطلاعات نمایه کاربران، وضعیت احراز هویت و نقش‌های کسب‌وکار را در یک پایگاه داده رابطه‌ای واحد به هم پیوند می‌دهند. معماری‌های پربازده این مسئولیت‌ها را از یکدیگر جدا می‌کنند و به ریزخدمت‌های مستقل می‌سپارند:
- ذخیره‌سازی هویت و موتورهای احراز هویت: ریزخدمت‌های اختصاصی برای مدیریت چرخه عمر هویت، هش‌کردن اطلاعات اعتبارنامه و مدیریت نشست؛ برای نمونه Ory Kratos.
- صدور توکن‌های OAuth 2.0 و OIDC: پیاده‌سازی‌های پربازده سرور OAuth 2.0 که می‌توانند توکن‌های دسترسی امضاشده صادر کنند و جریان‌های اعطای مجوز را با حداقل تأخیر مدیریت کنند؛ برای نمونه Ory Hydra.
- کنترل دسترسی با جزئیات دقیق (FGAC): موتورهای کنترل دسترسی مبتنی بر روابط که از الگوی Zanzibar شرکت گوگل پیروی می‌کنند؛ مانند Ory Keto. این موتورها روابط سه‌گانه میان شیء، رابطه و موضوع (ObjectRelationSubject) را در زمانی کمتر از یک میلی‌ثانیه ارزیابی می‌کنند.
۲. ذخیره‌سازی توزیع‌شده در مناطق مختلف ابری
برای پشتیبانی از مسیریابی جهانی در لبه شبکه، لایه ذخیره‌سازی زیربنایی باید از نوشتن داده‌ها در مناطق جغرافیایی توزیع‌شده و خواندن محلی با تأخیر کم پشتیبانی کند. ترکیب یک موتور هویت خودمیزبان با موتورهای SQL توزیع‌شده، مانند CockroachDB یا پایگاه‌های داده ابری بومی با قابلیت پشتیبانی از چند منطقه، امکان تکثیر سراسری وضعیت موردنیاز برای اعتبارسنجی توکن‌ها را فراهم می‌کند؛ بدون آنکه خطر ایجاد وضعیت دوگانه متعارض (split-brain) یا تأخیر ناشی از ارتباط میان قاره‌ها به وجود آید.
۳. امنیت عامل‌ها: گذار از «اجرای فوری محدودیت‌ها» به «حالت مشاهده»
وقتی سازمان‌ها عامل‌های مستقلی را به کار می‌گیرند که به نمایندگی از کاربران فرمان اجرا می‌کنند، اعمال فوری سیاست‌های محدودکننده IAM ممکن است جریان‌های کاری را مختل کند یا باعث شکست‌هایی شود که به‌سادگی قابل تشخیص نیستند. به همین دلیل، رویه‌های نوین امنیتی بر مشاهده‌پذیری در زمان اجرا، پیش از اجرای سخت‌گیرانه سیاست‌ها، تأکید می‌کنند:
- گام اول: شناسایی اثر انگشت عامل‌ها: تمام اعتبارنامه‌های ارتباط ماشین‌به‌ماشین (M2M) و حساب‌های کاربری سرویس متعلق به عامل‌ها را که در شبکه‌های داخلی فعالیت می‌کنند، شناسایی و ثبت کنید.
- گام دوم: ردیابی اجرا: استفاده از ابزارها، فراخوانی‌های API و پرس‌وجوهای پایگاه داده‌ای را که محیط‌های اجرای مستقل آغاز می‌کنند، بررسی و ثبت کنید.
- گام سوم: واگذاری هویت: سازوکار تبادل توکن OAuth 2.0 مطابق استاندارد RFC 8693 را با دامنه مجوز محدود پیاده‌سازی کنید تا عامل‌ها فقط با مجوزهایی محدودتر و مشخص فعالیت کنند که مستقیماً به کاربر انسانی واگذارکننده مجوز وابسته‌اند.
برای مدت محدودی، می‌توانید یک حساب رایگان Ory ایجاد کنید و حالت مشاهده را فعال سازید تا مشخص شود چگونه باید سیاست‌های کنترلی را به بهترین شکل طراحی و اجرا کرد.
«مقیاس‌پذیر کردن احراز هویت برای ۱.۲ میلیارد کاربر فعال هفتگی ثابت می‌کند که هویت دیگر صرفاً یک گزینه امنیتی برای تیک زدن در فهرست الزامات نیست؛ بلکه یکی از چالش‌های اصلی سامانه‌های توزیع‌شده است.»
مقیاس‌پذیر کردن احراز هویت برای ۱.۲ میلیارد کاربر فعال هفتگی نشان می‌دهد که مدیریت هویت دیگر صرفاً یک الزام امنیتی فرعی نیست، بلکه چالشی اساسی در طراحی سامانه‌های توزیع‌شده به شمار می‌رود.
با تغییر الگوی استفاده از نرم‌افزارها، از تعاملات انسانی با رابط کاربری به اجرای سریع و پرتعداد وظایف به‌وسیله عامل‌های هوش مصنوعی، تیم‌های مهندسی باید ارزیابی کنند که آیا زیرساخت مدیریت هویت آن‌ها توان پاسخ‌گویی به رشد فزاینده حجم درخواست‌های API را دارد یا خیر. موتورهای مدیریت هویت مستقل از سایر اجزا و مبتنی بر معماری بدون وضعیت، تأخیر کم، حاکمیت بر داده‌ها و عملکرد قابل پیش‌بینی موردنیاز پلتفرم‌های مدرن برای توسعه در عصر عامل‌های هوش مصنوعی را فراهم می‌کنند.