RSS

Enterprise Tech Solutions Meetup #6: W chmurach

Liczba odsłon: 260

28 lis­to­pa­da w ka­to­wic­kiej sie­dzi­bie ING Inno­vation Lab od­by­ło się szós­te już spot­ka­nie z cyk­lu Enter­pri­se Tech Solutions Meetup. W tym mie­sią­cu te­ma­tem prze­wod­nim by­ły śro­do­wis­ka chmu­ro­we, a w szcze­gól­noś­ci kwe­stie zwią­za­ne z wy­dzie­le­niem pry­wat­nej chmu­ry, za­bez­pie­cze­niem pub­licz­nej chmu­ry oraz wsa­do­wym prze­twa­rza­niem du­żych iloś­ci in­for­mac­ji w chmu­rze. Poniższy tekst sta­no­wi re­la­cję z te­go wy­da­rze­nia.

Infrastruk­tu­ra ser­we­ro­wa sta­no­wią­ca pod­sta­wę dzia­ła­nia apli­kac­ji prze­szła nie­sa­mo­wi­tą me­ta­mor­fo­zę. Dawno mi­nę­ły już cza­sy, gdy usłu­gi uru­cha­mia­ło się na nie­po­trzeb­nych ni­ko­mu kom­pu­te­rach usta­wia­nych w schow­ku na szczot­ki. Serwery naj­pierw prze­nio­sły się do szaf w wy­dzie­lo­nych, kli­ma­ty­zo­wa­nych po­miesz­cze­niach, póź­niej uleg­ły prze­kształ­ce­niu w ma­szy­ny wir­tu­al­ne ob­słu­gi­wa­ne przez po­je­dyn­cze su­per­kom­pu­te­ry, a na­stęp­nie wy­wę­dro­wa­ły do cen­trów hos­tin­go­wych. Każda trans­for­mac­ja po­zwa­la­ła uru­cha­miać ty­le sa­mo usług za po­mo­cą mniej­szej iloś­ci sprzę­tu zaj­mu­ją­ce­go mniej­szą po­wierz­chnię fir­my.

Najnowszym tren­dem jest prze­no­sze­nie usług w chmu­rę. W naj­prost­szym przy­pad­ku da­lej ope­ru­je się po­ję­ciem ma­szy­ny wir­tu­al­nej, jed­nak nie wia­do­mo już, gdzie ta ma­szy­na jest uru­cho­mio­na. Co wię­cej, do­wol­ne­go dnia mo­że ona zo­stać prze­nie­sio­na set­ki ki­lo­met­rów da­lej, a mi­mo to nie utra­cić ani jed­ne­go po­łą­cze­nia. W bar­dziej skom­pli­ko­wa­nych sce­na­riu­szach moż­na oder­wać się cał­ko­wi­cie od sprzę­tu i uru­cha­miać apli­kac­je na abstrak­cyj­nej pod­sta­wie sys­te­mu i śro­do­wis­ka opera­cyj­ne­go do­star­czo­nych i za­rzą­dza­nych przez do­staw­cę usług chmu­ro­wych.

Przeniesie­nie apli­kac­ji „w chmu­rę” cza­sem jest nie­moż­li­we z po­wo­dów praw­nych. W ta­kim przy­pad­ku moż­na jed­nak sko­rzys­tać z tech­ni­ki pry­wat­nej chmu­ry, w któ­rej wszyst­kie za­so­by po­zos­ta­ją fi­zycz­nie pod kon­tro­lą da­nej in­sty­tu­cji.


Pierwsza pre­zen­tac­ja, po­pro­wa­dzo­na przez Mikołaja Kujawę oraz Rafała Ślęzaka, po­świę­co­na by­ła as­pek­tom tech­nicz­nym uru­cha­mia­nia pry­wat­nej chmu­ry ob­słu­gu­ją­cej apli­kac­je nie­zbęd­ne do funkcjo­no­wa­nia ban­ko­wo­ści ING Bank Śląski. Obecna po­stać in­fra­struk­tu­ry ukształ­to­wa­ła się w la­tach 2013-2014, gdy na­stą­pi­ła mi­grac­ja ze śro­do­wis­ka VMware vSphere w kie­run­ku Micro­soft Hyper-V. Wynikały z niej na­stę­pu­ją­ce ko­rzyś­ci:

