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

• Проверка зависимостей: еще один тип статического тестирования, проводимый во время сборки программы в конвейере развертывания, включает в себя проверку всех зависимостей продукта на наличие бинарных и исполняемых файлов, а также проверку того, что у всех этих зависимостей (а над ними у нас часто нет контроля) нет уязвимых мест или вредоносного кода. Примеры инструментов для таких тестов — Gemnasium и bundler audit для Ruby, Maven для Java, а также OWASP Dependency-Check.

• Целостность исходного кода и подпись программы: у всех разработчиков должен быть свой PGP-ключ, возможно, созданный и управляемый в такой системе, как keybase.io. Все подтверждения кода в системе контроля версий должны быть подписаны — это легко сделать с помощью таких инструментов свободного ПО, как gpg и git. Кроме того, все пакеты, созданные во время процесса непрерывной интеграции, должны быть подписаны, а их хэш должен быть записан в централизованный сервис логирования для облегчения аудита.

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

• как хранить пароли;

• как работать с забытыми паролями;

• как работать с входом в систему;

• как избежать уязвимых мест межсайтового скриптинга (XSS).

Презентация 10 Deploys per Day: Dev and Ops Cooperation at Flickr, подготовленная Джоном Оллспоу и Полом Хэммондом в 2009 г., известна тем, какое масштабное влияние она оказала на сообщество DevOps. Ее эквивалент для сообщества информационной безопасности — по-видимому, презентация Джастина Коллинса, Алекса Смолина и Нила Мататала, представленная на конференции AppSecUSA в 2012 г. В ней рассказывалось о трансформации работы над защитой данных в компании Twitter.

Из-за стремительного роста у этой организации появилось много проблем. На протяжении многих лет, когда у сайта не было достаточного количества ресурсов, чтобы соответствовать высокому спросу пользователей, на экран выводилась страница с сообщением об ошибке. На ней был нарисован кит, поднимаемый в небо восемью птичками. Масштаб роста числа пользователей поражал воображение: между январем и мартом 2009 г. число активных пользователей Twitter выросло с 2,5 миллиона до 10 миллионов человек.

У компании в этот период также были и проблемы с безопасностью. В начале 2009 г. произошло два серьезных инцидента. В январе был взломан аккаунт @BarackObama. Затем, в апреле, с помощью словарного перебора были взломаны аккаунты администрации Twitter. Эти события привели к тому, что Федеральная комиссия по торговле США приняла решение о том, что организация вводила своих пользователей в заблуждение относительно безопасности их аккаунтов, и издала соответствующее распоряжение.

Согласно этому распоряжению, компания должна была в течение 60 дней ввести несколько мер, а затем поддерживать их 20 лет. Среди этих мер были:

• назначение сотрудников, ответственных за план информационной безопасности компании;

• определение относительно предсказуемых рисков, как внутренних, так и внешних, приводящих к несанкционированному проникновению, а также создание и воплощение плана по сокращению этих рисков [163];

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

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

В уже упоминавшейся презентации Коллинс, Смолин и Мататал определили несколько насущных проблем.

• Предотвратить повторение ошибок в сфере безопасности: они обнаружили, что на самом деле они снова и снова исправляли все те же дефекты и уязвимые места, что и раньше. Нужно было так изменить инструменты автоматизации и всю систему работы, чтобы эти проблемы перестали повторяться.

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

• Сохранить доверие разработчиков: им надо было заслужить и сохранить доверие разработчиков. Это означало, что требовалось узнавать о случаях, когда они посылали разработчикам неверную информацию, чтобы стало возможным разобраться в причинах ложного срабатывания и впоследствии не тратить зря время разработчиков.

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

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

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

Первый большой прорыв произошел во время общеорганизационного недельного хакатона, когда они интегрировали статический анализ кода в процесс сборки. Команда использовала Brakeman, сканирующий приложения Ruby on Rails на наличие уязвимых мест. Целью было встроить сканирование в самые ранние стадии разработки, а не только проверять итоговый код, отправляемый в репозиторий.