Felhőbiztonság – Az azonosítás dilemmája

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?
3. rész – Bróker, de nem a tőzsdén, mi az? 

Az előző részben feldobott betűszavak egyikével kezdem a mai írásomat: IdP, Identity Provider, azaz azonosság szolgáltató. Kinek szolgáltatunk azonosságot, miért és hogyan? Bár a felhős szolgáltatások nagy része képes azonosítani a felhasználót, általában korlátos eszközökkel és a vállalati felhasználók számára nagy limitációkkal. Gondoljunk csak a privát felhős azonosságainkra: mindenhol más-más a felhasználónév és jelszó, ha betartjuk az adathalászat ellenes ajánlásokat. Céges környezetben ez még fontosabb, így annak a lehetősége, hogy egyetlen azonosságot használjunk a felhő szolgáltatásainkban, rendkívül kecsegtető. Ha ez az azonosság ráadásul megegyezik az egyébként vállalati használatra úgyis szükséges címtárban (többnyire Active Directory) használttal, az még jobb volna. Az IdP egy olyan szolgáltatás, amely tipikusan a meglévő vállalati infrastruktúrán helyezkedik el, bekötve a címtár irányába és integrálva a felhő szolgáltatással. A felhasználók eredetileg a címtárban léteznek, ott vannak kezelve, nincs szükség az IdP-n egy másik felhasználói adatbázist kezelni. Az IdP beazonosítja a felhasználót (ennek módjairól később) és jelzi a szolgáltatásnak, hogy engedélyezett a kapcsolat. A szolgáltatás maga nem végez azonosítást.

Amikor azonosításról beszélünk az  IdP-nek több lehetősége is van, aszerint hogy mi a cél. Alap esetben beszélünk egy aktív azonosításról (Active authentication). Aktív annyit jelent, hogy a felhős szolgáltatás bekéri a felhasználótól az azonosításhoz a nevét és jelszavát, majd anélkül hogy azonosítani próbálná továbbküldi ezeket az IdP irányába. Az IdP elvégzi az azonosítást, jelzi a szolgáltatás felé a sikerességet és a felhasználó megkapja a kért erőforrást. Ebben az esetben a felhős szolgáltatás aktívan részt vesz az azonosításban, rajta keresztül megy minden felhasználói azonosításhoz szükséges adat. Mivel ez egy biztonsági kockázatot jelent, a legtöbb IdP már csak azoknál az alkalmazásoknál engedi az aktív azonosítást, ahol nincs más opció, és ott is érdemes a jelszóról  legalább a tanúsítvány alapú azonosításra áttérni.

A másik irány a passzív azonosítás (Passive authentication), mely során a felhő szolgáltatás nem kér be semmit a felhasználótól, hanem átirányítja őt az IdP bejelentkező felületére. Mivel az IdP-k esetén ez egy webes felület, ehhez a működéshez böngésző, vagy legalábbis böngészővel integrált alkalmazás szükséges a felhasználói oldalon. Az IdP bejelentkező felületén megtörténik az azonosítás (a felhasználói alkalmazástól függően ez lehet Kerberos, tanúsítvány vagy jelszó alapú), és ad egy “egyszer használatos” tokent, amivel a szolgáltatást el tudja érni a felhasználó. (A szolgáltatás integrálva van az IdP-vel, azaz az IdP által kiállított és érvényes token-eket elfogadja, abból ki tudja olvasni a felhasználó azonosságát és meg tudja feleltetni a saját adatbázisában tárolt felhasználói azonosságok egyikével – ez akár történhet valamilyen anonimizált módon is). Ezen a módon a felhő szolgáltatás passzív, nem vesz részt az azonosításban, sőt, nem is kell feltétlenül tudnia, ki a felhasználó.

A biztonsági elvárások miatt a passzív azonosítás elterjedőben van, ezért erre térnék ki még egy kicsit részletesebben. A passzív azonosítás alapja, amely meghatározza, hogy milyen módon cseréljen információt egymással az IdP és a szolgáltató, kezdetekben kizárólag a SAML (Security Assertion Markup Language) leíró nyelv volt, mostanra azonban az OAuth is elterjedt. A választott megoldás mellé szükséges egy azonosítási protokoll is, ami a SAML esetén a SAML2P vagy WS-Federate, OAuth esetén pedig az OpenID Connect lehet. Aktív azonosítást már csak azon alkalmazások esetén érdemes használni, melyek más lehetőséget nem adnak – például egy általános mobiltelefon esetén a beépített levelező alkalmazás csak ezt tudja használni. Kivétel ez alól az iOS, amely 10-es verzió fölött már megadja a lehetőséget a felhasználóknak a passzív azonosításra.

Tehát megvan az azonosítás, biztonságos, hiszen a saját infrastruktúránkból szolgáljuk ki azonossággal. Igen ám, de nem vizsgáltunk kontextust, az IdP nem figyeli, hogy ki és honnan jön, amíg tudja a jelszót. Ha kontextus alapú vizsgálatot szeretnénk bevezetni, akkor szükségünk lesz valamire, ami képes mélyebben belenyúlni az azonosításba és kontrollálni ezt a folyamatot. Szükségünk lesz egy CASB (Cloud Access Security Broker) megoldásra, de ez már a következő rész témája lesz.

2 című bejegyzés “Felhőbiztonság – Az azonosítás dilemmája” 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