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

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

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

مقدمه

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

این سند رویکردهای محافظت در برابر حملات متداول مبتنی بر API را که توسط ده تهدید امنیتی برتر OWASP در سال 2019 شناسایی شده است، مورد بحث قرار خواهد داد. یک موضوع رایج در تهدیدات برتر که توسط آخرین لیست برجسته شده است، به دلیل قرار دادن نادرست کنترل‌های احراز هویت و مجوز، مانند اتکا به فیلتر کردن داده‌های بازگردانده شده توسط یک درخواست 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 خود را طوری طراحی کنید که تمام داده های پاسخ را از باطن در Apigee فیلتر کنند. هرگز برای انجام این کار به منطق کد برنامه پایین دستی اعتماد نکنید!
  • تمام درخواست‌های داده حاوی PII خاص کاربر را فیلتر کنید تا فقط داده‌هایی از باطن شما که متعلق به کاربر درخواست‌کننده است مجاز باشد.

مجوز سطح شیء شکسته API1:2019

شرح تهدید

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

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

از دیدگاه اجرای Apigee دو جنبه اصلی وجود دارد:

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

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

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

خط مشی های تأیید توکن دسترسی Apigee عبارتند از:

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

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

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

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

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

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

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

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

API2:2019 احراز هویت کاربر خراب است

شرح تهدید

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

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

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

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

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

طراحی امنیتی

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

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

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

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

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

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

ویژگی های مدیریت ترافیک Apigee زیر به محافظت در برابر حمله brute force کمک می کند:

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

حکومت داری

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

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

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

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

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

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

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

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

گزارش امنیتی

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

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

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

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

Apigee Sense

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

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

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

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

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

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

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

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

API3:2019 قرار گرفتن در معرض بیش از حد داده

شرح تهدید

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

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

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

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

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

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

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

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

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

  • اختصاص پیام
  • فراخوان کدها
  • رسیدگی به خطا

تعیین خط مشی پیام

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

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

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

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

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

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

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

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

رسیدگی به خطا

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

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

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

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

شرح تهدید

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

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

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

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

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

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

دستگیری سنبله

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

سهمیه ها

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

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

این خط‌مشی از دستگیری Spike دقیق‌تر است و عموماً باید همزمان با آن استفاده شود.

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

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

تشخیص تهدید با مانیتورینگ پیشرفته API Ops

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

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

شرح تهدید

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

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

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

  • چه چیزی محافظت می شود؟ در مورد استراتژی محصول API خود فکر کنید و هنگام استفاده از بهترین شیوه های RESTful برای طراحی مسیرها و منابعی که توسط پراکسی ها، محصولات و ویژگی های برنامه های Apigee API در معرض دید قرار می گیرند، تقسیم بندی منطقی عملکرد را اجرا کنید.
  • چه کسی به منابع 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، هرگونه درخواستی را که خارج از این است محدود کنید:

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

API6: 2019 تکلیف انبوه

شرح تهدید

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

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

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

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

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

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

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

  1. API خود را با ایجاد مشخصات OpenAPI (OAS) طراحی کنید
  2. میانجیگری، امنیت و منطق ذخیره سازی لازم را برای افشای ایمن یک محصول API از باطن خود با 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ها را در معرض دید قرار دهند:

  • از پایبندی به سیاست های امنیتی و الزامات پیکربندی اطمینان حاصل کنید
  • از داده های حساس در برابر سوء استفاده های داخلی و خارجی محافظت کنید
  • به طور فعال حوادث امنیتی را شناسایی، تشخیص و حل کنید

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

با گزارش امنیتی ، مدیران امنیتی می توانند به سرعت درک کنند که چگونه پروکسی های API شما برای امنیت پیکربندی می شوند ، و همچنین شرایط زمان اجرا که ممکن است بر امنیت پروکسی تأثیر بگذارد. با استفاده از این اطلاعات ، می توانید پیکربندی را تنظیم کنید تا از سطح امنیت مناسب برای هر پروکسی برخوردار باشید.

نظارت API

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

شکل: نظارت APIGEE API طیف گسترده ای از ابزارها را برای نظارت ، بررسی و عمل در مورد موضوعات فراهم می کند. این بهترین ویژگی در ویژگی های اطلاعات کلاس از Google Cloud Platform است.

حس apigee

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

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

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

API8: تزریق 2019

توصیف تهدید

تزریق غیرقابل اعتماد از داده ها ، مانند SQL ، NOSQL ، XML پارسرها ، ORM ، LDAP ، دستورات OS و JavaScript ، به درخواست های API می تواند منجر به اجرای دستورات ناخواسته یا دسترسی به داده های غیرمجاز شود. مهاجمان از طریق هر نوع بردارهای تزریقی مانند ورودی مستقیم ، پارامترها ، خدمات یکپارچه و غیره ، API را با داده های مخرب تغذیه می کنند و انتظار دارند که آن را به یک مترجم ارسال کند. مهاجمان می توانند هنگام بررسی کد منبع با استفاده از اسکنرهای آسیب پذیری و فاز ، این نقص ها را به راحتی کشف کنند. تزریق موفقیت آمیز می تواند منجر به افشای اطلاعات شود که بر محرمانه بودن و از بین رفتن داده ها تأثیر می گذارد یا در برخی موارد ممکن است منجر به DOS نیز شود.

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

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

