Architecting for DDoS protection

Markku Kaskenmaa, Security Solutions Architect, Public Sector, AWS

Markku Kaskenmaa (AWS) piti hyvän esityksen hajautettujen palvelunestohyökkäysten (Distributed Denial of Service, DDoS) torjunnasta AWS:ssä. Esityksessä luonnollisesti kerrottiin AWS:n ja asiakkaiden välisestä vastuunjaosta tietoturva-asioissa. DDoS-hyökkäysten torjunta nojaa vahvasti siihen, että asiakas käyttää AWS:n palveluita ja AWS:n omaa, maailmanlaajuista, verkkoinfrastruktuuria mahdollisimman laajasti, koska ne on rakennettu kestämään ja torjumaan erittäin suuria hyökkäyksiä. Esityksessä annettiin myös tietoa minkälaisilla keinoilla asiakkaat voivat itse vähentää DDoS-hyökkäysten vaikutuksia eri AWS-palveluiden asetuksilla sekä tehdä sovelluksistaan sopeutuvia vaihtelevaan kuormaan. DDoS-hyökkäysten torjunta vaatii siis toimenpiteitä monella tasolla ja AWS tekee sitä myös asiakkaiden huomaamatta taustalla.

Multi Region Availability

Juho Rautio, Principal Consultant, Webscale

Multi region availability esityksessä kerrottiin miten Route53 Latency-Based Routing (LBR) ja Route53 health check ominaisuuksien avulla voi rakentaa erittäin vikasietoisen ja vasteaika-optimoidun palvelun. Esityksessä käytiin yksityiskohtaisesti, oikean maailman esimerkin avulla läpi, mitä ratkaisun toteuttaminen vaatii monimutkaisessa yrityksen sisäverkossa. Automaattista vikatilanteen korjautumista ja vasteaikaan perustuvaa reititystä demonstroitiin reaaliajassa.

Chaos Engineering with AWS Fault Injection Simulator

Jussi Lehtiniemi, Senior Consultant / Cloud Architect, Webscale

Reaalimaailman sovelluksissa ja palveluissa tulee aina olemaan ongelmia. Tämä yksinkertainen toteamus on se, johon Netflix törmäsi 2010-luvun alussa ollessaan skaalaamassa palveluitaan globaalille tasolle. Kun palvelut skaalautuvat riittävän suuriksi, pelkästään ongelmiin reagoiminen alkaa käydä mahdottomaksi. Ratkaisuksi tähän ongelmaan Netflix kehitti konseptin, jolle se antoi nimen Chaos Engineering.

Chaos Engineering on pohjimmiltaan filosofia, jossa hyväksytään, että palveluissa tulee aina olemaan odottamattomia ongelmia. Sen sijaan, että näihin vastattaisiin reaktiivisesti ongelman jo ilmettyä, Chaos Engineering pyrkii varautumaan ongelmiin jo ennalta. Varautumisessa tärkeimmät työkalut ovat tarkkaan suunnitellut ja kontrolloidut testit, joilla simuloidaan reaalimaailman ongelmia, esimerkiksi CPU-kuormaa, palvelinten levyjen täyttymistä, verkkokatkoksia tai latenssin kasvua. Chaos Engineering -kokeista saadaan paras mahdollinen hyöty, jos niitä ajetaan suoraan tuotantoympäristössä. Tämä kuitenkin vaatii, että järjestelmät ovat jo sillä tasolla, että kokeiden aiheuttamat mahdolliset ongelmat eivät vaaranna liiaksi itse palveluita.

Omia Chaos Engineering -kokeita varten Netflix kehitti Chaos Monkey -työkalun, joka on yksinkertaisesti erillinen prosessi, mikä satunnaisesti sammuttaa virtuaalikone-instansseja tuotantoympäristössä. Se että tuotantoympäristössä ajetaan Chaos Monkeyn kaltaista työkalua tai suoritetaan muita kokeita, jotka aiheuttavat “hallittua kaaosta”, johtaa siihen, että jo suunnittelu- ja kehitysvaiheessa on panostettava palveluiden vikasietoisuuteen, ja myös testattava palveluita mahdollisten ongelmien varalta. Lopputuloksena syntyy pikkuhiljaa parempia ja vikasietoisempia palveluita. Samalla myös tiimit oppivat toimimaan simuloiduissa vikatilanteissa, ja osaavat näin myös toimia paremmin oikean vikatilanteen sattuessa.

Chaos Engineering filosofian käyttöönotossa organisaatioissa ei tarvitse välittömästi hypätä tuntemattomaan ja alkaa aiheuttaa ongelmia omassa tuotantoympäristössä, vaan tämä on vasta tavoitetila, johon pyritään. Alkuun pääsee helposti ottamalla Chaos Engineering -kokeet ja käytännöt osaksi sovellusten ja palveluiden normaalia kehityskaarta. Aluksi tehdään pieniä ja hallittuja kokeita esim. testiympäristöissä, joissa mahdollisista havaituista ongelmista ei ole haittaa tuotantojärjestelmille. Kokeiden tekemiseen on nykyään paljon valmiita tuotteita ja palveluita, joilla pääsee alkuun, esim. AWS Fault Injection Simulator (FIS). Havaitut ongelmat korjataan ja iteraatiokierroksia jatketaan, kunnes oma luottamus palveluiden laatuun ja vikasietoisuuteen on riittävällä tasolla. Tärkeintä on hyväksyä, että reaalimaailmassa kaaos on normaalia, ja mitä vain voi sattua. Näin voidaan ennalta varautua tuleviin ongelmiin.

