Всього до 2025 р створення глобальних даних досягне 181 зетабайт. Для підприємств ці дані є активом, що дозволяє їм використовувати різноманітні технологічні платформи для створення високоперсоналізованого досвіду клієнтів, що створює лояльність і залучає нових клієнтів. Однак цей досвід залежить від хмарних інфраструктур, які використовують спільні режими безпеки. Ось у чому криється ризик, і він зростає, оскільки технологія розвивається, щоб включити нову армію громадянських розробників, які використовують платформи з низьким і безкодовим кодом.
Розуміння та подолання мислення про успадкування
Gartner за оцінками, до 2025 року 70% корпоративних додатків створюватимуться на платформах з низьким і без коду, таких як Salesforce і ServiceNow. Реагування на основі принципу успадкування — це вірний спосіб підготувати понад дві третини корпоративних програм до відмови.
«Мислення про успадкування» є вдалим описом проблем, які заважають інфраструктурі. Це нагадує про багатих, розпещених дітей, які повністю залежать від виконаної роботи та людей, які були до них. Це поганий спосіб створення спадщини, і це настільки ж поганий спосіб створення системи.
Коли у вас є застаріле мислення, ви припускаєте, що інфраструктура налаштована. Платформа є безпечною, а безпека вбудована. Довіра передбачається просто тому, що технологія була там до адміністратора.
Такий спосіб успадкування шкодить платформам із низьким кодом і без нього. Користувачі покладаються на безпеку платформи, щоб перенести їх через всю інфраструктуру підприємства. Натомість безпека цієї платформи має застосовуватися лише до неї.
Скажімо, розробники Salesforce створюють автоматичну програму призначення для нових потенційних клієнтів. Вони використовують його в Salesforce для внутрішніх завдань, і це добре. Вони можуть покладатися на безпеку платформи. Вони вирішують розширити його, щоб покращити автоматизацію. Вони підключають цю програму до зовнішньої CRM, наприклад ServiceNow, SAP або Oracle. Наслідування бере верх: Salesforce безпечний. ServiceNow, SAP або третя сторона безпечні.
Отже, Salesforce + третя сторона = безпечно.
Але в цьому плюсику є багато невідомого. Як безпечно та сумісно підключити внутрішню програму, створену в Salesforce, до зовнішньої програми, створеної на сторонній платформі? У цьому єдиному символі є багато можливостей для помилок.
І це лише один зв’язок. Багато програм, створених у Salesforce, стосуються сотень інших. Це сотні невідомих, які розглядаються як знак «плюс», описаний вище, людьми, які не мають практично жодного досвіду розробки.
Єдине рішення — повернути цю розробку на землю, повернувшись до принципів DevSecOps.
Створення DevSecOps Framework
DevSecOps рамки були написані, переписані та написані знову з моменту створення концепції. Немає потреби винаходити колесо, створюючи їх, особливо коли SAFECode і Cloud Security Alliance побудував шість стовпів:
- Колективна відповідальність: Безпека — це відповідальність кожної особи на підприємстві, але люди не можуть відповідати стандартам, яких вони не знають. Необхідно призначити керівників, які керуватимуть політикою кібербезпеки та забезпечують її поширення на підприємстві.
- Співпраця та інтеграція: Знаннями потрібно ділитися і передавати. Половина причини того, що підприємства впадають у застаріле мислення, полягає в тому, що всі, хто знав стару систему, пішли. Постійний обмін знаннями допомагає усунути цю проблему.
- Прагматична реалізація: Прагматичне впровадження пов’язане з досвідом розробника. Процеси, які є важкими, буденними та громіздкими, не відбуваються довго. Безпека має бути включена в практику розробки — тобто кожен рядок коду потребує рядка тесту. Високоефективне підприємство пішло б далі, використовуючи інструмент для автоматизації кожного рядка тестового коду.
- Відповідність і розвиток: Вимоги до відповідності повинні керувати процесом розробки таким чином, щоб розробники не могли відхилятися від них. Розробник для фінансової установи, наприклад, працюватиме на платформі, яка розроблена відповідно до Закону Грамма-Ліча-Блайлі. Розробнику не обов’язково знати окремі тонкощі дії, щоб відповідати вимогам, оскільки вони вбудовані в платформу.
- Автоматизація: Завдання, які є передбачуваними, повторюваними та великими, слід автоматизувати, коли це можливо, щоб зняти навантаження з розробників і зменшити ризик людської помилки.
- Монітор: Сучасні хмарні інфраструктури змінюються та розвиваються. Важливо відстежувати це — в ідеалі, за допомогою певної форми оркестровки, яка дозволяє з першого погляду побачити всі різноманітні взаємозв’язки.
В низький або без коду середовища, ці стовпи не такі прості, як можна було б очікувати. Люди, які використовують ці інструменти, часто є бізнес-експертами, які мало знайомі з основами DevSecOps.
Об’єднання людей, процесів і технологій
Використання платформ з низьким кодом і без коду насправді може допомогти усунути цю прогалину в навичках. Співробітники хочуть отримати нові навички. Підприємства можуть підтримати це, створивши структуру DevSecOps, зосереджену на людях, процесах і технологіях.
- Процеси: У середовищі нульової довіри розробникам із низьким або нульовим кодом не потрібно турбуватися про встановлення з’єднань, які загрожують цілісності системи, оскільки вони нездатні це зробити. Вони не мають базових повноважень за межами своєї ізольованої системи.
- People: Культура відповідальності відрізняється від культури звинувачення. Підзвітність означає, що люди відчувають себе комфортно, повідомляючи про проблему чи помилку, оскільки в центрі уваги проблема, а не особа.
- Технології: Технологія є найбільшою перешкодою для належного впровадження принципів DevSecOps, оскільки вона не в руках розробників. Вони повинні використовувати те, що їм надає організація. Якщо ця технологія не працює, розробники знайдуть обхідні шляхи, які не є ні безпечними, ні безпечними. По суті, технологія стає одним великим тіньовим ІТ-генератором.
Ми живемо у захоплюючий час для розвитку. Все більше і більше людей мають можливість створювати програмне забезпечення, тестувати стратегії та підвищувати вартість бізнесу. Але з цим пов’язаний ризик. Підприємства, які шукають способи перекласти цей ризик на технології, залишатимуть свій розвиток на землі, залишаючи простір для досліджень.
