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

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

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

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

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

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

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

• библиотеки и рекомендуемые конфигурации (например, 2FA (двухфакторная аутентификация), хэширование паролей bcrypt, логирование);

• управление секретной информацией (например, настройки соединения, ключи шифрования) с помощью таких инструментов, как Vault, sneaker, Keywhiz, credstash, Trousseau, Red October и так далее;

• пакеты и сборки операционных систем (например, NTP для синхронизирования времени, безопасные версии OpenSSL с правильными конфигурациями, OSSEC или Tripwire для слежения за целостностью файлов, конфигурации syslog для логирования важных параметров безопасности в стек ELK).

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

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

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