Az RSA Security cég gyártja a hálózati azonosítás, a sérülékenység-menedzsment, a GRC, a SecOps, és a malware analízis alapvető megoldásait.A legutóbbi tájékoztatón saját multifaktoros autentikációs megoldásuk, az RSA SecurID Access volt terítéken. A termékről és alkalmazási példáiról Soós Zoltán, az RSA magyarországi képviseletét ellátó Arrow ECS Kft. IT Security Product Managere tartott előadást november 13-án.
https://www.arrowecs.hu/cegunkrol/munkatarsaink/munkatarsaink.cfm
Elhangzott, a különálló RSA Authentication Manager és az RSA Via Access összevonása után számos újdonság vált elérhetővé a termékcsaládon belül, használatával a vállalati igényeknek legmegfelelőbb azonosítási rendszer alakítható ki.
Alapvetően, az RSA SecurID Access on-premise biztonságos és kényelmes hozzáférést nyújt software as a service (SaaS) megoldásokhoz, https://hu.wikipedia.org/wiki/Saas
felhő alapú, mobil és webes alkalmazásokhoz, bármikor, bárhonnan, bármilyen eszközről.
https://en.wikipedia.org/wiki/On-premises_software
A megoldás nem csak kétfaktoros rendszerrel, de akár access management (hozzáférés-kezelés) opcióval is rendelkezik, mellyel kockázatelemző, dinamikus szabályok hozhatók létre.
https://en.wikipedia.org/wiki/Access_management
Az RSA megoldások vezér-motívumai:
hackerek által okozott károk,
autentikációval kapcsolatos nehézségek, problémák,
azonosítási alapelvek.
Az előadó áttekintette az RSA SecurID Access működési elvét, s a bevezetett újdonságokat;
license csomagok és opciók,
a termék fejlesztésének várható jövőbeli irányai,
kipróbálási lehetőségek.
Mit mutat az IT biztonsági statisztika?
Az IT támadások mintegy 64 %-a köthető közvetlenül a levelezéshez ( www.hackmageddon.com ),
94,2 %-a email kezeléshez (www.verizon.com ).
A vállalatok 76 %-a észlelt phishing támadást 2017-ben (www.barkly.com ), 2017 végén egy felhasználó átlagosan havi 16 phishing levelet kapott
A támadáshoz leggyakrabban használt file formátumok( www.cisco.com ) :
office dokumentumok 38 %
archive 37 %
pdf 14 %
Globálisan a hacker-ek „bekerülési költsége”, az általuk okozott veszteség a világ éves GDPjének 1,29%-a (10 évvel ezelőtt 0,8%), ez kb. 800 milliárd amerikai dollárt jelent, ami Magyarország 63-havi GDP-jének felel meg.
A hagyományos IT control ma már nem elegendő, nehéz megvédeni az online felhasználói adatokat, s nehéz meghatározni a védendő határokat.
Hogyan kezeljük a harmadik félként fellépők alkalmazásait, hogyan kapjanak hozzáférést a külsősök, az ideiglenes munkavállalók (pl. külső fejlesztők),
az ismeretlen eszközök, a nem ellenőrizhető hozzáférési pontok, cloud vagy hosted alkalmazások, vállalkozók, partnerek, ügyfelek, s milyen gyakorisággal történjen vizsgálatuk?
Hogyan kezeljük az egyedi azonosítókat, az egyedi felhasználókat a különböző rendszerekben?
Hogyan lehet növelni a jelszavakhoz kapcsolódó biztonsági szintet?
A kézben hordott végpontok kezelésének akkor is helyt kell állania, ha nincsenek körülötte tűzfalak és IPS megoldások. Úgy kell működnie, mintha mindig fel akarná törni valaki.
A manuális folyamatok, eljárások bonyolítják az átmeneti időszakot, csökkenhet a biztonság szintje. A támadások 81,9%-a néhány perc alatt sikert arat,
67,8%-uk esetén az adatok egyetlen napon belül kikerülnek a szervezetből. Az adatlopások 63%-a egy lopott jelszóval kezdődik. A saját hálózaton belül gyakran később vesszük észre a támadást, mint az akció netes következményeit, leiratát... (Verizon Data Breach Investigation Report, 2016.)
Milyen módon kezelhetők a gondok?
A Compliance (megfelelőség) biztosítására az RSA ajánlásai:
PCI – kártyaadatokhoz hozzáférő felhasználóknak kötelező legyen a 2FA (kétfaktoros azonosítás),
https://www.pcisecuritystandards.org
A követelménynek az RSA eleget tesz; az ISO előírások kétfaktoros részének megfelelő lefedést a cég képes biztosítani.
(https://www.iso.org/home.html )
https://en.wikipedia.org/wiki/Multi-factor_authentication , https://en.wikipedia.org/wiki/Principal_component_analysis
FIPS – a token-ekhez elérhető a certificate
https://en.wikipedia.org/wiki/Federal_Information_Processing_Standards
https://hu.wikipedia.org/wiki/Token (egyértelműsítő_lap) ,
GDPR alapelvek követése:
- május 26-án lépett érvénybe az európai adatvédelmi szabvány, amely a 250 felhasználónál nagyobb, évi 5 ezernél több ügyféladatot kezelő cégekre vonatkozik.
Megsértése esetén (hanyag kezelés-, vagy erőforrás-hiány miatt) a büntetés a globális bevétel 4%-a, vagy 20 millió euro is lehet.
A biztonsági incidenseket az észlelést követő 72 órán belül, a személyes adatok elvesztését azonnal jelenteni kell.
Az EU-s állampolgárok adatait mindenhol ugyanazon feltételekkel kell kezelni (akár az USA-ban is).
A GDPR-al kapcsolatos hatósági javaslatok:
User Access Control – felhasználói hozzáférés-kezelés (Windows) alkalmazandó
Nem lehet olyan adminisztrátor, aki minden adathoz hozzáfér
Külön adminisztrátori fiókokat kell alkalmazni
Használjunk komplex jelszavakat és beállított lejárati időket
Ne legyenek újrahasználható jelszavak
Távoli munkavégzéshez legyen kötelező a 2FA
Biztonságos WiFi működjön
Szűrjük a webes forgalmat
Szem előtt tartandó:
A személyazonosság-lopás az egyik legelterjedtebb támadási forma, melyek során a cloud, mobil, social network alapú támadások a leggyakoribbak.
Mivel a felhő alapú alkalmazások egyre inkább terjednek (Office365, GoogleDrive, OneDrive, stb.), vállalaton belüli letiltásuk nem lehet megoldás a biztonsági kockázatokra, szabályozni kell használatukat. Az elismert támadások 63%-a egy gyenge, alapértelmezett, vagy lopott jelszóval kezdődik. Korábban minden kritikus alkalmazáshoz kötelező volt külön, rövid időn belül megújított jelszót alkalmazni. Természetesen, a felhasználók ezt nem tudták mind megjegyezni, le kellett maguknak írni egy papírra…
Ma az új trend; legyen erős a jelszó, de lehessen újra használni és azt az egy jelszót több alkalmazásnál is lehessen alkalmazni. Ennek vannak előnyei és hátrányai.A hackerek egy-egy feltört Facebook fiókban talált jelszóval rögtön megpróbálkoznak számos másik alkalmazásba is beférkőzni. Néha működik, néha nem. Jó megoldás lehet, ha ezt a jelszavas módit kiegészítjük valamilyen másik, második faktorral, így nagyobb biztonságban lehet a felhasználó. A hitelesítéssel kapcsolatos jelszó-problémák:
a jelszavak ellophatók, keylogger-el felvehetők, ( https://searchsecurity.techtarget.com/definition/keylogger )
a felhasználók leírják a jelszavakat, megosztják egymással,
a könnyű jelszavak kitalálhatók,
a jelszavak újrahasznosíthatók,
feltörhetők.
A hitelesítés költséggel jár; a jelszavaknak, jelszóváltásnak, az elfeledett jelszavak feloldásának is ára van (Gartner Group tanulmány szerint 20% és 50% közé tehető a password reset kérelmek száma az összes Helpdesk hívást nézve), Nyugat-Európában egy password reset „ára” 70 USD, automatikus password reset alkalmazás ára 50 ezer USD körül indul.
Cloud és BYOD problémák:
(www.shiwaforce.com/mi-az-a-byod/ )
A cloud alkalmazások (Office365, stb.) szigetszerű „identitás-menedzsment” rendszereket jelentenek.Ezek a sziget-megoldások megnehezítik a központi menedzsmentet (nincs közös konzol, riportok, kockázatkezelés), ezért szükség van a különálló identitás-menedzsment rendszerek menedzselésére. Ehhez az elérést biztonságossá kell tenni. Tisztázandó; ki alkalmazza, és ki hagyta jóvá? Alapból nem lehetséges egyetlen menedzsment-rendszer használata, meg kell keresni az egész terület lefedésére alkalmas eszközt. Rendszeresen ellenőrizni kell a felhasználói jogosultságokat.A mobil felhasználók igénylik, hogy bármikor dolgozhassanak bármilyen saját mobil eszközükről is, s bárhonnan elérhessék a céges alkalmazásokat. A probléma kezelésekor a biztonság igényeit kell illeszteni a cég produktivitási igényeihez. Nem abszolutizálható a biztonság. Ismert szlogen; „a biztonságot a használhatatlanságig lehet fokozni...”. Betarthatatlan szabályok esetén a felhasználók megtalálják a könnyebb utat…Ellenérdekeltek a felhasználók és az IT biztonsági osztályok. A felhasználók a legegyszerűbb módon akarnak belépni minden alkalmazásba, a CIO/CISO pedig minél erősebb jelszó-policyt szeretne...
A gondokra a kétfaktoros azonosítás a megoldás, melynek alapszavai:
identification (azonosítás) - “Vagyok, aki vagyok”
autentication (hitelesítés) - “Így tudom igazolni magam”
authorization (engedélyezés) - “Ezekre van jogom”
accounting (riportok) - “Ezeket a tevékenységeket végeztem”
A kétfaktoros azonosítás:
“Egy olyan hitelesítési procedúra, ahol a felhasználó három módszer valamely kombinációjával azonosítja magát” :
Összetevői:
“Valamit tud” = PIN-kód, jelszó, vagy security question (ami a tokenen megjelenik),
https://hu.wikipedia.org/wiki/Token_(egyértelműsítő_lap) ,
“Valamivel rendelkezik” = egy Token, Smartcard, vagy Trusted Device, ill. mostanában a token egyre inkább mobil telefont jelent, amelyen megjelenik az
- szoftver token, ugyanazon funkcionalitással,
( https://en.wikipedia.org/wiki/Security_token ), ( https://www.rsa.com/content/dam/en/data-sheet/rsa-securid-hardware-tokens.pdf )
valamint;
“Valamilyen biometrikus azonosítója is van” = ujjlenyomat, retina, stb.Az RSA termékei, a hardver token felől elmozdulva, az összes fenti funkciót igyekeznek összesíteni, mindegyiket tudják támogatni.A mobiltelefonok többsége képes ujjlenyomatot, vagy arc-felismerést használni azonosításra, ezt a beépített modult használhatjuk pl. Office365 ellenőrzésre.
Kockázatelemzésen alapuló azonosításról van szó, amelynél több száz alkalmazás, akár onpremise, akár cloud alkalmazásokhoz férhet hozzá.Nagyon fontos; hogyan tudom azt igazolni, hogy az vagyok, akinek mondom magam.Korábban a munkatárs leült a munkaállomása elé, megpróbálta az adott webes alkalmazást a hálózaton belülről elérni, jelszóval azonosította magát és létrejött az elérés.Ez a felállás mára borult; van számos projekt-alapú munkatárs, vannak külsős munkatársak, vannak vállalkozók, mindannyiuknak szükségük van az adott hálózathoz való hozzáférésre. Mindamellett, amikor az adott projekt befejeződött, vagy az adott vállalkozó már nem bedolgozója a cégnek, akkor ezeket a jogosultságokat valahogy vissza kell vonni.
Az eddigi működésben jól meg lehetett határozni, hogy honnan léphet be a felhasználó, ma viszont bármely eszközről megpróbálhatja ezt. Eddig előírható volt, hogy az irodán belülről dolgozzon, vagy VPN-ről (Virtual Private Network), de cloud használatakor már ez sem helytálló; nehezen lehetne arra szorítani a felhasználókat, hogy az Office365-öt ne használják közvetlenül otthonról, hanem a céges hálózatról, vagy a számára biztosított céges gépről. Ezideig, ha RSA tokenről, vagy kétfaktoros azonosításról esett szó, akkor az on premise azonosításokat lehetett elérni. A kétfaktoros azonosítás működéséhez elengedhetetlen volt, hogy az alkalmazás, amit a felhasználó el akar érni, (pl. Sharepoint, Oracle, SAP vagy a CA), az a hálózaton belül legyen és onnan lehessen adminisztrálni, így az azonosítási kéréseket át lehetett irányítani a saját fejlesztő-felületre.
A bevezetett változtatások után a trau alkalmazások is jól alkalmazhatók a jövőben. Az RSA megegyezett a Salesforce-al, a Microsoft-al, a Google-al, és egyéb gyártókkal, hogy azonosítási módszereik közé vegyék fel az RSA megoldását.
https://en.wikipedia.org/wiki/TRAU
https://en.wikipedia.org/wiki/Salesforce.com
Mit jelent mindez a felhasználónak?
Amikor otthon a saját gépéről valaki közvetlenül be akart lépni pl. az Office365-be, eddig beírta a felhasználónevét, jelszavát, s ettől kezdve működött a dolog. Az RSA a partner cégekkel történt megállapodásaival elérte, hogy azok az ügyfeleit, akik Office365-öt és az RSA-t is használják, a megfelelő domén (euró.com) beírása után a Microsoft automatikusan irányítsa vissza a megfelelő RSA portálra. Ily módon, a felhasználó nem tud belépni közvetlenül az Office365 felületére, hanem elirányítják az RSA felületére és ha ott sikerült az azonosítás, akkor érheti el az Office365-öt.
A megoldás előnye:mindegy, hogy milyen eszközről próbálja a felhasználó ezt a felületet elérni, az azonosítási kérelem látható lesz, azt szabályozni és menedzselni lehet. Továbbá; lehetőség nyílik különböző kockázati szintek beállítására, pl. ha munkaidőben céges laptopról a céges hálózaton belül teszi mindezt, akkor legyen elég a felhasználói név és jelszó, de ha éjjel kettőkor Kínából egy tabletről próbálja ugyanezt, akkor kérjünk tőle egy ujjlenyomatot és írisz-azonosítást is.
A fentieken kívül az RSA alkalmaz egy plusz kényelmi szintet; ez a Single Sign-On (SSO), ami központi menedzsmenttel nyújt biztonságos hozzáférést jelent.
https://en.wikipedia.org/wiki/Single_sign-on
Az eljárás menete:
A központi azonosítási megoldás során az adott felhasználó már azonosította magát, mert pl. az Office365-öt akarja elérni. Sikerrel járt, s már ismerjük paramétereit, amikor megpróbálja elérni a Word-ot. Az előzmények ismeretében felesleges lenne újra kérni tőle a felhasználói jelszót, s egyebeket, megoldja ezt az RSA.
A megoldás lehet teljesen automatikus; azaz, ha egyszer azonosította magát, akkor a világ összes, ismert cloud vagy onpremise alkalmazásához legyen hozzáférése, vagy manuális, amikor különböző kockázati szinteket rendelhetünk a különböző alkalmazásokhoz. Ezt úgy is megadhatjuk, hogy az azonos, vagy alacsonyabb kockázati szintű alkalmazásokhoz automatikusan bejuthasson, a magasabb kockázati szinthez viszont további azonosítást is rendelhetünk.
Pl., tekinthetjük az Office 365-öt alacsony kockázati szintnek, ehhez az egyszerűbb belépést lehet rendelni, a Salesforce pedig a magasabb kockázat szerint kezelhető, s nem engedjük a felhasználót automatikusan belépni rá az Office 365-ből, hanem pl. kérünk egy ujjlenyomat-olvasást is. Ezt nevezik step-up autentikációnak, ami végbemehet teljesen automatikusan, vagy manuálisan, testre szabva. Az RSA már nem csak hardver-, hanem szoftver tokeneket is készít a mobil telefonokon, ill. a laptopokon futó alkalmazásokhoz. Ehhez kapcsolódóan, az RSA-nál vallják, vállalatuk rendelkezik a legnagyobb harmadik-fél (third-party) támogatással; a kétfaktoros azonosítást kereső ügyfelek a piacon sok gyártóval találkozhatnak, közöttük az RSA nem a legolcsóbb, de a támogatást tekintve a vevő jól jár a céggel. Amennyiben a vevőnek pl. van 15-fajta alkalmazása és valamilyen rugalmas támogatást szeretne, akkor az RSA megoldása van előnyben.
Figyelemre méltó, hogy az RSA webhelyén kiválóan szerkesztett dokumentum szolgálja az ügyfeleket úgy az RSA-beállítások, mint az alkalmazás-oldali beállítások részletes leírásával.
Hogyan alakul az RSA jelenlegi termékkínálata?
A fent vázolt folyamat során, a 2-3 évvel korábban két különálló termékként funkcionáló RSA SecureID, (másnéven RSA Authentication Manager), és az RSA Via Access összevonásával, először SecurID néven, ma pedig RSA SecurID Access néven alakított ki új terméket a cég. Az összevonást a felhasználók nem, vagy csekély mértékben érzékelték, plusz költséget nem jelentett számukra, a licencek érvényessége nem változott, a funkcionalitás viszont sokkal nagyobb lett.
A korábbi működés:
A SecureID felállásban volt az RSA-nak egy központi szervere, az Authentication Manager, (ez lehetett fizikai, vagy virtuális privacy), ez volt a kétfaktoros azonosítás menedzser platformja. Ebből legalább egy volt alkalmazásban, ezt nevezték Primary-nek, de a hibatűrés miatt többet is alkalmazhattak. Mindegyik ugyanazt az adatbázist tartalmazta, itt voltak definiálva a felhasználók, vagy csoportok, s az, hogy milyen azonosítási lépések sorozata szükséges az egyes alkalmazások eléréséhez. Szabályrendszerek voltak felsorolva, s lehetett tudni, hogy pl. egy terminál szerver eléréshez egy adott felhasználónak van-e jogosultsága, ill., hogy milyen azonosítási lépésekre van szükség az eléréshez.Ehhez a működéshez szükség volt a belső hálózatban alkalmazás szerverekre, amelyeket a felhasználó pl. VPN használatra érhetett el, vagy ha el akarta érni a belső web-szervert, ill. a terminál szervert. Ezt csak akkor tudta biztosítani az RSA megoldása, ha az adott alkalmazás támogatta az RSA saját kétfaktoros azonosítási megoldását. Amennyiben pl. a VPN-re szeretett volna az adott felhasználó bejutni, akkor ezt az azonosítási kérést el kellett juttatni az Authentication Manager felé. A felhasználót az Authentication Manager azonosította, ezt hívjuk agent-nek minden alkalmazás szervernél. Voltak továbbá a felhasználók, akiknek mobiltelefon hardver tokenjeik, vagy mobil telefon tokenjeik voltak, ezt hívjuk autenticater-nek.Ezek az összetevők biztosították az adott RSA SecureID megoldás működését.
Az RSA-nál zajló fejlesztések során az elmúlt évben a fenti megoldás kibővült a SecureID Access-el (korábbi nevén ViaAccess). A többletet az RSA által üzemeltetett trau szolgáltatás jelenti. A felhasználók megvásárolnak, vagy licencükhöz kapcsolódóan kapnak egy URL-t, amelyen az adminisztrátorok be tudnak lépni és ugyanolyan, vagy a fentiekhez hasonló szabályrendszereket tudnak beállítani, de nem az onpremise megoldásokra, hanem a felhőben levőkre, pl. az Office365-re, vagy SalesForce-ra. Tehát van két külön kétfaktoros azonosításunk, s a kettőt még össze is tudjuk kötni egy Linuxos szerveren, amelyen fut egy Linuxos web-szerver, erre lép be az adott felhasználó.Bármely alkalmazás eléréséhez, bármely felhasználónak, csak ezt az egy URL-t kell ismernie. Ez a szerver dönt arról, hogy az azonosítási kérés hova kerüljön; ha a felhasználó egy terminál szervert szeretne elérni, akkor az Autentication Manager felé küldi a kérést, ha pl. az Office365-öt szeretné elérni, akkor a Cloud Service felé.A felhasználó dolga is egyszerűsödött; ezen a portálon listázhatja magának, hogy milyen alkalmazáshoz van joga, kiválasztja, rákattint és már be is léphet a választott alkalmazásba. A Single Sign-On biztosítja, ha egyszer már azonosította magát, akkor minden további alkalmazáshoz automatikusan, újabb azonosítás nélkül férhessen hozzá.
A rendszer telepítése időt igényel, akár egy hetet is, de nem a telepítendő komponensek száma, hanem a sok beállítás miatt.
Szükséges hozzá
certificate,
DNS módosítás és
egy sor nyitott tűzfal-port a komponensek kommunikációjához.
A beállítás teljeskörű leírása rendelkezésre áll az RSA-nál, bonyolult, de nagyon rugalmas, szinte bármit be lehet állítani. Próbafuttatásra is elérhető minden változat, kipróbálható, hogy adott felállásra melyik azonosítási komponens és beállítás a legkedvezőbb, nincs „zsákba macska”. Hibrid megközelítés esetén van egy belső hálózatunk és egy cloud szolgáltatásunk is, amit ugyan az RSA nyújt, de ez továbbra is egy cloudban fut.
Eddig csak az onpremise alkalmazásokra lehetett két-, vagy többfaktoros azonosítást kikényszeríteni. Felmerülhet a kérdés, milyen adatok kerülnek ki a felhőbe és a jelszavak kikerülnek-e?
A válasz; a felhőben nem tárolunk jelszavakat. Amennyiben ezt a komponenst egy hacker fel is töri, még a lokális felhasználókhoz sem tud hozzáférni, csak egy ActiveDirectory kapcsolatot tud lekérdezni. Amennyiben sikerül teljesen feltörnie ezt a cloud szolgáltatást, akkor is csak annyit tudhat meg, hogy egy adott felhasználó létezik-e, de a jelszavát nem tudja lekérdezni. Ez az RSA megoldás azon ügyfelek számára is teljesen elfogadható, akik a cloudtól irtóznak. A magyar előírások nagyon szigorúak és a pénzügyi intézetek nagyon sok mindent nem tehetnek közszemlére, de itt a cloud szolgáltatásba nem kerülnek ki érzékeny adatok.
Mit támogat az RSA?
Az RSA mindig is híres volt rendkívül zárt rendszeréről. Csak azokat a tokeneket lehetett használni, amit maga bocsátott ki, és csak azokat a szoftver-tokeneket, amiket maga igazolt. Nem volt ujjlenyomat olvasás, írisz olvasás, vagy egyéb kiegészítő lehetőség. Ehhez képest nagy változást jelent, hogy a cég felismerte, token gyártásból nem lehet megélni. Nem tartható, hogy egy létrehozott zárt rendszerben csak az RSA tokenjeinek használata legyen engedélyezve. A követendő megoldást a szolgáltatásokból eredő nyereség nyújtja, nem pedig a hardwer-eladásból. Az online password hardwer-szoftver tokent továbbra is meg lehet vásárolni és használni. Amennyiben egy adott eszköz támogatja az ujjlenyomat-alapú azonosítást, akkor az is használható. A hardwer token is használható továbbra is.
A push notification lehetőség arról szól, hogy amikor egy felhasználónak nincs se hardwer, se szoftver tokenje. Azonosítását akkor is megoldhatjuk egy számára küldött e-mail, vagy sms üzenettel, amiben elhelyezünk egy egyszer használatos (one-time) jelszót, ezt kell beírnia a megfelelő alkalmazás eléréséhez.
https://www.lifewire.com/what-is-push-notification-1994351
Írisz támogatású azonosítás telepítése előtt meg kell győződni róla, hogy az alkalmazottaknak ajánlott eszköz támogatja-e azt (a Google nem minden esetben ad támogatást).
Az RSA megnyitotta az utat a harmadik fél által gyártott tokenek felé; a független FIDO cég által elismert, azonosított tokeneket elfogadja, használatukat támogatja rendszerében.
Az RSA teljeskörű megoldás keretében kockázat-elemzést is biztosít, amely alkalmas az on-premise vagy traud alkalmazásokhoz is, s a single-sine-al a felhasználók kényelmét is biztosítja.Ezt a teljes megoldás halmazt nevezzük RSA Security Accessnek.
https://hajekj.net/2017/02/27/to-single-sign-out-or-not-to/
A megoldás összetevői:
menedzsment platform
az azonosítási kéréseket kezelő agent-ek (webszerver, tűzfal, stb.)
autentikátorok
SIEM router appliance (a cloud elérések kezelésére)
Egy klasszikus azonosítás menete a gyakorlatban:
A felhasználó rendelkezésére áll egy hardver vagy szoftver token, ami támogatja az RSA megoldásokat. Ezzel megpróbál elérni a belső hálózatában egy alkalmazást. Az eléréshez van egy manager és egy agent, ezek továbbítják a felhasználói azonosítási kéréseket a fent ismertetett managerhez, amely eldönti, hogy az adott felhasználói azonosítás sikeres-e, ha sikeres, akkor továbbengedi a belső hálózatra. Ez az egyszerű on-premise megoldás.
A gyakorlatban, egy SecureID tokennel a művelet elején, a művelet provision részénél nem szüksége közvetlenül csatlakozni a managerhez, vagy közel állni hozzá. Az algoritmus mindig ugyanaz, az időt pedig hozzávetőleg be tudjuk azonosra lőni; meg kell adni két, egymást követő one-time password-öt, akkor tudni fogja a manager, hogy éppen hol tart a token. Meg kell adnunk egy seed recordot, hogy a manager elfogadja ezt a tokent. A seed record (átmenő jelszó) azt a jelszót jelenti, amelyet korábban megadtunk, hogy a manager elfogadja ezt a tokent a saját hálózatunkban való működésre. Amennyiben ez a hármas követelmény teljesül, akkor a tokenek működnek. A több telephellyel rendelkező ügyfelek körében használatos megoldás, hogy a cég a megvásárolt, pl. ezer darab tokent nem a központi telephelyére kéri, hanem szétosztva az egyes vidéki telephelyekre, s a fenti megoldással a felhasználók onnan tudják használni, nincs szükség előtte provision megoldásra. Ezzel csökkenthetők a bevezetési költségek.
Az RSA harmadik-fél támogatását jellemző kategoriák
- nativ
amikor pl. egy Cisco VPN-t szeretne valamely cég használni, s mögé RSA kétfaktoros azonosítási módszert szeretne bevezetni, semmi változtatást nem kell eszközölnie, a Cisco alapértelmezetten tudja ezt. Csak be kell kapcsolni az RSA kétfaktoros azonosítást rajta, ezt fogja kérni a felhasználóktól. Ingyenes.
- letölthető
- az IS szerver egyik változata ezt nem tudta, le lehetett hozza tolteni az agentet, ingyenes volt.
Akkor sincs gond, ha Radius (Remote Authentication Dial-In User Service) képes megoldásról van szó, az RSA Authentication Meneger tud Radius szerverként is viselkedni, a Radius kereséseket is el tudja fogadni. Ez is ingyenes.
https://en.wikipedia.org/wiki/RADIUS
A támogatott cégkapcsolatok listája elérhető az RSA weboldalán, az illető által nyújtott megoldások támogatási javaslatával együtt.
Ezen az oldalon betűrendben lehet gyártóra, termékre keresni, ahol láthatjuk, hogy mi mivel kompatibilis, és mindkét oldal szükséges beállításait. Mintegy 800 gyártó 1.200 termékéről van szó. Nagy segítséget jelent, hogy 15 perc alatt megállapítható, vajon az ügyfél által nyújtott megoldások támogathatók-e az RSA kétfaktoros azonosításával.
Az Identity Router az a virtual appliance, ami összeköti a cloud alapú azonosítási részt az on-premis alapú azonosítási résszel, megoldja szinkronizációjukat.Megoldja, hogy melyik felhasználó melyik részben található meg. Biztosítja, hogy amennyiben egy felhasználó már azonosította magát egy felhasználásban, akkor single-sine-on segítségével egy másik alkalmazáshoz is hozzáférjen mindenféle plusz azonosítási kérés nélkül. Az RSA jól teljesít az SAML (Security Assertion Markup Language) kezelésében, ha ezt tudja egy adott alkalmazás, akkor az egyszerűen importálható és negyedóra alatt használhatóan beilleszthető. https://en.wikipedia.org/wiki/Security_Assertion_Markup_Language
Az Identity Router skálázható, load-balansz illesztése beállítható, a single point of failer (SPOF) itt sem okozhat gondot, megoldható, hogy ebből is több nod álljon rendelkezesre.
https://en.wikipedia.org/wiki/Single_point_of_failure
Amennyiben egy felhasználó egy belső erőforrást akar elérni, de az Autentication Manager nem ismeri őt fel, mert nem a megfelelő felületen keresztül közelíti az alkalmazást, akkor sincs gond, mert az Autentication Manager és az RSL Cloud szolgáltatását össze lehet szinkronizálni, s némi kerülőúttal a felhasználó számára hozzáférést biztosíthatunk a belső erőforráshoz.
Egy adott vállalatnak nem csak egy Autentication Managere, több telephelye is lehet, cloud szolgáltatásból is vásárolhat többet. Amennyiben van 20 cloud szolgáltatása és 20 Identity Managere, akkor mindegyik összeköthető mindegyikkel, s más, hasonlóan bonyolult rendszerek is összerakhatóak. Az Identity Routerben három összetevő található, egy SSO-t (single-sine-on) megvalósító portál, egy Radius szerver és egy Connector, amely az on-premise és a felhő közötti szinkronizációt valósítja meg. Az on-premise megoldást adó RSA Autentication Manager is elérhető fizikai valójában, de elérhető virtual appliance-ként is, 130-as és 250-es kivitelben.Ezek az eszközök hatalmas mértékben túl vannak méretezve, a 130-as tízezer felhasználóig működik, a 250-es minimum 50-ezer, de esetenként 100 ezer azonosítást is képes kezelni. Hazai viszonylatban ez elegendő. Hibatűrési megfontolásokból ezek akár klaszterezhetők is, akar két különböző méretű is.
A hardveres token funkciók
Jelenleg kétfajta tokent lehet vásárolni az RSA-tól, egy simát és egy USB csatlakozással is rendelkezőt. Ezt a 128 kbyte/os hattértárat nem lehet adattárolásra használni, maximum 7 db certificate-et lehet rá feltölteni, tanúsítás esetére. Ehhez van egy middlewar is, egy kis program, amivel ezt akár automatikusan is lehet használni. Preboot automatication fázisban, usb szlotba csatlakoztatva ezt a tokent, a certificate is kiolvasható, a gép bebootol, s bármely alkalmazás használható.
A testre-szabhatóság érvényesítésével akár a megjelenő céges logo is lecserélhető.
Élettartam garancia; az RSA tokeneket kínozták mikrohullámú sütőben, tették röntgen gépbe, traktorokkal mentek át rajtuk, kibírták. Gyakorlati számok szerint, 12 év alatt 150 ezer eladott tokenből 20-30 esetben merült fel olyan kijelző-meghibásodás, ami a kijelző mechanikus (szándékos) megsértése, ill. magának a folyadék-kristálynak a tönkremenetele miatt állt elő. Az egybeöntött kemény műanyag burkolat megbontása esetén az lcd kijelzés és a chip tartalma azonnal törlődik, semmiféle információ nem nyerhető ki.A többi token gyártóval ellentétben, az RSA tokeneknek van feltüntetett lejárati ideje. A tervezhető lejárati idő után, a határ-napot követően már nem olvasható ki a szerkezet.1, 2, 3, 4, 5, 10 évre lehet ezeket vásárolni, s a gyártó RSA ebben a konstrukcióban látja a biztonságos üzemidő zálogát.
A kiváló minőségű tokenek minőségbiztosítással rendelkeznek, többféle funkciójuk több felhasználási területen (hard-disk encryption, email signing, stb.) alkalmazható. Testre szabhatók, saját logóval ellátva. A tranzakció alapú kód helyetti időszinkronizációjuknál a sikeres működéshez az idő, az algoritmus és az egyedi azonosító hármasa szükséges.
AES 128-bit algoritmust használnak (OATH helyett), s jelenleg 40 milliónál több SID 700 token van napi használatban.
SecurID 700, SecurID800 (OTP, vagy certificate alapon) hardver opció választható.
Szoftver token komponensek
OS alapú alkalmazás, ami letölthető az rsa.com oldalról, vagy az app store-ból
Elsőként ezt kell telepíteni (provisioning előtt)
RSA-tól vásárlás (SID820)
Adminisztrátor tudja jóváhagyni
A szoftvertokenek
A token fél évtől 10 évig terjedő időre vásárolható, s ezen belül is rugalmas a konstrukció.
Az elérhető szoftvertoken típusok:
RSA SecurID Mobile SDK
Desktop token
Mobiltelefon, tablet
Szoftver token (6, 12, 24, 36, 48, 60 és 120 hónapos lejárattal)
Telepíthetők tehát mobiltelefonra, laptopra is. Régen csak egy java kliens kellett hozzá, bármilyen buta-telefonra is fel lehetett telepíteni. Ma már ezek alkalmazásként letölthetők (Tesco, Googleplay), de a használathoz inicializálni kell őket. Meg kell adni az illető, használandó azonosítási Authentication Managert, hol van az a jelszó, ami megmondja, hogy ahhoz a szerverhez fordulhatok, ki vagyok, mi a felhasználó nevem. Akár egyedi jelszót is be tudok állítani, megfelelő telepítés szükséges.
Különböző, határozott időre felvett munkatársak, külsősök, bedolgozók, stb. esetén kedvező megoldás ez a kiosztott tokenekre. Pl. egy 10 évre vásárolt tokent 3 év után többször (több személynek) is kioszthatunk. Nem kell a szoftvertokent élettartamáig egyetlen felhasználóhoz kötni.Lehetőség van QR kód telepítésére is. A szoftvertoken telepítését nehéznek tartják. Le kell tölteni magát az elsőként (provisioning előtt) telepítendő OS alapú alkalmazást az rsa.com oldalról, vagy az app store-ból, utána felhasználónevet és egyéb adatokat kell megadni, ezt a felhasználók nem nagyon kedvelik.
Lehet generálni viszont egy QR kódot, ezt a telefonban lévő QR kód olvasóval le lehet olvasni, s akár e-mailben is el lehet küldeni fájlként, hogy az illető berendezésen megjelenjen, s arra kattintva települjön. Url-ként is elküldhetjük, hasonló eljárás követi. Az RSA-tól történő vásárlást (SID820) az adminisztrátor tudja jóvá hagyni. A szoftvertoken támogatási listája széles, s nincs egyetlen platformhoz (Apple, MS, stb.) rendelve, tehát teljesen független a felhasználótól és a futtató környezettől is.Biztonsági meggondolásokból, hogy a felhasználó ne tudja többszörösen alkalmazni ugyanazt a szoftvertokent, pl. a megkapott QR kóddal, elérhető védelmet nyújt az un. device bunding; az a fogás, hogy amelyik eszközről először telepítette a felhasználó az illető szoftvertokent, csak azon működik. Második használatnál ki fogja írni, hogy ez a szoftvertoken már használatban van, ezen az eszközön nem működtethető, forduljon a rendszergazdához.
Eszköz azonosítás kockázatelemzéssel
A kockázatelemzésen alapuló azonosítás több mint 10 éve elérhető, jelenleg 350 millió felhasználó azonosítását segíti.Az RSA Adaptive Authentication a tanuló algoritmussal token nélküli, de mégis többfaktoros azonosítást tesz lehetővé, több kockázati szint (High, Medium-High, Medium, Low) alkalmazásával, biztonsági elágazásokkal, igény szerinti megvalósítással.
Az RSA-nak ehhez van egy kockázat-elemző modulja is. Eddig, ha a felhasználó egy védett erőforráshoz akart hozzáférni, akkor az adott szabályrendszer szerint szüksége volt egy felhasználónévre, egy jelszóra és egy one-time passwordre. A kockázat-elemzéssel ez összetettebbé válik. Nemcsak azt fogja nézni, hogy melyik felhasználó melyik alkalmazást akarja elérni, hanem ezt egy összefüggés rendszerbe is helyezi.
Fent említettek szerint, amennyiben a felhasználó hétfő reggel 9-kor a belső hálózatból céges laptopról a belső hálózaton futó alkalmazást akar elérni, akkor ezt minimális kockázatnak minősítjük; elég egy felhasználó név és egy jelszó, ha viszont Kínából éjjel kettőkor tabletről próbálja elérni ugyanazt, akkor ezt magas kockázatúnak minősítjük és egy magasabb kockázatú azonosítási módszert kötünk hozzá, pl. ujjlenyomat-, vagy írisz-azonosítást. Mindezt az RSA automatikusan megcsinálja. Számos faktor figyelésére képes, pl. meg tudja nézni böngésző esetében, hogy az adott böngésző, vagy IP cím ismert-e már az alkalmazás számára, ismert-e maga az eszköz, ill. a bejelentkezési módszer megfelel-e a felhasználó napi bejelentkezési rutinjának.
Ennek megoldására iktattak be egy kéthetes tanulási ciklust, amikor az RSA csak figyeli ezeket a viselkedési szokásokat, belépési-kilépési időpontokat, az SAP indítási idejét, stb. Kiírja ezeket az adatokat, rendellenességeket keres közöttük, s ami az általa normális ügymenetnek minősítettől eltér, azt magasabb kockázatúnak minősíti és arra más azonosítási módszert fog kikényszeríteni.
Sok dolgot tud figyelni; eszközt, típust, operációs rendszert, DHCP teszteket, stb., ahhoz, hogy eldöntse, az adott belépési kérelem minimális, vagy maximális kockázatú.Ezekhez a különböző kockázati szintekhez különböző azonosítási módszereket lehet rendelni. Nem csak azt lehet megadni, hogy adott felhasználó adott alkalmazáshoz milyen módszerrel lépjen be, de az is előírható, különböző változatokban, hogy ha ő kockázatos-, vagy high-risk minősítésű profilt kap, akkor további azonosítási módszereket is alkalmaznia kell az eléréshez. A felhasználók számára mindez előnyös, alkalmazásukkal pl. a one-time password szükségszerű alkalmazása tizedére csökkenthető.350 millió felhasználó alkalmazza már ezt a kiforrott, megbízható megoldást.
A két-faktoros azonosítás működik tokenek nélkül is. Amennyiben semmit se szeretnénk telepíteni a mobiltelefonra, laptopra, ill. semmiféle hardvertokent nem akarunk adni a felhasználónak, és e-mailben, vagy sms-ben akarjuk kiküldeni a felhasználónak a one-time password-ot, akkor minden felhasználónak ilyet vásárol a cég. Az ideiglenes munkatársaknak is vásárolhat ilyet, ha rövid munkaidejükre, alkalmazási idejükre nem akar hardvertokent vásárolni.
Adódhat eset, pl. összeomlás utáni helyreállításkor, amikor minden felhasználónak egy másik telephelyre kell azonosítania magát, ilyenkor nyilván plusz azonosítási tokenre van szükség, hiszen magasabb kockázatú a belépési kérelem. Létezik még az otthonról dolgozás (home office) esete is, ilyenkor a kétfaktoros azonosítás működtetéséhez bizonyos portokat ki kell nyitni az Authentication Manager szerver felé. Erre találták ki a webpeer funkciót, amely egyszerűen csak proxyzik, ő publikál az internet felé, és ő beszélget a háttérben található Authentication Managerrel. Egy kiegészítő védelmi szintet alkot, s az azonosítási kérelmek biztonságát segíti. Néhány komponenst letilt, néhányat pedig engedélyez.
A szoftvertokenhez hasonló megoldás van a mobiltelefonunkban. Az Authentication Managernél megszoktuk, hogy van egy hardver-, vagy szoftvertoken,de mi a helyzet, ha ezt az azonosítási formát nem kizárólag cloud alkalmazásokhoz akarjuk alkalmazni?
Ehhez van egy un. authenticater, amit szintén le lehet tölteni a mobiltelefonokra. Ez teljesen megfelel a szoftvertokennek, de nem az Authentication Managerhez kapcsolódik, hanem a Cloud Service-hez, ill. az Identity Router-hez. Amennyiben egy ügyfél csak a cloud erőforrásokra szeretne egy ilyen rendszert kiépíteni, az Office365-re, SalesForce-ra, és nincs Home Purvis megoldása, RSA kétfaktoros megoldása, akkor nem kell vásárolnia tokent, Authentication Managert, meg tudja oldani a feladatot egy ilyen app-al, ami megfelel egy szoftver tokennek, ill. az RSA által nyújtott cloud szolgáltatásnak.Ezt a két dolgot kombinálni is lehet; futtatni lehet szoftvertokent és un. Authenticat app-ot is ugyanazon mobiltelefonon. Teljesen megfelel a kettő egymásnak. A one-time passwordot lehet védeni akár egy pin/kóddal is.
Az RSA SecurID Access-t 25 ezer ügyfél használja. Az aktív tokenek száma 50 millió felett van, s évente 10 millió darabbal nő.
Az RSA piaci részesedése meghaladja az 50%-ot.
Az RSA partnerei:
A cég ezernél több technológiai partnerrel ápol rendszeres kapcsolatot.
A kezdeményezésben résztvevő partnerek listája: www.rsa.com/rsasecured
Az RSA világszerte megtalálható felhasználói körébe kormányzati alkalmazók is tartoznak, közöttük van az USA Védelmi Minisztériuma, Kalifornia és Nevada állam, Európában a lengyel kormányzat körében van erős elkötelezettség gyártmányaik iránt. Termék kipróbálási (device trial)lehetőségek:
https://www.rsa.com/en-us/products/rsa-securid-suite/free-trials
Demó admin hozzáférés
https://rsatrial.access.securid.com/AdminInterface/login
Administrator User ID: admin@sid9.tryrsasecurid.com
Demó user hozzáférés
https://sso.sid9.tryrsasecurid.com/WebPortal/
User ID_1: zoltan.soos@arrow.com
User ID_2: sanjay.sample@sid9.tryrsasecurid.com
User ID_3: emilio.example@sid9.tryrsasecurid.com
https://www.arrowecs.hu/gyartok/rsa/termekek/termekek_megoldasok.cfm
Harmat Lajos
