سرویس هویت چندمستأجری با اعتبارسنجی نامتقارن RS256 JWT و حذف کامل راز مشترک
۱۷ شهریور ۱۴۰۵
۰۱. مسئله: آسیب‌پذیری‌های کلیدهای متقارن و گلوگاه‌های احراز هویت متمرکز
در معماری‌های میکروسرویس سازمانی، احراز هویت و صدور مجوزها اغلب دچار دو الگوی ضدطراحی (Anti-Pattern) پرهزینه می‌شود: ۱. پراکندگی کلیدهای متقارن (HS256): تمام سرویس‌های پایین‌دستی از یک کلید رمز مشترک HMAC استفاده می‌کنند. در صورت نفوذ به کم‌اهمیت‌ترین سرویس حاشیه‌ای (مانند سرویس گزارش‌گیری)، مهاجم قادر به جعل توکن‌های دسترسی اصلی برای کل زیرساخت پلتفرم خواهد بود. ۲. تقویت خواندن از دیتابیس (Database Read Amplification): سرویس‌های پایین‌دستی در هر درخواست ورودی HTTP یا gRPC برای تایید نشست کاربر به دیتابیس یا سرویس مرکزی احراز هویت کوئری می‌زنند. این امر علاوه بر ایجاد نقطه شکست تکی (SPOF)، به ازای هر هاپ ۱۵ الی ۴۰ میلی‌ثانیه به تأخیر اضافه می‌کند. ۳. نشت داده میان سازمانی (Cross-Tenant Data Leakage): در سامانه‌های سازمانی با چندین پذیرنده و کاربر سازمانی، فقدان مرزبندی سخت‌گیرانه در سطح داده خطر دسترسی غیرمجاز متقاطع را افزایش می‌دهد.
۰۲. راهکار معماری: اعتبارسنجی نامتقارن با الگوریتم RS256 و ایزولاسیون سطح داده
سرویس مستقل مدیریت هویت و دسترسی کاربران (UAA) بر پایه رمزنگاری کلید عمومی و خصوصی نامتقارن (RS256) و تفکیک چندمستأجری طراحی شد.
┌────────────────────────────┐
│ UAA Service (Auth) │
│ Private Key (2048-bit RSA) │
└─────────────┬──────────────┘
│ Signs JWTs
│ Publishes JWKS
▼
┌──────────────────────────────┐
│ API Edge Gateway │
└──────────────┬───────────────┘
│ RS256 Public Key Verification
┌────────────────────────┼────────────────────────┐
▼ ▼ ▼
┌──────────────────┐ ┌──────────────────┐ ┌──────────────────┐
│ Payment Switch │ │ Ledger Service │ │ BNPL Origination│
│ (Tenant Alpha) │ │ (Tenant Beta) │ │ (Tenant Gamma) │
│ Public Key Cache │ │ Public Key Cache │ │ Public Key Cache │
└──────────────────┘ └──────────────────┘ └──────────────────┘۱. چرخه حیات کلیدهای نامتقارن (RS256 و JWKS)
- حذف کامل کلیدهای مشترک: کلید خصوصی امضا منحصراً درون محیط ایزوله امنیتی نگهداری می‌شود. سرویس‌های پایین‌دستی صرفاً کلید عمومی را از طریق اندپوینت استاندارد JWKS دریافت می‌کنند (
/.well-known/jwks.json). - اعتبارسنجی مستقل محلی: هر میکروسرویس امضای توکن را در حافظه رم و در زمانی کمتر از ۰.۲ میلی‌ثانیه بدون هیچ فراخوانی شبکه بررسی می‌کند.
- چرخش کلیدها بدون توقف سرویس: توکن‌ها شامل شناسه کلید (
kid) هستند. در زمان چرخش کلید، سرویس‌ها کلید عمومی جدید را به صورت خودکار دریافت و کش می‌کنند.
۲. مرزبندی چندمستأجری و ایزولاسیون سازمانی
- کپسوله‌سازی شفاف کلیم‌ها (Claims): هر توکن صادره شامل ویژگی‌های تغییرناپذیر زیر است:
- شناسه کاربر (
sub) - شناسه ایزوله مستأجر سازمانی (
tid) - نقش‌های کاربری (
roles) - مجوزهای دسترسی دقیق عملیاتی (
scopes) مانندpayment:writeوledger:read
- شناسه کاربر (
- امنیت در سطح سطر دیتابیس (Row-Level Security): لایه‌های داده در سرویس‌های پایین‌دستی با استفاده از مقدار
tidسیاست‌های RLS پستگرس را اعمال می‌کنند (SET LOCAL app.current_tenant_id = '...') که عدم دسترسی متقاطع داده‌ها را در لایه سخت‌افزاری تضمین می‌کند.
۳. تیکت‌های یک‌بارمصرف تراکنش‌های حساس
در عملیات با ریسک مالی بالا (مانند برداشت‌های مبالغ سنگین از کیف پول یا دستور تسویه بانکی)، توکن استاتیک به تنهایی کافی نیست:
- کلاینت درخواست صدور تیکت تراکنشی ۶۰ ثانیه‌ای می‌دهد.
- تیکت با هش مشخص در ردیس ثبت می‌شود.
- در لحظه اجرا در سوئیچ پرداخت یا درگاه، تیکت با دستور اتمیک
GETDELردیس سوزانده می‌شود و امکان هرگونه حمله تکرار (Replay Attack) را به صفر می‌رساند.
۰۳. دستاوردهای عملیاتی در پروداکشن
- صفر نشت داده میان مستأجران: اثبات‌شده در ۲۱ سناریوی آزمون نفوذ و شبیه‌سازی تست بار پروداکشن.
- حذف ۱۰۰ درصدی کلیدهای متقارن مشترک: جایگزینی کامل کلیدهای HMAC با استاندارد نامتقارن کلید عمومی.
- کاهش ۹۹.۵ درصدی سربار شبکه در اعتبارسنجی: حذف مراجعات مکرر به پایگاه داده مرکزی برای بررسی نشست، که موجب کاهش ۲۸ میلی‌ثانیه‌ای تأخیر P95 تراکنش‌ها شد.
- توان عملیاتی بسیار بالا: مدیریت موفقیت‌آمیز بیش از ۱۲,۰۰۰ درخواست صدور توکن در ثانیه در شرایط پیک بار بدون افزایش مصرف منابع سرور.