Grundlæggende i Oracle 12c Audits - dummies

Sikkerhed er afgørende, fordi du ikke vil have de forkerte mennesker, der kigger på Oracle 12c dataene, og fordi du skal beskytte data mod at blive ændret eller beskadiget. Revision er en ting, du kan bruge til sikkerhed. At kunne begrænse og overvåge brugerne i systemet hjælper dig med at sikre et sikkert og sikkert arbejdsmiljø for dig og dine kunder eller kunder.

Sådan aktiveres og deaktiveres revisioner med ensartede revisionspolitikker i Oracle 12c

Du kan gøre alt det ønskede opsætning, men intet er revideret (undtagen standardindstillinger), indtil du vælger at gøre det. Dette gavner dig, fordi du kan oprette, oprette og konfigurere din applikation og objekter, før du skal administrere et revisionsspor. Du tænder og slukker for auditering med kommandoen AUDIT eller NOAUDIT.

Da Oracle 12c gør en hel del standard revision, bør du overveje at slukke for nogle, før du indstiller din applikation. Derefter kan du aktivere al den revision du ønsker lige før din ansøgning går til produktion. Gør den beslutning baseret på dine egne forretningsbehov.

En samlet revisionspolitik er en navngivet gruppe af revisionsindstillinger, der reviderer et bestemt aspekt af brugeradfærd. CREATE AUDIT POLICY erklæringen opretter politikkerne. Politikken kan være så enkel som at revidere aktiviteterne hos en enkelt bruger eller et organiseret sæt komplekse revisionspolitikker, som bruger betingelser for at påvirke bestemte revisioner.

Du kan også have mere end en revisionspolitik aktiveret i databasen. Politikker kan omfatte både system-dækkende og objektspecifikke revisionsindstillinger. Det meste af den revision, du vil gøre for generelle aktiviteter (herunder standard revision), skal bruge revisionspolitikker.

Sådan revideres Oracle 12c-systemrettigheder

Med sikkerhed er det så vigtigt, at Oracle 12c leveres med en vis revision automatisk aktiveret via ORA_SECURECONFIG-politikken. Desuden er det ikke altid brugernes handlinger, du vil revidere, men hvad de er forsøger at gøre. En revision kan genereres, selv når nogen forsøger at gøre noget, må han ikke gøre det.

Standardrevisioner

Standard forudkonfigurerede revisioner i 12c omfatter systemrettigheder eller revisionsopgørelser, herunder kommandoer og handlinger som CONNECT, ALTER, DROP, CREATE og så videre.

Du kan f.eks. Spore, hvem der opretter tabeller i databasen, eller hvor ofte tabeller oprettes. Denne enkle politik bliver til revision for enhver CREATE TABLE-sætning, der genererer en revisionsindgang hver gang nogen opretter en tabel. Skriv følgende:

CREATE AUDIT POLICY table_cre_policy PRIVILEGES CREATE TABLE;

Du ser dette:

Operation 229 lykkedes.

Hvis du vil aktivere denne politik for brugeren SHARDIN, skal du skrive

Du ser dette:

Revisionen lykkedes.

Indtast følgende for at deaktivere politik for SHARDIN:

Sådan kontrolleres succesfulde og mislykkede forsøg separat

Standarden er at revidere både succesfulde og mislykkede forsøg. Du kan revidere erklæringen, hvis brugeren gennemfører kommandoen med succes. revisionen sker ikke, hvis kommandoen fejler. Denne tilgang kan være nyttig på to måder:

• Hvis du kun kontrollerer succesfulde kommandoer, behøver du ikke at sejle gennem en masse revisionsposter, der viser en bruger, der forsøger at få den korrekte syntaks.

• Hvis du specifikt kontrollerer de mislykkede kommandoer, kan du fange brugere, der forsøger at gøre ting, som de ikke skal. Antag for eksempel, at brugere er forbudt at tabe tabeller, som de ikke ejer. For det første kan du forhindre upassende dråber ved ikke at give dem DROP ANY TABLE system privilegium. For det andet, hvis de forsøger at gøre det alligevel, genererer det en fejl og reviderer det mislykkede forsøg.

Denne politik reviderer kommandoen DROP ANY TABLE. Skriv følgende:

Du ser dette:

Operation 229 lykkedes.

For at revidere kun mislykkede forsøg på brugeren JKOTAN, udfør følgende:

Du ser dette:

Revisionen lykkedes.

Sådan revideres Oracle 12c-objekter

Overvej objektrevision, hvis du vil revidere erklæringer, som f.eks. VÆLG, INDSÆT, OPDATE og DELETE. Objektrevision kan spore

• Handlinger mod specifikke objekter

• Privilegier på alle eller specifikke tabeller

Det kan være skræmmende at sive gennem et revisionsspor i en database med tusindvis af reviderede objekter. Det er også sandsynligt, at nogle objekter simpelthen ikke behøver revision. Hvis det er tilfældet, begræns din revision til bestemte objekter.

Endvidere kan du revidere objekter med disse parametre:

• Når operationen lykkes eller når den fejler

• Kun en gang pr. Session eller hver gang den udføres

Hvis du reviderer et objekt kun én gang pr. Session, det revideres første gang brugeren udsteder erklæringen. Hver gang efter det ignoreres det. Dette reducerer dit revisionsspor, men holder dig også i stand til at være 100 procent sikker, hvis den pågældende bruger er ansvarlig for senere operationer mod en bestemt genstand i en session.

Hvis en bruger f.eks. Sletter en række fra MEDARBEJDERE, revideres erklæringen. Hvis brugeren vender tilbage senere og sletter en anden række inden for samme session, bliver den ikke revideret. Du ved hvad de siger dog: Hvor der er røg, er der ild!

At oprette en revisionspolitik for SELECT mod HR. EMPLOYEES tabel, skriv følgende:

Du ser dette:

Operation 229 lykkedes.

For derefter at revidere hver erklæring for brugeren DCOLLINS, skriv

Du ser dette:

Revisionen lykkedes.