Oracle adatbázis biztonságának fenntartása

1. Kovács Tibor Krisztián Oracle adatbázis biztonságának fenntartása

2. Tartalom • Az útmutatókról • Útmutatók • A felhasználói fiókok és jogosultságaik biztonságossá tételéről • Szerepkörök biztonságossá tételéről • Jelszavak biztonságossá tételéről • Adatok biztonságossá tételéről • Adatbázis konfigurációk biztonságossá tételéről • Hálózat biztonságossá tételéről • Auditáláshoz • Végül a CONNECT szerepkör módosulásáról

3. Az útmutatókról • Az adatbázis biztonságának fenntartásához készültek az itt leírt útmutatók. • A vállalkozások számára nagyon fontos az információk védelme. Az Oracle DB széleskörűen lefedi az információk biztonsága iránti szükségleteket, olyan élvonalbeli megoldásokkal, mint a mély adatvédelem, auditálás, skálázható védelem, valamint a host és az adatcsere biztosítása.

4. Az útmutatókról • Az Oracle DB bármely vállalkozási környezet számára felkínált biztonsági szolgáltatások maximalizálásához elkerülhetetlen, hogy az adatbázis maga jól védett legyen. • Ezek az útmutatók tanácsot adnak az Oracle DB konfigurálásához ipari szabványok megkövetelésével és ajánlott biztonsági gyakorlatokkal. • Az itt leírt útmutatók általános szabályozó követelmények megvalósítását mutatják be.

5. Az útmutatókról • Mindig frissítsük a futtató op rendszert és az adatbázist a legfrissebb javításokkal. • http://www.oracle.com/technology/deploy/security/alerts.htm • http://metalink.oracle.com • Használjuk a My Oracle Support-otvagy írjunk a secalert_us@oracle.come-mail címre biztonsági hibák felfedezése esetén.

6. Útmutató a felhasználói fiókok és jogaik biztonságossá tételéhez • Az legkevesebb jogosultság elvének gyakorlása • Csak a feltétlen szükséges jogosultságokat biztosítsuk a felhasználóknak. • A CREATE és DROP ANY EDITION jogosultság limitált biztosítása • CREATE ANY JOB, BECOME USER, EXP_FULL_DATABASE, IMP_FULL_DATABASE jogosultság korlátozása • Ne engedjük a nem adminisztratív felhasználók számára a SYS séma objektumainak elérését

7. Útmutató a felhasználói fiókok és jogok biztonságossá tételéhez • A felesleges jogosultságokat vonjuk meg a PUBLIC felhasználói csoporttól. • Az EXECUTE jogosultságot csak megbízható felhasználók számára biztosítsuk a DBMS_RANDOM PL/SQL csomagon • Korlátozzuk a futási idejű eszközök eléréséhez szükséges jogosultságokat • Zároljuk az alapbeállítású felhasználói fiókokat • Az adatbázisba csatlakozó felhasználókról a következő nézettáblákból szerezhetünk információt:

8. Útmutató a felhasználói fiókok és jogok biztonságossá tételéhez • DBA_*, DBA_ROLES, DBA_SYS_PRIVS, DBA_ROLE_PRIVS, DBA_TAB_PRIVS, DBA_AUDIT_TRAIL, DBA_FGA_AUDIT_TRAIL • Figyeljük a következő jogosultságok engedélyezettségét • Oracle DB alapból auditált jogosultságai: • ALTER SYSTEM, AUDIT SYSTEM, CREATE EXTERNAL JOB • Ajánlott az alant leírt további jogosultságok vizsgálatais: • ALL PRIVILAGES, BECOME USER, CREATE LIBRARY, CREATE PROCEDURE, DBMS_BACKUP_RESTORE csomag, EXECUTE a DBMS_SYS_SQL-re, SELECT ANY TABLE

9. Útmutató a felhasználói fiókok és jogok biztonságossá tételéhez • SELECT a PREFSTAT.STATS$SQLTEXT, PREFSTAT.STATS$SQL_SUMMARY, SYS.USER$, SYS.SOURCES$ táblákon • Jogok amik rendelkeznek a WITH ADMIN, WITH GRANT záradékkal, vagy a CREATE kulcsutasítással • Vonjuk meg a hozzáférést a • SYS.USER_HISTORY$ táblához (kivéve SYS és DBA fiókoknak) • A RESOURCE és CONNECT szerepköröket a tipikus alkalmazás fiókoktól • DBA szerepkört azoktól akiknek nincs rá szüksége

10. Útmutató a felhasználói fiókok és jogok biztonságossá tételéhez • Jogosultságokat csak szerepköröknek biztosítsunk az egyszerűbb kezelés miatt. • Szűkítsük a proxi felhasználók jogosultságait CREATE SESSION-re. • Használjuk a secureapplicationroles-t az alkalmazások kódja által engedélyezett szerepkörök védelmére. • A NOLOGGING záradék használatát az SQL utasításokba ne engedélyezzük.