Zaobserwo­wa­no też na­stę­pu­ją­ce nie­do­god­noś­ci:

Wprowadze­nie pry­wat­nej chmu­ry to wed­ług pre­le­gen­tów du­żo wię­cej, niż sa­mo stwo­rze­nie in­fra­struk­tu­ry ob­słu­gu­ją­cej ma­szy­ny wir­tu­al­nej. Powinno za tym iść ustan­da­ry­zo­wa­nie ca­łe­go sto­su tech­no­lo­gicz­ne­go:

Decyzją, któ­rą trze­ba pod­jąć na eta­pie bu­do­wa­nia pry­wat­nej chmu­ry, jest roz­miar klast­rów skła­da­ją­cych się na roz­wią­za­nie. Jednym z głów­nych czyn­ni­ków wpły­wa­ją­cych na tę de­cy­zję jest spo­sób li­cen­cjo­no­wa­nia pro­duk­tów uru­cha­mia­nych w ra­mach chmu­ry. Niestety, jest on obec­nie częs­to uza­leż­nio­ny nie od śro­do­wis­ka wir­tu­al­ne­go, w któ­rym pro­gram dzia­ła, lecz od roz­mia­ru i pa­ra­met­rów ca­łe­go ser­we­ra lub klast­ra wir­tu­ali­zac­ji. W ta­kim przy­pad­ku wpro­wa­dze­nie po­dzia­łu na kil­ka mniej­szych klast­rów mo­że zna­czą­co zmniej­szyć kosz­ty li­cen­cyj­ne.

Jako ele­ment kry­tycz­ny, wpły­wa­ją­cy na do­stęp­ność two­rzo­ne­go klast­ra, pre­le­gen­ci wy­mie­ni­li ba­zę da­nych Oracle. Niestandar­do­wym roz­wią­za­niem, ofi­cjal­nie nie­ob­słu­gi­wa­nym przez do­staw­cę lecz po­myśl­nie wdro­żo­nym przez ING, jest po­łą­cze­nie in­stan­cji ba­zy da­nych dzia­ła­ją­cych w dwóch ośrod­kach od­da­lo­nych o 20 km od sie­bie w je­den klas­ter. Osiągnięto w ten spo­sób wy­so­ką do­stęp­ność na po­zio­mie in­fra­struk­tu­ry. Mimo to, po­szcze­gól­nych ser­we­rów ba­zo­da­no­wych nie moż­na wy­łą­czać lub re­star­to­wać bez szko­dy dla apli­kac­ji koń­co­wych. Między in­ny­mi z te­go po­wo­du obec­nym tren­dem jest za­pew­nia­nie wy­so­kiej do­stęp­noś­ci już w sa­mych apli­kac­jach, któ­re po­win­ny być w sta­nie rea­go­wać na utra­tę klu­czo­wych usług w spo­sób przez­ro­czy­sty dla użyt­kow­ni­ka.

W cza­sie pre­zen­tac­ji zo­sta­ły przed­sta­wio­ne do­bre prak­ty­ki, któ­rych po­win­ni trzy­mać się wdro­że­niow­cy pry­wat­nych śro­do­wisk chmu­ro­wych:

Wystąpie­nie za­koń­czy­ło prze­ka­za­nie drob­nych po­rad dla osób reali­zu­ją­cych du­że pro­jek­ty wir­tua­li­za­cyj­ne ty­pu „pry­wat­na chmu­ra” za po­mo­cą Hyper-V, głów­nie do­ty­czą­cych wska­zań, któ­re war­to ob­ser­wo­wać oraz pa­ra­met­rów kon­fi­gu­ra­cyj­nych, na któ­re na­le­ży zwró­cić uwa­gę. Prelegenci po­pro­wa­dzi­li też krót­ką dys­kus­ję z pub­licz­noś­cią.


