Felhőbiztonság – Bróker, de nem a tőzsdén, mi az?

A felhőbiztonság sokakat foglalkoztat már évek óta, az IT üzemeltetés számára egy fontos eszköz kezdve az első felhőszolgáltatások megjelenésétől a mai mobil és felhőalapú munkavégzés támogatásáig. Ez az írás egy több részes sorozat része, az előző és következő részek hivatkozásaival folyamatosan bővítem ezt a bevezetőt.
1. rész – Miért van rá szükség?
2. rész – Az azonosítás dilemmája

A felhőbiztonsággal foglalkozó sorozatom előző két részében a technológia körüli információkból azokat próbáltam összegyűjteni, melyek a témában jártasabbak számára nem nyújtottak újdonságot – ez a mai résszel már változik. Az írás témája a Cloud Access Security Broker, azaz CASB megoldások bemutatása és szükségességük tárgyalása lesz.

Onnan folytatom, ahol múlt héten befejeztem: megvan az azonosítás, és biztonságos, hiszen a saját infrastruktúránkból szolgáljuk ki egy Identity Provider megoldással. De vajon tényleg biztonságos? Ehhez szükséges a hozzáférés vezérlés, melyet a legtöbb CASB szolgáltatás már biztosítani képes. Egy felhasználónév-jelszó pároson alapuló azonosítás eredendően nem biztonságos, hiszen egy olyan információ, amit “tudok”. A szaknyelvben ezt egy faktoros azonosításnak hívjuk, ezzel ellentétben vannak a többfaktoros azonosítások, amikor a “tudok” mellé kerül egy “rendelkezek vele” vagy “vagyok”. Ha tehát biztonságosabbá akarjuk tenni az azonosítást, vonjunk be egy második faktort. Erre rendkívül jó lehetőséget adnak az okostelefonok, hiszen mindenki rendelkezik vele, ráadásul a legtöbb okostelefon biometrikus azonosítással is rendelkezik már, ezért aztán akár mindhárom faktort is be tudjuk vetni az azonosításnál. A felhőszolgáltatásba belépéshez megadjuk a jelszavunkat, ezután kapunk egy értesítést a telefonunkra, hogy hagyjuk jóvá a bejelentkezést, amit csak akkor tudunk megtenni, ha feloldottuk a telefon képernyőzárát. Ha egyszerűsíteni akarjuk, a jelszavat el is hagyhatjuk – ehhez szükséges, hogy a telefon egy vállalati mobilbiztonsági megoldással (UEM – Unified Endpoint Management) menedzselt legyen, hogy a maradék két faktor erősségét biztosítani tudjuk.

Ha az azonosítás így már teljes, mi maradt még a felhőbiztonságból? Ahogy azt az első írásomban összefoglaltam, adatvédelem, végpontvédelem, azonosítás és hozzáférés vezérlés szükséges. A végpontvédelemre az UEM megoldás, azonosításra az IdP, a hozzáférés vezérlésre a CASB, de mi van az adatvédelemmel? A válasz szerencsére erre már megvan, ugyanis az UEM a végpontokon tárolt adatok biztonságát (végpont titkosítással), a CASB pedig a felhőben tárolt adatok biztonságát (titkosítással és DLP szabályzattal) tudja kezelni. A legtöbb CASB négy féle módon tudja védeni a felhőszolgáltatásunkat:

  1. Passzív naplógyűjtés segítségével
  2. API bekötéssel
  3. Reverse Proxy módon
  4. Forward Proxy módon

A négy esetet egyenként érdemes végignézni, előnyeivel és hátrányaival. A passzív naplógyűjtés azért lehet jó, mert a felhasználók által használt nem engedélyezett felhőszolgáltatásokat a tűzfalaink és internetes proxy-jaink naplófájljaiból ki lehet elemezni és egy “shadow IT” reportot készíthet a CASB, mellyel a későbbi mélyebb integrációt lehet üzletileg támogatni. Ez szokott lenni tipikusan az első lépése egy CASB bevezetésének, mivel  egyszerű és nagy üzleti értéket teremt az információbiztonsági csoport számára.

