13 лучших практик для защиты микросервисов

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

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

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

Архитектура «монолит-микросервисы» Изображение Красная Шапка

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

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

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

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

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

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

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

Типичные области для решения включают

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

Лучшие практики для защиты микросервисов

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

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

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

№1. Обеспечьте безопасность с самого начала 👮

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

№ 2. Используйте механизм глубокоэшелонированной защиты

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

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

Эшелонированная многоуровневая защита Изображение: Имперва

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

№3. Развертывание безопасности на уровне контейнера 📦

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

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

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

Типичные инструменты сканирования изображений включают Клэр, Якорьи более.

№ 4. Разверните многофакторную аутентификацию 🔒

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

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

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

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

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

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

№ 6. Создать шлюз API

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

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

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

Образ шлюза API микросервисов Живая книга

Типичные шлюзы API включают Nginx, Конг, Тык, посол, API-шлюз AWSи более.

Чтобы узнать больше о безопасности API, ознакомьтесь с нашим руководством Почему и как защитить конечную точку API.

№ 7. API-интерфейсы профилей на основе зоны развертывания

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

  • API-интерфейсы Ethernet — для служб, открытых внешнему миру за пределами центра обработки данных.
  • API-интерфейсы корпоративной зоны — предназначены для внутреннего частного трафика.
  • API-интерфейсы DMZ — для обработки трафика, исходящего из Интернета.
  • API-интерфейсы гибридной зоны — для развертывания центров обработки данных

№8. Защитите связь между службами

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

Как правило, существует три основных метода, которые можно использовать для защиты связи между службами. Это доверие к сети, веб-токен JSON (JWT) и взаимная безопасность транспортного уровня (mTLS или Mutual TLS).

Защита межсервисных коммуникаций с помощью JWT Image Живая книга

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

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

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

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

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

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

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

№10. Используйте диспетчеры оркестрации

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

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

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

  • Кодирование оркестровки как микросервиса
  • Использование шлюзов API для обеспечения уровня оркестровки

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

Уровень оркестровки микросервисов — образ Глобаллогик

Типичные инструменты управления оркестровкой включают Кубернетес, Истио, Служба Azure Kubernetes (AKS)так далее.

Чтобы узнать больше, изучите Container Orchestration for DeOps.

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

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

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

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

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

  • Включите ведение журнала на уровне приложения. Вы можете Splunk, Графана, ELK стеки другие инструменты, которые собирают журналы на уровне приложения, контейнера, сети и инфраструктуры.
  • Следите за показателями использования
  • Используйте тенденции таких показателей, как ЦП, память, время отклика, ошибки, уведомления и другие, для обнаружения необычных действий, свидетельствующих о существующей или потенциальной атаке.
  • Проведите аудит журналов в таких областях, как входящие запросы клиентов, записи базы данных, контейнеры и другие, чтобы выявить несоответствия или необычные действия.

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

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

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

№ 13. Всегда защищайте 🛡️ данные

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

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

Вывод

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

В идеале стремитесь уменьшить поверхность атаки, защитив среду микросервисов, API, приложения и данные.