Blog

F5 BIG-IP APM – najpogostejši primeri uporabe

V predhodni objavi smo predstavili uvod v BIG-IP APM in navedli nekatere funkcije. Glede na kompleksnost rešitve in širok spekter možnosti uporabe, vam bomo v tej objavi poizkusili približati nekatere izmed bolj pogostih scenarijev uporabe.

BIG-IP APM kot proxy za avtentikacijo

BIG-IP APM je pravzaprav avtentikacijski proxy ter prav zaradi svoje proxy arhitekture omogoča ločevanje avtentikacije na klijentski in strežniški strani. To omogoča transformacijo identitet in avtentikacijskih metod. Na primer, klijent, ki se nahaja v internem omrežnem okolju in skuša skozi APM dostopati do Sharepoint aplikacije, ki se nahaja v istem okolju, bo avtenticiran z uporabo NTLM ali Kerberos avtentikacijske metode. V trenutku ko klijent zapusti lokalno omrežje in do aplikacije želi dostopati iz drugega okolja, je možno implementirati dodatno metodo avtentikacije, npr. z uporabo smart kartice ali klijentskih certifikatov. Prav tako je možno zahtevati dodatno preverjanje naprave s katere se uporabnik želi povezati. To kaže na to, da se APM in SSO avtomatsko spreminjajo glede na številne faktorje kot so kdo je uporabnik in kje se nahaja ter na kakšen način dostopa.

Auth Transformation

Številna podjetja še vedno uporabljajo različne legacy aplikacije, ki z vidika pristopa uporabnika uporabljajo nekatere zastarele metode avtentikacije. APM omogoča uporabo naprednejših metod avtetikacije. Obstaja cel niz avtentikacijskih mehanizmov, ki jih je možno uporabiti v klijentskem/strežniškem delu, navedeni pa so v predhodni objavi o APM-ju. Na ta način je možno izkoristiti nove avtentikacijske mehanizme dostopa do aplikacij brez potrebe po spreminjanju same aplikacije. Na primer uporabnika je možno avtenticirati preko spletnega obrazca, podatke pa poslati do spletne aplikacije s pomočjo HTTP Basic avtentikacije. V tem primeru APM ne avtenticira uporabnika ampak samo vzame njegove podatke in jih pošlje naprej do spletnega strežnika na preverjanje, ki nato preveri uporabnika.

Single Sign-On pristop ne glede na tip aplikacije

IT oddelki imajo enostaven cilj: zagotoviti enostaven dostop uporabniku različnih internih aplikacij. Medtem ta “enostaven” cilj postane vse razen enostaven, če v obzir vzamemo, da nove in stare legacy aplikacije ne uporabljajo iste mehanizme za avtentikacijo in zagotavljanje dostopa uporabnikov. Legacy aplikacije pogosto uporabljajo nekaterega izmed starejših mehanizmov kot je Headers Insertion ali Kerberos Constrained Delegation, ki jih najnovejše aplikacije morda ne podpirajo.

Na primer, če želimo izkoristiti SAML kot avtentikacijsko metodo, ki jo legacy aplikacija ne podpira. V tem primeru APM postavimo kot avtentikacijski proxy, ki bo v trenutku avtentikacije vzel SAML token ter ga „prevedel“ v nekaj kar aplikacija v ozadju razume. Na ta način s funkcijo Single Sign-On uporabniku zagotovimo edinstven dostop do vseh aplikacij, ne glede na to ali gre za legacy ali moderne aplikacije.

APM Web Access Management

APM web application je reverse proxy portal, ki omogoča dostop do različnih spletnih storitev skozi APM sistem do virtualnih strežnikov za katerimi se nahajajo spletne aplikacije ter zagotavlja dostop do aplikacij preko spletnega brskalnika ter brez potrebe po uporabi tunela ali nekaterih drugih specifičnih storitev. Takšna konfiguracija v večini primerov vključuje tudi implementacijo LTM modula, ki ga lahko uporabimo za optimizacijo dostavljanja prometa ter offload oziroma terminacijo SSL/TLS prometa.

Po avtentikaciji se uporabniku lahko prikaže Webtop, ki je prikazan na spodnji sliki, prikazuje pa povezave do vseh vsebin do katerih ima uporabnik pravice dostopati.