سیاست حفاظت منظم بیان

خط مشی regularexpressionProtection اطلاعات را از یک پیام (به عنوان مثال ، مسیر URI ، query param ، header ، فرم پارام ، متغیر ، بارگذاری XML یا بار JSON) استخراج می کند و آن محتوا را در برابر عبارات منظم از پیش تعریف شده ارزیابی می کند. اگر هرگونه عبارات منظم مشخص به درستی ارزیابی شود ، پیام تهدید محسوب می شود و رد می شود. یک عبارت منظم یا Regex به طور خلاصه ، مجموعه ای از رشته ها است که یک الگوی را در یک رشته مشخص می کند. عبارات منظم باعث می شود محتوا به صورت برنامه ای برای الگوهای ارزیابی شوند. به عنوان مثال می توان از عبارات منظم برای ارزیابی آدرس ایمیل استفاده کرد تا از ساخت صحیح آن اطمینان حاصل شود.

متداول ترین استفاده از RegulareXpressionProtection ارزیابی بارهای JSON و XML برای محتوای مخرب است.

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

چندین روش دیگر برای اعتبارسنجی ورودی موجود با پلت فرم Apigee وجود دارد:

انواع محتوا را تأیید کنید

نوع محتوا به محتوای پرونده ای اشاره دارد که از طریق HTTP منتقل می شود و طبق یک ساختار دو قسمتی طبقه بندی می شود. Apigee توصیه می کند با استفاده از منطق شرطی همانطور که در زیر توضیح داده شده است ، انواع محتوا را برای درخواست و پاسخ تأیید کنید.

گزارش امنیتی API

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

  • اطمینان از پیروی از سیاست های امنیتی و الزامات پیکربندی.
  • محافظت از داده های حساس در برابر سوء استفاده داخلی و خارجی.
  • شناسایی ، تشخیص و حل حوادث امنیتی.

API9: 2019 مدیریت نامناسب دارایی

توصیف تهدید

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

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

سازمان ها ، محیط ها و اصلاحات : نگهبان های مجازی و فیزیکی که انزوا را تضمین می کنند و یک فرآیند ارتقاء امن از طریق زمینه های زمان اجرا.

کنترل دسترسی مبتنی بر نقش : فقط افراد لازم در تیم های API شما مجوز برای مدیریت تغییرات پیکربندی و همچنین روند ارتقاء دارند.

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

قلاب های جریان : شما می توانید سیاست ها و الگوهای جهانی را اجرا کنید که می توانند به عنوان نگهبان ممتاز مدیریت شوند که توسط توسعه دهندگان API قابل تغییر نیستند.

گزارش امنیتی : ذینفعان امنیتی به پایان رسیده اند تا دید API های منتشر شده و پیکربندی پشتیبانی آنها را به پایان برسانند. پیروی از سیاست های امنیتی جهانی می تواند بر اساس مشخصات ریسک برای هر نقطه پایانی API منتشر شده حسابرسی و ارزیابی شود.

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

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

سازمان ها : یک سازمان مستاجر سطح بالا در Apigee است. این امکان را برای شما فراهم می کند که تفکیک کامل برای ترافیک ، پیکربندی و کاربران داشته باشید. به عنوان بهترین روش حاکمیتی ، باید در نظر داشته باشید که سازمانهای تولید و تولید جداگانه ای داشته باشید. این عمل به طور موثری از مخلوط کردن داده های تولید ، کاربران و ترافیک با محیط های پایین جلوگیری می کند.

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

اصلاحات : اصلاحات به API ها و ویژگی های فردی اجازه می دهد تا از طریق محیط ها یکپارچه ارتقا یابد.

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

به منظور کاهش API9 ، داشتن تعاریف واضح و جدایی وظایف بین ذینفعان امنیتی و توسعه دهندگان API ضروری است. همانطور که قبلاً در این سند گفته شد ، Apigee دارای قابلیت کنترل دسترسی مبتنی بر نقش انعطاف پذیر است که به شما امکان می دهد مجوزهایی را به نقش های سفارشی اختصاص دهید. برای این تهدید خاص ، می توان نقش ها را در اختیار داشت تا امتیازات محدودی در هر سازمان ، محیط یا مجوزهای پیکربندی گرانول بیشتری داشته باشد. به عنوان یک عمل ارجح ، محدودیت های محدود کردن امتیازات برای تغییر وضعیت استقرار API ها از طریق محیط و همچنین اطمینان حاصل کنید که توسعه دهندگان قادر به دسترسی یا اصلاح کتابخانه های امنیتی جهانی نیستند (قلاب های جریان). این نقش های محدود از تغییرات ناخواسته در سیاست های امنیتی جهانی که پوشش گسترده ای در میراث و نقاط پایانی منتشر شده فعلی دارند ، جلوگیری می کند.

