Auditoria de eventos de segurança
Os aplicativos criados com o Windows Communication Foundation (WCF) podem registrar eventos de segurança (êxito, falha ou ambos) com o recurso de auditoria. Os eventos são gravados no log de eventos do sistema Windows e podem ser examinados usando o Visualizador de Eventos.
A auditoria fornece uma maneira para um administrador detetar um ataque que já ocorreu ou está em andamento. Além disso, a auditoria pode ajudar um desenvolvedor a depurar problemas relacionados à segurança. Por exemplo, se um erro na configuração da política de autorização ou verificação negar acidentalmente o acesso a um usuário autorizado, um desenvolvedor poderá descobrir e isolar rapidamente a causa desse erro examinando o log de eventos.
Para obter mais informações sobre segurança WCF, consulte Visão geral de segurança. Para obter mais informações sobre como programar WCF, consulte Programação básica do WCF.
Nível e comportamento da auditoria
Existem dois níveis de auditorias de segurança:
Nível de autorização de serviço, no qual um chamador é autorizado.
Nível de mensagem, no qual o WCF verifica a validade da mensagem e autentica o chamador.
Você pode verificar se ambos os níveis de auditoria são bem-sucedidos ou falhados, o que é conhecido como comportamento de auditoria.
Local do log de auditoria
Depois de determinar um nível e comportamento de auditoria, você (ou um administrador) pode especificar um local para o log de auditoria. As três opções incluem: Padrão, Aplicativo e Segurança. Quando você especifica Padrão, o log real depende de qual sistema você está usando e se o sistema suporta gravação no log de segurança. Para obter mais informações, consulte a seção "Sistema operacional" mais adiante neste tópico.
Para gravar no log de segurança é necessário o SeAuditPrivilegearquivo . Por padrão, apenas as contas Sistema Local e Serviço de Rede têm esse privilégio. Para gerenciar as funções read de log de segurança e delete requer o SeSecurityPrivilege. Por padrão, apenas os administradores têm esse privilégio.
Por outro lado, os usuários autenticados podem ler e gravar no log do aplicativo. O Windows XP grava eventos de auditoria no log do aplicativo por padrão. O log também pode conter informações pessoais visíveis para todos os usuários autenticados.
Suprimindo falhas de auditoria
Outra opção durante a auditoria é suprimir ou não qualquer falha de auditoria. Por padrão, uma falha de auditoria não afeta um aplicativo. Se necessário, no entanto, você pode definir a opção como false, o que faz com que uma exceção seja lançada.
Auditoria de Programação
Você pode especificar o comportamento de auditoria programaticamente ou por meio da configuração.
Aulas de Auditoria
A tabela a seguir descreve as classes e propriedades usadas para programar o comportamento de auditoria.
| Classe | Description |
|---|---|
| ServiceSecurityAuditBehavior | Permite definir opções para auditoria como um comportamento de serviço. |
| AuditLogLocation | Enumeração para especificar em qual log gravar. Os valores possíveis são Default, Application e Security. Quando você seleciona Padrão, o sistema operacional determina o local real do log. Consulte a seção "Escolha do log de eventos de segurança ou aplicativo" mais adiante neste tópico. |
| MessageAuthenticationAuditLevel | Especifica quais tipos de eventos de autenticação de mensagem são auditados no nível da mensagem. As escolhas são None, Failure, Success, e SuccessOrFailure. |
| ServiceAuthorizationAuditLevel | Especifica quais tipos de eventos de autorização de serviço são auditados no nível de serviço. As escolhas são None, Failure, Success, e SuccessOrFailure. |
| SuppressAuditFailure | Especifica o que acontece com a solicitação do cliente quando a auditoria falha. Por exemplo, quando o serviço tenta gravar no log de segurança, mas não tem SeAuditPrivilege. O valor padrão de indica que as falhas são ignoradas e a solicitação do cliente é processada true normalmente. |
Para obter um exemplo de configuração de um aplicativo para registrar eventos de auditoria, consulte Como auditar eventos de segurança.
Configuração
Você também pode usar a configuração para especificar o comportamento de auditoria adicionando um serviceSecurityAudit> sob os <comportamentos>.< Você deve adicionar o elemento sob um <comportamento> , conforme mostrado no código a seguir.
<configuration>
<system.serviceModel>
<behaviors>
<behavior>
<!-- auditLogLocation="Application" or "Security" -->
<serviceSecurityAudit
auditLogLocation="Application"
suppressAuditFailure="true"
serviceAuthorizationAuditLevel="Failure"
messageAuthenticationAuditLevel="SuccessOrFailure" />
</behavior>
</behaviors>
</system.serviceModel>
</configuration>
Se a auditoria estiver habilitada e um auditLogLocation não for especificado, o nome de log padrão será "Segurança" para a plataforma que suporta a gravação no log de Segurança, caso contrário, será o log "Aplicativo". Somente os sistemas operacionais Windows Server 2003 e Windows Vista oferecem suporte à gravação no log de segurança. Para obter mais informações, consulte a seção "Sistema operacional" mais adiante neste tópico.
Considerações de Segurança
Se um usuário mal-intencionado souber que a auditoria está habilitada, esse invasor poderá enviar mensagens inválidas que farão com que as entradas de auditoria sejam gravadas. Se o log de auditoria for preenchido dessa maneira, o sistema de auditoria falhará. Para atenuar isso, defina a SuppressAuditFailure propriedade e true use as propriedades do Visualizador de Eventos para controlar o comportamento de auditoria.
Os eventos de auditoria gravados no log do aplicativo no Windows XP são visíveis para qualquer usuário autenticado.
Escolhendo entre logs de eventos de aplicativo e segurança
As tabelas a seguir fornecem informações para ajudá-lo a escolher se deseja fazer logon no aplicativo ou no log de eventos de segurança.
Sistema operativo
| Sistema | Registo da aplicação | Registo de segurança |
|---|---|---|
| Windows XP SP2 ou posterior | Suportado | Não suportado |
| Windows Server 2003 SP1 e Windows Vista | Suportado | O contexto do thread deve possuir SeAuditPrivilege |
Outros fatores
Além do sistema operacional, a tabela a seguir descreve outras configurações que controlam a habilitação do registro em log.
| Fator | Registo da aplicação | Registo de segurança |
|---|---|---|
| Gestão da política de auditoria | Não aplicável. | Junto com a configuração, o log de segurança também é controlado pela diretiva de autoridade de segurança local (LSA). A categoria "Acesso a objetos de auditoria" também deve ser habilitada. |
| Experiência de usuário padrão | Todos os usuários autenticados podem gravar no log do aplicativo, portanto, nenhuma etapa de permissão adicional é necessária para os processos do aplicativo. | O processo de candidatura (contexto) deve ter SeAuditPrivilege. |