Recimo, da imate aplikacijo, ki trenutno ne zahteva avtentikacije ob pristopu, vendar iz določenih razlogov je potrebno dodati to k aplikaciji. Uporabnik preko spletnega obrazca vpisuje svoje podatke, APM ga avtenticira in mu dovoli dostop. Ni potrebno delati nobene rekonfiguracije strežnikov ali dodelave aplikacij – APM poenostavlja uvajanje novih varnostnih pravil v omrežno-aplikativna okolja.

BIG-IP APM podpora za SAML protokol

Mnoge organizacije v zadnjem času v svoja okolja implementirajo SAML ne glede na to ali gre za interna ali cloud okolja. Tu se pojavlja težava implementacije SAML-ja na strežnike v ozadju. SAML funkcijonira precej dobro na uporabniški strani, ni pa vedno enostaven za implementacijo in uporabo na strežniški strani. Zato je v takšnih situacijah dobro izkoristiti APM proxy arhitekturo in možnost uporabe različnih metod avtentikacije na uporabniški in strežniški strani. Da se izognemo zahtevnemu procesu rekonfiguracije strežnikov je APM možno postaviti kot SAML SP ali SAMP IdP, s čimer je omogočena tudi federacija identitete in SSO znotraj enterprise okolja.

Ko je kot avtentikacijska metoda v uporabi SAML, IdP kreira assertion za dokazovanje uporabniške identitete. V takšnih primerih F5 nima uporabniškega gesla in posledično ni možno uporabiti metod kot sta HTTP Basic ali HTTP Form avtentikaciji. Medtem F5 lahko „prevaja“ SAML assertion v token ter uporabi Kerberos Constrained Delegation kot metodo avtentikacije uporabnika na strežniški strani. Ta metoda je podprta na večini strežnikov in ne potrebuje dodatne SSO konfiguracije za vsako aplikacijo.

Varovanje O365 identitete

Varovanje dostopa do O365 aplikacij je prav tako možno zagotoviti s pomočjo APM z dodajanjem različnih preverjanj za dvigovanje ravni varnosti sistema:

  • Večfaktorska avtentikacija
  • Preverjanje endpoint-a
  • Preverjanje geografske lokacije uporabnika
  • Preverjanje omrežja iz katerega uporabnik dostopa

Problem v primeru O365 in podobnih cloud aplikacij leži v tem kje in kako shranjevati informacije o uporabnikih. Zaradi tega večina organizacij izbere federalni model identitet z namenom ohranjanja nadzora nad njimi. V tem primeru O365 uporablja SAML za avtentikacijo uporabnika preko obstoječih Active Directory storitev. Eden izmed načinov, da to dosežemo je uporaba ADFS strežnika in ADFS proxy strežnika, to pa je možno doseči tudi na bolj enostaven način z uporabo F5 APM in LTM rešitev.

Z zamenjavo ADFS proxy strežnika zagotovimo visoko dosegljivost storitev ter pre-avtentikacijo za ADFS strežnike in s tem višjo stopnjo varnosti sistema, hkrati pa tudi enostavnejšo infrastrukturo. Klijente je možno dodatno preverjati preko številnih integriranih APM funkcij in naprednih metod avtentikacije kot je uporaba klijentskih certifikatov ali two-factor avtentikacija.

Več lahko najdete v eni izmed naših objav na blogu: Office 365 zaščita identitet.

BIG-IP APM podpora za OAuth 2.0

S TMOS verzijo 13 je dodana podpora za OAuth 2.0, avtorizacijski framework, ki omogoča aplikacijam omejevanje dostopanja do uporabniških računov z določenih storitev kot so Facebook, Google, Salesforce. Sedaj se APM lahko obnaša kot OAuth client, OAuth Resource Server in OAuth Authorization Server, odvisno od potrebne implementacije.

Če je APM implementiran kot OAuth Authorization Server lahko izda authorization codes, access tokens ter refresh tokens in oddela token introspection.

Če pa je implementiran kot OAuth Resource Server, se uporabniki lahko vpišejo z uporabo eksternih OAuth računov, da bi lahko dobili dostop do sredstev, ki jih sistem ščiti. Eksterni OAuth računi so lahko računi z družabnih omrežij kot sta Google ali Facebook, lahko pa enterprise računi kot sta F5 (APM) ali Ping Identity. V tem primeru APM postane klijentska aplikacija v smeri OAuth avtorizacijskega strežnika kot je naprimer Google.

