Szükség van a biztonsági Patch-re?

Épp a holnapi Oracle" Security Summit előadásomra készülök, ami az Oracle Database biztonsági megoldásairól lesz egy áttekintés. Jó apropó ez arra, hogy a hetek óta engem foglalkoztató, a témával kapcsolatos kérdésnek utánajárjak. Ez pedig nem más, mint a Security Patch-ek kérdése. A legtöbb magyar cégnél ha egy DBA-val beszélek erről, akkor azzal szembesülök, hogy még csak nem is mérlegelik az úgynevezett CPU (Critical Patch Update) telepítését (tisztelet a kivételnek). Pedig a nevében szereplő kritikus szó önmagában elég aggasztóan hangzana számomra, ha én például egy személyes adatokat vagy nagy értékű üzleti információkat is tartalmazó adatbázist adminisztrálnék.
Kis utánjárást követően meggyőződhettem róla, hogy ez nem csak magyar mentalitásból eredő probléma, a világon másutt is hasonló a többség hozzáállása a kérdéshez. Az IT biztonsággal foglalkozó Sentrigo Inc. cég felmérése szerint 305 IT szakértő (nagy részük DBA) kétharmada állította azt, hogy soha életében nem telepített Oracle Critical Patch Update-et. Hasonló állítást tett közzé az IOUG is a Unisphere Research által készített felmérésben, miszerint a szervezetek többsége bevallotta, hogy soha nem alkalmazott még Oracle CPU-t.
Legtöbbször a DBA-k ezt azzal magyarázzák, hogy túl nagy a kockázata annak, hogy egy jól működő rendszerbe indokolatlanul (?!) beavatkozzanak. Másrészt pedig az adatbázis amúgy is tűzfal mögött van, kívülről nem érhető el. Azt gondolom az első felvetést úgy kell vizsgálni, hogy vajon minek van nagyobb kockázata és nagyobb költsége, egy adatszivárgásból (vagy más biztonsági támadásból) eredő bevételkiesés, esetleg rendszerleállás vagy prezstízs veszteség. Ezzel szemben áll egy megfelelően letesztelt Patch telepítése. Ez utóbbinak alapból nagy költséget tulajdonítunk, hiszen rendkívül időigényes. Azonban a megfelelő eszköz használatával (Real Application Testing, Provisioning and Patch Management Pack) ez időszükséglet és a Patch telepítés kockázata jelentősen csökkenthető, sőt utóbbi akár eliminálható is. Az pedig, hogy az adatbázis tűzfal mögött van csupán egy hamis biztonság érzetet ad. Hallott már valaki arról, hogy a tűzfalak is tele vannak bug-okkal? És az adatbázist elérő alkalmazások hibáiról?
Nagyon tetszett nekem az IT knowledge Exchange oldalon található egyik comment ennél a cikknél, ahol is a Patch-elést ahhoz hasonlítják, amikor valaki TB-t, vagy utazási biztosítást fizet azért, hogy baj esetén legyen hova fordulnia. Pedig optimális esetben nagyon ritkán történik baj, de a kockázata megvan, és sokkal többe kerül, ha nincs biztosítás, és mégis beüt egyszer a
crach. Arról már nem is beszélve, hogy ha valaki a saját személyes adatait megadja egy szolgáltatónak idehaza, azt gondolom elvárja hogy azok megfelelően védett helyen legyenek tárolva. Márpedig a Patch-ek telepítésének hiánya ezt a biztonságot egyszerűen lehetetlenné teszi, például az adatszivárgás kockázatát hordozza magában.
Véleményem szerint egy komoly hiányosság idehaza, hogy az IT biztonsági incidenseket nem kötelező publikálni, ezért az a téves kép alakulhat ki bennünk, hogy ez egy nem létező probléma. Pedig, ha néhány IT biztonsági audittal foglalkozó céget megkérdezünk, tudnak miről mesélni... Végül csupán egy idézet egy auditortól, ugyancsak az imént idézett cikkhez kapcsolódó comment-ek közül: "Every single Oracle instance we have ever tested has been like butter to go through." Idehaza vajon más lenne a helyzet?

Comments:

Épp most találtam bizonyítékot arra, hogy idehaza is vannak akik keresik a biztonsági réseket, még ha az nem minden esetben származik is Patch hiányból, hane, mondjuk konfigurációs hiányosság az oka: http://buhera.blog.hu/2011/01/26/obudai_egyetem Azt hiszem ez is megér egy külön post-ot majd.

Posted by Sárecz Lajos on január 26, 2011 at 07:41 DE CET #

Post a Comment:
  • HTML Syntax: NOT allowed
About


Sárecz Lajos vagyok, 2003 óta dolgozok az Oracle Hungary Kft-nél értékesítési tanácsadóként. Szakterületem az Oracle Engineered Systems, azaz olyan szerverek, amelyek hardver és szoftver komponensek előre optimalizált konfigurációja.
A blogon publikált vélemények a saját nézeteimet tükrözik, nem feltétlenül egyeznek meg az Oracle álláspontjával.
The views expressed on this blog are my own and do not necessarily reflect the views of Oracle.
View Lajos Sárecz's LinkedIn profileView Lajos Sárecz's profile

Search

Archives
« április 2014
HKSzeCsPSzoV
 
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
    
       
Today