Granska säkerhetshändelser

2025-06-17

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 Händelsevisaren.

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:

Auktoriseringsnivå för tjänst, där en anropare är behörig.
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 krävs det SeAuditPrivilege. Som standard har endast lokala system- och nätverkstjänstkonton den här behörigheten. För att hantera funktionerna för säkerhetsloggning read och delete krävs 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.

Revisionskurser

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`, `Success`och `SuccessOrFailure`.
ServiceAuthorizationAuditLevel	Anger vilka typer av tjänstauktoriseringshändelser som granskas på tjänstnivå. Alternativen är `None`, `Failure`, `Success`och `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 konfigurationen för att ange granskningsbeteendet genom att lägga till en <serviceSecurityAudit> under <beteenden>. 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äkerhetshänsyn

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 mildra detta, ställer du in SuppressAuditFailure egenskapen till true och använder egenskaperna för Händelseloggen 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

Systemet	Applikationslogg	Säkerhetslogg
Windows XP SP2 eller senare	Understödd	Stöds inte
Windows Server 2003 SP1 och Windows Vista	Understödd	Trådkontexten måste ha `SeAuditPrivilege`

Andra faktorer

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

Faktor	Applikationslogg	Säkerhetslogg
Revisionspolicyhantering	Ej tillämpbart.	Tillsammans med konfigurationen styrs säkerhetsloggen också av LSA-principen (Local Security Authority). Kategorin "Revision av objektså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`.

Dela via