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

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

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

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

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

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

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

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

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

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

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