Как обеспечить безопасность в микросервисных архитектурах по сравнению с монолитными приложениями?
Особенности микросервисов
В случае микросервисной архитектуры каждый отдельный микросервис имеет независимую точку входа для общения как с внешними пользователями, так и с другими сервисами. По мере увеличения количества точек входа в систему расширяется и область атаки. Такая ситуация является одной из основных проблем при разработке системы безопасности для приложений с микросервисной архитектурой. Каждая точка входа в каждый микросервис должна быть защищена с одинаковой степенью надежности. Как правило, у пользователей нет возможности обращаться к микросервисам напрямую, вместо этого микросервисы общаются друг с другом от лица пользователей. Для обеспечения безопасности необходимо реализовать механизмы аутентификации и авторизации доступа к микросервисам. Для этого можно использовать протоколы аутентификации, основанные на токенах или на сертификатах.
Одним из популярных способов решения задачи межсервисной аутентификации является JWT (Json Web Token). Помимо решения задачи защищенного межсервисного взаимодействия JWT помогает обеспечить передачу пользовательского контекста между сервисами.
Пользовательский контекст содержит информацию, относящуюся к пользователю, который обращается к приложению. Этот пользователь может быть человеком или системой (другим сервисом, например). Из-за распределенного характера микросервисов доступ к пользовательскому контексту осложняется, в отличие от приложения с монолитной архитектурой, где каждый компонент использует один сеанс с пользовательским контекстом, относящимся к запросу. При проектировании приложения с микросервисной архитектурой необходимо позаботиться о том, чтобы происходила доверенная передача пользовательского контекста от одного микросервиса к другому. JWT решает эту задачу.
Аутентификация пользователей и сервисов в приложениях с микросервисной архитектурой обширная тема, в которой помимо JWT, отдельного упоминания заслуживают стандарты OAuth2, OpenID Connect. Выбор в пользу того или иного решения, их комбинации для организации системы аутентификации зависит от модели пользователей, которую использует приложение.
Когда данные передаются из клиентской части или из одного микросервиса в другой микросервис, злоумышленник может перехватить или изменить данные в своих интересах. Таким образом, возникает задача обеспечения целостности передаваемых данных между сервисами приложения с микросервисной архитектурой. Наиболее распространенным способом обеспечения целостности сообщений является подпись. Например, любые данные, передаваемые по каналу связи, защищенному протоколом безопасности транспортного уровня (TLS), защищены с точки зрения целостности. Если вы используете HTTPS для обмена данными между микросервисами (по сути, это протокол HTTP с использованием TLS), передаваемые сообщения будут защищены с точки зрения целостности.
Реализовывать каждый отдельный микросервис потенциально могут отдельные программисты, отдельные группы программистов и даже команды из других компаний. У них имеется возможность самостоятельно выбирать язык программирования, технологический стек. Возникает ситуация, когда приложение будет реализовано с использованием различных языков программирование и использованием различных технологий. Это влечет за собой увеличение компетенций команд по безопасности. Команды по безопасности берут на себя ответственность за определение лучших практик по обеспечению безопасности используемых технологий, руководств по безопасному программированию, исследование инструментов статического и динамического анализа, безопасную интеграцию инструментов в среду разработки. В целом, подходы к безопасности жизненного цикла программного обеспечение при использовании микросервисной архитектуры в сравнении с монолитной не сильно изменяются, однако повышается трудоёмкость и количество ресурсов, необходимых для организации мер по безопасности. Например, за счет того, что для разработки и функционирования используются новые технологии – система контейнеризации, система оркестрации контейнеров и т.д. Эти технологии требуются отдельного внимания со стороны безопасности – выработка лучших практик по использованию, безопасная конфигурация, руководства для администраторов.
Задачи для разработчиков
В заключении предлагаю рассмотреть список задач, которым следует уделить внимание при разработке приложения с использованием микросервисной архитектуры:
1. Авторизация и аутентификация
Для обеспечения безопасности необходимо реализовать механизмы аутентификации и авторизации доступа к микросервисам как пользователей, так и сервисов между собой. Для этого можно использовать протоколы аутентификации, такие как OAuth, JWT и другие.
2. Шифрование
Следуя концепции ZeroTrust, среду передачи данных следует считать недоверенной. Во избежание утечек и фальсификаций необходимо шифровать данные, передаваемые между микросервисами. Для этого можно использовать протокол TLS и mTLS.
3. Мониторинг и логирование
Для обеспечения безопасности важно внедрить систему мониторинга и логирования действий в микросервисах для обнаружения подозрительной активности и быстрого реагирования на возникающие угрозы. Для этого можно использовать ELK – набор из трёх инструментов (Elasticsearch, Logstash, Kibana) для генерации, обработки и индексации логов. Zabbix или Prometheus – как инструменты для мониторинга различных параметров микросервисов, таких как нагрузка на сервер, состояние web-сервера, сквозной мониторинг запросов и мониторинг баз данных.
4. Сетевая безопасность
В связи с особенностями микросевисной архитектуры острее выглядят уязвимости типа SSRF. Чтобы нивелировать эффект подобных угроз, рекомендуется разграничивать доступ к сетевым ресурсам и микросервисам с помощью фильтрации сетевого трафика, сетевых политик и firewalls.
5. Управление идентификацией и доступом
Следовать принципам минимальных привилегий (Least Privilege) для доступа к микросервисам и управлению идентификацией пользователей и сервисов. Использовать системы управления доступом (IAM), механизмы RBAC (Role-Based Access Control) и ABAC (Attribute-Based Access Control) для управления доступом к микросервисам.
6. Обновление артефактов
Необходимо обеспечить мониторинг актуальности используемых артефактов при разработке. Обновлять зависимости и библиотеки, используемые в микросервисах, чтобы предотвращать работу компонентов в продуктовом приложении с общеизвестными уязвимостями.
7. Обучение персонала
Обучение сотрудников, участвующих в разработке и эксплуатации приложения, безопасным практикам разработки и эксплуатации микросервисов, чтобы повысить уровень безопасности в компании. Учитывая сложность микросервисных систем, важно постоянно совершенствовать и обновлять стратегии безопасности, чтобы обеспечить надежную защиту ваших приложений.
Опубликовано 19.04.2024
