Dotkom
A Megbízható Számítástechnika megvalósulása a Microsoftnál
Több mint két éve írtunk először a Microsoft Trustworthy Computing kezdeményezéséről. Azóta az elképzelés megvalósulni látszik. A részletekről interjúnkban Dénes Gábort, a Microsoft Magyarország megoldás értékesítési tanácsadóját kérdeztük.
Bill Gates, a Microsoft alapítója még 2002 elején jelentette be, hogy a jövőben más irányra koncentrálják erőiket. Célként a biztonság és a magánszféra védelmének erősítését jelölte meg. A kezdeményezés Trustworthy Computing nevet kapta és Gates szerint a cégnél a legnagyobb prioritást élvezi a munkafolyamatok között. Akkor az utóbbi időkben felmerült biztonsági problémák miatt jutott erre a döntésre a Microsoft vezetése.
A beszélgetésre a Microsoft Üzleti Megoldások Konferencia 2004-es rendezvényen került sor. A tavaly áprilisban hagyományteremtő céllal megrendezett nagy sikerű konferencia folytatásaként idén már másodjára lezajlott konferencián a Microsoft Magyarország elsősorban a közép-és nagyvállalatok vezetőinek kívánta bemutatni azokat az iparági trendeket, melyek napjaink vállalati információtechnológiai alkalmazásaira hatnak.
Terminal.hu – Melyek a Microsoft Megbízható Számítástechnika nevű biztonsági törekvéseinek megvalósítási fázisai egy termékre vetítve?
Dénes Gábor – Megbízható Számítástechnika kezdeményezésünknek 3 kulcsmondata van: 1. Secured by Design, 2. Secured by Default, 3. Secured by Deployment.
A Secured by Design azt jelenti, hogy maga a kód, ami kikerül, ami alapján a termék előáll, biztonságosabb, mint korábban. Ez például a Windows Server 2003 fejlesztésére levetítve azt jelenti, hogy a termék valamikor 2002 év vége felé kellett volna, hogy megjelenjen, de bejelentettük, hogy nagyjából fél évet csúszni fog. Az összes fejlesztő elment egy három hónapos tanfolyamra, ami arról szólt, hogy hogyan lehet biztonságos kódot készíteni. Ez a feltörésre, memóriakezelésre és adatszegmens-kezelésre vonatkozott. Ezek után mindenki visszament, átnézte a korábbi kódjait, és amelyikről azt gondolta, hogy biztonságos, azt digitálisan aláírta, hogy lehessen látni, valójában ki készítette és ellenőrizte a rendszert. Majd bekerült a közös nagy kódkészletbe, amiből naponta előállnak a ˝daily build˝-ek, és amiből végül a termék összeáll.
Ezt követően, a termék elkészülte után jön a Secured by Default fázis, ami azt jelenti, hogy miután a felhasználó a terméket telepíti, minden szolgáltatás le van tiltva a szerveren, és ezeknek nem is települ fel a kódja. Amikor egy-egy funkciót beélesítünk, azután telepítődik az adott rész. A telepítés történhet egy jól ismert „varázsló” segítségével is, ami végigvezet lépésről-lépésre, hogy hogyan kell a szolgáltatást beélesíteni és a telepítésnek milyen kockázatai lehetnek. Ez az eljárás ellentétben áll a korábbi verziókkal, például a Windows 2000 Serverrel, ami szintén elég biztonságos volt, de mivel sok olyan szolgáltatást futtatott ˝feleslegesen˝, amiket az adott szerveren nem használtak ki, így ezekre nem is fordítottak kiemelten figyelmet, ezért támadási felületet adott.
A Secured by Deployment az előzőeknek a vállalatra való kiterjesztése, melynek segítségével nagyvállalati szinten fizikailag is elkülöníthetőek a különböző szolgáltatások, amivel a cég saját biztonsági szabályzatainak megfelelő szinten biztonságos infrastruktúrát lehet megvalósítani.
Terminal.hu – A Windows Server 2003 terjedési sebességére mennyiben van ez hatással?
Dénes Gábor – A Windows Server 2003 nagyobb arányban terjed, mint ahogy az a Windows 2000 Servernek a piaci bevezetés utáni hasonló időszakában történt. Véleményem szerint ez nagymértékben köszönhető annak a ténynek, hogy a frissen kijött kijövő kód már lényegesen jobb minőségű és kiadása pillanatában is biztonságosabb mint elődje volt.
Terminal.hu – Ha a Windows Server 2003 átesett a Secured by Design fázison, akkor mégis miért kell a legtöbb, a Windows XP-ben vagy korábbi termékekben lévő hibát ebben is kijavítani?
Dénes Gábor – Nagyon sok közös kód van, tehát az összes rendszerünkben például a különböző szintű adatkommunikációs rétegek (TCP/IP-kezelő protokollok, authentikációs kódok) mind-mind egyszer ki lettek fejlesztve, és ha jónak bizonyultak, ezeket újra és újra felhasználjuk. Így nagyon sok közös kód van az Internet Explorerekben is. Értelemszerűen adódik ebből, hogy ha valahol hibát találunk, akkor minden korábbi verziónál ezt javítani kell. Csak az újonnan fejlesztett kódok estek át a Secured by Design fázison, a régebbi kódoknál pedig folyamatos az ellenőrzés. Ehhez az ellenőrzéshez, a biztonsági és minőségi szint fenntartásának érdekében ugyanazokat az eszközöket és technológiákat használjuk mint az újonnan történő fejlesztettekhez.
Terminal.hu – Rendszerint mennyi idő telik el egy biztonsági probléma felfedezése és az azt kihasználó ártó kód elterjedése között?
Dénes Gábor – Ez az idő folyamatosan rövidül, ami nem jó hír. A több mint két éve felbukkant Nimda esetében még 330 nap telt el a hiba bejelentésétől a rosszindulatú kód megjelenéséig, míg ugyanez tavaly a Blaster esetében már csak 25 nap volt. Ez egy folyamatosan csökkenő tendencia, és épp ezért nem tartható az álláspont, ami régebben volt, hogy félévente kijött egy új service pack, és az összes ismert hibát javította. Ez az idő már nem a régebbi időtartományban mozog, ezért is van szükség a Windows Update Services és Software Update Services, vagy SMS (System Management Server) alapú javítás-megvalósításra, amelyek kontrollálják, hogy a javítócsomagok eljussanak a munkaállomásokra, illetve a szerverekre, megpróbálva ezzel is egyre jobban kizárni az emberi tényezőt. Ha ugyanis egy ezer fős nagyvállalatnál egyetlen gép nincs frissítve, előfordulhat, hogy azon keresztül hozzáférve a címtár adataihoz, innen mennek ki vírusos levelek a cég nevében, ami elég nagy presztízsveszteség a cégnek, és a hírtelen megnövekedő terhelés miatt közvetlen költség vonzata (például szolgáltatás-kimaradás) is lehet.
Ha fellátogatunk a Microsoft.com oldalra, akkor lehet látni hogy szinte minden oldalon az első banner, ami azt hirdeti, hogy a felhasználó hogyan teheti biztonságosabbá a gépét. Ennek 3 pillére van: 1. használjunk tűzfalat (egyedi felhasználóknak is van beépített tűzfal a Windows XP-ben), 2. legyünk naprakészek a szoftverfrissítésekkel, 3. használjunk vírusellenőrző programot. A 3. rész nem a Microsoft feladata, mi nem készítünk vírusirtó alkalmazásokat és nem is célunk, hanem az alappillért adjuk meg az összes alkalmazáshoz, és próbáljuk ezeken keresztül a támadások veszélyét kizárni.
Terminal.hu – Általában hogyan derül fény a biztonsági problémákra és mi egy átlagos támadás ˝menetrendje˝ a rablók és a pandúrok, illetve a tulajdonos-fejlesztő Microsoft oldaláról?
Dénes Gábor – Nem volt még arra példa a Microsoft történetében, hogy külső forrásból fedezték volna fel a hibát. Miután kijön egy termék, onnantól kezdve egy külső auditor cég, aki a Microsoftnak dolgozik, folyamatosan ellenőrzi visszamenőleg az összes kódot. Ha ők találnak valami rést, azonnal értesítik a Microsoft megfelelő részlegét. Ott megnézik, hogy hogyan lehetne ezt a sérülékenységet kijavítani, kifejlesztik a javító kódot, és amikor publikálják a javítást, publikálják mellé azt az információt is, hogy ez milyen hibát hárított el. Innentől elindul egy versenyfutás az idővel, egyrészt a végfelhasználóknak, hogy telepítsék a javítást, másrészt a hackereknek, hogy útjára indítsák a rosszindulatú kódot. Általában elsőként a kódfeltörők lépnek és először ők teszik közzé a visszafejtett javítást, ami megmutatja, hogy a javítókód mit és hogyan javított, és hogy ezáltal mi vált támadhatóvá. Erre egy másik hackerréteg rá szokott ugrani, és nagyon egyszerű módszerekkel megpróbálják kihasználni a sebezhetőséget.
[fbcomments url="https://www.technokrata.hu/egazdasag/dotkom/2004/03/29/a-megbizhato-szamitastechnika-megvalosulasa-a-microsoftnal/" width="800" count="off" num="3" countmsg=""]





