Erhalten Sie Zugang zu diesem und mehr als 300000 Büchern ab EUR 5,99 monatlich.
- Herausgeber: Питер
- Kategorie: Wissenschaft und neue Technologien
- Sprache: Russisch
Приложение, запущенное в облаке, обладает множеством преимуществ, но в то же время подвержено особенным угрозам. Задача DevOps-команд — оценивать эти риски и усиливать защиту системы от них. Книга основана на уникальном опыте автора и предлагает важнейшие стратегические решения для защиты веб-приложений от атак, предотвращения попыток вторжения. Вы увидите, как обеспечить надежность при автоматизированном тестировании, непрерывной поставке и ключевых DevOps-процессах. Научитесь выявлять, оценивать и устранять уязвимости, существующие в вашем приложении. Автор поможет ориентироваться в облачных конфигурациях, а также применять популярные средства автоматизации. В этой книге: •Обеспечение непрерывной безопасности. •Внедрение безопасности на основе тестирования в DevOps. •Приемы, помогающие повысить надежность облачных сервисов. •Отслеживание вторжений и реагирование на инциденты . •Тестирование безопасности и оценка рисков. Требуется знание Linux и владение стандартными практиками DevOps, такими как CI, CD и модульное тестирование.
Sie lesen das E-Book in den Legimi-Apps auf:
Seitenzahl: 520
Veröffentlichungsjahr: 2024
Das E-Book (TTS) können Sie hören im Abo „Legimi Premium” in Legimi-Apps auf:
Ähnliche
Переводчик С. Черников
Технический редактор Н. Гринчик
Литературные редакторы Е. Ковалева, Н. Рощина
Художники С. Заматевская , Г. Синякина (Маклакова)
Корректоры Е. Павлович, Т. Радецкая
Верстка Г. Блинов
Джульен Вехен
Безопасный DevOps. Эффективная эксплуатация систем. — СПб.: Питер, 2021.
ISBN 978-5-4461-1336-1
© ООО Издательство "Питер", 2021
Все права защищены. Никакая часть данной книги не может быть воспроизведена в какой бы то ни было форме без письменного разрешения владельцев авторских прав.
Оглавление
Посвящается моей жене Богдане и всем ребятам из Mozilla, которые берегут защищенность и открытость Интернета
Предисловие
Я расчищал полки со списанным оборудованием в подвале старого правительственного здания, и мне на глаза попалось несколько внушительных жестких дисков. 2002 год, мне 19 лет, это мое первое рабочее место в качестве специалиста службы поддержки во французском налоговом агентстве. Начальница едва не извиняется за то, что попросила убрать подвал, подозревая, что я выполню задание спустя рукава. Однако я чувствую себя как Али-Баба, впервые вошедший в волшебную пещеру. Я вижу множество старых серверов, стоящих без дела, но все еще способных запускать UNIX-системы, о которых я даже не слышал. Они оставлены в лучшем случае для баловства. Если бы в моей квартире было больше одной комнаты и крохотной кухни, я бы взял все это и запустил масштабную сеть прямо из дома!
Два жестких диска — это SCSI-диски с 15 000 об/мин, которые предназначались для устаревшего контроллера домена. Я отложил их в сторону, чтобы поискать SCSI-адаптер для подключения. Нашел его в соседней коробке пыльным, но невредимым. После нескольких часов расчистки и инвентаризации подвала я спросил разрешения забрать все домой. План был прост — подключить диски к запасной материнской плате и настроить самый быстрый сервер для шутера Counter Strike, которого Интернет еще не видел. Затем я бы развернул его в сети с помощью недавно установленного DSL-соединения на 512 Кбит/с и пригласил свою игровую команду потренироваться на нем.
Я провел все выходные, пытаясь заставить жесткие диски и адаптер правильно работать, стремился добиться их грамотного распознавания инсталлятором Debian. Часами искал руководства для работы со специфичным оборудованием, подсказки на десятках форумов и в письмах. Но большинство из них касались либо другого SCSI-адаптера, либо каких-то секретных ядер операционной системы (ОС), которые я не мог расшифровать. Прошли выходные, затем будни, и я наконец-то нашел верное сочетание параметров, которые запускают установку Linux на RAID 1. Может быть, я ошибаюсь, но думаю, что работа с железом — это и правда сложно!
Однако радость от успеха была недолгой. Вскоре я понял: эти два диска с их 15 000 об/мин создают слишком много шума, намного больше, чем я могу выдержать, когда сижу часами в нескольких метрах от них. Конечно, мой сервер работал, он был умеренно быстрым, но мне пришлось выключить его и оставить затею превращения квартиры в центр обработки данных.
Когда я изучал IT (в конце 1990-х и начале 2000-х годов), акцент делался на оборудовании и сетях. Вместе со своими сверстниками и преподавателями я проводил много времени, читая новости о последних серверах, новейших CPU и лучших жестких дисках. Все это надо было знать, чтобы создать идеальную систему для реализации на ней наших приложений. Закупка происходила медленно и была затратной, в частности, в моем правительственном агентстве. Неправильный выбор оборудования мог оставить нас в заложниках сервера, который не менялся бы в течение трех лет, а может, и дольше.
Представьте себе это в настоящем времени. Три года! Это длиннее, чем жизнь многих стартапов. Больше, чем продолжительность пика популярности почти всех веб-фреймворков на JavaScript. Множество людей работают в одной компании не дольше. Такой период просто вечность в мире IT.
В те времена (наверное, звучит так, будто я ваш дедушка) невозможно было развернуть веб-сервис на рынке менее чем за год или даже два. Не было облачных технологий, поставщиков услуг, которые могли бы размещать серверы или запускать службы онлайн вместо вас, предоставляя вам удаленный доступ к ним. Наши интернет-соединения были медленными (правительственное агентство обеспечивало вопиющими 128 Кбит/с, распределенными между 150 сотрудниками!) и не подходили для передачи больших объемов данных между локальным настольным компьютером и онлайн-сервисом. Настройка серверов представляла собой длительный и сложный процесс, который зачастую подразумевал часы сражения с драйверами оборудования и дни трудностей, связанные с прокладкой кабелей и работами по установке. Организации и целые отделы посвящали себя этому занятию. Программисты знали, что заказывать серверы нужно заранее, иначе есть риск того, что проект придется отложить на несколько месяцев.
Сосредоточенность IT на оборудовании и сетях также была характерна для отделов, обеспечивающих безопасность. Немногие тогда говорили о безопасности приложений. Зато все внимание сосредоточивалось на фильтрации сетевого трафика и доступе (физическом или виртуальном) к серверам. В школе мы узнали о межсетевых экранах (брандмауэрах), изолированных системах в пределах виртуальной локальной вычислительной сети (ЛВС) и обнаружении сетевых вторжений. Мы не вдавались в подробности безопасности веб-приложений — не знали тогда, что через несколько лет почти весь мир откажется от использования установленного программного обеспечения наподобие Outlook и сосредоточится на форме программы как сервиса, такой как Gmail. Эти перемены начались в середине 2000-х годов и позднее стали для нас более очевидными.
Когда методология DevOps набирала обороты и распространяла концепции непрерывной интеграции, непрерывной поставки и инфраструктуры как сервиса, те, кто страдал от длительных задержек в эксплуатации оборудования, воодушевленно стремились перенять многообещающие возможности развертывания инфраструктуры в течение нескольких дней, а не месяцев. Однако большинство специалистов по безопасности противились этим переменам, обеспокоенные тем, что потеря контроля над инфраструктурой в итоге окажется не на пользу безопасности.
Сначала я был одним из тех, кто противился. Все мои потом и кровью полученные навыки внушали мысли о безопасности, неотделимой от управления оборудованием: если вы не управляете системами самостоятельно, то не можете считать свое положение безопасным. Но мало-помалу становилось все более заметно, что мои друзья-разработчики развертывают приложения с помощью небольшого перечня команд, в то время как я все еще трачу часы на то, чтобы осуществить это старым методом. Однозначно, они обнаружили что-то полезное, поэтому я начал работать инженером по эксплуатации и перенес монолитное Java-приложение на AWS (Amazon Web Services). Это было мучительно. Я не знал о существовании конфигурационных инструментов, Puppet или Chef, да и AWS в то время не был настолько развит, как сейчас. Я писал оригинальные скрипты для автоматизации настройки серверов и учился использовать API для создания виртуальных машин на ходу. Моему руководителю нравилось то, что возможно сломать приложение и развернуть его заново несколькими командами, однако все работало ненадежно и довольно нестабильно. Но это было лишь начало. Оно придало мне уверенности в том, что безопасность сильно зависит от гибкости инфраструктуры: чем быстрее системы способны изменяться, тем быстрее можно устранить проблемы и тем выше уровень безопасности.
А присоединившись к Mozilla Cloud Services, я увидел, чего опытная команда может достичь с помощью продвинутых техник DevOps. Когда я наблюдаю, как сервис автоматически удваивает количество серверов для поглощения растущего трафика, а затем отключается от дополнительных серверов через несколько часов после снижения нагрузки, и усматриваю в этом определенную красоту, мой внутренний зануда ликует. Автоматизация развертывания сбособствует интеграции новых проектов в течение одного или двух дней после первоначальной настройки. Такая гибкость помогает малым организациям быстро нарастить производительность, популярность и в результате стать технологическими гигантами. Меня продолжает удивлять то, как далеко позади остались недели, затрачиваемые на настройку простых серверов под Linux с двумя жесткими дисками на RAID 1, соединенных с какой-нибудь приличной сетью.
Я убежден в том, что безопасность должна служить бизнесу. Когда бизнес требует модернизации, которая реализуется посредством DevOps, безопасности необходимо пойти следом и поддержать преобразования, а не препятствовать им. Я написал эту книгу, чтобы помочь начинающим и опытным специалистам в сфере безопасности поддерживать внедрение современных практик в своих организациях, не подвергая риску данные или заказчиков. Эта книга отражает мой собственный опыт внедрения безопасности в веб-сервисы, нуждающиеся в высоком уровне защиты, а также практику и технику, которые годами совершенствовались сообществом специалистов по безопасности. Эти техники не являются незыблемыми. Они будут развиваться после выхода данной книги, но концепции, изложенные здесь, останутся полезными до тех пор, пока мы управляем сервисами онлайн.
Благодарности
Написание книги — большой труд. Эта не исключение. Сбор, упорядочение информации, редактирование, переписывание материала, проверка содержания заняли более двух лет. Думаю, моя любимая цитата о процессе создания книги (автор — Дж. Фаулер) следующая: «Писать — это легко. Нужно всего лишь уставиться на чистый лист бумаги и смотреть на него, пока на лбу не появятся капли крови». Кто-нибудь другой, будучи втянутым в этот долгий и мучительный процесс, давно мог бы сдаться. Возможно, этим другим стал бы я, если бы не моя жена Богдана, которая постоянно призывала меня завершить книгу, поддерживала, когда я тратил на нее время, которое мог бы посвятить семье. Я люблю тебя и моей благодарности нет предела!
Я также хочу поблагодарить своих друзей и коллег из службы безопасности, разработки, эксплуатационных групп Mozilla, которые помогали мне советами, отзывами и технологиями. Вы во многом улучшили эту книгу.
Мой друг Дидье Бернадо помог расширить видение безопасности в DevOps благодаря тому, что поделился своим опытом, полученным в банковской сфере. Он высказал свою точку зрения, которая отличалась от моей, и это увеличило аудиторию книги.
Я должен сказать спасибо Эндрю Бовилю и Скотту Пайперу за проверку технической точности кода и работоспособности методов, представленных в книге. Никакой код не получится хорошим без должной дружеской проверки.
Множество полезных комментариев было сделано рецензентами из Manning: Адамом Монтвилем, Адриеном Саладином, Брюсом Цамэром, Клиффордом Миллером, Дэвидом Морганом, До Мориной, Эрнестом Карденасом Кангахуалой, Джеффом Кларком, Джимом Армрайном, Морганом Нельсоном, Радживом Ранджаном, Тони Суитсом и Ян Гуо.
Последнее, но не менее важное, — я хочу отметить значительную роль Тони Арритолы и Дэна Махарри, моих редакторов-консультантов по аудитории. Они поспособствовали воплощению идеи этой книги в жизнь. Дэн оформил беспорядочные мысли в материал, с помощью которого можно обучать. Благодаря Тони книга была выпущена в наивысшем качестве. Я могу с уверенностью сказать, что это издание никогда не появилось бы, если бы не эти двое. Спасибо вам!
О книге
Я писал эту книгу для Сэм — вымышленной героини, которая работает в IT сколько себя помнит. Несколько лет она трудилась в отделе эксплуатации и немного занималась разработками. Сэм недавно получила должность DevOps-инженера в FlyCARE. FlyCARE занимается созданием веб- и мобильных платформ для выставления счетов за медицинские услуги и управления ими. Это небольшой стартап — два штатных системных администратора, пять разработчиков на полную ставку и несколько человек на стороне бизнеса. Здесь существуют высокие риски для персональных данных о здоровье, но коллеги надеются, что Сэм сможет создать для этих данных безопасную платформу, на которой можно запускать веб-сервисы.
Испытания — именно то, чего искала Сэм. Но защищать платформу с высокими рисками в стартапе, где разработчики любят размещать код из GitHub в Docker-контейнерах по три раза в день, будет трудно. Нашей героине нужна помощь. Эта книга — путеводитель для Сэм.
Структура издания
Книга оформлена в виде обучающего курса, начинающегося с базовых операционных понятий. Это сделано для того, чтобы читатель освоил самые элементарные техники DevOps. Затем будут рассматриваться все более сложные темы. В части I мы погрузимся в понятие безопасности в тестовой среде. В части II будем выявлять атаки и бороться с ними. В части III усовершенствуем стратегию безопасности внутри организации. Главы упорядочены так, чтобы показать последовательность, в которой будет реализовываться стратегия безопасности в организации, не применяющей DevOps или только начинающей внедрять его. Издание представляет собой практическое руководство, включающее разумное количество концепций для непосредственного применения теории на практике.
В главе 1 рассматриваются DevOps и необходимость внедрения безопасности параллельно с практикой разработки и эксплуатации. Вы узнаете о принципе непрерывной защиты, который будет использоваться на протяжении всей книги.
В часть I входят главы 2–6, они познакомят читателя с принципами защиты целого DevOps-конвейера.
• В главе 2 раскрывается процесс разработки DevOps-конвейера в AWS. Вы сможете создать конвейер и развернуть приложение с помощью автоматизации. Сначала оно не будет безопасным. Я выделю те области, которые нуждаются в улучшениях, детальнее мы изучим их в последующих главах.
• В главе 3 рассказывается о безопасности веб-приложений. Мы обсудим то, как тестировать ваши сайты, защищаться от типовых атак, управлять аутентификацией пользователей и поддерживать актуальность кода.
• В главе 4 сделан акцент на укреплении инфраструктуры AWS. Вы научитесь выполнять тестирование безопасности в пределах автоматического размещения, ограничивать сетевой доступ, защищать доступ к инфраструктуре и базе данных.
• В главе 5 рассматривается защита каналов взаимодействия и обсуждается TLS — криптографический протокол под HTTPS, также изучается их корректная реализация для защиты сайтов.
• В главе 6 рассказывается о безопасности конвейера поставки. Мы обсудим, как управлять разграничением доступа в GitHub, Docker Hub и AWS. Вы также узнаете, как сохранить целостность кода и контейнеров и распределить идентификационные данные по приложениям.
К части II относятся главы 7–10, которые направлены на выявление аномалий в инфраструктуре и защиту сервисов от атак.
• В главе 7 объясняется структура конвейера журналирования. Вы изучите то, как уровни сбора, потоковой передачи, анализа, хранения и доступа взаимодействуют друг с другом, обеспечивая эффективную работу с журналами.
• В главе 8 рассматривается анализ уровней конвейера журналирования. Вы реализуете различные техники для работы с журналами, сможете обнаружить аномалии и вредоносную активность.
• В главе 9 рассказывается о выявлении вторжений. Мы обсудим инструменты и техники, применяемые для обнаружения вредоносной активности в сети, системе и на человеческом уровне.
• В главе 10 представлен практический пример вторжения в выдуманной организации. Вы поймете, как надо реагировать на такой инцидент и восстанавливаться после него.
Часть III включает главы 11–13, которые обучают техникам совершенствования стратегии безопасности для организации, применяющей DevOps.
• В главе 11 содержится введение в оценку рисков. Вы узнаете о трех элементах CIA (конфиденциальность, целостность и доступность), фреймворках моделирования потоков STRIDE и DREAD. Вы также поймете, как реализовать легковесный фреймворк оценки рисков в вашей организации.
• В главе 12 раскрывается тестирование безопасности веб-приложения, исходного кода и уровней инфраструктуры. Обсуждаются различные инструменты и техники, применяемые для обнаружения проблем безопасности в организации.
• В главе 13 представлена трехгодичная модель реализации непрерывной безопасности в организации. В ней даны некоторые подсказки, способные увеличить ваши шансы на успех.
О коде
В книге содержится множество небольших команд и листингов, а также несколько полномасштабных приложений. Исходный код форматирован моношириннымшрифтом для отделения его от остального текста. Иногда код выделен полужирнымшрифтом для обозначения изменившихся фрагментов кода относительно последних шагов в главе, например, когда в существующую строку кода добавлен новый функционал. Все листинги с кодом из этой книги доступны для скачивания на сайте GitHub: https://securing-devops.com/code.
Исходный код содержит приложения invoicer и deployer вместе со скриптами для их настройки и конвейер журналирования, упомянутый в главе 8.
Вы можете заметить некоторые различия между кодом в книге и сети. В большинстве случаев это обусловлено требованиями к форматированию. К тому же я буду поддерживать актуальность онлайн-кода, включая исправление багов и изменения в сторонних инструментах и сервисах, в то время как код в книге останется неизменным.
От издательства
Ваши замечания, предложения, вопросы отправляйте по адресу [email protected] (издательство «Питер», компьютерная редакция).
Мы будем рады узнать ваше мнение!
На сайте издательства www.piter.com вы найдете подробную информацию о наших книгах.
Об иллюстрации на обложке
Рисунок на обложке книги называется «Женщина гаку». Иллюстрация выбрана из коллекции «Костюмы разных стран» (Costumes de Diffe'rents Pays) Жака Гасе де Сен-Совьера (1757–1810), напечатанной во Франции в 1797 году. Каждая иллюстрация выполнена с ювелирной точностью и раскрашена вручную. Богатое разнообразие коллекции Гасе де Сен-Совьера служит напоминанием о том, как далеки были друг от друга 200 лет назад культуры разных местностей и городов. Находясь в такой изоляции, люди разговаривали на различных языках и диалектах. Легко было определить, где они жили, чем занимались, каково было их положение в обществе, исходя из того, какую носили одежду.
С тех пор одежда сильно изменилась, исчезло разнообразие, свойственное различным странам и областям. Сейчас по одежде сложно различить даже жителей разных континентов, не говоря уже о принадлежности к странам, городам и регионам. Мы предпочли культурному разнообразию жизнь среди технологий, более насыщенную и быстро развивающуюся.
В наше время, когда порой непросто отличить одну компьютерную книгу от другой, издательство Manning по достоинству оценивает находчивость и предприимчивость представителей компьютерного бизнеса, украшая обложки книг изображениями, которые показывают богатое разнообразие жизни в регионах два века назад, возрожденное в работах Гасе де Сен-Совьера.
Об авторе
На момент написания книги Джульен Вехен управляет командой системы безопасности операций в Firefox, Mozilla. Он отвечает за формирование, реализацию и эксплуатацию стратегии защиты веб-сервисов, с которыми миллионы пользователей Firefox взаимодействуют ежедневно. Джульен сконцентрировался на защите сервисов в сети в начале 2000-х годов. Он начинал работать системным администратором в Linux, а в 2007 году получил диплом магистра по информационной безопасности.
Глава 1. Безопасность в DevOps
В этой главе
• Знакомство с DevOps, его влияние на создание облачных сервисов.
• Применение непрерывной интеграции, непрерывной поставки и инфраструктуры как сервиса.
• Оценка роли и целей безопасности в культуре DevOps.
• Определение трех компонентов стратегии безопасности DevOps.
Связанные между собой приложения, которые облегчают жизнь, стали технологической революцией XXI века. Появляется возможность помогать с налогами, делиться фотографиями с друзьями и семьей, находить хороший ресторан в незнакомой местности, отслеживать прогресс в тренажерном зале. Такие приложения становятся все более полезными. Показатели роста использования таких сервисов, как Twitter, Facebook, Instagram и Google, демонстрируют, что пользователи считают их очень полезными. Каждое из этих приложений можно открыть на экране смартфона или в браузере.
Отчасти этот прорыв стал возможен благодаря появлению улучшенных инструментов для создания приложений и управления ими. Конкуренция в Интернете сильна. Идеи быстро устаревают, компании должны стремительно двигаться вперед, чтобы завладеть долями рынка, обеспечить заинтересованность пользователей в своих продуктах. В мире стартапов скорость и стоимость, с которыми организация может воплотить идею в продукте, являются ключевыми факторами успеха. DevOps, внедряющий инструменты и техники из мира Интернета в промышленность, представляет собой революцию, которая обеспечила возможность запускать онлайн-сервисы с низкими затратами, позволила малым стартапам конкурировать с технологическими гигантами.
При золотой лихорадке стартапов данные иногда оказываются недостаточно защищенными. Пользователи продемонстрировали желание доверять приложению, предоставив свои данные в обмен на услуги и сервисы. Это привело к тому, что многие организации стали обладателями большого количества персональных данных своих пользователей даже до того, как разработали план безопасности, позволяющий должным образом обращаться с этими сведениями.
Пространство, где есть конкуренция, вынуждает компании брать на себя риски хранения большого количества конфиденциальных данных. Это идеальное условие для катастрофы. Поэтому с увеличением количества онлайн-сервисов растет частота обнаружения пробелов в безопасности.
В книге «Безопасный DevOps. Эффективная эксплуатация систем» рассказано о том, как можно помочь организациям безопасно обращаться с данными, доверенными пользователями, и защищать их. Я познакомлю вас с моделью, которую называют «непрерывная безопасность». Она сосредоточена на внедрении усиленных принципов безопасности в различные компоненты стратегии DevOps. Я объясню общие подходы, архитектурные принципы, техники управления рисками для того, чтобы вы могли перейти от отсутствия безопасности к полноценной программе. В этой книге в целом рассматриваются принципы и концепции, но в главах в качестве примеров будут использоваться специфичные инструменты и среды.
DevOps может охватывать множество вещей, все зависит от того, в какой области информационных технологий (IT) он применяется. Эксплуатация инфраструктуры атомной станции кардинально отличается от обработки платежей кредитными картами на сайтах, хотя в обоих случаях выгода от применения DevOps для оптимизации операций будет очевидна. Раскрыть все, что касается DevOps и IT, в одной книге непросто, поэтому я сконцентрировался на облачных сервисах — IT-сфере, посвященной развитию и эксплуатации веб-приложений. Вам предлагается разработать, использовать, обезопасить и защитить веб-приложение, размещенное в облаке. Концепции и примеры, которые здесь представлены, лучше всего подойдут для облачных сервисов организаций, которые еще не имеют собственной команды по безопасности. Однако читатель с прогрессивными взглядами сможет легко перенести их в любую DevOps-среду.
В первой главе мы изучим, как DevOps и безопасность могут работать совместно. Это позволяет организациям брать на себя риски без ущерба для безопасности клиентов.
1.1. Методология DevOps
DevOps — процесс непрерывного совершенствования программных продуктов посредством ускорения циклов релизов, глобальной автоматизации интеграционных и разверточных конвейеров и тесного взаимодействия между командами. Целью DevOps является сокращение времени и стоимости воплощения идеи в продукте, которым пользуются клиенты. DevOps применяет много автоматизированных процессов для ускорения разработки и развертывания. На рис. 1.1 сравнивается традиционный подход к построению программ (вверху) и DevOps (внизу).
Рис. 1.1. DevOps сокращает время между разработкой концепций функционала и его доступностью для клиентов
•В верхней части время между разработкой концепции и готовностью продукта составляет восемь дней. Почти весь этот период занимает развертывание инфраструктуры, так как инженерам нужно создать компоненты, необходимые для размещения программы в Интернете. Другой пожиратель времени — стадия тестирования и проверки между развертываниями.
• В нижней части время между разработкой концепции и развертыванием сокращается до двух дней. Это достигается за счет использования автоматизированных процессов для развертывания инфраструктуры, а также тестирования и проверки программ.
Организация, которая способна создать программу в четыре раза быстрее, чем ее конкурент, имеет значительное преимущество. История доказывает, что клиенты ценят инновационные продукты, которые сначала могут быть незавершенными, но постепенно быстро совершенствуются. Организации внедряют DevOps для того, чтобы уменьшить стоимость времени при задержке циклов разработки и удовлетворить потребности клиентов.
С использованием DevOps разработчики могут выпускать новые версии своих программ, тестировать их и развертывать для клиентов за несколько часов. Это не значит, что версии всегда выпускаются так быстро, — для должной проверки качества (QA) тоже требуется время, но DevOps при необходимости предоставляет возможность быстрее двигаться дальше. Рисунок 1.2 дополняет нижнюю часть рис. 1.1, чтобы подробнее описать то, как техники непрерывных интеграции и поставки, а также инфраструктура как сервис применяются вместе для ускорения циклов релизов.
Рис. 1.2. Непрерывная интеграция (CI), непрерывная поставка (CD) и инфраструктура как сервис (IaaS) формируют автоматизированный конвейер, который позволяет DevOps ускорять тестирование и развертывание программы
Ключевым компонентом конвейера на рис. 1.2 являются цепочки автоматизированных стадий: полностью автоматизированное движение от отправки разработчиком модификации программы до развертывания сервиса в среде эксплуатации. Если какая-либо из автоматизированных стадий проходит неудачно, весь конвейер останавливается и код не развертывается. Этот механизм обеспечивает успешное прохождение всех тестов перед тем, как станет возможным выпуск новой версии программы в среду эксплуатации.
1.1.1. Непрерывная интеграция
Быстрая интеграция нового функционала в программу называется непрерывной интеграцией (Continuous Integration, CI). CI определяет рабочие процессы для внедрения, тестирования и слияния функциональностей в программном продукте. Менеджеры по продукту и разработчики определяют набор малых функций, которые внедряются в течение коротких циклов. Каждая функция добавляется в ответвление основного исходного кода и отправляется на дружескую проверку коллеге ее разработчика. Автоматизированные тесты производятся на стадии проверки для того, чтобы убедиться: изменения не спровоцировали появления отклонений в существующем функционале и уровень качества сохранился. После проверки изменения сливаются с основным репозиторием исходного кода, теперь они готовы для развертывания. Быстрая циклическая обработка малых функций упрощает процесс и предотвращает появление неисправностей в функциональности, что происходит при внесении значительных изменений в код.
1.1.2. Непрерывная поставка
Автоматизацию развертывания программ в сервисах, доступных для пользователей, называют непрерывной поставкой (Continuous Delivery, CD). Вместо управления компонентами инфраструктуры вручную DevOps предлагает инженерам программировать инфраструктуру для быстрой обработки изменений. Когда разработчики выполняют слияние кода с изменениями в программе, специалисты по эксплуатации запускают развертывание обновленной программы из CD-конвейера, который автоматически извлекает последнюю версию исходного кода, упаковывает ее и создает для нее новую инфраструктуру. Если развертывание проходит гладко, то, возможно, после ручной или автоматизированной проверки QA-командой среда преобразуется в новую переходную среду или среду эксплуатации. Пользователей перенаправляют на нее, а старую среду извлекают. Процесс управления серверами и сетями с кодом смягчает проблему появления долгих задержек, которые вызваны работой с процессами развертывания.
1.1.3. Инфраструктура как сервис
Инфраструктура как сервис (Infrastructure-as-a-Service, IaaS) — облако. Это означает, что центр обработки данных, сеть, иногда системы, на которые полагается организация, полностью обслуживаются третьей стороной и управляются посредством API и кода, открытых для операторов в качестве сервиса. IaaS — основной инструмент в арсенале DevOps, так как он играет важную роль в уменьшении стоимости управления инфраструктурой. Программируемая природа IaaS делает ее отличной от традиционных видов инфраструктуры. Также она позволяет специалистам по эксплуатации писать код, который создает и модифицирует инфраструктуру, вместо того чтобы работать над этим вручную.
Штатная эксплуатация
Многие организации предпочитают инфраструктуру, управляемую штатно, по целому ряду причин (контролируемость, безопасность, стоимость и т.д.). Важно заметить, что применение IaaS не обязательно предполагает передачу управления инфраструктурой третьей стороне. Организация может штатно развертывать IaaS и управлять ею с применением платформ, таких как Kubernetes или OpenStack, для того чтобы пользоваться преимуществом гибкости этих промежуточных уровней управления при непосредственном запуске приложений на оборудовании.
В рамках книги мы рассмотрим применение системы IaaS. Ее обслуживает сторонний ресурс AWS, популярный во множестве организаций благодаря своей способности упрощать управление инфраструктурой, что позволяет сосредоточиться на самом продукте. Большинство концепций инфраструктуры, представленных в этой книге, применимы к любому типу IaaS независимо от того, обслуживают ли оборудование штатные специалисты, или этим занимается третья сторона.
Управление низшими слоями инфраструктуры создает целый ряд новых проблем, касающихся безопасности сетей и управления доступом к центру обработки данных, о которых стоит подумать заранее. Я не раскрываю эти вопросы в книге, так как они проявляются не только в DevOps. К тому же сейчас легко найти соответствующую информацию в заслуживающих доверия литературных источниках.
Amazon Web Services (AWS), задействованные в качестве среды во всей книге, выступают показательным примером IaaS. На рис. 1.3 демонстрируются компоненты AWS, обслуживаемые поставщиком (внизу), в сравнении с теми, которые обслуживают специалисты по эксплуатации (вверху).
CI, CD и IaaS — это фундаментальные компоненты успешной стратегии DevOps. Организации, которые осваивают рабочие процессы CI/CD/IaaS, способны быстро развертывать программы для конечных пользователей до нескольких раз в день в полностью автоматизированном режиме. Автоматизация всех стадий тестирования и развертывания обеспечивает минимальное вовлечение человека в обслуживание конвейера, а также полную восстанавливаемость инфраструктуры в случае аварии.
Помимо предоставления технических преимуществ, DevOps влияет на культуру взаимодействия в организации и во многих случаях способствует увеличению уровня удовлетворенности людей.
Рис. 1.3. AWS — это IaaS, уменьшающая нагрузку отдела эксплуатации и обслуживающая основные компоненты инфраструктуры. Оборудованием в нижнем прямоугольнике управляет Amazon, специалист по эксплуатации контролирует компоненты в верхнем прямоугольнике. В пределах традиционной инфраструктуры эти специалисты должны управлять всеми компонентами самостоятельно
1.1.4. Культура и доверие
Усовершенствование инструментов — первая ступень успешного применения DevOps-подхода. Смена культуры сопровождает изменения, а организации, которые продвигаются в технических аспектах DevOps, обретают уверенность в своей способности поставлять новые продукты пользователям. Любопытный побочный эффект, повышающий доверие к технологии, — сокращение объемов обслуживания, так как инженерам предоставляется возможность приносить пользу организации с минимальными издержками. Некоторые DevOps-организации шагнули дальше, экспериментируя с линейной структурой, в которой совсем не было менеджеров. И хотя исключение менеджеров из технологического процесса — рискованная затея, подходящая не всем организациям, тенденция к сокращению менеджмента явно связана с развитием DevOps-сред.
Организации, которые заимствуют принципы DevOps, зачастую лучше способны находить таланты и сохранять их. Часто можно услышать, как разработчики и специалисты по эксплуатации выражают недовольство по поводу работы с медлительными и беспорядочными средами. Разработчики раздражаются, неделями ожидая развертывания модификации в эксплуатационной системе. Специалисты по эксплуатации, менеджеры продукта и проектировщики — все не в восторге от медленных итераций. Люди уходят из таких компаний. Усиление текучки кадров может негативно сказаться на качестве продукта. Компании, которые стремительнее предоставляют продукты на рынок, обладают преимуществом перед конкурентами: они не только быстрее доставляют функциональность пользователям, но и поддерживают степень удовлетворенности своих инженеров, избегая сложностей эксплуатации.
Система DevOps учит нас тому, что ускоренная поставка программных продуктов оздоравливает организации и делает их более конкурентоспособными. Однако это может усложнить работу инженеров по безопасности. Быстрые циклы релизов оставляют мало возможностей для тщательной проверки безопасности и вынуждают организации брать на себя повышенные риски по сравнению с теми, кто реализует более медлительные методологии. Внедрение безопасности в DevOps подвергает команды новым испытаниям, которые начинаются с фундаментального сдвига в культуре безопасности.
1.2. Безопасность в DevOps
Пока корабль в порту, он в безопасности, но корабли строят не для этого.
Джон А. Шедд
Чтобы быть успешными на конкурентном рынке, организациям следует быстро развиваться, брать на себя риски и работать за разумную плату. Роль команд, обеспечивающих безопасность, в таких организациях состоит в том, чтобы быть барьером, который защищает ресурсы компании и в то же время помогает им преуспевать. Такие команды должны тесно взаимодействовать с инженерами и менеджерами, работающими над созданием продуктов компании. Когда компания начинает внедрять принципы DevOps, в первую очередь стоит сосредоточиться на клиенте.
DevOps и его предшественники — Agile-манифест (http://agilemanifesto.org/) и 14 принципов Деминга (https://deming.org/explore/fourteen-points) — имеют одну общую черту — стремление к ускоренной поставке заказчику улучшенных продуктов. Каждая успешная стратегия начинается с сосредоточенности на заказчике (http://mng.bz/GN43).
Мы не одержимы конкуренцией, мы одержимы заказчиком. Мы начинаем с того, что необходимо заказчику, и работаем, отталкиваясь от этой информации.
Джефф Безос, Amazon
В рамках DevOps все, кто задействован в конвейере продукта, преследуют цели заказчика.
• Менеджеры продукта оценивают показатели взаимодействия и задержек.
• Разработчики оценивают эргономику и практичность.
• Специалисты по эксплуатации оценивают продолжительность работоспособного состояния и время ответа.
Все внимание компании обращено на заказчика. Удовлетворенность заказчика является показателем, увеличение которого — цель всех команд.
Для сравнения: многие команды по безопасности концентрируются на задачах, охватывающих только аспекты безопасности, таких как:
• соответствие стандартам безопасности;
• количество инцидентов, касающихся безопасности;
• количество неисправленных уязвимостей в эксплуатационных системах.
Когда внимание компании направлено не на заказчика, команды безопасности фокусируются на ее внутренней среде. Одна сторона желает увеличить ценность организации, другая — защитить существующую ценность. Обе они необходимы для обеспечения полноценности экосистемы, но отвлеченность от главной цели негативно влияет на взаимодействие и эффективность.
Организации, оценивающие показатели и производительность отдельных команд для распределения бонусов и назначения вознаграждений, поощряют игнорирование других команд и сосредоточенность только на собственных результатах. Достигая своей цели, разработчики и специалисты по эксплуатации игнорируют рекомендации по безопасности, поставляя продукты, которые могут оказаться рискованными. Команды по безопасности вносят задержки в проекты, в которых применяются небезопасные техники, и рекомендуют нереалистичные решения, чтобы избежать случаев, наносящих вред основным аспектам безопасности. В таких ситуациях обе стороны зачастую приводят весомые аргументы в защиту своей позиции, действуют с лучшими намерениями, но не справляются с достижением договоренности.
Будучи инженером по безопасности, я никогда не встречал команды разработчиков и специалистов по эксплуатации, которые не заботились о безопасности, но встречал сотрудников, разочарованных плохим взаимодействием и расхождением целей. Команды по безопасности, которым не хватало понимания стратегии продукта, выполняли произвольные проверки безопасности. Последние задерживали поставку функциональности или нуждались в сложном управлении, которое было трудно реализовать, — это признаки системы безопасности, представляющей из себя все что угодно, только не Agile. В то же время команды продукта, которые игнорируют опыт и обратную связь с командой по безопасности, содействуют появлению источника риска, который по большому счету вредит всей организации.
DevOps учит нас: для успешной стратегии необходимы сближение стороны эксплуатации со стороной разработки, а также разрушение коммуникационного барьера между различными разработчиками и специалистами по эксплуатации. Безопасность в DevOps должна начинаться с близкого взаимодействия команд по безопасности и их коллег-инженеров. Безопасность должна служить клиенту, выступая в качестве функции сервиса, а внутренние цели команд по безопасности и DevOps-команды должны быть связаны.
Когда безопасность становится составляющей DevOps, инженеры по безопасности могут настроить управление непосредственно в продукте, вместо того чтобы, по сути, «прикручивать» его сверху продукта. Все преследуют одну цель — успех организации. Когда цели связаны, улучшается взаимодействие и усиливается безопасность данных. Основная идея, в основе которой — объединение безопасности и DevOps, заключается в том, что командам по безопасности следует брать техники DevOps и переключать внимание с изолированной защиты инфраструктуры на защиту всей организации, постоянно совершенствуясь.
На протяжении всей книги я буду называть этот подход непрерывной безопасностью. В следующем разделе вы узнаете, как постепенно добиться непрерывной безопасности, начав с простого легко реализуемого управления безопасностью, а затем стремительно совершенствуя стратегию безопасности, чтобы охватить всю организацию.
1.3. Непрерывная безопасность
Непрерывная безопасность состоит из трех областей (на рис. 1.4 обведены прямоугольниками). Каждая область сосредоточена на особом аспекте конвейера DevOps. Отзывы заказчика стимулируют организационный рост, который способствует появлению новой функциональности. Так происходит и в непрерывной безопасности. Эта книга состоит из трех частей, каждая раскрывает одну область непрерывной безопасности.
•Безопасность на основе тестирования (test-driven security, TDS) — первыми шагами к безопасности программы являются определение, реализация и тестирование управления безопасностью. TDS охватывает простые средства управления, такие как стандартная конфигурация Linux-сервера или заголовки безопасности, которые должны быть реализованы в веб-приложениях. Значительной безопасности можно добиться последовательной реализацией основных мер безопасности и их жестким тестированием на точность. В эффективной системе DevOps случаи ручного тестирования должны быть исключением, а не правилом. Тестировать безопасность следует так же, как и все приложения в CI- и CD-конвейерах: автоматически и повсеместно. Мы раскроем TDS, применяя уровни безопасности в простом DevOps-конвейере (см. часть I).
• Мониторинг и реагирование на атаки. Пережить вторжение — судьба всех онлайн-сервисов. Когда случаются подобные инциденты, организации обращаются за помощью к своим командам по безопасности. Последние должны быть готовы к ответным действиям. Второй фазой непрерывной безопасности выступают мониторинг и реагирование на угрозы, а также защита сервисов и критических для организации данных. В части II я расскажу о таких техниках, как выявление мошенничества и вторжений, цифровая криминалистика, реагирование на инциденты. Это сделано, чтобы лучше подготовить организации к таким случаям.
•Оценка рисков и усиление безопасности. Мы будем много говорить о технологиях в первых двух частях книги. Однако стратегия безопасности не может стать успешной, если основывается только на технических аспектах. Третьей фазой непрерывной безопасности выступает выход за пределы технологии и общий обзор безопасности в организации. В части III книги я объясняю, как управление рисками и тестирование безопасности, внешнее и внутреннее, помогают организациям переосмыслить действия в области безопасности, способствуют более эффективному вложению ресурсов.
Рис. 1.4. Три фазы непрерывной безопасности защищают продукты организации и клиентов, постоянно совершенствуя безопасность с помощью циклов обратной связи
Серьезные организации доверяют своим программам безопасности и работают во взаимодействии с командами по безопасности. Для того чтобы обеспечить такое сотрудничество, необходимы сосредоточенность, опыт и верное представление о том, когда нужно рисковать, а когда — отказываться от этого. Полноценная стратегия безопасности сочетает применение технологий и деятельности людей. Это поможет определить области, требующие модернизации, и ресурсы, необходимые для быстрого совершенствования.
Теперь, ознакомившись с моделью непрерывной безопасности, рассмотрим подробнее, что представляет собой каждый из трех ее компонентов с точки зрения безопасности продукта.
1.3.1. Безопасность на основе тестирования
Изощренные атаки хакеров с обходом уровней брандмауэра или расшифровка криптографической защиты хорошо выглядят в фильмах, но нечасто встречаются в реальном мире. В большинстве случаев атакующие ищут легкую добычу: веб-фреймворки с уязвимостями в безопасности, необновленные системы, административные страницы с легко угадываемыми паролями и ошибочно попавшие в сеть через открытый исходный код учетные данные — это наиболее популярные кандидаты в жертвы. При реализации стратегии непрерывной безопасности мы в первую очередь позаботимся об основах: нужно будет реализовать базовый набор мер безопасности в приложении и инфраструктуру организации, а в дальнейшем постоянно их тестировать. К примеру:
• вход администратора через SSH должен быть отключен во всех системах;
• системы и приложения должны быть модифицированы до последней доступной версии в течение 30 дней после выхода данного релиза;
• веб-приложения должны использовать протокол HTTPS — никакого HTTP;
• секретные и учетные данные нельзя хранить в коде приложения, следует содержать их в отдельном хранилище, доступном только для специалистов по эксплуатации;
• интерфейсы администрирования нужно защитить VPN-соединением.
Список лучших методов нужно согласовать между командами безопасности, разработки и эксплуатации, чтобы добиться одинакового восприятия их полезности. Из этих методов можно быстро составить перечень основополагающих требований, включив здравый смысл. В части I книги я расскажу, какие шаги следует предпринимать для защиты приложений, инфраструктуры и CI/CD-конвейеров.
Безопасность приложения
Современные веб-приложения подвергаются различным видам атак. Открытый проект обеспечения безопасности веб-приложений (OWASP) каждые три года составляет и публикует рейтинг десяти самых распространенных (http://mng.bz/yXd3): межсайтовые сценарии, SQL-инъекции, подделка межсайтовых запросов, метод грубой силы и так далее до бесконечности. К счастью, любую атаку можно предотвратить, правильно и в нужном месте применяя меры безопасности. В главе 3 мы подробнее рассмотрим приемы, которые DevOps-команда должна реализовать для того, чтобы поддерживать защиту веб-приложений.
Безопасность инфраструктуры
Если для запуска программ вы применяете IaaS, это не значит, что DevOps-команде можно не беспокоиться о безопасности инфраструктуры. Все системы имеют точки входа, наделенные определенными привилегиями: VPN, SSH-интерфейсы и панели администрирования. Когда компания расширяется, необходимо уделять особое внимание непрерывной защите систем и сетей при открытии новых прав доступа и интегрировании всех составляющих в одно целое.
Безопасность конвейера
Метод, с помощью которого DevOps автоматически развертывает продукты, сильно отличается от традиционных методов, используемых большинством команд по безопасности. Соглашаясь на применение CI/CD-конвейеров, нужно учитывать, что это может дать хакеру полный контроль над программами, запущенными в среде эксплуатации. Выполняемые автоматически действия, предназначенные для развертывания кода в системах среды эксплуатации, можно защитить, внедрив контроль целостности, такой как подписание коммитов или контейнеров. Я расскажу, как увеличить надежность CI/CD-конвейеров и обеспечить целостность кода, запущенного в среде эксплуатации.
Непрерывное тестирование
В каждой из трех названных областей управлять безопасностью довольно просто в изолированной среде. Сложности возникают, когда нужно повсеместно и постоянно тестировать и реализовывать управление. Здесь вступает в действие безопасность на основе тестирования (test-driven security, TDS). Подход TDS аналогичен методу разработки через тестирование (TDD), при котором разработчикам рекомендуется писать сначала тесты, представляющие желаемое поведение, а затем код, реализующий сами тесты. TDS предлагает сначала писать тесты безопасности, представляющие ожидаемое состояние, а затем реализовывать меры безопасности, которым предстоит проходить эти тесты.
В традиционной среде реализовать TDS будет непросто, так как тесты потребуется внедрять в работающие годами системы. Но в DevOps каждое изменение программного обеспечения или инфраструктуры проходит через CI/CD-конвейер, и это прекрасное место для реализации TDS (рис. 1.5).
Подход TDS имеет некоторые преимущества.
• Необходимость создания тестов способствует тому, что инженеры по безопасности чаще уточняют и документируют ожидаемый результат. Так они смогут создавать продукты, точно зная, какие меры безопасности потребуется предпринять, вместо того чтобы задумываться о них после реализации.
• Меры безопасности должны представлять собой небольшие конкретные операции, которые легко тестировать. Нечетких требований вроде «шифровать взаимодействие по сети» стоит избегать, вместо этого мы используем явное «нужно усилить HTTPS-шифрованием X, Y и Z на всем трафике», которое четко называет ожидаемый результат.
• Показатель повторного использования тестов в продуктах высокий, так как большинство продуктов и сервисов пользуются одной и той же основной инфраструктурой. Если набор основных тестов уже разработан, то команда безопасности сможет сосредоточиться на более сложных задачах.
• Недостающие меры безопасности обнаруживаются до развертывания, что позволяет разработчикам и специалистам по эксплуатации исправить проблемы до релиза, не подвергая клиентов рискам.
Рис. 1.5. Безопасность на основе тестирования внедряется в CI/CD для выполнения тестов безопасности перед развертыванием в среде эксплуатации
При подходе TDS тесты сначала должны выдавать неудовлетворительный результат. В этом случае можно будет убедиться в том, что они работают правильно. В первую очередь команды по безопасности должны помочь разработчикам и специалистам по эксплуатации реализовать меры безопасности в их программах и инфраструктуре, проводя все тесты один за другим и корректируя процесс реализации. В итоге проведение тестов передается DevOps-командам. Когда тест проходит успешно, команды уверены в том, что контроль реализован правильно.
При TDS важно представлять безопасность как отдельную функциональность продукта. Для этого меры безопасности реализуются непосредственно в коде или системе продукта. Работа команд по безопасности, выстраивающих защиту вне самого приложения и инфраструктуры, вызывает меньше доверия, поэтому лучше воздерживаться от такого подхода. Он не только создает напряженность между командами, но и не обеспечивает полноценной защитой, так как люди, отвечающие за безопасность, недостаточно хорошо осведомлены о функционировании приложения и упускают важные детали. Стратегия безопасности, которая формируется только в пределах команды инженеров, не проживет долго и со временем медленно придет в упадок. Крайне важно, чтобы команда безопасности определяла, реализовывала и тестировала стратегию безопасности, а также чтобы ведение ключевых компонентов было доверено нужным людям.
TDS ориентируется на принципы DevOps в части автоматизации конвейера и тесного взаимодействия с командами. По этой причине специалисты из отдела безопасности выстраивают и тестируют управление безопасностью в пределах сред, используемых разработчиками и специалистами по эксплуатации, а не создают для этого отдельную инфраструктуру. Внедрение базовых защитных мер с помощью TDS значительно сокращает риски вторжения в сервис, но не избавляет от необходимости наблюдать за средой эксплуатации.
1.3.2. Мониторинг и реагирование на атаки
В свободное время инженеры по безопасности любят играть в игры. Одной из наших любимых игр в середине 2000-х годов была такая: мы устанавливали виртуальную машину с Windows XP с неисправленными уязвимостями, подключали ее непосредственно к Интернету (без брандмауэра, антивируса или прокси) и ждали. Догадаетесь, сколько приходилось ждать, пока ее взломают?
Сканеры, которыми управляли создатели вредоносных программ, быстро обнаруживали систему и высылали одно из множества средств, к воздействию которых была уязвима операционная система Windows XP. За несколько часов ее взламывали, и открывалась лазейка для обхода системы безопасности, чтобы внедрить еще большее количество вирусов и наводнить ими ОС. Наблюдать за этим было забавно, но более замечательным было то, что мы получали важный урок: все системы, имеющие выход в Интернет, в конечном счете будут взломаны — без исключений.
Управление популярным сервисом в сети общего доступа, по сути, аналогично эксперименту с Windows XP: сканер его точно так же обнаружит и попытается взломать. Хакер может атаковать отдельных пользователей, пытаясь угадать их пароли, или вывести из строя сервис и потребовать выкуп, или внедриться через уязвимость в инфраструктуре и достичь уровня данных, чтобы извлечь информацию.
В современных организациях используются довольно сложные и разнообразные приложения, и защитить все их аспекты, заплатив за это разумную цену, зачастую не представляется возможным. Команды по обеспечению безопасности должны выстраивать приоритеты. Грамотный подход к мониторингу и реагированию на атаки состоит из трех компонентов:
• журналирования и выявления нарушений;
• обнаружения вторжений;
• реагирования на инциденты.
Организации, которые могут внедрить все три компонента, будут подготовлены к вторжению. Кратко рассмотрим каждую из этих составляющих.
Журналирование и обнаружение нарушений
Любой компании необходимо создавать, хранить и анализировать журналы. Разработчикам и специалистам по эксплуатации они необходимы для наблюдения за состоянием сервисов. Менеджеры продуктов используют их для оценки популярности функционала или посещаемости. С точки зрения безопасности мы будем преследовать две цели:
• обнаружение аномалий в безопасности;
• предоставление возможностей для проведения экспертизы при расследовании инцидентов.
Было бы идеально постоянно собирать данные в журналы и анализировать их, но это осуществимо лишь в редких случаях. Огромные объемы данных хранить непрактично. В части II книги я расскажу о том, как выбирать журналы для анализа командой по безопасности и сосредоточить усилия на специфичных областях DevOps-конвейера.
Мы изучим концепцию конвейера журналирования для обработки и концентрации событий журналов из различных источников. Конвейеры журналирования — мощный инструмент, так как они предоставляют единый канал, в котором можно обнаруживать аномалии. Проще работать с этой моделью, чем просить каждый компонент выявлять вторжения самостоятельно, но реализовать ее в большой среде может быть затруднительно. Обзор ключевых компонентов конвейера журналирования, о которых я расскажу более детально в главе 7, сделан на рис. 1.6. В нем пять уровней.
• Уровень сбора для фиксирования событий журналов из различных компонентов инфраструктуры.
• Уровень потоковой передачи для захвата и перенаправления событий журналов.
• Уровень анализа, с помощью которого можно изучить содержимое журналов, обнаружить вторжения и поднять тревогу.
• Уровень хранения для архивации журналов.
• Уровень доступа, позволяющий предоставить специалистам по эксплуатации и разработчикам доступ к журналам.
Мощный конвейер журналирования обеспечивает команду по безопасности основной функциональностью, необходимой для наблюдения за инфраструктурой. В главе 8 я расскажу о том, как выстроить целостный уровень анализа в конвейере журналирования, и продемонстрирую различные техники, полезные для мониторинга систем и приложений. Это заложит основы для работы с обнаружением вторжений в главе 9.
Рис. 1.6. Конвейер журналирования реализует стандартный канал, в котором анализируются и хранятся события, происходящие в инфраструктуре
Обнаружение вторжений
Вторгаясь в инфраструктуру, атакующие обычно выполняют четыре шага.
1. Отправляют полезную нагрузку на целевые серверы. Полезная нагрузка — это некий небольшой бэкдорный скрипт или вредоносный код, который может быть загружен и выполнен, не привлекая внимания.
2. Развернутая полезная нагрузка связывается с источником для получения дальнейших инструкций с помощью канала контроля и управления (command-and-control, C2). С2-каналы могут принимать форму исходящего IRC-соединения, HTML-страниц, которые содержат особые ключевые слова, спрятанные в теле страницы, или DNS-запросов с командами, помещенными в текстовые записи.
3. Бэкдор выполняет все инструкции и пытается двигаться по горизонтали внутри сети, сканируя другие узлы и проникая в них, пока не достигнет цели, имеющей ценность.
4. Когда цель найдена, ее данные извлекают, чаще всего через канал, параллельный C2.
В главе 8 я объясню, как каждый из этих шагов может быть обнаружен бдительной командой по безопасности. Мы сосредоточимся на мониторинге и анализе сетевого трафика и событий системы с помощью следующих инструментов безопасности.
•Система обнаружения вторжений (intrusion detection system, IDS). На рис. 1.7 показано, как IDS может выявить C2-канал, постоянно анализируя копию сетевого трафика и применяя сложную логику к сетевым соединениям, чтобы обнаружить мошенническую активность. Системы IDS прекрасно подходят для исследования гигабайтов сетевого трафика в реальном времени, выявляя модели такой активности, и пользуются доверием множества команд по безопасности. Мы изучим, как их использовать в среде IaaS.
Рис. 1.7. Системы обнаружения вторжений могут обнаружить аномальные узлы, которые связываются с источником. При этом выявляются модели преступной активности и к исходящему трафику применяется статистический анализ
• Контроль за соединениями. Обеспечить анализ всего сетевого трафика, проходящего по инфраструктуре, не всегда реально. NetFlow предоставляет альтернативу отслеживанию сетевых соединений, журналируя их в конвейере. NetFlow — это замечательный способ контролировать активность сетевого уровня в среде IaaS, когда невозможно предоставить низкоуровневый доступ.
• Контроль систем. Контроль целостности реальных систем — замечательный способ отслеживания того, что происходит в инфраструктуре. В операционной системе Linux подсистема отслеживания в ядре может журналировать системные вызовы. Атакующие зачастую не учитывают этот тип журналирования при проникновении в системы, и отправка событий отслеживания в конвейер журналирования может помочь обнаружить вторжение.
Обнаружить вторжения сложно, зачастую для этого требуется тесное взаимодействие команд по безопасности и эксплуатации. При неправильном использовании эти системы могут потреблять ресурсы, предназначенные для управления сервисами среды эксплуатации. Вы увидите, как прогрессивный и консервативный подходы к обнаружению вторжений повышают эффективность их внедрения в DevOps.
Реагирование на инциденты
Возможно, самая напряженная ситуация, с которой может столкнуться организация, — это реагирование на проникновения. Нарушение безопасности создает хаос и вносит неопределенность, которая может серьезно пошатнуть стойкость даже самых стабильных компаний. В то время как команды инженеров борются за восстановление целостности систем и приложений, руководство занимается ликвидацией последствий и должно гарантировать бизнесу скорое восстановление нормальной эксплуатации.
В главе 10 я познакомлю вас с шестью фазами, которые организации должны пройти, реагируя на инциденты нарушения безопасности. Они перечислены далее.
•Подготовка — необходимо убедиться, что у вас имеется допустимый минимум процессов для действий после инцидентов.
• Идентификация — требуется быстро решить, является ли аномалия инцидентом нарушения безопасности.
• Изоляция — предотвратить дальнейшее проникновение.
• Искоренение — избавить организацию от угрозы.
• Восстановление — вернуть деятельность организации в нормальное состояние.
• Извлечение уроков — снова рассмотреть инцидент, чтобы сделать выводы.
Каждый случай нарушения безопасности уникален, и организации реагируют на них по-разному, что затрудняет формирование универсальных ответов на вопросы. В главе 10 мы рассмотрим практический пример реагирования на инцидент. В нем будет продемонстрировано, как обычная компания проходит через этот разрушительный процесс, как можно чаще используя техники DevOps.
1.3.3. Оценка рисков и усиление безопасности
Полноценная стратегия непрерывной безопасности выходит за рамки технических аспектов реализации управления безопасностью и реагирования на инциденты. Хоть их описание и дается на протяжении всей книги, человеческий фактор в непрерывной безопасности наиболее значим, когда речь идет об управлении рисками.
Оценка рисков
Многие инженеры и менеджеры представляют себе управление рисками в виде больших таблиц с цветными ячейками, которые сложены в папки входящих сообщений. Это, к сожалению, приводит к тому, что многие организации начинают избегать управления рисками. В части III книги я расскажу о том, как изменить такое отношение и сформировать рациональное и эффективное управление рисками в DevOps-организации.
Управление рисками связано с идентификацией и определением приоритетности проблем, угрожающих выживанию и развитию. Цветные ячейки в таблицах и правда могут помочь, но суть не в них. Верный подход к управлению рисками должен преследовать три цели.
• Оценивать риски следует в пределах небольших итераций, часто и быстро. Программы и инфраструктура постоянно меняются, и организация должна быть способна обсуждать риски сразу, а не с недельной задержкой.
• Автоматизируйте! Это DevOps, и исполнение задач вручную должно быть исключением, а не правилом.
• Требуйте, чтобы вся организация участвовала в обсуждении рисков. Создание безопасных продуктов и поддержание безопасности — это командная работа.
Фреймворк управления рисками, помогающий достичь всех этих целей, представлен в главе 11. При правильной реализации он может стать действительно полезным приобретением для организации и превратиться в один из основных компонентов жизненного цикла продукта, который вся организация будет ценить и использовать.
Тестирование безопасности
Еще одним основным преимуществом зрелой программы безопасности является способность оценивать состояние регулярного тестирования безопасности. В главе 12 мы изучим три важные области успешной стратегии тестирования, которые помогут укрепить защиту организации.
• Оценка безопасности приложений и инфраструктуры изнутри с использованием таких техник безопасности, как сканирование уязвимостей, фаззинг (fuzzing), статический анализ кода или контроль конфигурации. Мы обсудим различные техники, которые можно внедрить в CI/CD-конвейер и превратить в часть жизненного цикла разработки программ (Software Development Lifecycle, SDLC) в стратегии DevOps.
• Использование услуг сторонних фирм для проверки безопасности основных сервисов. При правильно заданных целях внешние проверки безопасности могут принести организации большую пользу, а программам безопасности — свежие идеи и новые перспективы. Мы обсудим, как эффективно задействовать внешние проверки и «красные команды» и наилучшим образом использовать их среды.
• Запуск программы премирования за отлов неисправностей. DevOps-организации часто используют открытые источники и отправляют большие объемы кода в общий доступ. Это замечательные ресурсы для независимых исследователей безопасности, которые за несколько тысяч долларов протестируют ваши приложения и отчитаются о выявленных проблемах.
Совершенствование программы непрерывной безопасности занимает годы, но приложенные усилия приводят к тому, что команды по безопасности становятся неотъемлемой частью стратегии продукта в организации. В главе 13 мы завершим эту книгу рассуждением о том, как реализовать успешную программу безопасности за три года. Тесное взаимодействие между командами, правильное реагирование на нарушение безопасности и техническое наставничество помогают командам по безопасности обрести доверие коллег, чтобы иметь возможность полноценно поддерживать безопасность для клиентов. По сути, успешная стратегия непрерывной безопасности связана с максимальным сближением специалистов по безопасности, обладающих определенными инструментами и знаниями, с остальными DevOps-командами.
Резюме
• Чтобы по-настоящему защитить клиентов, команды по безопасности должны внедряться в продукт и работать в тесном взаимодействии с разработчиками и специалистами по эксплуатации.
• Безопасность на основе тестирования, мониторинг и реагирование на атаки, а также усиление безопасности — три фазы, которые ведут организацию к успешной реализации стратегии непрерывной безопасности.
• Традиционные техники безопасности, такие как сканирование уязвимостей, обнаружение вторжений и мониторинг журналов, должны быть приспособлены для DevOps-конвейера.
Часть I. Пример применения уровней безопасности к простому DevOps-конвейеру
В части I мы выстроим небольшую DevOps-среду для управления почти не защищенным веб-приложением. Наш конвейер пронизан дырами, которые мы будем закрывать на всех уровнях — приложения, инфраструктуры, каналов взаимодействия и развертывания. Перед нами поставлена задача послойного внедрения безопасности, при котором мы будем извлекать пользу из автоматизированного тестирования, представленного в концепции безопасности на основе тестирования из главы 1.
Безопасность — это путешествие. Создание собственного конвейера в главе 2 представит вам различные проблемы, с которыми обычно сталкиваются организации, и положит начало обсуждению внедрения безопасности в CI/CD-конвейер. В главе 3 мы обратимся к уровню приложения и порассуждаем о типичных атаках на веб-приложения и способах проверки и защиты от них. В главе 4 сосредоточимся на уровне инфраструктуры и обсудим техники защиты облачных данных. В главе 5 реализуется HTTPS для защиты каналов взаимодействия между конечными пользователями и вашей инфраструктурой. И наконец, глава 6 рассказывает о безопасности конвейера развертывания и методах, обеспечивающих целостность кода, начиная с поставки разработчиками и заканчивая выпуском в среду эксплуатации.
По завершении части I ваша среда, обладающая целостной безопасностью, будет готова для части II, где мы обсудим внешние атаки.
Глава 2. Выстраивание базового DevOps-конвейера
В этой главе
• Настройка CI-конвейера для приложения invoicer.
• Развертывание invoicer в AWS.
• Определение областей в DevOps-конвейере, на безопасность которых необходимо обратить внимание.
В главе 1 я описал многообещающую стратегию безопасности и рассказал, почему безопасность должна быть неотъемлемой частью продукта. Чтобы осмыслить безопасность в DevOps, мы сначала должны понять, как приложения выстраиваются, развертываются и эксплуатируются в DevOps. В данной главе мы проигнорируем безопасность и сосредоточимся на построении полностью функционирующего DevOps-конвейера, чтобы понять техники DevOps и приблизиться к стадии обсуждения безопасности в главах 3–5.
DevOps скорее раскрывает концепции, идеи и рабочие процессы, нежели рекомендует какую-то определенную технологию. Стандарта в DevOps вполне может и не быть, но есть распространенные шаблоны способов реализации. В этой главе мы рассмотрим частный пример применения этих шаблонов — invoicer, небольшой веб-API, который управляет приходными счетами с помощью множества конечных точек HTTP. Он написан на Go, и его исходный код доступен на https://securing-devops.com/ch02/invoicer.
2.1. Реализация схемы
Мы хотим управлять invoicer и эксплуатировать его в DevOps-манере. Для того чтобы этого добиться, предпримем в CI, CD и IaaS различные шаги, которые позволят нам быстро выпускать и развертывать новые версии программы для пользователей. Цель — пройти путь от отправки модификаций к развертыванию в среде эксплуатации менее чем за 15 минут, по большей части прибегая к автоматизированным процессам. Конвейер, который вы выстроите (рис. 2.1), состоит из шести шагов.
1. Разработчик пишет модификацию и публикует ее в репозитории на ветви функциональностей.
2. Выполняются автоматизированные тесты на приложении.
3. Коллега разработчика проверяет модификацию и выполняет ее слияние с основной ветвью в репозитории кода.
4. Новая версия приложения автоматически собирается и упаковывается в контейнер.
5. Контейнер публикуется в открытом каталоге.
6. Инфраструктура среды эксплуатации получает контейнер из каталога и развертывает его.
Рис. 2.1. Полный CI/CD/IaaS-конвейер для размещения invoicer состоит из шести шагов, после выполнения которых модификация передается в развернутое приложение
Для выстраивания этого конвейера потребуется внедрение нескольких компонентов, обеспечивающих взаимодействие. Вашей среде понадобится следующее.
•Репозиторий исходного кода. Существуют бесплатные и коммерческие решения для управления исходным кодом: Bitbucket, Beanstalk, GitHub, GitLab, SourceForge и т.д. На момент написания книги популярен GitHub, который мы и будем использовать для размещения кода invoicer.
• CI-платформа. И снова вариантов уйма: Travis CI, CircleCI, Jenkins, GitLab и т.д. В зависимости от своих потребностей и среды вы сможете выбрать подходящую CI-платформу. В этом примере используем CircleCI, так как она без труда интегрируется с GitHub и позволяет поддерживать SSH-доступ для сборки экземпляров, что пригодится для отладки шагов сборки.
• Репозиторий контейнера. Мир контейнеров быстро развивается, но Docker — признанный стандарт на время написания книги. Мы будем использовать репозиторий, предоставленный Docker Hub на hub.docker.com.
• Поставщик IaaS. Google Cloud Platform и Amazon Web Services (AWS) — самые популярные поставщики IaaS на момент написания книги. Некоторые организации предпочитают самостоятельно размещать свои IaaS и обращаются к таким решениям, как Kubernetes или OpenStack, для реализации уровня управления на собственном оборудовании (заметьте, что Kubernetes может быть использован также поверх EC2-экземпляров в AWS). В этой книге я задействую AWS, так как это наиболее востребованная и зрелая IaaS из имеющихся на рынке.
Подведем итоги выбора инструментов: код размещается на GitHub, из него производится вызов CircleCI, когда высылаются модификации. CircleCI собирает приложение в контейнер и отправляет его на Docker Hub. AWS запускает инфраструктуру и получает новые контейнеры из Docker Hub, чтобы обновить среду эксплуатации до последней версии. Просто и элегантно.
Каждая среда уникальна
Вряд ли среда в вашей организации идентична использованной в книге, и некоторые из более специфических мер безопасности нельзя будет применить непосредственно к инструментам, с которыми работаете вы. Это ожидаемо, и я раскрываю концепции безопасности на особенных реализациях, чтобы вы могли поместить их в свою среду без больших проблем.
К примеру, применение GitHub, Docker или AWS может сбить с толку, если в вашей организации используются другие инструменты. Я рассматриваю их в качестве инструментов обучения, чтобы объяснить техники DevOps. Относитесь к этой главе как к лаборатории для изучения концепций и экспериментов с ними. Эти концепции вы сможете реализовать на наиболее подходящей для вас платформе.
Помните, что даже традиционные инфраструктуры могут воспользоваться преимуществом от применения современных техник DevOps при самостоятельной сборке точно
таких же CI/CD/IaaS-конвейеров, как и у сторонних инструментов. Когда вы меняете технологию, меняются также инструменты и терминология, но общие концепции, в частности в безопасности, остаются прежними.
Этот конвейер применяет бесплатные инструменты и сервисы, по крайней мере в течение времени, достаточного для обучения. Предоставленные код и листинги вы можете копировать и воспроизводить, чтобы собрать свой конвейер. Настройка собственной среды будет отличным сопровождением чтения данной главы.
2.2. Репозиторий кода: GitHub
Перейдя на https://securing-devops.com/ch02/invoicer, вы будете перенаправлены на GitHub-репозиторий invoicer. В этом репозитории размещены исходный код приложения invoicer и скрипты, которые упрощают настройку инфраструктуры. Если вы хотите добавить собственную версию конвейера, создайте ответвление (fork) репозитория в своем аккаунте (при этом в ваше собственное пространство скопируются также все Git-файлы) и следуйте инструкциям, приведенным в файле README, чтобы настроить среду. В этой главе описываются подробности, необходимые для того, чтобы поднять и запустить свою среду, некоторые из них автоматизируются при помощи скриптов, размещенных в репозитории.
2.3. CI-платформа CircleCI
В данном разделе вы настроите CircleCI для выполнения тестов и сборки Docker-контейнера в ходе применения изменений к invoicer. Листинг в этом разделе применим к CircleCI, но концепция использования CI-платформы для тестирования и сборки приложения является общей и ее можно с легкостью воспроизвести на других CI-платформах.
Репозитории кода и CI-платформы, такие как GitHub и CircleCI, реализуют концепцию под названием «веб-хуки» для рассылки уведомлений. Когда в репозиторий кода вносятся изменения, веб-хук отправляет уведомление на веб-адрес, размещенный CI-платформой. В теле уведомления содержится информация об изменениях, которую CI-платформа использует для выполнения задач.
Когда вы входите в CircleCI с помощью своего аккаунта GitHub, CircleCI просит у вас разрешения производить действия от имени GitHub-аккаунта. Одним из этих действий будет автоматическая настройка веб-хука в GitHub-репозитории invoicer для уведомления CircleCI о новых событиях. Результат автоматической настройки веб-хука в GitHub показан на рис. 2.2.
Веб-хук используется на шагах 2 и 4 на рис. 2.1. Каждый раз, когда GitHub необходимо уведомить CircleCI об изменениях, GitHub отправляет уведомление на circleci.com. CircleCI получает уведомление и запускает сборку invoicer. Простота техники веб-хуков объясняет ее распространенность в службах интерфейсов, управляемых различными сущностями.
Рис. 2.2. Веб-хук между GitHub и CircleCI автоматически создается в репозитории invoicer для запуска сборки программы при внесении изменений
Примечание по поводу безопасности
GitHub имеет продуманную модель предоставления прав доступа, которая позволяет пользователям назначать права сторонним приложениям, несмотря на то что CI-платформы хотят иметь права доступа к чтению и записи во всех репозиториях пользователя. В главе 6 мы обсудим, как использовать аккаунт с ограниченными привилегиями и контролировать ваши права доступа, вместо того чтобы использовать вашего пользователя с широкими привилегиями для интегрирования с CI-платформой.
Файл конфигурации config.yml (рис. 2.3) расположен в репозитории приложения. Он написан в формате YAML и настраивает CI-среду для выполнения особых задач при каждом изменении, зафиксированном GitHub. В частности, вы настроите CircleCI для тестирования и компиляции приложения invoicer, чтобы затем собрать и отправить Docker-контейнер, который позднее развернете в AWS-среде.
Рис. 2.3. Конфигурация CircleCI содержится в каталоге .circleci в репозитории приложения
ПРИМЕЧАНИЕ
YAML — это язык сериализации данных, обычно используемый для настройки приложений. По сравнению с такими форматами, как JSON или XML, YAML представлен в более понятной человеку форме.
Далее полностью показан файл конфигурации CircleCI (листинг 2.1). Вы можете заметить, что некоторые его части представлены операциями командной строки, в то время как другие — это параметры, присущие CircleCI. Большинство CI-платформ позволяют операторам указывать операции командной строки, поэтому они прекрасно подходят для выполнения частных задач.
Некоторые части этого файла могут показаться непонятными, особенно про Docker и Go. Пока что пропускайте их (мы вернемся к ним позже) — сосредоточьтесь на идее конфигурационного файла. Как показано в этом листинге, его синтаксис декларативный. Это подобно тому, как если бы мы писали сценарий оболочки, выполняющий точно такие же операции.
Листинг 2.1. Файл config.yml настраивает CircleCI для приложения
Файл конфигурации должен храниться в репозитории кода. Если он существует, CircleCI станет использовать его инструкции, чтобы выполнять действия, когда от GitHub придет уведомление веб-хука. Для начала добавьте конфигурационный файл из листинга 2.1 в ветвь функциональностей в Git-репозитории и отправьте ее в GitHub (листинг 2.2).
Листинг 2.2. Создание Git-ветви функциональностей с модификацией добавления конфигурации CircleCI
Что такое запрос на включение
«Запрос на включение» — это термин, распространенный в GitHub, который обозначает запрос перемещения изменений из одной ветви в другую. Обычно он применяется для перемещения изменений из ветви функциональностей в основную. Запрос на включение открывается, когда разработчик отправляет модификацию на проверку. С появлением запросов на включение веб-хуки запускают автоматизированные тесты в CI (см. шаг 2 на рис. 2.1), и коллеги проверяют предложенную модификацию перед тем, как дать согласие на слияние (см. шаг 3 на рис. 2.1).
На рис. 2.4 показан пользовательский интерфейс запроса на включение в GitHub, ожидающий завершения тестов в CircleCI. CircleCI получает копию ветви функциональностей, считывает конфигурацию в config.yml и выполняет все шаги для сборки и тестирования приложения.
Рис. 2.4. Веб-интерфейс запроса на включение в GitHub демонстрирует статус выполнения тестов в CircleCI. Тесты в процессе выполнения желтые, они становятся зелеными, если CircleCI успешно справился, и красными при обнаружении неудачных результатов
Заметьте, что в соответствии с конфигурацией будут запущены только модульные тесты, которые выполняются как часть команды gotest. Раздел deploy в конфигурации станет исполняться только тогда, когда запрос на включение будет одобрен, а код слит с основной ветвью.
Предположим, что проверяющий остался доволен изменениями и одобрил запрос на включение, тем самым завершая шаг 3 конвейера. Модификация сливается с основной ветвью, и конвейер переходит к шагам 4 и 5 на рис. 2.1. CircleCI снова запустится, выполнит развертывание для сборки Docker-контейнера приложения и отправит его в Docker Hub.