Az API bekötés elengedhetetlen ahhoz, hogy a felhőben tárolt adatokat biztosítsuk. Mivel ez csak akkor lehetséges, ha a felhőszolgáltatás rendelkezik megfelelő API-val (és le is van dokumentálva), minden CASB szolgáltató rendelkezik egy többé-kevésbé egyező listával a támogatott felhőszolgáltatásokról. Ezek esetén is megoszlik a képességek skálája, de a legtöbb felhőszolgáltatás esetében a feltöltött fájlokra tudunk DLP szabályzatot alkalmazni, riasztást és akár  blokkolást generálni ha nem megfelelő a feltöltött tartalom. A fejlettebb CASB szolgáltatások esetén ez be van kötve legalább egy anti-vírus adatbázisba, jobb esetben egy sandboxing/ATP-szűrő megoldásba is, hogy ne kerüljön fel káros állomány a felhőbe (és ezáltal akár felhasználóink százainak számítógépére és okostelefonjára). Az API használatának nagy előnye az, hogy a háttérben passzív módon történik, a felhasználó számára teljesen transzparens, nem ad további késleltetést a szolgáltatás eléréséhez. Az API bekötés tehát eléggé erős képességeket ad, tipikusan a passzív naplóelemzés mellett a legelső CASB implementációs mód, azonban az előnye egyben limitációja is: mivel a forgalomba nem áll bele, nem tudja azonnal megakadályozni az adatszivárgást vagy veszélyes állományok feltöltését, csupán az esemény után pár perccel (a legjobb esetben 20-30 másodperccel). Továbbá amennyiben egy CASB csak API kapcsolatra képes, nem tudja a fent taglalt hozzáférés vezérlést sem végrehajtani.

Fentiekhez nyújt megoldást a reverse proxy felépítés. Ennek lényege, hogy a CASB saját magán áthajtja a forgalmat – egyes esetekben csak az azonosítást, de akár az egész felhő felé menő forgalomba is beállhat. A hozzáférés vezérlés az egyik nagy előnye ennek a felállásnak, a másik pedig, hogy a beállított DLP szabályok szerint akár azonnal el tudja “kapni” a veszélyes vagy szabályellenes megosztásokat. A reverse proxy illesztése egy nehézkes és nagyobb rizikóval járó feladat, késleltetést adhat a rendszerbe, valamint az egyes felhőszolgáltatások verzióváltásakor problémát okozhat, ezért amennyiben nem kifejezetten szükségesek az általa adott előnyök, meg kell fontolni használatát. Tipikusan a passzív naplóelemzés és API bekötés után szokták a vállalatok fontolóra venni a bevezetését.

Végül a forward proxy felállás ahhoz szükséges, hogy a vállalat teljes felhőirányú forgalmát vizsgálni lehessen és az esetleges shadow IT működését fel tudjuk tárni. Ez azt jelenti, hogy vagy a CASB egy komponense áll be hagyományos internetes proxy-ként az ügyfél hálózatába, vagy a már meglévő proxy és tűzfal megoldásunkkal integráljuk. Az így begyűjtött adatok alapján a CASB a shadow IT-ként használt szolgáltatásokat blokkolni tudja, a felhasználókat a vállalat által elfogadott megoldások irányába terelve. Több megoldás esetén előnyt jelenthet itt az, ha a CASB megoldás és a céges tűzfalak azonos gyártótól vannak, mélyebb integrációt ígérve. A forward proxy megoldás jellemzően az utolsó a CASB funkciók közül, mivel a hozzáadott értéke relatív alacsony a bele fektetendő energia és velejáró kockázat mellett.

2 című bejegyzés “Felhőbiztonság – Bróker, de nem a tőzsdén, mi az?” gondolatot, hozzászólást tartalmaz

Vélemény, hozzászólás?

Adatok megadása vagy bejelentkezés valamelyik ikonnal:

WordPress.com Logo

Hozzászólhat a WordPress.com felhasználói fiók használatával. Kilépés /  Módosítás )

Google kép

Hozzászólhat a Google felhasználói fiók használatával. Kilépés /  Módosítás )

Twitter kép

Hozzászólhat a Twitter felhasználói fiók használatával. Kilépés /  Módosítás )

Facebook kép

Hozzászólhat a Facebook felhasználói fiók használatával. Kilépés /  Módosítás )

Kapcsolódás: %s