10 تهدید برتر API OWASP

شما در حال مشاهده مستندات Apigee Edge هستید.
به مستندات Apigee X مراجعه کنید . اطلاعات

این سند رویکردهای مختلفی را که می‌توانید در Apigee برای رفع آسیب‌پذیری‌های امنیتی شناسایی‌شده توسط OWASP استفاده کنید، شرح می‌دهد. برای رویکردهای بیشتر مستند شده برای Apigee، به 10 گزینه برتر کاهش خطرات OWASP در سال 2021 در Google Cloud مراجعه کنید.

مقدمه

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

این سند، رویکردهای محافظت در برابر حملات رایج مبتنی بر API را که توسط ده تهدید امنیتی برتر API در سال ۲۰۱۹ توسط OWASP شناسایی شده‌اند، مورد بحث قرار خواهد داد. یکی از مضامین رایج در تهدیدات برتر که در آخرین فهرست برجسته شده‌اند، ناشی از قرارگیری نامناسب کنترل‌های احراز هویت و مجوزدهی است، مانند اتکا به فیلتر کردن داده‌های بازگردانده شده توسط یک درخواست API در برنامه‌های کلاینت، با استفاده از الگوی متضاد اتکا به برنامه کلاینت مصرف‌کننده برای انجام اجرای کنترل دسترسی.

با رشد سریع اکوسیستم API، متأسفانه سوءاستفاده‌ها و سوءاستفاده‌های API که منجر به استخراج داده‌ها توسط مهاجمان می‌شود، امروزه به یکی از رایج‌ترین مسیرهای حمله تبدیل شده است. امنیت همچنان با تعدادی ویژگی جدید مانند Advanced API Ops که شامل ویژگی‌های تشخیص ناهنجاری است، اولویت اصلی Apigee است. با این حال، طراحی و پیاده‌سازی صحیح ویژگی‌های امنیتی Apigee برای کاهش احتمال حملات موفقیت‌آمیز به APIهای شما بسیار مهم است.

برنامه‌های کاربردی مصرف‌کننده باید غیرقابل اعتماد یا «عمومی» در نظر گرفته شوند، زیرا شما پلتفرمی را که برنامه روی آن اجرا می‌شود کنترل نمی‌کنید. فرض کنید که هر برنامه عمومی می‌تواند و مورد نفوذ قرار خواهد گرفت، بنابراین نمی‌توان به آنها برای اعمال کنترل دسترسی ( API1 ، API5 )، فیلتر کردن داده‌های پاسخ ( API6 ) یا ذخیره ایمن اسرار مشتری ( API2 ) مانند کلیدهای API یا توکن‌های دسترسی اعتماد کرد. برخی از توصیه‌ها از بررسی 10 برنامه برتر OWASP در سال 2019 به دست آمده است:

  • مشخص کنید که چه نوع برنامه‌های کلاینتی از APIهای شما استفاده خواهند کرد (SPA، موبایل یا مبتنی بر مرورگر) و الگوهای احراز هویت، مجوز و امنیت مناسب را طراحی کنید.
  • همیشه از جریان‌های «مشتری عمومی» OAuth یا OpenID Connect استفاده کنید (استفاده از PKCE اکیداً توصیه می‌شود)
  • در مورد منطق تجاری برنامه خود فکر کنید، ابتدا مشخصات OpenAPI خود را تعریف کنید و پروکسی‌های API خود را طوری طراحی کنید که تمام داده‌های پاسخ از backend را در Apigee فیلتر کنند. هرگز برای انجام این کار به منطق کد برنامه پایین‌دستی تکیه نکنید!
  • تمام درخواست‌های داده حاوی اطلاعات شخصی کاربر (PII) را فیلتر کنید تا فقط داده‌هایی از backend شما که متعلق به کاربر درخواست‌کننده است، مجاز باشند.

API1:2019 مجوز سطح شیء خراب است

شرح تهدید

اعتبارسنجی ناکافی مجوز برای درخواست دسترسی به شیء، به مهاجم اجازه می‌دهد تا با استفاده مجدد از توکن دسترسی، اقدام غیرمجازی انجام دهد. این تهدید ناشی از پیکربندی نامناسب اعتبارسنجی‌های مجوز است. Apigee سیاست‌های VerifyApiKey، OAuth و JSON Web Token (JWT) را ارائه می‌دهد که به محافظت در برابر این آسیب‌پذیری کمک می‌کنند، اما بسیار مهم است که این سیاست‌ها به درستی پیکربندی شوند تا از این تهدید جلوگیری شود.

برای جلوگیری از این تهدید، همکاری نزدیک تیم‌های توسعه و امنیت برنامه کاربردی بسیار مهم است. مجوزدهی ذاتاً موضوعی پیچیده است و مجوزدهی دقیق و مؤثر نیازمند درک عمیقی از منطق کسب‌وکار برنامه کاربردی است.

از دیدگاه پیاده‌سازی Apigee، دو جنبه اصلی وجود دارد که باید در نظر گرفته شوند:

  • یکپارچگی توکن دسترسی
  • اجرای کنترل دسترسی

یکپارچگی توکن دسترسی

بسیار مهم است که با استفاده از جریان صحیح OAuth یا OpenID Connect به همراه مکانیزم اعتبارسنجی یا امضای اعتبارنامه مناسب، تأیید شود که توکن ارائه شده توسط کلاینت درخواست‌کننده دستکاری نشده است. Apigee از تمام جریان‌های رایج OAuth پشتیبانی می‌کند.

