تا سال 2025، مجموع ایجاد داده های جهانی به 181 زتابایت خواهد رسید. برای شرکت‌ها، این داده‌ها یک دارایی است که به آنها اجازه می‌دهد تا از انواع پلتفرمهای فناوری برای ایجاد تجربیات مشتری بسیار شخصی‌سازی‌شده استفاده کنند که باعث وفاداری و جذب کسب‌وکار جدید می‌شود. با این حال، این تجربیات وابسته به زیرساخت های ابری با استفاده از حالت های امنیتی مشترک است. این همان جایی است که خطر نهفته است و با رشد فناوری برای ترکیب ارتش جدیدی از توسعه دهندگان شهروندی که از پلتفرمهای کم‌کد و بدون کد استفاده می‌کنند، افزایش می‌یابد.
درک و غلبه بر ذهنیت ارثی
گارتنر تخمین می‌زند که تا سال 2025، 70 درصد برنامه‌های کاربردی سازمانی از پلتفرمهای کم‌کد و بدون کد مانند Salesforce و ServiceNow ساخته می‌شوند. پاسخگویی با طرز فکر مبتنی بر وراثت راهی مطمئن برای تنظیم بیش از دو سوم برنامه های سازمانی برای شکست است.
"ذهن وراثت" توصیف مناسبی برای مشکلات زیرساختی است. این یک بچه ثروتمند و لوس را به یاد می آورد که کاملاً به کار انجام شده و افرادی که قبل از آنها آمده اند وابسته هستند. این راه خوبی برای ساختن میراث نیست، و به همان اندازه راه بدی برای ساختن یک سیستم است.
هنگامی که شما یک ذهنیت میراثی دارید، فرض می کنید که زیرساخت تنظیم شده است. پلتفرم امن است، و امنیت در آن تعبیه شده است. اعتماد صرفاً به این دلیل فرض می شود که این فناوری قبل از مدیر وجود داشته است.
این طرز فکر وراثت پلتفرمهای کم‌کد و بدون کد را آزار می‌دهد. کاربران برای انتقال آنها از طریق کل زیرساخت سازمانی به ایمنی یک پلت فرم متکی هستند. در عوض، امنیت آن پلتفرم باید فقط برای آن پلتفرم اعمال شود.
فرض کنید توسعه دهندگان Salesforce یک برنامه انتساب خودکار برای سرنخ های جدید ایجاد می کنند. آنها از آن در Salesforce برای تکالیف داخلی استفاده می کنند، و خوب است. آنها می توانند بر ایمنی پلت فرم تکیه کنند. آنها تصمیم می گیرند آن را برای بهبود اتوماسیون گسترش دهند. آنها آن برنامه را به یک CRM خارجی مانند ServiceNow، SAP یا Oracle متصل می کنند. طرز فکر وراثت غلبه می کند: Salesforce امن است. ServiceNow، SAP یا شخص ثالث ایمن است.
بنابراین، Salesforce + شخص ثالث = امن.
اما، مقدار زیادی ناشناخته در آن علامت مثبت وجود دارد. چگونه برنامه داخلی ایجاد شده در Salesforce را به طور ایمن و مطابق با برنامه خارجی ایجاد شده در پلت فرم شخص ثالث متصل می کنید؟ در آن شخصیت مجرد جای زیادی برای خطا وجود دارد.
و این تنها یک ارتباط است. بسیاری از برنامه های ایجاد شده در Salesforce صدها برنامه دیگر را لمس می کنند. این صدها ناشناخته است که توسط افرادی که تجربه توسعه کمی دارند یا اصلاً تجربه ندارند مانند علامت مثبت توصیف شده در بالا رفتار می کنند.
تنها راه حل این است که آن توسعه را با بازگشت به اصول DevSecOps به زمین بازگردانیم.
ایجاد چارچوب DevSecOps
DevSecOps چارچوب ها از زمان ایجاد مفهوم نوشته شده، بازنویسی و دوباره نوشته شده اند. نیازی به اختراع مجدد چرخ هنگام استقرار آنها نیست، به خصوص زمانی که SAFECode و Cloud Security Alliance شش ستون ساخته است:
- مسئولیت جمعی: امنیت مسئولیت هر فرد در شرکت است - اما افراد نمی توانند استانداردهایی را که نمی دانند رعایت کنند. سرنخ ها باید برای هدایت خط مشی امنیت سایبری و اطمینان از انتشار آن در سراسر شرکت اختصاص داده شوند.
- همکاری و ادغام: دانش باید به اشتراک گذاشته و منتقل شود. نیمی از دلیلی که شرکت ها در ذهنیت میراثی قرار می گیرند این است که همه کسانی که سیستم قدیمی را می شناختند از بین رفته اند. به اشتراک گذاری مداوم دانش به رفع این مشکل کمک می کند.
- اجرای عملی: پیاده سازی عملی با تجربه توسعه دهنده پیوند دارد. فرآیندهایی که دشوار، پیش پا افتاده و سخت هستند برای مدت طولانی دنبال نمی شوند. امنیت باید در شیوه‌های توسعه گنجانده شود – یعنی هر خط کد به یک خط آزمایش نیاز دارد. یک شرکت با عملکرد بالا با استفاده از ابزاری برای خودکار کردن هر خط کد آزمایشی، این کار را بیشتر انجام می دهد.
- انطباق و توسعه: الزامات انطباق باید فرآیند توسعه را به گونه ای هدایت کند که به توسعه دهندگان اجازه انحراف از آنها را ندهد. برای مثال، یک توسعه‌دهنده برای یک موسسه مالی، روی پلتفرمی کار می‌کند که مطابق با قانون Gramm-Leach-Bliley طراحی شده است. توسعه‌دهنده نیازی به دانستن نکات و نکات تک تک این عمل ندارد زیرا آنها در پلتفرم تعبیه شده‌اند.
- اتوماسیون: کارهایی که قابل پیش بینی، تکرارپذیر و حجم بالا هستند باید تا حد امکان خودکار شوند تا بار از دوش توسعه دهندگان برداشته شود و خطر خطای انسانی کاهش یابد.
- مانیتور: زیرساخت های ابری مدرن تغییر می کنند و رشد می کنند. پیگیری آن بسیار حیاتی است - در حالت ایده آل، از طریق نوعی ارکستراسیون که امکان مشاهده یک نگاه از تمام اتصالات مختلف را فراهم می کند.
در یک کم یا بدون کد محیط زیست، این ستون ها آنطور که انتظار می رود ساده نیستند. افرادی که از این ابزارها استفاده می کنند اغلب متخصصان کسب و کار هستند که آشنایی کمی با اصول DevSecOps دارند.
گرد هم آوردن افراد، فرآیندها و فناوری
استفاده از پلتفرمهای کم‌کد و بدون کد در واقع می‌تواند به رفع این شکاف مهارتی کمک کند. کارمندان می خواهند مهارت های جدیدی بیاموزند. شرکت ها می توانند با ایجاد یک چارچوب DevSecOps با تمرکز بر افراد، فرآیندها و فناوری از آن پشتیبانی کنند.
- فرآیندها: در یک محیط بدون اعتماد، توسعه دهندگان با کد پایین و بدون کد نیازی به نگرانی در مورد ایجاد اتصالاتی ندارند که یکپارچگی سیستم را به خطر می اندازد، زیرا آنها قادر به انجام این کار نیستند. آنها خارج از سیستم منزوی خود هیچ اختیار پایه ای ندارند.
- مردم: فرهنگ پاسخگویی با فرهنگ سرزنش متفاوت است. مسئولیت پذیری به این معنی است که افراد احساس راحتی می کنند که با یک مشکل یا اشتباه روبرو می شوند، زیرا تمرکز بر روی موضوع است، نه شخص.
- فن آوری: فناوری تنها بزرگترین مانع برای اجرای صحیح اصول DevSecOps است زیرا از دست توسعه دهندگان خارج است. آنها باید از آنچه سازمان به آنها می دهد استفاده کنند. اگر آن فناوری کار نکند، توسعه‌دهندگان راه‌حل‌هایی را ارائه خواهند کرد که نه ایمن هستند و نه ایمن. اساساً، این فناوری به یک مولد سایه بزرگ فناوری اطلاعات تبدیل می شود.
ما در یک زمان هیجان انگیز برای توسعه زندگی می کنیم. افراد بیشتر و بیشتری فرصت ایجاد نرم افزار، آزمایش استراتژی ها و بهبود ارزش کسب و کار را دارند. اما با آن خطر نیز همراه است. شرکت‌هایی که به دنبال راه‌هایی برای تخلیه این خطر بر روی فناوری هستند، توسعه خود را ثابت نگه می‌دارند و در عین حال فضایی برای کاوش باقی می‌گذارند.
