Как реализовать TLS между микросервисами

Question

Может кто-нибудь прокомментировать, проверить, критиковать или иным образом взорвать дыры в проекте безопасности микросервисов, который я рассматриваю?

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

Эта реализация работает, но что-то не совсем пахнет по этому поводу.

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

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

Мне интересноесли вместо вышесказанного а) целесообразно и б) безопасно разделить один доверенный сертификат открытого ключа между всеми микросервисами?Что-то совершенно другое?

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

РЕДАКТИРОВАТЬ: После прочтения ответов / комментариев к моему исходному сообщению мне пришло в голову, что я пропустил детали, которые могли сделать проблемуболее понятным, и, следовательно, комментаторам будет проще справиться с ним:

1. Рассматриваемые микросервисы существуют в частной интрасети и будут доступны только клиентам (браузерам или другим микросервисам) в пределахэта интрасеть.

2. На самом деле существует доверенный центр сертификации, а именно компания, которой принадлежит эта интрасеть, и именно этот центр подписывает пары ключей микросервисов.

Решение этой проблемы, по-видимому, подразумевается в первом комментарии @Andreas, в котором он писал: «Пока ЦС, выпустивший их, доверяет, им тоже будут доверять».

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

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

Answer 1

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

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

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

Answer 2

Один из способов сделать это (ваш вопрос является широким, и без кода он может быть более тематическим в SoftwareEngineering, чем здесь), заключается в следующем:

1. создать свой собственный CA
2. (необязательно, создать дополнительный CA только для ваших микросервисов)
3. генерировать все сертификаты этим CA
4. заставить ваш код доверять всем сертификатам этого CA вместо проверки самого сертификата (но вы все равно должны проверить даты, правильную подпись и т. д.)

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

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

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

Кроме того, слабо связаны, но убедитесь, чточтобы прочитать это: https://www.cs.utexas.edu/~shmat/shmat_ccs12.pdf показывает различные подводные камни при использовании TLS вне сети.Это открытие глаза.Несмотря на то, что он предназначен только для TLS, а не для проблем с PKI, этот Интернет-проект (https://datatracker.ietf.org/doc/draft-gutmann-tls-lts/) может дать полезную информацию о том, как правильно реализовать TLS1.2 с некоторыми безопасными вариантами по умолчанию. Часть «LTS» конкретно означает «Long»).Термин «Поддержка».

Посмотрите также на этот связанный вопрос: https://security.stackexchange.com/questions/175627/securing-internal-micro-services-letsencrypt-vs-self-signed-certificates-be и ответ, дающий вам другие идеи, такие как использование хранилища.