Blog

F5 BIG-IP APM – najčešći primjeri korištenja

U prošloj objavi dali smo uvod u BIG-IP APM i naveli neke njegove funkcionalnosti. S obzirom na kompleksnost proizvoda i široki spektar mogućih primjena, u ovom postu probat ćemo vam približiti neke od najčešćih scenarija korištenja ovog proizvoda.

BIG-IP APM kao autentikacijski proxy

BIG-IP APM je zapravo autentikacijski proxy te baš zbog svoje proxy arhitekture omogućava odvajanje autentikacije na klijentskoj i serverskoj strani. Ovo omogućava transformaciju identiteta i autentikacijskih metoda. Na primjer, klijent koji se nalazi u internom mrežnom okruženju i koji pokušava kroz APM pristupiti recimo Sharepoint aplikaciji koja se nalazi u tom istom okruženju jednostavno će se autenticirati korištenjem NTLM ili Kerberos autentikacijske metode. U trenutku kad klijent napusti interno mrežno okruženje te aplikaciji pokuša pristupiti iz nekog drugog okruženja, moguće je implementirati dodatnu metodu autentikacije, npr. korištenjem smart kartica ili klijentskog certifikata. Isto tako moguće je tražiti dodatne provjere uređaja s kojeg korisnik pristupa. Ovo pokazuje kako se APM i SSO mogućnosti automatski mijenjaju ovisno o brojnim faktorima, od toga tko je korisnik i gdje se nalazi pa do toga kojem resursu, kada i na koji način pokušava pristupiti.

Auth Transformation

I dalje brojne tvrtke koriste različite legacy aplikacije koje, ako pričamo iz perspektive pristupa korisnika, možda koriste neke zastarjele metode autentikacije. APM omogućava da se prema korisniku koristi neka od modernijih metoda autentikacije. Postoji čitav niz autentikacijskih mehanizama koje je moguće iskoristiti u klijentskom/serverskom dijelu, a koji su navedeni u prethodnoj objavi o APM-u. Na ovaj način moguće je iskoristit nove autentikacijske mehanizme pristupa aplikaciji bez da se mijenja sama aplikacija. Na primjer, s klijentske strane korisnika je moguće autenticirati preko web forme, a korisničke podatke poslati prema web aplikaciji putem HTTP Basic autentikacije. U tom slučaju APM ne autenticira korisnika već samo uzima njegove podatke i šalje ih dalje web serveru na provjeru koji nakon toga autenticira korisnika.

Single Sign-On pristup bez obzira na tip aplikacije

IT odjeli imaju jednostavan cilj: osigurati jednostavan pristup korisnika različitim internim aplikacijama. Međutim, taj “jednostavan” cilj postaje sve osim jednostavan kad se uzme u obzir da nove i stare legacy aplikacije ne koriste iste autentikacijske mehanizme kako bi se osigurao pristup korisnika. Legacy aplikacije koriste obično neki od starijih autentikacijskih mehanizama, kao što su Headers Insertion ili Kerberos Constrained Delegation, koje novije aplikacije možda ne podržavaju.

Na primjer, želimo iskoristiti SAML kao autentikacijsku metodu, međutim legacy aplikacija to ne podržava. U tom slučaju APM postavljamo kao autentikacijski proxy koji će u trenutku autentikacije klijenta uzeti SAML token te ga „prevesti“ u nešto što pozadinska aplikacija razumije. Na ovaj način osiguravamo jedinstveni pristup korisnika svim aplikacijama, bilo da se radi o legacy ili modernim aplikacijama, korištenjem Single Sign-On funkcionalnosti.

APM Web Access Management

APM web application je reverse proxy portal koji omogućava pristup različitim web resursima kroz APM sustav do virtualnih servera iza kojih se nalaze web aplikacije te osigurava autenticirani pristup aplikacijama kroz internet preglednik bez potrebe za korištenjem tunela ili nekih drugih specifičnih resursa. Ovakva konfiguracija obično uključuje i implementaciju LTM modula kojeg onda možemo iskoristiti za optimizaciju isporuke prometa prema klijenta te offload odnosno terminaciju SSL/TLS prometa.

Nakon autentikacije klijentu se može prikazati Webtop koji je prikazan na donjoj slici, a koji sadrži poveznice na sve resurse za koje klijent ima mogućnost pristupa.

