На начальных стадиях внедрения облачных сервисов по методу DevOps обычно возникают разногласия между специалистами, отвечающими за безопасность и разработку. Могут пройти месяцы и даже годы, прежде чем процессы обеспечения безопасности будут полностью интегрированы в ускоренные циклы разработки. Но ждать так долго на предприятии не могут. Каково же решение? DevSecOps – набор практик, позволяющих быстро ввести в курс дела специалистов по безопасности и внедрить новые механизмы защиты облачных сервисов.
На предприятиях уже разрабатывают инструменты и процессы, с которыми нужно будет разобраться отделу безопасности. Дадим пять советов, помогающих объединить DevOps с процессами обеспечения безопасности.
1. Определите источник трудностей. Когда процессы DevOps ограничены одним бизнес-подразделением или отделом, придерживаться практик безопасности довольно просто. Проблема возникает, если от отдела безопасности, в котором еще не сталкивались с DevOps, требуют разработать новые общекорпоративные процессы и стандартизировать методологии безопасности.
Вот что обычно происходит, когда старые процессы безопасности применяются в командах DevOps: центральный отдел безопасности разрабатывает документацию для облака и вмешивается на каких-либо этапах спринта (обычно на стадии тестирования), вручную удостоверяясь в том, что конфигурации облачных ресурсов отвечают спецификациям. При этом проходят целые недели от идентификации очередной уязвимости в облачном сервисе до документирования и внесения исправлений – тем самым создаются задержки в разработке.
Легко видеть, что источник сложностей – ручное выполнение задач безопасности. Когда в эксплуатационном отделе вручную настраивают системы и сети, появляется вероятность ошибок, а значит, требуется ручная проверка. Если специалисты по безопасности обнаруживают проблему, они должны вручную задокументировать решение, которое вручную устанавливается на каждую виртуальную машину в среде. В результате на это уходят часы работы.
2. Подключайте специалистов по безопасности к процессам DevOps на ранних этапах. Когда в отделе безопасности определились с источником трудностей или уже ощутили последствия своей медлительности, следующим шагом должно стать обучение. Специалистов по безопасности надо знакомить с технологиями и методами DevOps, а затем – с инструментами облачной разработки и развертывания.
«Просветление» наступает, когда в отделе безопасности выясняют, что инструменты DevOps, например средства конфигурационного управления, можно использовать для улучшения руководства. В сущности, инструменты конфигурационного управления вроде Puppet и Chef до применения их при автоматизации конвейеров разработки использовались специалистами по безопасности для конфигурирования и подтверждения настроек безопасности на серверах. Специалисты по безопасности обычно охотно начинают пользоваться декларативными языками конфигурирования, поскольку те позволяют разработать новые эффективные решения их повседневных задач.
3. Организуйте централизованное обеспечение безопасности. Когда специалисты по безопасности видят, какие оптимизационные возможности в решении их повседневных задач дает DevOps, сопротивление обычно сходит на нет. На этом этапе они начинают разрабатывать более зрелые практики, отвечающие концепции «безопасности как кода» (security-as-code).
Что такое security-as-code? Некоторые аспекты безопасности, например конфигурация сети и политики доступа, могут и должны быть реализованы в форме модульных скриптовых шаблонов, доступных для многократного использования с помощью инструментов вроде AWS CloudFormation или Troposphere в сочетании со средствами конфигурационного управления наподобие Puppet, Chef или Ansible. Эти инструменты позволяют «жестко закодировать» лучшие практики безопасности в каждой сборке, вместо того чтобы применять их постфактум. Перенеся тестирование и аудит безопасности «ближе» к коду, специалисты по безопасности могут работать результативнее, и затраты на устранение ошибок снижаются.
4. Берегите время специалистов по безопасности. После того как специалисты по безопасности вместе с сотрудниками, отвечающими за эксплуатацию, внесли практики безопасности в шаблоны, первым уже не придется проводить ревизию каждой новой среды. Ведь шаблоны хранятся в центральном репозитории и автоматически применяются с каждой новой средой, а любые изменения необходимо проверять как новую ветвь кода и передавать на утверждение. Специалистам по безопасности достаточно проверить изменения в единственном шаблоне – нет нужды проводить ревизию и тестировать тысячи виртуальных машин, созданных с использованием шаблонов.
Каков результат? Вы объявили «вне закона» ручное конфигурирование и существенно снизили риск того, что инженер по эксплуатации совершит неучтенную ошибку (например, забудет применить важную настройку безопасности). К тому же вы переориентировали отдел безопасности с ручной скучной, малопродуктивной работы на то, что действительно важно.
5. Взламывайте собственное программное обеспечение. После внедрения принципов security-as-code остается еще один важный элемент DevSecOps – не доверять защите. Единственный способ обнаружить бреши – это непрерывное тестирование.
Из ИТ-специалистов нужно сформировать команду «условного противника», который должен пытаться проникнуть в вашу среду методами социальной инженерии и грубой силы. Заодно это поможет специалистам по безопасности убедить разработчиков и инженеров принимать меры немедленно (поскольку факт взлома для любой команды DevOps будет позорным).
Популярность DevSecOps растет не без причины: это единственная четкая методология, касающаяся безопасности облачных корпоративных систем, которые разрабатываются по принципу DevOps. На каком бы этапе ни начинали внедрять DevSecOps (во время планирования перехода в облако или после того, как взаимодействие между отделами безопасности и DevOps уже налажено), такая эволюция будет важнейшим шагом к обеспечению защищенности облачных ресурсов.
– Jason McKay. How to use DevSecOps to smooth cloud deployment. Network World. March 8, 2016