سیاست‌های تأیید توکن دسترسی Apigee شامل موارد زیر است:

اجرای کنترل دسترسی

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

Apigee دو مکانیسم اصلی برای تأیید و اجرای سیاست‌های مجوز ارائه می‌دهد:

  • داخلی : استفاده از جریان‌های شرطی برای ارزیابی درخواست‌های دسترسی بر اساس ادعاهای استخراج‌شده به عنوان متغیرهای جریان از یک توکن مجوز
  • واگذار شده : استفاده از فراخوانی سرویس به یک راهکار مدیریت دسترسی شخص ثالث

رویکرد داخلی (که در شکل بالا نشان داده شده است) زمانی توصیه می‌شود که مدل کنترل دسترسی نسبتاً سرراست باشد. برای مثال، اگر بتوان از ادعاهای استخراج‌شده از یک توکن دسترسی برای ارزیابی و تأیید مستقیم یک درخواست شیء API استفاده کرد.

از متغیرهای جریان موجود برای سیاست‌های OAuth یا JWT برای ارزیابی درخواست‌های دسترسی با استفاده از دستورات جریان شرطی استفاده کنید.

رویکرد وکالتی (که در شکل بالا نشان داده شده است) زمانی توصیه می‌شود که نتوان از claim های استخراج شده از یک access token به طور مستقیم برای تأیید درخواست API به یک شیء backend استفاده کرد، یا برای انواع جریان OAuth پیچیده‌تر که برای دریافت access token نیاز به فراخوانی جداگانه به یک سرور تأیید دارند.

با استفاده از سیاست فراخوانی سرویس ، می‌توان از یک سرویس شخص ثالث درخواست تصمیم‌گیری در مورد سیاست مجوز کرد، یا اطلاعات ادعایی بیشتری در مورد عامل درخواست‌کننده به دست آورد تا سپس با استفاده از یک جریان شرطی، تصمیم کنترل دسترسی اتخاذ شود.

API2:2019 احراز هویت کاربر با مشکل مواجه شد

شرح تهدید

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

  • همیشه هم عامل کاربر (برنامه) و هم کاربر درخواست‌کننده را احراز هویت کنید
  • از الگوهای احراز هویت و مجوز تفویض‌شده استفاده کنید و از ارسال مستقیم رمزهای عبور در یک درخواست API خودداری کنید.
  • همیشه امضای اعتبارنامه‌های دسترسی را اعتبارسنجی کنید و مطمئن شوید که تمام اعتبارنامه‌های دسترسی مورد استفاده، زمان انقضای مشخصی دارند.
  • با تعیین سهمیه‌بندی و استفاده از Apigee Sense برای شناسایی و پاسخ به حملات brute force که توسط ربات‌ها هدایت می‌شوند، از حملات brute force جلوگیری کنید.

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

در اینجا چند عنصر اصلی برای بررسی وجود دارد که هر دو در بخش‌های بعدی مورد بررسی قرار خواهند گرفت:

  • طراحی امنیتی : استفاده کامل از ویژگی‌های Apigee برای پیاده‌سازی الگوهای احراز هویت
  • مدیریت : اطمینان از اینکه الگوهای احراز هویت طراحی‌شده به طور صحیح و مداوم در تمام محصولات API منتشر شده استفاده می‌شوند.
  • امنیت عملیاتی : توانایی تشخیص رفتارهای مشکوک یا غیرعادی و تلاش برای دور زدن یا حمله‌ی جستجوی فراگیر (brute force) پروکسی‌های API احراز هویت شده

طراحی امنیتی

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

RFCهای OpenID Connect و OAuth تعداد زیادی از جریان‌های احراز هویت و مجوز تفویض‌شده و همچنین بازیگران درگیر در این جریان‌ها را ارائه می‌دهند. این یک موضوع پیچیده است و جای تعجب نیست که احراز هویت ناقص یکی از تهدیدات اصلی OWASP API است. ارائه یک مقدمه جامع در مورد پیاده‌سازی صحیح استانداردهای هویت خارج از محدوده این سند است، با این حال Apigee منابع اضافی زیادی برای درک بهتر جریان‌های OAuth، مانند این کتاب الکترونیکی و پخش وب و پیاده‌سازی نمونه ، دارد.

سیاست‌های احراز هویت

سیاست‌های Apigee که به رفع نگرانی‌های مربوط به هویت و احراز هویت کمک می‌کنند عبارتند از:

  • تأیید یا تولید توکن‌های دسترسی، توکن‌های به‌روزرسانی یا توکن‌های جریان پاسخ هنگام استفاده از چارچوب OAuth 2.0 . توجه: از نظر فنی، OAuth یک چارچوب مجوزدهی تفویضی است، با این حال به طور گسترده در الگوهای احراز هویت تفویضی یا فدرال استفاده می‌شود.
  • تأیید ، رمزگشایی و تولید توکن‌های وب JSON و امضاهای وب JSON در OpenID Connect 1.0
  • تولید و اعتبارسنجی ادعاهای SAML
  • تأیید کلیدهای API
  • تأیید کد احراز هویت پیام هش‌شده با کلید ( HMAC )

مدیریت ترافیک

