ممکن است بارها شنیده باشید که «گسترش بی‌رویهٔ API همان فناوری سایه (Shadow IT) جدید است». اما این واقعاً به چه معناست؟ این مشکل از کجا سرچشمه می‌گیرد؟ در عصر هوش مصنوعی، این موضوع چه معنایی دارد؟ و از همه مهم‌تر، این مشکل تا چه اندازه در صنعت API فراگیر است؟
امروز قصد داریم به مشکل گسترش بی‌رویهٔ API و فناوری سایه از دیدی کلی نگاه کنیم. ما به مسئلهٔ امنیت API می‌پردازیم، بررسی می‌کنیم این موضوع چگونه برای بیشتر ارائه‌دهندگان معنا پیدا می‌کند و تأثیر آن بر سازمان‌هایی که با API کار می‌کنند چیست.
فناوری سایه (Shadow IT) چیست؟
پیش از آنکه دربارهٔ گسترش API صحبت کنیم، بیایید مشخص کنیم منظور از فناوری سایه چیست. به طور کلی، فناوری سایه به استفاده از سیستم‌ها، نرم‌افزارها، دستگاه‌ها و موارد مشابه بدون تأیید — یا حتی بدون آگاهی — بخش فناوری اطلاعات مرکزی یک سازمان گفته می‌شود. این موضوع می‌تواند به دلایل گوناگونی، هم مشروع و هم غیرمشروع، رخ دهد.
تصور کنید شما کارمندی هستید که در یک شرکت بزرگ در بخش پشتیبانی مستقیم مشتری فعالیت می‌کنید. مشتری از شما دربارهٔ نسخهٔ موبایل نرم‌افزار اصلی شرکت سؤال می‌کند و برای یافتن بهترین پاسخ، تصمیم می‌گیرید از طریق اپلیکیشن iOS وارد حساب کاربری توسعه‌دهنده شوید. در آنجا داده‌های مورد نیازتان را جمع‌آوری می‌کنید و برای پشتیبانی بهتر، تصمیم می‌گیرید از داده‌ها اسکرین‌شات بگیرید و با مشتری به اشتراک بگذارید. برای این کار، تصاویر را در Google Drive شخصی خود آپلود کرده و لینک را با استفاده از متنی که در ChatGPT ساخته‌اید برای مشتری ارسال می‌کنید.
برای یک کارمند عادی، این فرایند ممکن است بسیار کارآمد به نظر برسد، اما از دید یک شرکت بزرگ، این نمونه‌ای بارز از فناوری سایه است. استفاده از دستگاه شخصی بدون مجوز، استفاده از نرم‌افزار تأیید‌نشده، و اشتراک‌گذاری داده‌ها از طریق Google Drive شخصی — همهٔ این موارد نشانه‌های فناوری سایه هستند.
علت وقوع چنین مواردی نیز روشن است: کارمندان معمولاً می‌خواهند از بهترین ابزارها برای انجام کارشان استفاده کنند. تمایل به بهره‌وری، نیاز به دور زدن فرایند کند یا ناکارآمد تأیید فناوری اطلاعات، و فقدان راهکارهای ساده و رسمی، موجب می‌شود در صورت امکان از روش‌های غیررسمی بهره ببرند.
گسترش بی‌رویهٔ API چیست؟
فناوری سایه پدیده‌ای شناخته‌شده و به‌نسبت ساده برای تعریف است. اما گسترش API چطور؟ گسترش بی‌رویهٔ API به افزایش کنترل‌نشدهٔ تعداد APIها درون یک سازمان گفته می‌شود. زمانی که APIها بدون نظارت، مستندسازی یا محدودیت مشخصی ایجاد و استفاده می‌شوند، شبکه‌ای از سیستم‌های به‌هم‌پیوسته یا جدا از هم شکل می‌گیرد که خارج از دید و استراتژی یکپارچهٔ سازمان است.
این وضعیت می‌تواند خطرات قابل توجهی ایجاد کند. برخی از پیامدهای رایج گسترش API عبارت‌اند از:
-
APIهای دارای مستندسازی ضعیف که به سیستم‌هایی بدون دلیل یا کنترل روشن متصل می‌شوند.
-
نبود نظارت کافی بر APIهایی که با سامانه‌های حیاتی یا داده‌های خصوصی تعامل دارند.
-
دسترسی تکراری یا افزونه به داده‌ها که باعث افزایش ترافیک شبکه و مصرف منابع می‌شود.
-
سیستم‌های متروکه یا منسوخ که تهدیدی پنهان برای پایداری کل شبکه محسوب می‌شوند.
-
نقاط پایانی ناامن که می‌توانند به مهاجمان اجازه دهند کنترل‌ها را دور بزنند.
مشابه فناوری سایه، تأخیر در فرایندهای تأیید می‌تواند باعث شود تیم‌ها برای نیازهای خاص خود APIهای اختصاصی بسازند. در موارد دیگر، تیم‌ها برای پاسخگویی سریع‌تر، راهکارهای غیرمتمرکز طراحی می‌کنند یا برای سرعت بیشتر، نقاط پایانی جدیدی ایجاد می‌کنند که از پیش وجود داشته‌اند.
با وجود شباهت‌ها با فناوری سایه، برخی دلایل خاص موجب گسترش API می‌شوند که آن را از سایر مشکلات متمایز می‌کند:
-
ادغام و تملک شرکت‌ها می‌تواند باعث افزوده شدن APIها و پلتفرم‌های جدیدی شود که هرگز با هستهٔ اصلی یکپارچه نمی‌شوند.
-
معماری مایکروسرویس‌ها منجر به افزایش تعداد نقاط پایانی می‌شود و در صورت نبود کنترل کافی، اثرات سوء مدیریت را به‌سرعت چند برابر می‌کند.
-
استفاده از APIهای متن‌باز به عنوان منابع «غیررسمی اما پذیرفته‌شده».
داده‌ها نشان می‌دهند که APIها فناوری سایهٔ جدید هستند
گزارش‌های اخیر نشان می‌دهند نگرانی نسبت به APIها رو به افزایش است. طبق گزارش امنیت API شرکت Traceable در سال ۲۰۲۳، حدود ۴۸٪ از سازمان‌ها گسترش بی‌رویهٔ API را یکی از نگرانی‌های اصلی امنیت API می‌دانند. همچنین، ۳۹٪ از سازمان‌ها در حفظ فهرست دقیق APIهای خود مشکل دارند و ۳۰٪ در مدیریت دسترسی APIهای شخص ثالث دچار چالش هستند.
گزارش Postman نیز نشان می‌دهد که ۳۱٪ از شرکت‌های نرم‌افزاری شرکت‌کننده اذعان کرده‌اند که «مدیریت تعداد زیاد APIها یا مایکروسرویس‌ها» مانعی جدی برایشان است. این رقم بالاتر از میانگین کلی ۲۳٪ است.
پیش‌بینی‌ها حاکی از آن است که این رشد به این زودی متوقف نخواهد شد. تحلیل انجام‌شده توسط F5 نشان می‌دهد که تا سال ۲۰۳۱، تعداد APIهای فعال می‌تواند از یک میلیارد فراتر رود.
متأسفانه، همهٔ این داده‌ها به یک نکته اشاره دارند: APIهای بیشتری بدون کنترل لازم ساخته می‌شوند و اغلب بدون مستندسازی کافی مورد استفاده قرار می‌گیرند. این مشکل با گسترش خدمات SaaS مانند OpenAI که APIهای قابل‌ادغام آسان ارائه می‌دهند، پیچیده‌تر می‌شود — چرا که استفاده از این APIها ممکن است تا زمانی که به‌صورت خاص بررسی نشوند، آشکار نباشد.
کاهش تأثیر گسترش API
حال که مسئله را شناختیم، پرسش این است که چگونه می‌توان این خطر را در مقیاس گسترده کاهش داد؟ هرچند هنوز این معضل در سطح صنعت حل نشده، برخی روش‌های برتر می‌توانند به سازمان‌ها کمک کنند اثرات گسترش API را کاهش دهند.
ایجاد فهرست مرکزی API
چیزی را که نمی‌بینید، نمی‌توانید مدیریت کنید. بخشی از مشکل از روش‌های ناکارآمد در مستندسازی و کنترل APIها ناشی می‌شود. بنابراین، باید فهرست مرکزی API بسازید که تمام APIهای عمومی، خصوصی، داخلی و شخص ثالث را دنبال کند. این فهرست باید شامل مالکیت، اطلاعات تماس، نسخه‌بندی، فرادادهٔ چرخهٔ عمر، الزامات امنیتی و احراز هویت، و هرگونه طرح یا تعریف OpenAPI باشد.
این فهرست فقط برای نظارت نیست — می‌تواند برای آموزش توسعه‌دهندگان، مدیریت درگاه‌ها، کشف APIها و دیگر موارد نیز کاربرد داشته باشد. باید اطمینان حاصل کنید که این فهرست به منبعی واحد و معتبر تبدیل شود، نه صرفاً صفحه‌ای از مستندات که به ندرت مراجعه می‌شود.
انتقال حاکمیت API به مراحل ابتدایی‌تر
انتقال به «سمت چپ» به معنای جابه‌جایی تمرکز از انتشار نهایی به مراحل اولیهٔ چرخهٔ توسعهٔ نرم‌افزار است. ایده این است که حاکمیت باید بخشی از جریان توسعه باشد، نه موضوعی که بعداً به آن فکر شود.
راهکارهای ممکن شامل موارد زیر است:
-
افزودن بررسی‌های طراحی، اعتبارسنجی طرح، راهبردهای منقضی‌سازی و حذف در خطوط CI/CD
-
بازبینی مداوم فهرست APIها
-
استفاده از ابزارهایی مانند Spectral یا Redocly برای اعتبارسنجی OpenAPI، و Swagger یا Optic برای شناسایی تغییرات شکسته در مقیاس بزرگ
-
بهره‌گیری از GitHub Actions برای جلوگیری از ادغام APIهای تأیید‌نشده
هدف از این اقدامات کند کردن تیم‌ها نیست، بلکه افزودن دید و کنترل پیش از انتشار API است.
الزام به ثبت API
یکی دیگر از روش‌های مؤثر کنترل گسترش API، استفاده از درگاه‌های API یا شبکه‌های سرویس به‌عنوان نقطهٔ کنترل است. برای مثال، می‌توان تمام تماس‌های API را از یک درگاه مرکزی عبور داد تا جریان داده‌ها قابل ثبت و کنترل باشد. در این حالت می‌توان احراز هویت مرکزی، محدودسازی نرخ، پایش، ثبت وقایع و سایر قابلیت‌ها را پیاده‌سازی کرد.
این کار کنترل نسخه‌ها، سیاست‌ها و لغو دسترسی‌ها را نیز تسهیل می‌کند. در نتیجه، تنها APIهای مجاز قادر به تعامل با سیستم خواهند بود.
خودکارسازی کشف APIها
حتی با وجود چنین سیستم‌هایی، ممکن است APIهایی بدون نظارت باقی مانده باشند. برای رفع این مشکل، می‌توان کشف خودکار APIهای رهاشده یا غیرمجاز را از طریق بازرسی عمیق انجام داد. با بررسی ترافیک شبکه، لاگ درگاه‌ها، تلمتری دیوارهٔ آتش API و سایر سیستم‌ها، می‌توان تمام تعاملات API را ثبت کرد.
این کار علاوه بر بهبود قابلیت مشاهده، به شناسایی APIهای مستندسازی‌نشده، نقاط پایانی زامبی یا ناامن و تماس‌های شخص ثالث مشکوک کمک می‌کند. ابزارهایی مانند Traceable، Noname Security یا Salt Security برای پیاده‌سازی آسان وجود دارند و همچنین می‌توان با استفاده از ابزارهای متن‌باز مانند Prometheus و Grafana سامانهٔ بومی نظارتی ساخت.
اجرای سیاست‌های چرخهٔ عمر API
در نهایت، اجرای سیاست‌های چرخهٔ عمر API حیاتی است. هر API باید چرخه‌ای مشخص داشته باشد: ایجاد، استفاده، نگهداری، و منقضی شدن. بدون این سیاست‌ها، نقاط پایانی فراموش‌شده همچنان فعال می‌مانند و بدون نظارت، قوانین صرفاً روی کاغذ باقی می‌مانند.
برای اجرای صحیح این سیاست‌ها باید موارد زیر را در سطح سازمان تعیین کرد:
-
استانداردسازی نسخه‌بندی، اطلاعیه‌های انقضا و اطلاع‌رسانی به کاربران
-
تعیین بازه‌های زمانی برای حذف یا منسوخ‌سازی و معیارهای تصمیم‌گیری مبتنی بر ترافیک
-
سیاست‌های سازگاری با نسخه‌های قبلی
-
روند مدیریت تغییرات شکسته و زمان‌بندی مهاجرت کاربران
این سیاست‌ها باید بخشی اساسی از محصول در نظر گرفته شوند و راهنمای کل چرخهٔ عمر آن باشند.
مقابله با APIهای سایه در آیندهٔ عامل‌محور
این مسئله هنوز حل نشده است. گسترش API با سرعت در حال افزایش است و با ظهور مدل‌های زبانی بزرگ (LLM) که از پروتکل زمینهٔ مدل (MCP) و APIها بهره می‌برند، این رشد احتمالاً به‌صورت تصاعدی ادامه خواهد داشت. در سه تا پنج سال آینده، نیاز به کنترل‌های مؤثرتر برای دسترسی عامل‌محور افزایش می‌یابد، و در نتیجه باید توانایی خود را در مستندسازی و کنترل APIها ارتقا دهیم. کاری که امروز انجام می‌دهیم، پایه‌گذار آینده‌ای خواهد بود که در آن گسترش APIها به‌مراتب قابل کنترل‌تر است.
