About...

Napi betevő adag elírás, elütés és helyesírási hiba egy helyen! Amúgy meg #információbiztonság #webcserkészet néha #élettudomány

bardóczi ákos @post.r

blogavatar

minőségi kontent-egyveleg

RSS

cimketenger

ITsec (36),privacy (17),Facebook (17),social media (11),itsec (11),egyéb (10),social web (9),mobil (8),biztonság (8),OSINT (6),magánszféra (6),tudomány (6),szellemi tulajdon (6),jog (6),Google (5),webcserkészet (5),molbiol (5),szájbarágó (5),felzárkóztató (4),Nobel-díj (4),terrorizmus (4),kriminalisztika (4),big data (4),kultúra (4),email (4),plágium (4),Apple (3),jelszó (3),nyelvtechnológia (3),genetika (3),Android (3),biztonságpolitika (3),pszichológia (3),webkettő (3),reklám (3),élettudomány (3),gépi tanulás (3),CRISPR (3),Onedrive (3),üzenetküldés (3),2015 (3),orvosi-fiziológiai (3),online marketing (3),kriptográfia (3),molekuláris biológia (3),azelsosprint (3),torrent (3),konferencia (3),magatartástudomány (3),hype (3),biztonságtudatosság (3),open source intelligence (3),popszakma (3),levelezés (3),Gmail (3),szabad információáramlás (2),Yoshinori Ohsumi (2),bejutas (2),Hacktivity (2),Reblog Sprint (2),tweak (2),Pécs (2),génterápia (2),DKIM (2),cas9 (2),bűnügy (2),fiziológia (2),hitelesítés (2),TOR (2),kulturális evolúció (2),villámokosság (2),deep web (2),ransomware (2),bűnüldözés (2),DDoS (2),természetes nyelvfeldolgozás (2),arcfelismerés (2),FUD (2),nyílt forrású információszerzés (2),Balabit (2),P2P (2),webkamera (2),Netacademia (2),neuropszichológia (2),Whatsapp (2),SPF (2),2-FA (2),bolyai-díj 2015 (2),molekuláris genetika (2),jövő (2),sudo (2),IDC (2),cyberbullying (2),social engineering (2),malware (2),tartalomszolgáltatás (2),meetup (2),facebook (2),reblog (2),videó (2),titkosítás (2),kutatás (2),epic fail (2),pedofília (2),netkultúra (2),nyelvtudomány (2),vírus (2),hírszerzés (2),iOS (2),farmakológia (2),sajtó (2),tanulás (2),biológia (2),szociálpszichológia (2),gépház (2),bulvár (2),bug (2),Tinder (2),öröklődő betegség (2),Yandex (2),könyv (2),beszélgetés rögzítése (2),pszeudo-poszt (2),Twitter (2)

Viselkedésalapú azonosításé a jövő?


UBA Balabit user behavior analysis authentikáció ITsec felhasználói magatartás viselkedésmintázat magatartástudomány Blindspotter IDC threat intelligenceIgazán kényes helyeken az erős jelszavak és a szigorú jelszópolitika már nem elegendő. Mi több, a többlépcsős hitelesítés is kijátszható, ahogy arról korábban már dobtam is egy posztot.  

Ha még az sem szavatolja a biztonságos beléptetést, hogy a felhasználónak a felhasználói neve és a jelszava mellett még egy egyszer használatos, például SMS-ben érkező vagy mobilalkalmazás által generált tokent is meg kell adnia, akkor mégis mi? Avagy mi az, ami szinte száz százalékosan azonosít egy-egy felhasználót? Igen, a viselkedése, amit a gép fel is ismer. Na de nem szaladnék annyira előre.

Nemrég több nagy iparági óriás is ismertette azokat a trendeket és friss kutatási eredményeket, amikből egészen dermesztő adatok derülnek ki, már ami az információvédelmet egészében illeti.

Az IDC egyik legújabb felmérése szerint a szervezetek többsége még mindig nem méri semmilyen módon azt, hogy az az összeg, amit információbiztonságra fordítanak, mennyire is hatékony. Míg nagyon sok esetben csak a hatósági feltételeknek kell megfelelniük, a harmadik legnagyobb csoportba pedig azok tartoznak, akik klasszikus kockázatbecslést végeznek, amikor kiértékelik egy-egy IT biztonsági incidens bekövetkezésének valószínűségét megszorozva az általa okozott kárral és ezt vetik össze azzal, hogy mennyit is költsenek informatikai biztonságra.

