Artikkelit kirjoittajan mukaan

“Kun et kuitenkaan tajua, niin anna meidän tehdä se”. Jos et kuitenkaan ole täysin samaa mieltä tämän ajatuksen kanssa, niin kannattaa silti jatkaa lukemista, sillä seuraavassa kirjoituksessa saattaa esiintyä asioita, jotka sinunkin olisi hyvä ottaa huomioon ympäristöäsi suunnitellessa. Disclaimer: Sisältää tuotesijoittelua!

Miten toteuttaa pääsynhallinta itse palveluun?

Yleisimmin todennus toteutetaan joko käyttäjätunnus/salasana -periaatteella tai vahvaa tunnistusta hyväksi käyttäen (two-factor authentication). Määrittelyvaiheessa tulisikin kartoittaa tarpeet sen mukaan, kuinka luottamuksellista materiaalia taustapalveluun tuodaan käyttäjien käsiteltäväksi sekä millainen hierarkinen malli palvelun kirjastoissa on käytössä.

Ensimmäiseksi olisi syytä miettiä miten edustapalvelun todennus eli Front End Authentication kannattaisi toteuttaa. Sijaitseeko jo ensimmäisen vaiheen tunnistautumisen takana luottamuksellista materiaalia vai onko tarkoitus julkaista vain käyttäjäystävällinen sivusto, jonka sisältö on kaikkien tunnistautuneiden luettavissa? Sivuston sisältäessä kaikille luettavaksi tarkoitettua materiaalia voidaan hyvinkin harkita käyttäjätunnus/salasana -mallista tunnistautumista, mutta aina kannattaa ottaa huomioon, että tämä avaa yhden lisäoven osaavalle hyökkääjälle.Mutta jätetäänpä pelottelu sikseen. Tärkeää on, että lukija ymmärtää ratkaisujen tuomat hyödyt sekä riskit. Toisena varteenotettavana vaihtoehtona voitaisiin toteuttaa edustapalvelun todentaminen vahvaa tunnistusta hyväksi käyttäen, jolloin palveluun päästäkseen käyttäjätunnuksen sekä salasanan lisäksi käyttäjän tulisi syöttää esimerkiksi kertakäyttöinen salasana, jonka palvelu toimittaa käyttäjälle ensimmäisen vaiheen tunnistautumisen jälkeen esimerkiksi matkapuhelimeen tai sähköpostiin. Tällöin hyökkääjällä tulisi olla jollain tavalla pääsy hyökättävän käyttäjän omaisuuteen, jotta hyökkäys voisi onnistua.

Edustapalvelun todennuksen lisäksi tulisi miettiä taustapalvelujen todennus (Back End Authentication). Voidaanko käyttäjille sallia pääsy taustapalveluihin joustavasti (kertakirjautuminen, single sign-on) vai tuleeko käyttäjän tunnistautua myös taustapalvelua varten? Edusta- ja taustapalvelun ratkaisut eivät ole kytköksissä toisiinsa, vaan on mahdollista määritellä palvelukohtaisesti millaista suojaustasoa käytetään käyttäjän siirtyessä kuhunkin palveluun. Tällä tavoin saadaan luottamuksellinen materiaali suojattua pääsynhallintapolitiikoilla, ja ainoastaan palveluun valtuutetuilla (auktorisoiduilla) käyttäjillä on pääsy tiettyihin taustapalveluihin. Joustavilla pääsynhallintapolitiikoilla saadaan aikaan toivottuja ratkaisuja ilman turhaa pelkoa tiedon leviämisestä vääriin käsiin.

Harkinnan arvoinen asia on myös se, miten pääsynhallintapolitiikka erotellaan yrityksen sisäisten ja ulkoisten käyttäjien välillä. Haluammeko, että sisäisillä käyttäjillä on suora pääsy extranet-palveluun vai halutaanko saavuttaa prosessietuja yhdistämällä sekä sisäisten että ulkoisten käyttäjien pääsynhallinta yhden ja saman komponentin avulla?

Tällaisen vaihtoehdon tarjoaa esimerkiksi Microsoftin Forefront Unified Access Gateway, joka nimensä mukaisesti toimii yhtenäisenä yhdyspisteenä ja reunatason pääsynhallintaratkaisuna kaikille käyttäjille riippumatta siitä, ovatko he yrityksen sisäisiä työntekijöitä vai ulkoisia kumppaneita. Aiemmin mainittu edusta- ja taustapalvelujen todennus on häiritsevän helppoa toteuttaa taustapalvelukohtaisesti. Kertakirjautumistapojen toteutusmahdollisuuksia on useita, Windows-ympäristöissä Kerberos tai NTLM, sekä muissa ympäristöissä lomaketunnistautuminen (Forms Based Authentication). Riippuen valittavasta todentajasta (Authentication Provider) on mahdollista määrittää sisäisille ja ulkoisille käyttäjille saman pääsypisteen (access point) kautta toisistaan eroavat todennustavat käyttäjien päätyessä kuitenkin samaan palveluun.

