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

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

Доказательства соблюдения требований в регулируемых средах (2015 г.)

Среди обязанностей Билла Шинна, ведущего архитектора по обеспечению безопасности Amazon Web Services, — демонстрация крупным корпоративным клиентам того, что их работа может соответствовать многочисленным законам и требованиям. За долгие годы количество компаний, с которыми ему довелось поработать, перевалило за тысячу, среди них — Hearst Media, GE, Phillips и Pacific Life, открыто заявлявшие, что пользуются общедоступными облаками в высокорегулируемых средах.

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

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

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

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

Шинн утверждает, что лучший способ добиться этого — «послать все данные в системы телеметрии, такие как Splunk или Kibana. Так аудиторы смогут получить все, что им нужно, без посторонней помощи. Им не требуется запрашивать выборку из данных, вместо этого они заходят в Kibana и ищут нужные аудиторские доказательства за конкретный временной период. В идеале они очень быстро найдут свидетельства того, что наши средства контроля действительно работают».

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

Для этого нужно, чтобы технические требования формировались на основе реальных нормативных требований. Шинн объясняет: «Чтобы найти, что требует HIPAA[179] с точки зрения обеспечения безопасности, вам нужно посмотреть раздел 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 в подразделении крупной американской финансовой организации, занимающейся банковским обслуживанием физических лиц. Она заметила, что служба информационной безопасности, аудиторы и регулирующие органы часто полагаются только на анализ кода, чтобы обнаруживать факты мошенничества. Вместо этого, чтобы сократить риски, связанные с ошибками и защитой данных, им следовало бы больше полагаться на средства мониторинга работы сервисов в эксплуатации вкупе с автоматизированным тестированием, анализом кода и оценкой качества.

Смит отмечает:

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

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

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