UBA Balabit user behavior analysis authentikáció ITsec felhasználói magatartás viselkedésmintázat magatartástudomány Blindspotter IDC threat intelligence

Olyan szempontból évek óta alig történt változás, hogy a leggyengébb láncszem nagyon sok esetben maga az ember, azaz az incidensek többsége megelőzhető lenne tudatosabb felhasználói viselkedés mellett. Nemrég egy konferencián az IT Services Hungary ismertetett egy, stílusosan Mikulásnapon elvégzett kísérletet, amiben egy auditor Télapónak öltözve ballagott be az ITSH egyik telephelyére nem mellékesen alaposan bekamerázva. Sehol nem állították meg, hogy igazolja a kilétét, szinte mindenki készségesen beengedte, így emberünk alaposan szét tudott nézni az irodákban, márpedig tudjuk, hogy egy hely bejárhatósága a social engineering támadások szempontjából aranybánya. Nem pusztán a helyismeret miatt, jobban belegondolva eléggé rizikós lehet, ha rejtett kamerával simán rögzíthető az, ami a monitorokon vagy esetleg nyomtatva megjelenik. Az öröm nem tartott sokáig, az alkalmazottaknak a Mikulás látogatása után levetítették a teljes felvételt, bemutatva azt, hogy az ál-Mikulás csak azt nem látott, amit nem is akart.

UBA Balabit user behavior analysis authentikáció ITsec felhasználói magatartás viselkedésmintázat magatartástudomány Blindspotter IDC threat intelligence

Márpedig a kifinomult, célzott támadások rendszerint hosszas előzetes információgyűjtéssel kezdődnek a megtámadni kívánt szervezettel kapcsolatban. A Lockheed Martin által csak Cyber Kill Chainnek nevezett ábra magyarra fordított változatát a CheckPoint idei diasorából vettem át, amiből kiderül az is, hogy egy-egy kémprogram telepítése ugyan néhány másodperc, a kémprogramok pedig nem kevés ideig, átlagosan 200 napig lappangnak egy hálózatban anélkül, hogy észlelnék őket, ráadásul ez az idő folyamatosan egyre hosszabbra nyúlik.

UBA Balabit user behavior analysis authentikáció ITsec felhasználói magatartás viselkedésmintázat magatartástudomány Blindspotter IDC threat intelligence

Nem csak azért nyúlik egyre hosszabbra, mert a malware-ek sokszor azért, hogy ne keltsenek feltűnést, nem lépnek azonnal akcióba, hanem azért is, mert az egész folyamat évről évre egyre kifinomultabbá válik. A kémprogramok elleni védekezés egyik bevett módja az, hogy minden kívülről jövő adat, így az esetlegesen rosszindulatú kód is először egy sandbox környezetben fut, azaz egy olyan virtuális gépen, amiben hiába kezdene el működni elvben, nem tenne kárt a valós rendszerben. 3-4 évvel ezelőttre teszem az első olyan kémprogramok megjelenését, amik már kellően rafináltak voltak ahhoz, hogy észleljék azt, ha nem valós, hanem virtualizált környezetben vannak, így ekkor nem tesznek semmit, hogy elkerüljék a feltűnést. Másrészt technikák egész sora jelent meg, amivel sok esetben lehetővé válik a sandbox-kitörés [sandbox evasion]  a vírusok számára.

UBA Balabit user behavior analysis authentikáció ITsec felhasználói magatartás viselkedésmintázat magatartástudomány Blindspotter IDC threat intelligence

Ahogy a poszt elején is írtam, az incidensek bekövetkezése mégis leggyakrabban emberi mulasztás vagy hiba miatt következik be, mi több, rendszerint ezek járnak a legtöbb kárral, így teljesen érthető, hogy a kutatások egy nagyon preferált területe lett éppen ezeknek az emberi hibáknak az időben történő kiszúrása.

Ahogy frappánsabban össze sem lehetett volna foglalni, a múlt a határvonal-alapú biztonság volt, amit többek közt klasszikus tűzfalakkal oldottak meg, manapság a legelterjedtebb az identitás-alapú biztonság, azaz amikor az előzőn túl egyre erősebb és erősebb azonosítási technikákkal látnak el rendszereket, a jövő pedig a viselkedés alapú biztonságé lesz.

