Книга: Руководство по DevOps
Стандарты безопасности PCI и поучительная история о разделении обязанностей в компании Etsy (2014 г.)
Стандарты безопасности PCI и поучительная история о разделении обязанностей в компании Etsy (2014 г.)
Билл Мэсси работает руководителем разработки в компании 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, на самом деле очень хрупки: даже если у команды богатая история сотрудничества, высокое доверие друг к другу и общие цели, она может столкнуться с проблемами, когда вводятся механизмы контроля, основанные на недоверии.
- Встройте цели защиты данных и выполнения требований в процесс одобрения изменений
- Переместите большинство низкорисковых правок в категорию стандартных изменений
- Что делать с изменениями из категории нормальных
- Практический пример
- Автоматизированные изменения инфраструктуры как стандартные изменения в компании Salesforce.com (2012 г.)
- Уменьшите зависимость от разделения обязанностей
- Практический пример
- Стандарты безопасности PCI и поучительная история о разделении обязанностей в компании Etsy (2014 г.)
- Храните документацию для аудиторов и проверяющих органов
- Практический пример
- Доказательства соблюдения требований в регулируемых средах (2015 г.)
- Практический пример
- Эксплуатационная телеметрия в системах управления банкоматами
- Заключение
- Заключение части VI
- Система безопасности InterBase
- Общие рекомендации по безопасности
- Конфигурация безопасности для базы данных
- CPC или CPM: показатель оптимизации № 11 – CPC как инновация компании Google
- 2.2. Практическая разработка фирменного стиля компании 51
- 7.4 Технология виртуализации хранилища от компании Microsoft
- 7.9 Будущее управления хранилищами по версии ассоциации SNIA: стандарты SMI
- Обеспечение безопасности библиотеки
- Глава 1 Стандарты и угрозы информационной безопасности
- Глава 3 Нормативные руководящие документы, назначение и задачи информационной безопасности России
- История развития компьютеров (вместо пролога)
- Распределение функциональных обязанностей между должностями