ویژگی‌های مدیریت ترافیک Apigee که در ادامه آمده است، به محافظت در برابر حملات جستجوی فراگیر کمک می‌کند:

  • سیاست Spike Arrest ، برای تنظیم محدودیت نرخ میانگین متحرک کلی روی یک پروکسی API
  • سیاست‌های سهمیه‌بندی ، برای تنظیم محدودیت‌های نرخ دقیق برای پروکسی‌های API بر اساس سهمیه‌های تعریف‌شده توسط کلیدهای برنامه، توسعه‌دهندگان یا سهمیه‌های محصول API
  • سیاست‌های ذخیره‌سازی، برای ذخیره‌سازی توکن‌های دسترسی ذخیره‌شده بر اساس زمان انقضای تعریف‌شده‌ی آن‌ها، و همچنین قابلیت نامعتبر کردن اعتبارنامه‌های ذخیره‌سازی‌شده (برای مثال، در شرایطی که یک توکن دسترسی معتبر به خطر افتاده است)

حکومتداری

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

Apigee تعدادی ویژگی و ابزار برای اطمینان از یکپارچگی پیاده‌سازی و جلوگیری از خطاهای پیکربندی نادرست ارائه می‌دهد.

کنترل دسترسی مبتنی بر نقش (RBAC)

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

Apigee با ارائه قابلیت‌هایی برای شما جهت اختصاص کاربران به نقش‌های از پیش تعریف شده یا ایجاد نقش‌های سفارشی متناسب با تیم‌های API شما، ویژگی‌هایی را برای مدیریت دسترسی مبتنی بر نقش فراهم می‌کند. تعریف و مدیریت صحیح تخصیص نقش برای شما بسیار مهم است تا بتوانید برنامه API خود را به طور ایمن مقیاس‌بندی کنید. همچنین می‌توانید از Federation برای ادغام با دایرکتوری شرکتی موجود خود و کاهش نیاز به مدیریت مجموعه دوم اعتبارنامه‌های مدیریتی در Apigee استفاده کنید.

جریان‌های مشترک

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

شکل: جریان‌های مشترک، بسته‌های قابل استفاده مجدد از سیاست‌ها و منطق شرطی هستند که به شما امکان می‌دهند یک الگوی مرکب را حفظ کنید.

امنیت عملیاتی

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

حس آپیجی

Apigee Sense از APIهای شما در برابر ترافیک درخواست‌های ناخواسته، از جمله حملات کلاینت‌های مخرب، محافظت می‌کند. Apigee Sense ترافیک درخواست‌های API را تجزیه و تحلیل می‌کند و الگوهایی را که ممکن است نشان‌دهنده درخواست‌های ناخواسته باشند، شناسایی می‌کند. با استفاده از این تجزیه و تحلیل، می‌توانید کلاینت‌هایی را که درخواست‌های ناخواسته دارند شناسایی کنید، سپس برای مجاز کردن، مسدود کردن یا علامت‌گذاری این درخواست‌ها اقدام کنید. ویژگی‌های آینده Sense شامل امکان فعال کردن خودکار تأیید ReCAPTCHA در ترافیک مشکوک خواهد بود.

با Apigee Sense، می‌توانید APIهای خود را از الگوهای درخواستی که شامل موارد زیر هستند، محافظت کنید:

  • رفتار خودکار که با رفتار انسانی ترکیب می‌شود
  • تلاش‌های مداوم از همان IP
  • نرخ خطاهای غیرمعمول
  • درخواست‌های مشکوک مشتریان
  • خزش داده‌ها
  • حملات جستجوی فراگیر (brute force) برای جمع‌آوری کلید و احراز هویت
  • انفجار فعالیت
  • الگوهای جغرافیایی

عملیات پیشرفته API

در حالی که Sense به طور خاص برای شناسایی و پاسخ به تهدیدهای شبیه ربات طراحی شده است، Advanced API Ops شامل تشخیص ناهنجاری و تعریف هشدار پیشرفته است.

تشخیص ناهنجاری با اعمال مدل‌های هوش مصنوعی (AI) و یادگیری ماشین (ML) بر روی داده‌های API شما انجام می‌شود. تشخیص ناهنجاری می‌تواند در صورت بروز سناریوهایی که حتی به آنها فکر هم نکرده‌اید، هشدارهایی را به صورت بلادرنگ ایجاد کند تا بهره‌وری شما را بهبود بخشد و میانگین زمان لازم برای حل مشکلات API شما (MTTR) را کاهش دهد.

Advanced API Ops بر اساس مکانیزم هشدار مانیتورینگ API موجود ساخته شده است تا انواع هشدار پیشرفته زیر را اضافه کند:

  • هشدارهای ناهنجاری . Edge مشکلات ترافیک و عملکرد را تشخیص می‌دهد، به جای اینکه شما مجبور باشید خودتان آنها را از پیش تعیین کنید. سپس می‌توانید برای این ناهنجاری‌ها هشدار دهید.
  • هشدارهای انقضای TLS . هنگامی که یک گواهی TLS به انقضا نزدیک می‌شود، اعلانی ارسال می‌کند.

API3:2019 افشای بیش از حد داده‌ها

شرح تهدید

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

