Войти в систему
Войти с помощью соц. сетей:
Практический пример
Автоматизированные изменения инфраструктуры как стандартные изменения в компании (2012 г.)
Компания была основана в 2000 г., ее целью было сделать управление взаимоотношениями с клиентами легкодоступным и легко поставляемым сервисом. Предложения организации были широко востребованы на рынке, результатом чего стало успешное IPO в 2004 г. К 2007 г. у компании было более 59 000 клиентов, в день ее сервисы обрабатывали сотни миллионов транзакций, а годовой доход достиг 497 миллионов долларов.Однако в то же самое время их способность к разработке и выпуску новой функциональности упала практически до нуля. В 2006 г. у них было четыре больших релиза, но в 2007-м компания сделала всего лишь один релиз, несмотря на то что к тому времени число ее инженеров увеличилось. В результате число новых компонентов функциональности на команду падало, а периоды между большими релизами увеличивались.И поскольку размер каждого релиза становился все больше, результаты развертываний все ухудшались. Картик Раджан, тогда работавший директором по организации инфраструктуры, в своей презентации отмечал, что 2007 г. стал «последним, когда программное обеспечение создавалось и поставлялось с помощью каскадной методологии разработки, и именно тогда мы перешли на инкрементальный процесс поставки».На конференции DevOps Enterprise Summit в 2014 г. Дэйв Мангот и Рина Мэтью описали занявшую много лет DevOps-трансформацию компании, начавшуюся в 2009 г. Согласно Манготу и Мэтью, применяя принципы и методики DevOps, в 2013 г. организация сократила среднее время развертывания с шести дней до пяти минут. В результате стало легче масштабировать ресурсы, что позволило их сервисам обрабатывать более миллиарда транзакций в день.Одной из главных тем трансформации компании Salesforce было стремление сделать качество ответственностью всех сотрудников, вне зависимости от того, работали ли они в разработке, эксплуатации или информационной безопасности. Для этого встроили автоматизированное тестирование во все стадии создания приложений и сред, а также во все процессы непрерывной интеграции и развертывания и создали инструмент с открытым кодом под названием Rouster, чтобы проводить функциональное тестирование своих модулей Puppet.Они также начали проводить разрушающие тестирования — этот термин используется в промышленном производстве для обозначения длительных испытаний продукта в самых суровых условиях, пока тестируемый предмет не сломается. Команда Salesforce начала регулярно тестировать свои сервисы под большой нагрузкой, пока они не выходили из строя. Это помогло понять причины и ход отказа систем и внести нужные коррективы. Неудивительно, что в результате качество работы сервисов в нормальных условиях стало гораздо лучше.Служба информационной безопасности также работала вместе со службой обеспечения качества на ранних стадиях проекта, принимая участие в таких критических фазах, как разработка архитектуры и тестов, а также встраивая инструменты защиты данных в процесс автоматического тестирования.Для Мангот и Мэтью одним из важнейших результатов этого сурового процесса было то, что группа по управлению изменениями сказала им, что «изменения инфраструктуры, сделанные с помощью Puppet, теперь будут классифицироваться как “стандартные изменения”, для их внедрения не нужно будет одобрения комитета». Кроме того, было отмечено, что «изменения, вносимые в инфраструктуру вручную, все равно должны будут проходить процедуру одобрения».Благодаря проделанной работе они смогли не только интегрировать процессы DevOps и процессы управления изменениями, но также создали мотивацию для дальнейшей автоматизации внесения правок в инфраструктуру.
Практический пример
Стандарты безопасности PCI и поучительная история о разделении обязанностей в компании Etsy (2014 г.)
Билл Мэсси работает руководителем разработки в компании Etsy и отвечает за приложение оплаты под названием ICHT (аббревиатура от I Can Haz Tokens). ICHT проводит заказы клиентов через набор внутренних приложений обработки платежей: они принимают онлайн-заказ, выделяют информацию о платежной карте клиента, маркируют ее, отсылают платежной системе и завершают транзакцию.Поскольку в предметную область среды CDE входят «люди, процессы и технологии, хранящие, обрабатывающие и передающие данные владельцев платежных карт или конфиденциальную аутентификационную информацию», в том числе любые связанные с ними системные компоненты, приложение 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, на самом деле очень хрупки: даже если у команды богатая история сотрудничества, высокое доверие друг к другу и общие цели, она может столкнуться с проблемами, когда вводятся механизмы контроля, основанные на недоверии.
Практический пример
Доказательства соблюдения требований в регулируемых средах (2015 г.)
Среди обязанностей Билла Шинна, ведущего архитектора по обеспечению безопасности Amazon Web Services, — демонстрация крупным корпоративным клиентам того, что их работа может соответствовать многочисленным законам и требованиям. За долгие годы количество компаний, с которыми ему довелось поработать, перевалило за тысячу, среди них — Hearst Media, GE, Phillips и Pacific Life, открыто заявлявшие, что пользуются общедоступными облаками в высокорегулируемых средах.Шинн отмечает: «Одна из проблем была в том, что аудиторы привыкли работать методами, не очень хорошо подходящими для шаблонов DevOps. Например, если аудитор видел среду с десятком тысяч серверов, он традиционно просил сделать выборку из тысячи серверов, вместе со скриншотами материалов по управлению активами, настроек контроля доступа, данных по установке агентов, логов серверов и так далее.Для физических сред это нормально, — продолжает Шинн. — Но когда инфраструктура — это код, а из-за автомасштабирования серверы все время то появляются, то исчезают, как можно сделать выборку? Те же самые проблемы и с конвейером развертывания, он очень отличается от традиционного процесса разработки программного обеспечения, где одна группа пишет код, а другая вводит его в эксплуатацию».Далее он объясняет: «В работе аудиторов самым распространенным методом сбора информации все еще остаются скриншоты и CSV-файлы, заполненные параметрами конфигураций и логами. Наша цель — создать альтернативные способы представления данных. Они четко показывают аудиторам, что наши средства контроля удобны и эффективны».Чтобы сократить этот разрыв, у него есть команды, вместе с аудиторами разрабатывающие средства контроля. Они пользуются итеративным подходом, используя одно средство контроля за один подход, чтобы определить, что нужно для аудиторских доказательств. Благодаря этому аудиторы могут по запросу получать всю нужную им информацию, когда сервис находится в эксплуатации.Шинн утверждает, что лучший способ добиться этого — «послать все данные в системы телеметрии, такие как Splunk или Kibana. Так аудиторы смогут получить все, что им нужно, без посторонней помощи. Им не требуется запрашивать выборку из данных, вместо этого они заходят в Kibana и ищут нужные аудиторские доказательства за конкретный временной период. В идеале они очень быстро найдут свидетельства того, что наши средства контроля действительно работают».Шинн продолжает: «Благодаря современному аудиторскому логированию, чатам и конвейерам развертываний мы добились небывалой прозрачности и видимости того, что происходит в производственной среде, особенно если сравнивать с тем, как раньше обстояли дела в эксплуатации. Вероятность ошибок и брешей в безопасности стала гораздо меньше. Главная задача теперь состоит в том, чтобы преобразовать все эти доказательства в то, что аудитор сможет понять».Для этого нужно, чтобы технические требования формировались на основе реальных нормативных требований. Шинн объясняет: «Чтобы найти, что требует HIPAA с точки зрения обеспечения безопасности, вам нужно посмотреть раздел 160 части 45 Свода федеральных нормативных актов, проверить подразделы A и C раздела 164. Но и там вы не сразу найдете то, что ищете, вам придется читать до части “технические меры предосторожности и аудиторские средства контроля”. Только тогда вы увидите, что нужно определить отслеживаемые действия, связанные с информацией о пациентах, затем спроектировать и реализовать средства контроля, выбрать инструменты и только потом собрать и проанализировать нужные данные».Шинн продолжает: «Как именно выполнить это требование — предмет обсуждения между специалистами по надзору за соблюдением требований, службой защиты данных и командами DevOps. Особенного внимания требуют вопросы предотвращения, обнаружения и исправления ошибок. Иногда эти проблемы можно решить с помощью параметров конфигурации системы контроля версий. А иногда это проблема контроля мониторинга».Шинн приводит пример: «Можно воплотить одно из этих средств контроля с помощью AWS CloudWatch и затем протестировать, что это средство запускается с помощью одной строки. Кроме того, нужно показать, куда отправляются логи: в идеале мы складываем их в общую систему логирования, где можем связать аудиторские доказательства с актуальными требованиями контроля».Способ решения этой проблемы представлен в документе DevOps Audit Defence Toolkit: в нем описывается весь процесс аудита в вымышленной организации (Parts Unlimited из книги The Phoenix Project) от начала и до конца. Начинается он с рассказа о целях организации, ее бизнес-процессах, главных рисках и заканчивается описанием итоговых средств контроля и того, как руководство компании смогло успешно доказать, что эти средства контроля существуют и эффективно работают. В тексте также приводится список типичных возражений со стороны аудиторов и то, как с ними работать.В документе описано, как можно разработать средства контроля для конвейера развертывания, чтобы сократить известные риски, и приведены примеры аттестации качества средств и рабочих продуктов контроля, демонстрирующих их эффективность. Описание намеренно было сделано как можно более общим по отношению ко всем целям управления контролем, включающим в себя поддержку точной финансовой отчетности, соблюдение нормативных требований (например, SEC SOX-404, HIPAA, FedRAMP, типовые договоры Европейского союза и нормативные положения SEC Reg-SCI), контрактные обязательства (например, PCI DSS, DOD DISA) и эффективный и действенный процесс эксплуатации.Практический пример
Эксплуатационная телеметрия в системах управления банкоматами
Мэри Смит (имя вымышлено) возглавляет инициативную группу DevOps в подразделении крупной американской финансовой организации, занимающейся банковским обслуживанием физических лиц. Она заметила, что служба информационной безопасности, аудиторы и регулирующие органы часто полагаются только на анализ кода, чтобы обнаруживать факты мошенничества. Вместо этого, чтобы сократить риски, связанные с ошибками и защитой данных, им следовало бы больше полагаться на средства мониторинга работы сервисов в эксплуатации вкупе с автоматизированным тестированием, анализом кода и оценкой качества.Смит отмечает:
«Много лет назад у нас был разработчик, оставивший лазейку в коде, развертываемом в наши банкоматы. В нужный момент он мог переводить банкоматы в профилактический режим и получать наличные деньги. Эту мошенническую схему мы раскрыли быстро, и не с помощью анализа кода. Такие способы обхода защиты сложно, даже практически невозможно обнаружить, когда у злоумышленника достаточно мотивации, навыков и благоприятных возможностей.Однако мы смогли быстро обнаружить мошенничество во время регулярных встреч группы эксплуатации для анализа, когда кто-то заметил, что банкоматы в городе переходят в режим обслуживания не по расписанию. Мы раскрыли схему даже до запланированной проверки наличности в банкоматах, когда аудиторы сверяют реальное количество денег с проведенными транзакциями».
В этом примере из практики противозаконная операция произошла, несмотря на процессы управления изменениями и разделение обязанностей между разработкой и эксплуатацией, но обнаружение и исправление бреши безопасности стали возможными благодаря эффективной эксплуатационной телеметрии.
Войти с помощью соц. сетей: