Усе, що ви читаєте про інфраструктуру як код (IaC), зосереджено на тому, як вона працює або чому ви хочете переконатися, що вона насправді будується так, як ви хочете.
Це критичні ділянки. Але чи достатньо ми думаємо про те, як ми використовуємо цей підхід у нашій організації?
As Мелінда Маркс ESG зазначає у звіті компанії: «83% організацій відчули збільшення кількості неправильних конфігурацій шаблонів IaC», оскільки вони продовжують застосовувати цю технологію.
Ми знаємо з роботи, виконаної Cloud Security Alliance ("Основні загрози хмарним обчисленням: неймовірна одинадцять“) та інші, неправильні конфігурації залишаються головним ризиком у хмарі.
IaC підтримується зменшити
неправильні конфігурації шляхом систематизації створення інфраструктури, додавання рівня суворості та процесу, який гарантує, що команди будують те, що вони хочуть, і лише те, що вони хочуть. Якщо приблизно 83% команд цього не бачать, проблема глибша.
У невеликих командах, де елементи Dev і Ops філософії DevOps разом, це має сенс. IaC дозволяє цим невеликим командам використовувати одну мову — код — для опису всього, що вони роблять.
Ось чому ми бачимо абстракції навіть більш високого рівня, ніж такі інструменти, як Terraform або AWS CloudFormation AWS CDK і такі проекти cdk8s. Ці високорівневі абстракції більш зручні для розробників.
Перспектива операцій/SRE/платформи хмарної служби буде сильно відрізнятися від точки зору розробника тієї самої служби. Розробник подивиться на службу масового обслуговування та зануриться в її інтерфейс — просту кінцеву точку для додавання та одну для читання? Продано. Це проста інтеграція.
Ця операційна перспектива має на меті знайти грані. Отже, коли ця черга досягне своєї межі? Продуктивність постійна чи радикально змінюється під навантаженням?
Так, існують проблеми, що збігаються. І так, це спрощений погляд. Але ідея тримається. IaC вирішує багато проблем, але він також може створити та посилити розрив між командами. Що ще важливіше, це може підкреслити розрив між наміром того, що ви намагаєтеся побудувати, та реальністю того, що ви побудували.
Як наслідок, саме тут часто загострюються проблеми безпеки.
Більшість інструментів — комерційних або з відкритим вихідним кодом — зосереджені на виявленні несправностей у шаблонах інфраструктури. це
це хороша конструкція. виготовлення це
було б погано. Ці інструменти спрямовані на отримання цих результатів у рамках конвеєра безперервної інтеграції/безперервної доставки (CI/CD).
Це чудовий початок. Але це відлуння тієї ж мовної проблеми.
Хто говорить і хто слухає?
Коли інструмент IaC висвітлює проблему, хто її вирішить? Якщо це команда розробників, чи має вона достатньо інформації, щоб знати, чому це було позначено як проблему? Якщо це оперативна група, чи наслідки проблеми викладено у звіті?
З розробниками часто трапляється, що вони просто налаштовують конфігурацію, щоб тестування IAC пройшло.
Для операцій, як правило, питання про проходження тестів. Якщо вони є, то переходьте до наступного завдання. Це не стукіт для жодної команди; скоріше, це підкреслює розрив між очікуваннями та реальністю.
Потрібен контекст. Інструмент безпеки IaC забезпечує видимість того, що (сподіваємось) збирається створити. Мета – зупинити проблеми перед тим вони надходять у виробництво.
Сучасні інструменти безпеки IAC висвітлюють реальні проблеми, які необхідно вирішити. Отримання результатів цих інструментів і збагачення його додатковим контекстом, який є специфічним для команди, відповідальної за код, є ідеальною можливістю для певної індивідуальної автоматизації.
Це також допоможе подолати мовну прірву. Вихідні дані з вашого інструментарію по суті є третьою мовою — просто для того, щоб зробити речі складнішими — і повинні бути передані таким чином, щоб це було зрозуміло для розробників або операційної аудиторії. Часто обидва.
Наприклад, коли сканування позначає, що правило групи безпеки не має опису, чому це має значення? Просто отримання сповіщення з написом «Додайте опис для контексту» не допоможе нікому побудувати краще.
Цей тип прапора є чудовою нагодою для навчання команд, які будують у хмарі. Додавання пояснення про те, що правила групи безпеки мають бути якомога точнішими, зменшує ймовірність зловмисних атак. Наведіть посилання на приклади сильних правил. Викличте це, не знаючи про намір, і інші команди не зможуть перевірити дійсність підтвердження безпеки.
Безпека — це відповідальність кожного, тому визнання мовної різниці між розробниками та операторами висвітлить такі можливості, як ця, щоб додати просту автоматизацію, яка надасть уявлення вашим командам. Це допоможе покращити те, що вони будують, і, як наслідок, покращить результати безпеки.
Про автора
.jpg?width=690&quality=80&format=webply&disable=upscale "Сканування IAC: фантастична можливість навчання, яку не помічають")
Я криміналіст, спікер і технологічний аналітик, який намагається допомогти вам зрозуміти цифровий світ і його вплив на нас. Звичайним користувачам моя робота допомагає пояснити виклики цифрового світу. Наскільки великий вплив має використання соціальних мереж на вашу конфіденційність? Що це означає, коли такі технології, як розпізнавання обличчя, починають використовуватися в наших громадах? Я допомагаю відповідати на такі та інші запитання. Для людей, які розробляють технології, я допомагаю їм застосовувати лінзу безпеки та конфіденційності у своїй роботі, щоб вони могли дозволити користувачам приймати чіткіші рішення щодо їх інформації та поведінки. Коли йдеться про конфіденційність і безпеку, існує багато плутанини. Не повинно бути. Я роблю безпеку та конфіденційність легшими для розуміння.
