sql >> Database >  >> RDS >> Oracle

Oracle Database Security:Database Auditing

In dit artikel ga ik verder met Oracle Database Security en zal ik enkele belangrijke feiten presenteren over standaard database-audits, audittriggers en auditbeleid in Oracle. Database-auditing bestaat uit twee componenten:monitoring en permanente registratie van gevestigde database-activiteitensets en -gebeurtenissen. De doeleinden van database-audits zijn onweerlegbaarheid, onderzoek naar verdachte activiteiten, detectie van problemen die worden gegenereerd door configuraties met betrekking tot autorisatie (toegang tot bronnen), naleving van actuele wetgeving en controle.

Standaard controle

Welke activiteiten controleren we? Het starten en stoppen van de database en de verbindingen die door de databasebeheerder worden gemaakt, worden impliciet gecontroleerd door Oracle en de gegevens worden automatisch opgeslagen in het besturingssysteem. De onderstaande tabel toont andere activiteiten die kunnen worden gecontroleerd:

Waar bewaren we de gecontroleerde activiteiten?

  • in de database , met behulp van database audit trail, waar we twee mogelijkheden hebben:
    • audit_trail =DB
      wat gedaan kan worden met de volgende code:

      alter system set audit_trail=db scope=spfile;
    • audit_trail =DB,EXTENDED
      met de volgende code:

      alter system set audit_trail= db, extended scope=spfile;

    Het verschil tussen DB en DB,EXTENDED is dat de tweede de kolommen SQLBIND en SQLTEXT CLOB van de tabel SYS.AUD$ vult.

  • extern , met behulp van de audit trail van het besturingssysteem, met de volgende mogelijkheden:
    • audit_trail =OS
      en de gebruikte code is:

      alter system set audit_trail=os scope=spfile;
    • audit_trail =XML en het AUDIT_FILE_DEST =bestandspad (impliciet is $ORACLE_BASE/admin/$ORACLE_SID/adump)
      met de code:

      alter system set audit_trail=xml scope=spfile;

Om de huidige configuratie van de opgeslagen gecontroleerde activiteiten te vinden, kan men de volgende query uitvoeren, geschreven met kleine letters:

select value from v$parameter where name='audit_trail';

Meer nuttige commando's:

[tabel id=43 /]

Laten we nu enkele voorbeelden geven van database-audits.

Hier is een voorbeeld van een standaardaudit met gecontroleerde informatie die is opgeslagen in de database:

De gecontroleerde informatie bestaat uit de SELECT-instructies die op de databasetabellen worden uitgevoerd.

Voer in SQL Developer het volgende script uit:

alter system set audit_trail= db, extended scope=spfile;
AUDIT SELECT TABLE;

Daarna moet de database opnieuw worden opgestart. Om dat te doen, maakt u in de SQLPlus-terminal verbinding met gebruikersnaam sys als sysdba / wachtwoord en voert u de volgende instructies uit:

SHUTDOWN IMMEDIATE
STARTUP

Houd er rekening mee dat de bovenstaande maten van systeem tot systeem verschillen.

Voer de volgende query uit om te controleren of de audit trail correct is ingesteld:

select value from v$parameter where name='audit_trail';

of:

show parameter audit_trail;

Als u de audit wilt stoppen, voert u het volgende uit:

NOAUDIT SELECT TABLE;

Om te zien welke verklaringen tijdens de audit zijn vastgelegd, kunt u het volgende gebruiken:

select dbms_lob.substr( sqltext, 4000, 1 )
from SYS.AUD$
where OBJ$NAME IN ('EMPLOYEES','DEPARTMENTS','JOBS','LOCATIONS');

of

select count(*), OBJ$NAME, USERID
from SYS.AUD$
where OBJ$NAME IN ('EMPLOYEES','DEPARTMENTS','JOBS','LOCATIONS')
group by rollup (OBJ$NAME, USERID);