11. Útmutató a szerepkörök biztonságossá tételéhez • Egy szerepkört csak akkor biztosítsunk a felhasználóknak ha a szerepkör minden jogosultságára szüksége van. • Felhasználói jogosultságokat ne biztosítsunk fejlesztőknek. • Minden Oracle DB telepítéshez specifikusan hozzunk létre szerepköröket. • A nagy üzleti felhasználók számára hozzunk létre globális szerepköröket.

12. Útmutató a jelszavak biztonságossá tételéhez • Figyelmesen válasszunk jelszót • 8-30 karakter között • Minimum egy nagybetűvel és egy számmal • Vegyesen nagybetűt és kisbetűt és speciális jeleket • Stb… • Csináljunk mondatokból rövidítéssel, vagy több egyszerű rövidből összetétellel jelszavakat. • Tegyünk róla komplexitás vizsgálattal, hogy a jelszavak kellően összetettek legyenek.

13. Útmutató a jelszavak biztonságossá tételéhez • Változtassuk meg az alapbeállítású felhasználók alapértelmezett jelszavait. • Az adminisztratív felhasználóknak (SYS, SYSTEM, SYSMAN, DBSNMP) adjunk meg erős és különböző jelszavakat. • Engedélyezzünk alapvető jelszókezelési szabályokat. • Ne tároljuk olvashatóan a felhasználók jelszavait, azaz kódoljuk az azokat tároló oszlopokat.

14. Útmutató az adatok biztonságossá tételéhez • Védjük az adatszótárt • Az ANY rendszerjoggal rendelkező felhasználóktól az initsid.ora fájlban a 07_DICTIONARY_ACCESSIBILITY init paraméter hamisra állításával • Korlátozzuk az operációs rendszer elérési engedélyét. • A DB host gépén kevés felhasználó legyen, kevés jogosultsággal. • Az Oracle DB telepítési könyvtárát, vagy a DB által használt könyvtárakat senki ne tudja módosítani.

15. Útmutató az adatok biztonságossá tételéhez • Kódoljuk az érzékeny adatbázis adatokat és a backup fájlokat, melyek ilyen adatokat tartalmaznak.

16. Útmutató a biztonságos DB telepítéshez • Csak azt telepítsük ami szükséges • Használjuk az egyéni telepítést, hogy ne kelljen karbantartani a nem használt plusz eszközöket. • Ne telepítsük a mintapéldákat, vagy töröljük, esetleg zároljuk azokat éles környezetben. • Telepítés alatt mikor jelszót kell megadni, biztonságos jelszót válasszunk. • Telepítés után azonnal zároljuk az alapbeállításban létrehozott felhasználókat.

17. Útmutató a hálózat biztonságossá tételéhez • Tegyük biztonságossá a felhasználói bejelentkezést • A felhasználót szigorúan autentikáljuk, azaz ne bízzunk a távoli osautentikációjában. • A bejelentkezés történjen kódoltan. • Tegyük biztonságossá a hálózati kapcsolatot • Használjunk SSL-t • Az Enterprise Manager DatabaseControl segítségével nyomon követhetjük az figyelőben létrejött biztonsági riasztásokat.

18. Útmutató a hálózat biztonságossá tételéhez • Előzzük meg az online adminisztráció lehetőségét a figyelő jelszavának és a listener.ora fájl írási jogának megvonásával a szerveren. • Ha a figyelő jelszavát nem állítjuk be a listener.ora fájlban, akkor távoli figyelő adminisztrációra nem lesz lehetőség, és elkerülhető a bruteforce betörési lehetőség. • Több IP-vel rendelkező hostgépen a figyelőnek csak egy IP címen való kliensfogadási lehetőséget engedélyezzünk.

19. Útmutató a hálózat biztonságossá tételéhez • Korlátozzuk a figyelő jogait, hogy ne írhasson vagy olvashasson az adatbázisból, vagy az Oracle szerver címtárából. • Használjunk tűzfalat • Előzzünk meg engedély nélkül végzett adminisztrációkat a figyelőn. • Ellenőrizzük az IP címeket, amiben az Oracle Net eszköz segíthet. • Kódoljuk a hálózaton áthaladó adatokat. • Tegyük biztonságossá a hostoló operációs rendszert az összes szükségtelen szolgáltatás leállításával. (FTP, TFTP, TELNET, stb.)

20. Útmutató a hálózat biztonságossá tételéhez • Az SSL beállítása. (Az internet szabványos protokollja a biztonságos kommunikációhoz.) • Bizonyosodjunk meg róla hogy a konfigurációs fájlok a megfelelő SSL portot tartalmazzák. • Alapból a 443, de az URL-ben átdefiniálható. • A tnsnames.ora fájlban ellenőrizzük, hogy az ADRESS paraméterben TCPS van feltüntetve PROTOCOL-ként. • Biztosítsuk, hogy a kapcsolat mindkét oldala ugyanazon SSL módot használja.