Resilience at AWS

Panu Koskela, Partner Solution Architect, AWS

Panu Koskelan (AWS) esitys keskittyi vikasietoisten järjestelmien luomiseen AWS:n pilviympäristössä. Tässäkin esityksessä käytiin läpi mikä osuus vikasietoisuudesta on AWS:n vastuulla ja mikä jää asiakkaan vastuulle. Esityksen mielenkiintoisinta antia oli kun Panu esitteli AWS:n käyttämiä jatkuvan kehityksen malleja, joissa tiimit sekä kehittävät että ylläpitävät palvelua tai sen osaa. Mahdollisten ongelmien jälkikatselmoinnissa etsitään juurisyitä ja ratkaisuja syyllistämättä ketään. Jatkuva kehitys mahdollistaa AWS:n oman vikasietoisuuden. Esityksessä käytiin myös laajasti läpi minkälaisia arkkitehtuureja, kehitysmalleja ja AWS-palveluita asiakkaat voivat käyttää parantaakseen sovellustensa vikasietoisuutta. Yksi mielenkiintoinen nosto on AWS Fault Injection Simulator (AWS FIS), jolla asiakkaat voivat testata erilaisten häiriöiden vaikutusta omaan ympäristöönsä.

Application Security in AWS

Jukka Ukkonen, Senior Consultant / Cloud Architect, Webscale

Kyberturvallisuus on tärkeässä roolissa yrityksen koosta riippumatta, sillä kyberhyökkäyksen aiheuttamat vahingot voivat olla suuria, ja ne vaikuttavat myös yrityksen maineeseen ja asiakkaiden luottamukseen. Sovellusten turvallisuuteen liittyvät oleellisesti erilaiset työkalut, käytännöt ja prosessit, joiden avulla pyritään estämään sovelluksen turvallisuusongelmia. Kehittäjät ovat myös nykyään enenevissä määrin vastuussa pilvi-infrasta ja -resursseista, joita sovellukset tarvitsevat toimiakseen.



Tästä syystä sovellusten turvallisuuden kannalta on tärkeää, että yksittäisen sovelluksen koodin sijaan käsitellään kokonaisuutta, johon kuuluvat esimerkiksi sovellus- ja IaC-koodi, pilvi-infra ja -resurssit ja data. Onkin suositeltavaa, että turvallisuus on läsnä ohjelmistokehityksen elinkaaren kaikissa vaiheissa. DevOpsin yhteydessä tästä käytetään termiä DevSecOps, joka tarkoittaa turvallisuuden lisäämistä DevOps-malliin. DevSecOps pitää myös sisällään turvallisuuteen liittyvien operaatioiden automatisoinnin, kuten esimerkiksi erilaisten skannaussovellusten käytön (SAST, DAST, IAST), riippuvuuksien ja kontti-imagejen tarkistamisen sekä reagoimisen havaittuun uhkaan. Lisäksi turvallisuuteen liittyvä monitorointi on osa DevSecOps:ia.

Turvallisuuteen liittyvät tärkeimmät toiminnot ovat ongelmien tunnistaminen, suojautuminen erilaisilta uhkilta, hyökkäyksen tai muun tietoturvaongelman havaitseminen, havaittuun ongelmaan reagointi sekä palautuminen ongelman jäljiltä. AWS tarjoaa erilaisia turvallisuuteen liittyviä palveluita sekä tuotteita, joissa on erilaisia mekanismeja tähän liittyen ja joiden käyttö on suositeltavaa turvallisuuteen liittyvien tärkeimpien toimintojen mahdollistamiseksi.

Workshop

Kalle Soranko, Senior Consultant / Cloud Architect, Webscale

Henri Meltaus, CTO, Webscale

Konferenssipäivän päätteeksi järjestimme “Business Continuity”-aiheisen workshopin.

Workshopissa osallistujat pääsivät pienryhmissä suunnittelemaan lippu-lappu.fi lipunmyyntiverkkokaupan AWS-arkkitehtuurin uudelleen päivän teeman mukaisesti. Workshopin lopussa jokainen ryhmä esitteli vielä tuotoksensa yhteisesti.

Yhteenveto päivästä

Tech Days -konferenssi oli oikein onnistunut tapahtuma, joka kokosi yhteen lähes kaikki webscalerit sekä myös asiakkaitamme. Päivän aikana pääsimme verkostoitumaan ja oppimaan uutta. Mielenkiintoisten esitysten ja workshopin lisäksi meitä hemmoteltiin hyvällä ruoalla ja hienolla iltajuhlalla. Iltajuhlassa saimme nauttia tarjoiluiden sekä hyvän musiikin lisäksi TV:stä tutun näyttelijän ja stand-up koomikon Jaakko Saariluoman esityksestä. Paikkana Tuusulan Krapi loi loistavat puitteet tapahtumalle.

Jäämme innolla odottamaan tapahtuman palautekyselyn tuloksia ja kehitysideoita, jotta pystymme ensi vuonna tekemään Tech Daysistä vieläkin onnistuneemman. Toivottavasti tapaamme mahdollisesti myös sinut ensi vuonna!