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

Результаты интеграции тестирования в процесс разработки были потрясающими. За год благодаря быстрой обратной связи о небезопасном коде и о способах его корректировки Brakeman сократил долю обнаруженных уязвимых мест на 60 %, как показано на рис. 44 (пики обычно соответствуют релизу новой версии Brakeman).

Рис. 44. Число уязвимых мест в системе безопасности, обнаруженное Brakeman

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

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

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

Изучение нарушений конфиденциальности данных о владельцах карт наглядно показывает, насколько важна безопасность используемых компонентов. С 2008 г. ежегодный отчет Verizon PCI Data Breach Investigation Report (DBIR) считается самым авторитетным источником об утечках данных владельцев карт. В отчете 2014 г. они изучили более 85 000 утечек, чтобы лучше понять пути атак, как именно крадут данные владельцев карт и какие факторы способствуют нарушениям конфиденциальности.

Исследование DBIR показало, что в 2014 г. всего из-за десяти уязвимых мест (так называемые распространенные уязвимые места и риски — CVE (common vulnerabilities and exposures)) произошло примерно 97 % утечек информации. Возраст восьми из этих уязвимых мест был больше десяти лет.

В отчете Sonatype State of the Software Supply Chain Report 2015 г. проанализированы данные об уязвимых местах репозитория Nexus Central Repository. В 2015 г. в этом репозитории хранилось более 605 000 проектов с открытым кодом, он обслуживал более 17 миллиардов запросов на скачивание программ и зависимостей, в основном для платформы Java, от более чем 106 000 организаций.

В отчете упоминались следующие пугающие факты:

• типичная организация полагалась на 7601 программный продукт (то есть источник программного обеспечения или компонент) и использовала 18 614 разных версий (то есть частей программного обеспечения);

• из этих компонентов у 7,5 % содержались известные уязвимые места, примерно 66 % были известны более двух лет, и никаких мер по их устранению предпринято не было.

Последний факт подтверждается и в исследовании Дэна Джира и Джоша Кормэна: они показали, что из всех открытых проектов с известными уязвимыми местами, зарегистрированных в Национальной базе, проблемы с защитой были устранены только у 41 % и в среднем на выпуск патча требовалось 390 дней. Для уязвимых мест с наивысшей степенью опасности (уровень 10 по шкале CVSS [164]) исправление заняло в среднем 224 дня [165].

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

Для этого мы создадим автоматизированные тесты, проверяющие, что у средств обеспечения устойчивости конфигураций, настроек безопасности баз данных, длин ключей и многого другого выставлены верные параметры. Кроме того, мы используем тесты для сканирования сред на известные уязвимые места [166].

Другое направление проверки безопасности — анализ того, как работают реальные среды (другими словами, «как есть», а не как «должно быть»). Примеры инструментов этого направления — Nmap, следящий за тем, что открыты только нужные порты, и Metasploit, проверяющий, что все типичные уязвимые места сред закрыты, например с помощью симуляции SQL-инъекций. Результаты применения этих инструментов должны храниться в общем репозитории и в процессе функционального тестирования сравниваться с предыдущими версиями. Это поможет быстро отследить любые нежелательные изменения.

В 2016 г. федеральные государственные учреждения США должны были потратить на информационные технологии 80 миллиардов долларов. Вне зависимости от учреждения, чтобы перевести систему в эксплуатацию, нужно было получить специальное разрешение на использование от соответствующего органа. Законы и требования в исполнительной власти состоят из десятков документов. В сумме они насчитывают более 4000 страниц, усеянных непонятными аббревиатурами вроде FISMA, FedRAMP и FITARA [167]. Даже в системах с низким уровнем конфиденциальности, целостности и доступности должно быть проверено, задокументировано и проверено более сотни элементов. После завершения разработки обычно требуется от восьми до четырнадцати месяцев, чтобы получить разрешение.

Чтобы решить эту проблему, команда 18F Управления служб общего назначения федерального правительства приняла многоэтапный план. Майк Бланд объясняет: «Группу 18F в Управлении служб общего назначения создали на волне ажиотажа от успеха восстановления сервиса Healthcare.govради полного изменения подхода правительства к разработке и покупке программного обеспечения».

Одним из результатов работы группы стала платформа Cloud.gov, собранная из общедоступных компонентов с открытым исходным кодом. В настоящее время сервис Cloud.govработает в облаке AWS GovCloud. Платформа не только сама справляется с такими задачами эксплуатации, как логирование, мониторинг, оповещения и управление жизненным циклом сервиса. Ими обычно занимаются команды эксплуатации. Она также сама следит за большей частью задач по соблюдению законодательных требований. Для приложений, запускаемых на этом сервисе, большинство компонентов, обязательных для правительственных систем, можно реализовать на инфраструктурном или платформенном уровне. После этого документировать и тестировать нужно только компоненты на уровне приложения, что значительно сокращает нагрузку по соблюдению требований и уменьшает сроки получения разрешений.