21. Útmutató a hálózat biztonságossá tételéhez • Biztosítsuk, hogy a szerver támogassa a használatos kliens cipher, valamint az azonosító kulcsot kódoló algoritmusokat. • Engedélyezzük a DN összehasonlítást mindkét oldalon, a „személy”azonosság meghamísításának elkerülése miatt. • Az RSA privát kulcsunkat kódolt formában tároljuk a server.key fájlban

22. Útmutató az auditáláshoz • Érzékeny információk auditálása • Az érzékeny adatok (pl. bankkártya szám) feltűnhetnek a finomszemcsézett audit trailben az SQL utasítások szövegein belül. • Az auditálást a AUDIT_TRAIL inicializáló paraméterrel állíthatjuk be, ahol az EXTENDED beállítás esetén engedélyezett az SQL szövegek gyűjtése. • Helyezzük át az audit trailt a SYSTEM táblaterületről a SYSAUX vagy más táblaterületre. • Vagy tiltsuk le az SQL szövegek mentését az audit trailbe.

23. Útmutató az auditáláshoz • Tartsuk az auditálási információkat kezelhető mértékben. Habár nem igényel sok erőforrást, de limitáljuk az auditált események számát és az audit trail méretét. • Mérlegeljük az auditálási okokat. Gondoljuk ki a megfelelő stratégiát. • Auditáljunk minél céltudatosabban, csak a minimális mennyiségű utasítás, felhasználó vagy objektum vizsgálatával. • A választott auditálási stratégia megvalósítása előtt konzultáljunk a jogi osztállyal is az apróbb kellemetlenségek elkerülése végett .

24. Útmutató az auditáláshoz • Mindennapi DB aktivitás auditálása • Csak lényeges eseményeket auditáljunk • Minimum a felhasználói bejelentkezéseket, rendszerjogosultságok használatát, és az adatbázis séma változását, ezzel elkerülhető az audit trailben tárolt rekordok zűrzavara. • Archiváljuk és tisztítsuk az audit trailt • Vegyük figyelembe a cégünk titoktartási szempontjait. • Az Oracle DB log fájljaiban is találhatunk további auditálásnál felhasználható információkat.

25. Útmutató az auditáláshoz • Gyanús tevékenységek auditálása • Először általánosságban auditáljunk, majd célratörően • Auditáljunk általánosan gyanús tevékenységeket • Ritka órákban belépő felhasználókat • Többszöri sikertelen belépési kísérletet • Nem létező felhasználó belépési kísérletét • Figyeljük a fiókjukat megosztó felhasználókat, vagy egy IP-ről belépő több felhasználót. • Védjük az audit trailt, hogy ne lehessen hozzáadni, törölni vagy módosítani benne semmit.

26. Útmutató az auditáláshoz • Ajánlott auditálási beállítások adatbázis séma vagy struktúra változásokhoz • AUDIT ALTER ANY PROCEDURE BY ACCESS; • AUDIT ALTER ANY TABLE BY ACCESS; • AUDIT ALTER DATABASE BY ACCESS; • AUDIT ALTER SYSTEM BY ACCESS; • AUDIT CREATE ANY JOB BY ACCESS; • AUDIT CREATE ANY LIBRARY BY ACCESS; • AUDIT CREATE ANY PROCEDURE BY ACCESS; • AUDIT CREATE ANY TABLE BY ACCESS; • AUDIT CREATE EXTERNAL JOB BY ACCESS; • AUDIT DROP ANY PROCEDURE BY ACCESS; • AUDIT DROP ANY TABLE BY ACCESS;

27. Útmutató az auditáláshoz • Ajánlott auditálási beállítások az adatbázis elérésekhez és jogosultságokhoz • AUDIT ALTER PROFILE BY ACCESS; • AUDIT ALTER USER BY ACCESS; • AUDIT AUDIT SYSTEM BY ACCESS; • AUDIT CREATE PUBLIC DATABASE LINK BY ACCESS; • AUDIT CREATE SESSION BY ACCESS; • AUDIT CREATE USER BY ACCESS; • AUDIT DROP PROFILE BY ACCESS; • AUDIT DROP USER BY ACCESS; • AUDIT EXEMPT ACCESS POLICY BY ACCESS; • AUDIT GRANT ANY OBJECT PRIVILEGE BY ACCESS; • AUDIT GRANT ANY PRIVILEGE BY ACCESS; • AUDIT GRANT ANY ROLE BY ACCESS; • AUDIT ROLE BY ACCESS;

28. A CONNECT szerepkör módosulása • A CONNECT szerepkör még a 7. verzióban jött be, és a példakódok, alkalmazások, dokumentációk és a technikai írások is használták. • A 10.2.-es verziótól kezdődően viszont ez a szerepkör jelentősen megváltozott. • Eredetileg a következő jogosultságokat tartalmazta: • ALTER SESSION, CREATE SESSION, CREATE CLUSTER, CREATE SYNONYM, CREATE DATABASE LINK, CREATE TABLE, CREATE SEQUENCE, CREATE VIEW • Az új verzióban viszont már csak a CREATE SESSION jogot tartalmazza.

29. VÉGE Köszönöm a figyelmet!