Dela via


Granska säkerhetshändelser

Program som skapats med Windows Communication Foundation (WCF) kan logga säkerhetshändelser (antingen lyckade, misslyckade eller båda) med granskningsfunktionen. Händelserna skrivs till Windows-systemhändelseloggen och kan undersökas med hjälp av Loggboken.

Granskning är ett sätt för en administratör att identifiera ett angrepp som redan har inträffat eller pågår. Dessutom kan granskning hjälpa en utvecklare att felsöka säkerhetsrelaterade problem. Om till exempel ett fel i konfigurationen av auktoriserings- eller kontrollprincipen oavsiktligt nekar åtkomst till en behörig användare, kan en utvecklare snabbt identifiera och isolera orsaken till det här felet genom att undersöka händelseloggen.

Mer information om WCF-säkerhet finns i Säkerhetsöversikt. Mer information om programmering av WCF finns i Grundläggande WCF-programmering.

Granskningsnivå och beteende

Det finns två nivåer av säkerhetsgranskningar:

  • Tjänstauktoriseringsnivå, där en anropare har behörighet.

  • Meddelandenivå, där WCF söker efter meddelandets giltighet och autentiserar anroparen.

Du kan kontrollera båda granskningsnivåerna för att lyckas eller misslyckas, vilket kallas granskningsbeteende.

Plats för granskningslogg

När du har fastställt en granskningsnivå och ett beteende kan du (eller en administratör) ange en plats för granskningsloggen. De tre alternativen är: Standard, Program och Säkerhet. När du anger Standard beror den faktiska loggen på vilket system du använder och om systemet stöder skrivning till säkerhetsloggen. Mer information finns i avsnittet "Operativsystem" senare i det här avsnittet.

För att skriva till säkerhetsloggen SeAuditPrivilegekrävs . Som standard har endast lokala system- och nätverkstjänstkonton den här behörigheten. För att hantera säkerhetsloggfunktionerna read och delete kräver SeSecurityPrivilege. Som standard har endast administratörer den här behörigheten.

Autentiserade användare kan däremot läsa och skriva till programloggen. Windows XP skriver granskningshändelser till programloggen som standard. Loggen kan också innehålla personlig information som är synlig för alla autentiserade användare.

Förhindra granskningsfel

Ett annat alternativ under granskning är om du vill förhindra eventuella granskningsfel. Som standard påverkar ett granskningsfel inte ett program. Om det behövs kan du dock ange alternativet till false, vilket gör att ett undantag genereras.

Programmeringsgranskning

Du kan ange granskningsbeteende antingen programmatiskt eller via konfiguration.

Granskningsklasser

I följande tabell beskrivs de klasser och egenskaper som används för att programmera granskningsbeteende.

Klass beskrivning
ServiceSecurityAuditBehavior Aktiverar inställningsalternativ för granskning som ett tjänstbeteende.
AuditLogLocation Uppräkning för att ange vilken logg som ska skrivas till. Möjliga värden är Standard, Program och Säkerhet. När du väljer Standard avgör operativsystemet den faktiska loggplatsen. Se avsnittet "Val av program- eller säkerhetshändelselogg" senare i det här avsnittet.
MessageAuthenticationAuditLevel Anger vilka typer av meddelandeautentiseringshändelser som granskas på meddelandenivå. Alternativen är None, Failure, Successoch SuccessOrFailure.
ServiceAuthorizationAuditLevel Anger vilka typer av tjänstauktoriseringshändelser som granskas på tjänstnivå. Alternativen är None, Failure, Successoch SuccessOrFailure.
SuppressAuditFailure Anger vad som händer med klientbegäran när granskning misslyckas. Till exempel när tjänsten försöker skriva till säkerhetsloggen, men inte har SeAuditPrivilege. Standardvärdet true för anger att fel ignoreras och att klientbegäran bearbetas normalt.

Ett exempel på hur du konfigurerar ett program för att logga granskningshändelser finns i Så här: Granska säkerhetshändelser.

Konfiguration

Du kan också använda konfiguration för att ange granskningsbeteende genom att lägga till en <serviceSecurityAudit> under beteendena<>. Du måste lägga till elementet under ett <beteende> som visas i följande kod.

<configuration>  
  <system.serviceModel>  
    <behaviors>  
      <behavior>  
        <!-- auditLogLocation="Application" or "Security" -->  
        <serviceSecurityAudit  
                  auditLogLocation="Application"  
                  suppressAuditFailure="true"  
                  serviceAuthorizationAuditLevel="Failure"  
                  messageAuthenticationAuditLevel="SuccessOrFailure" />
      </behavior>  
    </behaviors>  
  </system.serviceModel>  
</configuration>  

Om granskning är aktiverat och inget auditLogLocation har angetts är standardloggnamnet "Security"-loggen för plattformen som stöder skrivning till säkerhetsloggen. Annars är det "Program"-loggen. Endast Operativsystemen Windows Server 2003 och Windows Vista stöder skrivning till säkerhetsloggen. Mer information finns i avsnittet "Operativsystem" senare i det här avsnittet.

Säkerhetsöverväganden

Om en obehörig användare vet att granskning är aktiverat kan angriparen skicka ogiltiga meddelanden som gör att granskningsposter skrivs. Om granskningsloggen fylls i på det här sättet misslyckas granskningssystemet. För att minimera detta anger du SuppressAuditFailure egenskapen till true och använder egenskaperna för Loggboken för att kontrollera granskningsbeteendet.

Granskningshändelser som skrivs till programloggen i Windows XP är synliga för alla autentiserade användare.

Välja mellan program- och säkerhetshändelseloggar

Följande tabeller innehåller information som hjälper dig att välja om du vill logga in på program- eller säkerhetshändelseloggen.

Operativsystem

System Programlogg Säkerhetslogg
Windows XP SP2 eller senare Stöds Stöds inte
Windows Server 2003 SP1 och Windows Vista Stöds Trådkontexten måste ha SeAuditPrivilege

Andra faktorer

Förutom operativsystemet beskriver följande tabell andra inställningar som styr aktiveringen av loggning.

Faktor Programlogg Säkerhetslogg
Granska principhantering Ej tillämpbart. Tillsammans med konfigurationen styrs säkerhetsloggen också av LSA-principen (Local Security Authority). Kategorin "Granska objektåtkomst" måste också vara aktiverad.
Standardanvändarupplevelse Alla autentiserade användare kan skriva till programloggen, så inga ytterligare behörighetssteg krävs för programprocesser. Programprocessen (kontexten) måste ha SeAuditPrivilege.

Se även