امنیت تاکتیکی برای ادغام فروشنده هیبریدی

معماری امنیتی در محیط های ترکیبی به طور سنتی بر مفاهیم شناخته شده ای مانند آسیب پذیری های OWASP، مدیریت هویت و دسترسی، کنترل دسترسی مبتنی بر نقش، امنیت شبکه و اصل کمترین امتیاز متمرکز شده است. بهترین شیوه ها مانند کدگذاری ایمن و ترکیب تست SAST/DAST در خطوط لوله CI/CD نیز به طور گسترده مورد بحث قرار گرفته است.

با این حال، زمانی که سازمان‌ها در یک مدل ترکیبی کار می‌کنند – حجم کاری را هم در محل و هم در فضای ابری اجرا می‌کنند – در حالی که با راه‌حل‌های ابری مدیریت شده توسط فروشنده ادغام می‌شوند، مجموعه‌ای از ملاحظات طراحی امنیتی مورد نیاز است. این سناریوها غیر معمول نیستند، اما به ندرت در زمینه استقرار یک راه حل امن شامل نرم افزار فروشنده در محیط های ترکیبی برجسته می شوند.

این مقاله چهار مورد استفاده در دنیای واقعی را برجسته می‌کند و استراتژی‌های معماری عملی را برای سازمان‌ها ترسیم می‌کند تا از یکپارچگی ایمن در تنظیمات ترکیبی اطمینان حاصل کنند.

اختصارات

• OWASP – پروژه Web Application Security را باز کنید
• SAST – تست امنیت برنامه استاتیک
• DAST – تست امنیت اپلیکیشن پویا
• CI/CD – یکپارچه سازی مداوم / تست مداوم
• SaaS – نرم افزار به عنوان یک سرویس
• UX – تجربه کاربری
• ETL – استخراج، تبدیل و بارگذاری

موارد استفاده کنید

سه مورد استفاده وجود دارد که این مقاله به شرح زیر پوشش می دهد.

• به روز رسانی نرم افزار فروشنده خودکار در مرکز داده مدیریت شده سازمان
• Webhook – ناسازگاری در روش تأیید
• جاسازی جاوا اسکریپت – دستور نظارت

تصمیمات تاکتیکی

به روز رسانی خودکار نرم افزار از یک فروشنده در مرکز داده تحت مدیریت سازمان

بیان مشکل

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

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

راه حل

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

Webhook: ناسازگاری در روش تأیید

بیان مشکل

این یک سناریوی امنیتی جالب است که ما اغلب به آن برخورد می کنیم. برای استقرار یک هوک، سازمان باید اتصال ورودی از نرم افزار فروشنده را از طریق اینترنت باز کند. از آنجایی که این ترافیک ورودی به مرکز داده سازمان است (on-prem یا cloud)، ترافیک ورودی باید توسط هر جنبه ای از امنیت نرم افزار، مانند حمله DDoS، بار مخرب، و غیره بررسی شود.

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

راه حل

یک راه تاکتیکی برای حل مشکل، اجازه دادن به ترافیک ورودی به لایه پروکسی معکوس سازمان است. لایه پروکسی معکوس که ترافیک را از اینترنت دریافت می کند معمولاً توسط یک لایه حفاظتی DDoS محافظت می شود. لایه پروکسی معکوس می تواند ترافیک ورودی را به لایه سرور سرویس ارسال کند، که منطق تجاری برای رسیدگی به درخواست وب هوک را دارد. لایه سرویس پشتیبان می تواند بارگذاری بار و سایر تأییدهای ترافیک ورودی را بر روی وب کوکی ارائه دهنده بر اساس قوانین تنظیم شده برای مشخصات ارائه دهنده اجرا کند. شکل 3 راه حل تاکتیکی را نشان می دهد.

جاسازی جاوا اسکریپت: اختیار نظارت

بیان مشکل

برخی از راه حل های فروشنده این روزها جعبه ابزار جاوا اسکریپت هستند. اینها معمولاً نرم افزارهای پلت فرم پذیرش دیجیتال (DAP) هستند که برای هدایت کاربران از طریق UX پلت فرم وب به منظور آشنایی آنها با ویژگی های جدید منتشر شده استفاده می شود. فرآیند یکپارچه سازی اغلب نیاز به جاسازی جعبه ابزار جاوا اسکریپت فروشنده در پایگاه کد سازمان دارد. این به دلیل تزریق اسکریپت و انواع دیگر آسیب پذیری های جاوا اسکریپت خطرناک در نظر گرفته می شود.

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

راه حل

در این مورد دو مشکل برای حل وجود دارد:

• بسته جاوا اسکریپت فروشنده را با خیال راحت در پایگاه کد سازمان ادغام کنید
• پیاده سازی یک راه حل برای ارسال ترافیک تجزیه و تحلیل از مرورگر به ارائه دهنده از طریق زیرساخت سازمان

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

نتیجه گیری

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