یکی از اصول طراحی « از بیرون به درون » Apigee برای طراحی API، صرفه‌جویی در داده‌ها است. با طراحان و توسعه‌دهندگان UX خود همکاری کنید تا فقط داده‌هایی را از طریق APIهایی که در رابط کاربری برنامه شما مورد نیاز هستند، در معرض نمایش قرار دهید. سیستم‌های Backend برای الگوهای استفاده عمومی ساخته نشده‌اند، بنابراین یکی از اولین وظایف طراحی اولیه API با Apigee، کاهش داده‌های در معرض نمایش به حداقل مقدار لازم برای ارائه یک محصول API عالی برای مشتریان و توسعه‌دهندگان شما است.

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

از دیدگاه امنیتی، این تهدید ناشی از واگذاری اجرای مجوز به یک برنامه است، اما اغلب بر روی پلتفرم یا سیستم عاملی که شما هیچ کنترلی بر آن ندارید. ما قبلاً در API1 و API2 اهمیت پیاده‌سازی صحیح احراز هویت و مجوز را برای جلوگیری از دسترسی غیرمجاز به داده‌ها بررسی کرده‌ایم.

بخش‌های بعدی چگونگی انجام موارد زیر را بررسی می‌کنند:

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

بازنویسی پاسخ‌ها و درخواست‌ها

سیستم‌های Backend معمولاً برای استفاده در برنامه‌های عمومی یا در شبکه‌های عمومی غیرقابل اعتماد طراحی نشده‌اند. Apigee Edge به گونه‌ای طراحی شده است که با محافظت از backendهای شما در برابر افشای بیش از حد داده‌ها، شما را قادر به استقرار محصولات API عمومی کند.

برای انجام این کار، Apigee از سه سیاست کلیدی استفاده می‌کند:

  • اختصاص پیام
  • توضیحات کد
  • مدیریت خطا

سیاست اختصاص پیام

سیاست اختصاص پیام، پیام‌های درخواست و پاسخ جدید را در طول جریان پروکسی API تغییر می‌دهد یا ایجاد می‌کند. این سیاست به شما امکان می‌دهد اقدامات زیر را روی آن پیام‌ها انجام دهید:

  • پارامترهای فرم، سرصفحه‌ها یا پارامترهای پرس‌وجوی جدید را به یک پیام اضافه کنید
  • کپی کردن ویژگی‌های موجود از یک پیام به پیام دیگر
  • حذف هدرها، پارامترهای پرس و جو، پارامترهای فرم و/یا بارهای پیام از یک پیام
  • مقدار ویژگی‌های موجود را در یک پیام تنظیم کنید

با استفاده از Assign Message، معمولاً ویژگی‌های درخواست یا پاسخ را اضافه، تغییر یا حذف می‌کنید. با این حال، می‌توانید از Assign Message برای ایجاد یک پیام درخواست یا پاسخ سفارشی و ارسال آن به یک هدف جایگزین، همانطور که در Create custom request messages توضیح داده شده است، نیز استفاده کنید.

بازنویسی پیچیده با کد سفارشی

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

با کد رویه ای، شما می توانید:

  • مقادیر پیچیده بدنه، مانند مقادیر درخواست و پاسخ را ایجاد یا دستکاری کنید.
  • بازنویسی URLها، مثلاً برای پوشاندن URL نقطه پایانی هدف.

Apigee Edge شامل یک سیاست جداگانه برای زبان‌های پشتیبانی‌شده است: سیاست جاوا اسکریپت ، سیاست فراخوانی جاوا و سیاست اسکریپت پایتون .

مدیریت خطا

Apigee شما را قادر می‌سازد تا با استفاده از سیاستی از نوع Raise Fault، مدیریت خطای سفارشی را انجام دهید. سیاست Raise Fault که نوعی از سیاست Assign Message است، به شما امکان می‌دهد در پاسخ به یک وضعیت خطا، یک پاسخ خطای سفارشی ایجاد کنید.

جریان‌های مشترک

جریان‌های مشترک می‌توانند برای اعمال استانداردسازی پیام‌های خطا مورد استفاده قرار گیرند. به عنوان مثال، همان سیاست‌های پیکربندی شده‌ای که یک کد خطای HTTP خاص را از backend تشخیص می‌دهند، می‌توانند برای بازنویسی پاسخ خطا به منظور بازگرداندن یک پیام خطای عمومی مورد استفاده قرار گیرند.

API4:2019 کمبود منابع و محدودیت سرعت

شرح تهدید

با عدم اجرای سیاست‌های محدودکننده نرخ، مهاجمان می‌توانند با حملات انکار سرویس، بک‌اند را تحت الشعاع قرار دهند.

این تهدید را می‌توان به راحتی با استفاده از ویژگی‌های Apigee زیر برطرف کرد:

  • سیاست‌های سهمیه‌بندی و Spike Arrest به عنوان کنترل‌های پیشگیرانه برای اعمال محدودیت ترافیک بر درخواست‌های ورودی API
  • Apigee Sense برای شناسایی و پاسخ پویا به حملات ربات محور
  • نظارت و هشدار پیشرفته API به عنوان کنترل‌های کارآگاهی برای هشدار به حملات DDoS در حال انجام

محدود کردن نرخ با سیاست‌های سهمیه‌بندی و دستگیری ناگهانی

Apigee دو سیاست برای محدود کردن نرخ ارائه می‌دهد:

  • Spike arrest یک سیاست کلی، تعریف شده در سطح پروکسی API، برای محدود کردن نرخ تعداد کلی درخواست‌های ورودی به backend ارائه می‌دهد.
  • سهمیه‌ها یک ابزار سیاست‌گذاری جزئی برای اجرای سیاست‌های سهمیه‌بندی، چه در سطح پروکسی API و چه در سطح محصول API، ارائه می‌دهند.