Drugie wy­stą­pie­nie, po­świę­co­ne bez­pie­czeń­stwu śro­do­wis­ka chmu­ro­we­go, wy­gło­sił Michał Furmankiewicz z fir­my Chmurowisko. Rozpoczął je od okre­śle­nia, co skła­da się na po­czu­cie bez­pie­czeń­stwa i stwier­dze­nia, że jeś­li ktoś nie mo­że za­ufać śro­do­wis­ku chmu­ro­we­mu, to tym bar­dziej nie po­wi­nien ufać włas­nym ser­we­rom, któ­re rów­nież mo­gą za­wie­rać pod­ze­spo­ły szpie­gu­ją­ce. Podkreślił, że w aspek­cie bez­pie­czeń­stwa chmu­ry istot­na jest treść pod­pi­sy­wa­nych umów, któ­re częs­to da­ją do­staw­cy zbyt du­że upraw­nie­nia do prze­ka­zy­wa­nych mu da­nych.

Usługi chmu­ro­we mo­gą być do­star­cza­ne wed­ług róż­nych mo­de­li. W każ­dym ko­lej­nym – IaaS, PaaSSaaS – ob­szar znaj­du­ją­cy się pod kon­tro­lą klienta koń­co­we­go jest co­raz mniej­szy. Prelegent pod­kreś­lił przy tym, że nie jest to wca­le złe, gdyż po­zwa­la skon­so­li­do­wać wy­sił­ki ma­ją­ce na ce­lu zwięk­sze­nie bez­pie­czeń­stwa in­fra­struk­tu­ry. Dostawcy śro­do­wisk chmu­ro­wych nie chcą, a na­wet nie po­win­ni po­zwa­lać klien­tom na ana­li­zo­wa­nie i audy­to­wa­nie in­fra­struk­tu­ry, gdyż mo­że to zmniej­szać po­ziom bez­pie­czeń­stwa.

W przy­pad­ku du­żych śro­do­wisk wir­tu­ali­za­cyj­nych, w tym chmu­ro­wych, nie ma miej­sca na dro­biaz­go­we zaj­mo­wa­nie się każ­dym ser­we­rem z osob­na. Prelegent pod­su­mo­wał to stwier­dze­niem „trak­tuj swo­je ser­we­ry jak byd­ło, a nie zwie­rzę do­mo­we”. Poszczegól­ne ser­we­ry nie mu­szą mieć na­wet uni­ka­to­wych nazw, a wszel­kie pra­ce ad­mi­ni­stra­cyj­ne mu­szą być wy­ko­ny­wa­ne w spo­sób zauto­ma­ty­zo­wa­ny. W ra­zie prob­le­mów z jed­nym z węz­łów wir­tu­ali­zac­ji nie na­le­ży pró­bo­wać pro­wa­dzić diag­no­sty­ki lub na­pra­wy opro­gra­mo­wa­nia, lecz na­le­ży od­two­rzyć śro­do­wis­ko od pod­staw.

Dość spo­ro cza­su pre­le­gent po­świę­cił na zgrub­ne omó­wie­nie fi­zycz­nej i lo­gicz­nej archi­tek­tu­ry chmu­ry Azure. Szczególny na­cisk po­ło­żył przy tym na te ele­men­ty, któ­re ma­ją istot­ny wpływ na zwięk­sze­nie bez­pie­czeń­stwa in­fra­struk­tu­ry, ta­kie jak po­dwój­na wir­tua­li­za­cja zmniej­sza­ją­ca ry­zy­ko uciecz­ki ko­du z war­stwy wir­tu­al­nej czy mo­duł Fabric Controller, któ­ry ana­li­zu­je ruch sie­cio­wy i dys­ko­wy za­po­bie­ga­jąc nie­auto­ry­zo­wa­ne­mu do­stę­po­wi do da­nych.

