Open search

    Pilvipalveluiden Top 10 -tietoturvariskit (OWASP-luonnos) ja niihin varautuminen, osa 3

    Kolmannessa osassa pilvipalveluiden riskejä ja hallintakeinoja käsittelevässä kirjoituksessani käsittelen loput viisi pilvipalveluiden Top-10 riskiä:

    • Service and Data Integration eli Palvelujen ja tietojen integrointi
    • Multi Tenancy and Physical Security eli Resurssien jako ja fyysinen turvallisuus
    • Incident Analysis and Forensic Support eli Poikkeamien analysointi ja tutkinta
    • Infrastructure Security eli Järjestelmän turvallisuus
    • Non-Production Environment Exposure eli Kehitys- ja testausympäristöjen paljastuminen

    Ensimmäistä osaa kirjoituksesta pääset lukemaan tästä.

    Toista osaa kirjoituksesta pääset lukemaan tästä.

     

    6.     Service and Data Integration eli Palvelujen ja tietojen integrointi

    Palvelun integrointi yrityksen järjestelmiin siten, että järjestelmät keskustelevat toistensa kanssa ohjelmointirajapintojen (Application Programming Interface, API) kautta tuo tehokuutta yrityksen prosesseihin. Palvelut voidaan toteuttaa siten, että asiakassovellus ja API:n tarjoava sovellus vaihtavat tietoja keskenään automaattisesti. Asiakassovellus käy kutsumassa rajapintaa, joka välittää syötteet toteuttavalle sovellukselle. Toteuttava sovellus suorittaa pyynnön vaatimat toimenpiteet ja rajapinta välittää vastauksen takaisin asiakassovellukselle.

    Uhka: API:en väärinkäyttö ja hallinnan menetys

    API:a käyttävä asiakas ei API:n kehitykseen pääse vaikuttamaan, mutta voi arvioida käytettävien API:en tietoturvaa muun muassa arvioimalla onko palveluntarjoaja käyttänyt kehitystyössä Secure by Design -lähestymistapaa. Tässä tapauksessa arvioiminen tarkoittaa esimerkiksi tietoturva-arvion yhteydessä tehtävää selvitystä siitä, miten palveluntarjoaja on suorittanut API-rajapintojen haavoittuvuustestauksen ja miten OWASP Top 10 Web Application Security Risks -listauksen riskeihin on reagoitu.

    Uhka: Liikenteen kaappaaminen/Tietojen kaappaaminen

    Liikenteen ja liikenteen mukana kulkevan tiedon kaappaamisen estääkseen voi rajapintaa käyttävä asiakas käyttää turvallisinta vaihtoehtoa tiedonsiirtomahdollisuuksista. Niin pilvipalveluihin liittyvän kuin muunkin tiedonsiirron tulisi aina olla salattua. Salaamisen lisäksi API-rajapintoja käytettäessä rajapinnan kummatkin osapuolet pitäisi tunnistaa ja valtuuttaa niin, että tiedetään kuka tietoja lähettää ja vastaanottaa, ja että osapuolilla on näin myös oikeus tehdä. 

    Uhka: Lisääntynyt haittaohjelmien määrä

    Haittaohjelmat käyttävät hyväkseen laitteistojen ja ohjelmistojen vikoja, jotka varsinkin vanhojen versioiden osalta ovat laajalti tunnettuja. Pilvipalveluita käytettäessä tulisi omasta tietoturvasta huolehtia niin, että omat ohjelmistot ja kirjastojen versiot, verkkopalvelut, middleware ja taustajärjestelmät päivitetään viipymättä tuoreimpaan ja virheettömimpään versioon. Palveluntarjoajan kohdalla tulisi vastaavasti arvioida, onko näin tehty, ja päivityksiä tulisi vaatia tarvittaessa.

     

    7.     Multi Tenancy and Physical Security eli Resurssien jako ja fyysinen turvallisuus

    Samassa pilvipalvelussa toimivat eri asiakkaiden palvelut toimivat käytännössä kaikki samassa/samoissa konesaliympäristö(i)ssä ja palvelimissa, ja uhat liittyvätkin puutteelliseen asiakkuuksien eriyttämiseen kyseisissä ympäristöissä.

    Uhka: Tietojen menetyksen uhka palveluntarjoajan epäonnistuneen asiakkuuksien eristämisen vuoksi ja hyökkäyksen laajeneminen huonosti suojatulta asiakkuudelta toiseen asiakkuuteen (esim. verkon skannaus ja DDoS-hyökkäykset)

    Tietoturva-arvion yhteydessä pyritään vahvistamaan, että palveluntarjoaja on eriyttänyt eri asiakkaiden tiedot asiakaskohtaisiin virtuaalikoneisiin, tietokantoihin ja virtuaalisiin verkkoihin. Jokaisen asiakkaan tiedot on salattu eri avaimilla ja parhaassa tapauksessa asiakkaan omilla avaimilla (Bring Your Own Keys, BYOK). Palvelussa tulisi olla normaalit kuormantasaus-, palomuuri-, skannaus- ja muut suojakeinot käytössä.

     

    8.     Incident Analysis and Forensic Support eli Poikkeamien analysointi ja tutkinta

    Niin hyökkäysten kuin vahingossa tapahtuvien tietoturvapoikkeamien havaitsemiseen ja selvittämiseen tarvitaan tietoa tapahtumaketjuista. Hyökkäysten, murtojen, tietovarkauksien, kiristysten ym. tapauksessa kyse on rikoksesta ja tapahtumasta on tarpeellista saada myös todistusaineistoa tapahtuman jatkotoimenpiteitä varten.

    Uhka: Poikkeamiin reagointi viivästyy tai epäonnistuu monimutkaisten ympäristöjen vuoksi

    Palvelun tapahtumien selvittämisen avainasemassa on lokitus, joka on toteutettu lokituspolitiikan mukaisesti. Palveluntarjoajaa arvioitaessa tulisikin selvittää myös palvelun tuottamat lokikirjaukset. Tarpeellinen, mutta ei liiallinen lokien määrä auttaa selvittämään tapahtumien kulun. Kun lokihavainnot yhdistetään Security Operations Centeriin (SOC) ja Security Information and Event Management (SIEM) -ohjelmistoon/palveluun, on poikkeamien havaitseminen ja analysointi astetta helpompaa.

    Kun tapahtumaa selvitellään, saattaa olla tarpeellista ottaa rikostutkintaan varautumisen vuoksi todistusaineistoa talteen. Tällöin halutaan tutkia digitaalista mediaa ja tunnistaa, säilyttää ja analysoida tietoa. Tämä tapahtuu muun muassa tutkimalla ja säilyttämällä lokeja ja muita digitaalisia tallenteita, jotka tulisi säilyttää myös myöhempiä jatkotoimenpiteitä varten.

     

    9.     Infrastructure Security eli Järjestelmän turvallisuus

    Pilvipalvelun taustalla toimii normaali konesaliympäristö virtualisoituine palveluineen ja aivan kuin perinteisissä konesaleissa, myös pilvikonesalissa on pahantahtoisella taholla mahdollisuus tehdä tuhoja ja varastaa tietoja pitkän ajan kuluessa.

    Uhka: Pitkälle edenneiden pysyvien uhkien (Advanced Persistent Threats, APT) riski, DoS- ja DDoS-hyökkäykset

    Hyökkääjän mahdollisuus tunkeutua ja piileskellä järjestelmässä heikkenee ympäristön ylläpitäjän pitkäjänteisellä ja sitkeällä tietoturvatyöllä. Tietoturvan kehittäminen riskilähtöisesti on hyvä aloittaa hyvällä toimintaympäristön ymmärtämisellä ja riskianalyysin teolla. Riskianalyysin havaintojen perusteella voidaan priorisoida (ja vaatia palveluntarjoajalta) tärkeimmät tietoturvaa parantavat toimenpiteet, kuten laitteistojen kovennus (sovellukset, tietokannat, käyttöjärjestelmät, verkkolaitteet), kuormantasaukset, DDoS-suojaukset, päivitysten tekeminen, käyttöoikeuksien rajaukset (roolipohjaisesti, ei vaarallisia työyhdistelmiä), kolmannen osapuolen tekemät auditoinnit ja tunkeutumistestaukset. Tunkeutumisen ja tihutöiden estämisen lisäksi niiden aikainen havaitseminen on tärkeää ja siinä monitorointi ja SOC/SIEM-järjestelmien käyttöönotto ovat oleellisessa asemassa.

     

    10.     Non-Production Environment Exposure eli Kehitys- ja testausympäristöjen paljastuminen

    Julkisuudessakin on usein puitu tapauksia, joissa henkilötietoja tai muuta yritystoiminnan kannalta arkaluonteista tietoa on vuotanut tuotekehitys- tai testausympäristöjen kautta.

    Uhka: Luvaton pääsy luottamuksellisiin tietoihin Kehitys- ja testausympäristöissä, tietovuodot

    Tuotekehitys- ja testausympäristöjen sääntö numero yksi testausaineistojen kohdalla on aina ollut: tuotekehityksessä ja testauksessa ei käytetä tuotantodataa. Mikäli dataa pitää käyttää, arkaluonteiset ja luottamukselliset tiedot pitää anonymisoida. Edellisen lisäksi jo aikaisemmin mainitut tietoturvan hallintakeinot koskevat myös tuotekehitys- ja testausympäristöjä. Ympäristöt tulisi suunnitella noudattaen security ja privacy by design -periaatteita, kovennustoimet, pääsyoikeuksien rajaus ja monitorointi sekä muut hallintakeinot tulisi laajentaa koskemaan myös kehitysympäristöjä. Kaikkein arkaluonteisinta kehitystyötä ei tulisi viedä pilveen ollenkaan, vaan toteuttaa esimerkiksi Katakrin mukaisesti toteutetuissa suojatuissa ympäristöissä.

     

    Tietoturva-arvio ja OWASP Top-10 Cloud Security Risk

    Kolmiosaisen blogikirjoitukseni ensimmäisessä osassa käsittelin pilvipalveluiden aiheuttamia huolenaiheita yleisesti ja miten näihin huolenaiheisiin voi vastata tietoturva-arvion avulla. Tietoturva-arvion lopputuloksena syntyneessä dokumentissa ja/tai riskilistauksessa on paljon samoja elementtejä, kuin OWASP Top-10 Cloud Security Risk-listauksessa. Kirjoituksen osissa kaksi ja kolme lähestyinkin pilvipalveluiden uhkia kyseisen listauksen kautta, tarkoituksenani löytää perinteisistä tietoturvan hallintakeinoista keinoja, joilla vastata näihin riskeihin. Keinoja löytyikin varsin runsaasti ja voinkin lopuksi toistaa otsikon sanat ja todeta: Perinteiset tietoturvan hallintakeinot pätevät myös pilvessä.          

    Kirjoittaja

    Insta_Secrays_PetriVetikko

    Petri Vetikko

    LinkedIn