Check Point AEV

Kako AI agenti menjaju pravila cyber odbrane

Korišćenje autonomnih AI agenata za efikasniji proboj odbrane sistema povećava pritisak na timove za bezbednost. Kao odgovor na ovu novu vrstu pretnji, kompanija Check Point predstavila je napredno rešenje AEV – Agentic Exposure Validation.

U eri ubrzane digitalne i AI transformacije, organizacije se suočavaju sa surovom realnošću: broj bezbednosnih propusta, procurelih pristupnih podataka i pogrešnih konfiguracija raste eksponencijalnom brzinom. Pritisak na timove za cyber bezbednost nikada nije bio veći, ali najveća promena ne leži samo u broju pretnji, već u brzini i načinu na koji napadači deluju.

Tradicionalni ciklusi analize, korelacione provere i ručnog krpljenja sistema više ne mogu da isprate napadače. Jer oni ne čekaju, već koriste autonomne AI agente kako bi u realnom vremenu automatizovali proreze u sistemima i dinamički menjali metode napada sve dok ne probiju odbranu. Taj pristup drastično skraćuje vreme potrebno za uspešno kompromitovanje sistema.

Kao odgovor na ovu novu vrstu pretnji, kompanija Check Point predstavila je napredno rešenje Agentic Exposure Validation (AEV).

Razmišljati kao napadač

Check Point Agentic Exposure Validation uvođenjem AI agenata redefiniše način na koji se organizacije bore protiv cyber pretnji. Umesto da se oslanja isključivo na pasivno skeniranje ranjivosti, što često generiše ogroman broj lažnih uzbuna, AEV kreira model autonomnog agentičkog napadača koji razmišlja i deluje baš kao pravi haker.

Umesto da se oslanja isključivo na pasivno skeniranje ranjivosti, AEV kreira model autonomnog napadača koji razmišlja i deluje kao pravi haker

AEV spaja informacije iz različitih izvora pretnji. S jedne strane, tu je interni kontekst: procureli izvorni kod, kompromitovani kredencijali i analize CVE ranjivosti, a s druge strane ono što se vidi spolja: podaci o izloženosti prema internetu, uključujući digitalne sertifikate, otvorene portove, web interfejse i aktivne servise.

Povezivanjem ovih podataka u jedinstven kontekst, AEV unutar samo nekoliko minuta može sigurno i bezbedno da testira različite vektore napada na nivou cele infrastrukture. Rezultat je kontinuirano, automatizovano black box penetraciono testiranje koje pruža nedvosmislene dokaze o tome šta je zaista ranjivo.

Kako AEV funkcioniše u praksi?

Kako bi se osiguralo da automatizovana testiranja ne naruše kontinuitet poslovanja, Check Point AEV primenjuje strogo definisanu petlju bezbedne provere kroz šest koraka:

1. Razumevanje konteksta: AI agent analizira imovinu, tehnologiju, specifični CVE ili kompromitovane podatke.
2. Obogaćivanje informacijama: Podaci organizacije kombinuju se sa živim praćenjem pretnji (threat intelligence) i istraživanjem mogućnosti za napad.
3. Identifikacija bezbednosnih praznina: Proverava se da li postojeće kontrole i detekcije već blokiraju uočeni rizik.
4. Kreiranje ciljane validacije: Agent osmišljava putanju napada koja simulira logiku hakera, bez upotrebe destruktivnih tehnika.
5. Nezavisna AI revizija: Poseban AI revizor procenjuje bezbednost, tačnost i dubinu testa pre nego što se on izvrši.
6. Potvrda, preusmeravanje ili uklanjanje: Ako je propust dokazan, generiše se izveštaj. Ako je napad blokiran, agent traži novu putanju. Ukoliko se ne može dokazati, nalaz se uklanja kako se ne bi stvarala šum-notifikacija.

Ključna vrednost za CTEM programe

U okviru modernih programa za upravljanje izloženošću pretnjama (Continuous Threat Exposure Management – CTEM), AEV daje odgovore na ključna pitanja bezbednosnih timova, a to su: Da li napadač zaista može iskoristiti ovu izloženost u našem okruženju? Da li postojeće bezbednosne kontrole funkcionišu i koji je najkritičniji korak koji moramo preduzeti prvi kako bismo maksimalno smanjili rizik?

