Поделиться через


Проблемы безопасности и полезные советы при трассировке

В этом разделе описываются способы защиты конфиденциальных сведений от раскрытия, а также приводятся полезные советы по использованию WebHost.

Использование пользовательского прослушивателя трассировки с WebHost

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

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

Регистрация конфиденциальных сведений

Трассировки содержат заголовки сообщений, когда сообщения находятся в области действия. Когда трассировка включена, персональные данные в заголовках, зависящих от приложения (такие как строка запроса), и в теле сообщения (такие как номер кредитной карты) могут быть видимы в журналах. За надлежащее управление доступом к файлам конфигурации и трассировки отвечает специалист, выполняющий развертывание приложения. Если требуется, чтобы подобные сведения не были видимы, необходимо отключить трассировку или фильтровать часть данных (если предполагается доступ к трассировкам других лиц).

Следующие советы помогут предотвратить непреднамеренное раскрытие содержимого файла трассировки.

  • Убедитесь, что файлы журналов защищены с помощью списков управления доступом (ACL), как в сценарии с использованием WebHost, так и в сценарии с резидентной службой.

  • Выберите расширение файла, которое нельзя легко получить с помощью веб-запроса. Например, расширение XML безопасным не является. Список расширений, которые могут быть получены, можно найти в руководстве по администрированию IIS.

  • Задайте абсолютный путь к местоположению файла журнала, которое должно находиться за пределами общедоступного каталога vroot WebHost во избежание доступа к нему третьих лиц с помощью веб-браузера.

По умолчанию ключи и персональные данные (personally identifiable information, PII), такие как имя пользователя и пароль, не регистрируются трассировкой и не указываются в заносимых в журнал сообщениях. Тем не менее, администратор компьютера может с помощью атрибута enableLoggingKnownPII в элементе machineSettings файла Machine.config разрешить приложениям, выполняющимся на компьютере, регистрировать известные персональные данные (PII). Это делается следующим образом:

<configuration>  
   <system.ServiceModel>  
      <machineSettings enableLoggingKnownPii="Boolean"/>  
   </system.ServiceModel>  
</configuration>

Специалист, выполняющий развертывание приложения, может затем с помощью атрибута logKnownPii в файле App.config или Web.config включить регистрацию персональных данных следующим образом:

<system.diagnostics>  
  <sources>  
      <source name="System.ServiceModel.MessageLogging"  
        logKnownPii="true">  
        <listeners>  
                 <add name="messages"  
                 type="System.Diagnostics.XmlWriterTraceListener"  
                 initializeData="c:\logs\messages.svclog" />  
          </listeners>  
      </source>  
  </sources>  
</system.diagnostics>  

Регистрация PII включена, только когда оба параметра имеют значение true. Такое сочетание из двух ключей позволяет регистрировать известные PII для каждого приложения.

Необходимо иметь в виду, что при задании в файле конфигурации двух или более пользовательских источников считываются только атрибуты первого источника. Остальные атрибуты не учитываются. Это значит, что в случае следующего файла App.config PII не регистрируются для обоих источников, несмотря на то что для второго источника явно включена регистрация персональных данных.

<system.diagnostics>  
  <sources>  
      <source name="System.ServiceModel.MessageLogging"  
        logKnownPii="false">  
        <listeners>  
           <add name="messages"  
                type="System.Diagnostics.XmlWriterTraceListener"  
                initializeData="c:\logs\messages.svclog" />  
          </listeners>  
      </source>  
      <source name="System.ServiceModel"
         logKnownPii="true">  
         <listeners>  
            <add name="xml" />  
         </listeners>  
      </source>  
  </sources>  
</system.diagnostics>  

Если элемент <machineSettings enableLoggingKnownPii="Boolean"/>ConfigurationErrorsException присутствует за пределами файла Machine.config, система вызывает исключение.

Изменения вступают в силу только после запуска или перезапуска приложения. Когда оба атрибута имеют значение true, при запуске регистрируется событие. Событие также регистрируется, если атрибут logKnownPii имеет значение true, а атрибут enableLoggingKnownPii имеет значение false.

Дополнительные сведения о ведении журнала персональных данных см . в примере блокировки безопасности PII.

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

Кроме того, IP-адрес отправителя сообщения регистрируется при каждом подключении в случае транспорта, ориентированного на подключения, а в остальных случаях - при каждом сообщении. Это делается без согласия отправителя. Впрочем, эта регистрация выполняется только на уровнях трассировки «Данные» и «Подробно», которые не используются по умолчанию и не рекомендуются для использования в производственной среде, за исключением отладки.

См. также