Recimo da imate aplikaciju koja trenutno ne traži da se korisnik autenticira prilikom pristupa, no iz određenih razloga potrebno je ipak dodati autentikaciju na aplikaciju. Korisnik putem web forme upisuje svoje podatke, APM ga autenticira i dozvoljava mu pristup do aplikacije. Nije potrebno raditi nikakvu rekonfiguraciju servera ni dorađivati kod aplikacije – APM pojednostavljuje uvođenje novih mjera sigurnosti u mrežno aplikativnim okruženjima.

BIG-IP APM podrška za SAML protokol

Mnoge organizacije u zadnje vrijeme u svojim aplikativnim okruženjima implementiraju SAML, bilo da se radi o internim ili cloud rješenjima. Ovdje se javlja problem implementacije SAML-a na pozadinskim serverima. SAML funkcionira prilično dobro na klijentskoj strani, ali nije uvijek jednostavan za implementaciju i korištenje na serverskoj strani. Zato su to situacije u kojim je dobro iskoristiti APM proxy arhitekturu i mogućnost korištenja različitih metoda autentikacije na klijentskoj i serverskoj strani. Kako bi se izbjegao zahtjevan proces rekonfiguracije serverskog okruženja, APM je moguće postaviti kao SAML SP ili SAMP IdP, čime je omogućena i federacija identiteta i SSO unutar enterprise okruženja.

Kad se SAML koristi kao autentikacijska metoda, IdP kreira assertion kako bi se dokazao korisnički identitet. U ovakvim situacijama F5 nema korisničku lozinku pa nije moguće koristiti metode poput HTTP Basic ili HTTP Form autentikacije. Međutim, F5 može „prevesti“ SAML assertion u token te onda koristiti Kerberos Constrained Delegation kao metodu autentikacije korisnika na serverskoj strani. Ova metoda skalira jako dobro budući da većina servera podržava Kerberos autentikacijsku metodu i nije potrebno kreirati posebnu SSO konfiguraciju za svaku aplikaciju.

Osiguravanje O365 identiteta

Osiguravanje pristupa prema O365 aplikacijama moguće je ostvariti također preko APM uz dodavanje različitih provjera kako bi se podigla razina sigurnosti sustava:

  • Višefaktorska autentikacija
  • Provjera endpoint-a
  • Provjera geografske lokacije korisnika
  • Provjera mreže iz koje korisnik pristupa

Problem u slučaju O365 i sličnih cloud aplikacija leži u činjenici gdje i kako spremati korisničke informacije. Zbog ovoga većina organizacija odabire federirani model identiteta kako bi se zadržala kontrolu nad istima. U ovom slučaju O365 koristi SAML za autentikaciju korisnika koristeći postojeće Active Directory servise. Jedan od načina da se to ostvari je korištenje ADFS poslužitelja i ADFS proxy poslužitelja, međutim moguće je to postići i na jednostavniji način korištenjem F5 APM i LTM produkata.

Zamjenom ADFS proxy servera osigurava se visoka dostupnost usluge te je moguće osigurati pre-autentikaciju za ADFS servere čime se podiže sigurnost cjelokupnog sustava, ali i pojednostavljenje infrastrukture. Klijente je moguće dodatno provjeriti korištenjem brojnih ugrađenih APM provjera, moguće je koristiti napredne metode autentikacije kao što je korištenje klijentskih certifikata ili two-factor autentikacija.

Više detalja možete pronaći u jednom od postova na našem blogu: Office 365 zaštita identiteta.

BIG-IP APM podrška za OAuth 2.0

S TMOS verzijom 13 dodana je podrška za OAuth 2.0, autorizacijski framework koji omogućava aplikacijama limitirani pristup korisničim računima s nekih servisa, kao što su Facebook, Google, Salesforce. Sada se APM može ponašati kao OAuth client, OAuth Resource Server i OAuth Authorization Server, ovisno o potrebnoj implementaciji.

Ukoliko je APM implementiran kao OAuth Authorization Server, tada može izdati authorization codes, access tokens te refresh tokens, te isto tako odraditi token introspection.

Ako je pak implementiran kao OAuth Resource Server, korisnici se mogu ulogirati korištenjem eksternih OAuth računa kako bi dobili pristup resursima koje sustav štiti. Eksterni OAuth računi mogu biti računi sa društvenih mreža kao što su Google ili Facebook, ili pak enterprise računi poput F5 (APM) ili Ping Identity. U ovom slučaju, APM postaje klijentska aplikacija prema eksternom OAuth autorizacijskom serveru, kao što je recimo Google.

