Nota
O acesso a esta página requer autorização. Podes tentar iniciar sessão ou mudar de diretório.
O acesso a esta página requer autorização. Podes tentar mudar de diretório.
O exemplo SecurityLockdown demonstra como controlar vários recursos relacionados à segurança de um serviço WCF (Windows Communication Foundation):
Criptografar informações confidenciais no arquivo de configuração de um serviço.
Bloqueando elementos no arquivo de configuração para que os subdiretórios de serviço aninhados não possam substituir as configurações.
Controlando o registo de informações pessoalmente identificáveis (PII) em logs de rastreio e mensagens.
Discussão
Cada um desses recursos pode ser usado separadamente ou em conjunto para controlar aspetos da segurança de um serviço. Este não é um guia definitivo para proteger um serviço WCF.
Os arquivos de configuração do .NET Framework podem conter informações confidenciais, como cadeias de conexão para se conectar a bancos de dados. Em cenários compartilhados hospedados na Web, pode ser desejável criptografar essas informações no arquivo de configuração de um serviço para que os dados contidos no arquivo de configuração sejam resistentes à visualização casual. O .NET Framework 2.0 e posterior tem a capacidade de criptografar partes do arquivo de configuração usando a interface de programação de aplicativos (DPAPI) do Windows Data Protection ou o provedor de criptografia RSA. O aspnet_regiis.exe usando o DPAPI ou RSA pode criptografar partes selecionadas de um arquivo de configuração.
Em cenários hospedados na Web é possível ter serviços em subdiretórios de outros serviços. A semântica padrão para determinar valores de configuração permite que os arquivos de configuração nos diretórios aninhados substituam os valores de configuração no diretório pai. Em certas situações, isto pode ser indesejável por várias razões. A configuração de serviço do WCF suporta o bloqueio dos valores de configuração, de modo que configurações aninhadas gerem exceções quando um serviço aninhado é executado utilizando valores de configuração substituídos.
Este exemplo demonstra como controlar o registro de informações de identificação pessoal (PII) conhecidas em logs de rastreamento e mensagens, como nome de usuário e senha. Por padrão, o registo de informação pessoal identificável (PII) conhecida é desativado. No entanto, em certas situações, pode ser importante registar PII para a solução de problemas de uma aplicação. Este exemplo é baseado em Introdução. Além disso, este exemplo usa rastreamento e registro de mensagens. Para obter mais informações, consulte o exemplo de rastreamento e registro de mensagens .
Criptografando elementos do arquivo de configuração
Para fins de segurança em um ambiente compartilhado de hospedagem na Web, pode ser desejável criptografar determinados elementos de configuração, como cadeias de conexão de banco de dados que podem conter informações confidenciais. Um elemento de configuração pode ser criptografado usando a ferramenta aspnet_regiis.exe encontrada na pasta .NET Framework Por exemplo, %WINDIR%\Microsoft.NET\Framework\v4.0.20728.
Para criptografar os valores na seção appSettings em Web.config para o exemplo
Abra um prompt de comando usando Start-Run>....
cmdDigite e clique em OK.Navegue até o diretório atual do .NET Framework emitindo o seguinte comando:
cd %WINDIR%\Microsoft.NET\Framework\v4.0.20728.Criptografe as definições de configuração appSettings na pasta Web.config emitindo o seguinte comando:
aspnet_regiis -pe "appSettings" -app "/servicemodelsamples" -prov "DataProtectionConfigurationProvider".
Mais informações sobre como criptografar seções de arquivos de configuração podem ser encontradas lendo um tutorial sobre DPAPI em ASP.NET configuração (Building Secure ASP.NET Applications: Authentication, Authorization, and Secure Communication) e um how-to on RSA in ASP.NET configuration (How To: Encrypt Configuration Sections in ASP.NET 2.0 Using RSA).
Bloqueando elementos do arquivo de configuração
Em cenários hospedados na Web, é possível ter serviços em subdiretórios de serviços. Nessas situações, os valores de configuração para o serviço no subdiretório são calculados ao examinar os valores em Machine.config e unindo-os sucessivamente a quaisquer arquivos Web.config nos diretórios superiores, descendo pela árvore de diretórios, e, finalmente, unindo o arquivo Web.config no diretório que contém o serviço. O comportamento padrão para a maioria dos elementos de configuração é permitir que os arquivos de configuração em subdiretórios substituam os valores definidos nos diretórios pai. Em determinadas situações, pode ser desejável impedir que os arquivos de configuração em subdiretórios substituam os valores definidos na configuração do diretório pai.
O .NET Framework fornece uma forma de bloquear elementos de ficheiros de configuração para que configurações que sobreponham elementos de configuração bloqueados lancem exceções em tempo de execução.
Um elemento de configuração pode ser bloqueado especificando o lockItem atributo para um nó no arquivo de configuração, por exemplo, para bloquear o nó CalculatorServiceBehavior no arquivo de configuração para que os serviços de calculadora em arquivos de configuração aninhados não possam alterar o comportamento, a seguinte configuração pode ser usada.
<configuration>
<system.serviceModel>
<behaviors>
<serviceBehaviors>
<behavior name="CalculatorServiceBehavior" lockItem="true">
<serviceMetadata httpGetEnabled="True"/>
<serviceDebug includeExceptionDetailInFaults="False" />
</behavior>
</serviceBehaviors>
</behaviors>
</system.serviceModel>
</configuration>
O bloqueio de elementos de configuração pode ser mais específico. Uma lista de elementos pode ser especificada como valor para o lockElements bloquear um conjunto de elementos dentro de uma coleção de subelementos. Uma lista de atributos pode ser especificada como o valor para o lockAttributes bloquear um conjunto de atributos dentro de um elemento. Uma coleção inteira de elementos ou atributos pode ser bloqueada, com exceção de uma lista especificada, especificando os atributos lockAllElementsExcept ou lockAllAttributesExcept no nó.
Configuração de registro de PII
O registro de PII é controlado por duas opções: uma configuração em todo o computador encontrada em Machine.config que permite que um administrador de computador permita ou negue o registro de PII e uma configuração de aplicativo que permite que um administrador de aplicativo alterne o registro de PII para cada fonte em um arquivo Web.config ou App.config.
A configuração em todo o enableLoggingKnownPii computador é controlada pela configuração true de false ou machineSettings, no elemento Machine.config. Por exemplo, o seguinte permite que os aplicativos ativem o registro de PII.
<configuration>
<system.serviceModel>
<machineSettings enableLoggingKnownPii="true" />
</system.serviceModel>
</configuration>
Observação
O arquivo Machine.config tem um local padrão: %WINDIR%\Microsoft.NET\Framework\v2.0.50727\CONFIG.
Se o enableLoggingKnownPii atributo não estiver presente no Machine.config, o registro de PII não será permitido.
A habilitação do registro de PII para um aplicativo é feita definindo o logKnownPii atributo do elemento de origem para true ou false no arquivo Web.config ou App.config. Por exemplo, o seguinte permite o registo de PII tanto para o registo de mensagens como para o registo de rastreamento.
<configuration>
<system.diagnostics>
<sources>
<source name="System.ServiceModel.MessageLogging" logKnownPii="true">
<listeners>
...
</listeners>
</source>
<source name="System.ServiceModel" switchValue="Verbose, ActivityTracing">
<listeners>
...
</listeners>
</source>
</sources>
</system.diagnostics>
</configuration>
Se o logKnownPii atributo não for especificado, a PII não será registrada.
As PII só serão registradas se ambas enableLoggingKnownPii estiverem definidas como true, e logKnownPii se estiverem definidas como true.
Observação
System.Diagnostics ignora todos os atributos em todas as fontes, exceto o primeiro listado no arquivo de configuração. Adicionar o logKnownPii atributo à segunda fonte no arquivo de configuração não tem efeito.
Importante
Para executar este exemplo envolve a modificação manual de Machine.config. Deve-se ter cuidado ao modificar Machine.config pois valores ou sintaxe incorretos podem impedir a execução de todos os aplicativos do .NET Framework.
Também é possível criptografar elementos do arquivo de configuração usando DPAPI e RSA. Para obter mais informações, veja as seguintes ligações:
Criando aplicativos de ASP.NET seguros: autenticação, autorização e comunicação segura
Como: Criptografar seções de configuração no ASP.NET 2.0 usando RSA
Para configurar, compilar e executar o exemplo
Verifique se você executou o procedimento de instalação do One-Time para os exemplos do Windows Communication Foundation.
Edite Machine.config para definir o
enableLoggingKnownPiiatributo comotrue, adicionando os nós pai, se necessário.Para criar a edição C# ou Visual Basic .NET da solução, siga as instruções em Criando os exemplos do Windows Communication Foundation.
Para executar o exemplo em uma configuração de computador único ou entre computadores, siga as instruções em Executando os exemplos do Windows Communication Foundation.
Para limpar a amostra
- Edite Machine.config para definir o
enableLoggingKnownPiiatributo comofalse.