Kluczowym ele­men­tem ca­łe­go śro­do­wis­ka Azure jest sys­tem usta­la­nia toż­sa­mo­ści użyt­kow­ni­ków. Infrastruk­tu­ra chmu­ry mu­si mieć pew­ność, że po­szcze­gól­ne żą­da­nia do­stę­pu do usług i da­nych po­cho­dzą fak­tycz­nie od użyt­kow­ni­ków, któ­rych da­ne iden­ty­fi­ka­cyj­ne zo­sta­ły po­da­ne. Dlatego war­stwa ser­we­ra toż­sa­mo­ści LDAP, uży­wa­ne­go w AzureActive Directory, jest chro­nio­na w szcze­gól­ny spo­sób, a bez­po­śred­nie­go do­stę­pu do ka­ta­lo­gu użyt­kow­ni­ków nie ma­ją na­wet pra­cow­ni­cy ob­słu­gi tech­nicz­nej Azure. Jest to tym bar­dziej istot­ne, że toż­sa­mość użyt­kow­ni­ków mo­że być usta­la­na za po­śred­nic­twem roz­wią­zań ta­kich jak OAuth, nie zaw­sze w spo­sób za­pew­nia­ją­cy peł­ną wia­ry­god­ność. Firma Micro­soft, po­dob­nie jak in­ne du­że kon­cer­ny IT, re­gu­lar­nie sku­pu­je na „czar­nym ryn­ku” skra­dzio­ne ba­zy da­nych uwie­rzy­tel­nia­ją­cych aby upew­nić się, czy nie ma w nich in­for­mac­ji o użyt­kow­ni­kach ko­rzy­sta­ją­cych z Azure.

Aby użyt­kow­ni­cy plat­for­my Azure mog­li oce­nić stan bez­pie­czeń­stwa uru­cha­mia­nych tam usług, do­stęp­ne są na­rzę­dzia po­zwa­la­ją­ce zau­to­ma­ty­zo­wać pro­ces ana­li­zy i oce­ny. Przy iloś­ci in­for­mac­ji, któ­ra jest prze­twa­rza­na – mo­wa o 13 miliar­dach zda­rzeń dzien­nie! – nie ma mo­wy o mo­zol­nym prze­glą­da­niu dzien­ni­ków zda­rzeń. Każdy wpis tra­fia do na­rzę­dzia Azure Log Analytics, a wy­ni­ki ana­li­zy są przed­sta­wia­ne w kon­so­li Azure Security Center.

Duże wra­że­nie zro­bi­ła ses­ja de­mon­stra­cyj­na, w cza­sie któ­rej pre­le­gent po­ka­zał wy­sta­wio­ną na świat ma­szy­nę wir­tu­al­ną, ce­lo­wo skon­fi­gu­ro­wa­ną w ka­ry­god­ny z punk­tu wi­dze­nia bez­pie­czeń­stwa spo­sób. Już w cza­sie trwa­nia pre­zen­tac­ji na­stą­pi­ły uda­ne pró­by za­lo­go­wa­nia się na nią wła­my­wa­czy z ca­łe­go świa­ta. Panel Azure Security Center nie tyl­ko wy­świet­lił ostrze­że­nie o błęd­nej kon­fi­gu­rac­ji ma­szy­ny i li­stę za­le­ca­nych zmian, ale też po­ka­zał wszyst­kie pró­by ko­mu­ni­kac­ji z ma­szy­ną oraz li­stę uwie­rzy­tel­nio­nych użyt­kow­ni­ków (w tym wła­my­wa­czy) sko­re­lo­wa­ną ze źród­ło­wy­mi adre­sa­mi IP. Automa­tycz­nie wy­ka­za­ne zo­sta­ły te ses­je użyt­kow­ni­ków, któ­re są po­dej­rza­ne, to zna­czy zo­sta­ły za­po­cząt­ko­wa­ne z sie­ci zna­nych z du­żej licz­by ata­ków. Można by­ło w tym mo­men­cie na­ka­zać dal­sze śle­dze­nie dzia­łań rea­li­zo­wa­nych w tych po­dej­rza­nych ses­jach, łącz­nie z po­ka­za­niem uru­cha­mia­nych pro­gra­mów oraz do­ko­ny­wa­nych zmian w pli­kach kon­fi­gu­ra­cyj­nych i sys­te­mo­wych.

Kolejnym na­rzę­dziem poz­wa­la­ją­cym oce­nić bez­pie­czeń­stwo usług, szcze­gól­nie uru­cha­mia­nych w mo­de­lu PaaS lub SaaS, jest Network Watcher. Również ono ko­rzy­sta z da­nych o adre­sach IP zna­nych ze szkod­li­wej dzia­łal­no­ści i ostrze­ga użyt­kow­ni­ków o po­łą­cze­niach ini­cjo­wa­nych z tych adre­sów. Analizuje jed­nak też sie­cio­wy pod ką­tem wy­stę­po­wa­nia ano­malii ta­kich jak du­ża licz­ba po­łą­czeń i da­nych lub po­ja­wia­nie się nie­właś­ci­wej dla da­nej usłu­gi po­sta­ci in­for­mac­ji.