Ami a jelent illeti, a többlépcsős azonosítás korában sokan lobbiznak a biometrikus azonosítást használó technikák elterjedése mellett, amit személy szerint én már akkor is egy igencsak fancy, ámde annál blődebb dolognak tartottam, amikor először olvastam róla komolyabban. A biometrikus azonosítással személy szerint az elvi problémát abban látom, hogy nem valami bölcs dolog olyan azonosításra támaszkodni, aminél az azonosításhoz használt információ nem változtatható meg. Többször igazolták már, hogy az okoseszközök ujjlenyomat-azonosítója arcpirító egyszerűséggel megtéveszthető, a retina mintázatát felismerő kamerák működése drága, körülményes és szintén becsapható. Sajnos a biometrikus azonosítás gyengeségei nem csak az emlegetett okoskütyük esetén jellemző, hanem drága és megbízhatónak hitt rendszerek esetén is. Ujjlenyomat? Retina? Írisz? Arc? Vénalefutás? Kéretik elhinni, hogy mindegyik sokkal biztonságosabbnak van kikiáltva, mint amennyire azok.  

A Balabit friss felmérései szerint az információbiztonsági szakértők gyakorlatilag mindegyike egyetért abban, hogy az incidensek egy jelentős része az alkalmazottak gondatlanságára vagy vezethetők vissza, esetleg ők maguk az insider támadók, valamint a gondatlansággal illetve szándékolt támadásokkal okozható kár nyilván annál nagyobb, minél több jogosultsággal rendelkezik az adott alkalmazott.

UBA Balabit user behavior analysis authentikáció ITsec felhasználói magatartás viselkedésmintázat magatartástudomány Blindspotter IDC threat intelligence

Innen eléggé értelemszerű, hogy akiknek a legnagyobb gondossággal kell vigyázni a munkáját illetve a legjobban védeni a hozzáféréseiket a külső támadóktól, a legmagasabb jogosultsági szinttel rendelkező rendszergazdák.

Itt lépett színre úgy igazán a felhasználó viselkedési mintázatának elemzése [balabites terminussal UBA avagy user-behavior analytics], amire természetesen nem csak ők fejlesztettek ki védelmi megoldást, elsősorban kényes adatvagyonnal dolgozó szervezetek számára.

Nézzük legegyszerűbb példaként azt, hogy mi lehet ordítóan feltűnő akkor, ha egy rendszergazda hozzáférését szerzi meg valaki és azzal próbál visszaélni. Ha valaki például adatbázis-adminisztrátorként egy pénzintézeti adatbázisszerverbe hétköznap általában reggel lép be, néha délelőtt vagy délben, a saját ebédidejében nem nagyon, délután ritkábban, éjszaka pedig soha, akkor szinte biztos, hogy ha hajnalban lép be valaki az ő hozzáférését felhasználva, csak támadó lehet.

UBA Balabit user behavior analysis authentikáció ITsec felhasználói magatartás viselkedésmintázat magatartástudomány Blindspotter IDC threat intelligence

Intuitív ezt nem olyan nehéz megállapítani. De hogyan lehet felkészíteni a gépet, egy komplex védelmi szoftverrendszert arra az esetre, ha ilyet tapasztal? Ismétcsak a bűvös gépi tanulás úszik be a képbe: valamilyen hatékony gépi tanuló algoritmus bizonyos idő alatt megtanulja, hogy az adott rendszergazda mikor szokott belépni, ezt tárolja, majd valószínűségi alapon riaszt, ha ettől a megszokottól valami merőben eltérőt észlel. Természetesen nem csak időbeli eloszlás tanítható a rendszernek, hanem szinte minden, ami leírja egy felhasználó géphasználati szokásait. Ha valaki szinte mindig a céges hálózatról lép be, kicsit szokatlan, ha otthonról lép be a céges VPN-en keresztül, az pedig már eléggé kritikus, ha képzeletbeli rendszergazdánknál azt tapasztalható, hogy hajnalban próbál belépni olyan IP-címmel, ami mondjuk egy karibi-térségben vagy Kínában jegyzett IP-tartományhoz tartozik.

