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

Практический пример

Стандарты безопасности PCI и поучительная история о разделении обязанностей в компании Etsy (2014 г.)

[173]

Билл Мэсси работает руководителем разработки в компании Etsy и отвечает за приложение оплаты под названием ICHT (аббревиатура от I Can Haz Tokens[174]). ICHT проводит заказы клиентов через набор внутренних приложений обработки платежей: они принимают онлайн-заказ, выделяют информацию о платежной карте клиента, маркируют ее, отсылают платежной системе и завершают транзакцию[175].

Поскольку в предметную область среды CDE[176] входят «люди, процессы и технологии, хранящие, обрабатывающие и передающие данные владельцев платежных карт или конфиденциальную аутентификационную информацию», в том числе любые связанные с ними системные компоненты, приложение ICHT также попадает в область регулирования PCI DSS.

Чтобы поддерживать стандарты PCI DSS, приложение ICHT физически и логически отделено от остальных сервисов Etsy и управляется отдельной командой разработчиков, инженеров баз данных, специалистов по сетям и инженеров эксплуатации. У каждого члена команды есть два ноутбука: один для ICHT (который настроен по-особому, чтобы соответствовать требованиям DSS; в нерабочее время он хранится в сейфе) и один для прочей работы.

Благодаря такому подходу мы смогли отделить среду CDE от остальной части Etsy, тем самым сильно ограничив ту область, где должны соблюдаться стандарты PCI DSS. Системы, составляющие CDE, отделены (и управляются) от других сред компании на физическом, сетевом, логическом уровнях и на уровне исходного кода. Кроме того, среда CDE управляется и сопровождается многофункциональной командой, отвечающей только за нее.

Чтобы соблюсти требования по соответствию кода, группе ICHT пришлось поменять свои методики непрерывной поставки. Согласно разделу 6.3.2 PCI DSS v3.1, команды должны анализировать весь специально разработанный код до передачи в эксплуатацию или пользование, чтобы идентифицировать следующие потенциальные уязвимые места (с помощью процессов, проводимых вручную или автоматизированных).

• Анализируются ли изменения кода кем-то другим, помимо самого автора кода, и владеет ли эксперт методиками анализа кода и его написания?

• Проверяется ли код на соответствие требованиям написания безопасного кода?

• Исправляются ли проблемные места кода до релиза?

• Проверяются и одобряются ли результаты анализа кода соответствующими специалистами до релиза?

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

Это позволило Etsy выполнить требования PCI DSS и получить от оценщиков подписанный Отчет о соответствии требованиям. Однако в команде возникли серьезные проблемы.

Мэсси отмечает один проблематичный побочный эффект — это «уровень “изоляции” в команде ICHT. Такого нет ни в одной другой команде Etsy. С тех пор как мы ввели разделение обязанностей и другие средства контроля в соответствии с PCI DSS, в этой среде больше никто не мог быть инженером широкого профиля».

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

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