Informacje o wy­kry­tych prob­le­mach moż­na od­czy­ty­wać za po­mo­cą inter­fej­su REST i prze­twa­rzać we włas­nych na­rzę­dziach do mo­ni­to­rin­gu i po­wia­da­mia­nia. Istnieje też moż­li­wość auto­ma­tycz­ne­go wy­łą­cza­nia ma­szyn wir­tu­al­nych i usług w mo­men­cie stwier­dze­nia na­ru­sze­nia ich bez­pie­czeń­stwa tak, aby uda­ne wła­ma­nie nie stwa­rza­ło ata­ku­ją­ce­mu moż­li­woś­ci wy­kra­dze­nia da­nych lub wy­ko­rzys­ta­nia prze­ję­tej ma­szy­ny do prze­pro­wa­dze­nia dal­szych ata­ków.

Podsumo­wu­jąc swo­je wy­stą­pie­nie Michał Furmankiewicz stwier­dził, że wyś­ci­gu zbro­jeń w za­kre­sie bez­pie­czeń­stwa nie da się już ani unik­nąć, ani za­trzy­mać. Należy też pa­mię­tać, że na­wet do­sko­na­le bez­piecz­na in­fra­struk­tu­ra nie ochro­ni przed błę­da­mi w sa­mych apli­kac­jach. I tak, jak ol­brzy­mią po­pu­lar­ność zdo­by­wa obec­nie ruch DevOps, co­raz więk­sze zna­cze­nie po­win­no na­bie­rać po­dejś­cie Dev­Sec­Ops, in­te­gru­ją­ce bez­pie­czeń­stwo z pro­ce­sem roz­wo­ju i wdra­ża­nia opro­gra­mo­wa­nia.


Jako ostat­ni pre­zen­tac­ję przed­sta­wił Tomasz KrawczykFuture Processing Data Processing. Poświęcił ją do­stęp­ne­mu w ra­mach plat­for­my Azure na­rzę­dziu Data Factory, słu­żą­ce­mu do wsa­do­we­go za­si­la­nia i prze­twa­rza­nia da­nych. Obsługuje ono za­rów­no pro­ce­sy ETL jak i ELT. Pozwala od­czy­ty­wać in­for­mac­je z po­nad 70 róż­nych ty­pów źró­deł i za­pi­sy­wać do kil­ku­dzie­się­ciu, przy czym uży­wa­ne mo­gą być skład­ni­ce da­nych ist­nie­ją­ce w chmu­rze (nie tyl­ko Azure) oraz w we­wnętrz­nej infra­struk­tu­rze klienta (ang. on pre­mises).

Przetwarza­nie mo­że być wyz­wa­la­ne na róż­ne spo­so­by. Można uru­cha­miać pro­ce­sy ręcz­nie, a na­wet kro­ko­wo ana­li­zo­wać ich reali­zac­ję. Można też wy­wo­łać pro­ces zdal­nie, uru­cha­miać go re­gu­lar­nie wed­ług har­mo­no­gra­mu lub zde­fi­nio­wać wy­zwa­la­cze re­a­gu­ją­ce na przy­kład na po­ja­wie­nie się no­wych da­nych w źród­ło­wej skład­ni­cy.

Sposób prze­twa­rza­nia in­for­mac­ji moż­na co praw­da de­fi­nio­wać za po­mo­cą struk­tur JSON, jed­nak naj­waż­niej­szą ce­chą no­wej, dru­giej wer­sji na­rzę­dzia Data Factory jest wi­zu­al­ny edy­tor po­to­ków prze­twa­rza­nia. Kolejno do­da­wa­ne blocz­ki mo­gą uru­cha­miać wbu­do­wa­ne algo­ryt­my trans­for­mo­wa­nia da­nych, włas­ne pro­ce­du­ry prze­twa­rza­ją­ce al­bo ze­wnętrz­ne usłu­gi chmu­ro­we.