UBA terén ez ráadásul csak a jéghegy csúcsa. Nyilván azzal kapcsolatban is lehet tendenciákat megállapítani adott, magas jogosultságú felhasználóval kapcsolatban, hogy milyen alkalmazásokat használ és mikor vagy milyen parancsokat ad ki egy parancssoros környezetben. Egészen pofás viselkedés alapú ujjlenyomat hozható létre ugyancsak gépi tanuláson keresztül arról, hogy a felhasználónak milyen a billentyűzési dinamikája, azaz a billentyűleütések időbeli eloszlása vagy ami legalább ennyire egyedi, hogyan használja az egeret [itt olyanokra kell gondolni, mint az egérmozgás sebessége, gesztúrái, vagy a kattintásdinamika illetve ezek együttesen és ki tudja még, hogy mi]. Scheidler Balázs egy ilyen, adott felhasználóra jellemző egérhasználati mintázat vizualizált képét is bemutatta.

UBA Balabit user behavior analysis authentikáció ITsec felhasználói magatartás viselkedésmintázat magatartástudomány Blindspotter IDC threat intelligence

A teljes védelmi megoldásnak szerves részét képzi, hogy a felhasználókat aszerint, hogy milyen jogosultságaik illetve szerepköreik vannak a cégnél, különböző osztályokba sorolja, azaz a valós-idejű monitorozást az sem zavarja meg, ha több, magas jogosultságú rendszergazdát kell megfigyelni, hiszen köztük is nyilván vannak különbségek többek közt szerepkör szerint, azaz lehet valaki adatbázis adminisztrátor, egy adott virtuális szerver adminisztrátora vagy akár mindenki fölött álló hypervisor admin. Enélkül megoldhatatlan lenne a riasztási szintek skálázhatósága, egyáltalán a riasztási házirend kialakítása.

Az UBA igencsak előremutató, hiszen valakinek a jellemző felhasználói magatartását nem lehet csak úgy meghamisítani, ugyanakkor újabb és újabb kérdéseket vet fel. Tudvalevő, hogy a felhasználói viselkedésből is számos pszichikus nyom nyerhető, konkrétabban olyan jellegzetességek is, amik összefüggésben állnak vagy állhatnak a felhasználó más területen mutatott viselkedésével, ami viszont már nem tartozna másra, ennek megfelelően biztosítani kell, hogy ezek a patternek ne kerülhessenek ki. Hogy világosabb legyen: a Rorschach-tesztnél is a vizsgált személy ábrák láttán adott visszajelzéseiből tudnak pazar leírást adni az illető személyére vonatkozóan, holott a teszt előtt nyilván úgy gondolták volna, hogy a tintapacák értelmezésének első blikkre semmi köze nincs például az illető személyiségvonásaihoz.

Másrészt hosszú út is áll még az UBA előtt, hiszen a gépi tanításon alapuló megoldást fel kell készíteni arra is, hogy egy felhasználó jellegzetes felhasználói viselkedése változhat nyilván akkor, ha más szerepkörbe kerül, ezen kívül ami bennem felmerült, hogy a felhasználói viselkedés finomszerkezetét olyan tényezők is befolyásolhatják, mint különböző gyógyszerek vagy akár élelmiszerek. Ez alatt nem csak arra gondolok, hogy a billentyűzési-egerezési dinamika nyilván más lesz, valamilyen lónyugtató hatása alatt ül a gép elé, esetleg több kávét ivott a kelleténél vagy bepiált, az eltérés elvben akkor is megmutatkozhat, ha valaki alaposan teleeszi magát ebédidőben, majd úgy ül vissza a gép elé. A felhasználói viselkedés mintázata márpedig annál nagyobb „felbontású” lesz, minél több információ gyűlik össze a felhasználóról, az pedig eléggé világos, hogy a fejlesztés iránya az, hogy a felhasználó viselkedésbeli ujjlenyomata legyen minél részletgazdagabb.

Remek kérdés, hogy a felhasználói viselkedés elemzésén alapuló védelem finomhangolásához eléggé gyorsan lehet-e alkalmazni, abba integrálni a magatartástudományi, főként kognitív pszichológiai és neuropszichológiai ismereteket, ahogy történt ez például a nyelvtudomány területén is.

A felhasznált ábrákért köszönet az IDC-nek!

0 Tovább

Adatközpontok és trendek


Az adatközpontokról mindenkinek rácsok mögötti, hűtőszekrény méretű szilíciumszörnyek vagy éppen zsúfolt, kisebb, asztali gépekhez hasonló masinákkal teli tömött polcok jutnak eszébe. Arról már jóval kevesebbet tudunk, hogy az adatközpontok ténylegesen hogyan is működnek és mikben változott az adatközpontok kialakítása az idő folyamán.