دستگیری اسپایک

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

سهمیه‌ها

سیاست سهمیه‌بندی، پیکربندی تعداد پیام‌های درخواستی را که یک پروکسی API در یک دوره زمانی، مانند دقیقه، ساعت، روز، هفته یا ماه، مجاز می‌داند، فعال می‌کند. می‌توانید سهمیه را برای همه برنامه‌هایی که به پروکسی API دسترسی دارند، یکسان تنظیم کنید، یا می‌توانید سهمیه را بر اساس موارد زیر تنظیم کنید:

  • محصولی که حاوی پروکسی API است
  • برنامه‌ای که API را درخواست می‌کند
  • توسعه دهنده برنامه
  • بسیاری از معیارهای دیگر

این سیاست نسبت به Spike arrest جزئی‌تر است و معمولاً باید همزمان با آن استفاده شود.

تشخیص ربات با Apigee Sense

با Apigee Sense ، می‌توانید بر اساس آن دسته از کلاینت‌ها یا مکان‌هایی که رفتار مخرب یا مشکوکی از خود نشان می‌دهند، اقداماتی را برای مجاز، مسدود یا علامت‌گذاری صریح درخواست‌های کلاینت‌های خاص، محدوده‌های IP یا سازمان‌های Autonomous System انجام دهید. Apigee Edge این اقدامات را قبل از پردازش درخواست‌ها توسط پروکسی‌های API شما، روی آنها اعمال می‌کند. به عنوان مثال، می‌توان یک محدوده IP یا کلاینت خاص را که رفتار "brute guesser" از خود نشان می‌دهد، شناسایی، مسدود یا علامت‌گذاری کرد.

تشخیص تهدید با نظارت پیشرفته عملیات API

از هشدار ترافیک برای ارسال اعلان در زمانی که ترافیک یک محیط، پروکسی یا منطقه در یک بازه زمانی مشخص، درصد مشخصی تغییر می‌کند، استفاده کنید. این ویژگی می‌تواند به صورت پویا در زمانی که ترافیک به طور قابل توجهی از توان عملیاتی مورد انتظار شما منحرف می‌شود، مانند موردی که در طول حمله DDoS رخ می‌دهد، هشدار ایجاد کند. این هشدارها را می‌توان به راحتی به یک راهکار ثبت و نظارت شخص ثالث ارسال کرد.

API5:2019 مجوز سطح عملکرد خراب

شرح تهدید

این تهدید، گونه‌ی جدیدی از API1 است و همچنین یک آسیب‌پذیری مجوزدهی محسوب می‌شود. با این تهدید، یک مهاجم می‌تواند با ارسال درخواست به توابعی که دسترسی به آنها غیرمجاز است، اقداماتی را انجام دهد. به عنوان مثال، یک مهاجم ممکن است بتواند داده‌هایی را که فقط در صورتی مجاز به خواندن آنها است که یک نقطه پایانی API، فعل درخواست HTTP را اعتبارسنجی نکند، با جایگزینی GET با PUT یا DELETE، تغییر دهد یا حذف کند. یا با عدم پیاده‌سازی کنترل دسترسی به اندازه کافی محدودکننده در مسیر URI منبع API، یک نقطه پایانی API ممکن است به مهاجم اجازه دهد داده‌های کاربر دیگری را صرفاً با تغییر مسیر در یک درخواست، مشاهده کند.

این نوع تهدید، ارزش استفاده از Apigee را به عنوان یک لایه واسطه و انتزاع برجسته می‌کند، زیرا بسیاری از سیستم‌های backend - که برای دسترسی عمومی طراحی نشده‌اند - ممکن است به طور پیش‌فرض یک نقطه پایانی واحد برای اجرای چندین تابع منطق کسب‌وکار، از جمله حتی عملکردهای مدیریتی پرخطر، ارائه دهند.

عناصر مفهومی برای کاهش احتمال این تهدید معمولاً به موارد زیر تقسیم می‌شوند:

  • چه چیزی محافظت می‌شود؟ در مورد استراتژی محصول API خود فکر کنید و هنگام استفاده از بهترین شیوه‌های RESTful برای طراحی مسیرها و منابعی که توسط پروکسی‌های API Apigee، محصولات و ویژگی‌های برنامه‌ها در معرض دید قرار می‌گیرند، تقسیم‌بندی منطقی عملکرد را پیاده‌سازی کنید.
  • چه کسی به منابع API شما دسترسی دارد؟ شخصیت‌های سطح بالا را تعریف کنید و با استفاده از برخی از ویژگی‌های احراز هویت و مجوز Apigee که در API1 و API2 شرح داده شده است، مجوزهای دسترسی پیش‌فرض «حداقل امتیاز» را پیاده‌سازی کنید.
  • سیاست‌های دسترسی شما چگونه اجرا می‌شوند؟ از جریان‌های شرطی و خطاها برای اعتبارسنجی مسیر URL و فعل همه درخواست‌های API استفاده کنید.

شکل: این نمودار نشان می‌دهد که چگونه مجوزدهی در سطح تابع در Apigee با استفاده از محدوده‌های ارائه شده در یک توکن دسترسی به عنوان مجوزها، اعمال می‌شود.