Umesto gubljenja vremena na teorijske rizike, Check Point AEV omogućava timovima da deluju brže, preciznije i sa potpunim poverenjem u tačnost podataka, pre nego što napadači uopšte dobiju priliku da deluju.

The post Kako AI agenti menjaju pravila cyber odbrane appeared first on Business&IT.

Kontinuirana validacija bezbednosti

Pretnje koje vidimo i rizici koje previđamo

Poslednje dve godine donele su velike promene u svim oblastima IT industrije. AI, inicijalno više prepoznat kao buzz word nego kao prava opasnost, naterao je security stručnjake i vendore da naprave veliki zaokret u radu. Napad koji je targetirao jednu kompaniju ranije je bio skup i zahtevao previše vremena, a sada su na raspolaganju alati koji mogu ceo proces olakšati i ubrzati. Za nas, čije se usluge baziraju na odbrani IT sistema, to je značilo veliku posvećenost praćenju trendova, razmenu iskustava i dosta vremena provedenog u labu. Za sva rešenja kojima smo se svakodnevno bavili zaključak je bio isti: tradicionalni pristup je trom, spor i velika prednost je na drugoj strani.

Da bismo mogli da idemo u korak sa sadašnjim pretnjama, moramo koristiti slične pristupe i automatizovati naše procese. Dobar primer primene ovakvog pristupa je pentest, jedan od bitnih stubova bezbednosti. Tradicionalni pentest najčešće se sprovodi jednom godišnje ili pre puštanja važnog sistema u produkciju. Proces implementacije podrazumeva da kompanija angažuje stručni tim i definiše obim testiranja, zatim se simulira napad, a potom dobija izveštaj koji navodi pronađene ranjivosti i preporuke, čime je testiranje završeno. Međutim, problem predstavlja činjenica da se bezbednosna slika sistema ne okončava danom kada je pentest sproveden. Aplikacije se svakodnevno menjaju, uvode se nove funkcionalnosti, menjaju konfiguracije, dodaju servisi i korisnici, otkrivaju nove ranjivosti i propusti. Odgovor na ovaj izazov je prelazak na agilniji model kontinuirane validacije bezbednosti. U tom pristupu posebno su interesantna dva tipa platformi koja mogu da promene način na koji kompanije testiraju svoju otpornost na napade.

Pentest u vašim rukama

Prvi koncept odnosi se na platformu za automatizovani pentest web aplikacija koja se nalazi direktno u rukama korisnika. Ideja je jednostavna: umesto da čekate termin za sledeći godišnji pentest, on može da se pokrene kad god za njim postoji potreba – nakon nove verzije aplikacije, velike izmene infrastrukture, uvođenja nove funkcionalnosti ili jednostavno kao redovna provera bezbednosti.

Ključna vrednost ovakvog rešenja nije samo u tome što može da pronađe veliki broj potencijalnih ranjivosti. Klasično skeniranje često rezultira dugačkom listom nalaza: određeni port je otvoren, neka verzija softvera je zastarela, postoji izvesna konfiguraciona slabost ili je pronađen potencijalni problem u aplikaciji. Takav pristup može biti koristan, ali sam po sebi ne govori dovoljno o tome šta ta ranjivost zapravo znači za konkretnu aplikaciju i podatke koji se u njoj nalaze.

Napredniji pristup ide korak dalje: platforma ponavlja različite faze skeniranja, međusobno korelira rezultate i pokušava da utvrdi da li više pojedinačnih nalaza zajedno predstavljaju stvarnu i iskoristivu pretnju. Drugim rečima, cilj nije samo dobijanje spiska ranjivosti, već njihovo posmatranje u kontekstu realnog napada. To omogućava bezbednosnom timu da se fokusira na ono što je zaista važno – ranjivosti, odnosno propuste koje napadač može da iskoristi i koje mogu imati konkretan uticaj na web aplikaciju.

Pentest – ne samo test aplikacija

Drugi koncept ide korak dalje i bavi se pitanjem koje klasičan pentest ili skener ranjivosti često ne obrađuje u dovoljnoj meri: Šta napadač može da uradi nakon što je već uspeo da se nađe unutar sistema?