Kako izkoristiti obstoječe uporabniške račune z družabnih omrežij za zagotavljanje dostopa do aplikacij?

Recimo, da imamo interno aplikacijo do katere smo omogočili dostop preko APM-ja. Ob pošiljanju inicijalne zahteve za dostop do aplikacij uporabnik dobi sliko kot je prikazana spodaj ter mora izbrati kateri način avtentikacije želi uporabiti.

Google in Facebook sta vse bolj priljubljena načina avtentikacije uporabnika in dovoljevanje deljenja informacij, ki jih imata Google in Facebook z njihovim aplikacijskim sistemom. Interna aplikacija organizacije je postavljena za F5 sistemom, delo v njej pa je odvisno od deljenja informacij s temi eksternimi storitvami.

Če uporabnik izbere recimo Facebook, ga APM preusmeri na Facebook login stran. Tu se uporabnik mora vpisati s svojimi podatki. Po tem ko Facebook avtenticira uporabnika, pošlje do F5 pomembne podatke kot so ime, e-mail ali neki drugi parametri.

Kaj se je pravzaprav zgodilo? APM je sprejel OAuth token, ki mu je bil poslan s strani Facebook-a ter iz OAuth scope-a je izvlekel podatke, ki so mu potrebni in jih je posredoval do končne aplikacije, ki ima nato informacije o identiteti uporabnika in na kakšen način lahko dostopa.

Uporaba logina z družabnih omrežij organizacijam pomaga pri vzpostavljanju avtentikacije za svoje aplikacije, hkrati pa tudi izboljša end user izkušnje, ker je zagotovljen hiter in praktičen pristop, ki organizacijam omogoča tudi zbiranje pomembnih informacij o svojih uporabnikih.

SSL VPN

Ena izmed številnih možnosti, ki jih APM nudi je tudi zagotavljanje oddaljenega dostopa do korporativnega omrežja ali aplikacij. Povezava je lahko vzpostavljena preko spletnega brskalnika ali z uporabo posebne alikacije, ki dela na večini dostopnih operacijskih ssitemov (Windows OS, MacOS, Linux, iOS, Android). Uporabnikom je možno omejiti dostop do posameznih sredstev z uporabo dostopnih seznamov ali pa narediti določena preverjanja na napravi s katere uporabnik dostopa. APM podpira split tunneling in  full tunnels. APM Networks Access klijent spreminja routing tablico na uporabniški napravi v skladu s konfiguracijo definirano na APM-ju.

 

Kako zavarovati obrazec za vnos uporabniških podatkov? 

Spletni brskalnik je verjetno najranljivejši del vsake spletne komunikacije. Zlonamerni uporabniki nenehno skušajo izkoristiti vsako pomankljivost brskalnika z namenom pridobivanja informacij za vstop in ostalih pomembnih podatkov o uporabnikih storitev.

Recimo, da imate aplikacijo, ki svojim uporabnikom daje prijavni obrazec preko F5 APM naprave. Čeprav je stran na kateri se obrazec nahaja zavarovana s TLS-jem, lahko napadalci znotraj brskalnika izvedejo neko vrsto Man-in-the-Middle ali Man-in-the-Browser napada. S tem dosežejo, da pridejo do informacij, ki jih uporabnik vnaša, med tem ko so še, kot je vidno na spodnji sliki, v plain-text obliki.

Za preprečevanje napada je možno integrirati APM z WebSafe Application Layer Encryption rešitvijo. V F5 konfiguraciji je možno izbrati kateri tip zaščite želimo in katere parametre želimo zavarovati. WebSafe kritpira vsak vnos preko tipkovnice „on-the-fly“ v realnem času. Dodatno, dinamično spreminja HTML kodo in imena občutljivih parametrov, da se napadalcu onemogoči dostop do osebnih podatkov. Več o WebSafe rešitvi si lahko preberete na našem blogu.

 

To so samo nekateri najpogostejši primeri implementacije BIG-IP APM rešitev v različnih okoljih. Za dodatan nasvet ali pomoč nas kontaktirajte!

Share on LinkedInShare on FacebookShare on Google+Tweet about this on Twitter