تقسیم‌بندی منطقی با پروکسی‌های API، محصولات و برنامه‌ها

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

با این حال، برای پیاده‌سازی مجوزدهی و تقسیم‌بندی عملکردی مؤثر، تعریف یک استراتژی محصول API بسیار مهم است. بخشی از این فرآیند ضروری و مداوم، تعریف «چه کسی» و «چه چیزی» محصولات API شما است که با نگاه به منابع API شما از دیدگاه مشتری و توسعه‌دهنده، و سپس تعریف دقیق انواع درخواست‌های مجاز تا سطح منبع مسیر و فعل HTTP انجام می‌شود.

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

کنترل دسترسی در سطح تابع با دامنه‌های OAuth و ادعاهای JWT

در حالی که رویکردهای مجوزدهی که در بالا برای API1:2019 در مورد مجوزدهی اشیاء شکسته در نظر گرفته شد، به کنترل دسترسی دقیق در سطح شیء می‌پردازند، به همان اندازه مهم است که به کنترل دسترسی دقیق در سطح تابع نیز بپردازند. آیا کاربر درخواست‌کننده اصلاً مجاز به درخواست این مسیر URL است؟ این نوع سیاست اغلب برای هر کاربر (مشتری، کارمند، مدیر، توسعه‌دهنده داخلی یا شخص ثالث) تعریف می‌شود.

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

درخواست اعتبارسنجی با جریان‌های شرطی

در سطح پایه، یک فراخوانی REST API شامل موارد زیر است:

  • یک نقطه پایانی
  • یک منبع
  • فعل عملی
  • هر تعداد ویژگی درخواست اضافی، مانند پارامترهای پرس و جو

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

وقتی منطق کسب‌وکار یک محصول API را به روشنی درک و تعریف کردید، اینکه چه عملکردهایی توسط APIهای شما مجاز هستند، گام بعدی محدود کردن هرگونه درخواستی است که خارج از این موارد از طریق ویژگی‌های محصول Apigee قرار می‌گیرد:

  • منطق شرطی و سیاست‌های Raise Fault برای محدود کردن مسیرها یا افعال منابع در هر مرحله از پیکربندی جریان پروکسی
  • سیاست‌های محافظت در برابر تهدیدات JSON و XML برای محافظت در برابر حملات مبتنی بر محتوا با استفاده از درخواست‌های ناقص JSON یا XML

API6:2019 انتساب انبوه

شرح تهدید

داده‌های فیلتر نشده‌ای که از طریق APIها به برنامه‌های کلاینت ارائه می‌شوند، به مهاجمان اجازه می‌دهند تا ویژگی‌های اشیاء را از طریق درخواست‌ها حدس بزنند، یا از قراردادهای نامگذاری نقطه پایانی برای سرنخ‌هایی در مورد محل انجام تغییرات غیرمجاز یا دسترسی به ویژگی‌های اشیاء داده ذخیره شده در backend استفاده کنند.

این تهدید زمانی ایجاد می‌شود که داده‌های فیلتر نشده (معمولاً در قالب JSON یا XML) به یک کلاینت ارسال می‌شوند و به مهاجم اجازه می‌دهند جزئیات پیاده‌سازی اساسی سیستم‌های backend شما و همچنین نام ویژگی‌های عناصر داده محرمانه را حدس بزند. نتیجه این نوع حمله می‌تواند به مهاجم امکان خواندن یا دستکاری داده‌های نامناسب را بدهد، یا در بدترین حالت، می‌تواند آسیب‌پذیری‌های اجرای کد از راه دور را فعال کند.

دو جنبه معمولاً در مجاز دانستن این نوع تهدید دخیل هستند:

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

از دیدگاه محصولات Apigee، ما چندین ویژگی مفید برای تضمین پیاده‌سازی قوی فیلترینگ داده‌ها در APIهای شما ارائه می‌دهیم.

سیاست فیلترینگ مشخصات OpenAPI

سیاست OASValidation ( اعتبارسنجی مشخصات OpenAPI ) شما را قادر می‌سازد تا یک درخواست یا پیام پاسخ ورودی را در برابر مشخصات OpenAPI 3.0 (JSON یا YAML) اعتبارسنجی کنید. این سیاست به شما امکان می‌دهد:

  1. با ایجاد مشخصات OpenAPI (OAS) API خود را طراحی کنید
  2. منطق میانجیگری، امنیت و ذخیره‌سازی لازم را برای نمایش ایمن یک محصول API از backend خود با Apigee پیاده‌سازی کنید.
  3. درخواست‌های ورودی را با طرح داده تعریف‌شده در مشخصات OAS خود، شامل مسیر پایه ، فعل ، سیاست پیام درخواست و پارامترها، اعتبارسنجی کنید.

سیاست اعتبارسنجی پیام SOAP

سیاست اعتبارسنجی پیام SOAP به شما امکان می‌دهد درخواست‌های مبتنی بر XML را با اعتبارسنجی یک پیام XML در برابر یک طرحواره XSD یا اعتبارسنجی یک پیام SOAP در برابر تعریف WSDL اعتبارسنجی کنید. علاوه بر این، می‌توانید از سیاست اعتبارسنجی پیام برای تأیید صحت ساختار یک پیام JSON یا XML استفاده کنید، که شامل تأیید موارد زیر در یک پیام XML یا JSON است:

  • یک عنصر ریشه واحد وجود دارد
  • هیچ کاراکتر غیرمجازی در محتوا وجود ندارد
  • اشیاء و برچسب‌ها به درستی تودرتو شده‌اند
  • تگ‌های شروع و پایان با هم مطابقت دارند

