Blog

Other languagesBosna i Hercegovina Bosna i Hercegovina   Hrvatska Hrvatska   Slovenija Slovenija   English English   

F5 BIG-IP APM – najčešći primeri 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 autentifikacijski proxy i baš zbog svoje proxy arhitekture omogućava odvajanje autentifikacije na klijentskoj i serverskoj strani. Ovo omogućava transformaciju identiteta i autentifikacijskih metoda. Na primer, klijent koji se nalazi u internom mrežnom okruženju i koji pokušava kroz APM da pristupi recimo Sharepoint aplikaciji koja se nalazi u tom istom okruženju, jednostavno će se autentifikovati korišćenjem NTLM ili Kerberos autentifikacijske metode. U trenutku kad klijent napusti interno mrežno okruženje i aplikaciji pokuša pristupiti iz nekog drugog okruženja, moguće je implementovati dodatnu metodu autentifikacije, npr. korišćenjem smart kartica ili klijentskog sertifikata. Isto tako moguće je tražiti dodatne provere uređaja s kojeg korisnik pristupa. Ovo pokazuje kako se APM i SSO mogućnosti automatski menjaju zavisno o brojnim faktorima, od toga ko je korisnik i gde se nalazi pa do toga kojem resursu, kada i na koji način pokušava da pristupi.

Auth Transformation

I dalje brojne kompanije koriste različite legacy aplikacije koje, ako pričamo iz perspektive pristupa korisnika, možda koriste neke zastarele metode autentifikacije. APM omogućava da se prema korisniku koristi neka od modernijih metoda autentifikacije. Postoji čitav niz autentifikacijskih mehanizama koje je moguće iskoristiti u klijentskom/serverskom delu, a koji su navedeni u prethodnoj objavi o APM-u. Na ovaj način moguće je iskoristiti nove autentifikacijske mehanizme pristupa aplikaciji bez da se menja sama aplikacija. Na primer, s klijentske strane korisnika je moguće autenticirati preko web forme, a korisničke podatke poslati prema web aplikaciji putem HTTP Basic autentifikacije. U tom slučaju APM ne utvrđuje autentičnost korisnika već samo uzima njegove podatke i šalje ih dalje web serveru na proveru koji nakon toga autentifikuje korisnika.

Single Sign-On pristup bez obzira na tip aplikacije

IT odeljenja imaju jednostavan cilj: da osiguraju 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 autentifikacijske mehanizme kako bi se osigurao pristup korisnika. Legacy aplikacije koriste obično neki od starijih autentifikacijskih mehanizama, kao što su Headers Insertion ili Kerberos Constrained Delegation, koje novije aplikacije možda ne podržavaju.

Na primer, želimo da iskoristimo SAML kao autentifikacijsku metodu, međutim legacy aplikacija to ne podržava. U tom slučaju APM postavljamo kao autentifikacijski proxy koji će u trenutku autentifikacije klijenta uzeti SAML token i tako ga „prevesti“ u nešto što pozadinska aplikacija razume. Na ovaj način osiguravamo jedinstveni pristup korisnika svim aplikacijama, bilo da se radi o legacy ili modernim aplikacijama, korišćenjem 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 sastav do virtualnih servera iza kojih se nalaze web aplikacije i osigurava autentificirani pristup aplikacijama kroz internet pretraživač bez potrebe za korišćenjem 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 i offload odnosno terminaciju SSL/TLS prometa.

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

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

BIG-IP APM podrška za SAML protokol

Mnoge organizacije u zadnje vreme u svojim aplikativnim okruženjima implementiraju SAML, bilo da se radi o internim ili cloud rešenjima. Ovde se javlja problem implementacije SAML-a na pozadinskim serverima. SAML funkcioniše prilično dobro na klijentskoj strani, ali nije uvek jednostavan za implementaciju i korišćenje na serverskoj strani. Zato su to situacije u kojim je dobro iskoristiti APM proxy arhitekturu i mogućnost korišćenja različitih metoda autentifikacije na klijentskoj i serverskoj strani. Kako bi se izbegao zahtevan 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 autentifikacijska 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 autentifikacije. Međutim, F5 može „prevesti“ SAML assertion u token i onda koristiti Kerberos Constrained Delegation kao metodu autentifikacije korisnika na serverskoj strani. Ova metoda skalira jako dobro budući da većina servera podržava Kerberos autentifikacijsku metodu i nije potrebno kreirati posebnu SSO konfiguraciju za svaku aplikaciju.

Osiguravanje O365 identiteta

Osiguravanje pristupa prema O365 aplikacijama moguće je ostvariti takođe preko APM uz dodavanje različitih provera kako bi se podigao nivo sigurnosti sastava:

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

Problem u slučaju O365 i sličnih cloud aplikacija leži u činjenici gde 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 autentifikaciju korisnika koristeći postojeće Active Directory servise. Jedan od načina da se to ostvari je korišćenje ADFS servera i ADFS proxy servera, međutim moguće je to postići i na jednostavniji način korišćenjem F5 APM i LTM proizvoda.

Zamenom ADFS proxy servera osigurava se visoka dostupnost usluge te je moguće da se osigura pre-autentifikaciju za ADFS servere čime se podiže sigurnost celokupnog sastava, ali i pojednostavljenje infrastrukture. Klijente je moguće dodatno proveriti korišćenjem brojnih ugrađenih APM provera, moguće je koristiti napredne metode autentifikacije kao što je korišćenje klijentskih sertifikata ili two-factor autentifikacija.

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čkim 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, zavisno o potrebnoj implementaciji.

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

Ako je pak implementiran kao OAuth Resource Server, korisnici se mogu ulogovati korišćenjem eksternih OAuth računa kako bi dobili pristup resursima koje sastav š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 zahteva za pristup aplikaciji, korisnik na primer dobija sliku kakva je prikazana niže i mora odabrati koji način autentifikacije želi koristiti.

Google i Facebook su sve popularniji načini autentifikacije gde organizacija želi autentificirati korinika i dozvoliti deljenje informacija koje imaju Google i Facebook s njihovim aplikativnim sastavom. Interna aplikacija organizacije postavljena je iza F5 sastava i rad u njoj zavisi o deljenju informacija s ovim eksternim servisima.

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

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

Korišćenje logina sa društvenih mreža pomaže organizacijama u uspostavljanju autentifikacije za svoje aplikacije, ali i poboljšava end user iskustvo budući da osigurava brz i praktičan pristup, a i omogućava 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 pretraživač ili korišćenjem 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šćenjem pristupnih lista ili pak napraviti različite provere na uređaju s kojeg korisnik pristupa. APM podržava split tunneling, ali i full tunnels. APM Networks Access klijent menja routing tablicu na klijentskom uređaju u skladu s konfiguracijom definisanom na APM-u.

 

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

Internet preglednik je verojatno najranjiviji deo u svakoj online komunikaciji. Maliciozni korisnici kontinuirano pokušavaju iskoristiti svaku ranjivost pretraživača kako bi došli do informacija o podacima za login i ostalih osetljivih 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š uvek u plain-textu kao što se i vidi na sledećoj slici.

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

 

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

Treba Vam ponuda ili pomoć pri izradi rešenja? Tražite partnera za implementaciju?

Kontaktirajte nas!