На дворе наступила осень, во всю бушует техноутопия. Технологии стремительно рвутся вперед. Мы носим в кармане компьютер, вычислительная мощность которого в сотни миллионов раз больше мощности компьютеров, управлявших полетами на Луну. С помощью Youtube VR мы можем плавать в океане с медузами и китами, а роботы давно исследуют безжизненные горизонты холодных планет.

В это же время инженеры и специалисты ИТ-служб, разработчики и их бесчисленные коллеги разделились на два лагеря: тех, кто создает новые решения (ПО, стратегии, информационные системы), и тех, кто в них разбирается.

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

Микросервисная архитектура. Контейнеры

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

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

Касательно микросервисной архитектуры стоит отметить важный момент — среду ее выполнения. На сегодня широко распространенный вариант — это контейнеры (привет, Docker). Особенностью контейнеров является идея упаковки в них всего необходимого окружения, начиная с легковесного образа ОС, установленных пакетов, загруженных фреймворков и библиотек и заканчивая самим приложением. Чем же это полезно? Как минимум тем, что разработчик не сможет отмазаться объяснением «У меня на компе все работает», когда вы придете к нему с сообщением, что приложение не работает.

Контейнеры позволяют создавать приложения, упаковывать их вместе со всем окружением в готовый образ легковесной системы и больше не переживать из-за проблем, связанных с работой в различных средах. Понадобилось развернуть приложение на другом сервере? Запустили в контейнере рабочий образ с ним — и всё работает.

В информационной системе, построенной с использованием контейнеров, больше не надо переживать из-за версий ПО в среде, на которой запускаются приложения, а при реализованных процессах непрерывной доставки – и за доставку кода и т. д. Идея контейнера подразумевает, что разработка и сама работа приложения происходит в одной и той же контейнерной среде, и ввиду замкнутости микросервиса ему все равно, на какой операционной системе или с какими установленными пакетами в ней он работает. Приложение работает, потому что создавалось под среду контейнера, которая не меняется независимо от окружающей контейнер системы. Больше не нужно долго и нудно устанавливать все необходимое ПО, устанавливать связи, зависимости и пакеты. Не требуется вручную мигрировать приложения при переездах между средами разработки и развертывания или при увеличении мощностей вычислительных центров. Появился новый уровень абстракции, занявший свое место между конечным софтом с его пользователями и средой хоста (виртуальным или bare-metal), на которой все это работает. Этот подход в силу его удобства уверенно набирает обороты и сбавлять темп не собирается.

Многие крупные организации стремятся принять на вооружение лучшие методики для повышения эффективности бизнеса, его развития, масштабируемости и преобразований, в том числе в разрезе информационных систем. Ведь именно для крупного, digital oriented бизнеса в первую очередь интересны решения, направленные на гибкость, масштабируемость и мобильность, так как он, меняя индустрию, раньше всех становится подвержен сложностям, связанным с расширением, адаптацией под меняющийся рынок и т. д. Речь идет не обязательно об ИТ-компаниях. В контексте вопросов CI/CD и его безопасности в нашу организацию обращаются компании из госсектора, крупные игроки финансового рынка вроде банков и даже логистические монополисты. Во всех случаях объединяет их одно – использование контейнеров в том или ином виде при разработке приложений, сервисов и т. д.

Крупный бизнес часто сравнивают с акулами. В данном случае более подходящее сравнение трудно придумать. Вы видели, как акулы охотятся на стаи рыб? А замечали ли вы, насколько более маневренны мелкие рыбы, даже если они в большой стае? Кто резче реагирует, более маневренный и быстрый — акула или мелкая скумбрия? То же самое и с компаниями на рынке в целом. Мы, конечно, не берем в расчет Microsoft или Apple в те времена, когда они умещались в гараже, это единичные случаи. А вот статистически картина складывается такая, что крупные компании в состоянии диктовать тренды и задавать направление, однако мелким легче оперативно подстраиваться и адаптироваться. И вот крупные компании тоже стараются нарастить мобильность и гибкость доступными способами.

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

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

А как сделать процессы безопасными?

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

Однако не всегда удается все предусмотреть, за всем уследить и все промониторить. Вот как, например, понять, если версия SQL-сервера в контейнере содержит критичную уязвимость? Вручную? Допустим. А если контейнеров десятки? А сотни?

Как ИБ-специалист может быть уверен, что базовый образ ОС в контейнере с приложением не содержит скрытый эксплойт? Проверять вручную? А что именно проверять, где искать? На всех десятках и сотнях контейнеров? А где взять столько времени и ресурсов?

С развитием и распространением CI/CD острее встал вопрос обеспечения безопасности в цикле разработки. Ведь требуется быть уверенным хотя бы на приемлемом уровне в качестве образов, нужно знать об уязвимостях ПО и пакетов, о состоянии работающих контейнеров, не происходит ли в них подозрительных или явно нелегитимных действий. А если речь идет именно о цикле разработки, то стоило бы иметь инструменты для обеспечения безопасности в самом процессе разработки, в ее пайплайне, а не только в контейнерах. А еще нужен и контроль за секретами, аудит реестров, контроль за сетевым взаимодействием и так далее. И тут мы подходим к главному вопросу.

Зачем нужна безопасность, и в чем ее особенности в CI/CD?

По сути, речь идет о наборе практик для обеспечения безопасности внутри и вокруг цикла разработки. То есть это и использование специального ПО, и разработка методик и регламентов, и даже подготовка команд (команды – ключ ко всему!) к обеспечению безопасности. И важный момент: оправданное внедрение всей этой безопасности в разработку, а не рубка с плеча!