پیکربندی نادرست امنیتی API7:2019

شرح تهدید

پیکربندی نادرست امنیتی معمولاً نتیجه پیکربندی‌های پیش‌فرض ناامن، پیکربندی‌های ناقص یا موردی، ذخیره‌سازی ابری باز، هدرهای HTTP پیکربندی نادرست، روش‌های HTTP غیرضروری، اشتراک‌گذاری منابع Cross-Origin (CORS) سهل‌انگارانه و پیام‌های خطای طولانی حاوی اطلاعات حساس است. مهاجمان اغلب سعی می‌کنند نقص‌های وصله نشده، نقاط پایانی مشترک یا فایل‌ها و دایرکتوری‌های محافظت نشده را پیدا کنند تا به سیستمی که می‌خواهند حمله کنند، دسترسی غیرمجاز یا دانش کسب کنند. پیکربندی نادرست امنیتی نه تنها می‌تواند داده‌های حساس کاربر را افشا کند، بلکه جزئیات سیستم را نیز که ممکن است منجر به در معرض خطر قرار گرفتن کامل سرور شود، افشا می‌کند. علاوه بر این، برخی موارد استفاده دیگر برای آسیب‌پذیری‌های پیکربندی نادرست امنیتی ممکن است شامل موارد زیر باشد:

  • پیکربندی نادرست TLS
  • پیام‌های خطا با ردیابی پشته
  • سیستم‌های پچ نشده
  • پنل‌های مدیریت سرور یا فضای ذخیره‌سازی در معرض دید

گام‌های مختلفی وجود دارد که سازمان‌ها می‌توانند برای رسیدگی و کاهش چالش‌های مربوط به پیکربندی‌های نادرست امنیتی بردارند که شامل موارد زیر است:

  1. ایجاد و استانداردسازی فرآیندهای مقاوم‌سازی و وصله‌گذاری
  2. توسعه‌ی مدیریت پیرامون اکوسیستم API
  3. محدود کردن دسترسی مدیریتی و فعال کردن حسابرسی و هشدار

جریان‌های مشترک و قلاب‌های جریان

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

نظارت بر API

Apigee یک پلتفرم جامع نظارت بر API ارائه می‌دهد. نظارت بر API سازمان‌ها را قادر می‌سازد تا به صورت پیشگیرانه مشکلات ترافیک و عملکرد API را شناسایی کنند. Apigee API Monitoring در کنار Apigee Edge for Public Cloud بینش‌های زمینه‌ای بلادرنگ از عملکرد API ارائه می‌دهد، به تشخیص سریع مشکلات کمک می‌کند و اقدامات اصلاحی را برای تداوم کسب‌وکار تسهیل می‌کند.

شکل: Apigee API Monitoring طیف گسترده‌ای از ابزارها را برای نظارت، بررسی و اقدام در مورد مشکلات ارائه می‌دهد. این ابزار از بهترین ویژگی‌های هوش مصنوعی Google Cloud Platform بهره می‌برد.

حس آپیجی

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

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

  • رفتار خودکار که با رفتار انسانی ترکیب می‌شود
  • تلاش‌های مداوم از همان IP
  • نرخ خطاهای غیرمعمول
  • درخواست‌های مشکوک مشتریان
  • خزش داده‌ها
  • برداشت کلید
  • انفجار فعالیت
  • الگوهای جغرافیایی

تزریق API8:2019

شرح تهدید

Untrusted injection of data, such as SQL, NoSQL, XML Parsers, ORM, LDAP, OS Commands, and JavaScript, into API requests can result in the execution of unintended commands or unauthorized data access. Attackers will feed the API with malicious data through whatever injection vectors are available such as direct input, parameters, integrated services, and so on, expecting it to be sent to an interpreter. Attackers can discover these flaws easily when reviewing the source code using vulnerability scanners and fuzzers. A successful injection can lead to information disclosure impacting the confidentiality and data loss or in some cases it may also lead to DoS.

Best practices to mitigate injection errors/attacks include strictly defining the input data such as schemas, types, string patterns, performing input validation, limit checks and enforcing them at runtime. The Apigee platform allows validating the incoming data using filters to only allow valid values for each input parameter.

Apigee Edge, acting as a server for the incoming API requests, checks to ensure that the payload structure falls within an acceptable range, also known as a limit check. You can configure an API proxy so that the input validation routine transforms the input to remove risky character sequences and replace them with safe values.

Regular Expression Protection policy

The RegularExpressionProtection policy extracts information from a message (for example, URI Path, Query Param, Header, Form Param, Variable, XML Payload, or JSON Payload) and evaluates that content against predefined regular expressions. If any specified regular expressions evaluate to true, the message is considered a threat and is rejected. A regular expression, or regex for short, is a set of strings that specify a pattern in a string. Regular expressions enable content to be programmatically evaluated for patterns. Regular expressions can be used, for example, to evaluate an email address to ensure that it is properly structured.

The most common usage of RegularExpressionProtection is the evaluation of JSON and XML payloads for malicious content.