Za uspešan napad ponekad je dovoljan jedan fišing mejl. Kada korisnik otvori zlonamerni fajl ili klikne na kompromitovani link, ukoliko antivirus u tom trenutku ne detektuje napad, malver dospeva u mrežu. Od tog trenutka situacija se menja. Napadač više ne mora da traži način da probije spoljnu zaštitu. On je već u sistemu i pokušava da poveća nivo pristupa, dođe do drugih mašina, ukrade korisničke sesije, pristupi podacima ili kompromituje domen.

Upravo ovde pojavljuje se koncept platforme za validaciju unutrašnje bezbednosti i simulaciju aktivnosti napadača. Takvo rešenje ne posmatra samo pojedinačne mašine i njihove ranjivosti, već omogućava aktivno skeniranje okruženja, a istovremeno „osluškuje“ i korisnički saobraćaj i proverava različite tehnike koje napadač može koristiti nakon inicijalnog pristupa. To može uključivati tehnike poput Man-in-the-Middle (MiTM) napada, relay saobraćaja, pokušaja dekripcije i drugih metoda koje se koriste za dalje napredovanje kroz mrežu. Suština je u povezivanju različitih tehnika i pronađenih slabosti.

Jedna osrednja ranjivost, sama po sebi, možda i nije ozbiljan problem. Druga, takođe, ne predstavlja kritičan rizik. Ali šta ako se upravo te dve ranjivosti mogu povezati? Tada dobijamo potpuno drugačiji rezultat, što znači da napadač može da dođe do podataka sa domena, preuzme korisničku sesiju ili ostvari pristup resursima koji mu pojedinačno nisu bili dostupni. To je važna razlika između „imamo ranjivost“ i „napadač može da iskoristi ovu ranjivost da uradi nešto konkretno“.

Dva rešenja, jedan cilj

Iako se ove dve platforme bave različitim delovima bezbednosnog lanca, njihova zajednička vrednost je ista: provera onoga što napadač zaista može da uradi.

Bezbednost više ne možemo posmatrati kao stanje koje potvrđujemo jednom godišnje, već kao proces koji se mora redovno proveravati. Najvažnija promena nije samo u tehnologiji, već u načinu razmišljanja. Više nije dovoljno utvrditi da ranjivost postoji. Potrebno je razumeti da li je ona iskoristiva, sa kojim se drugim slabostima može povezati i dokle može odvesti napadača, jer najveći rizik često nije pretnja koju vidimo, već mogućnost kompromitovanja koju smo prevideli.

Najveći rizik često nije pretnja koju vidimo, već mogućnost kompromitovanja koju smo prevideli

Kompanija COMING je tu da omogući klijentu podizanje nivoa bezbednosti svoje organizacije. Za zainteresovane kompanije dostupan je i Proof of Concept (PoC), kroz koji je moguće praktično proveriti kako ova rešenja funkcionišu u konkretnom okruženju.

Jasna Miletić i Luka Živanović, COMING

The post Pretnje koje vidimo i rizici koje previđamo appeared first on Business&IT.

Active Directory i Microsoft Entra ID

Upravljanje identitetima u hibridnom okruženju

Active Directory se možda još uvek nije „preselio u istoriju“, ali prvi put postaje realnost da organizacije postepeno smanjuju njegovu ulogu

Active Directory je „mrtav“ već duže vreme, barem ako bismo sudili po naslovima tekstova koji se pojavljuju otkako je cloud postao ozbiljna alternativa lokalnoj infrastrukturi. Ipak, ni danas mi ne prođe radni dan bez otvaranja Active Directory Users and Computers konzole.

Korisnici iz dobro poznate Active Directory Users and Computers konzole sada postoje i u Microsoft Entra ID-ju, prijavljuju se na Microsoft 365 i druge cloud servise, prolaze kroz Conditional Access polise i koriste uređaje koji možda nikada nisu ni videli lokalnu mrežu kompanije.

Active Directory, dakle, nije nestao. Ali zašto je to tako? Iz prostog razloga: radi posao, i to dobro. Niko razuman ne menja nešto što i dalje solidno funkcioniše samo zato što postoji noviji sistem, koji radi drugačije. Grupna polisa za par sekundi konfiguriše hiljadu mašina, Kerberos i dalje drži legacy aplikacije koje generišu ozbiljan promet, dok fajl-serveri i dalje čuvaju NTFS permisije. Cloud je u međuvremenu promenio dosta toga, ali server u data-centru i dalje mora nekako da zna ko sme da mu priđe, a Active Directory to radi dobro kao i uvek.