Een ander voorbeeld is een standaardaudit met gecontroleerde gegevens die zijn opgeslagen in een XML-bestand, in het standaardpad.

alter system set audit_trail=xml scope=spfile;
AUDIT SELECT, INSERT, UPDATE, DELETE ON employees WHENEVER NOT
SUCCESSFUL;

Start de database opnieuw:maak verbinding met de SQLPlus-terminal met gebruikersnaam sys als sysdba / wachtwoord en voer de opdrachten SHUTDOWN IMMEDIATE en STARTUP uit.

Elke keer dat een selectie-, invoeg-, update- en verwijderquery mislukt in de werknemerstabel, moet deze worden vastgelegd in het XML-bestand.

Als we de audit willen stoppen, voeren we de volgende opdrachten uit in de database-ontwikkelomgeving:

NOAUDIT ALL;
NOAUDIT ALL ON DEFAULT;

En herstel de standaard audit trail:

alter system set audit_trail=db scope=spfile;

Hieronder ziet u een voorbeeld van een deel van een XML-controlebestand:

Hoe verwijderen we de gecontroleerde informatie?

Het volume van de gecontroleerde gegevens kan erg groot worden vanwege het aantal gecontroleerde activiteiten en hun frequentie. Daarom wordt aanbevolen om de gecontroleerde gegevens periodiek te archiveren en uit het productiesysteem te verwijderen.

Als de gecontroleerde gegevens zijn opgeslagen in de database (database-auditspoor), kunnen we verwijderinstructies gebruiken (maar alleen nadat we de gegevens hebben gearchiveerd!):

DELETE FROM SYS.AUD$;

U kunt ervoor kiezen om de gecontroleerde informatie voor een specifiek databaseobject te verwijderen, bijvoorbeeld een tabel met de naam producten:

DELETE FROM SYS.AUD$ WHERE OBJ$NAME='PRODUCTS';

Audittriggers

Een trigger is een PL/SQL-blok of de CALL-instructie van een PL/SQL-procedure die automatisch wordt uitgevoerd telkens wanneer zich een gebeurtenis voordoet. Er zijn twee soorten triggers:op databaseniveau (databasestatements) en op applicatieniveau (bijvoorbeeld een knop indrukken op een Oracle Form). De triggers die voor controle worden gebruikt, zijn de triggers op databaseniveau. Ze classificeren in de volgende categorieën:

  • DML-triggers – waarbij een DML-instructie wordt geactiveerd op een tabel. Die triggers kunnen eenmalig worden uitgevoerd op commandoniveau, ongeacht het aantal records (triggers op instructieniveau) of ze kunnen VOOR ELKE RIJ worden uitgevoerd (triggers op recordniveau). Typen triggers op recordniveau:VOOR VERKLARING, NA VERKLARING, VOOR ELKE RIJ, NA ELKE RIJ;
  • IN PLAATS VAN triggers – waar een DML-instructie wordt geactiveerd op een weergave;
  • SYSTEEM-triggers – geactiveerd door gebeurtenissen zoals het starten/stoppen van de database, DDL-instructies, inloggen/uitloggen van gebruikers. Typen systeemtriggers:NA GEBEURTENIS, VOOR GEBEURTENIS.

Opvragen van de SYS.TRIGGER$ tafel of de ALL_TRIGGERS view biedt informatie over alle triggers op databaseniveau. Het onderscheidende triggertype uit de database kan bijvoorbeeld als volgt worden gevonden:

SELECT DISTINCT TRIGGER_TYPE FROM ALL_TRIGGERS;

De DBA_TRIGGERS-weergave biedt informatie over de triggers die tijdens de installatie automatisch door de Oracle-producten worden gemaakt. Als we informatie willen vinden over de SYSTEEM-triggers ('BEFORE EVENT' en 'NA EVENT'), kunnen we de volgende verklaring uitvoeren:

