Джин Ким - Руководство по DevOps

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

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

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

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

Это упростило выполнение бизнес-целей организации. Снехал Антани, бывший директор по информационным технологиям подразделения Enterprise Architecture компании GE Capital Americas, говорил, что у них тремя ключевыми показателями были «скорость разработки (то есть скорость вывода на рынок новых продуктов и элементов функциональности), неудачи в работе с клиентами (то есть сбои и ошибки) и время на выполнение запроса о соответствии нормам (то есть время от запроса аудиторов до предоставления всей количественной и качественной информации для удовлетворения запроса)».

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

Если есть возможность, стоит отслеживать все проблемы с защитой данных в той же системе учета, которая используется в разработке и эксплуатации. Такой подход очень отличается от традиционного подхода службы безопасности, где все уязвимые места хранятся в инструменте GRC (governance, risk, compliance — управление, риск, соответствие требованиям), а доступ к нему есть только у отдела безопасности. Вместо этого будем помещать все задачи по защите данных в системы, используемые разработкой и эксплуатацией.

В презентации 2012 г. на конференции DevOpsDays в Остине Ник Галбрет, на протяжении многих лет возглавлявший отдел информационной безопасности в Etsy, так описывает свой подход к проблемам защиты: «Все задачи по защите данных мы создавали в JIRA. Ею все инженеры пользуются каждый день, и их приоритет был либо “P1”, либо “P2” — то есть они должны были быть исправлены сразу же или к концу недели, даже если проблема была во внутреннем приложении организации».

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

В главе 20мы создали хранилище кода, доступное всей организации. В нем все могут легко найти накопленные знания организации: не только о коде, но и о наборах инструментов, о конвейере развертывания, стандартах и т. д. Благодаря этому все сотрудники могут извлечь пользу из опыта своих коллег.

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

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

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

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