Cloud je promenio dosta toga, ali server u data-centru i dalje mora nekako da zna ko sme da mu priđe, a Active Directory to radi dobro kao i uvek

Pomeranje bezbednosnog perimetra

Međutim, iako Active Directory i dalje dobro radi svoj posao, to ne znači da taj posao obuhvata čitavu sliku modernog identiteta. Entra ID, dakle, nije Active Directory u cloudu, već drugačiji sistem, napravljen za drugačiji svet. AD govori jezik domena, Kerberosa i NTLM-a – protokola za mrežu u kojoj su uređaji, korisnici i domenski kontroleri deo unapred uspostavljenog odnosa poverenja. Entra ID govori jezik otvorenog interneta – OAutha, SAML-a i OpenID Connecta, a pretpostavka da postoji jedno jasno definisano „unutra“ više ne važi sada, kada se korisnik prijavljuje sa svog telefona, iz kafića, na aplikaciju koja fizički radi na serveru u Švedskoj.

Entra ID nije Active Directory u cloudu, već drugačiji sistem, napravljen za drugačiji svet

Mrežni perimetar nije potpuno nestao, niti će, ali je definitivno prestao da bude jedina granica koju branimo. Korisnik, uređaj i aplikacija mogu se nalaziti bilo gde, pa se odluka o pristupu sve više donosi na osnovu toga ko se prijavljuje, sa kog uređaja, na koji način i pod kojim okolnostima. Drugim rečima, identitet je postao novi bezbednosni perimetar. Znam, ta rečenica vrti se unaokolo otkako je Zero Trust postao nezaobilazan buzzword, ali to što je izlizana u ovom slučaju ne znači i da nije tačna, već ovde precizno opisuje šta se zaista promenilo.

Pošto identitet više nije bio vezan za jednu mrežu, sledeće pitanje bilo je prilično praktično: kako sprečiti da isti čovek dobije dva odvojena identiteta čim kompanija počne da koristi cloud? Odgovor je bio hibridni identitet. Korisnik se i dalje kreira u Active Directoryju, odatle dobija ime, lozinku, članstva u grupama i pristup starim aplikacijama, a zatim se preko Microsoft Entra Connecta ili Cloud Synca pojavljuje i u Entra ID-ju. Korisnicima je to jedan nalog. Za administratora su to dva direktorijuma, dva odvojena modela rada i čitav niz sync pravila koja ih drže usklađenim.

Taj model je godinama imao vrlo jasan smer kretanja. Korisnik nastaje u AD-u, tamo se menja i tamo se, na kraju, gasi. Entra ID samo preuzima ono što mu sinhronizacija pošalje. Ako je neki atribut dolazio iz lokalnog direktorijuma, taj atribut je u Entra ID-ju bio samo za čitanje. Administrator koji bi pokušao da promeni takvog korisnika na pogrešnom mestu suočavao se sa famoznim sivim poljem u admin portalu (Koliko sam samo puta reagovao na tikete i odgovarao na pozive zbog njega!). Drugim rečima, AD je bio „source of authority“, original. Entra ID bio je njegova upotrebljiva, ali ipak kopija namenjena cloud servisima.

Most između dva sveta

To je dugo bilo sasvim logično: ako lokalne aplikacije, računari i serveri i dalje zavise od AD naloga, prirodno je da se tim nalozima upravlja tamo gde su nastali. Problem je što su se, vremenom, mnogi korisnici gotovo potpuno preselili u cloud, dok su njihovi nalozi ostali prikovani za lokalni direktorijum. Mailbox je u Exchange Onlineu, dokumenti na SharePointu, uređaj je Entra joined i pod Intune upravljanjem, ali promena prezimena ili odeljenja korisnika i dalje prvo mora da prođe kroz Active Directory konzolu, pa kroz sinhronizaciju. U tom trenutku hibrid više nije samo most između dva sveta. Za neke kompanije sigurno postoje razlozi da stari svet održavaju duže nego što im je zaista potreban.

