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

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

В эпоху Kubernetes и развертывания облачных приложений инженер по безопасности инфраструктуры — это награда. Но из десятков описаний вакансий и интервью с практиками мы обнаружили, что эта роль отражает чрезвычайно сложную задачу: быть лучшим как в косвенном влиянии, так и в сложных технических навыках.

Так что же такое проектирование безопасности инфраструктуры? Группа безопасности инфраструктуры или облачных вычислений находится (что неудивительно) на уровне инфраструктуры, а не на уровне приложений. В первую очередь они связаны с развертыванием и работающей облачной средой.

Первое, что нужно понять об этой роли, это насколько модель совместной ответственности за облачную безопасность требует от них. В случае управляемые платформы Kubernetes, мы можем принять общую модель PaaS. Это подразумевает модель совместной ответственности, которая ставит почти вся конфигурация облака в руках роли безопасности инфраструктуры. По словам Google, «в GKE вы несете ответственность за защиту своих рабочих узлов, включая развертывание исправлений для ОС, среды выполнения и компонентов Kubernetes, и, конечно же, за безопасность собственной рабочей нагрузки».

Но модель общей ответственности — это только начало. Ни одна роль не существует в вакууме, и третьим наиболее распространенным требованием к этой роли, помимо управления уязвимостями и обновления тенденций в этой области, является распространение лучших практик среди других команд в организации. Как выразился один менеджер по найму: «Ваша основная ответственность будет заключаться в том, чтобы наши инженерные команды интегрировали лучшие практики безопасности в свои рабочие процессы и предоставляли безопасные продукты и услуги».

Существует неотъемлемое трение в том, чтобы просить команду разработчиков сделать что-либо, что может замедлить поток новых функций в рабочую среду, даже если было показано, что команды внедряя безопасность в свои процессы DevOps на самом деле доставить быстрее.

Что нужно инженерам по безопасности инфраструктуры для достижения успеха

Что, по мнению менеджеров по найму, поможет кандидатам добиться успеха в только что описанной роли? Неудивительно, что третьим наиболее распространенным требованием для этой роли — после практического опыта работы с облачными платформами и сетями — является владение языками сценариев в сочетании с практическим опытом работы в любой комбинации. IaC, Terraform и конвейер CI/CD. Почему? Потому что, если вы никогда не автоматизировали развертывание с помощью кода, будет невозможно поделиться лучшими практиками безопасности с разработчиками, которые делают это ежедневно.

Последним общим требованием к роли безопасности инфраструктуры является глубокое понимание сквозного конвейера разработки. Если инженер по безопасности рассчитывает быть в курсе последних событий в облаке, влиять на разработку и ежедневно управлять облачными уязвимостями, ему необходимо понимать эффективность, то, как все это работает вместе, и как расставлять приоритеты. .

Вот еще несколько советов от наших собеседников:

• «Если вы просто смотрите на облако, не забывайте о Kubernetes. Хотя в наши дни он чаще всего развертывается через управляемые облачные сервисы, с ним нельзя бороться так же, как с уязвимостями облачных сред». — Директор по облачной безопасности
• «Сортировка имеет решающее значение. Когда мои команды терпели неудачу в прошлом, обычно это происходило из-за того, что мы продолжали гоняться за блестящими вещами. Будучи дисциплинированными и методичными в расстановке приоритетов, мы сохраняем уверенность в том, что решаем правильные проблемы в (почти) любой момент времени». — Менеджер, инфраструктура и ИТ-безопасность
• «Не стоит недооценивать интерес инженерных групп к решению проблем безопасности. Предоставьте им данные и контекст и посмотрите, насколько они хотят их использовать». — Менеджер, инфраструктура и ИТ-безопасность

Почему это может быть самой сложной работой

Интересно, что в нашем исследовании только в одной должностной инструкции была строка «проверки безопасности», где роль позволяла команде безопасности сказать «да» или «нет» изменениям в разработке. Это показательно в контексте других наблюдений о роли прямого и косвенного влияния на проектирование и разработку; например, знание ИаК нужно не для непосредственного использования, а для того, чтобы рассказать другим, как его использовать.

Кроме того, общение и наставничество не были перечислены среди наиболее распространенных требований к работе, но половина должностей по-прежнему возлагала большие надежды на этот мягкий навык. Особенно это касалось более высоких должностей.

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

• SEO-контент и PR-распределение. Получите усиление сегодня.
• ЭВМ Финанс. Единый интерфейс для децентрализованных финансов. Доступ здесь.
• Квантум Медиа Групп. ИК/PR усиление. Доступ здесь.
• ПлатонАйСтрим. Анализ данных Web3. Расширение знаний. Доступ здесь.
• Источник: https://www.darkreading.com/edge/the-infrastructure-security-engineer-is-a-unicorn-among-thoroughbreds