2014-01-08 7 views
2

У меня машина Windows Server 2008 R2 с IIS7.5. Этот веб-сервер размещает многие веб-сайты в разных доменах, и на каждом веб-сайте есть несколько приложений asp.net. Поддержка и развитие доступа к этой машине довольно ограничены из-за требований заказчика. Я хочу использовать библиотеку Microsoft.Web.Administration для запроса конфигурации каждого из этих приложений в ASMX веб-метод:Как безопасно прочитать корневую конфигурационную папку asp.net?

[WebMethod(MessageName = "GetDatabases")] 
    public List<Connection> GetDatabases() 
    { 
     List<Connection> connections = new List<Connection>(); 
     ServerManager sm = new ServerManager(); 
     foreach (Site site in sm.Sites) 
     { 
      foreach (Application app in site.Applications) 
      { 
       System.Configuration.Configuration config = System.Web.Configuration.WebConfigurationManager.OpenWebConfiguration(app.Path); 
       foreach (ConnectionStringSettings cs in config.ConnectionStrings.ConnectionStrings) 
       { 
        try 
        { 
         SqlConnectionStringBuilder builder = new SqlConnectionStringBuilder(cs.ConnectionString); 
         connections.Add(new Connection { Site = site.Name, Path = app.Path, Name = cs.Name, InitialCatalog = builder.InitialCatalog, DataSource = builder.DataSource }); 
        } 
        catch 
        { 
         connections.Add(new Connection { Site = site.Name, Path = app.Path, Name = cs.Name}); 
        } 
       } 
      } 
     } 
     return connections; 
    } 

Этот код работает отлично в Visual Studio, но после развертывания на сервере возникает ошибка:

Server was unable to process request. ---> Filename: redirection.config 
    Error: Cannot read configuration file due to insufficient permissions 

Я исследовал, как обойти эту проблему и нашел эту страницу:

http://www.iis.net/learn/manage/configuring-security/application-pool-identities

Так я CR добавили новый пул приложений только для этого веб-сервиса и настроили идентификатор пула приложений, чтобы иметь доступ только для чтения к папке, содержащей redirection.config (C: \ Windows \ System32 \ inetsrv \ config), используя ACL из папки. (Я сделал это для папки, а не для файла, так как кажется, что требуется больше одного файла в папке.)

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

Спасибо, Owen

EDIT: Просто интересно, если я сформулировать этот вопрос правильно? До сих пор никто не принимал удар, чтобы ответить на него, поэтому это редактирование в основном для того, чтобы поднять его;)

ответ

1

Я не эксперт по безопасности (так что возьмите мои слова с щепоткой соли), но я бы сказал, на этом нет жесткого и быстрого ответа. Однако, скорее всего, стоит больше рекомендовать против.

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

Тем не менее, есть ряд вещей, которые вы должны думать долго и упорно о том, прежде чем идти вперед с ним:

  • Мог же быть достигнуто путем простого создания защищенного общего доступа на сервере, и предоставления СВОЕГО поддерживает/обеспечивает RO доступ к этому местоположению? Это может быть более безопасным, чем написание собственного сервиса.
  • Если вы делаете это через веб-сервис, вы должны добавить безопасность для службы, чтобы предотвратить несанкционированный доступ (я бы, вероятно, использовал проверку подлинности самостоятельно, но это зависит от ваших требований)
  • Я бы рекомендовал вам убедиться, что эта услуга не видна за пределами вашей локальной сети: вы не хотите, чтобы кто-то из более широкого веб-сайта мог получить на это
  • Используйте SSL-соединение для вашей службы, чтобы предотвратить снифферы пакетов, способные отслеживать ваш трафик и получить эту конфиденциальную информацию.
  • Я бы рекомендовал удалить конфиденциальную информацию из строки Connection перед ее отображением.Как минимум, я удалю пароль. Любой, кому нужен пароль, уже знает об этом или знает, как его получить. Любой, кто не нуждается в этом, не сможет получить его с помощью этого инструмента. Вы также можете отключить все, кроме последней части IP, это не очень безопасно, но это помогает обмануть информацию, которая облегчила бы взломать.

Прежде всего, вы почти наверняка хотите сообщить об этом руководству/клиенту, четко изложите потенциальные риски и детализируйте, что (если угодно) вы сделаете, чтобы смягчить его. Если после этого они подпишут, то ответственность за них действительно будет.

+0

_Если ваше требование - разрешить поддержку, чтобы видеть соединения, которые используют ваши разные сайты, то я не вижу проблемы с созданием такого сервиса в общем принципе, если вы будете осторожны. Благодарю г-на Феникса. Я планировал использовать все ваши предложения и соглашаюсь с тем, что в целом принцип должен быть в порядке. Однако при рассмотрении мы решили использовать этот код для локального вывода информации в текстовый файл. Это неплохая идея, но не стоит ничего рисковать. –

+0

Это имеет смысл. Лучше не рисковать шансом, что кто-то сможет обойти ваши ограничения. Рад помочь. –

0

Безопасность веб-службы должна быть вашей последней заботой, основная проблема - , вы должны сделать такие конфиденциальные/конфиденциальные данные доступными через веб-сервис?

И ответ прямой НЕТ.

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

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

Смежные вопросы