Ovde dolazi do promene koja je, po mom mišljenju, mnogo važnija od još jednog novog portala ili preimenovanog, „ispoliranog“ servisa. Ideja je krenula kao preview za grupe još prošle godine, a od januara ove godine je i prebacivanje „source of authority“ (SOA) za pojedinačne korisnike zvanično stiglo i do opšte dostupnosti. U praksi to znači da autoritet za odabrane sinhronizovane korisnike, grupe i kontakte može da pređe sa lokalnog Active Directoryja na Microsoft Entra ID. Pritom, nema potrebe da se napravi svojevrsni rez, odnosno prekine sinhronizacija za čitavu organizaciju, niti da se svi objekti odjednom proglase za cloud-only. Prelazak može da se odvija u talasima ili objekat po objekat, tamo gde je to tehnički i poslovno opravdano.

Ono što se lako da prevideti jeste da prebacivanje izvora autoriteta menja i to „ko pobeđuje“ ako dođe do konflikta. Dok je ranije AD imao poslednju (često i jedinu) reč, sada je to Entra ID – izmena napravljena direktno u AD-u pri sledećem sinhronizacionom ciklusu jednostavno se ignoriše. Za administratore to znači da SOA prelazak zahteva i pripremu, a ne jednostavan klik: treba znati koji atributi i koji ekosistemi, recimo Exchange Hybrid, i dalje računaju na to da AD ima poslednju reč.

Bezbednost u hibridnom okruženju

Kod security grupa priča je još zanimljivija. Grupa koja je godinama nastajala i menjala se u AD-u može da postane upravljiva iz clouda, dok se njeno članstvo ponovo provisionuje nazad u Active Directory. Entra može – i treba – da bude mesto na kojem se takve odluke donose, a Active Directory je okruženje koje tu odluku samo prenosi staroj Kerberos ili LDAP aplikaciji. Čak se može podeliti i autoritet nad jednim korisnikom: identitetski atributi tako mogu ostati pod kontrolom Active Directoryja, dok se Exchange atributima upravlja direktno iz clouda.

Bezbednosna strana priče dobila je potvrdu početkom juna, kada je Microsoft pooštrio takozvani „hard match“ – automatsko povezivanje AD naloga sa postojećim cloud nalogom. Ako je cloud nalog već dobio neku privilegovanu Entra rolu, sinhronizacija neće više sama smeti da mu promeni autoritet na osnovu podataka iz Active Directoryja. Na prvi pogled zvuči sitno – makar je meni bilo kada sam prvi put pročitao ovu vest – ali zapravo zatvara realan scenario eskalacije privilegija, u kome bi napadač sa pristupom lokalnom AD-u mogao da preuzme i privilegovani cloud identitet. Kada se identitet posmatra kao perimetar, ovakve izmene nikako nisu kozmetičke, već su deo istog zaokreta o kome sam pisao na početku članka.

Ako bismo posmatrali hibridni identitet kao neku topologiju, do sada je Active Directory bio rezervisan isključivo kao glavni čvor, koji dalje svoj autoritet prenosi na ogranke. Od sada, to nije i ne treba da bude slučaj. Sada svesno možemo odlučivati gde se i za šta nalazi autoritet u našem hibridnom okruženju.

Active Directory time nije „umro“ po ko zna koji put, ali prvi put postaje realnost da organizacije postepeno smanjuju njegovu ulogu, korisnik po korisnik, grupa po grupa. Organizacije ne vole nagle promene: SOA im upravo daje mogućnost da zavisnost od lokalnog direktorijuma smanjuju tamo gde ima smisla, umesto da biraju između večnog hibrida i velikog, rizičnog reza preko noći.

Petar Jurjević, COMING

The post Upravljanje identitetima u hibridnom okruženju appeared first on Business&IT.

COMING

Centralizovano upravljanje identitetima

Zašto centralizovano upravljanje identitetima postaje temelj savremenog poslovnog softvera? Jedan identitet. Jedan pristup. Jedan digitalni ekosistem.

Prosečan zaposleni u većoj kompaniji danas svakodnevno koristi pet, deset ili više različitih poslovnih aplikacija. Svaka od njih ima svoju listu korisnika, svoja pravila o lozinkama i svoj način dodele privilegija. Za korisnika to znači niz prijava koje treba zapamtiti, pa lozinke često završe na papiriću ispod tastature. Za IT službu to znači isto toliko odvojenih evidencija koje treba održavati. A za kompaniju, to je bezbednosni rizik koji raste sa svakom novom aplikacijom.