SELECT SUBSTR(OWNER,1,20) OWNER ,SUBSTR(TRIGGER_NAME,1,30),
TRIGGER_NAME, SUBSTR(TRIGGERING_EVENT,1,30) TRIGGERING_EVENT,
TRIGGER_TYPE
FROM DBA_TRIGGERS
WHERE TRIGGER_TYPE='BEFORE EVENT' OR TRIGGER_TYPE='AFTER EVENT'
ORDER BY TRIGGER_TYPE DESC;

Bij de installatie worden ook automatisch DML-triggers gemaakt op het HR-gebruikersschema:

SELECT SUBSTR(TABLE_NAME,1,20) TABLE_NAME,
SUBSTR(TRIGGER_TYPE,1,30) TRIGGER_TYPE,TRIGGER_BODY
FROM DBA_TRIGGERS
WHERE OWNER='HR';

Voor auditing kunnen we aangepaste triggers maken om de gewenste informatie vast te leggen, maar men moet een speciale tabel maken om de gecontroleerde informatie op te slaan.

Het is belangrijk om ervoor te zorgen dat de ontwikkelde triggers de normale database-activiteit niet beïnvloeden. Het doel van auditing is om passief toezicht te houden op de normale, dagelijkse database-activiteit en deze op te slaan voor latere analyse. Daarom wordt het niet aanbevolen om IN PLAATS VAN triggers te creëren om de resultaten van de doeltabellen terug te sturen naar de controletabel.

DML-triggers op instructieniveau kunnen naast DML-triggers op recordniveau bestaan. De volgorde van bellen is:

  • trigger BEFORE-instructie
  • voor elk betrokken record
    • trigger VOORDAT opnemen
    • huidige DML-actie
    • trigger NA record
  • trigger AFTER-instructie

Door de gebruiker gedefinieerde triggers worden alleen uitgevoerd als, volgens Oracle, de instructie correct is en kan voorkomen. Voor een verkeerde DML-instructie of een die een beperking schendt, wordt een fout geretourneerd en wordt de trigger niet uitgevoerd. Daarom wordt voor auditing aanbevolen om met name de LMD-triggers op instructieniveau te gebruiken.

Voorbeeld van audittrigger:

Laten we aannemen dat we een trigger willen creëren om in een controletabel (genaamd TAB_AUDIT_EMP) informatie vast te leggen over de DML-verklaringen die salarissen van meer dan 20000 (valuta is hier niet belangrijk) voor de werknemers van het bedrijf vaststellen. We willen in TAB_AUDIT_EMP het volgnummer van de zoekopdracht, de gebruikersnaam, de sessie, de host en de datum opslaan.

Dit kan als volgt:

CREATE TABLE TAB_AUDIT_EMP

(secv_id NUMBER(3) PRIMARY KEY,
username VARCHAR2(20),
session_nr NUMBER(10),
hostname VARCHAR2(100),
query_date DATE
);

CREATE SEQUENCE secv_aud_emp START WITH 1 INCREMENT BY 1;
CREATE OR REPLACE TRIGGER huge_salary
AFTER INSERT OR UPDATE OR DELETE OF SALARY ON EMPLOYEES
FOR EACH ROW WHEN (NEW.salary>20000)
BEGIN
INSERT INTO TAB_AUDIT_EMP
VALUES(secv_aud_emp.NEXTVAL , sys_context('userenv', 'session_user'), sys_context('userenv', 'sessionid'), sys_context('userenv', 'host'), sysdate);
END;

Stel dat we een salariswijziging doorvoeren voor de medewerkers van een bepaalde afdeling:

UPDATE EMPLOYEES
SET SALARY=25000
WHERE ID_DEPARTMENT = 1;

En dan verifiëren we de monitoring:

select secv_id, substr(username,1,20) username, session_nr, substr(hostname,1,30) hostname, query_date
from TAB_AUDIT_EMP;

Controlebeleid

