VÉDELMI ELEKTRONIKA, INFORMATIKA ÉS KOMMUNIKÁCIÓ
MÉSZÁROS GERGELY
NYÍLT FORRÁSKÓDÚ RENDSZEREK BIZTONSÁGI KÉRDÉSEI SECURITY CONSIDERATIONS OF OPEN SOURCE SOFTWARES A nyílt forráskódú rendszerek üzleti, kormányzati és védelmi szektorban tapasztalható növekvő népszerűségével párhuzamosan egyre fontosabbá válnak az ilyen típusú rendszerekkel kapcsolatos biztonsági vizsgálatok. Több konzorcium és kormányzati támogatású projekt is született a nyílt forrású szoftver kezdeményezések tulajdonságainak felbecslésére. A cikk áttekintést nyújt ezekről a nemzetközi projektekről, valamint bemutat egy általam összeállított lehetséges szempontrendszert, amely felhasználható a nyílt forrású megoldások összehasonlító vizsgálatához. Kulcsszavak: Nyílt forrás, kódminőség, OSS biztonság, szoftver audit.
Parallel with increasing popularity of Open Source System in fields of business, government and even military sector, security considerations of such systems are also becoming increasingly important. Numerous consortium and government funded projects were initialized to develop a methodology to assess free and Open Source software endeavors. In this paper I summarize these international projects, as well as introduce a specific criteria system which can be used in comparison studies of Open Source projects. Keywords: open Source, source-code quality, OSS security, software audit
1. Bevezetés Ma már kevesen kérdőjelezik meg a nyílt forrású rendszerek létjogosultságát az üzleti szférában. A legtöbb szakember egyetért abban, hogy vannak területeket ahol a nyílt forrás jó szolgálatot tehet, hozzátéve, hogy sajnálatos módon hazánkban a kapcsolódó fogalmak valamint a nyílt forrásban rejlő lehetőségek és veszélyek még nem igazán közismertek [1]. A nyílt forrású fejlesztések két jellemző tulajdonsága a magas variációszám és a minőségi paraméterekben tapasztalható igen nagy szórás. Az egyik fontos kérdés, hogy milyen szempontok alapján tudjuk kiválasztani a megfelelő változatot, a másik, hogy az így nyert előnyök ellen63
súlyozzák-e a nyílt forrás használatával együtt járó hátrányokat. Például, elérhető-e a kormányzati és védelmi területen megkövetelt biztonsági szint? Mint ismeretes, a Magyarországon hatályos jogszabályok szerint az egyes közigazgatási szervek nem nyílt forráskódú irodai szoftvereket csak indokolt esetben szerezhetnek be [2]. A jogalkotók véleménye szerint a közigazgatásban — legalábbis az adminisztráció szintjén — úgy tűnik igen a válasz. A magasabb biztonsági szintet követelő alkalmazási területek további vizsgálatot igényelnek. A nyílt forráskód néhány előnyös tulajdonsága kétségtelenül erős motiváló erőt jelent. Ilyen például a függőségmentesség. Az USA befolyásával szemben álló országokat, Oroszországot, Kínát és Iránt érthető okokból foglalkoztatja az átállás [3], ugyanakkor az informatika globalizálódásával és a távol-keleti gazdaság erősödésével a közeljövőben ez a késztetés fordított irányban is könnyen felmerülhet. Napjainkban már találkozhatunk olyan esetekkel, amikor amerikai kormányzati szervek kifejezetten nyílt forráskódot fejlesztő közösségeket kerestek meg, mint tette azt az amerikai NSA1 2011-ben [4]. Azt is látni kell, hogy a mai nyílt forrású kezdeményezések nagy része nem hobbifejlesztés, hanem közismert alapítvány vagy akár több száz tagot számláló konzorcium által támogatott, tekintélyes méretű nemzetközi projekt. Példaként említhetjük a közismert Mozilla, Apache alapítványok fejlesztéseit az Eclipse [5] keretrendszert vagy az újabb keletű OpenStack felhő [6] megoldást. Számos nagyvállalat (Oracle, IBM, Novell stb.) önállóan is támogat több kisebb vagy komolyabb nyílt forráskódú fejlesztést [7]. A szervezettség növekedése és vállalati szféra támogatása megnövelte a nyílt forrású rendszerekbe vetett bizalmat. Nem véletlen tehát, hogy az OSS megfelelőség-vizsgálati módszerei is sokat erősödtek az elmúlt években. Önmagában a forrás nyíltsága valójában nem jelent túl sokat. Az egyébként nyílt kód lehet rossz minőségű, hiányosan dokumentált vagy akár szándékosan összezavart (obfuscated). Egyáltalán nem mindegy milyen módszerekkel és milyen közösség fejleszti az adott rendszert. Linus Torvalds híres mondása2 sem állja meg a helyét, ha a kódot átnéző szemek mögött nincs megfelelő tudás vagy szándék. 1 2
National Security Agency „Given enough eyeballs, all bugs are shallow.” – Linus Torvalds
64
VÉDELMI ELEKTRONIKA, INFORMATIKA ÉS KOMMUNIKÁCIÓ
Cikkünkben a népszerű, komoly fejlesztőtáborral rendelkező, angol szakirodalomban FLOSS3 megnevezéssel jelölt „szabad” nyílt forráskódú kezdeményezésekre koncentrálunk és megpróbáljuk feltárni, hogy a közismert szempontokon túl milyen érvek szólnak a nyílt forráskód alkalmazása mellett és ellen, különös tekintettel a szoftverbiztonság területére.
2. Hol találkozunk nyílt forrással? Nyílt forrás kapcsán a legtöbb embernek a Linux kernel alapú operációs rendszerek jutnak először eszébe. Holott — bár kétségtelenül az egyik legnagyobb OS4 kezdeményezés — korántsem az egyetlen. Valójában meglehetősen sok rendszer tartalmaz nyílt forrású vagy nyílt forráson alapuló komponenseket. A 60-nál is több különféle OSS licencelési forma [8] között jó néhányat találunk, amely megengedő a zárt forrású rendszerekben történő felhasználást illetően és ezt a lehetőséget gyakran ki is használják. Ennek megfelelően előfordulhat, hogy egy informatikai rendszer anélkül használ fel nyílt forrású kódot, hogy a végfelhasználó erről tudomást szerezne. A nyílt forrású rendszerek egyik legdinamikusabban fejlődő és az üzleti világ legnagyobb támogatását élvező területe a köztes szoftverek és könyvtárak fejlesztése. Az üzleti szoftverek és online szolgáltatások igen gyakran ilyen rendszereken alapulnak. A Hadoop nyílt forrású rendszert felhasználja például többek közt a Yahoo!, EBay, Facebook és az IBM [9] is. Hasonlóképpen szinte minden területen elterjedten használják a Boost C++ programkönyvtár sablonjait is; olyan ismert programokban találkozhatunk vele, mint az Adobe Photoshop CS2, McAfeee VirusScan, SAP NetWeaver [10]. Azért, hogy az olvasó képet kaphasson arról, milyen széles skálán mozognak az OSS fejlesztések, az alábbiakban felsorolunk néhány jellemző felhasználási területet, valamint pár ismertebb nyílt forráskódú példát a teljesség igénye nélkül: • alkalmazás szoftverek (gimp, libreoffice, inkscape stb.); • szerverszoftverek (squid, apache2, postfix, mysql, asterisk stb.); • operációs rendszerek (Linux, FreeBSD, Haiku, Hurd stb.); 3 4
Free Libre Open Source Software Open Source, Nyílt forrás
65
• rendszer elemző- segédprogramok (nmap, wireshark, amanda stb.); • fejlesztőeszközök (gcc, Code::Blocks, NetBeans, Glade, Eclipse stb.); • webalkalmazások (drupal, wordpress, phpmyadmin, OpenERP stb.); • middleware, engine ( Android, Ogre, JBoss, Sphinx stb.); • programkönyvtárak (jQuery, GTK, Boost C++, Mesa stb.). A végfelhasználó e rendszerek közül elsősorban az alkalmazásokkal, webalkalmazásokkal esetleg az operációs rendszerrel találkozik közvetlenül. Látható, hogy jó néhány olyan terület létezik, amellyel közvetlen módon nem kerülünk kapcsolatba, így az ott alkalmazott megoldások nyílt forrású jellege rejtve maradhat előttünk. A szerző véleménye szerint éppen ezek a területek, ahol a nyílt forráskódú rendszerek részesedése és fejlődése a legerősebb. Úgy vélem különösen fontos, hogy a biztonsági vizsgálat és elemzés során ne csak az adott rendszer nyíltságát elemezzük, hanem — amenynyiben lehetséges — vizsgáljuk meg, milyen nyílt forrású komponenseket használ fel. Az alkalmazott programkönyvtár, középréteg vagy akár fejlesztőeszköz minősége alapvetően befolyásolhatja a rendszerbiztonság globális szintjét.
3. Vizsgálati lehetőségek A nyílt forrású rendszerek minősítése esetén egy sor olyan egyedi lehetőséggel találkozunk, amelyek zárt forrás esetében csak ritkán kerülhetnek szóba vagy egyáltalán fel sem merülnek. A közösségi kapcsolattartó és fejlesztőrendszerek elterjedése oda vezetett, hogy szinte minden nagyobb, modern nyílt forráskódú projekt használ valamilyen verziókezelő, hibakövető és automatikus dokumentációs rendszert. Ezekből a rendszerekből kinyerhető információk alapján egyedi, csak a nyílt forrású projektekre jellemző minősítési módszereket alkalmazhatunk. Az igazsághoz hozzá tartozik, hogy a versenyszféra is elterjedten alkalmazza az említett megoldásokat, mindazonáltal kevés a remény rá, hogy az ott tárolt adatok elemzési célra megszerezhetők. A nyílt forrású projekt minőségi mutatói az alábbi adatforrások felhasználásával hozhatók létre: 66
VÉDELMI ELEKTRONIKA, INFORMATIKA ÉS KOMMUNIKÁCIÓ
• Nyílt forrás esetén a forráskód beszerzése nem jelent problémát, a statikus kódanalízis lehetősége tehát mindig adott. Zárt forrás esetén erre legfeljebb NDA5 szerződés keretén belül, vagy egyáltalán nincs lehetőség. • A verziókezelő rendszerekből több évre visszamenően kinyerhetők a projekt módosítási adatai, fejlesztőhöz rendelt, sorokra lebontott forráskód változási listái, gyakran hibajegyekhez rendelt módon. • A hibakövető rendszerek bejegyzéseiből leválogathatók a súlyosság és típus szerint kategorizált problémák, azok javításai, valamint a javításra fordított idő. • A nyílt programozói dokumentáció. Semmilyen algoritmikus módszer nem helyettesítheti a legalább szúrópróbaszerű emberi kódanalízist. A kód érthetőségét két tényező befolyásolja: a kódolási stílus és a dokumentáltság. A legtöbb szabad forrású fejlesztés nyitott, szívesen látnak bárkit, aki hajlandó időt szánni a kód javítására vagy új funkciók implementálására. Bár a magot alkotó fejlesztők többnyire lassabban cserélődnek, apróbb módosításokat nagyon sokan javasolhatnak. Ahhoz, hogy ez megvalósítható legyen, elengedhetetlen a kitűnő minőségű dokumentáció. A szerző tapasztalatai szerint a nyílt forráskódú projektek programozói (tehát nem felhasználói) dokumentáltsága igen jó, felveszi a versenyt az ilyen téren szigorú szabályozást követő nagyvállalati rendszerek dokumentumaival. A nyílt forráskód esetén a szabályozás helyét a józan belátás és kényszerűség veszi át.
4. Kapcsolódó vizsgálati projektek Ahogy a nyílt forráskód szerepe növekedett, egyre erősebb igény jelentkezett az üzleti és kormányzati szféra irányából valamilyen kielégítő minőségvizsgálati módszer létrehozására, amely a korábban említett egyedi tulajdonságokat is képes figyelembe venni. Az első generációs FLOSS elemző projektek a hagyományos vizsgálati módszereket alkalmazták a nyílt forrás egyedi jellemzőihez igazítva 5
Non-Disclosure Agreement, titoktartási kötelezettségvállalás
67
azokat. Ilyen volt az OSMM6 Capgemini, OSMM Navica, az Atos Origin QSOS7 modellje, valamint a nemzetközi konzorcium által támogatott OpenBBR8. [11] 2004-től az Európai Közösség több nyílt forrású szoftverelemzési projektet is elindított. Ezeket a vizsgálatokat — a módosított elvekre utalva — második generációs FLOSS minőségmodelleknek nevezi a szakirodalom. A sort az EDOS9 projekt nyitotta, amely Linux alapú disztribúciók csomagfüggőségének elemzésével foglalkozott [12]. Később, a szintén EC támogatás keretében zajló SQO-OSS10 projekt eredményeképpen született meg az Alitheia Core szoftverminőség vizsgálati platform [13], amely hasznos segítséget nyújthat a nyílt forrású projektekkel kapcsolatos minőségi jellemzők előállítása során. A kutatások következő lépcsőfokát jelentő QualOSS projekt elsősorban módszertani jellegű eredményeket vonultat fel [14]. Az itt bemutatott irányelvek és besorolási módszertan felhasználható üzleti vagy kormányzati auditokhoz, illetve alapul szolgálhat további módszertani kutatásokhoz. Az utolsó logikai lépcsőt a nyílt forrással kapcsolatos adatok gyűjtésére irányuló FLOSSMetrics projekt képviseli [15]. A projekt adatgyűjtésének online eredményeit a Melquiades web felületen keresztül érhetjük el [16]. A kereslet növekedése természetesen az üzleti világban is visszatükröződött és a nyílt forrás auditálására specializálódott tanácsadó vállalkozások komoly fejlődésnek indultak. E folyamat eredményeképpen hozzáférhetővé váltak projektekkel, szervezetekkel kapcsolatos aggregált tematikus metaadatok amelyek szintén segíthetnek a tájékozódásban. Az Ohloh metaadatbázis például cikkünk írása idején több mint félmillió nyílt forrású fejlesztés statisztikáit indexeli [17]. Természetesen az eredmények alapjául szolgáló adatkategóriák és számítási módszertan pontos ismerete nélkül az egyébként könnyen kezelhető ábrák és jellemzők felhasználhatósága korlátozott. Gyorsan és egyszerűen becsülhető viszont a kérdéses projekt aktivitása, fejlesztésének tendenciái. 6
Open Source Maturity Modell Qualification and Selection of Open Source software 8 Business Readiness Rating for Open Source 9 Environment for the development and distribution of open source software 10 Source Quality Observatory for Open Source Software 7
68
VÉDELMI ELEKTRONIKA, INFORMATIKA ÉS KOMMUNIKÁCIÓ
5. Biztonságot módosító SAJÁTOS tényezők A korábban bemutatott projektek elsődleges célkitűzése az üzleti szempontokat szem előtt tartó minősítési rendszer kialakítása volt. Ennek megfelelően a vizsgálat szempontrendszerében helyet kapott a karbantarthatóság, rugalmasság, tesztelhetőség, hordozhatóság, újrafelhasználhatóság és interoperabilitás, valamint a hatékonyság és használhatóság is. A szoftverminőség ezen területei ugyan nem tartoznak szorosan a szoftverbiztonság kérdésköréhez, az említett projektek metodikájának tanulmányozása mégis feltétlenül hasznos, hiszen egyrészt maga a biztonság is egy a minőségi jellemzők közül, másrészt több más kontextusban vizsgált jellemző közvetve vagy közvetlenül kihat a szoftverbiztonságra is. Felmerülhet a kérdés, vannak-e olyan, kifejezetten a biztonságot befolyásoló tényezők, amelyek eltérő jellegzetességeket mutatnak a nyílt és zárt forrású rendszerek esetében. A forrás megtekintési lehetősége, az abban rejlő hibák felhasználhatósága kétségkívül ilyen, gyakran hangoztatott szempont. A teljes kép azonban ennél jóval árnyaltabb. Az alábbiakban néhány – talán kevésbé nyilvánvaló – biztonsággal kapcsolatos területre szeretnénk felhívni a figyelmet, ahol a nyílt forrású rendszereket sajátos szempontok szerint kell, illetve érdemes értékelni: 1. Frissítések nyíltak és sűrűségük rendszerint nagyobb. 2. Fejlesztői közösség megismerhető. 3. Nyílt forrás terjedésének van egyfajta önerősítő hatása: az azokat felhasználó üzleti, vagy akár zárt forrású fejlesztésekből javítások, fejlesztések vezetődnek vissza az alaprendszer forrásába. 4. Eltérő javítási, reagálási idő. 5. Bizalmas rendszerinformációk kiadása nélkül, saját hatáskörben is elvégezhető egy esetleges integráció. A szerző véleménye szerint e szempontokat feltétlenül érdemes figyelembe venni a nyílt forrású rendszerek biztonsági vizsgálatával foglalkozó tanulmányok készítése során, ezért a továbbiakban részletesen is bemutatjuk őket. 5.1 Frissítések nyíltsága és sűrűsége A YouGov 2012-es felmérése szerint a felhasználók 40%-a nem frissít amikor a rendszer felkínálja, egynegyedük pedig azzal sincs teljes mér69
tékben tisztában, hogy egyáltalán mire valók a frissítések. A támadások igen nagy, 99% feletti része a biztonsági frissítésekkel el nem látott, elavult szoftverek ellen irányul [18]. Ez tehát, talán — megfelelő frissítési szabályozás nélkül mindenképpen — a legsúlyosabb veszélyforrás. A biztonsági rések valóságos aranybányája a biztonsági frissítések változáslistáit tároló verziókezelő adatbázisok. Mivel ezek nyílt forráskód esetén természetesen nyíltan hozzáférhetők, a javításokból könnyen visszakövetkeztethető maga a sérülékenység is. Nyilvánvaló módon a zárt forrású rendszerek sem immúnisak az ilyen típusú támadásokra, de a hiányosság felderítése nagyságrendekkel nehezebb. A biztonsági hiányosság részleteit általában a javítás megszületése után sem hozzák nyilvánosságra, így annak tényleges kihasználási módjára csak következtetni lehet. Ennek bizonyos negatív irányba mutató hatásai is jelentkeznek, ugyanis épp a fent említett indokok miatt, sok cég nem érzi olyan sürgetőnek a biztonsági hiányosság befoltozását. Általánosan jellemző trend, hogy a nyílt forráskódú projektek biztonsági javításai lényegesen hamarabb készülnek el. [19] A fentiek alapján látható, hogy nyílt forráskódú rendszer használata esetén különös figyelmet kell fordítani a naprakész frissítés-követésre. 5.2 Fejlesztői közösség Tekintve, hogy napjainkban a kódot még főként emberek írják, semmiképpen sem kerülhető meg az emberi tényező kérdése. Biztonsági problémákat okozhat a technikai felkészületlenség, hanyagság, valamint a szándékosság. A nyílt forráskódhoz ugyan elméletben bárki hozzáférhet, szerencsére ez koránt sem nem jelenti azt, hogy a „hivatalos” verzióba bárki írhat is. A szabad forrású projektek fejlesztőgárdája lehet relatíve kicsiny (Apache HTTP szerver, alig több mint tucatnyi hozzájáruló) vagy egészen hatalmas (Gnome, több mint 5000 hozzájáruló). A fejlesztők profilozása, ellenőrzése a földrajzi távolság és információhiány miatt eleve nehézségekbe ütközik, több ezer fejlesztő esetén pedig praktikusan megoldhatatlan. A magas biztonsági besorolású üzleti és kormányzati területeken szokásos átvilágítás tehát jellemzően nem kivitelezhető. Biztonsági szempontból kulcskérdés az adott projekt kódelfogadási módszerének ismerete. A tényleges verziókiadásokat soha nem a teljes 70
VÉDELMI ELEKTRONIKA, INFORMATIKA ÉS KOMMUNIKÁCIÓ
fejlesztőgárda, hanem jóval szűkebb csoport végzi. A szervezet felépítését Eric S. Raymond népszerű hasonlatával élve katedrális vagy bazár jellegű fejlesztéseknek szokás nevezni [20] attól függően, hogy a kommunikáció és ellenőrzési folyamat inkább központosított, hierarchikus vagy önszerveződő, megoszló. Szoftverbiztonsági szempontból a döntő kérdés, hogy fejlesztőközösség, illetve annak kiadásokat végző csoportja milyen módszereket alkalmaz — ha egyáltalán alkalmaz — a hibás, rosszindulatú vagy rossz minőségű kód kiszűrésére. Felmerülhet a kérdés, hogy kik, milyen háttérrel, motivációval fejlesztenek egyáltalán nyílt forrású rendszert? Amerikai és európai felmérések alapján többségük 40 év alatti elsősorban férfi, magasan képzett szakember. Motivációjuk sokféle; lehet meggyőződésből fakadó, tudásuk csiszolása és szinten tartása végett végzett gyakorlás, valamint hobbi, kedvtelés [8]. Ugyanakkor, talán meglepő módon, viszonylag alacsony arányú a diákok és munkanélküli fejlesztők részvétele [14]. A legtöbb esetben tehát nem műkedvelő amatőrökről, hanem tapasztalt szakemberekről van szó. A szerző saját megítélése szerint a hobbi jellegű, kedvtelésből végzett fejlesztőtevékenységnek lehetnek kifejezetten előnyös hatásai is. Nyilvánvaló, hogy kedvtelésből végzett munka esetén a közvetlen számonkérés lehetősége nem játszik jelentős motiváló szerepet, ugyanakkor a tökéletesre való törekvés, a mestermű készítésének igénye sokkal hangsúlyosabban van jelen, mint az üzleti fejlesztések esetében, ahol az adott fejlesztő sokszor nem azzal foglalkozik, ami ténylegesen érdekli ráadásul szűk határidőket kell tartania. A fejlesztőgárda átlagos technikai felkészültségéről képet kaphatunk a forráskód átvizsgálásával (kódminőség, műszaki megoldások, dokumentáció) valamint a változáslisták elemzésével. Kis létszámú fejlesztőcsapat esetén, a közösségi hálózatokon történő manuális metaadat gyűjtés is célravezető lehet. 5.3 Nyílt forrás terjedésének önerősítő hatása A nyílt forrás terjedésének van bizonyos pozitív visszahatása a kódminőségre és biztonságra. A növekvő érdeklődés piacot teremt. Világszerte, így hazánkban is jó néhány tanácsadó, elemző cég foglalkozik nyílt forrású rendszerekkel üzleti alapon, aminek jótékony hatása van a szoftvermi71
nőségre. A forráskódot ez által a szabad közösség figyelő tekintetén felül a vállalati szférában megszokott szigorú normákat teljesítő elemzési módszerekkel is gyakran bevizsgálják. Példaként megemlítjük a jól ismert RedHat vállalattal időközben egyesült FuseSource tanácsadó céget, amely saját munkája során üzleti elemzőszoftverekkel rendszeresen ellenőrzi a nyílt forráskódú Apache szoftverkomponenseket, majd a javításokat periodikusan visszavezeti az eredeti közösségi rendszerbe [21]. 5.4 Javítási, reagálási idő Bármely összetett rendszer kialakításakor fontos szempont a komponensek továbbfejleszthetősége, karbantarthatósága. A nyílt forráskód kapcsán gyakran hozzák fel komoly előnyként, hogy megfelelő fejlesztői kapacitás birtokában a forrás rendelkezésre állása és módosíthatósága nagy mértékben megkönnyíti az integráció folyamatát, valamint a funkcionális és interoperabilitási tesztek elvégzését [8]. A biztonság kérdését előtérbe helyezve megállapítható, hogy a módosítás lehetősége a rendkívüli helyzetre való reagálás idejét jelentős mértékben csökkentheti. Amennyiben rendelkezünk a rendszert jól ismerő fejlesztőgárdával, a kritikus helyzet elhárításával nem kell a gyártóra (esetünkben közösségre) várakoznunk, a probléma saját hatáskörben néhány óra, vagy akár percek alatt teljesen kiküszöbölhető, összetettebb esetben szeparálható, a kódból a hibás funkció eltávolítható. 5.5 Bizalmas rendszerinformációk védelme Bár a szakemberek táborának véleménye megoszlik a bizonytalanságon alapuló biztonság (security by obscurity) használhatóságát illetően, kétségtelen, hogy sok szervezet él ezzel a lehetőséggel. A nem nyilvános, egyedi rendszerek lelassíthatják, elbizonytalaníthatják a támadót. Új rendszer integrációja vagy javítása során viszont problémákat vetnek fel. Zárt forrású rendszer bevezetése esetén be kell vonni a fejlesztőt és fel kell fedni esetlegesen bizalmas technikai részleteket. Ezzel szemben, nyílt forrású megoldás választása esetén — megfelelő saját fejlesztőkapacitás birtokában — nem jelent gondot a specifikus megoldásaink implementálása, így a minősített információ kiszivárgása kizárható. 72
VÉDELMI ELEKTRONIKA, INFORMATIKA ÉS KOMMUNIKÁCIÓ
6. Összefoglalás Mint azt láthattuk, tulajdonképpen nem is lehet kérdéses, hogy érdemes-e felhasználni nyílt forráson alapuló összetevőket, hiszen igen nagy a valószínűsége, hogy közvetve vagy közvetlenül valamennyien használjuk azokat. Fontos tehát, hogy rendelkezésre álljon nyílt forrású komponensek beazonosításának képessége és fel kell tudni használni a nyílt forráshoz kapcsolódó egyedülálló lehetőségeket a biztonsági auditok során. Komplett nyílt forráskódú rendszer közvetlen felhasználása esetén leghangsúlyosabb kérdés a megfelelő megoldás kiválasztásának módja, valamint az alkalmazott ellenőrzési folyamat, módszertan. Mindkét esetben sokat segíthet a nyílt forrású kezdeményezések minőségi osztályozásával foglalkozó, első és második generációs projektek eredményeinek tanulmányozása. A cikkben a biztonság kérdéskörére koncentrálva bemutattam egy lehetséges szempontrendszert, amely részét képezheti a nyílt forrású szoftverelemek biztonsági auditjának. Rámutattam, hogy érdemes figyelembe venni a bizonyos egyedi szempontokat. A nyílt forrású komponensek esetén különös figyelmet kell fordítani a frissítés-követésre. Tekintve, hogy a fejlesztők képességeinek és motivációinak közvetlen beazonosítása nehéz, elsősorban a szervezet struktúrájára, fejlesztési módszertanának elemzésére érdemes koncentrálni. Az üzleti világ érdeklődésének növekedésével a nyílt forrású projektek a tanácsadó cégek visszacsatolása révén az üzleti világban meghonosodott szoftverminőség javító eljárások pozitív hatását is egyre inkább élvezhetik. A nyíltságból adódó nyilvánvaló biztonsági hátrányokkal szembeállíthatók a különleges helyzetekre való reagálási idő csökkenéséből adódó és rendszerintegráció során tapasztalható egyértelmű előnyök. Tekintve, hogy a nyílt forráskódú rendszerek szerepe várhatóan hazánkban is egyre nő, ezeket a gondolatébresztőnek szánt szempontokat érdemes lehet komolyabb kutatás keretében részletesen is megvizsgálni. Véleményem szerint ezen túlmenően a kormányzati és üzleti szféra számára is haszonnal járhat a nyílt forrással kapcsolatos európai projektek eredményeire támaszkodó, de a magyarországi viszonyokat és követelményeket figyelembevevő honi vizsgálati módszertan és szoftverminőség-mutató adatbázis létrehozása. 73
Végezetül szeretnénk kiemelni, hogy a még a hibátlan és nyílt forrás sem csodaszer. Emlékezzünk Thompson közel három évtizedes híres „törésére” [22] amely megmutatta, hogy a teljes forráskód utolsó karakterig történő tüzetes átnézése sem elegendő ahhoz, hogy teljesen biztonságban érezhessük magunkat.
74
VÉDELMI ELEKTRONIKA, INFORMATIKA ÉS KOMMUNIKÁCIÓ
Felhasznált irodalom [1] D. Szalay: Braun: óvatosan a „vadászgéppel”! [online]. 2011.
[2012-10-20] [2] 1479/2011. (XII. 23.) Korm. határozat az egyes közigazgatási szervek által használt elektronikus dokumentumok formátumáról és a nyílt forráskódú irodai szoftverek használatáról. [3] Evgeny Morozov: A Walled Wide Web for Nervous Autocrats. The Wall Street Journal [online]. [2012-10-18] [4] NSA’s open-source Accumulo software project aims for secure, largescale storage. GCN [online]. [2012-10-30] [5] Explore The Eclipse Membership. eclipse.org [online]. [2012-10-18] [6] Companies Supporting The OpenStack Foundation. www.openstack.org [online]. [201210-20] [7] E-commerce and development report 2003. Geneva: United Nations, 2003. ISBN 92-1-112602-9. [8] Krasznay Cs.: Az open source rendszerek auditja. Open Source 2011 [online]. 2011. [2012-1020] [9] PoweredBy Hadoop. Hadoop Wiki [online]. [2012-10-28] [10] Who’s Using Boost? Boost C++ Libraries [online]. [2012-10-29] [11] K. Haaland, A.K. Groven, N. Regnesentral, R. Glott, A. Tannenberg, A.S. FreeCode: Free/Libre Open Source Quality Models-a comparison between two approaches. 4th FLOS International Workshop on Free/Libre/Open Source Software [online]. 2010.
75
[2012-11-1] [12] Open Source EC Funded Projects: EDOS. Commercial Open Source Software [online]. [2012-10-29] [13] Alitheia Core - A platform for software engineering research. SQO-OSS [online]. [2012-10-20] [14] QualOSS. CETIC [online]. [201210-29] [15] FP6-033982: FLOSSMetrics Final Report [online]. European Comission, 2010. [2012-10-20] [16] Melquiades - data about FLOSS projects. [online]. [2012-10-29] [17] About Ohloh. Ohloh Meta [online]. [201210-29] [18] M. Lennon: Consumers Clueless on Why They Should Update Software, Survey. SecurityWeek [online]. 2012. [2012-10-26] [19] A. Arora, R. Krishnan, R. Telang, Y. Yang: An empirical analysis of vendor response to software vulnerability disclosure. [online]. 2005, [2012-10-31] [20] E.S. Raymond: The Cathedral & the Bazaar. Revised Edition. Sebastopol: O’Reilly Media, 2001. ISBN 978-0-596-00108-7. [21] FuseSource Overview [online]. RedHat. [2012-10-28] [22] K. Thompson: Reflections on Trusting Trust. Communications of the ACM 27. 1984, Vol. 27, no. 8, pp. 761–763. ISSN 0001-0782.
76
