Інженер з безпеки інфраструктури — єдиноріг серед чистокровних

Команда нещодавнього заходу, присвяченого хмарній індустрії, голосно розсміялася, сказавши нам: «Ми щойно закінчили розмову, і, очевидно, тепер ми інженери з безпеки інфраструктури». У зв’язку з нестримними звільненнями в технологічній індустрії в основі розваги про посади лежить справжня невизначеність щодо очікувань процвітання в цій новій ролі та пов’язаній з нею екосистемі.

В епоху Kubernetes і розгортання власних хмарних додатків найняти інженера з безпеки інфраструктури – це приз. Але з огляду на десятки посадових інструкцій та інтерв’ю з фахівцями ми виявили, що ця посада відображає надзвичайно складний виклик: бути найкращим як у непрямому впливі, так і в складних технічних навичках.

Отже, що таке інженерія безпеки інфраструктури? Команда інфраструктури або хмарної безпеки сидить (не дивно) на рівні інфраструктури, а не на рівні додатків. Вони в першу чергу стурбовані розгортанням і робочим хмарним середовищем.

Перше, що потрібно зрозуміти про цю роль, це скільки хмарна модель спільної відповідальності вимагає від них. У випадку керовані платформи Kubernetes, ми можемо припустити загальну модель PaaS. Це передбачає модель спільної відповідальності, яка ставить майже вся конфігурація хмари в руках відповідального за безпеку інфраструктури. Власними словами Google: «Для GKE ви несете відповідальність за захист своїх робочих вузлів, зокрема за розгортання патчів для ОС, середовища виконання та компонентів Kubernetes, і, звичайно, за захист вашого власного робочого навантаження».

Але модель спільної відповідальності – це лише початок. Жодна роль не існує у вакуумі, і третьою найпоширенішою вимогою в цій ролі, окрім управління вразливістю та постійного інформування про тенденції в просторі, є впровадження найкращих практик серед інших команд в організації. Як сказав один менеджер з найму: «Ваш основний обов’язок полягатиме в тому, щоб наші інженерні команди інтегрували найкращі методи безпеки у свої робочі процеси та постачали безпечні продукти та послуги».

Вимагати від команди розробників зробити щось, що може уповільнити потік нових функцій у виробництво, викликає невід’ємне тертя, навіть якщо було показано, що команди забезпечуючи безпеку своїх процесів DevOps насправді доставляють швидше.

Що потрібно інженерам з безпеки інфраструктури, щоб досягти успіху

Що, на думку менеджерів з найму, зробить кандидатів успішними на щойно описаній посаді? Не дивно, що третьою найпоширенішою вимогою для цієї посади (за практичним досвідом роботи з хмарними платформами та мережами) є знання мов сценаріїв у поєднанні з практичним досвідом будь-якої комбінації IaC, Terraform і конвеєр CI/CD. чому Тому що, якщо ви ніколи не автоматизували розгортання за допомогою коду, буде неможливо поділитися передовими методами безпеки з розробниками, які роблять це щодня.

Останньою загальною вимогою до ролі безпеки інфраструктури є глибоке розуміння наскрізного конвеєра розробки. Якщо інженер безпеки очікує бути в курсі останніх технологій хмари, впливати на розробку та щоденно керувати вразливими місцями хмари, йому потрібно розуміти ефективність, як усе це працює разом і як розставляти пріоритети .

Ось ще кілька порад від наших співбесідників:

• «Якщо ви просто дивитеся на хмару, не забувайте про Kubernetes. Незважаючи на те, що в наші дні його розгортають через керовані хмарні служби, його неможливо вирішити так само, як уразливі місця в хмарних середовищах». — Директор з хмарної безпеки
• «Сортування є критичним. Коли мої команди зазнавали невдач у минулому, зазвичай це було тому, що ми продовжували переслідувати блискучі речі. Завдяки дисциплінованості та методичності у визначенні пріоритетів ми зберігаємо впевненість, що вирішуємо правильні проблеми в (майже) будь-який час». — Менеджер, інфраструктура та ІТ-безпека
• «Не варто недооцінювати інтерес команд інженерів до вирішення проблем безпеки. Додайте їм дані та контекст і подивіться, наскільки вони прагнуть цим скористатися». — Менеджер, інфраструктура та ІТ-безпека

Чому це може бути найважча робота

Цікаво, що в нашому дослідженні лише одна посадова інструкція містила пункт «перевірки безпеки», де ця роль дозволяла команді безпеки сказати «так» або «ні» змінам у розробці. Це показово в контексті інших спостережень щодо ролі прямого чи непрямого впливу на інженерію та розвиток; наприклад, знання IaC потрібні не для того, щоб використовувати їх безпосередньо, а для того, щоб мати можливість розповісти іншим, як ними користуватися.

Крім того, комунікація та наставництво не були перераховані серед найпоширеніших умов роботи, але половина ролей все ще мала високі очікування щодо цієї м’якої навички. Особливо це стосувалося вищих посад.

Між вимогою впливати на команди розробників, необхідними знаннями інструментів і автоматизації IAC, потребою в спілкуванні та наставництві та майже повною відсутністю формальних перевірок безпеки, починає формуватися погляд на найуспішнішого професіонала з безпеки інфраструктури. Ця особа матиме великий практичний досвід роботи в хмарній екосистемі, а також навички впливу та підвищення довіри серед кваліфікованих команд, які щодня керують надзвичайно новими, передовими інструментами GitOps. Це справді висока планка!

• Розповсюдження контенту та PR на основі SEO. Отримайте посилення сьогодні.
• EVM Фінанси. Уніфікований інтерфейс для децентралізованих фінансів. Доступ тут.
• Quantum Media Group. ІЧ/ПР посилений. Доступ тут.
• PlatoAiStream. Web3 Data Intelligence. Розширення знань. Доступ тут.
• джерело: https://www.darkreading.com/edge/the-infrastructure-security-engineer-is-a-unicorn-among-thoroughbreds