Azure Architecture - управление безопасностью - PullRequest
Новая
       17

Azure Architecture - управление безопасностью

3 голосов
/ 02 ноября 2011

Планирование миграции нашего существующего приложения на Azure.Наша существующая архитектура с потоком безопасности выглядит следующим образом:

  • Уровень пользовательского интерфейса ASP MVC 3.0, который принимает пароль от имени пользователя от пользователя. Мы планируем перенести уровень пользовательского интерфейса в вычислительное облако.и будет доступен, скажем, на uilayerdomainname.com, который будет иметь сертификат SSL.

  • Уровень веб-сервисов WCF REST, который, помимо прочего, также выполняет аутентификацию.Это в настоящее время на скажем servicename.cloudapp.net.(Мы могли бы сопоставить его с servicelayername.com и получить SSL для этого доменного имени).

  • база данных SQL Azure

Уровень пользовательского интерфейса отправляет учетные данные на сервисный уровень, который аутентифицирует его по базе данных SQL Azure.

Вопрос

  • И вычислительное облако WCF, и уровень пользовательского интерфейса находятся в одном и том же регионе Azure.Будет ли общение между этими двумя склонными к атаке человека?Моему облаку вычислений WCF также нужен SSL?У нас есть два доменных имени с SSL и мы можем просто привязать сервисы к одному.

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

  • Будет ли производительность лучше, если я опубликую службы WCF и уровень пользовательского интерфейса в одном экземпляре?Это как бы сбивает с толку красивую многоуровневую архитектуру, но если это улучшит производительность, я мог бы пойти на это.Мы не хотим перепрыгивать через слишком много обручей, чтобы приспособить приложение к Azure, чтобы из-за этого не было трудно мигрировать.

Ответы [ 2 ]

1 голос
/ 03 ноября 2011

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

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

Это относится как к веб-ролям, так и к рабочим ролям: вы можете настроить веб-роль, на которой размещается ваша служба WCF, для создания внутренней внутренней конечной точки.

В зависимости от архитектуры вашей системы, вы можете увидеть более высокую производительность, если у вас есть слой UI и WCF на одной машине.

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

1 голос
/ 02 ноября 2011

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

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

Надеюсь, это помогло

...