درحال مشاهده اسناد Apigee Edge هستید.
به
اسناد Apigee X بروید. اطلاعات
این سند رویکردهای مختلفی را که می‌توانید در Apigee برای پرداختن به آسیب‌پذیری‌های امنیتی شناسایی‌شده توسط OWASP استفاده کنید شرح می‌دهد. برای رویکردهای تکمیلی مستندشده برای Apigee، به گزینه‌های کاهش OWASP Top 10 2021 در Google Cloud مراجعه کنید.
مقدمه
OWASP یک انجمن باز است که به سازمان‌ها کمک می‌کند برنامه‌ها و میاناهای برنامه‌سازی کاربردی مطمئن را توسعه دهند، خریداری کنند، و نگهداری کنند. ازطریق پروژه امنیت OWASP API، OWASP مهم‌ترین خطرات امنیتی را برای برنامه‌های وب و REST API منتشر می‌کند و توصیه‌هایی برای رسیدگی به این خطرات ارائه می‌دهد.
این سند درباره رویکردهای محافظت دربرابر حملات رایج مبتنی بر API که در ده تهدید امنیتی برتر API در سال ۲۰۱۹ ازنظر OWASP شناسایی شده‌اند بحث می‌کند. موضوع مشترک در تهدیدهای برتر برجسته شده توسط فهرست جدید ناشی از جای‌گذاری نادرست کنترل‌های اصالت‌سنجی و صدور مجوز است، مثل اتکا به فیلتر کردن داده‌های برگشتی از درخواست API در برنامه‌های مشتری، با استفاده از الگوی ضداتکا به برنامه مشتری مصرف‌کننده برای اجرای کنترل دسترسی.
با ادامه رشد سریع اکوسیستم API، سوءاستفاده‌ها و استفاده‌های نادرست از API که منجر به برون‌ریزی داده توسط مهاجمان می‌شود، متأسفانه به یکی از رایج‌ترین بردارهای حمله امروزی تبدیل شده است. امنیت همچنان یکی از اولویت‌های اصلی Apigee است و ویژگی‌های جدیدی مانند عملیات API پیشرفته، که شامل ویژگی‌های تشخیص ناهنجاری است، به آن اضافه شده است. بااین‌حال، طراحی و پیاده‌سازی صحیح ویژگی‌های امنیتی Apigee برای کاهش احتمال حملات موفق به میاناهای برنامه‌سازی کاربردی شما بسیار مهم است.
«برنامه‌های مصرف‌کننده» باید غیرقابل‌اعتماد یا «عمومی» درنظر گرفته شوند، زیرا پلاتفرمی که برنامه در آن اجرا می‌شود تحت کنترل شما نیست. فرض کنید هر برنامه عمومی می‌تواند و قطعاً درمعرض خطر قرار می‌گیرد، بنابراین نمی‌توان به آن‌ها اعتماد کرد تا کنترل دسترسی را اعمال کنند (API1، API5)، داده‌های پاسخ را فیلتر کنند (API6)، یا رمزهای مشتری (API2) مانند کلیدهای API یا نشان‌های دسترسی را به‌طور ایمن ذخیره کنند. برخی‌از توصیه‌ها از بررسی ۱۰ مورد برتر OWASP در سال ۲۰۱۹ حاصل شده است:
- تعیین کنید که چه نوع برنامه‌های کلاینتی از میاناهای برنامه‌سازی کاربردی شما استفاده خواهند کرد (SPA، تلفن همراه، یا مبتنی بر مرورگر)، و الگوهای اصالت‌سنجی، مجوز، و امنیت مناسب را طراحی کنید.
- همیشه از جریان‌های OAuth یا OpenID Connect «کارخواه عمومی» استفاده کنید (استفاده از PKCE به‌شدت توصیه می‌شود)
- به منطق کسب‌وکار برنامه‌تان فکر کنید، ابتدا مشخصات OpenAPI خود را تعریف کنید، و کارگزاران API خود را طراحی کنید تا همه داده‌های پاسخ را از زیرینه در Apigee فیلتر کنید. هرگز برای انجام این کار به منطق کد برنامه پایین‌دست تکیه نکنید!
- همه درخواست‌های داده حاوی «اطلاعات شناساننده شخصی» کاربر-ویژه را فیلتر کنید تا فقط داده‌های بخش پشتیبان شما که متعلق به کاربر درخواست‌کننده است مجاز باشد.
API1:2019 سطح شیء شکسته مجوز
شرح تهدید
اعتبارسنجی ناکافی مجوز درخواست دسترسی به شیء به مهاجم اجازه می‌دهد با استفاده مجدد از کد دسترسی، کنش غیرمجاز انجام دهد. این تهدید ناشی از پیکربندی نامناسب اعتبارسنجی‌های مجوز است. Apigee خط‌مشی‌های VerifyApiKey، OAuth، و JSON Web Token (JWT) را ارائه می‌دهد که به محافظت دربرابر این آسیب‌پذیری کمک می‌کند، اما بسیار مهم است که این خط‌مشی‌ها به‌درستی پیکربندی شوند تا از این تهدید جلوگیری شود.
برای جلوگیری از این تهدید، مهم است که تیم‌های توسعه و امنیت برنامه همکاری نزدیکی داشته باشند. مجوز به‌ذاته موضوعی پیچیده است و مجوز مؤثر با جزئیات دقیق نیازمند درک عمیق منطق کسب‌وکار برنامه است.
از دیدگاه پیاده‌سازی Apigee، دو جنبه اصلی برای درنظر گرفتن وجود دارد:
- تمامیت کد دسترسی
- اجرای کنترل دسترسی
تمامیت کد دسترسی
بسیار مهم است که بااستفاده از جریان صحیح OAuth یا OpenID Connect همراه با سازوکار مناسب درستی‌سنجی یا امضای اعتبارنامه، تأیید کنید که نشان ارائه‌شده توسط کارخواه درخواست‌کننده دستکاری نشده است. Apigee از همه جریان‌های OAuth متداول پشتیبانی می‌کند.
خط‌مشی‌های درستی‌سنجی نمودار دسترسی Apigee شامل موارد زیر می‌شود:
- کدهای دسترسی، کدهای بازآوری، یا کدهای جریان پاسخ هنگام استفاده از چارچوب OAuth 2.0، ازجمله استفاده از چالش کارخواه با PKCE برای جلوگیری از اینکه مهاجم کد دسترسی را ضبط کند
- OpenID Connect 1.0 JSON Web Tokens و JSON Web Signatures
- درحال اعتبارسنجی ادعاهای SAML
- درحال تأیید کلیدهای میانای برنامه‌سازی کاربردی
- کد اصالت‌سنجی پیام درهم‌سازی‌شده (HMAC) درستی‌سنجی
اجرای کنترل دسترسی
پس‌از درستی‌سنجی اعتبار کد دسترسی، اجرای خط‌مشی‌های اعمال کنترل دسترسی برای ارزیابی هر درخواست ورودی API دربرابر حقوق دسترسی کد مجوز بسیار مهم است.
Apigee دو سازوکار اصلی برای درستی‌سنجی و اجرای خط‌مشی‌های مجوز ارائه می‌دهد:
- داخلی: استفاده از جریان‌های شرطی برای ارزیابی درخواست‌های دسترسی براساس ادعاهایی که به‌عنوان متغیرهای جریان از یک رمز مجوز استخراج شده‌اند
- واگذارشده: استفاده از خدمات برنمای به راهکار مدیریت دسترسی طرف سوم
رویکرد داخلی (که در شکل بالا نشان داده شده است) زمانی توصیه می‌شود که مدل کنترل دسترسی نسبتاً ساده باشد. برای مثال، اگر ادعاهای استخراج‌شده از یک کد دسترسی بتواند برای ارزیابی مستقیم و مجاز کردن درخواست شیء API استفاده شود.
از متغیرهای جاری دردسترس برای خط‌مشی‌های OAuth یا JWT برای ارزیابی درخواست‌های دسترسی بااستفاده از عبارت‌های جاری شرطی استفاده کنید.
رویکرد واگذارشده (که در شکل بالا نشان داده شده است) زمانی توصیه می‌شود که ادعاهای استخراج‌شده از یک کد دسترسی نتواند مستقیماً برای مجوز دادن به درخواست API برای یک شیء زیرینه استفاده شود، یا برای انواع جریان OAuth پیچیده‌تر که نیاز به تماس جداگانه با سرور مجوز برای دریافت کد دسترسی دارند.
بااستفاده از خط‌مشی خدمات پیام‌واره، می‌توان یا از سرویس طرف سوم تصمیم خط‌مشی صدور مجوز درخواست کرد، یا اطلاعات ادعای اضافی درباره عامل درخواست‌کننده دریافت کرد و سپس بااستفاده از جریان شرطی تصمیم کنترل دسترسی گرفت
API2:2019 اصالت‌سنجی کاربر خراب
شرح تهدید
خط‌مشی‌های اصالت‌سنجی کاربر که به‌درستی پیاده‌سازی نشده‌اند به مهاجمان اجازه می‌دهند با سوءاستفاده از نقص‌های پیاده‌سازی در پیاده‌سازی‌های اصالت‌سنجی، خود را به‌جای کاربران قانونی جا بزنند. برخی‌از اصول اصالت‌سنجی که هنگام پیاده‌سازی رویکردهای اصالت‌سنجی باید درنظر داشته باشید عبارت‌اند از:
- همیشه هم نماینده کاربر (برنامه) و هم کاربر درخواست‌کننده را اصالت‌سنجی کنید
- از الگوهای اصالت‌سنجی و صدور مجوز واگذارشده استفاده کنید و از ارسال مستقیم گذرواژه‌ها در درخواست «میانای برنامه‌سازی کاربردی» خودداری کنید
- همیشه امضای اطلاعات اعتباری دسترسی را اعتبارسنجی کنید و مطمئن شوید که همه اطلاعات اعتباری دسترسی استفاده‌شده زمان انقضای مشخصی داشته باشند
- با تنظیم سهمیه و استفاده از Apigee Sense برای شناسایی و پاسخ به حملات نیروی بی‌رحمانه ربات‌محور، از این حملات جلوگیری کنید
تحت الگوی بیرون به درون، طراحی API براساس موارد استفاده مصرف‌کنندگان از داده‌ها انجام می‌شود نه براساس ساختار داده‌های موجود در سیستم‌های زیرینه شما، و امنیت عنصر مهمی در طراحی API برای مصرف‌کنندگان خارجی است. سیستم‌های زیرینه به‌طور سنتی با پیاده‌سازی‌های اصالت‌سنجی به‌اندازه کافی قوی برای قرار گرفتن درمعرض شبکه‌های عمومی ساخته نمی‌شوند. در اینجا است که Apigee، همراه با راهکار مدیریت هویت و دسترسی، می‌تواند راهکارهای قدرتمندی برای محافظت دربرابر این تهدید ارائه دهد.
در اینجا چند عنصر اصلی وجود دارد که باید درنظر بگیرید، که هر دو در بخش‌های بعدی به آن‌ها پرداخته خواهد شد:
- طراحی امنیتی: استفاده کامل از ویژگی‌های Apigee برای پیاده‌سازی الگوهای اصالت‌سنجی
- حاکمیت: اطمینان از اینکه استفاده صحیح از الگوهای اصالت‌سنجی طراحی‌شده به‌طور یکنواخت در همه محصولات API منتشرشده استفاده می‌شود
- امنیت عملیاتی: توانایی تشخیص رفتارهای مشکوک یا غیرعادی و تلاش برای دور زدن یا حمله نیروی بی‌رحمانه به پراکسی‌های API اصالت‌سنجی‌شده
طراحی امنیتی
هدف طراحی امنیتی اجرای صحیح جریان‌های اصالت‌سنجی و یکپارچه‌سازی با ابزارهای هویت طرف سوم است. طراحی امنیتی مرحله‌ای حیاتی است و با درک نوع صحیح جریان اصالت‌سنجی واگذارشده‌ای که باید براساس نوع برنامه‌ای که نقاط پایانی API شما را مصرف می‌کند استفاده شود شروع می‌شود. مرحله بعدی این است که همراه با تیم هویت خود، الگوهای یکپارچه‌سازی را برای پیاده‌سازی با راه‌حل هویت خود تعریف کنید.
RFCهای OpenID Connect و OAuth تعداد زیادی از جریان‌های اصالت‌سنجی و صدور مجوز واگذارشده و همچنین عاملان دخیل در این جریان‌ها را ارائه می‌دهند. این موضوع پیچیده‌ای است و تعجب‌آور نیست که اصالت‌سنجی شکسته یکی از تهدیدات برتر OWASP API است. ارائه یک راهنمای جامع درباره اجرای صحیح استانداردهای هویت خارج از محدوده این سند است، اما Apigee منابع تکمیلی بسیاری برای درک بهتر جریان‌های OAuth دارد، مانند این کتاب الکترونیک و وب‌فرست، و نمونه اجرا.
خط‌مشی‌های اصالت‌سنجی
خط‌مشی‌های Apigee که به رفع نگرانی‌های مربوط به هویت و اصالت‌سنجی کمک می‌کنند عبارت‌اند از:
- درستی‌سنجی یا تولید کدهای دسترسی، کدهای بازآوری، یا کدهای جاری پاسخ هنگام استفاده از چارچوب OAuth 2.0. توجه: ازنظر فنی، OAuth چارچوب مجوز واگذارشده است، اما به‌طور گسترده در الگوهای اصالت‌سنجی واگذارشده یا فدرال استفاده می‌شود
- درحال درستی‌سنجی، رمزگشایی و تولید «نشان‌های وب JSON» و «امضاهای وب JSON» در OpenID Connect 1.0
- درحال تولید و اعتبارسنجی اظهارات SAML
- درحال تأیید کلیدهای میانای برنامه‌سازی کاربردی
- کد اصالت‌سنجی پیام درهم‌سازی‌شده (HMAC) درستی‌سنجی
مدیریت ترافیک
ویژگی‌های مدیریت ترافیک Apigee زیر به محافظت دربرابر حمله نیروی بی‌رحمانه کمک می‌کند:
- خط‌مشی Spike Arrest، برای تنظیم حد نرخ میانگین غلتان کلی در یک پراکسی API
- خط‌مشی‌های سهمیه، برای تنظیم محدودیت‌های نرخ دقیق برای پراکسی‌های API براساس سهمیه‌های تعریف‌شده توسط کلیدهای برنامه، توسعه‌دهندگان یا سهمیه‌های محصول API
- خط‌مشی‌های ذخیره در حافظه نهان، برای ذخیره در حافظه نهان کدهای دسترسی ذخیره‌شده براساس زمان‌های انقضای تعریف‌شده آن‌ها، و همچنین توانایی نامعتبر کردن اطلاعات اعتباری ذخیره‌شده در حافظه نهان (برای مثال، در شرایطی که کد دسترسی معتبری به‌خطر افتاده است)
نظارت
امنیت یک فرایند مداوم است، نه پروژه‌ای که «تنظیم شود و فراموش شود»، و یکی از بزرگ‌ترین دلایل رخ دادن نقض‌های امنیتی پیکربندی نادرست است. پس‌از تعریف جریان‌های اصالت‌سنجی، الگوهای یکپارچه‌سازی هویت، و خط‌مشی‌های مدیریت ترافیک مربوط به اصالت‌سنجی، بسیار مهم است که این موارد به‌درستی و به‌طور یکنواخت پیاده‌سازی شوند.
Apigee ویژگی‌ها و ابزارهای متعددی برای تضمین تمامیت پیاده‌سازی و جلوگیری از خطاهای پیکربندی نادرست ارائه می‌دهد.
کنترل دسترسی نقش‌مبنا (RBAC)
چه یک شرکت بزرگ باشید و چه یک استارتاپ کوچک، جلوگیری از خطاهای پیکربندی نادرست با این شروع می‌شود که مطمئن شوید فقط افراد و تیم‌های مناسب می‌توانند به پیکربندی‌های پراکسی API دسترسی داشته باشند و آن‌ها را اصلاح کنند. برنامه‌های API توسط تیم‌های چندرشته‌ای در سراسر سازمان شما پشتیبانی می‌شوند. کاملاً ضروری است که به هر تیم فقط اجازه‌های لازم برای انجام وظایفشان به‌عنوان بخشی از سفر API شما داده شود.
Apigee ویژگی‌هایی را برای مدیریت دسترسی مبتنی بر نقش دراختیارتان قرار می‌دهد و به شما امکان می‌دهد کاربران را به نقش‌های ازپیش تعریف‌شده اختصاص دهید یا نقش‌های سفارشی ایجاد کنید تا با تیم‌های API شما مطابقت داشته باشد. تعریف و مدیریت صحیح واگذاری نقش برای اینکه بتوانید برنامه میانای برنامه‌سازی کاربردی خود را به‌طور ایمن گسترش دهید بسیار مهم است. همچنین می‌توانید از فدراسیون برای یکپارچه‌سازی با فهرستگان شرکت موجودتان و کاهش نیاز به مدیریت مجموعه دوم اطلاعات اعتباری سرپرست در Apigee استفاده کنید.
جریان‌های مشترک
جریان‌های مشترک به شما امکان می‌دهند خط‌مشی‌ها و منابع را در یک شیء قابل‌استفاده مجدد تعریف کنید که می‌تواند در سراسر کارگزاران میانای برنامه‌سازی کاربردی پیاده‌سازی شود. برای مثال، ممکن است با تیم‌های امنیتی خود چندین الگوی طراحی اصالت‌سنجی را براساس نوع برنامه‌ای که از یک API استفاده می‌کند، به‌صورت مشارکتی طراحی کرده باشید. توسعه‌دهنده میانای برنامه‌سازی کاربردی برای استفاده مجدد از این مورد نیازی به متخصص هویت بودن ندارد، کافی است جریان مشترک صحیح را برای افزودن به پیکربندی کارگزار میانای برنامه‌سازی کاربردی موجود خود بااستفاده از خط‌مشی Flow callout بداند.
شکل: «جریان‌های مشترک» دسته‌های قابل‌استفاده مجدد از خط‌مشی‌ها و منطق شرطی هستند که به شما امکان می‌دهند الگوی ترکیبی را حفظ کنید.
امنیت عملیاتی
وقتی میاناهای برنامه‌سازی کاربردی شما بااستفاده از الگوهای اصالت‌سنجی صحیح با مدیریت ترافیک پایه در محل تولید می‌شوند، تیم SecOps شما نیز باید بتواند فعالیت‌های مشکوک را که اغلب با تلاش برای به‌خطر انداختن اعتبارنامه‌های اصالت‌سنجی شروع می‌شود، نظارت و به آن‌ها پاسخ دهد.
Apigee Sense
Apigee Sense از «میاناهای برنامه‌سازی کاربردی» شما دربرابر ترافیک درخواست ناخواسته، ازجمله حملات مشتریان مخرب، محافظت می‌کند. Apigee Sense ترافیک درخواست API را تجزیه‌وتحلیل می‌کند و الگوهایی را که ممکن است نشان‌دهنده درخواست‌های ناخواسته باشند شناسایی می‌کند. بااستفاده از این تجزیه‌وتحلیل، می‌توانید مشتریانی را که درخواست‌های ناخواسته ارسال می‌کنند شناسایی کنید، سپس برای مجاز کردن، مسدود کردن، یا پرچم‌گذاری کردن آن درخواست‌ها اقدام کنید. ویژگی‌های آتی Sense شامل قابلیت فعال کردن خودکار درستی‌سنجی ReCAPTCHA در ترافیک مشکوک خواهد بود.
با Apigee Sense، می‌توانید از «میاناهای برنامه‌سازی کاربردی» خود دربرابر الگوهای درخواست که شامل موارد زیر است محافظت کنید:
- رفتار خودکارسازی‌شده‌ای که با رفتار انسانی ترکیب می‌شود
- تلاش‌های مداوم از همان IP
- نرخ خطای غیرمعمول
- درخواست‌های مشکوک کارخواه
- خزیدن داده
- حملات جستجوی کلید و حملات اصالت‌سنجی با نیروی بی‌رحمانه
- فعالیت‌های ناگهانی
- الگوهای جغرافیایی
عملیات پیشرفته میانای برنامه‌سازی کاربردی
درحالی‌که Sense به‌طور خاص برای شناسایی و پاسخ به تهدیدهای روبات‌مانند طراحی شده است، «عملیات API پیشرفته» شامل هر دو شناسایی ناهنجاری و تعریف هشدار پیشرفته است.
«تشخیص ناهنجاری» با اعمال هوش مصنوعی (AI) و مدل‌های یادگیری ماشین (ML) روی داده‌های سابقه API شما کار می‌کند. سپس تشخیص ناهنجاری می‌تواند برای سناریوهایی که حتی به آن‌ها فکر نکرده‌اید، به‌صورت بی‌درنگ هشدار صادر کند تا بهره‌وری‌تان را بهبود بخشد و میانگین زمان رفع مشکلات API را کاهش دهد.
«عملیات پیشرفته میانای برنامه‌سازی کاربردی» با افزودن انواع هشدار پیشرفته زیر، بر سازوکار هشدار «پایش میانای برنامه‌سازی کاربردی» موجود بنا می‌شود: انواع هشدار پیشرفته:
- هشدارهای ناهنجاری. Edge به‌جای اینکه خودتان مشکلات ترافیک و عملکرد را ازقبل تعیین کنید، آن‌ها را تشخیص می‌دهد. سپس می‌توانید برای این ناهنجاری‌ها هشدار ایجاد کنید
- هشدارهای انقضای «امنیت لایه انتقال». وقتی گواهینامه TLS به انقضا نزدیک می‌شود، اعلانی را افزایش می‌دهد
API3:2019 درمعرض قرار گرفتن داده‌های بیش‌ازحد لازم
شرح تهدید
یک API منتشرشده ممکن است داده‌های بیشتری از آنچه لازم است را آشکار کند و برای انجام فیلترهای لازم به برنامه مشتری متکی باشد. اگر مهاجمی مستقیماً API زیربنایی را پُرسمان کند، می‌تواند به داده‌های حساس دسترسی پیدا کند.
یکی از اصول طراحی «بیرون به درون» Apigee برای طراحی میانای برنامه‌سازی کاربردی، صرفه‌جویی در داده‌ها است. با طراحان تجربه کاربری و توسعه‌دهندگان خود همکاری کنید تا فقط داده‌هایی را ازطریق میاناهای برنامه‌سازی کاربردی نمایان کنید که در میانای کاربری برنامه شما لازم است. سیستم‌های زیرینه برای الگوهای استفاده عمومی ساخته نشده‌اند، بنابراین یکی از اولین وظایف طراحی «میانای برنامه‌سازی کاربردی اول» با Apigee کاهش داده‌های نمایان‌شده به حداقل لازم برای ارائه محصول «میانای برنامه‌سازی کاربردی» عالی به مشتریان و توسعه‌دهندگان شما است.
یکی دیگر از اصول طراحی Apigee قابلیت استفاده مجدد است. گذشته از نگرانی‌های امنیتی، اتکا به یک برنامه برای فیلتر کردن داده‌های ارائه‌شده توسط یک API منجر به الزام انتقال منطق فیلتر کردن در هر پلاتفرمی می‌شود که برای آن برنامه توسعه می‌دهید.
از دیدگاه امنیتی، این تهدید ناشی از واگذاری اجرای مجوز به یک برنامه است، که اغلب در یک پلاتفرم یا سیستم‌عاملی است که شما هیچ کنترلی بر آن ندارید. قبلاً در API1 و API2 اهمیت پیاده‌سازی صحیح احراز هویت و صدور مجوز برای جلوگیری از دسترسی غیرمجاز به داده‌ها را بررسی کرده‌ایم.
بخش‌های بعدی به بررسی نحوه انجام موارد زیر می‌پردازد:
- بازنویسی درخواست‌ها و پاسخ‌ها به سرویس‌های زیرینه برای به‌حداقل رساندن نمایش داده‌ها
- پیاده‌سازی مدیریت خطا برای جلوگیری از نمایش پیام‌های خطای پرحرف که اطلاعات حساس محیط را درباره خدمات زیرینه شما به مهاجمان نشان می‌دهد
بازنویسی پاسخ‌ها و درخواست‌ها
سیستم‌های زیرینه معمولاً برای استفاده در برنامه‌های عمومی یا در شبکه‌های عمومی غیرقابل اعتماد طراحی نشده‌اند. Apigee Edge برای این طراحی شده است که شما را قادر سازد محصولات API عمومی را با محافظت از زیرینه‌هایتان دربرابر نمایش بیش‌ازحد داده‌ها مستقر کنید.
برای انجام این کار، Apigee از سه خط‌مشی کلیدی استفاده می‌کند:
- اختصاص دادن پیام
- نوشته‌های راهنمای کد
- مدیریت خطا
اختصاص دادن خط‌مشی «پیام»
خط‌مشی Assign Message درطول «جریان» کارگزار API، پیام‌های درخواست و پاسخ جدیدی را ایجاد می‌کند یا تغییر می‌دهد. این خط‌مشی به شما امکان می‌دهد کنش‌های زیر را روی آن پیام‌ها انجام دهید:
- افزودن پارامترهای فرم جدید، سرایندها، یا پارامترهای پُرسمان به پیام
- خصوصیت‌های موجود را از پیامی به پیام دیگر کپی کنید
- برداشتن سرایندها، پارامترهای پُرسمان، پارامترهای فرم، و/یا بار پیام از پیام
- تنظیم مقدار دارایی‌های موجود در پیام
با «اختصاص دادن پیام»، معمولاً ویژگی‌های درخواست یا پاسخ را اضافه، تغییر، یا حذف می‌کنید. بااین‌حال، می‌توانید از «اختصاص پیام» نیز برای ایجاد پیام درخواست یا پاسخ سفارشی و ارسال آن به هدفی جایگزین، همان‌گونه که در ایجاد پیام‌های درخواست سفارشی توضیح داده شده است، استفاده کنید.
بازنویسی پیچیده با کد سفارشی
برای مدیریت داده‌های پیچیده و بازنویسی قوانینی که پیچیدگی آن‌ها فراتر از قابلیت خط‌مشی «تخصیص پیام» است، می‌توانید از زبان‌های رویه‌ای مثل جاوا اسکریپت، جاوا، یا پایتون استفاده کنید. می‌توانید به کارگزاری API کد سفارشی اضافه کنید و سپس آن را از خط‌مشی‌های اضافه‌شده به جریان کارگزاری فراخوانی کنید. پشتیبانی از کد رویه‌ای به‌گونه‌ای طراحی شده است که پیاده‌سازی مدیریت پیچیده متغیرهای جریان، خطاها، و متن درخواست و پاسخ را برای شما آسان‌تر کند.
با کد رویه‌ای، می‌توانید:
- ایجاد یا دستکاری مقادیر پیچیده بدنه، مانند مقادیر درخواست و پاسخ.
- بازنویسی نشانی‌های وب، مثلاً برای پوشاندن نشانی وب نقطه پایان هدف.
Apigee Edge شامل خط‌مشی جداگانه‌ای برای زبان‌های پشتیبانی‌شده است: خط‌مشی جاوا اسکریپت، خط‌مشی تماس با Java، و خط‌مشی برنامه Python.
مدیریت خطا
Apigee به شما امکان می‌دهد بااستفاده از خط‌مشی نوع Raise Fault، مدیریت استثنای سفارشی انجام دهید. خط‌مشی «ایجاد خطا»، که گونه‌ای از خط‌مشی «اختصاص پیام» است، به شما امکان می‌دهد در پاسخ به وضعیت خطا، پاسخ خطای سفارشی تولید کنید.
جریان‌های مشترک
از جریان‌های مشترک می‌توان برای اجرای استانداردسازی پیام‌های خطا استفاده کرد. برای مثال، از خط‌مشی‌های پیکربندی‌شده یکسانی که کد خطای HTTP خاصی را از زیرینه تشخیص می‌دهند می‌توان برای بازنویسی پاسخ خطا استفاده کرد تا پیام خطای عمومی برگرداند.
API4:2019 کمبود منابع و محدودیت نرخ
شرح تهدید
با پیاده‌سازی نکردن خط‌مشی‌های محدود کردن نرخ، مهاجمان می‌توانند با حمله‌های منع سرویس، زیرینه را تحت فشار قرار دهند.
بااستفاده از ویژگی‌های Apigee زیر می‌توان به‌راحتی به این تهدید رسیدگی کرد:
- سهمیه‌ها و خط‌مشی‌های «مهار جهش» به‌عنوان کنترل‌های پیشگیرانه برای اعمال محدودیت‌های ترافیک بر روی درخواست‌های ورودی API
- Apigee Sense برای شناسایی و پاسخ پویا به حملات روبات‌محور
- پایش و هشداردهی پیشرفته میانای برنامه‌سازی کاربردی به‌عنوان کنترل‌های کارآگاهی برای دریافت هشدار درباره حمله‌های منع سرویس توزیع‌شده درحال انجام
محدود کردن نرخ با «سهمیه‌ها» و «خط‌مشی‌های دستگیری ناگهانی»
Apigee دو خط‌مشی برای محدود کردن نرخ ارائه می‌دهد:
- جلوگیری از جهش خط‌مشی کلی را که در سطح پراکسی API تعریف شده است برای محدود کردن تعداد کلی درخواست‌های ورودی به یک زیرینه ارائه می‌دهد
- سهمیه‌ها ابزار خط‌مشی دانه‌دریشتی برای اجرای خط‌مشی‌های سهمیه در سطح محصول میانای برنامه‌سازی کاربردی یا پراکسی میانای برنامه‌سازی کاربردی ارائه می‌دهند
دستگیری با شوک الکتریکی
خط‌مشی Spike Arrest دربرابر افزایش ناگهانی ترافیک محافظت می‌کند. این خط‌مشی تعداد درخواست‌های پردازش‌شده توسط پراکسی API و ارسال‌شده به زیرینه را محدود می‌کند و بااستفاده از مقدار میانگین متحرک قابل‌تعریف در خط‌مشی، از تأخیر در عملکرد و زمان توقف محافظت می‌کند.
سهمیه‌ها
خط‌مشی Quota پیکربندی تعداد پیام‌های درخواست را که یک پراکسی API در یک دوره زمانی، مانند یک دقیقه، یک ساعت، یک روز، یک هفته یا یک ماه مجاز می‌کند، فعال می‌کند. می‌توانید سهمیه را برای همه برنامه‌هایی که به پراکسی API دسترسی دارند یکسان تنظیم کنید، یا می‌توانید سهمیه را براساس موارد زیر تنظیم کنید:
- محصولی که حاوی پراکسی API است
- برنامه‌ای که میانای برنامه‌سازی کاربردی را درخواست می‌کند
- توسعه‌دهنده نرم‌افزار
- معیارهای بسیار دیگر
این خط‌مشی جزئی‌تر از «مهار جهش» است و به‌طورکلی باید هم‌زمان با آن استفاده شود.
تشخیص روبات با Apigee Sense
با Apigee Sense، می‌توانید براساس رفتار مخرب یا مشکوک آن مشتریان یا مکان‌ها، اقدام کنید و درخواست‌های مشتریان خاص، محدوده‌های IP، یا سازمان‌های «سیستم خودمختار» را صریحاً مجاز، مسدود، یا پرچم‌گذاری کنید. Apigee Edge این کنش‌ها را قبل‌از اینکه کارگزاران API شما آن‌ها را پردازش کنند، روی درخواست‌ها اعمال می‌کند. برای مثال، محدوده IP یا کارخواه خاصی که رفتار «حدس‌زننده بی‌رحم» از خود نشان می‌دهد می‌تواند شناسایی شود، سپس مسدود یا پرچم‌گذاری شود.
تشخیص تهدید با «عملیات API پیشرفته» پایش
از هشدار ترافیک برای ایجاد اعلان وقتی ترافیک محیط، پراکسی، یا منطقه در محدوده زمانی مشخصی براساس درصد تغییر می‌کند استفاده کنید. این ویژگی می‌تواند به‌صورت پویا زمانی که ترافیک به‌طور قابل‌توجهی از توان عملیاتی موردانتظار شما منحرف می‌شود، مانند زمانی که حمله DDoS رخ می‌دهد، هشدار دهد. این هشدارها را می‌توان به‌راحتی به راهکار ثبت و نظارت طرف سوم ارسال کرد.
API5:2019 Broken function level authorization
شرح تهدید
این تهدید گونه‌ای از API1 است و آسیب‌پذیری مجوز هم دارد. با این تهدید، مهاجم می‌تواند با ارسال درخواست به توابعی که مجاز به دسترسی به آن‌ها نیست، کنش‌هایی را انجام دهد. برای مثال، اگر نقطه پایانی میانای برنامه‌سازی کاربردی فعل درخواست HTTP را اعتبارسنجی نکند، مهاجم می‌تواند با جایگزین کردن GET با PUT یا DELETE، داده‌هایی را که فقط اجازه خواندن آن‌ها را دارد تغییر دهد یا حذف کند. یا با پیاده‌سازی نکردن کنترل دسترسی به‌اندازه کافی محدودکننده در مسیر نشانی وب منبع API، نقطه پایانی API ممکن است به مهاجم اجازه دهد با تغییر ساده مسیر در درخواست، داده‌های کاربر دیگری را مشاهده کند.
این نوع تهدید بر ارزش استفاده از Apigee به‌عنوان لایه میانجی‌گری و انتزاع تأکید می‌کند، زیرا بسیاری از سیستم‌های زیرینه - که برای دسترسی عمومی طراحی نشده‌اند - ممکن است به‌طور پیش‌فرض یک نقطه پایانی برای اجرای چندین تابع منطق کسب‌وکار ارائه دهند، ازجمله عملکردهای مدیریتی پرخطر.
عناصر مفهومی برای کاهش احتمال این تهدید معمولاً به موارد زیر تقسیم می‌شوند:
- چه چیزی محافظت می‌شود؟ درباره استراتژی محصول API خود فکر کنید و هنگام استفاده از روال‌های مطلوب RESTful برای طراحی مسیرها و منابعی که توسط پراکسی‌های Apigee API، محصولات، و ویژگی‌های برنامه نمایان می‌شوند، تقسیم‌بندی منطقی کارکرد را پیاده‌سازی کنید.
- چه کسی به منابع «میانای برنامه‌سازی کاربردی» شما دسترسی دارد؟ شخصیت‌های سطح بالا را تعریف کنید و بااستفاده از برخی‌از ویژگی‌های اصالت‌سنجی و مجوز Apigee که در API1 و API2 شرح داده شده است، حق استفاده از دسترسی پیش‌فرض «کمترین امتیاز» را پیاده‌سازی کنید.
- خط‌مشی‌های دسترسی شما چگونه اجرا می‌شوند؟ از جریان‌های شرطی و خطاها برای اعتبارسنجی مسیر نشانی وب و فعل همه درخواست‌های API استفاده کنید.
شکل: این نمودار نشان می‌دهد که چگونه مجوز سطح تابع در Apigee بااستفاده از محدوده‌های ارائه‌شده در یک کد دسترسی به‌عنوان حقوق اعمال می‌شود.
تقسیم‌بندی منطقی با میانای برنامه‌سازی کاربردی کارگزاران، محصولات، و برنامه‌ها
Apigee ابزاری بسیار انعطاف‌پذیر برای فعال کردن تقسیم‌بندی منطقی منابع میانای برنامه‌سازی کاربردی ارائه می‌دهد که به پراکسی‌های میانای برنامه‌سازی کاربردی اجازه می‌دهد در هر تعداد محصول میانای برنامه‌سازی کاربردی دسته‌بندی شوند، که به نوبه خود توسط توسعه‌دهندگان برنامه شما مصرف می‌شوند و می‌توانند برنامه‌هایی را ثبت کنند که از محصولات میانای برنامه‌سازی کاربردی شما استفاده می‌کنند. خط‌مشی‌های دسترسی را می‌توان در هریک از این سطوح تعریف کرد.
برای پیاده‌سازی تفکیک و مجوز عملکردی مؤثر، تعریف استراتژی محصول API بسیار مهم است. بخشی از این فرایند ضروری و مداوم، تعریف «چه کسی» و «چه چیزی» محصولات API شما است، با نگاه کردن به منابع API از دیدگاه مشتری و توسعه‌دهنده، و سپس تعریف کردن تا سطح منبع مسیر و فعل HTTP، دقیقاً چه نوع درخواست‌هایی مجاز خواهد بود.
شکل: منابع «میانای برنامه‌سازی کاربردی» که در محصول «میانای برنامه‌سازی کاربردی» دسته‌بندی شده‌اند می‌توانند از یک یا چند «میانای برنامه‌سازی کاربردی» باشند، بنابراین می‌توانید منابع را ترکیب کنید و با هم تطبیق دهید تا سطوح مصرف و مرزهای مجوز ایجاد کنید.
دسترسی سطح تابع کنترل با محدوده‌های OAuth و ادعاهای JWT
درحالی‌که رویکردهای مجوزدهی که در بالا برای API1:2019 مجوزدهی شیء شکسته درنظر گرفته شده است کنترل دسترسی دقیق در سطح شیء را مدیریت می‌کند، به همان اندازه مهم است که کنترل دسترسی درشت‌دانه در سطح عملکرد را مدیریت کنیم. آیا کاربر درخواست‌کننده اصلاً اجازه دارد این مسیر نشانی وب را درخواست کند؟ این نوع خط‌مشی اغلب براساس شخصیت کاربر (مشتری، کارمند، سرپرست، توسعه‌دهنده داخلی یا طرف سوم) تعریف می‌شود.
برای کاهش خطر پیکربندی اشتباه، توصیه می‌شود با تیم امنیتی خود همکاری کنید تا مطمئن شوید ادعاهای مربوط به کاربر درخواست‌کننده در رمز دسترسی، چه بااستفاده از محدوده‌های OAuth یا ادعاهای JWT، گنجانده شده است.
درخواست اعتبارسنجی با جریان‌های شرطی
در سطح پایه، یک فراخوانی REST API از موارد زیر تشکیل شده است:
- نقطه پایانی
- منبع
- فعل کنشی
- هر تعداد مشخصه درخواست اضافی، مثل پارامترهای پُرسمان
نوع حمله شرح‌داده‌شده در این تهدید معمولاً به‌دلیل فیلتر ناکافی درخواست میانای برنامه‌سازی کاربردی ایجاد می‌شود، بنابراین به مهاجم اجازه می‌دهد کنش‌های غیرمجاز انجام دهد یا به منبع محافظت‌شده دسترسی پیدا کند. علاوه‌بر منطق شرطی که به شما امکان می‌دهد درخواست‌ها را براساس ادعاهای یا نشان‌های دسترسی فیلتر کنید، Apigee امکان پیاده‌سازی منطق فیلتر براساس خود درخواست را فراهم می‌کند.
وقتی منطق کسب‌وکار محصول API را به‌وضوح درک کردید و تعریف کردید، و دانستید که APIهای شما چه عملکردهایی را مجاز می‌کنند، گام بعدی این است که درخواست‌هایی را که خارج از این محدوده قرار می‌گیرند ازطریق این ویژگی‌های محصول Apigee محدود کنید:
- منطق شرطی و خط‌مشی‌های «ایجاد خطا» برای محدود کردن مسیرهای منبع یا فعل‌ها در هر مرحله از پیکربندی جریان پراکسی
- خط‌مشی‌های محافظت دربرابر تهدید JSON و XML برای محافظت دربرابر حملات مبتنی بر محتوا بااستفاده از JSON یا XML ناقص درخواست‌های داده‌بار
API6:2019 تخصیص انبوه
شرح تهدید
داده‌های فیلترنشده‌ای که ازطریق «میاناهای برنامه‌سازی کاربردی» به برنامه‌های کارخواه ارائه می‌شود به مهاجمان اجازه می‌دهد ازطریق درخواست‌ها ویژگی‌های شیء را حدس بزنند، یا از قراردادهای نام‌گذاری نقطه پایانی برای یافتن سرنخ‌هایی درباره مکان انجام تغییرات غیرمجاز یا دسترسی به ویژگی‌های اشیای داده ذخیره‌شده در زیرینه استفاده کنند.
این تهدید زمانی ایجاد می‌شود که داده‌های فیلترنشده (معمولاً در قالب JSON یا XML) به کارخواه ارسال شود، و به مهاجم اجازه دهد جزئیات پیاده‌سازی زیربنایی سیستم‌های پشتیبان شما و همچنین نام‌های دارایی عناصر داده محرمانه را حدس بزند. نتیجه این نوع حمله می‌تواند به‌طور بالقوه به مهاجم امکان دهد داده‌های نامناسب را بخواند یا دستکاری کند، یا در بدترین حالت، می‌تواند آسیب‌پذیری‌های اجرای کد ازراه‌دور را فعال کند.
معمولاً دو جنبه در اجازه دادن به این نوع تهدید دخیل است:
- دیدگاه طراحی API. هرگز برای انجام فیلتر کردن داده‌های سمت کارخواه به منطق برنامه تکیه نکنید، زیرا مهاجمان می‌توانند از برنامه‌ها سوءاستفاده کنند و برنامه‌ها مورداعتماد درنظر گرفته شوند. همواره طرحواره داده میانای برنامه‌سازی کاربردی خود را به‌گونه‌ای طراحی کنید که فقط حداقل داده‌های لازم برای فعال کردن سرویس میانای برنامه‌سازی کاربردی را آشکار کند
- دیدگاه پیاده‌سازی میانای برنامه‌سازی کاربردی. پیاده‌سازی فیلتر کردن داده‌ها و اعتبارسنجی طرحواره برای جلوگیری از نمایش سهوی داده‌های محرمانه به برنامه کاربر
از دیدگاه محصول Apigee، ما چندین ویژگی مفید برای اطمینان از اجرای فیلتر داده‌های قوی در میاناهای برنامه‌سازی کاربردی شما ارائه می‌دهیم.
خط‌مشی فیلتر کردن «مشخصات OpenAPI»
خط‌مشی OASValidation (اعتبارسنجی مشخصات OpenAPI) به شما امکان می‌دهد پیام درخواست یا پاسخ ورودی را دربرابر «مشخصات OpenAPI نسخه ۳.۰» (JSON یا YAML) اعتبارسنجی کنید. این خط‌مشی به شما اجازه می‌دهد:
- با ایجاد مشخصات OpenAPI (OAS)، میانای برنامه‌سازی کاربردی خود را طراحی کنید
- پیاده‌سازی میانجی‌گری، امنیت، و منطق ذخیره‌سازی نهان لازم برای نمایان کردن ایمن محصول میانای برنامه‌سازی کاربردی از زیرینه با Apigee
- درخواست‌های ورودی را دربرابر طرحواره داده تعریف‌شده در مشخصات OAS خود، ازجمله مسیر پایه، فعل، خط‌مشی پیام درخواست، و پارامترها اعتبارسنجی کنید
خط‌مشی «اعتبارسنجی پیام SOAP»
خط‌مشی اعتبارسنجی پیام SOAPبه شما امکان می‌دهد درخواست‌های مبتنی بر XML را با اعتبارسنجی پیام XML دربرابر طرحواره XSD یا اعتبارسنجی پیام SOAP دربرابر تعریف WSDL اعتبارسنجی کنید. علاوه‌براین، می‌توانید از خط‌مشی «اعتبارسنجی پیام» برای تأیید اینکه پایه‌بار پیام JSON یا XML به‌درستی قالب‌بندی شده است استفاده کنید، که شامل درستی‌سنجی موارد زیر در پیام XML یا JSON می‌شود:
- یک عنصر ریشه واحد وجود دارد
- محتوا نویسه‌های غیرقانونی ندارد
- اشیا و برچسب‌ها به‌درستی لانه‌گذاری شده‌اند
- برچسب‌های شروع و پایان مطابقت دارند
API7:2019 پیکربندی نادرست امنیتی
شرح تهدید
پیکربندی نادرست امنیتی معمولاً نتیجه پیکربندی‌های پیش‌فرض ناامن، پیکربندی‌های ناقص یا موقتی، فضای ذخیره‌سازی ابری باز، سرایندهای HTTP پیکربندی‌شده نادرست، روش‌های HTTP غیرضروری، هم‌رسانی منابع بین مبدأ (CORS) مجاز، و پیام‌های خطای پرحرف حاوی اطلاعات حساس است. مهاجمان اغلب تلاش می‌کنند نقص‌های وصله‌نشده، نقاط پایانی مشترک، یا فایل‌ها و دایرکتوری‌های محافظت‌نشده را پیدا کنند تا به سیستم موردنظرشان برای حمله دسترسی غیرمجاز پیدا کنند یا اطلاعاتی درباره آن به‌دست آورند. پیکربندی‌های امنیتی نادرست نه تنها می‌تواند داده‌های حساس کاربر را افشا کند، بلکه می‌تواند جزئیات سیستم را نیز افشا کند که ممکن است منجر به به‌خطر افتادن کامل سرور شود. علاوه‌براین، برخی‌از موارد استفاده دیگر برای آسیب‌پذیری‌های پیکربندی‌های امنیتی نادرست ممکن است شامل موارد زیر باشد:
- «امنیت لایه انتقال» پیکربندی بد
- پیام‌های خطا با ردیابی پشته‌ای
- سیستم‌های وصله‌نشده
- پانل‌های مدیریت سرور یا فضای ذخیره‌سازی آشکارشده
سازمان‌ها می‌توانند اقدامات مختلفی برای رسیدگی و کاهش چالش‌های مربوط به پیکربندی‌های نادرست امنیتی انجام دهند، ازجمله:
- ایجاد و استانداردسازی فرایندهای مقاوم‌سازی و وصله‌گذاری
- توسعه حاکمیت در اکوسیستم میانای برنامه‌سازی کاربردی
- محدود کردن دسترسی سرپرست و فعال کردن ممیزی و هشدار
جریان‌های هم‌رسانی‌شده و قلاب‌های جریان
Apigee از مفهوم جاری‌سازی هم‌رسانی‌شده پشتیبانی می‌کند که به توسعه‌دهندگان API امکان می‌دهد خط‌مشی‌ها و منابع را در گروهی قابل‌استفاده مجدد ترکیب کنند. جریان مشترک با ثبت کردن عملکرد قابل‌استفاده مجدد در یک مکان به شما کمک می‌کند تا از یکپارچگی اطمینان حاصل کنید، زمان توسعه را کاهش دهید، و کد را راحت‌تر مدیریت کنید. می‌توانید جریان مشترکی را در داخل پراکسی‌های API مجزا بگنجانید، یا می‌توانید یک گام فراتر بردارید و جریان‌های مشترک را در قلاب‌های جریان قرار دهید تا منطق جریان مشترک به‌طور خودکار برای هر پراکسی API که در همان محیط جریان مشترک مستقر شده است اجرا شود.
پایش میانای برنامه‌سازی کاربردی
Apigee پلاتفرم جامع پایش میانای برنامه‌سازی کاربردی را ارائه می‌دهد. «پایش میانای برنامه‌سازی کاربردی» سازمان‌ها را قادر می‌سازد تا مشکلات عملکرد و ترافیک میانای برنامه‌سازی کاربردی را به‌صورت پیشگیرانه شناسایی کنند. «پایش میانای برنامه‌سازی کاربردی Apigee» با «Apigee Edge برای ابر عمومی» کار می‌کند تا اطلاعات آماری زمینه‌ای هم‌زمان درباره عملکرد میانای برنامه‌سازی کاربردی ارائه دهد، به تشخیص سریع مشکلات کمک کند، و اقدامات اصلاحی برای تداوم کسب‌وکار را تسهیل کند.
شکل: Apigee API Monitoring طیف گسترده‌ای از ابزارها را برای پایش، بررسی، و اقدام درخصوص مشکلات ارائه می‌دهد. این پلتفرم از بهترین ویژگی‌های هوشمند در Google Cloud Platform بهره می‌برد.
Apigee Sense
Apigee Sense به محافظت از میاناهای برنامه‌سازی کاربردی دربرابر ترافیک درخواست ناخواسته، ازجمله حمله‌های مشتریان مخرب، کمک می‌کند. Apigee Sense ترافیک درخواست API را تجزیه‌وتحلیل می‌کند و الگوهایی را که ممکن است نشان‌دهنده درخواست‌های ناخواسته باشند شناسایی می‌کند.
سازمان‌ها بااستفاده از این تجزیه‌وتحلیل می‌توانند مشتریانی را که درخواست‌های ناخواسته ارسال می‌کنند شناسایی کنند، سپس برای مجاز کردن، مسدود کردن، یا پرچم‌گذاری کردن آن درخواست‌ها اقدام کنند. با Apigee Sense، می‌توان از «میاناهای برنامه‌سازی کاربردی» دربرابر الگوهای درخواست محافظت کرد که شامل موارد زیر می‌شود:
- رفتار خودکارسازی‌شده‌ای که با رفتار انسانی ترکیب می‌شود
- تلاش‌های مداوم از همان IP
- نرخ خطای غیرمعمول
- درخواست‌های مشکوک کارخواه
- خزیدن داده
- برداشت کلید
- فعالیت‌های ناگهانی
- الگوهای جغرافیایی
API8:2019 تزریق
شرح تهدید
تزریق داده‌های غیرقابل‌اعتماد، مثل SQL، NoSQL، XML Parsers، ORM، LDAP، OS Commands، و JavaScript، در درخواست‌های API می‌تواند منجر به اجرای دستورات ناخواسته یا دسترسی غیرمجاز به داده‌ها شود. مهاجمان ازطریق هر بردار تزریقی که دردسترس باشد، مثل ورودی مستقیم، پارامترها، سرویس‌های یکپارچه، و غیره، داده‌های مخرب را به API وارد می‌کنند و انتظار دارند که این داده‌ها به یک مفسر ارسال شود. مهاجمان می‌توانند این نقص‌ها را به‌راحتی هنگام بررسی کد منبع بااستفاده از اسکنرهای آسیب‌پذیری و fuzzers کشف کنند. تزریق موفق می‌تواند منجر به افشای اطلاعات شود و بر محرمانگی و ازدست رفتن داده‌ها تأثیر بگذارد یا در برخی موارد ممکن است منجر به DoS نیز شود.
شیوه‌های برتر برای کاهش خطاهای تزریق/حمله‌ها شامل تعریف دقیق داده‌های ورودی مانند طرحواره‌ها، انواع، الگوهای رشته‌ای، انجام اعتبارسنجی ورودی، بررسی محدودیت‌ها و اعمال آن‌ها در زمان اجرا است. پلاتفرم Apigee امکان اعتبارسنجی داده‌های ورودی را بااستفاده از فیلترها فراهم می‌کند تا فقط مقادیر معتبر برای هر پارامتر ورودی مجاز باشد.
Apigee Edge که به‌عنوان سرور برای درخواست‌های ورودی API عمل می‌کند، بررسی می‌کند که ساختار داده‌بار در محدوده قابل‌قبول باشد، که به آن بررسی محدودیت نیز گفته می‌شود. می‌توانید کارگزار میانای برنامه‌سازی کاربردی را پیکربندی کنید تا روال اعتبارسنجی ورودی، ورودی را تبدیل کند و توالی‌های نویسه خطرناک را بردارد و آن‌ها را با مقادیر ایمن جایگزین کند.
خط‌مشی «محافظت از عبارت باقاعده»
خط‌مشی RegularExpressionProtection اطلاعات را از پیام استخراج می‌کند (برای نمونه، مسیر نشانی وب، پارامتر پُرسمان، سرایند، پارامتر فرم، متغیر، پایه‌بار XML، یا پایه‌بار JSON) و آن محتوا را دربرابر عبارات باقاعده ازپیش‌تعریف‌شده ارزیابی می‌کند. اگر هریک از عبارت‌های باقاعده مشخص‌شده به درست ارزیابی شود، پیام به‌عنوان تهدید درنظر گرفته می‌شود و رد می‌شود. عبارت باقاعده، یا به‌اختصار regex، مجموعه‌ای از رشته‌ها است که الگویی را در یک رشته مشخص می‌کند. عبارت‌های باقاعده امکان ارزیابی برنامه‌ریزی‌شده محتوا برای الگوها را فراهم می‌کنند. برای مثال، از عبارت‌های باقاعده می‌توان برای ارزیابی نشانی ایمیل استفاده کرد تا مطمئن شویم ساختار آن درست است.
رایج‌ترین کاربرد RegularExpressionProtection ارزیابی محتوای مخرب در بار داده‌های JSON و XML است.
هیچ عبارت باقاعده‌ای نمی‌تواند همه حملات مبتنی بر محتوا را حذف کند و باید چندین سازوکار با هم ترکیب شوند تا دفاع در عمق فعال شود. این بخش برخی‌از الگوهای توصیه‌شده برای جلوگیری از دسترسی به محتوا را شرح می‌دهد.
رویکردهای دیگری برای اعتبارسنجی ورودی در پلاتفرم Apigee دردسترس است:
- خط‌مشی JSONThreatProtection پایه‌بار JSON را ازنظر وجود تهدید بررسی می‌کند
- خط‌مشی XMLThreatProtection بار XML را ازنظر وجود تهدید بررسی می‌کند
- اعتبارسنجی پارامتر را می‌توان بااستفاده از جاوا اسکریپت انجام داد
- اعتبارسنجی سرایند بااستفاده از جاوا اسکریپت انجام می‌شود
اعتبارسنجی انواع محتوا
نوع محتوا به محتوای فایلی اشاره دارد که ازطریق HTTP منتقل می‌شود و براساس ساختار دو بخشی طبقه‌بندی می‌شود. Apigee توصیه می‌کند انواع محتوا را برای «درخواست» و «پاسخ» بااستفاده از منطق شرطی که در زیر توضیح داده شده است اعتبارسنجی کنید.
- درخواست - از منطق شرطی در جریان پراکسی برای بررسی «نوع محتوا» استفاده کنید. از خط‌مشی‌های AssignMessage یا RaiseFault برای برگرداندن سفارشی پیام خطا استفاده کنید.
- پاسخ - از منطق شرطی در جریان پراکسی برای تأیید Content-Type استفاده کنید. از خط‌مشی AssignMessage برای تنظیم سرصفحه Content-Type استفاده کنید، یا از خط‌مشی AssignMessage یا RaiseFault برای برگرداندن پیام خطای سفارشی استفاده کنید.
API9:2019 مدیریت نادرست دارایی‌ها
شرح تهدید
مدیریت ناکافی محیط و تفکیک محیط به مهاجمان اجازه می‌دهد به نقاط پایانی API با امنیت پایین دسترسی پیدا کنند. نبودن پادمان‌های حکمرانی نیز باعث می‌شود منابع منسوخ‌شده به‌طور غیرضروری درمعرض دید قرار گیرند.
با بهره‌گیری از قابلیت‌های بالغ Apigee برای مدیریت چرخه حیات کامل API، می‌توان به این تهدید رسیدگی کرد. این قابلیت‌ها به شما امکان می‌دهد مدل حکمرانی جامعی ایجاد کنید که همکاری بین تیم‌ها را ممکن می‌کند و درعین‌حال، تفکیک مسئولیت‌ها بین ذینفعان امنیتی و توسعه‌دهندگان API را اعمال می‌کند. مرزها و کنترل‌ها را می‌توان بااستفاده از موارد زیر پیکربندی و نگهداری کرد:
سازمان‌ها، محیط‌ها، و بازبینی‌ها: نرده‌های محافظ مجازی و فیزیکی که ازطریق زمینه‌های زمان اجرا، جداسازی و فرایند ارتقای ایمن را تضمین می‌کنند.
کنترل دسترسی مبتنی بر نقش: فقط افراد ضروری در تیم‌های API شما اجازه مدیریت تغییرات پیکربندی و همچنین فرایند ارتقا را خواهند داشت.
اسناد API مدیریت مخاطبان: پس‌از اینکه API در درگاه توسعه‌دهندگان منتشر شد، می‌توانید با مدیریت مخاطبان هدف، رؤیت‌پذیری اسناد را محدود کنید.
قلاب‌های جریان: می‌توانید خط‌مشی‌ها و الگوهای جهانی را که می‌توانند به‌عنوان نرده‌های محافظ ممتاز مدیریت شوند و توسعه‌دهندگان API نمی‌توانند آن‌ها را تغییر دهند اعمال کنید.
سازمان‌ها و محیط‌ها
کاربران، ویژگی‌ها، و عناصر پیکربندی در Apigee می‌توانند به سازمان‌ها و/یا محیط‌های خاصی محدود شوند. این یعنی پلاتفرم دارای نرده‌های محافظ ازپیش ساخته‌شده‌ای است که می‌توانند در اطراف میاناهای برنامه‌سازی کاربردی و پیکربندی پشتیبانی‌کننده آن‌ها قرار گیرند.
سازمان‌ها: سازمان مستأجر سطح بالا در Apigee است. این ویژگی به شما امکان می‌دهد تا برای ترافیک، پیکربندی، و کاربران تفکیک کامل داشته باشید. به‌عنوان یک روال مطلوب حکمرانی، باید سازمان‌های تولید و غیرتولید جداگانه داشته باشید. این رویه به‌طور مؤثر از ترکیب داده‌های تولید، کاربران، و ترافیک با محیط‌های پایین‌تر جلوگیری می‌کند.
محیط‌ها: «میاناهای برنامه‌سازی کاربردی» در Apigee می‌توانند ازطریق چندین وضعیت استقرار ارتقا یابند؛ هر وضعیت به یک زمینه اجرا پیوند داده می‌شود. بافت محیط درطول فرایند ارتقا منتقل نمی‌شود، بنابراین از آشکار شدن پیکربندی حساس برای کاربران بدون امتیاز جلوگیری می‌شود.
ویرایش‌ها: ویرایش‌ها به میاناهای برنامه‌سازی کاربردی و ویژگی‌های فردی اجازه می‌دهند که به‌طور یکپارچه ازطریق محیط‌ها ارتقا یابند.
کنترل دسترسی نقش‌مبنا
برای کاهش API9، ضروری است که تعریف‌های واضحی از وظایف ذینفعان امنیتی و توسعه‌دهندگان API داشته باشیم و این وظایف را از هم جدا کنیم. همان‌طور که قبلاً در این سند ذکر شد، Apigee قابلیت‌های انعطاف‌پذیر «کنترل دسترسی نقش‌مبنا» دارد که به شما امکان می‌دهد اجازه‌ها را به نقش‌های سفارشی اختصاص دهید. برای این تهدید خاص، نقش‌ها می‌توانند محدوده داشته باشند تا در هر سازمان، محیط، یا پیکربندی دقیق‌تر اجازه‌های محدودی داشته باشند. به‌عنوان یک رویه ترجیحی، درنظر بگیرید که امتیازات تغییر وضعیت استقرار میاناهای برنامه‌سازی کاربردی را ازطریق محیط‌ها محدود کنید و همچنین مطمئن شوید که توسعه‌دهندگان نمی‌توانند به کتابخانه‌های امنیتی جهانی (قلاب‌های جریان) دسترسی داشته باشند یا آن‌ها را تغییر دهند. این نقش‌های محدود از تغییرات ناخواسته در خط‌مشی‌های امنیتی جهانی که پوشش گسترده‌ای در هر دو نقطه پایانی منتشرشده قدیمی و فعلی دارند جلوگیری می‌کنند.
«مدیریت مخاطبان» برای «مستندات میانای برنامه‌سازی کاربردی»
«درگاه توسعه‌دهندگان» جزء محوری برای موفقیت «استراتژی API» شما است؛ این درگاه به شما امکان می‌دهد فهرست جامعی از همه اسناد مربوط به APIهای خود، ازجمله میزبان‌ها/نقاط پایانی، منابع، عملیات، طرحواره‌های داده‌بار، و موارد دیگر را حفظ کنید. در Apigee می‌توانید میاناهای برنامه‌سازی کاربردی خود را بااستفاده از ساختارهای «محصول API» گروه‌بندی کنید. «محصولات API» براساس دسته‌های منابع و عملیات تعریف می‌شوند که در یک زمینه کسب‌وکار و امنیتی یکسان قرار می‌گیرند (برای نمونه، طرح خدمات، دامنه کسب‌وکار، دسته، سلسله مراتب شرکت، و غیره).
با درگاه توسعه‌دهنده یکپارچه Apigee می‌توانید «محصولات API» را منتشر کنید و با مدیریت مخاطبان هدف، رؤیت‌پذیری محتوای منتشرشده را محدود کنید. این قابلیت با استراتژی تقسیم‌بندی محتوا که با الزامات کسب‌وکار و امنیت هم‌راستا است مطابقت دارد.
قلاب‌های Flow
فرایندهای تبلیغات و انتشار برای «میاناهای برنامه‌سازی کاربردی» باید همیشه شامل فرایندهای انطباق و گواهینامه امنیتی باشد. برای اینکه تیم‌های API مؤثر باشند، باید بتوانند بااستفاده از ابزارهای مناسب، موانعی ایجاد کنند که جدایی مسئولیت‌ها را تضمین کند و درعین‌حال چرخه‌های انتشار چابک را حفظ کند.
Apigee به شما امکان می‌دهد با اعمال خط‌مشی‌های جهانی ازطریق قلاب‌های جریان، وظایف مدیریت امنیت را ارتقا دهید. این خط‌مشی‌های جهانی می‌توانند به‌عنوان نرده‌های محافظ ممتاز مدیریت شوند که توسعه‌دهندگان «میانای برنامه‌سازی کاربردی» نمی‌توانند آن‌ها را تغییر دهند، بنابراین تفکیک مسئولیت‌ها تضمین می‌شود و با اعمال امنیت پیش‌فرض و، درنتیجه، ارائه سازگاری امنیتی برای همه «میاناهای برنامه‌سازی کاربردی» مستقر در یک محیط اجرای معین، چابکی نیز ترویج داده می‌شود.
شکل: نرده‌های محافظ ممتاز را می‌توان ازطریق «قلاب‌های جریان» و «جریان‌های مشترک» در Apigee پیکربندی کرد. ذینفعان امنیتی مسئول حفظ خط‌مشی‌های جهانی مرتبط با امنیت هستند. این ویژگی‌ها جدایی مسئولیت‌ها را تضمین می‌کنند و چرخه‌های عمر توسعه چابک را ترویج می‌کنند.
API10:2019 گزارش‌گیری و نظارت ناکافی
شرح تهدید
ثبت گزارش، نظارت، و هشدارهای ناکافی باعث می‌شود حملات درحال انجام شناسایی نشوند و بنابراین باید راهبردی برای کسب اطلاعات آماری درباره رویدادهای مهمی که بر کسب‌وکارتان تأثیر می‌گذارند الزامی شود.
استراتژی‌های مدیریت رویداد و گزارش‌گیری برای «میاناهای برنامه‌سازی کاربردی» باید روال‌های مطلوب زیر را درنظر بگیرند:
- خط‌مشی مدیریت گزارش‌ها: مستندسازی و اجرای قوانین برای استانداردسازی و کنترل جزئیات گزارش، سطوح گزارش، یکپارچگی گزارش، مخزن متمرکز، و غیره
- خط‌مشی مدیریت رویداد: تضمین می‌کند که هر رویداد باید به منبع خود قابل ردیابی باشد. همچنین، رویدادها باید براساس اهمیت و تأثیر کسب‌وکار دسته‌بندی شوند
- گزارش‌ها و ممیزی‌ها: ذینفعان امنیت و عملیات باید بتوانند به گزارش‌های لحظه‌ای و رویدادها دسترسی داشته باشند و به آن‌ها واکنش نشان دهند. علاوه‌براین، چرخه‌های تقویت را می‌توان توسط افراد ذی‌نفع انجام داد تا الگوهای تشخیص براساس داده‌های تاریخی تنظیم شود
Apigee ابزارهای لازم را برای ایجاد یک استراتژی جامع مدیریت رویداد و گزارش‌گیری ارائه می‌دهد. این ابزارها شامل موارد زیر می‌شود:
خط‌مشی گزارش‌گیری: براساس داده‌های ترافیک یا فراداده‌های ترافیک API خود، جاری‌سازی‌های گزارش ایجاد کنید. با بهره‌گیری از منطق شرطی و الگوهای پیام، انعطاف‌پذیری لازم را برای تصمیم‌گیری درباره میزان جزئیات جاری‌سازی دارید.
مجموعه عملیات ابری Google: از یکپارچه‌سازی آماده استفاده در ابزارهای پایش و گزارش‌گیری بسیار مقیاس‌پذیر Google بهره ببرید.
خدمات خط‌مشی نوشته راهنما: از جاری‌سازی‌های گزارش که برای ارسال رویدادها به نقطه پایانی HTTP نیاز دارند پشتیبانی می‌کند.
Analytics: ازطریق گزارش‌های سفارشی و/یا آماده به فراداده‌های ترافیک تاریخی دسترسی پیدا کنید و آن‌ها را تجزیه‌وتحلیل کنید. براساس گرایش‌ها هشدار ایجاد و مدیریت کنید و ناهنجاری‌های ترافیک را درک کنید.
پایش میانای برنامه‌سازی کاربردی: همان‌طور که قبلاً توضیح داده شد، این ابزار قابلیت‌های هشداردهی ارائه می‌دهد که براساس رویدادهای مهم می‌توانند راه‌اندازی شوند. گزارش‌های ترافیک را می‌توان بیشتر تجزیه‌وتحلیل کرد و براساس آن‌ها اقدام کرد.