WCF wsHttpBinding в дата-центре - типичная схема использования

Question

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

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

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

Мне было бы интересно узнать, делают ли это другие люди и какие у нас есть альтернативы. Я рассмотрел (и исключил несколько ниже)

• SecurityMode = Нет - не используйте учетные данные. Наши специалисты по безопасности не довольны этим, поскольку злоумышленники на внешних веб-серверах могут получить доступ к любым услугам, которые им нравятся
• Использовать BasicHttpBinding - я думаю, что это можно настроить для передачи незашифрованных учетных данных пользователя с помощью TransportCredentialOnly . Тем не менее, некоторые обеспокоены тем, что BasicHttpBinding задуман как устаревший подход и менее совместим с другими технологиями
• Используйте Очистить привязку имени пользователя - однако, это открытый исходный код, и моя организация не хочет приближаться к открытому исходному коду по юридическим причинам
• Примите, что мы должны перейти к зашифрованным сообщениям даже внутри дата-центра
• Перейдите на использование другого типа аутентификации, например, Учетные данные Windows - опасайтесь, что это потенциально большое изменение в том, как мы в настоящее время управляем этими службами, а также в том, имеем ли мы доступ к серверу каталогов из DMZ.

Будем весьма благодарны за любые мысли о том, как другие люди используют WCF в дата-центре с зонами безопасности

Answer 1

Использовать BasicHttpBinding - я думаю, это можно настроить для передачи пользователю учетные данные незашифрованы с использованием TransportCredentialOnly. Тем не мение, несколько обеспокоен тем, что BasicHttpBinding предназначен для наследства подход и менее совместим с другими технологиями

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

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

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

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

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

Гораздо лучшим вариантом в этом случае являются сертификаты (CertificateOverTransport пользовательский режим безопасности). Проблема с обычной аутентификацией и аутентификацией UserNameToken в WCF заключается в том, что имя пользователя и пароль передаются в виде простого текста. Это также причина, почему WCF по умолчанию (и до .NET 4 всегда) требует шифрования либо через HTTPS, либо через безопасность сообщений. Любой злоумышленник (в том числе внутренние злоумышленники, которые являются гораздо более опасными) может прослушивать связь либо в демилитаризованной зоне, либо во внутренней сети и получать все учетные данные, необходимые для доступа к вашим услугам.

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

UserNameToken (как вы использовали в WSE) поддерживает зашифрованные пароли, но в WCF эта функция не реализована.

Чтобы не запрашивать шифрование для UserNameOverTransport или CertificateOverTransport, необходимо использовать пользовательское связывание (работает только в .NET 4 - для предыдущей версии требуется несколько КБ от MS).