Aiheen ‘extranet’ sisältävät artikkelit

“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.

Mitä tehdä tuotteella, joka tuntuu liian monipuoliselta? Microsoftin Unified Access Gatewayn ominaisuusskaala on häkellyttävän laaja. Käyttötarkoituksissa tuntuu olevan rajaton määrä vaihtoehtoja, eikä roolinjako ole yhtä selkeä kuin monessa kilpailijan tuotteessa. Extranet käytössä UAG:lle voidaan ajatella kaksi selkeästi erilistä käyttötapausta. Vaikka jako ei ole missään nimessä näin mustavalkoinen, on ajatusmallin helpottamiseksi syytä yksinkertaistaa molemmat vaihtoehdot.

Ensimmäinen käyttötapaus on extranet-sovelluksen julkaiseminen suoraan UAG:n läpi. Suoralla julkaisulla voidaan hyödyntää UAG:n laajoja tietoturvaominaisuuksia, ja mahdollistaa monipuolisemmat autentikointimallit. Käyttötapauksen hyötynä on kevyet asennus- ja kustoimointivaatimukset. UAG näkyy loppukäyttäjälle mahdollisesti lomakeautentikointina tai haluttaessa se voidaan piilottaa täysin. Julkaistaessa esimerkiksi sharepoint, voidaan hyötyä suoraan laajasta tuesta ja sharepoint-pakettien natiivikäsittelystä (http://technet.microsoft.com/en-us/library/dd857299.aspx). Vahvalle pohjalle rakentaminen mahdollistaa käytön laajentamisen helposti myöhemmässä vaiheessa.

Toisena käyttötapauksena voidaan eritellä UAG:n käyttö portaalina extranet-palveluihin. Tämä mahdollistaa useiden palveluiden julkaisemisen yhdestä näkymästä. Palveluiden keskittäminen ja julkaiseminen ei vielä muodosta merkittävää uutta innovaatiota, mutta mahdollisuudet palvelun hallintaan ja mukauttamiseen ovat huimat. Portaalin muokkaamiseen on käytössä enemmän mahdollisuuksia kuin koskaan aikaisemmin ja merkittäviä osia SharePoint toiminnallisuudesta voidaan toteuttaa UAG:n portaalissa. Tämä mahdollistaa luovien ja kiinnostavien portaalien kehittämisen, jossa voidaan hyödyntää aplikaatiokohtaiset autentikointi-/tietoturvavaatimukset. UAG:n vahvuus onkin nimenomaan liiallinen monipuollisuus. Tämä asettaa projektin suunnittelussa haasteen asioiden tuottamisen oikeassa kohtaa hierarkiaa. Merkittävät vaatimukset monimutkaisista landin page -kombinaatioista voidaankin toteuttaa UAG:n sisällä, joka on tietoturvan kannalta merkittävä kehitysaskel. Sanomattakin lienee selvää että loppukäyttä arvostaa työtä, joka on portaalin kehittämiseen käytetty. Perinteisen tylstän portaalinäkymän sijaan saadaan saumaton käyttökokemus koko extranetin laajuudelta.

Entä ne muut UAG:n ominaisuudet? Direct Access? No se onkin sitten toinen tarina, johon liittyy olennaisesti sama kiusallinen liiallinen monipuolisuus. Sisäverkon käyttäjien päästäminen yrityksien resursseihin eroaa merkittävästi extranet vaateista. Tämän takia onkin suositeltavaa miettiä onko järkevämpää ajatella extranet käytössä UAG kokonaan itsenäisenä kokonaisuutena.

Ei muuta kuin Dream BIG with UAG