Аутентификация серверов - каков хороший подход?

Question

Редактировать

Спасибо за предложения; Чтобы уточнить, мы уже используем SSL, но это, как правило, не аутентифицирует запрашивающую сторону, а просто отвечающую сторону (IIRC?). Я сразу же рассмотрю другие идеи, спасибо за мозговой штурм!

Фон

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

Вопрос

У нас есть группа серверов, предлагающих взаимосвязанные сервисы через веб-сервисы (т.е. SOAP). Весь HTTP-трафик проходит через SSL. Как запрашивающие серверы могут гарантировать, что они общаются с правильным отвечающим сервером? SSL по умолчанию аутентифицирует получателя отправителю. Например. Предположим, что сеть взломана или кто-то хочет изменить некоторую информацию (вызвав метод) без авторизации. Как мы можем помешать такому агенту просто подделать отправителя?

Реализации WS-Security от различных поставщиков (скажем, .NET и java), похоже, не очень хорошо взаимодействуют друг с другом - в частности, когда сервисы усложняются (с такими вещами, как поддержка транзакций), так что это решение, к сожалению, вероятно не очень хороший.

У нас есть (доверенный) сервер LDAP, на котором пользователи проходят проверку подлинности; Хранение аутентификаций сервера здесь естественно - но как? Иметь имя пользователя / пароль для сервера несколько бессмысленно, поскольку, если вам нужно отправить их на другой сервер для аутентификации, этот сервер может не быть тем, кем он себя считает, и в любом случае, если он взломан, он теперь может притворяться быть собой ...

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

Answer 1

Вам нужна PKI. Вы можете сделать это с stunnel , оборачивая серверы. Затем Stunnel можно использовать для проверки сертификатов и проверки подлинности без необходимости вообще изменять код сервера. Затем, когда вы работаете на серверах, вы можете перемещать их SSL / TLS в своем собственном темпе, даже не выполняя обе задачи одновременно.

Answer 2

На уровне веб-сервиса у вас есть такие вещи, как WS-Security и WS-Trust, но из вашего описания звучит так, будто, возможно, это те проблемы, с которыми у вас возникают проблемы?

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

Поскольку он является внутренним, вы можете подписывать свои собственные сертификаты, используя что-то вроде TinyCA, и устанавливать корневой сертификат CA на каждом сервере вручную, а не оплачивать сертификаты Versign / Thawte.

Answer 3

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

Answer 4

Очевидный ответ здесь - сертификаты (своего рода внутренняя PKI). Но заставить их работать с разными языками и т. Д. Может быть сложно; и само управление им может стать кошмаром безопасности.

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