مدیریت مخاطبان برای مستندات API

پورتال توسعه دهنده یک مؤلفه مهم برای موفقیت استراتژی API شماست. این امکان را به شما می دهد تا یک موجودی جامع از کلیه مستندات مربوط به API های خود از جمله میزبان/نقاط پایانی ، منابع ، عملیات ، طرح های بارگذاری و موارد دیگر را نگه دارید. در Apigee می توانید API های خود را با استفاده از سازه های محصول API گروه بندی کنید. محصولات API توسط بسته های منابع و عملیاتی که در همان زمینه تجاری و امنیتی قرار دارند تعریف می شوند (به عنوان مثال برنامه خدمات ، دامنه تجاری ، دسته ، سلسله مراتب شرکت و غیره).

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

قلاب

فرآیندهای ارتقاء و آزادی برای API ها همیشه باید شامل فرآیندهای انطباق امنیتی و صدور گواهینامه باشد. برای مؤثر بودن ، تیم های API با استفاده از ابزارهای مناسب باید بتوانند GuardRails ایجاد کنند که تضمین جدایی مسئولیت ها و ضمن حفظ چرخه انتشار چابک را تضمین می کند.

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

شکل: نگهبانان ممتاز را می توان از طریق قلاب های جریان و جریان های مشترک در Apigee پیکربندی کرد. ذینفعان امنیتی وظیفه حفظ سیاست های مربوط به امنیت جهانی را بر عهده دارند. این ویژگی ها جدایی مسئولیت ها را تضمین می کند و چرخه زندگی توسعه چابک را ترویج می کند.

گزارش امنیتی

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

در Apigee شما به گزارش های امنیتی تخصصی دسترسی دارید که به اطمینان از پیروی از سیاست های تعریف شده کمک می کند و تیم های امنیتی خود را قادر می سازد بر اساس بینش های جامع در مورد:

ترافیک زمان اجرا : نمای یک مرحله ای برای بینش ترافیک API در: سرورهای هدف ، میزبان های مجازی ، پیکربندی TLS ، تغییر ترافیک در هر محیط و موارد دیگر.

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

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

API10: 2019 ورود و نظارت کافی

توصیف تهدید

ورود به سیستم ، نظارت و هشدارها کافی نیست که حملات در حال انجام در حال انجام باشد و بنابراین باید یک استراتژی برای به دست آوردن بینش نسبت به رویدادهای مهم که بر تجارت شما تأثیر دارد ، لازم باشد.

استراتژی های مدیریت رویداد و ورود به سیستم برای API ها باید بهترین روشهای زیر را در نظر بگیرند:

  • خط مشی مدیریت سیاههها : مستندات و اجرای قوانین برای استاندارد سازی و کنترل سیاهههای مربوط به کلام ، سطح ورود به سیستم ، یکپارچگی ورود به سیستم ، مخزن متمرکز و موارد دیگر
  • خط مشی مدیریت رویداد : تضمین کنید که هر رویدادی باید در منبع خود قابل ردیابی باشد. همچنین ، رویدادها باید بتوانند با انتقاد و تأثیر تجاری طبقه بندی شوند
  • گزارش ها و ممیزی ها : ذینفعان امنیتی و عملیات باید بتوانند در زمان واقعی به سیاههها و رویدادها دسترسی پیدا کنند و واکنش نشان دهند. علاوه بر این ، چرخه تقویت می تواند توسط ذینفعان انجام شود تا الگوهای تشخیص را بر اساس داده های تاریخی تنظیم کنند

Apigee ابزارهای لازم را برای ایجاد یک رویداد جامع و استراتژی مدیریت ورود به سیستم فراهم می کند. این ابزارها عبارتند از:

خط مشی ورود به سیستم پیام : جریان های ورود به سیستم را بر اساس داده های ترافیکی یا ابرداده از ترافیک API خود ایجاد کنید. شما این انعطاف پذیری را برای تصمیم گیری در مورد جریان جریان با استفاده از منطق شرطی و الگوهای پیام دارید.

مجموعه عملکرد Cloud Google : از ادغام خارج از جعبه در ابزارهای نظارت و ورود به سیستم بسیار مقیاس پذیر از Google استفاده کنید.

خط مشی تماس با خدمات : پشتیبانی از جریان های سیاهه هایی را که برای ارسال رویدادها به نقاط پایانی HTTP نیاز دارند ، اضافه می کند.

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

نظارت API : همانطور که قبلاً توضیح داده شد ، این ابزار قابلیت های هشدار دهنده ای را ارائه می دهد که می تواند بر اساس وقایع مهم ایجاد شود. سیاهههای مربوط به ترافیک را می توان بیشتر مورد تجزیه و تحلیل قرار داد و بر اساس آن عمل کرد.