سوال: تفاوت بین API های زامبی و API های سایه چیست؟
نیک راگو، مدیر ارشد فناوری فیلد، امنیت نمک: APIهای زامبی و APIهای سایه محصول فرعی چالش بزرگ‌تری را نشان می‌دهند که امروزه شرکت‌ها در تلاش برای مقابله با آن هستند: گسترش API.
از آنجایی که شرکت ها به دنبال به حداکثر رساندن ارزش تجاری مرتبط با API ها هستند، API ها افزایش یافته اند. دگرگونی دیجیتال، مدرن‌سازی اپلیکیشن‌ها به میکروسرویس‌ها، معماری‌های برنامه اول API، و پیشرفت در روش‌های استقرار سریع نرم‌افزار مستمر، به رشد سریع تعداد APIهای ایجاد شده و در حال استفاده توسط سازمان‌ها دامن زده‌اند. در نتیجه تولید سریع API، گسترش API در تیم‌های متعددی که از پلتفرم‌های فناوری چندگانه (میراث، Kubernetes، VMها و غیره) در زیرساخت‌های توزیع‌شده متعدد (مراکز داده داخلی، چندین ابر عمومی و غیره استفاده می‌کنند) آشکار شده است. . موجودیت های ناخواسته مانند API های زامبی و API های سایه زمانی ظاهر می شوند که سازمان ها استراتژی های مناسبی برای مدیریت گسترش API نداشته باشند.
به زبان ساده، یک API زامبی یک API افشا شده یا یک نقطه پایانی API است که رها، قدیمی یا فراموش شده است. در یک نقطه، API یک عملکرد را انجام داد. با این حال، ممکن است دیگر به آن تابع نیاز نباشد یا API با نسخه جدیدتر جایگزین/به روز شده باشد. هنگامی که یک سازمان کنترل های مناسبی در مورد نسخه سازی، منسوخ شدن، و غروب API های قدیمی ندارد، آن API ها ممکن است به طور نامحدود باقی بمانند - از این رو اصطلاح زامبی به آن می گویند.
از آنجایی که APIهای زامبی اساساً فراموش شده‌اند، هیچ‌گونه وصله، نگهداری یا به‌روزرسانی مداومی را در هیچ ظرفیت عملکردی یا امنیتی دریافت نمی‌کنند. بنابراین، API های زامبی به یک خطر امنیتی تبدیل می شوند. در واقع، امنیت نمکوضعیت امنیت APIاین گزارش در چهار بررسی گذشته خود، API های زامبی را به عنوان نگرانی امنیتی شماره 1 سازمان ها نام می برد.
در مقابل، یک API سایه یک API در معرض یا یک نقطه پایانی API است که ایجاد و استقرار آن «زیر رادار» انجام شده است. Shadow APIها خارج از کنترل‌های نظارت، دید و امنیت API رسمی سازمان ایجاد و مستقر شده‌اند. در نتیجه، آنها می توانند طیف گسترده ای از خطرات امنیتی را ایجاد کنند، از جمله:
- API ممکن است دارای احراز هویت و گیت های دسترسی مناسب نباشد.
- API ممکن است داده های حساس را به درستی در معرض نمایش قرار دهد.
- API ممکن است از نقطه نظر امنیتی به بهترین شیوه‌ها پایبند نباشد و در مقابل بسیاری از موارد آسیب‌پذیر باشد. OWASP API Security Top 10 تهدیدات حمله
تعدادی از عوامل انگیزشی پشت این هستند که چرا یک برنامه‌نویس یا تیم برنامه بخواهد یک API یا نقطه پایانی را به سرعت اجرا کند. با این حال، برای اعمال کنترل‌ها و فرآیندهای مربوط به نحوه و زمان استقرار یک API بدون در نظر گرفتن انگیزه، باید از یک استراتژی سخت‌گیرانه حاکمیت API پیروی کرد.
علاوه بر این خطرات، گسترش API و ظهور APIهای زامبی و سایه فراتر از APIهای توسعه یافته داخلی است. API های شخص ثالث که به عنوان بخشی از برنامه های کاربردی بسته بندی شده، سرویس های مبتنی بر SaaS و مؤلفه های زیرساخت مستقر شده و مورد استفاده قرار می گیرند، اگر به درستی موجودی، کنترل و نگهداری نشوند، می توانند مشکلاتی را ایجاد کنند.
زامبی ها و API های سایه وضعیت مشابهی دارند خطرات امنیتی. بسته به کنترل‌های API موجود سازمان (یا فقدان آنها)، ممکن است یکی کمتر یا بیشتر از دیگری مشکل‌ساز باشد. به عنوان اولین گام برای مقابله با چالش های API های زامبی و سایه، سازمان ها باید از یک فناوری کشف API مناسب برای کمک به موجودی و درک همه API های مستقر در زیرساخت های خود استفاده کنند. علاوه بر این، سازمان‌ها باید یک استراتژی راهبری API را اتخاذ کنند که نحوه ساخت، مستندسازی، استقرار و نگهداری APIها را بدون در نظر گرفتن تیم، فناوری و زیرساخت، استاندارد کند.
