Руководство по DevOps. Как добиться гибкости, надежности и безопасности мирового уровня в технологических компаниях

Глава 22. Защита информации как часть повседневной работы всех сотрудников компании

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

Когда за информационную безопасность отвечает отдельное подразделение, возникает много проблем. Джеймс Уикетт, один из создателей средства защиты GauntIt и организатор конференции DevOpsDays в Остине и конференции Lonestar Application Security, отмечает:

«Одной из причин появления DevOps называют необходимость повысить производительность разработчиков, потому что с ростом числа разработчиков инженеры эксплуатации перестают справляться с развертываниями. Это ограничение еще сильнее бросается в глаза в информационной безопасности: отношение инженеров разработки, эксплуатации и информационной безопасности в типичной организации — обычно 100:10:1. Когда работников информационной безопасности так мало, без автоматизации и интегрирования защиты информации в повседневную деятельность отделов разработки и эксплуатации их времени будет хватать только на проверку, соответствует ли продукт нормативам и требованиям, что прямо противоположно принципам защиты данных. И, кроме того, из-за этого все нас ненавидят».

Джеймс Уикетт и Джош Кормен, бывший технический директор компании Sonatype и известный исследователь информационной безопасности, писали о встраивании целей защиты информации в DevOps, о наборе методик и принципов под названием прочный DevOps (Rugged DevOps). Похожие идеи, где защита информации встроена во все стадии цикла создания ПО, были разработаны Тапабратой Палом, директором и инженером по разработке платформ банка Capital One, и командой Capital One. Они назвали придуманные ими процессы DevOpsSec. Один из источников идей DevOps — книга Visible Ops Security, ее авторы — Джин Ким, Пол Лав и Джордж Спаффорд.

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

Приглашайте инженеров службы безопасности на презентации промежуточных этапов создания продуктов

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

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

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