Za reviziju pristupa datotekama i folderima u Windows Server 2008 R2, morate omogućiti funkciju revizije, kao i navesti fascikle i datoteke kojima pristup treba da se evidentira. Nakon postavljanja revizije, serverski dnevnik će sadržavati informacije o pristupu i drugim događajima na odabranim datotekama i folderima. Vrijedi napomenuti da se revizija pristupa datotekama i mapama može izvršiti samo na volumenima sa NTFS sistemom datoteka.
Omogućite reviziju objekata sistema datoteka u Windows Server 2008 R2
Revizija pristupa datotekama i fasciklama je omogućena i onemogućena pomoću smernica grupe: politika domena za domain Active Imenik ili lokalne politike sigurnost za odvojeno stojeći serveri. Da biste omogućili reviziju na pojedinačnom serveru, morate otvoriti konzolu za upravljanje lokalnim pravilima Start ->SveProgrami ->AdministrativnoAlati ->LokalnoSigurnostPolicy. U konzoli lokalnih politika, morate proširiti stablo lokalnih politika ( LokalnoPravila) i odaberite element RevizijaPolicy.
IN desni panel potrebno je da odaberete element RevizijaObjekatPristup i u prozoru koji se pojavi navedite koje vrste događaja pristupa datotekama i fasciklama treba da budu snimljene (uspešan/neuspešan pristup):
Nakon selekcije neophodna podešavanja treba pritisnuti UREDU.
Odabir datoteka i foldera kojima će se snimati pristup
Nakon što je revizijski pristup datotekama i fasciklama aktiviran, morate odabrati specifičnih objekata sistem datoteka, pristup kojem će biti revidiran. Baš kao i NTFS dozvole, postavke revizije se nasljeđuju prema zadanim postavkama za sve podređene objekte (osim ako nije drugačije konfigurirano). Baš kao i kod dodjeljivanja prava pristupa datotekama i mapama, nasljeđivanje postavki revizije može se omogućiti za sve ili samo za odabrane objekte.
Da biste podesili reviziju za određeni folder/fajl, potrebno je da kliknete na njega desni klik miša i odaberite Svojstva ( Svojstva). U prozoru sa svojstvima idite na karticu Sigurnost ( Sigurnost) i pritisnite dugme Napredno. U prozoru naprednih sigurnosnih postavki ( NaprednoSigurnostPostavke) idite na karticu Revizija ( Revizija). Postavljanje revizije, naravno, zahtijeva administratorska prava. U ovoj fazi, prozor revizije će prikazati listu korisnika i grupa za koje je omogućena revizija za ovaj resurs:
Za dodavanje korisnika ili grupa čiji pristup ovaj objekatće biti popravljeno, potrebno je da pritisnete dugme Dodati… i navedite imena ovih korisnika/grupa (ili navedite Svi– za reviziju pristupa svih korisnika):
Odmah nakon primjene ovih postavki u dnevniku Sigurnosnog sistema (možete ga pronaći u KompjuterUpravljanje -> Preglednik događaja), svaki put kada pristupite objektima za koje je omogućena revizija, pojavit će se odgovarajući unosi.
Alternativno, događaji se mogu pregledati i filtrirati pomoću PowerShell cmdleta − Get-EventLog Na primjer, da prikažete sve događaje sa eventid 4660, pokrenite naredbu:
Get-EventLog sigurnost | ?($_.eventid -eq 4660)
Savjet. Moguće je dodijeliti određene radnje bilo kojim događajima u Windows dnevniku, kao što je slanje email ili izvršavanje skripte. Kako je ovo konfigurisano opisano je u članku:
UPD od 06.08.2012 (Hvala komentatoru).
U Windows 2008/Windows 7, uvedeno je upravljanje revizijom poseban uslužni program auditpol. Cijela lista Tipovi objekata za koje se može omogućiti revizija mogu se vidjeti pomoću naredbe:
Auditpol /list /potkategorija:*
Kao što vidite, ovi objekti su podijeljeni u 9 kategorija:
- Sistem
- Prijava/odjava
- Pristup objektu
- Privilege Use
- Detaljno praćenje
- Promjena politike
- Upravljanje računa
- DS Access
- Prijava na račun
I svaka od njih je, u skladu s tim, podijeljena u potkategorije. Na primjer, kategorija revizije pristupa objektu uključuje potkategoriju Sistem podataka i da omogućite reviziju za objekte sistema datoteka na računaru, pokrenite naredbu:
Auditpol /set /podkategorija:"File System" /failure:enable /success:enable
U skladu s tim se onemogućava naredbom:
Auditpol /set /podkategorija:"File System" /failure:disable /success:disable
One. Ako onemogućite reviziju nepotrebnih potkategorija, možete značajno smanjiti volumen dnevnika i broj nepotrebnih događaja.
Nakon što je revizijski pristup datotekama i fasciklama aktiviran, potrebno je da navedete konkretne objekte koje ćemo nadgledati (u svojstvima datoteka i fascikli). Imajte na umu da se po defaultu postavke revizije nasljeđuju za sve podređene objekte (osim ako nije drugačije navedeno).
Zdravo svima!
Nastavljamo sa objavljivanjem varalica o postavljanju revizije razni sistemi, prošli put kada smo govorili o AD habrahabr.ru/company/netwrix/blog/140569, danas ćemo razgovarati o serverima datoteka. Mora se reći da najčešće vršimo reviziju podešavanja za fajl servere - tokom pilot instalacija sa korisnicima. U ovom zadatku nema ništa komplikovano, samo tri jednostavna koraka:
- Postavite reviziju na dijeljenim datotekama
- Konfigurišite i primenite opšte i detaljne politike revizije
- Promijenite postavke dnevnika događaja
Postavljanje revizije na resursima datoteka
Uspostavljanje opšte politike revizije
Kako biste kontrolirali promjene na server datoteka, morate konfigurirati politiku revizije. Prije postavljanja politike, uvjerite se da je vaš nalog član grupe administratora ili da imate prava za upravljanje evidencijama revizije i događaja u dodatku za pravila grupe.
Postavljanje detaljne politike revizije
Postavljanje dnevnika događaja
Da bi se efektivno kontrolisale promene, potrebno je konfigurisati evidenciju događaja, odnosno set maksimalna veličinačasopisi. Ako je veličina nedovoljna, događaji mogu biti prepisani prije nego stignu u bazu podataka koju koristi vaša aplikacija za kontrolu promjena.
Na kraju, želimo vam ponuditi skriptu koju i sami koristimo prilikom postavljanja revizije na serverima datoteka. Skripta konfiguriše reviziju svih dijeljenja za svaki računar u datoj OU. Na ovaj način ne morate omogućiti postavke na svakom fajl resurs ručno.
Prije pokretanja skripte, trebate urediti red 19 - unesite tražene vrijednosti umjesto "your_ou_name" i "your_domain". Skripta se mora izvršiti pod nalogom koji ima administratorska prava domena.
Skriptu možete dobiti u našoj bazi znanja ili spremiti sljedeći tekst u .ps1 datoteku:
#import-module activedirectory #$path = $args; # \\fileserver\share\folder $account = "Svi" # $args; $flavor = "Uspjeh,Neuspjeh" #$args; $flags = " ReadData, WriteData, AppendData, WriteExtendedAttributes, DeleteSubdirectoriesAndFiles, WriteAttributes, Delete, ChangePermissions, TakeOwnership " $inheritance = "ContainerInherit, ObjectInherit" $propagation = "Nijedan-AD Get" $Comps vaše_ou_name,DC=vaša_domena,DC=vaša_domena" | select -exp DNSHostName foreach ($comp u $comps) ( $shares = get-wmiobject -class win32_share -computername $comp -filter "type=0 I ime poput "%[^$]"" | select -exp ime foreach ( $share in $shares) ( $path = "\\"+$comp+"\"+$share $path $acl = (Get-Item $path).GetAccessControl("Access,Audit") $ace = new-object System.Security.AccessControl.FileSystemAuditRule($account, $flags, $inheritance, $propagation, $flavor) $acl.AddAuditRule($ace) set-acl -path $path -AclObject $acl ) )
Dobar dan, prijatelji i kolege. Danas ćemo razgovarati o tome kako pratiti promjene na vašim serverima datoteka, odnosno ko je šta uradio sa fajlom; Jeste li ga slučajno izbrisali? stvorena iz nekog razloga nepotreban fajl itd. Naravno, najmanje tri stvari su usko povezane s ovom temom: dokumentarni opis dijeljenja datoteka, korištenje filtera datoteka (zabrana određeni tip datoteke) i sistem za ograničavanje veličine skladišta (sistem kvota). Ali ove stvari će ići daleko izvan okvira jednog članka. Ako je tema tražena, članci o tim temama će se pojaviti u budućnosti.
Za iskusne administratore koji su već radili slične stvari, ovdje nećete pronaći ništa novo. Tehnologije revizije pojavile su se davno. Jednostavno ću podijeliti svoje iskustvo i izraziti svoje mišljenje o nekim stvarima koje su, po mom mišljenju, jednostavno neophodne na fajl serverima na domenskoj mreži.
Prvo, moramo omogućiti naprednu reviziju kroz politiku grupe i primijeniti je na pravi serveri. Uradiću to na testu Windows server Server 2008 R2, sve na mojoj mreži je urađeno na 2012 R2. Princip i interfejs su približno isti. Generalno, sistem revizije se pojavio još od vremena Windows Servera 2000 (možda čak i u NT-u, ali to nije važno), aktivno ga koriste i koriste mnogi administratori. Sa verzijom 2008, postala je dostupna i napredna revizija. Koristio sam i staru i novu reviziju dok nisam primijetio jake inovacije. Ali općenito, nova revizija je fleksibilnija u upravljanju i postavkama. Najvažnija prednost ove tehnologije je mogućnost obavljanja revizije samo na resursu koji nam je potreban. Odavde se gotovo svi sigurnosni događaji prikazuju u dnevniku onim redoslijedom koji nam je potreban, gdje nema ništa suvišno. Stoga je veličina magazina znatno manja.
U upravljanju grupnim pravilima idite na odjeljak Politika grupe i tamo kreirajte novi GPO:
Pozvali, kliknuli OK. Sada morate prijeći na svojstva novog objekta. Sve što se odnosi na reviziju i drugu sigurnost je gotovo uvijek unutar konfiguracije računara, tako da odmah idemo na to (pogledajte snimak ekrana):
U sigurnosnim postavkama moramo "podesiti" parametre sigurnosnog dnevnika (u odjeljku "Evidencija događaja") i konfigurirati, zapravo, samu reviziju (u odjeljku "Napredna konfiguracija politike revizije"):
Objasniću na minimum, jer... sve je čisto individualno. Postavljamo veličinu (najvjerovatnije 100-200 MB, u zavisnosti od veličine mrežnog foldera i broja korisnika), postavljamo maksimalni rok pohranjivanja događaja (meni su dovoljne 2 sedmice), automatski se zamjenjuje način čuvanja “dan po dan”. Mislim da tu nema ništa komplikovano. Sada da postavimo reviziju, nama najvažniju stvar:
Kako doći do toga: najbolje se vidi vašim očima na snimku ekrana. Imajte na umu da uprkos činjenici da ćemo izvršiti reviziju dijeljenja datoteka, i dalje moramo odabrati “Revizija sistema datoteka”. Sada ću pokušati da objasnim zašto. Činjenica je da ako odaberete "Revizija informacija o dijeljenom resursu datoteke", što bi se činilo logičnije, onda će se izvršiti vrlo (ponavljam, "vrlo") detaljna revizija SVIH mrežne fascikle SVI događaji, uklj. samo pogledi, mrežna sinhronizacija, atributi čitanja i mnogi, mnogi drugi događaji. Lično, moj dnevnik je rastao otprilike ovako: jedan sat = 50-100 MB dnevnika tokom dana, noću sa nultom aktivnošću = 30 MB. Općenito, ne preporučujem da omogućite ovaj potvrdni okvir. Zanimaju nas određeni folder i određeni događaji (promjena/kreacija/brisanje), pa biramo sistem datoteka. Upravo je ovaj trenutak (proces odabira revizije) slabo opisan na internetu, sve je površno naznačeno. Čak ni u službenom udžbeniku nisam našao objašnjenje svih nijansi. Tip događaja je „uspjeh“ (kada je operacija s fajlom i mapom bila uspješna), iako je moguće izvršiti reviziju „neuspjeha“, tj. pokušaji da se nešto uradi u nedostatku prava. Uvjerite se sami ovdje.
Hajdemo sada da optimizujemo politiku. Prvo ga primjenjujemo na server. U mom slučaju, sve radim na kontroloru domene i stoga se primjenjujem na OU kontrolera domene. File Services raditi na kontroleru domena, što nije dobro. Ali iz razloga se to dogodilo na ovaj način. Brišemo “authenticated” tako da se politika ne primjenjuje na druge servere (imam druge kontrolere domena):
Kliknite "Dodaj", odredite tip objekta "Računari" i tamo unesite naziv našeg servera:
Dotjerajmo politiku još bolje. Da bi se ubrzala primena smernica, Microsoft preporučuje da uvek navedete koje konfiguracije da primenite, a koje ne. U suprotnom, pokušava se primijeniti konfiguracije i računala i korisnika odjednom. Naša politika se primjenjuje na računar, tako da to možemo naznačiti u stanju politike. U technetu pišu da na taj način rasteretimo kontroler domene.
Kontrolna provjera političari. Provjera rezultata: Prvi dio je završen. Sada idemo na fajl server. Uvjerimo se da je folder postavljen na mrežu opšti pristup:
I idite na karticu "Sigurnost", odnosno na odjeljak "napredno":
Zanima nas kartica "Revizija":
Sada je prazan jer ništa nije konfigurisano. Sada ćemo dodati ono što se zove SACL (System Access Control Lists). Razlikuje se od NTFS ACL-a po tome što je to samo revizija, mi u suštini ne dajemo nikakva prava na folder, tako da ovu listu ne treba tretirati kao listu pravi pristup u folder. Zapamtite da je ovo potpuno drugačije. Zato dodajem grupu Svi i dajem potreban kriterij revizije:
Poništim izbor u polju za potvrdu “Dodaj elemente revizije, naslijeđeno...”; može biti korisno u budućnosti. Uostalom, u budućnosti možemo vršiti reviziju mrežnih dionica u drugom udjelu. Ako ostavite polje za potvrdu, nema problema.
Također pogledajte sami vrstu revizije. Trebam reviziju promjena datoteka, može se učiniti još fleksibilnijim, ali morate imati na umu da povećate opterećenje na serveru i veličinu dnevnika.
Postavke revizije za folder mogu se primjenjivati neko vrijeme (pojavljuje se prozor aplikacije statusa). Nakon svih ovih radnji, prijeđimo na treći dio - verifikaciju.
Primjenjujemo novu politiku na server datoteka i vidimo da li je primijenjena (gpupdate /force i gpresult /r komande):
Upalilo mi je. Sada idem na sigurnosni dnevnik i brišem ga:
Sada dolazi zabavni dio. Pokušavam pristupiti folderu preko mreže sa drugog računara i nešto promijeniti. U teoriji, odmah nakon ovoga pojavljuje se događaj poput „ko je uradio/šta je uradio/kada, itd.“:
Sve je prikazano u događaju. Ali kada ima puno događaja, korištenje dnevnika nije tako zgodno. Stoga se preporučuje da sačuvate prijavu pogodan format(csv, txt, evtx, xml) i dodatno mučite već formirani fajl. To je sve. Koristite reviziju, kolege. Kada imate dokaz o nečijoj krivici, to je vrlo korisno i uvelike pokriva jedno mjesto za admina.
Ažurirano: Prijatelji, trebali biste shvatiti da revizija učitava server i performanse mogu blago pasti. Od lično iskustvo Preporučujem da nakon nedelju dana rada odete na server i proverite veličinu dnevnika, kao i vrstu događaja. Odjednom je časopis dosta porastao i vaša veličina nije dovoljna u GPO-u. Ili je revizija potpuno prestala raditi. Općenito, nadgledajte rad revizije barem povremeno.
Prijatelji! Pridružite se našoj
Da bi promjene stupile na snagu, morate ažurirati svoju lokalnu politiku.
Omogućavanje revizije određenog objekta
Već smo aktivirali mogućnost revizije pristupa objektu datoteke NTFS sistemi. Sada sve što treba da uradimo je da naznačimo koje objekte treba posmatrati. Da biste to učinili, otvorite prozor Svojstva odabrani objekt i idite na karticu Sigurnost. Zatim morate kliknuti na dugme Dodatno i u prozoru koji se otvori idite na karticu Revizija. Dalje akcije može se opisati na sljedeći način:
- Pritisnite dugme Dodati i dodati korisnika ili grupu korisnika čije radnje želimo pratiti.
- Konfigurišemo opseg revizije (revizija samo fascikle, revizija fascikle i njenog sadržaja, itd.)
- Biramo ili reviziju uspješnih ili reviziju neuspješnih radnji u odnosu na objekt.
- Odabiremo one radnje koje treba dokumentirati. Na primjer, odabirom Odstranjivanje Vi dajete instrukcije računaru da dokumentuje samo one radnje korisnika koje uključuju brisanje objekta. Sve predložene radnje su prava pristupa datoteci ili fascikli, s njima se možete upoznati.
- Sačuvaj promjene.
Kako mogu vidjeti rezultate revizije pristupa objektu?
Za rezultate revizije NTFS sistema datoteka, posjetite Windows dnevnik i prođi kroz prozor Sigurnost. Tamo ćete dobiti neobično dugu listu svih radnji koje se odnose na sigurnost računara. Među njima ćete pronaći dokumentaciju o pokušajima pristupa vašem objektu. Koristeći sortiranje, siguran sam da ćete lako pronaći dokumentaciju koja vas zanima.
Kako aktivirati mogućnost revizije NTFS sistema datoteka kroz Registry?
Ova stavka će, kao što sam već rekao, biti od interesa za vlasnike Windows Starter ili Home Basic. Oni nemaju pristup uređivaču lokalnih grupnih politika, ali imaju pristup registru. Registar vam omogućava da radite iste radnje kao i uređivač lokalnih politika. Samo, nažalost, nisam našao drugi parametar, koji duplira drugu politiku. Upoznaću vas sa prvim parametrom: parametrom
HKLM\System\CurrentControlSet\Control\Lsa\SCENoApplyLegacyAuditPolicy
potrebno je promijeniti iz 0 u 1. Ako nađete drugi parametar, napišite u komentarima.
Kao što sam ranije rekao, ovih dana vrijedi voditi računa o sigurnosti korisničkih računa i povjerljivosti podataka vašeg poslovanja. U prethodnim člancima o lokalnim sigurnosnim politikama naučili ste o tehnikama korištenja lokalnih sigurnosnih politika i politikama računa koje možete koristiti da značajno poboljšate sigurnost svojih korisničkih naloga. Sada kada imate ispravno konfigurisane bezbednosne politike naloga, napadačima će biti mnogo teže da dobiju pristup korisničkim nalozima. Ali nemojte zaboraviti da je ovo vaš posao osiguravanja sigurnosti. mrežna infrastruktura ne završava. Svi pokušaji upada i neuspješna autentikacija vaših korisnika moraju biti zabilježeni kako bi se znalo da li treba nešto poduzeti. dodatne mjere kako bi se osigurala sigurnost. Provjera takvih informacija u cilju utvrđivanja aktivnosti u preduzeću naziva se revizija.
Proces revizije koristi tri kontrole: politiku revizije, postavke revizije na objektima i dnevnik "Sigurnost", gdje se evidentiraju događaji vezani za sigurnost, kao što su prijava/odjava sistema, korištenje privilegija i pristup resursima. U ovom članku ćemo pogledati politike revizije i naknadnu analizu događaja u dnevniku "Sigurnost".
Politika revizije
Politika revizije konfigurira sistem određenog korisnika i grupe za reviziju aktivnosti. Da biste konfigurirali politike revizije, u Control Editoru grupne politike morate otvoriti čvor Konfiguracija računara/Konfiguracija Windowsa/Sigurnosne postavke/Lokalna pravila/Politika revizije. Zapamtite da je po defaultu postavka politike revizije za radne stanice postavljena na "Nedefinirano". Ukupno možete konfigurirati devet pravila revizije, koja su prikazana na sljedećoj ilustraciji:
Rice. 1. Čvor “Politika revizije”
Baš kao i kod drugih sigurnosnih politika, da biste konfigurirali reviziju, morate definirati postavku politike. Poslije dvostruki klik kliknite levim tasterom miša na bilo koju od opcija, označite opciju "Definirajte sljedeće postavke pravila" i navedite opcije za reviziju uspjeha, neuspjeha ili obje vrste događaja.
Rice. 2. Svojstva politike revizije “Pristup servisu direktorija revizije”
Jednom kada se konfigurira politika revizije, događaji će biti zabilježeni u sigurnosnom dnevniku. Ove događaje možete vidjeti u sigurnosnom dnevniku. Pogledajmo bliže svaku politiku revizije:
Prijava Audit. Trenutna politika određuje da li operativni sistem korisnika na čijem računaru se ova politika revizije primjenjuje na reviziju svakog pokušaja prijave ili odjave korisnika. Na primjer, kada se korisnik uspješno prijavi na računar, generiše se događaj prijave na nalog. Događaji odjave se generiraju svaki put kada se nalog prijavljenog korisnika završi. Revizija uspjeha znači kreiranje zapisa revizije za svaki uspješan pokušaj prijave. Revizija neuspjeha znači kreiranje zapisa revizije za svaki neuspjeli pokušaj prijave.
Revizija pristupa objektu. Ova politika sigurnosna revizija pokušaja pristupa korisnika objektima koji nisu povezani Aktivni direktorij. Takvi objekti uključuju datoteke, fascikle, štampače, particije sistemski registar, koji su dati sopstvene liste u listi kontrole pristupa sistemu (SACL). Revizija se generira samo za objekte koji imaju specificirane liste kontrole pristupa, pod uvjetom da traženi tip pristupa i račun koji podnosi zahtjev odgovaraju postavkama u tim listama.
Revizija pristupa servisu imenika. Pomoću ove sigurnosne politike možete odrediti hoće li događaji navedeni u listi kontrole pristupa sistemu (SACL), koju možete uređivati u dijaloškom okviru, biti revidirani. « Dodatne opcije sigurnost" Svojstva objekata Active Directory. Revizija se kreira samo za objekte za koje sistemska lista kontrola pristupa, pod uslovom da se traženi tip pristupa i nalog koji podnosi zahtev podudaraju sa parametrima u ovu listu. Ova politika je donekle slična politici "Revizija pristupa objektu". Revizija uspjeha znači kreiranje zapisa revizije kad god korisnik uspješno pristupi na aktivni objekat Direktorij za koji je definirana SACL tablica. Revizija kvara znači kreiranje zapisa revizije kad god korisnik ne uspije pristupiti Active Directory objektu koji ima definiran SACL.
Revizija promjene politike. Ova politika revizije određuje da li operativni sistem revidira svaki pokušaj promjene dodjeljivanja korisničkih prava, revizije, naloga ili politike povjerenja. Revizija uspjeha znači kreiranje zapisa revizije kad god se politike dodjele korisničkih prava, politike revizije ili politike uspješno promijene odnose poverenja. Revizija neuspjeha znači kreiranje zapisa revizije kad god pokušaj promjene politika dodjele korisničkih prava, politika revizije ili politike povjerenja ne uspije.
Promjene privilegija revizije. Koristeći ovu sigurnosnu politiku, možete odrediti da li će korištenje korisničkih privilegija i prava biti revidirano. Revizija uspjeha znači kreiranje evidencije revizije za svaku uspješnu upotrebu korisničkog prava. Revizija neuspjeha znači kreiranje evidencije revizije za svako neuspješno korištenje korisničkog prava.
Revizija praćenja procesa. Trenutna politika revizije određuje da li operativni sistem revidira događaje vezane za proces, kao što su kreiranje i završetak procesa, aktivacija programa i indirektni pristup objektima. Revizija uspjeha znači kreiranje evidencije revizije za svaki uspješan događaj povezan s nadgledanim procesom. Revizija neuspjeha znači kreiranje zapisa revizije za svaki neuspjeli događaj povezan s nadgledanim procesom.
Revizija sistemskih događaja. Ova sigurnosna politika je posebno vrijedna jer pomoću ove politike možete saznati da li je računar korisnika preopterećen, da li je veličina sigurnosnog dnevnika premašila prag upozorenja, da li su praćeni događaji izgubljeni zbog neuspjeha revizije, pa čak i da li je napravljene su promjene koje bi mogle utjecati na sigurnost sistema ili sigurnosnog dnevnika, uključujući promjenu sistemskog vremena. Revizija uspjeha znači kreiranje zapisa revizije za svaki uspješan sistemski događaj. Revizija kvarova znači kreiranje zapisa revizije za svaki sistemski događaj koji ne uspije.
Revizija događaja za prijavu. Pomoću ove politike revizije možete odrediti da li će operativni sistem izvršiti reviziju svaki put kada ovaj računar provjeri akreditive. Kada se koristi ovo pravilo, generira se događaj za lokalne i udaljene prijave korisnika. Članovi domene i računari koji nisu domeni imaju povjerenje u svojim lokalnim nalozima. Kada se korisnik pokuša povezati na zajednički folder na serveru, događaj udaljene prijave se bilježi u sigurnosnom dnevniku, ali događaji odjave se ne bilježe. Revizija uspjeha znači kreiranje zapisa revizije za svaki uspješan pokušaj prijave. Revizija neuspjeha znači kreiranje zapisa revizije za svaki neuspjeli pokušaj prijave.
Revizija upravljanja računom. Ovo najnovija politika se takođe smatra veoma važnim jer vam može pomoći da utvrdite da li treba da izvršite reviziju svakog događaja Kontrole naloga na vašem računaru. Sigurnosni dnevnik će bilježiti aktivnosti kao što su kreiranje, premještanje i onemogućavanje naloga, kao i promjena lozinki i grupa. Revizija uspjeha znači kreiranje evidencije revizije za svaki uspješan događaj upravljanja računom. Revizija neuspjeha znači kreiranje evidencije revizije za svaki događaj upravljanja računom koji ne uspije.
Kao što vidite, sve politike revizije su u određenoj mjeri vrlo slične, a ako postavite reviziju svih politika za svakog korisnika u vašoj organizaciji, onda ćete se prije ili kasnije jednostavno zbuniti u njima. Stoga je potrebno prvo utvrditi šta je tačno potrebno za reviziju. Na primjer, da biste bili sigurni da se jednom od vaših računa stalno pristupa neovlašćeni pristup metodom pogađanja lozinke možete odrediti reviziju neuspjeli pokusaji ulaz. IN sljedeći odjeljak razmotrićemo najjednostavniji primjer korištenje ovih politika.
Primjer korištenja politike revizije
Recimo da imamo domenu testdomain.com, koja ima korisnika sa račun DImaN.Vista. V u ovom primjeru mi ćemo primijeniti politiku za ovog korisnika i vidjeti koji se događaji bilježe u sigurnosnom dnevniku kada se pokuša neovlašteni pristup sistemu. Igrati se slična situacija slijedite ove korake:
Zaključak
U ovom članku nastavili smo proučavanje sigurnosnih politika, naime, pogledali smo postavke politike revizije pomoću kojih možete istražiti pokušaje upada i neuspjelu autentifikaciju vaših korisnika. Uzima se u obzir svih devet sigurnosnih politika odgovornih za reviziju. Također, koristeći primjer, naučili ste kako politike revizije rade koristeći politiku "Revizija događaja prijave". Emulirana je situacija neovlaštenog ulaska u računar korisnika, nakon čega je uslijedila revizija syslog sigurnost.