Тут остановимся подробнее. Привычный подход безопасности ИТ в целом и в разработке в частности, который приходит на ум, зиждется на постулатах «Запретить/Ограничить/Не пускать». Безусловно, самая безопасная информационная система – та, которая не работает вообще. Но работать-то она должна! И люди, использующие эту систему, также должны иметь возможность работать с ней.

Здесь имеет место конфликт интересов, о котором упомянули выше. ИБ-специалист стремится сделать среду безопасной и хочет иметь полный контроль над ней, разработчик стремится сделать продукт и хочет, чтобы это происходило быстро и удобно, а ИТ-инженер делает среду работоспособной, отказоустойчивой и вместе с разработчиком стремится к автоматизации.



Защита в CI/CD – это не про софт или регламенты, это про слаженность команд и встраивание концепта безопасности в поток разработки. Этот подход направлен на равномерную вовлеченность в процесс всех участников, на распределение четких зон ответственности, на автоматизацию, мониторинг и прозрачную отчетность. И самое главное – на внедрение безопасности внутрь процесса разработки приложений таким образом, чтобы она появлялась на ранних этапах и не требовала выделения дополнительных ресурсов, как вычислительных, так и человеческих.

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

Потрачено время спецов ИБ на локализацию проблемы, время команды разработки на исправление и еще немного, пока служба ИБ проведет повторный аудит и закроет кейс. Но что, если бы мы могли использовать какой-то инструмент и внедрить его еще на стадии разработки? Что, если бы наше приложение не выкатилось в продакт, будучи несоответствующим заданному уровню защищенности? И каждый специалист, участвующий в процессе, мог бы видеть, какие угрозы обнаружены в его зоне ответственности? А что, если весь этот процесс был бы еще и автоматизирован, начиная с обнаружения и заканчивая инцидентами в багтрекере?

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

Существуют инструменты и методики, которые позволяют контролировать состояние нужных элементов системы и этапов процесса разработки и помогают всем задействованным сторонам быть в курсе событий в рамках своей зоны ответственности. Акцент здесь ставится не на специализированном софте, а на взаимодействии людей с системой и между собой. Разработчику удобнее исправить и протестировать приложение прямо внутри работающего контейнера? Ну, пусть исправляет. Служба ИБ при этом хочет быть уверена, что внутри контейнера не происходит нелегитимных действий? Нет проблем, она будет в курсе всего. Задача выполнена, и никто никому не помешал в процессе. Эффективность и рациональность! И это возможно, если применить в среде разработки нужные инструменты ИБ в нужных местах и пересмотреть регламенты взаимодействия между службами и командами. И пусть тогда не настанет утопия, но согласитесь, жить и тем, и другим станет чуточку легче.

Зачем связывать руки разработчикам, и нагружать этим службу ИБ, если можно построить процессы так, чтобы разработчик творил, как умеет (самозабвенно, изнемогая в экстазе от совершенства своего кода), а специалист ИБ контролировал этот процесс (не вмешиваясь, а лишь разделяя это наслаждение со стороны).

Безопасность контейнеров. Стоит ли того?

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

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

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



«Не ищи клиента, найди проблему и предлагай решение – клиент сам появится».

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

Исходя из всего этого, мы предлагаем начинать с проведения аудита, включающего в себя не только состояние информационных систем и их элементов, но и понимание процессной составляющей между командами разработки, подходом служб ИБ и т.д. Не забываем, что люди – важнейший фактор и с точки зрения угроз, и для результатов функционирования системы. Аудит – необходимый этап, в результате которого могут выявиться важные недочеты системы или просчеты во взаимодействиях, которые совместно с заказчиком мы стараемся решить или переработать. Важно понимать, что целью является не нагромождение множества программных решений и продуктов и не затыкание ими обнаруженных уязвимостей. Напротив, вполне вероятен сценарий, при котором покупка дорогостоящих программных продуктов может и вовсе не потребоваться. Зачастую процесс увеличения безопасности в CI/CD-среде можно обеспечить с помощью уже имеющихся в организации средств защиты, как встроенных в среду контейнеризации (в оркестраторе, например), так и сторонних. Важно не столько их количество или качество, сколько правильное применение.

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

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

Например, один из подобных кейсов предполагал внедрение ПО защиты контейнеров и среды оркестрации. Казалось бы, внедрили, настроили, просканировали, увидели все уязвимости – а дальше долгий процесс устранения. Однако при таком подходе возникают проблемы, о которых говорилось в начале. У службы ИБ появился инструмент, позволяющий блокировать множество активностей в среде оркестрации, от которого при неправильном использовании больше вреда, чем пользы. У разработчиков связываются руки, ведь служба ИБ урезает их возможности. Например, больше нельзя поправить что-то внутри контейнера «на горячую», а при обнаружении уязвимости пакета в образе разработчик вовлекается в регламентную бюрократию. В итоге решение проблемы, которую можно было устранить в течение дня, затягивается на неопределенное время.

Во избежание подобных ситуаций мы рекомендуем выстроить процессы таким образом, чтобы служба ИБ находилась не в стороне от процесса разработки, как это часто бывает, а была ее участником. На это безусловно требуется некоторое время, но стоит отладить процесс, и жизнь действительно облегчается. Например, средства ИБ позволяют проводить мониторинг угроз уже на стадии сборки внутри CI/CD пайплайна, и служба ИБ может это регистрировать. При этом информация об угрозах на каждом этапе сборки может автоматически передаваться команде или специалисту, ответственному за конкретный этап, а тот в свою очередь предпримет необходимые действия по устранению угрозы. И все это происходит не под надзором с плетью, а под мониторингом службы ИБ.

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

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

И конечно, удобство! Безопасность может быть удобной.