W ra­mach de­mon­stra­cji pre­le­gent po­ka­zał i uru­cho­mił pro­ces prze­twa­rza­nia po­bie­ra­ją­cy obra­zy ra­stro­we z ka­ta­lo­gu da­nych prze­cho­wy­wa­ne­go w chmu­rze Azure, wy­sy­ła­ją­cy je do usłu­gi ana­li­tycz­nej do­stęp­nej za po­mo­cą pro­to­ko­łu HTTP i ka­te­go­ry­zu­ją­cej treść obra­zów, a na­stęp­nie umiesz­cza­ją­cy wy­ni­ki ka­te­go­ry­zac­ji w ba­zie da­nych SQL Server, rów­nież dzia­ła­ją­cej w chmu­rze. I choć wy­daj­ność nie by­ła po­wa­la­ją­ca, w przy­pad­ku bar­dziej zin­te­gro­wa­nych po­to­ków prze­twa­rza­nia oraz więk­szych iloś­ci da­nych uda­je się po­dob­no uzys­kać cał­kiem do­bre wy­ni­ki. Zacytowany zo­stał prak­tycz­ny przy­kład, w któ­rym wsad da­nych o roz­mia­rze 15 GiB był prze­twa­rza­ny w cza­sie nie­prze­kra­cza­ją­cym 20 mi­nut.

Jako sła­be stro­ny Azure Data Factory Tomasz Krawczyk wy­mie­nił prze­de wszyst­kim trud­ne diag­no­zo­wa­nie prob­le­mów po­ja­wia­ją­cych się pod­czas prze­twa­rza­nia, spo­wo­do­wa­ne ma­ło treś­ci­wy­mi ko­mu­ni­ka­ta­mi. Ostrzegł też, że prze­twa­rza­nie przy­ro­sto­we wy­ma­ga sa­mo­dziel­ne­go wy­dzie­le­nia no­wych por­cji da­nych przy każ­dym ko­lej­nym uru­cho­mie­niu, na przy­kład na pod­sta­wie znacz­ni­ka cza­so­we­go po­przed­nie­go za­si­la­nia.


Wystąpienia pre­zen­to­wa­ne w ra­mach lis­to­pa­do­we­go spot­ka­nia gru­py ETSM by­ły na na­praw­dę wy­so­kim po­zio­mie me­ry­to­rycz­nym. Dotykały one prze­kro­jo­wo za­gad­nień zwią­za­nych ze śro­do­wis­kiem chmu­ro­wym, od je­go kon­struk­cji fi­zycz­nej i lo­gicz­nej, przez je­go za­bez­pie­cze­nie i mo­ni­to­ro­wa­nie, aż po wpro­wa­dza­nie i wy­pro­wa­dza­nie da­nych. Należy po­chwa­lić spój­ność spot­ka­nia w tym właś­nie za­kre­sie.

Szczególne wra­że­nie zro­bi­ło na mnie wy­stą­pie­nie Michała Furman­kie­wicza. Doskonale po­ka­zał on ol­brzy­mie moż­li­woś­ci ana­li­tycz­ne, ja­ki­mi dys­po­nu­je sys­tem Azure oraz po­ziom dba­ło­ści fir­my Micro­soft o utrzy­ma­nie wy­so­kie­go po­zio­mu za­ufa­nia w sto­sun­ku do bez­pie­czeń­stwa tej plat­for­my. Nawet, je­że­li nie ko­rzy­sta się z Azure lub roz­wią­zań chmu­ro­wych, po tym wy­stą­pie­niu po­win­no się za­dbać o wpro­wa­dze­nie auto­ma­ty­zacji dzia­łań ma­ją­cych zwią­zek z bez­pie­czeń­stwem, ta­kich jak mo­ni­to­ro­wa­nie opro­gra­mo­wa­nia, ana­li­zo­wa­nie dzien­ni­ków zda­rzeń i auto­ma­tycz­ne wy­kry­wa­nie ata­ków.

Jak wszyst­kie po­przed­nie, i to spot­ka­nie by­ło świet­nie zor­ga­ni­zo­wa­ne. Prelegenci trzy­ma­li się przyz­na­ne­go im cza­su, każ­de­mu wy­stą­pie­niu to­wa­rzy­szy­ła krót­ka dy­sku­sja, a na za­koń­cze­nie wszys­cy mie­li okaz­ję spot­kać się i po­roz­ma­wiać przy cze­ka­ją­cym już po­częs­tun­ku.