Jos (ja kun) palveluumme yritetään hyökätä?

Yleisimpiä hyökkäyskeinoja extranet-palvelutapauksissa on tietojen kalastelu (Social Engineering), LDAP-injektioyritykset sekä palvelunestohyökkäykset (Denial of Service).  Forefront Unified Access Gatewayssa on kahden jälkimmäisen varalle sisäänrakennetut mekanismit, joilla hyökkäykset saadaan pysäytettyä ilman, että koko palvelu kaatuu. Tietojen kalastelu voi tuottaa aina tulosta, kun tiedon luovuttamisesta vastaa  hyökkäyksen kohteena oleva käyttäjä, mutta vahvaa tunnistusta käyttäessä hyökkäyksen onnistumisen mahdollisuudet pienenevät huomattavasti.

Kuten kirjoituksesta on toivottavasti luettavissa, on olemassa useita tapoja toteuttaa turvallinen ja toimiva extranet-ratkaisu. Avainasemassa on huolellinen suunnitelu ja määrityksien tekeminen, jotta palvelusta saadaan mahdollisimman ketterä,mutta silti turvallinen juuri teidän tarpeitanne varten.

Markkinoiden kuumin muoti-ilmiö tällä hetkellä on pilvipalvelut.  Käsite pilvipalvelu tarkoittaa yrityksille verkossa tarjottavaa, yleensä selaimella käytettävää ohjelmaa tai sovellusta, joka tuotetaan palveluna yhdestä paikasta monen tahon käyttöön. Verkossa käytettävä palvelu luo omat haasteensa yrityksille tietoturvallisuuden kannalta jotka tulee ottaa huomioon palvelun käyttöönotossa.

Tämän on huomannut myös Websense,  joka on tuonut perinteisten Appliance-ratkaisujen rinnalle SaaS (Security-as- a-Service) –ratkaisut . Websensen pilvistäkkiin kuuluu tällä hetkellä Hosted Web Security sekä Hosted Email Security, jotka tarvittaessa integroituvat keskenään. Myöhemmin tänä vuonna Websense tuo SaaS-alustalleen ennennäkemättömiä uudistuksia, joista ei tässä vaiheessa voi valitettavasti vielä puhua. Toimikoon tämä siis teaserina, allekirjoittanut lupaa palata aiheeseen myöhemmin tänä keväänä. Stay tuned!

Viime vuosina tietomurrot ovat yleistyneet räjähdysmäisesti. Tänään uutisoitiin, että jopa 100000 suomalaisen korttitiedot ovat vuotaneet ulkomaille helsinkiläisen liikkeen maksujärjestelmään suoritetun hyökkäyksen yhteydessä. Kävi ilmi, että magneettijuovallisten maksukorttien tiedot lähetettiin salaamattomina maksuliikennettä hoitaneelle palvelimelle.

Miten tämä sitten olisi voitu estää? Valitettava tosiasia on, että harvoin tietoturvallisuuden puutteisiin reagoidaan ennen kuin on liian myöhäistä. Jos tietoturvamielessä heikkoon järjestelmään olisi suoritettu puolueeton auditointi, näin ei olisi päässyt tapahtumaan.

Miten sitten kriittiset järjestelmät tulisi suojata uhkia vastaan? Ratkaisuja on useita, niin myös niistä syntyviä tapahtumia eli lokeja. Jokainen järjestelmä tuottaa lokeja omalla tavalla ja kielellään. Kymmenien järjestelmien valvominen on erittäin aikaa vievää ja hankalaa.

Security Information and Event Management (SIEM) mahdollistaa alustariippumattoman tavan kerätä eri järjestelmistä tapahtumat sekä yhdistää ne yhden järjestelmän alle, jolla saadaan valvottua kaikkia verkon komponentteja reaaliaikaisesti sekä vaivattomasti. Epäilyttävistä toiminnoista verkossa järjestelmä voidaan asettaa lähettämään hälytyksen ylläpidolle, jolloin vahinko ei vielä välttämättä ole päässyt tapahtumaan.

Selvennettäköön, että SIEM ei ole tuote, SIEM on ratkaisu. Markkinoilla on olemassa hyviä työkaluja SIEM:n käyttöönottoon, mutta ilman sopivaa tarvetta ja sitoutumista prosessiin SIEM:in ominaisuudet jäävät auttamattomasti hyödyntämättä.  Ainoastaan hyvin suunniteltuna SIEM toimii organisaation tietoturvaprosessia tukevana ratkaisuna.

Syvennytään SIEM:n maailmaan myöhemmissä blogikirjoituksissa.