1955

چگونه اصول طراحی API با معماری اعتماد-صفر توسط کتاب «امنیت داده ابری بومی با OAuth» مورد تحلیل قرار می‌گیرد؟

Cloud Native Data Security with OAuth Breaks Down Zero-Trust API Design

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

“مدیریت امنیت داده و حریم خصوصی در APIها و مشتریان API مشکل پیچیده‌ای است که نیاز به راه‌حل معماری دارد”، این جمله توسط گری آرچر، جودیت کارهر و میکائو ترجانوسکی در مقدمه کتاب Cloud Native Data Security with OAuth نوشته شده است، یک راهنمای جدید برای طراحی و پیاده‌سازی معماری مقیاس‌پذیر اعتماد-صفر از O’Reilly Media که توسط اعضای Curity نگارش شده است.

کتاب Cloud Native Data Security with OAuth همانطور که انتظار دارید، عمیق، کاربردی و مفید است. نویسندگان اصول معماری اعتماد-صفر مقیاس‌پذیر و نحوه پیاده‌سازی آن را به گونه‌ای توضیح می‌دهند که خوانندگان وابسته به یک فروشنده یا پلتفرم خاص نشوند.

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

چرا از OAuth 2.0 استفاده کنیم؟

در فصل مقدماتی، نویسندگان می‌نویسند:
“یک پلتفرم بک‌اند معمولاً شامل چندین API است که داده‌ها را به کلاینت‌های وب، موبایل و B2B ارائه می‌کنند. همانند وب‌سایت‌ها، نیاز به احراز هویت و مجوزدهی درخواست‌ها بین APIها دارید… اینجاست که OAuth وارد می‌شود.”

آن‌ها توضیح می‌دهند که OAuth 2.0، چارچوب مجوزدهی مشخص شده در RFC 6079، که در سراسر متن به اختصار OAuth نامیده می‌شود، برای پیاده‌سازی امنیت API-محور در مقیاس بزرگ ضروری است.
اول اینکه، OAuth نیاز شما به ایجاد ابزارهای امنیتی اختصاصی را حذف می‌کند. دوم اینکه، OAuth بسیار قابل توسعه است و آن را برای امنیت داده ابری بومی ایده‌آل می‌سازد. OAuth از سرور مجوزدهی استفاده می‌کند که کاربران را قبل از ارائه توکن دسترسی احراز هویت می‌کند.

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

اجزای OAuth 2.0

در فصل دوم، OAuth 2.0 Distilled، نویسندگان معماری OAuth را به چهار نقش اصلی تقسیم می‌کنند: مالک منابع، سرور منابع، کلاینت و سرور مجوزدهی.

  • کلاینت معمولاً برنامه‌ای است که با توکن دسترسی API را فراخوانی می‌کند.

  • مالک منابع موجودیتی است که دسترسی به منابع را می‌دهد، اغلب از سرور منابع.

  • سرور مجوزدهی کلاینت‌ها را احراز هویت می‌کند و توکن دسترسی صادر می‌کند.

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

  • Opaque tokens: رشته‌های تصادفی که برای هر تراکنش نیاز به فراخوانی سرور اعتبارسنجی دارند.

  • Structured tokens: ساختار مشخصی دارند، اما امنیت کمتری نسبت به opaque tokens دارند.

  • JSON Web Tokens (JWTs) رایج‌ترین نوع structured tokens هستند.

چرا امنیت داده ابری بومی به معماری اعتماد-صفر نیاز دارد

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

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

کتاب سه طراحی اصلی برای معماری اعتماد-صفر را بررسی می‌کند:

  • اعتماد-صفر برای APIها

  • اعتماد-صفر برای کلاینت‌ها

  • اعتماد-صفر برای کاربران

برای کلاینت‌ها، خطر اصلی تقلید هویت و امنیت مرورگر است. برای اعتماد-صفر کاربران، نویسندگان توصیه می‌کنند از WebAuthn، Passkeys و گواهی‌های دیجیتال استفاده شود، که به اعتقاد آن‌ها آینده امنیت API است.

اجزای یک سیستم اعتماد-صفر

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

اجزای سیستم معماری اعتماد-صفر باید شامل سرور مجوزدهی برای تمرکز سیاست‌های امنیتی باشد. همچنین یک Policy Engine می‌تواند ابزار کمکی برای مدیریت امنیت باشد.

مزایای توکن‌های دسترسی

معماری اعتماد-صفر برای مجوزدهی به توکن‌های دسترسی متکی است. نویسندگان مثال زیر را ارائه می‌دهند:

{
"sub": "556c8ae33f8c0ffdd94a57b7eab37e9833445143cf6847357c65fcb8570413c4",
"customer_id": "۱۶۷۷۱",
"iss": "https://login.example.com",
"aud": ["api.example.com"],
"scope": "products",
"membership_level": "۱",
"level_of_assurance": ۳,
"exp": ۱۷۲۱۹۸۰۴۸۵
}

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

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

چگونه مجوزدهی اعتماد-صفر را در OAuth پیاده کنیم

کتاب توصیه می‌کند APIها JWT دسترسی امضا شده دریافت کنند که شامل زمینه امنیتی کسب‌وکار باشد. نویسندگان پیشنهاد می‌کنند JWTهای امضا شده در هدر HTTP Authorization ارسال شوند و از امضاهای نامتقارن و الگوریتم‌های رمزنگاری قوی استفاده شود. همچنین باید کاربر، مخاطب و زمان انقضا مشخص شود.

JWTهای امضا شده از سه بخش جداشده با نقطه ساخته شده‌اند: هدر، payload و امضای دیجیتال (JWS Compact Serialization). این تضمین می‌کند که داده‌ها دستکاری نشده‌اند و تراکنش در صورت تغییر داده رد می‌شود.

API باید امضای دیجیتال JWT را اعتبارسنجی کند. این مستلزم الگوریتمی است که با فیلد kid هدر JWT مطابقت داشته باشد، که معمولاً توسط سرور مجوزدهی انجام می‌شود. کلیدها به صورت عمومی در JSON Web Key Set (JWKS) منتشر می‌شوند.

API باید لیستی از صادرکنندگان معتبر داشته باشد و تنها کلیدهای آن‌ها را بپذیرد. OAuth راهکار مدیریت کلید ارائه می‌دهد و API باید با آن سازگار باشد. می‌توان کلیدهای امضا را به صورت دوره‌ای چرخاند و موقتاً هر دو کلید قدیم و جدید پذیرفته شوند.

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

نتیجه‌گیری درباره امنیت داده ابری بومی با OAuth

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

کتاب Cloud Native Data Security with OAuth با فصل‌بندی دقیق و مثال‌های کد کاربردی در مخزن GitHub، برای متخصصان IT و امنیت سایبری، توسعه‌دهندگان API یا هر کسی که می‌خواهد دنیای غیرمتمرکز امروز را بهتر درک کند، خواندنی ضروری است.

۵ راه برای ایمن‌سازی دسترسی عاملیت‌محور (Secure Agentic Access) به APIها کدامند؟
۳ الگوی جدید برای اتصال عوامل هوش مصنوعی (AI Agents) به APIها کدامند؟

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

سبد خرید
علاقه‌مندی‌ها
مشاهدات اخیر
دسته بندی ها