De derde controlemethode verwijst naar controlebeleid. De definitie van een auditbeleid houdt het volgende in:

  • specificatie van het object (schema, objectnaam, kolommen) onderworpen aan monitoring
  • specificatie van de gecontroleerde acties voor een object (SELECT, INSERT, UPDATE, DELETE):impliciet is het SELECT
  • specificatie van de voorwaarden waaraan moet worden voldaan om de gecontroleerde informatie vast te leggen, wordt gedaan in de WHEN-clausule van de trigger en is optioneel
  • een gebeurtenis-handler die bovendien de gebeurtenis afhandelt, wat optioneel is.

Een auditbeleid kan bijvoorbeeld actief (ENABLED-status) of inactief (DISABLED-status) zijn. De lijst met het controlebeleid kan worden verkregen door de weergave ALL_AUDIT_POLICIES op te vragen:

SELECT POLICY_TEXT, ENABLED
FROM ALL_AUDIT_POLICIES

Voor het beheer van auditbeleid hebben we het pakket DBMS_FGA. Om dit pakket te gebruiken, is het noodzakelijk om privileges te verlenen aan de gebruikers die PL/SQL-code zullen schrijven:

grant execute on dbms_fga to username;

Voorbeeld van auditbeleid:

We willen een controlebeleid maken voor het vastleggen van de DML-statements die de managers wijzigen (MANAGER_ID) in de DEPARTMENTS-tabel. We kunnen ervoor kiezen om een ​​handler voor het beleid te maken, genaamd proc_audit_alert, die ons informeert over een wijziging met betrekking tot de manager:

CREATE OR REPLACE PROCEDURE proc_audit_alert ( object_schema VARCHAR2, object_name VARCHAR2, policy_name VARCHAR2 ) AS
BEGIN
DBMS_OUTPUT.PUT_LINE('Alert! Manager Changed !');
END;

En het beleid kan zijn:

CREATE OR REPLACE PROCEDURE proc_audit_manager AS
BEGIN
DBMS_FGA.ADD_POLICY
(
object_schema=>'ADMINDB',
object_name=>'DEPARTMENTS',
policy_name=>'proc_audit_manager',
audit_column=>'ID_MANAGER',
enable=>false,
statement_types=>'UPDATE',
handler_module=>'proc_audit_alert'
);
DBMS_FGA.ENABLE_POLICY
( object_schema=>'ADMINDB',
object_name=>'DEPARTMENTS',
policy_name=>'proc_audit_manager');
END;

Merk op dat object_schema, object_name, policy_name, audit_column, statement_types en handler_module moeten worden aangepast aan het beleid dat u wilt schrijven.

Vervolgens voeren we de procedure uit:

EXECUTE proc_audit_manager;

We kunnen controleren of het beleid is ingeschakeld:

SELECT ENABLED, POLICY_NAME
FROM ALL_AUDIT_POLICIES
WHERE OBJECT_NAME='DEPARTMENTS';

Controleer vervolgens of de procedure en het beleid correct werken door een update uit te voeren:

UPDATE DEPARTMENTS
SET ID_MANAGER=2
WHERE ID_DEPARTAMENT=1;

Concluderend, auditing is noodzakelijk voor elke database en de bovenstaande methoden helpen u bij het vinden van verdachte activiteiten die de beveiliging van uw database kunnen beïnvloeden. Zie de onderstaande bibliografie voor meer informatie over het controleren van Oracle-databases.

Bibliografie:

  • http://www.datadisk.co.uk/html_docs/oracle/auditing.htm
  • http://docs.oracle.com/cd/B10501_01/server.920/a96521/audit.htm
  • https://docs.oracle.com/cd/E11882_01/server.112/e10575/tdpsg_auditing.htm#TDPSG50000

  1. toegang geweigerd voor laadgegevensbestand in MySQL

  2. Verstuur e-mails met bijlagen in SQL Server (T-SQL)

  3. T-SQL-bugs, valkuilen en best practices - draaiend en ondraaiend

  4. INFORMATION_SCHEMA versus sysobjects