Kako iskoristiti potojeće korisničke račune na društvenim mrežama kako bi se osigurao pristup aplikacijama?

Recimo da imamo internu aplikaciju kojem smo omogućili pristup preko APM-a. Prilikom slanja inicijalnog zahtjeva za pristup aplikaciji, korisnik primjerice dobiva sliku kakva je prikazana niže te mora odabrati koji način autentikacije želi koristiti.

Google i Facebook su sve popularniji načini autentikacije gdje organizacija želi autenticirati korinika i dozvoliti dijeljenje informacija koje imaju Google i Facebook s njihovim aplikativnim sustavom. Interna aplikacija organizacije postavljena je iza F5 sustava te rad u njoj ovisi o dijeljenju informacija s ovim eksternim servisima.

Ukoliko korisnik odabere recimo Facebook, APM ga preusmjerava na Facebook login stranicu. Tu se korisnik mora ulogirati sa svojim privatnim podacima. Nakon što Facebook autenticira korisnika šalje prema F5 bitne infromacije o korisniku kao što su ime, e-mail ili neki drugi parametri.

Što se zapravo dogodilo? APM je prihvatio OAuth token koji mu je poslan od strane Facebook-a te iz OAuth scope-a je izvukao informacije koje su mu potrebne i proslijedio informacije dalje do krajnje aplikacije koja sada ima informaciju o identitu korisnika i kojim resursima ima pravo pristupiti.

Korištenje logina sa društvenih mreža pomaže organizacijama u uspostavljanju autentikacije za svoje aplikacije, ali i poboljšava end user iskustvo budući da osigurava brz i praktičan pristup, a i omogućuje organizacijama da prikupe bitne informacije o svojim korisnicima.

SSL VPN

Jedna od brojnih mogućnosti koje APM pruža korisnicima je i osiguravanje udaljenog pristupa korporativnoj mreži ili aplikacijama u istoj. Konekcija može biti inicirana ili kroz internet preglednik ili korištenjem posebne aplikacije koja radi na većini dostupnih OS-ova danas (Windows OS, MacOS, Linux, iOS, Android). Moguće je ograničiti pristup korisnika pojedinim resursima korištenjem pristupnih lista ili pak napraviti različite provjere na uređaju s kojeg korisnik pristupa. APM podržava split tunneling, ali i full tunnels. APM Networks Access klijent mijenja routing tablicu na klijentskom uređaju u skladu s konfiguracijom definiranom na APM-u.

 

Kako zaštiti formu za unos korisničkih podataka? 

Internet preglednik je vjerojatno najranjiviji dio u svakoj online komunikaciji. Maliciozni korisnici kontinuirano pokušavaju iskoristiti svaku ranjivost preglednika kako bi došli do informacija o podacima za login i ostalih osjetljivih informacija korisnika servisa.

Recimo da imate aplikaciju koja svojim korisnicima isporučuje login formu preko F5 APM uređaja. Iako je stranica na kojoj se nalazi forma za unos korisničkih podataka zaštićena TLS-om, maliciozni napadači mogu se pozicionirati unutar browsera i izvesti neku vrstu Man-in-the-Middle ili Man-in-the-Browser napada. Pozicioniranjem unutar browsera postižu da dođu do informacija koje korisnik unosi u formu dok su one još uvijek u plain-textu kao što se i vidi na sljedećoj slici.

Kako bi onemogućili napadača u ovom naumu, moguće je integrirati APM s WebSafe Application Layer Encryption rješenjem. U F5 konfiguraciji moguće je odabrati koji točno tip zaštite želimo i koje sve parametre želimo zaštiti. WebSafe kritpira svaki unos na tipkovinici „on-the-fly“ u stvarnom vremenu. Dodatno, dinamički mijenja HTML kod i imena osjetljivih parametara kako bi se napadaču onemogućilo da dođe do osobnih podataka korisnika. Više o WebSafe rješenju možete pročitati na našem blogu.

 

Ovo su samo neki od najčešćih primjera implementacije BIG-IP APM proizvoda u različitim okruženjima. Za dodatan savjet ili pomoć, slobodno nam se obratite!

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