2-3 évvel ezelőtt még többen határozottan azt jósolták, hogy a jövő kis- és középvállalati környezetben a mikroszervereké, azaz az olyan szervereké, amik nem sokkal nagyobbak, mint egy asztali gép, csak éppenséggel a rendelkezésre állásuk sokkal nagyobb, emiatt persze egy átlagos asztali géphez képest drágábbak is. A mikroszerverek piaca ha nem is torpant meg, a kezdeti felfutás lelassulni látszik, vélhetően azért, mert ha a szerver többek közt attól szerver, hogy folyamatosan működnie kell, elfogadhatatlan, hogy a 2-3 év garanciális időszak után egy-egy ilyen kis szerver egy hardverhiba miatt leálljon és bizony ha nincs a kkv-nak szerződése valamilyen hosztingszolgáltatóval, amelyiknél egy tartalékszerver át tudná venni a mikroszerver feladatát, akkor az érthetően komoly kellemetlenség, mivel mikroszervert javíttatni nem is olcsó, másrészt veszélyeztetheti az üzletmenet-folytonosságot, akárcsak más leállás.

A megoldások egyike tehát nagyon sok esetben a klasszikus ún. polcos vagy rackszekrényes elhelyezés egy jól védett szerverhotelben, ahol nem kell számolni a porral, hőmérsékletingadozással, ingadozó páratartalommal, elektromágnesesség okozta zajjal vagy éppenséggel az olyan áramszünettől, amit a szünetmentes táp ne tudna áthidalni.
Hiszen a szerverhotelek tipikusan több, egymástól független, nagyteljesítményű betáppal vannak ellátva, nagyteljesítményű szünetmentes tápok gondoskodnak róla, hogy egy-egy áramszünet esetén se maradjanak a vasak áram nélkül, ha pedig még ezek a monstrum méretű szünetmentes tápok sem bírnák szuflával tovább, az szerverhotelek közelében vagy tetején elhelyezett dízelgenerátorokkal biztosítják az áramellátást, ugyan úgy tudom, hogy dízelgenerátorok beindítására Magyarországon még egyszer sem volt szükség a komolyabb adatközpontok esetén.


Dízelgenerátorok a tetőn [Dataplex]

A közelmúltban megtartott IDC Adatközponti Transzformáció Konferencián az adatközponti infrastruktúrákkal foglalkozó és céges ügyfélként jelen lévő részvevők oszthatták meg egymással a tapasztalataikat.

Szinte mindegy, hogy milyen infrastruktúráról van szó, máig a hibrid rendszerek a jellemzőek, azaz klasszikus dedikált szervergépek, nagy számításigényű és magas rendelkezésre állású mainframek  és felhő-alapú megoldások vegyesen.

Ami némileg meglepő lehet, hogy a 64 bites architektúra a nagyszámítógépek piacán csak szép lassan terjed ki, míg az asztali gépeknél és a laptopoknál már természetes, hogy mind 64 bites, ugyan 8-10 évvel ezelőtt a 64 bites architektúrák nem jelentettek a felhasználók számára akkora érezhető változást, mint korábban a 16 bitesről a 32 bitesre történő áttérés.
Ma már a tudatos otthoni felhasználónak sem kell tartania tőle, hogy komolyabb adatvesztést szenved el, ha elszáll a gépe, hiszen jobbnál-jobb cloud storage szogláltatók jelentek meg, amik folyamatosan feltalicskázzák a felhasználói adatokat a felhőbe, aminek tartalmát folyamatosan szinkronizálják a gépen, helyben tárolt
tartalommal.

Kis- és közepes méretű vállalatok szerverei esetén nyilván sokkal kackiásabb a helyzet. Az IDC-n az adatbiztonságra specializálódott Veeam regionális menedzsere egészen elképesztő adatokat osztott meg a hallgatósággal. Kiderült, hogy a felhő-alapú tároló megoldásoknál egy-egy leállás esetén az esetek közel 20%-ában lépnek fel súlyos nehézségek illetve a visszaállításkor. A cloudban alapvetően annyira bízik mindenki, hogy szinte sosem tesztelik. Egy-egy virtuális gép újraindítása egy kkv-nál olyan módon, hogy minden zökkenőmentesen haladhasson tovább, átlagosan négy órát vesz igénybe. Márpedig - ahogy erről többször is írtam ezen a blogon - egy-egy óra downtime társadalmi hatása időről időre egyre nagyobb, az érintett cég számára egyre nagyobb presztízsveszteséget jelent és a kiesésből adódó költségek is egyre nagyobbak.

