Azure: безопасность между веб-ролями

В Azure, если вы решили использовать внутреннюю конечную точку (вместо входной конечной точки), https не подходит. http и tcp - единственные варианты. Означает ли это, что внутренняя конечная точка защищена на 100% и вам не нужно шифрование.

Тогда возникает другой вопрос. Если я решу использовать конечную точку ввода между приложением mvc и службой wcf. Действительно ли необходимо иметь https между ними? Это нормально, если у меня есть 2 входные конечные точки для wcf. Один с http на порту 80, который должен использоваться приложением mvc. Другой с https на порту 443, который может использоваться кем-то другим. (не наше собственное приложение)


azure security asp.net-mvc-3 wcf webrole
person zhenbzha    schedule 10.10.2012    source источник
comment
В дополнение к приведенным ниже ответам вам может быть полезен ответ Брента на мой вопрос здесь: stackoverflow.com/questions/11584163/   -  person Jude Fisher    schedule 12.10.2012

Ответы (1)


arrow_upward
2
arrow_downward

Нужно ли вам шифровать внутренние конечные точки?

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

Необходимо ли включать HTTPS на конечных точках WCF?

Конечно, можно настроить ваше приложение таким образом. Почему бы не сделать конечную точку порта 80 службы WCF внутренней? Или — почему бы не разместить приложение WCF на той же роли, тогда вы можете просто использовать петлевой адрес?

Вам нужно подумать о требованиях безопасности вашего приложения и исходить из этого.

person Richard Astbury    schedule 10.10.2012
comment
Спасибо за ответ. почему бы не разместить приложение WCF в той же роли, потому что я хочу иметь возможность независимого масштабирования. Этого можно достичь только с помощью разных веб-ролей. У меня есть веб-приложение mvc в веб-роли с https на порту 443 и служба wcf в другой веб-роли. Для службы wcf у меня есть порт 80 для внутренней конечной точки и порт 449 для https для внешнего использования. Все отлично. Пока клиент не сказал из своего офиса, трафик с портом, отличным от 443, заблокирован. Итак, я рассматриваю возможность переноса wcf на другой хост-сервис с портом 443. - person zhenbzha; 10.10.2012
comment
Но для связи между mvc и wcf я не хочу иметь https. Я хочу иметь только https для wcf для внешнего использования. Таким образом, возникает вопрос, действительно ли http между приложением mvc и wcf снижает безопасность? - person zhenbzha; 10.10.2012
comment
Итак, вы говорите, что хотите настроить свое приложение для использования SSL на внешней конечной точке — это нормально, и отсутствие SSL на вашей внутренней конечной точке — тоже нормально (поскольку вы не можете создать атаку «человек посередине» на Азуре). Или я что-то неправильно понял? - person Richard Astbury; 10.10.2012
comment
Как уже говорилось, изначально развертывайте веб-приложение и сервис на одном и том же хост-сервисе. Для WCF у меня есть внутренняя конечная точка (порт 80) и внешняя конечная точка (порт 449), веб-приложение mvc на порту 443. Однако 449 недоступен для клиента, они могут использовать только 443. 443 уже используется веб-приложением. Таким образом, единственный вариант — развернуть WCF на другом хост-сервисе. Вопрос в том, находятся ли MVC и MVC в отдельной службе хоста. Нужно ли мне иметь https для их внутренней связи - person zhenbzha; 10.10.2012
comment
А, теперь я понял. Вопрос заключается в следующем: «Существует ли угроза безопасности при подключении к веб-службам в другой размещенной службе с использованием общедоступного адреса». Ответ «да», существует небольшой риск атаки DNS-спуфинга. Переживать, наверное, не стоит. - person Richard Astbury; 11.10.2012