Как защитить микросервисы в среде с нулевым доверием


Этот блог был написан независимым гостевым блоггером.

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

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

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

Краткий обзор микросервисов

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

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

Почему безопасность микросервисов жизненно важна

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

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

Определение среды с нулевым доверием

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

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

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

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

Как нам создать эту безопасность? Как правило, когда используется архитектура микросервисов, для связи в режиме реального времени используются HTTP или gRPC. Apache Kafka и RabbitMQ также являются примерами других протоколов связи для приложений. Чтобы защитить эти сообщения, нам нужно убедиться, что запросы от клиентского приложения проходят через систему безопасности не только на границе, но и внутри.

Как построить надежную аутентификацию и авторизацию с помощью mTLS

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

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

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

Криптографически безопасные методы передачи пользовательского контекста между микросервисами

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

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

В любом случае шлюз API действует как шлюз для регулирования потока контекстных вызовов пользователя. При переносе этих вызовов лучший способ криптографического переноса — использование веб-токена JSON (JWT).

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

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

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

Функционирующая структура безопасности микросервисов

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

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

https://cyberxhack.org/