Állítólag egy, a közelmúltban történt pénzintézeti szerverleállás 880 ezer USD veszteséget jelentett óránként.

IBM AS400 - napjainkig az egyik legelterjedtebb mainframe pénzintézeti környezetben

A Veeam előadásában elhangzott, hogy egy teljes adat- és szolgáltatásvisszaállítás meghibásodás esetén akár kevesebb, mint 15 perc alatt is megoldható. Itt persze nem arra kell gondolni, ami még régen volt IT-üzemeltetési gyakorlat, azaz, hogy - egyszerűsítve - "tükörszerverek" futnak egymással párhuzamosan így biztosítva a redundanciát, nem is úgy kell elképzelni a helyreállítást, mintha egyszerűen csak biztonsági másolatokat kapnának elő, hiszen azok természetükből adódóan nem tartalmaznák a legfrissebb adatokat illetve a kiesett szolgáltatások utolsó ismert állapotát. Valójában ún. replikátumokról, ha úgy tetszik, élő másolatokról van szó.

Egy másik előadásban volt róla szó, hogy a sok, különböző gépből álló szerverpark felügyeletét segítő integrált felügyeleti megoldások egyszerre képesek figyelni az infrastruktúra minden rezdülését és beavatkozni, ha kell. A központi felügyelet pedig nagyon nem mindegy, ha egy több ezer, ráadásul különböző platformon futó, különböző földrajzi helyen lévő gépekről van szó, amiknél nyilván igencsak veszélyes üzem lenne, ha csak külön-külön lehetne menedzselni. Ez utóbbinak az a magyarázata, hogy sokszor a nagygépes vagy több gépből álló rendszerek olyan módon futtatnak párhuzamos folyamatokat vagy éppenséggel biztosítanak virtualizált környezeteket eltérő szolgáltatásokhoz, hogy az IT-s nem is tudja valójában, hogy melyik melyiken fut fizikailag.

A HP előadásában volt róla szó, hogy a big data szép is, jó is, viszont azért, hogy egyre kifinomultabb módszerekkel lehessen hasznát venni, szükségszerűen olyan infrastruktúrára lesz a közeljövőben szükség, amik ma még nem elterjedtek.

Márpedig a jövőben a big datával tudnia kell bánnia minden olyan cégnek, ami meg szeretné tartani a versenyképességét, hiszen a hatékony üzleti tervek kialakításához nyilván jó minél pontosabban tudni, hogy hogyan optimalizálhatóak a belső folyamatok, hogy mit szeretne az ügyfél, arra mennyit hajlandó költeni és ez milyen paraméterekkel áll összefüggésben, amire a big data előtti korban esélyük sem lett volna rájönniük a kutatóknak.

Megjegyzem, ebben a posztban most nem megyek bele, hogy a big data mennyire buzzword vagy sem, na meg abba sem, hogy milyen bizarr módon néz ki, amikor egy aktuális tudományos vagy technológiai paradigmáról irritálóan sokan beszélnek a megrendelői oldalon olyanok, akiknek amúgy lövésük nincs a témáról. Ami viszont tény, hogy igencsak tekintélyes számítási kapacitásra és ehhez igazodó infrastruktúrára szükség lesz, ennek pedig szerintem is egyik flagshipje a HP, ha az igények kiszolgálásáról van szó. Ma ha egy szervezet hatékony szeretne lenni, a meglévő adattárházát az általa megbízott big datával foglalkozó cégnek úgy kell használnia, hogy úgymond minél jobb kérdéseket tudjon feltenni, ennek megfelelően minél részletgazdagabb válaszokat tudjon visszajuttatni a megrendelő szervezethez, ehhez viszont erős infrastruktúra kell.

