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

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

Не так, как раньше

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

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

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

Фронт внутренний и внешний

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

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

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

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

Далее следует подумать об обеспечении безопасности доступа к данным. Вице-президент компании AppDynamics Джон Кауэлл изучил подход к хранению данных, которому следует влиятельный пользователь микросервисов Netflix. «Для каждого сервиса в Netflix данные рекомендуют хранить отдельно, — указал он. — Это снижает зависимость сервисов друг от друга, но увеличивает объем хранимых данных».

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

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

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

Источник: Nginx

Дополнительные внутренние факторы

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

«Задача осложняется тем, что каждый микросервис разрабатывается независимо от других и имеет свой собственный набор языков и сред разработки, — отметил Гарретт. — Поэтому универсальных стандартов безопасности просто не существует».

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

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

Поделитесь материалом с коллегами и друзьями

Купить номер с этой статьей в PDF