۲۶۸ هزار سامانهٔ AI روی اینترنت باز مانده‌اند؛ ۱۱۴ هزار مورد n8n است

شرکت Censys در اعلام انتشار گزارش وضعیت اینترنت در ۱۴ اکتبر ۲۰۲۶ گفت شمار ابزارهای مرتبط با هوش مصنوعی که از اینترنت قابل مشاهده‌اند، پس از رشد ۶۳ درصدی طی نه ماه به نزدیک ۲۶۸ هزار سامانه رسیده است؛ n8n با نزدیک ۱۱۴ هزار میزبان، بزرگ‌ترین گروه محصولی این شمارش است. این ارقام گسترهٔ دسترسی اینترنتی را نشان می‌دهند، نه تعداد سامانه‌هایی را که به آن‌ها نفوذ شده است.

در گزارش Axios، شمارش ژوئیهٔ ۲۰۲۶ شامل ۴۴ محصول بود و از حدود ۱۶۴ هزار سامانه در اکتبر ۲۰۲۵ افزایش یافته بود؛ نزدیک ۷۷ هزار میزبان n8n نسخه‌هایی داشتند که در دامنهٔ دست‌کم یک آسیب‌پذیری بحرانی تازه‌افشاشده قرار می‌گرفتند و امیلی آستین، پژوهشگر Censys، دربارهٔ اتصال این ابزارها به سرویس‌های دیگر گفت: «these [tools] talk to some really sensitive systems». قرارگرفتن نسخهٔ نرم‌افزار در دامنهٔ یک آسیب‌پذیری، به‌تنهایی ثابت نمی‌کند آن نصب مشخص قابل بهره‌برداری بوده یا داده‌ای از آن خارج شده است.

این شمارش چه سطحی از دسترسی را نشان می‌دهد

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

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

چرا دسترسی به n8n می‌تواند به سرویس‌های دیگر برسد

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

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

ممیزی دارایی‌ها بدون ابزار اختصاصی

بازبینی را از دارایی‌های تحت مالکیت خود شروع کنید: دامنه‌ها و زیردامنه‌ها، رکوردهای DNS، نشانی‌های عمومی حساب‌های ابری، تنظیمات پراکسی معکوس و فهرست استقرارهایی که اعضای تیم یا پیمانکاران ساخته‌اند. برای هر مورد، مالک فنی، محیط تولید یا آزمایش، دلیل دسترسی بیرونی و سرویس‌های متصل را ثبت کنید. رکورد DNS به‌تنهایی کافی نیست؛ استقرارهایی که مستقیم با نشانی IP در دسترس‌اند نیز باید در فهرست بیایند.

1. دامنه‌ها و نشانی‌های عمومی را با فهرست نصب‌های n8n و ابزارهای مشابه تطبیق دهید و نشانی‌های آزمایشی را هم نگه دارید. از بیرون شبکهٔ مجاز فقط دارایی‌های خودتان را بررسی کنید تا روشن شود کدام مسیرها پاسخ می‌دهند و آیا صفحهٔ ورود یا مدیریت در دسترس عموم است.
2. برای هر مسیر عمومی، نیاز عملی آن را مشخص کنید. اگر فقط وب‌هوک باید درخواست بیرونی بگیرد، دسترسی به پنل مدیریت را در پراکسی، شبکه یا لایهٔ احراز هویت محدود کنید و پس از اعمال تغییر، نتیجه را دوباره از بیرون بسنجید. تغییر نام مسیر، جایگزین کنترل دسترسی نیست.
3. اتصال‌های هر جریان را به ایمیل، پایگاه داده، فضای ذخیره‌سازی و سرویس‌های دارای API ربط دهید. اعتبارنامه‌های بدون استفاده را حذف کنید، مجوزهای باقی‌مانده را به کار لازم محدود کنید و کلیدهایی را که احتمال افشا یا استفادهٔ ناخواسته از آن‌ها وجود دارد از سمت سرویس صادرکننده بچرخانید. برای اتصال عامل هوش مصنوعی، ببینید چه داده‌ای را می‌تواند بخواند و چه اقدامی را می‌تواند به نام کاربر انجام دهد.
4. نسخهٔ نصب، وصله‌های منتشرشده و نشانه‌های دسترسی غیرعادی را با هم بررسی کنید. اگر نسخه در دامنهٔ آسیب‌پذیری قرار دارد، اولویت اصلاح را با توجه به دسترسی عمومی و مجوزهای متصل تعیین کنید؛ خودِ شمارهٔ نسخه بدون بررسی تنظیمات، نتیجهٔ یک نفوذ را مشخص نمی‌کند.

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

از مشاهدهٔ یک سرویس تا ارزیابی خطر آن

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

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

بیشتر بخوانید:

• Zoom یا Microsoft Teams؛ اینترنت 4G و هزینهٔ AI برنده را عوض می‌کنند
• عامل OpenAI وارد سامانهٔ دولتی استرالیا شد؛ گزارش‌دهی سه ماه طول کشید
• Pluto با ۴۲ میلیون دلار از اختفا بیرون آمد؛ ریسک اصلی از ابزارهای بی‌کد است