A DevOps megközelítéssel a Prezi előadása foglalkozott behatóan. Akinek nem lenne ismerős a DevOps, nos, ez az a szemléletmód, ami azt vallja, hogy a szoftverrendszerek fejlesztői legyenek annak üzemeltetői is egyben. Aki nem foglalkozik informatikával, elsőre még így sem biztos, hogy világos, hogy miről van szó, hiszen elvben az informatikus tud szoftvereket fejleszteni, na meg üzemeltetni is, nem? Nos, az egyszerűsített válasz persze az, hogy valóban, viszont nyilván van, aki az idő folyamán a fejlesztésre, tesztelésre megint más pedig az üzemeltetésre specializálódik. Nagyméretű szoftverrendszerek pedig akkor működhetnek a legnagyobb hatékonysággal, rendelkezésre állással és persze leggyorsabban, ha a fejlesztőnek minél inkább pontos képe van arról a környezetről, azaz architektúráról, amire ténylegesen fejleszt valamint az admin-szemléletű informatikus képben van azzal kapcsolatban, hogy a sok-sok különböző technológiát használó szoftverrendszer alá hogyan érdemes beállítani a vasakat vagy éppen a felhőt.

A DevOps igazából kicsiben nem igazán értelmezhető dolog, viszont ha már arról van szó, hogy egy szolgáltatásnak percenként adatbázis lekérdezések milliárdjait kell végrehajtania nyilván megfelelő sebességgel, akkor a szolgáltatás által küldött adatbázis-lekérdezéseket kell optimalizálni ÉS az adatbázisszerveren a célnak leginkább megfelelő adatbáziskezelő motort kell választani, különben a szolgáltatás vagy lassú és megbízhatatlan lesz vagy veszett nagy összegeket kell a cégnek költenie arra, hogy meglegyen a megfelelő erőforrásigény. Az IT-re fordítható pénz pedig nyilván szűk keresztmetszet, azaz többet ésszel, mint erővel.

A klasszikus fejlesztési módszertanról és az agilis fejlesztésről szóló kerekasztal beszélgetésnek megvoltak a maga tanulságai. Megjegyzem, amikor ez kerül szóba valahol, többször tapasztalható, hogy úgy teszünk, mintha egyedül a V-modellel gyakran tévesztett vízesés-modell és az agilis fejlesztési módszertan létezne, holott van még bőven, másrészt gyorsan belátható, hogy az egyik nem váltja fel a másikat időben, hanem tisztában kell lenni azzal, hogy bizony, van, ahol az egyik, van, ahol pedig a másik fejlesztési módszertan hatékony. Ahogy az egész ipar, természetesen maga a fejlesztő is folyamatosan az idő szorításában dolgozik, tény, hogy időt spórolni valahogy a tesztelési folyamatoknál /*veszélyesen rossz*/ szokás. Az olyan módszertanokat követő fejlesztők, amik hallgatólagosan sokkal kisebb hangsúlyt fektetnek a tesztelésre, később komoly árat fizethetnek emiatt.
IMHO persze nincs általános képlet, megfelelő szoftverfejlesztési igényhez a megfelelő módszertant kell kiválasztani, igazán tragikusan például akkor sülhet el a dolog, amikor egy csapat olyan módszertant választ, amit esetleg saját maga talált ki vagy egyszerűen nincs elegendő rendelkezésre álló tapasztalat a hatékonyságával kapcsolatban.


Az IDC-n kiderült, amiről korábban csak pletykák voltak, nevezetesen, hogy a Raiffeisen Bank, kulcs fontosságú rendszerét ért leállást egy IBM AS400-as mainframe egy processzorának elfüstölése okozta, ami rántotta magával a többi hardverelemet. Ismereteim szerint ennyi még bőven kevés ahhoz, hogy egy pénzintézeti rendszer órákra elszálljon, emellett több, konkrétabban meg nem nevezett emberi eredetű hibát is elkövettek a helyreállítás során. Tehát az eset tanulsága ismétcsak az, hogy a leállást kizárni még méregdrága, többszörösen redundáns infrastruktúrával sem lehet biztosan, viszont nagyon nem mindegy, hogy a kiesett rendszer mennyi idő után áll talpra illetve veszi át a szerepét egy tartalék rendszer, ennek a gyakorlata viszont nyilván emberi tényező. Hogy mennyire részletes és szigorú annak a forgatókönyve, hogy különböző kieséseknél milyen protokoll szerint kell eljárni, nagyban függ attól, hogy milyen szektor informatikai rendszeréről van szó, ezzel a ISO/IEC 27000 szabványcsalád foglalkozik behatóan.

Közel teljes rendelkezésre állás létezik. Ez viszont nem csak a technikai kialakítástól, hanem az azt üzemeltető IT-stafftól, mint emberi tényezőtől is függ. Hogy a technikai megvalósítás mennyire is tud redundáns lenni, az IDC egyik előadójának a HP-nak egy ősrégi reklámjával szemléltetném.

0 Tovább