Kovács Tibor Krisztián. 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á.

Az előadások a következő témára: "Kovács Tibor Krisztián. 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á."— Előadás másolata:

1 Kovács Tibor Krisztián

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/se curity/alerts.htm http://www.oracle.com/technology/deploy/se curity/alerts.htm http://metalink.oracle.com  Használjuk a My Oracle Support-ot vagy írjunk a secalert_us@oracle.com e-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álata is: ○ 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 secure application roles-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 os autentiká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 Database Control 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!