No regular expression can eliminate all content-based attacks, and multiple mechanisms should be combined to enable defense-in-depth. This section describes some recommended patterns for preventing access to content.

There are several other approaches to validating input available with the Apigee platform:

Validate Content Types

Content type refers to content of a file which is transferred via HTTP and classified according to a two-part structure. Apigee recommends to validate the content types for the Request and Response using conditional logic as explained below.

API9:2019 Improper assets management

Threat Description

Insufficient environment management and environment segregation allows attackers to access under-secured API endpoints. Lack of governance safeguards also cause unnecessary exposure of deprecated resources.

This threat can be addressed by leveraging Apigee's matured capabilities to manage the full API life cycle, allowing you to create a comprehensive governance model that enables collaboration among teams, and at the same time, apply separation of responsibilities between security stakeholders and API developers. Boundaries and controls can be configured and maintained using:

Organizations, Environments, and Revisions : Virtual and physical guardrails that guarantee isolation and a secured promotion process through runtime contexts.

Role Based Access Control : Only the necessary people on your API teams will have permissions to manage configuration changes and also the promotion process.

Audience Management for API Documentation : Once an API has been published in the developer portal, you can limit the visibility of documentation by managing target audiences.

Flow Hooks : You can enforce global policies and patterns that can be managed as privileged guardrails that cannot be modified by API developers.

سازمان‌ها و محیط‌ها

Configuration artifacts, users, and features in Apigee can be scoped to specific organizations and/or environments. This means that the platform has pre-built guardrails that can be placed around APIs and their supporting configuration.

Organizations : An organization is the top-level tenant in Apigee. It enables you to have full segregation for traffic, configuration, and users. As a governance best practice, you should consider having separate production and non-production organizations. This practice effectively avoids mixing production data, users, and traffic with lower environments.

Environments : APIs in Apigee can be promoted through multiple deployment states; each state is linked to an execution context. The environment context is not carried along during the promotion process, therefore avoiding exposing sensitive configuration to unprivileged users.

Revisions : Revisions allow APIs and individual features to be promoted seamlessly through environments.

کنترل دسترسی مبتنی بر نقش

In order to mitigate API9 it is imperative to have clear definitions of and separation of duties between security stakeholders and API Developers. As previously stated in this document, Apigee has flexible Role Based Access Control capabilities that allow you to assign permissions to custom roles. For this specific threat, roles can be scoped to have limited privileges per organization, environments, or more granular configuration permissions. As a preferred practice, consider limiting privileges to change the deployment state of APIs through environments and also to make sure developers are unable to access or modify global security libraries (Flow Hooks). These limited roles will prevent unsolicited changes to global security policies that have broad coverage on both legacy and current published endpoints.

Audience Management for API Documentation

A Developer Portal is a pivotal component for the success of your API Strategy; it allows you to keep a comprehensive inventory of all documentation related to your APIs including hosts/endpoints, resources, operations, payload schemas, and more. In Apigee you can group your APIs using API Product constructs. API Products are defined by bundles of resources and operations that fall within the same business and security context (eg service plan, business domain, category, company hierarchy, etc.).

With Apigee's Integrated Developer Portal you can publish API Products and restrict the visibility of published content by managing target audiences. This capability complies with a content segmentation strategy that aligns with business and security requirements.

Flow Hooks

The promotion and release processes for APIs must always include security compliance and certification processes. To be effective, API teams using the appropriate tools should be able to create guardrails that guarantee the separation of responsibilities and while maintaining agile release cycles.

Apigee allows you to elevate security governance duties by enforcing global policies through Flow Hooks . These global policies can be managed as privileged guardrails that cannot be modified by API developers, therefore guaranteeing separation of responsibilities and also promoting agility by applying default security and, by extension, providing security compliance for all APIs deployed in a given execution environment.

Figure: Privileged guardrails can be configured in Apigee through Flow Hooks and Shared Flows. Security stakeholders are responsible for maintaining security related global policies. These features guarantee separation of responsibilities and promote agile development life cycles.

API10:2019 Insufficient logging & monitoring

Threat Description

Insufficient logging, monitoring, and alerts allows attacks in progress to go undetected and therefore a strategy should be required to obtain insights over critical events that have impact over your business.

Event and logging management strategies for APIs should consider the following best practices:

  • Logs Management Policy : Document and enforce rules to standardize and control logs verbosity, log levels, log integrity, centralized repository, and more
  • Event Management Policy : Guarantee that every event should be traceable to its source. Also, events should be able to be categorized by criticality and business impact
  • Reports and Audits : Security and operations stakeholders should be able to access and react to logs and events in real time. Additionally, reinforcement cycles can be performed by stakeholders to adjust detection patterns based on historical data

Apigee provides the necessary tools to create a comprehensive event and logging management strategy. These tools include:

Message Logging Policy : Create log streams based on traffic data or metadata from your API traffic. You have the flexibility to decide stream verbosity by leveraging conditional logic and message templates .

Google's Cloud Operation Suite : Leverage the out of box integration into highly scalable monitoring and logging tools from Google.

Service Callout Policy : Adds support for logs streams that require HTTP endpoints to send events.

Analytics : Access and analyze historical traffic metadata through out of box and/or customized reports. Create and manage alerts based on trends and understand traffic anomalies.

API Monitoring : As previously described, this tool provides alerting capabilities that can be triggered based on critical events. Traffic logs can be further analyzed and acted upon.