Упрощенное управление безопасностью: защита ваших микросервисных приложений

В дополнение к статье приведу 13 популярных практик для обеспечения безопасности микросервисов

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

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

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

Проблемы безопасности, связанные с микрослужбами

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

Из-за большого количества открытых API, портов и компонентов традиционные межсетевые экраны не могут обеспечивать адекватной безопасности для них. Эти проблемы делают развертывание микросервисов более уязвимым для различных киберугроз, таких как «man-in-middle», инъекционные атаки, межсайтовый скриптинг, DDoS.

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

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

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

Среди них можно выделить следующие пункты системы безопасности:

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

Популярные практики для обеспечения безопасности микросервисов

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

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

Настала пора рассмотреть некоторые эффективные методы обеспечения безопасности микросервисов.

1. Безопасность от начала до конца

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

2. Использование концепции «глубокой защиты»

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

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

При таком подходе необходимо сначала определить чувствительные зоны сервиса, после чего можно будет применить соответствующие уровни защиты (=создать определенные «стены безопасности» вокруг них).
3. Развертывание системы безопасности на уровне контейнера

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

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

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

Среди типичных инструментов сканирования изображений можно выделить Clair и Anchore,

4. Развертывание многофакторной аутентификации

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

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

5. Использование идентификаторов пользователей и маркеров доступа

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

В типичном развертывании приложение предложит пользователю авторизовать стороннюю службу. После этого оно создает маркер доступа для сеанса.

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

6. Создание шлюза API

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

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

Шлюз API координирует все внешние службы и микрослужбы, а также поддерживает многоуровневую защиту системы, соблюдая принципы безопасности.

Среди типичных шлюзов API можно выделить NGINX, Kong, Tyk, Ambassador, AWS API gateway.

7. API-профили, которые созданы на основе зоны развертывания

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

— Ethernet API – интерфейсы для сервисов, открытых миру за пределами центра обработки данных;
— Corporate Zone API – предназначен для внутреннего частного трафика;
— DMZ API – предназначен для обработки трафика, идущего из Интернета;
— Hybrid Zone API – предназначен для развертывания центров обработки данных.

8. Обеспечение связи между службами

Эффективная практика включает в себя аутентификацию и авторизацию запросов при взаимодействии двух микросервисов.

Как правило, существует три основных метода, которые можно использовать для обеспечения безопасности межуслугных коммуникаций. Это Trust the network, JSON Web Token (JWT) и Mutual Transport Layer Security (mTLS или Mutual TLS).

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

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

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

9. Ограничение скорости клиентского трафика

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

Следует настроить свои службы на ограничение работы, если они обнаружат несколько неудачных попыток входа в API или любую другую подозрительную активность.

Медленная система отпугнет злоумышленников, и, вероятно, они откажутся от попыток получить доступ к услугам. Человек может ограничить скорость с помощью шлюза API, через код или использовать любой другой метод. Обычно большинство сред SaaS имеют ограничение по скорости API, чтобы свести к минимуму злоупотребления со стороны пользователей, а также предотвратить возможные атаки.

10. Использование менеджеров оркестрации

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

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

Двумя наиболее часто используемыми методами эффективной оркестровки микросервисов являются:

— Кодирование оркестрации как микросервиса;
— Использование шлюза IP.

Оркестровка через шлюз API не рекомендуется специалистами из-за проблем, связанных с необходимостью масштабирования служб.

11. Мониторинг всех систем и служб

Поскольку микросервисы основаны на распределенных системах, необходимо иметь надежную и эффективную стратегию мониторинга для всех отдельных компонентов.

Развертывание непрерывного мониторинга позволяет своевременно обнаруживать и устранять риски безопасности. Для этого существует широкий спектр решений по мониторингу микросервисов, в том числе Prometheus, Statsd, InfluxDB, Logstash.

Мониторинг внутри архитектуры микросервисов

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

— Ведение журналов на уровне приложения. Человек может использовать Splunk, Graphana, ELK stack и другие инструменты, которые создают журналы на уровне приложений, контейнеров, сетей и инфраструктуры;
— Мониторинг метрики использования сети;
— Контроль таких компонентов, как процессор, память, время отклика, ошибки, уведомления, чтобы обнаружить необычные действия, указывающие на существующую или потенциальную атаку;
— Проверка журналов в таких областях, как входящие запросы клиентов, записи базы данных, контейнеры, чтобы выявить несоответствия или необычные действия пользователей.

12. Автоматизация действий по обеспечению безопасности

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

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

13. Защита данных в любое время

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

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