Odgovor na taj problem je promena pristupa: identitet korisnika prestaje da bude podatak koji svaka aplikacija čuva za sebe i postaje zajednički resurs celog poslovnog sistema. Jedan identitet, jedan pristup, jedan digitalni ekosistem.

Pre i posle: Kraj priče o zaboravljenim lozinkama

Bez centralizovanog identiteta, dan zaposlenog počinje serijom prijava. Novi kolega čeka da mu se nalozi otvore u svakoj aplikaciji ponaosob, često nekoliko dana i uz nekoliko zahteva IT službi. Kada neko napusti kompaniju, deaktivacija se radi po listi koja je retko potpuna, pa pojedini nalozi ostaju aktivni znatno duže nego što bi trebalo. Služba korisničke podrške, u međuvremenu, značajan deo kapaciteta troši na obnavljanje zaboravljenih lozinki.

Sa jedinstvenim identitetom i mehanizmom jedinstvene prijave (eng. Single Sign-On) taj scenario menja se iz korena.

Korisnik se prijavljuje jednom, na početku radnog dana, i kreće se kroz sve aplikacije bez ponovne autentifikacije, bez osećaja da koristi više nepovezanih sistema.

Po odlasku zaposlenog jednim postupkom se ukida pristup svim povezanim aplikacijama, bez liste za proveru i bez naloga koji ostaju aktivni mesecima.

Centralno upravljanje korisnicima i federacija identiteta

Tehnološku osnovu takvog pristupa čini centralni sistem za upravljanje identitetima i pristupima. U našim rešenjima tu rolu ima Keycloak, koji ne služi samo kao mesto gde se korisnici prijavljuju, već i kao posrednik ka postojećim sistemima za upravljanje identitetima u infrastrukturi klijenta: Active Directory, Entra ID, Ping i drugi.

Ta federacija identiteta praktično znači da kompanija koja već ima svoj sistem za upravljanje identitetima ne mora da menja način na koji vodi svoje zaposlene. Korisnici tada ostaju tamo gde su i do sada bili i prijavljuju se svojim postojećim korporativnim akreditivima. Kompanija pritom zadržava svoja pravila, od politike lozinki i višefaktorske autentifikacije do procedura pri zapošljavanju i odlasku, a centralni sistem tu proveru identiteta prihvata kao verodostojnu i odatle prenosi jedinstvenu prijavu na sve aplikacije u ekosistemu. Ako takvog sistema nema, mi ga uz ovo rešenje uspostavljamo: Keycloak i Organization Management postaju to jedinstveno mesto za upravljanje korisnicima i temelj celog ekosistema. Nema paralelne evidencije korisnika, ni dvostrukog unosa podataka o zaposlenima. Identiteti i njihove uloge vode se na jednom mestu, a konkretne privilegije dodeljuju se u samoj aplikaciji, tako da IT služba u svakom trenutku ima jasan odgovor na pitanje ko čemu ima pristup.

Identiteti i njihove uloge vode se na jednom mestu, a konkretne privilegije dodeljuju se u samoj aplikaciji, tako da IT služba u svakom trenutku ima jasan odgovor na pitanje ko čemu ima pristup

Više instanci, jedna kontrola pristupa

Uobičajeno je da jedna aplikacija u okviru iste organizacije radi na više instanci, na primer, za različite organizacione jedinice, zavisna društva ili poslovne linije. Bez centralnog identiteta svaka takva instanca postaje mali samostalan sistem, sa sopstvenom listom korisnika, što veoma brzo postaje teško za praćenje.

Sa jedinstvenim modelom identiteta korisnik ostaje jedan, a njegove privilegije definišu se po instanci. Isti zaposleni može imati administratorska prava u jednoj, pravo pregleda u drugoj i nikakav pristup trećoj instanci, bez dodatnih naloga i bez ponovne prijave. Kada se organizaciona struktura promeni ili zaposleni pređe na novu poziciju, menja se samo nivo njegovih prava, a ne i broj naloga.

Identitet ne pripada samo ljudima. Aplikacije razmenjuju podatke i onda kada niko nije prijavljen, pa i one moraju da imaju svoj identitet. U starijim sistemima to je najčešće bila jedna zajednička lozinka upisana u podešavanjima, koju niko ne menja godinama i za koju se vremenom više i ne zna ko je sve koristi.

