درحال مشاهده اسناد Apigee Edge هستید.
به
اسناد Apigee X بروید. اطلاعات
نمای کلی
بوم‌سازگان‌های API با حملات مختلفی ازسوی مشتریان خارجی و داخلی مواجه می‌شوند. ارائه و استفاده از میاناهای برنامه‌سازی کاربردی فرصت‌های فوق‌العاده‌ای برای ارائه‌دهندگان خدمات ایجاد می‌کند، اما مخاطرات امنیتی نیز به‌همراه دارد. توسعه‌دهندگان باید از این چالش‌ها آگاه باشند و هنگام ایجاد و استفاده از «میاناهای برنامه‌سازی کاربردی» به آن‌ها رسیدگی کنند.
OWASP یک انجمن باز است که به سازمان‌ها کمک می‌کند برنامه‌ها و میاناهای برنامه‌سازی کاربردی مطمئن را توسعه دهند، خریداری کنند، و نگهداری کنند. ازطریق پروژه امنیت OWASP API، OWASP مهم‌ترین خطرات امنیتی را برای برنامه‌های وب و REST API منتشر می‌کند و توصیه‌هایی برای رسیدگی به این خطرات ارائه می‌دهد.
با Apigee، لایه پراکسی API می‌تواند درخواست‌های API بدشکل را از کارخواه قبل‌از اینکه درخواست‌ها در سیستم‌های پشتیبان پردازش شوند شناسایی، مسدود، و گزارش کند، و ازاین‌طریق خطر را کاهش دهد و از خدمات شما محافظت کند. درخواست‌های نامعتبر می‌تواند شامل هر مؤلفه‌ای باشد که پروتکل سطح برنامه HTTP را تشکیل می‌دهد:
- نشانی وب
- سرایندها
- مسیر
- پایه‌بار
درخواست‌های API غیرعادی می‌تواند از کارخواه‌های شناخته‌شده یا ناشناخته توسعه‌یافته توسط توسعه‌دهندگان خارجی، توسعه‌دهندگان داخلی، یا روبات‌های مخرب باشد. این نوع درخواست‌ها بخش عمده‌ای از تهدیدات OWASP را تشکیل می‌دهند، اما اجزای دیگری در لایه زیرین پراکسی API وجود دارد که می‌تواند خطرات را کاهش دهد، مانند پوشش داده‌ها، ثبت گزارش، مدیریت، و غیره.
پلاتفرم مدیریت هوشمند میانای برنامه‌سازی کاربردی Apigee به شما امکان می‌دهد تا آسیب‌پذیری‌های امنیتی میانای برنامه‌سازی کاربردی OWASP را به‌طور یکپارچه برطرف کنید، زیرا رویکردی مصرف‌محور برای طراحی میاناهای برنامه‌سازی کاربردی خود و اتصال آن‌ها به سیستم‌های پشتیبان خود اتخاذ می‌کنید. در زیر فهرستی از خط‌مشی‌ها/پیکربندی‌هایی که Apigee برای تهدیدات برتر OWASP REST توصیه می‌کند آمده است.
راه‌حل‌های Apigee برای ۱۰ مورد برتر OWASP در سال ۲۰۱۷
وقتی صحبت از ساختن و ایمن کردن برنامه‌های وب می‌شود، نگرانی‌های امنیتی زیادی وجود دارد. OWASP فهرست ۱۰ تهدید امنیتی برتر OWASP در سال ۲۰۱۷ را برای برنامه‌های وب منتشر کرد. برنامه‌های وب بخش‌های زیادی دارند، اما اکثر برنامه‌های وب مدرن به‌شدت به REST APIs متکی هستند. Apigee برای رسیدگی به همه نیازهای امنیتی برنامه وب طراحی نشده است، اما می‌تواند نقش مهمی در ایمن‌سازی «میاناهای برنامه‌سازی کاربردی REST» ایفا کند. در زیر، تهدیدات امنیتی برتر OWASP با توضیحاتی درباره نحوه استفاده از Apigee برای کمک به رفع این تهدیدات آمده است.
A1:2017 - تزریق
برای محافظت دربرابر تزریق داده‌های غیرقابل‌اعتماد مثل SQL، NoSQL، LDAP، و JavaScript که می‌تواند منجر به اجرای فرمان‌های ناخواسته یا دسترسی غیرمجاز به داده‌ها شود، Apigee چندین خط‌مشی درستی‌سنجی ورودی ارائه می‌دهد تا تأیید کند مقادیر ارائه‌شده توسط مشتری با انتظار مطابقت دارد و سپس اجازه پردازش بیشتر را می‌دهد. Apigee Edge که به‌عنوان سرور برای درخواست‌های ورودی API عمل می‌کند، بررسی می‌کند که ساختار پایه‌بار در محدوده قابل‌قبول باشد، که به آن بررسی محدودیت نیز گفته می‌شود. می‌توانید کارگزار نیابتی API را پیکربندی کنید تا روال اعتبارسنجی ورودی، ورودی را تبدیل کند تا دنباله‌های نویسه خطرناک را بردارد و آن‌ها را با مقادیر ایمن جایگزین کند.
چندین روش برای اعتبارسنجی ورودی با پلاتفرم Apigee وجود دارد:
- JSONThreatProtection پایه‌بار JSON را ازنظر وجود تهدید بررسی می‌کند.
- XMLThreatProtection بار XML را ازنظر وجود تهدید بررسی می‌کند.
- اعتبارسنجی پارامتر را می‌توان بااستفاده از JavaScript انجام داد.
- اعتبارسنجی سرایند را می‌توان بااستفاده از JavaScript انجام داد.
- «تزریق کد SQL» را می‌توان بااستفاده از خط‌مشی «محافظت از عبارت باقاعده» مدیریت کرد.
انواع محتوا را اعتبارسنجی کنید:
- درخواست - از منطق شرطی در جریان پراکسی برای بررسی «نوع محتوا» استفاده کنید. از خط‌مشی AssignMessage یا خط‌مشی RaiseFault برای برگرداندن پیام خطای سفارشی استفاده کنید.
- پاسخ - از منطق شرطی در جریان پراکسی برای تأیید «نوع محتوا» استفاده کنید. از خط‌مشی AssignMessage برای تنظیم سرصفحه Content-Type استفاده کنید، یا از خط‌مشی AssignMessage یا RaiseFault برای برگرداندن پیام خطای سفارشی استفاده کنید.
A2:2017 - اصالت‌سنجی و مدیریت جلسه خراب
مهاجمان می‌توانند با بهره‌گیری از نقص‌های پیاده‌سازی در برنامه‌ها، به گذرواژه‌ها، نشان‌های جلسه، و کلیدها دسترسی پیدا کنند و هویت کاربران دیگر را جعل کنند. این بیشتر مشکل پیاده‌سازی است و نه مشکل محصول. Apigee خط‌مشی‌های «تأیید کلید API»، OAuth، و «توکن وب JSON» (JWT) را ارائه می‌دهد که به محافظت دربرابر این آسیب‌پذیری کمک می‌کند.
درستی‌سنجی کلید میانای برنامه‌سازی کاربردی
اعتبارسنجی کلید API ساده‌ترین شکل امنیت مبتنی بر برنامه است که می‌تواند برای یک API پیکربندی شود. برنامه مشتری به‌سادگی کلید API را با درخواست خود ارائه می‌دهد، سپس Apigee Edge ازطریق خط‌مشی پیوست‌شده به پراکسی API بررسی می‌کند که کلید API در وضعیت تأییدشده برای منبع درخواستی باشد.
Apigee از تولید و اعتبارسنجی «کلیدهای میانای برنامه‌سازی کاربردی» پشتیبانی می‌کند. وقتی برنامه توسعه‌دهنده‌ای ایجاد و تأیید می‌شود که به یک یا چند محصول API پیوند داده شده است، Apigee کلید و رمز API تولید می‌کند.
عبارت «کلیدهای API» گاهی اوقات می‌تواند معانی مختلفی داشته باشد. در Apigee، وقتی رابطه برنامه و محصول شکل می‌گیرد، Apigee شناسه کارخواه و رمز کارخواه تولید می‌کند. برخی به هر دو شناسه و رمز به‌عنوان کلید API اشاره می‌کنند. برخی‌از افراد فقط به شناسه کارخواه به‌عنوان کلید API اشاره می‌کنند. در «میانای کاربر Edge»، «کلید مصرف‌کننده» و «رمز مصرف‌کننده» را خواهید دید.
در خط‌مشی VerifyAPIKey، فقط شناسه مشتری یا «کلید مصرف‌کننده» درستی‌سنجی می‌شود. توسعه‌دهندگان وقتی کلید مصرف‌کننده دریافت می‌کنند که برنامه خود را در Apigee ثبت کنند و برنامه را با محصول API مرتبط کنند. توسعه‌دهندگان کلید مصرف‌کننده را در تماس‌هایی که برنامه با پراکسی‌های میانای برنامه‌سازی کاربردی که در محصول میانای برنامه‌سازی کاربردی دسته‌بندی شده‌اند برقرار می‌کند، اضافه می‌کنند.
Apigee همچنین از امکان وارد کردن کلیدهای میانای برنامه‌سازی کاربردی موجود از منابع خارجی پشتیبانی می‌کند.
برای انواع اعطای OAuth، هم از شناسه کارخواه و هم از رمز استفاده می‌شود.
OAuth 2.0
چارچوب مجوز OAuth 2.0 به برنامه طرف سوم امکان می‌دهد به سرویس HTTP دسترسی محدود داشته باشد، یا ازطرف مالک منبع با هماهنگ کردن تعامل تأیید بین مالک منبع و سرویس HTTP، یا با اجازه دادن به برنامه طرف سوم برای دسترسی ازطرف خود.
خط‌مشی‌های OAuth 2.0 در Apigee به شما امکان می‌دهد چهار نوع اعطای OAuth 2.0 را پیاده‌سازی و سفارشی‌سازی کنید. اجرای نمودار دسترسی OAuth را می‌توان بااستفاده از خط‌مشی OAuthv2 انجام داد. مصرف‌کننده باید ثبت‌نام کرده باشد و برنامه تأییدشده‌ای داشته باشد که به او دسترسی به API را اعطا کرده باشد. در مقابل، شناسه کارخواه API و رمز کارخواه دریافت خواهند کرد. مصرف‌کننده باید یکی از OAuth grants را برای اصالت‌سنجی شدن طی کند، که به او یک کد دسترسی مبهم می‌دهد. از این کد می‌توان برای کنترل دسترسی به API استفاده کرد.
JWT
«نشان‌های وب JSON» یا JWT معمولاً برای هم‌رسانی ادعاها یا اظهارات بین برنامه‌های متصل استفاده می‌شوند. Apigee بااستفاده از سه خط‌مشی از JWT پشتیبانی می‌کند.
- تولید نشان‌های JWT (از امضای HS256 و RS256 پشتیبانی می‌کند)
- درستی‌سنجی داده‌واحد JWT
- رمزگشایی داده‌واحد JWT بدون درستی‌سنجی
A3:2017 - Sensitive Data Exposure (نمایش داده‌های حساس)
مهاجمان داده‌های حساس مثل جزئیات کارت اعتباری، شماره‌های تأمین اجتماعی، اعتبارنامه‌های ورود به سیستم، اطلاعات شناساننده شخصی (PII)، و شناسه‌های مالیاتی را هدف قرار می‌دهند تا مرتکب سرقت هویت، سرقت پول، کلاهبرداری، و دیگر جرایم شوند. برنامه‌های وب باید رمزگذاری را هم در حالت سکون و هم در حالت انتقال و همچنین استراتژی‌های دیگر برای اطمینان از محافظت از داده‌های حساس پیاده‌سازی کنند.
TLS (امنیت لایه انتقال که پیش‌از آن SSL بوده است) فناوری امنیتی استاندارد برای ایجاد پیوند رمزگذاری‌شده بین کارساز وب و کارخواه وب، مثل مرورگر یا برنامه است. Apigee از TLS یک‌طرفه و دوطرفه پشتیبانی می‌کند.
«امنیت لایه انتقال» شمالی (کاربر به «میانای برنامه‌سازی کاربردی» متصل می‌شود که به‌عنوان سرور عمل می‌کند) ازطریق استفاده از پیکربندی میزبان مجازی پشتیبانی می‌شود. میزبان مجازی می‌تواند برای «امنیت لایه انتقال» یک‌طرفه یا دوطرفه پیکربندی شود.
«امنیت لایه انتقال» جنوبی (apigee به‌عنوان کارخواهی که به سرویس زیرینه متصل می‌شود) ازطریق استفاده از پیکربندی سرور هدف پشتیبانی می‌شود. «سرور هدف» می‌تواند برای «امنیت لایه انتقال» یک‌طرفه یا دوطرفه پیکربندی شود.
Apigee از بسیاری از گزینه‌های پیکربندی «امنیت لایه انتقال» پشتیبانی می‌کند.
اجرای امنیت لایه انتقال دوطرفه تضمین می‌کند که کارخواه از گواهینامه‌ای استفاده می‌کند که قبلاً در Apigee ثبت شده است. OWASP همچنین روال‌های مطلوب TLS را ارائه می‌دهد.
در Apigee hybrid، «امنیت لایه انتقال» در ورودی ازطریق نام مستعار میزبان دردسترس است که مفهومی مشابه میزبان مجازی است.
دستورالعمل‌های زیر برای ایمن‌سازی داده‌های حساس است:
- از پلاتفرمی استفاده کنید که از «امنیت لایه انتقال» یک‌طرفه و دوطرفه پشتیبانی می‌کند، که در سطح پروتکل محافظت می‌کند.
- از خط‌مشی‌هایی مثل خط‌مشی AssignMessage و خط‌مشی JavaScript برای برداشتن داده‌های حساس قبل‌از اینکه به مشتری برگردانده شود استفاده کنید.
- از تکنیک‌های استاندارد OAuth استفاده کنید و برای بهبود سطح اصالت‌سنجی هر درخواست، HMAC، درهم‌سازی، وضعیت، nonce، PKCE، یا تکنیک‌های دیگر را اضافه کنید.
- از تنظیمات پوشاندن داده برای پوشاندن داده‌های حساس در ابزار «ردیابی Edge» استفاده کنید.
- مراقب باشید که هیچ‌گونه داده حساسی را در حافظه نهان ذخیره نکنید (یا داده‌های حساس ذخیره‌شده در حافظه نهان را رمزگذاری کنید). در Edge، می‌توانید داده‌های حساس در حالت استراحت را در نقشه‌های مقدار کلید رمزگذاری کنید.
A4:2017 - نهادهای خارجی XML
سیستم‌ها یا برنامه‌هایی که XML را پردازش می‌کنند باید «ارجاع‌های نهاد خارجی» را در XML مدیریت کنند—ارجاع‌هایی به فایل‌ها یا داده‌هایی که درطول پردازش XML با داده‌های واقعی جایگزین می‌شوند. اگر برنامه‌ها یا پردازشگرهای XML قدیمی باشند یا به‌خوبی پیاده‌سازی نشده باشند، مهاجمان می‌توانند داده‌ها را هک کنند و از آن‌ها برای سرقت اطلاعات یا راه‌اندازی انواع مختلف حملات به سیستم، مانند منع سرویس، استفاده کنند.
خط‌مشی ExtractVariables در Apigee به شما امکان می‌دهد محتوای درخواست یا پاسخ را استخراج کنید و آن محتوا را به متغیری اختصاص دهید. می‌توانید هر بخشی از پیام را استخراج کنید، ازجمله سرایندها، مسیرهای نشانی وب، بار داده‌های JSON/XML، پارامترهای فرم، و پارامترهای پُرسمان. این خط‌مشی با اعمال الگوی نوشتاری بر محتوای پیام و، درصورت یافتن مطابقت، تنظیم متغیر با محتوای پیام مشخص‌شده کار می‌کند.
Apigee به‌عنوان بخشی از پلاتفرم خود، تجزیه‌کننده XML داخلی دارد که از XPath برای استخراج داده‌ها استفاده می‌کند. همچنین خط‌مشی XMLThreatProtection برای محافظت دربرابر پیام‌های مخرب XML دارد.
A5:2017 - کنترل دسترسی معیوب
پس‌از اینکه کاربران وارد سیستم شدند و به آن دسترسی پیدا کردند، باید کنترل‌های مجوز مناسبی درنظر گرفته شود تا کاربران فقط بتوانند آنچه را که مجاز هستند ببینند و انجام دهند. بدون کنترل‌های دسترسی قوی، مهاجمان می‌توانند داده‌های غیرمجاز و اغلب حساس را مشاهده کنند یا رفتار سیستم و داده‌ها را به‌طور مخرب دستکاری کنند.
Apigee از رویکردی لایه‌ای برای پیاده‌سازی کنترل‌های دسترسی استفاده می‌کند تا از ایجاد تغییرات غیرمجاز یا دسترسی به سیستم توسط عاملان بدخواه جلوگیری کند.
کنترل‌های دسترسی برای واسط کاربر Edge
- پیکربندی ورود به سیستم یکپارچه با ارائه‌دهنده هویت شرکتتان.
- کنترل دسترسی نقش‌مبنا (RBAC) را پیکربندی کنید تا فقط به کاربران اجازه دهید به عملکرد و پیکربندی موردنیازشان دسترسی داشته باشند.
- ویژگی «تیم‌ها» قابلیت بیشتری برای محدود کردن دسترسی به پراکسی‌ها، محصولات، و برنامه‌ها فراهم می‌کند.
- برای پنهان کردن داده‌های حساس از کاربران، پیکربندی پوشش داده را انجام دهید.
- ایجاد نقشه‌های مقدار کلید رمزگذاری‌شده برای ذخیره کردن جفت‌های کلید/مقدار حساس که در «میانای کاربری Edge» و در فراخوانی‌های میانای برنامه‌سازی کاربردی مدیریت به‌صورت پوشیده نشان داده می‌شوند.
کنترل‌های دسترسی برای «درگاه توسعه‌دهندگان Apigee»
- پیکربندی ورود به سیستم یکپارچه با ارائه‌دهنده هویت شرکتتان.
- کنترل دسترسی نقش‌مبنا (RBAC) را پیکربندی کنید تا فقط به کاربران اجازه دهید به عملکرد و پیکربندی موردنیازشان در درگاه‌های توسعه‌دهندگان مبتنی بر Drupal دسترسی داشته باشند.
- درگاه‌های توسعه‌دهنده را پیکربندی کنید تا محصولات میانای برنامه‌سازی کاربردی خاصی را براساس نقش کاربر نشان دهند.
- درگاه را پیکربندی کنید تا محتوا را براساس نقش کاربر نشان دهد یا پنهان کند.
کنترل‌های دسترسی برای دسترسی به Apigee runtime API
- دسترسی به میاناهای برنامه‌سازی کاربردی می‌تواند ازطریق کلیدهای میانای برنامه‌سازی کاربردی، کدهای OAuth، دامنه‌های OAuth، گواهینامه‌ها، و تکنیک‌های دیگر اعمال شود.
- ارائه‌دهنده API با تعریف یک محصول API پیکربندی می‌کند که کدام منابع دردسترس باشند. دسترسی یا به‌صورت دستی در واسط کاربری، ازطریق API مدیریت، یا ازطریق درگاه توسعه‌دهنده اعطا می‌شود. وقتی برنامه توسعه‌دهنده‌ای به محصول API دسترسی پیدا می‌کند، شناسه کارخواه و رمزی دریافت می‌کند که در فرایند اصالت‌سنجی استفاده می‌شود.
- Apigee می‌تواند با هر ارائه‌دهنده هویتی برای انجام OAuth ادغام شود.
- Apigee می‌تواند نشان‌های JWT یا روش‌های دیگری برای ارسال هویت کاربر به سرویس‌های هدف تولید کند. سرویس‌های هدف می‌توانند از آن هویت برای محدود کردن دسترسی به سرویس‌ها و داده‌ها درصورت نیاز استفاده کنند.
A6:2017-Security Misconfiguration
پیکربندی‌های نادرست امنیتی به‌راحتی نادیده گرفته می‌شوند، اغلب به این دلیل که سرپرستان و توسعه‌دهندگان به‌اشتباه تصور می‌کنند سیستم‌هایی که استفاده می‌کنند ذاتاً ایمن هستند. پیکربندی نادرست امنیتی می‌تواند به روش‌های مختلفی رخ دهد، مثلاً اعتماد به پیکربندی‌های پیش‌فرض یا انجام پیکربندی‌های جزئی که ممکن است ناامن باشند، اجازه دادن به پیام‌های خطا برای حاوی جزئیات حساس بودن، ذخیره کردن داده‌ها در فضای ابری بدون کنترل‌های امنیتی مناسب، پیکربندی نادرست سراینده‌های HTTP، و غیره. پلاتفرم Apigee سازوکارهای متعددی را برای کنترل، مدیریت، و نظارت بر پیکربندی‌های امنیتی، ازجمله جریان‌های مشترک قابل‌استفاده مجدد، ارائه می‌دهد.
جریان مشترک به توسعه‌دهندگان API اجازه می‌دهد خط‌مشی‌ها و منابع را در یک گروه قابل‌استفاده مجدد ترکیب کنند. جریان مشترک با ثبت کردن عملکرد قابل‌استفاده مجدد در یک مکان به شما کمک می‌کند از یکپارچگی اطمینان حاصل کنید، زمان توسعه را کوتاه کنید، و کد را راحت‌تر مدیریت کنید. می‌توانید یک جاری‌سازی هم‌رسانی‌شده را در داخل کارگزاران میانای برنامه‌سازی کاربردی فردی بگنجانید، یا می‌توانید یک گام فراتر بروید و جاری‌سازی‌های هم‌رسانی‌شده را در قلاب‌های جاری‌سازی قرار دهید تا منطق جاری‌سازی هم‌رسانی‌شده به‌طور خودکار برای هر کارگزار میانای برنامه‌سازی کاربردی که در همان محیط جاری‌سازی هم‌رسانی‌شده مستقر شده است اجرا شود.
انتشار محصولات Apigee از محافظت دربرابر کتابخانه‌های دارای آسیب‌پذیری اطمینان می‌دهد. اگر آسیب‌پذیری‌های جدیدی پیدا شود، ممکن است Apigee وصله‌های یا به‌روزرسانی‌های بیشتری منتشر کند. ابر عمومی Edge به‌طور خودکار وصله می‌شود. مشتریان Edge for Private Cloud (در محل) باید وصله‌های محصول را خودشان اعمال کنند.
A7:2017-Cross-Site Scripting (XSS)
«دستورگان بین‌سایتی» (XSS) به مهاجمان اجازه می‌دهد دستورگان‌هایی را در مرورگرهای وب کاربر اجرا کنند تا جلسه‌های کاربر را کنترل کنند، وب‌سایت‌ها را دستکاری کنند، یا به روش‌های دیگر به‌طور مخرب بر کاربران تأثیر بگذارند. مشکلات XSS لزوماً مربوط به API نیستند، اما Apigee خط‌مشی‌های محافظت دربرابر تهدید ارائه می‌دهد که می‌توان از آن‌ها برای محافظت دربرابر XSS در API استفاده کرد. بااستفاده از عبارت‌های باقاعده، چه با خط‌مشی «محافظت با عبارت باقاعده» و چه با خط‌مشی «جاوا اسکریپت»، مقادیر پارامتر و بار را برای جاوا اسکریپت و دیگر حمله‌های نوع تزریق بررسی کنید.
CORS، یکی از راه‌حل‌های معمولاً پیاده‌سازی‌شده برای خط‌مشی مبدأ یکسان که توسط همه مرورگرها اعمال می‌شود، می‌تواندبااستفاده از خط‌مشی AssignMessage پیاده‌سازی شود.
A8:2017 - Insecure Deserialization (سریال‌سازی غیرایمن)
مهاجمان می‌توانند از نقص‌های واسری‌سازی برای انواع مختلف حمله‌ها، مثل بازپخش، ارتقای امتیاز، و تزریق استفاده کنند. سریال‌سازی ناامن می‌تواند اجرای کد از راه دور را نیز فعال کند.
Apigee سریال‌سازی را توصیه نمی‌کند. بااین‌حال، خط‌مشی JSONThreatProtection و خط‌مشی RegularExpressionProtection می‌توانند به محافظت دربرابر بار داده‌های JSON مخرب کمک کنند. از خط‌مشی جاوا اسکریپت نیز می‌توان برای اسکن کردن داده‌بارها به‌منظور یافتن محتوای مخرب استفاده کرد. از حافظه نهان و خط‌مشی‌های دیگر می‌توان برای محافظت دربرابر حمله‌های بازپخش استفاده کرد. در سطح زیرساخت، پلاتفرم Apigee همچنین دارای موانع محافظتی داخلی برای محافظت از فرایندهای درحال اجرا است.
A9:2017 - Using Components with Known Vulnerabilities (استفاده از عناصر با آسیب‌پذیری‌های شناخته‌شده)
ازآنجایی‌که چارچوب‌ها، کتابخانه‌ها، و واحدها با دسترسی کامل به اجرا و CRUD اجرا می‌شوند، مهاجمان می‌توانند از آسیب‌پذیری‌های مؤلفه برای حمله به سیستم‌ها استفاده کنند.
انتشار منظم محصولات Apigee تضمین می‌کند که دربرابر آسیب‌پذیری‌های مؤلفه محافظت شوید، به‌ویژه زمانی که آسیب‌پذیری‌های خاصی کشف می‌شوند. ابر عمومی Apigee به‌طور خودکار وصله می‌شود و Apigee وقتی وصله‌های بوم‌گرد برای نصب دردسترس قرار می‌گیرند به مشتریان Edge for Private Cloud اطلاع می‌دهد.
A10:2017 - گزارش‌دهی و نظارت ناکافی
وقتی در سیستم‌هایتان به‌طور کافی گزارش‌گیری، پایش، و مدیریت رخداد انجام نمی‌دهید، مهاجمان می‌توانند حمله‌های عمیق‌تر و طولانی‌تری روی داده‌ها و نرم‌افزار انجام دهند.
Apigee چندین روش برای انجام گزارش‌گیری، نظارت، مدیریت خطا، و گزارش‌گیری ممیزی دارد.
ثبت
- پیام‌های گزارش را می‌توان بااستفاده از خط‌مشی MessageLogging به Splunk یا نقطه پایانی syslog دیگر ارسال کرد.
- داده‌های تجزیه‌وتحلیل API را می‌توان ازطریق analytics API بیرون کشید و در سیستم‌های دیگر وارد یا صادر کرد.
- در Edge for Private Cloud، می‌توانید از خط‌مشی MessageLogging برای نوشتن در فایل‌های گزارش محلی استفاده کنید. فایل‌های گزارش از هریک از اجزای درحال اجرا نیز دردسترس است.
- از خط‌مشی جاوا اسکریپت می‌توان برای ارسال هم‌زمان یا ناهم‌زمان پیام‌های گزارش به نقطه پایانی گزارش‌گیری REST استفاده کرد.
پایش کردن
- از میانای کاربر پایش میانای برنامه‌سازی کاربردی یا میانای برنامه‌سازی کاربردی برای پایش منظم میاناهای برنامه‌سازی کاربردی و کارسازهای پشتیبان و راه‌اندازی هشدارها استفاده کنید.
- از پایش وضعیت سلامت برای پایش منظم زیرینه‌های سرور هدف استفاده کنید.
- Apigee توصیه‌هایی برای پایش Edge for Private Cloud ارائه می‌دهد.
- Apigee همچنین روال‌های مطلوب را ارائه می‌دهد که تیم شما می‌تواند از آن‌ها برای نظارت بر برنامه API خود استفاده کند.
مدیریت کردن خطا
Apigee یک سازوکار قدرتمند و همه‌کاره برای مدیریت خطا در پراکسی‌های API ارائه می‌دهد. مشابه روشی که برنامه Java استثناها را دریافت می‌کند، کارگزاران API می‌توانند خطاها را دریافت کنند و تعیین کنند که چگونه پاسخ‌های مناسب را به مشتریان برگردانند. مدیریت خطای سفارشی Apigee به شما امکان می‌دهد هر زمان که خطایی رخ می‌دهد، کارکردهایی مانند ثبت پیام اضافه کنید.
گزارش‌های ممیزی
پلاتفرم Apigee گزارش ممیزی‌ای نگه می‌دارد که تغییرات در پراکسی‌های API، محصولات، و سابقه سازمان را پیگیری می‌کند. این گزارش ازطریق واسط کاربر یا ازطریق میانای برنامه‌سازی کاربردی ممیزی‌ها دردسترس است.
راه‌حل‌های Apigee برای آسیب‌پذیری‌های OWASP در سال ۲۰۱۳
وقتی OWASP فهرست خود را برای سال ۲۰۱۷ به‌روز کرد، برخی‌از آسیب‌پذیری‌های فهرست سال ۲۰۱۳ حذف شدند. این آسیب‌پذیری‌ها همچنان تهدیدهای معتبری هستند. بخش‌های زیر نحوه مدیریت این تهدیدها با Apigee را توضیح می‌دهد.
A8:2013 - جعل درخواست بین‌سایتی (CSRF)
درخواست‌های جعل بین‌سایتی به مهاجمان اجازه می‌دهد جزئیات اصالت‌سنجی کاربر، کوکی جلسه، و داده‌های دیگر را ازطریق HTTP به برنامه وب آسیب‌پذیر ارسال کنند و برنامه وب را فریب دهند تا باور کند درخواست‌ها درخواست‌های قانونی کاربر هستند.
رهنمودها:
- این بیشتر مشکل مرورگر است، نه مشکل محصول «میانای برنامه‌سازی کاربردی». می‌توانید این آسیب‌پذیری را با OpenID Connect، OAuth، و تکنیک‌های دیگر برطرف کنید.
- برای جلوگیری از حملات جعل و بازپخش، از تکنیک‌های HMAC، وضعیت، درهم‌سازی، نانس، یا PKCE استفاده کنید.
A10:2013 - هدایت‌ها و ارسال‌های تأییدنشده
اگر یک برنامه وب هدایت مجدد انجام دهد، اما تأیید نکند که هدایت‌های مجدد کاربران را به وب‌سایت‌های مورد اعتماد و موردنظر می‌فرستد، مهاجمان می‌توانند کاربران را به مقاصد مخرب بفرستند تا رمزگیری، اجرای بدافزار، و حملات دیگر انجام دهند.
رهنمودها:
- از OAuth استفاده کنید و در هر درخواست، اعتبارسنجی را اعمال کنید.
- با بررسی کدهای پاسخ در منطق پراکسی API و مدیریت صحیح هدایت‌های مجدد، از هدایت‌های مجدد غیرمنتظره ۳۰۲ جلوگیری کنید.