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

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

• Признаки SQL-инъекций:«Это был на удивление простой тест: мы просто поставили оповещение о любом вводе команды UNION ALL в полях ввода пользовательской информации, потому что это практически всегда говорит о попытке взлома с помощью внедрения SQL-кода. Мы также добавили специальный тест, чтобы подобный тип неконтролируемого пользовательского ввода не принимался нашей системой».

На рис. 45 показан пример графика, доступного каждому разработчику компании. На нем отображается число потенциальных атак с помощью SQL-инъекций в среде эксплуатации. Как отмечает Галбрет, «ничто так не помогает разработчикам понять враждебность среды эксплуатации, как возможность видеть атаки на их код в реальном времени».

Рис. 45. Разработчики Etsy могли видеть попытки SQL-инъекций в систему мониторинга Graphite (источник: “DevOpsSec: Appling DevOps Priciples to Security, DevOpsDays Austin 2012”, SlideShare.net, опубликовано Ником Галбретом, 12 апреля 2012 г., http://www.slideshare.net/nickgsuperstar/devopssec-apply-devops-principles-to-security)

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

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

Как отметил Джонатан Клаудиус, бывший старший тестировщик безопасности в организации TrustWave SpiderLabs, «серверы непрерывной сборки приложений и тестирования работают потрясающе, я сам их использую. Но я начал задумываться о том, как использовать CI и CD для внедрения вредоносного кода. Что привело меня к вопросу: где хорошее место для того, чтобы спрятать вредоносный код? Ответ очевиден: в юнит-тестах. На них никто не смотрит, и они запускаются каждый раз, когда кто-то отправляет свой код в репозиторий».

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

Кроме того, чтобы защитить конвейер непрерывной сборки, интеграции или развертывания, можно ввести такие стратегии:

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

• анализ и оценка всех изменений в системе контроля версий, или с помощью парного программирования во время подтверждения кода, или с помощью рецензирования кода между подтверждением кода и добавлением его в основную ветку. Так в серверы непрерывной интеграции не будет поступать неконтролируемый код (например, тесты могут содержать вредоносный код, делающий возможным неавторизованный доступ);

• оснащение репозиториев инструментами для обнаружения подозрительных API-вызовов в коде тестов (например, тесты, требующие доступа к файловой системе или сетевым соединениям), добавляемых в репозиторий, возможно, с карантином подозрительного кода и его немедленным анализом;

• предоставление для каждого процесса непрерывной интеграции своего изолированного контейнера или виртуальной машины;

• проверка того, что параметры доступа контроля версий, используемые системой непрерывной интеграции, разрешают только чтение.

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

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

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

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

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