Servisni nalozi to rešavaju drugačije. Svaka aplikacija dobija sopstveni nalog, sa jasno određenim pravima, koji se može ukinuti nezavisno od ostalih, a njene akcije ostaju vidljive u evidenciji. U zapisu tada ne stoji bezlična sistemska poruka, već ime aplikacije koja je akciju izvršila.

Jedinstvena evidencija i potpun uvid u aktivnosti

Možda najveća, a najmanje očigledna prednost jedinstvenog identiteta jeste upravo potpun uvid u aktivnosti korisnika. Kada isti identitet postoji u svim aplikacijama, lako je videti koje je akcije jedan korisnik izvršio, bez obzira na to u kom je sistemu radio. Praćenje aktivnosti prestaje da bude posao sastavljanja izveštaja iz pet različitih logova, u pet različitih formata zapisa.

Benefiti su vrlo praktični. Svaki zapis, u svakoj aplikaciji, vezan je za isti identitet, pa se aktivnosti jednog zaposlenog prate kroz ceo ekosistem bez ručnog uparivanja naloga po sistemima. Umesto sastavljanja izveštaja iz pet različitih logova, dovoljno je zapise filtrirati po identitetu i periodu, a odgovor na pitanje ko je pristupio kojim podacima, kada i u kom obimu, postaje izveštaj koji se generiše za nekoliko minuta, a ne višednevno istraživanje.

Identitet kao infrastruktura

Centralno upravljanje identitetima nije samo bezbednosna mera, ono je i razvojna infrastruktura. Standardizovan model autentifikacije i autorizacije znači da nova aplikacija ne mora da rešava upravljanje korisnicima od nule. Organization Management (OM) tu donosi najveću korist: nova aplikacija se na njega jednostavno poveže i odmah dobija kompletno upravljanje korisnicima, servisnim nalozima i ulogama, dok konkretne privilegije ostaju definisane u samoj instanci aplikacije, tamo gde i pripadaju. Samo u startnoj fazi razvoja to skraćuje posao za nekoliko radnih nedelja po aplikaciji.

Jedinstven identitet je jedna od onih investicija koje se ne vide na prvi pogled, a osete se svuda – u brzini kojom novi zaposleni postaje produktivan, u sigurnosti da nakon odlaska kolege nijedan pristup nije ostao otvoren, u lakoći kojom revizor dobija odgovor i u vremenu koje razvojni tim ne mora da potroši na rešavanje istog problema iznova. Aplikacije će se menjati i smenjivati, ali identitet korisnika je ono što ekosistem drži na okupu. Zato ga i treba tretirati kao infrastrukturu, a ne kao detalj svake pojedinačne aplikacije. Vrednost te odluke je i u tome što se donosi jednom – svaka nova aplikacija naslanja se na postojeći model identiteta, umesto da donese još jednu listu korisnika.

Jedinstven identitet je jedna od onih investicija koje se ne vide na prvi pogled, a osete se svuda

Kako započeti integraciju? Put ka integraciji počinje procenom postojeće infrastrukture za upravljanje identitetima u kompaniji. Na osnovu te procene bira se model: federacija sa postojećim sistemom ili uspostavljanje novog centralnog mesta za upravljanje korisnicima. Posle toga se, zahvaljujući standardizovanom modelu, svaka naredna aplikacija priključuje brzo i bez ponovnog rešavanja upravljanja korisnicima. Kompanija koja uđe u integraciju sa nama dobija jedinstven, standardizovan temelj identiteta, bez obzira na to sa koje tačke kreće.

Darko Stošić i Andrija Milosavljević, COMING

The post Centralizovano upravljanje identitetima appeared first on Business&IT.

The post Bezbedno otključajte GenAI potencijale uz Check Point appeared first on Business&IT.

The post Benefiti uvođenja Business Central ERP-a appeared first on Business&IT.

The post Revolucija u upravljanju dokumentima appeared first on Business&IT.

The post Unapređenje IT infrastrukture pametne zgrade appeared first on Business&IT.

The post Bezbedan centralizovani pristup IT resursima appeared first on Business&IT.

The post Prevencija umesto reakcije appeared first on Business&IT.