Email Security Hardening – Deo 4: Google Workspace hardening

Prethodni deo serije pokrio je Exchange Online. Ovaj, poslednji deo serije prelazi na Google Workspace — drugu, vrlo rasprostranjenu cloud email i produktivnu platformu, sa sopstvenom terminologijom (2SV umesto MFA, Context-Aware Access umesto Conditional Access) i specifičnim rizicima koji zaslužuju posebnu pažnju, posebno oko deljenja dokumenata i OAuth integracija — oblasti gde se Google Workspace suštinski razlikuje od Exchange Online pristupa obrađenog u prethodnom delu.

Deljena odgovornost — isti princip, ponovljen na novoj platformi

Isti obrazac koji smo naglasili za Exchange Online važi identično ovde: Google obezbeđuje snažnu baznu infrastrukturu (podaci enkriptovani i u mirovanju i u prenosu po difoltu), ali podrazumevana konfiguracija tenanta prioritizuje lakoću korišćenja nad bezbednošću. Mnoge organizacije završe početno podešavanje i nikad se ne vrate da revidiraju bezbednosna podešavanja u Admin Console-i, ostavljajući MFA nesprovedenom, eksterno deljenje neograničenim, i OAuth aplikacije nekontrolisanim — tri konkretne oblasti detaljno obrađene dalje u tekstu.

2-Step Verification — isti princip kao MFA, sa specifičnim Google Workspace detaljem oko super admin naloga

2-Step Verification (2SV) je Google-ov naziv za isti koncept MFA opisan kroz svaku prethodnu seriju na ovom blogu — Admin Console navigacija (Security → Authentication → 2-Step Verification) omogućava sprovođenje ove zaštite na nivou cele organizacije. Vredi istaći specifičan, Google Workspace karakterističan detalj oko super admin naloga koji zaslužuje pažljivo planiranje unapred.

Ako organizacija ima samo jedan super admin nalog, i ta osoba izgubi pristup (zaboravljena lozinka uz izgubljen drugi faktor, otpuštanje bez prethodnog prenosa pristupa, ili slično), proces oporavka administratorskog pristupa kroz Google-ovu podršku može trajati danima — period tokom kojeg organizacija efektivno nema mogućnost administracije sopstvenog Workspace okruženja. Ovo je suštinski drugačiji rizik od uobičajenog break-glass scenarija opisanog kroz druge serije na ovom blogu, gde je problem obično kompromitacija, ne gubitak pristupa kao takav.

Šta treba uraditi

• Sprovesti 2SV za sve korisnike bez izuzetka, prioritizujući hardverske sigurnosne ključeve ili passkeys nad SMS kodovima, koji ostaju podložni SIM-swapping napadima i slabiji su faktor od kriptografski baziranih alternativa
• Održavati dva do tri super admin naloga, ne jedan — bar jedan treba da bude dedikovan, isključivo-administratorski nalog (bez svakodnevne upotrebe za redovan rad), sa jakom, jedinstvenom lozinkom i hardverskim ključem za 2SV
• Čuvati kredencijale rezervnog super admin naloga na bezbednoj, fizički odvojenoj lokaciji (password manager sa ograničenim pristupom, ili fizički sef) — isti princip čuvanja break-glass kredencijala opisan kroz VMware, Proxmox i Windows Server hardening serije na ovom blogu
• Odvojiti administratorski nalog od svakodnevnog korisničkog naloga iste osobe — administratorski nalog ne treba da se koristi za čitanje mejla ili rad na dokumentima, isti princip opisan za Exchange Online administratore u prethodnom delu serije

Context-Aware Access — Google-ova implementacija zero trust principa

Context-Aware Access (izgrađen na Google-ovoj internoj BeyondCorp arhitekturi) je funkcionalna paralela Conditional Access-u iz Exchange Online sveta, opisanom u prethodnom delu serije — omogućava definisanje pristupnih politika na osnovu identiteta korisnika, stanja uređaja (da li je upravljan od strane organizacije, enkriptovan, sa uključenim zaključavanjem ekrana), i mrežne lokacije, umesto oslanjanja isključivo na ispravnost kredencijala.

Vredi napomenuti praktično ograničenje vezano za licencu: Context-Aware Access zahteva Enterprise Standard, Enterprise Plus, Education Plus, ili Cloud Identity Premium nivo pretplate — organizacije na nižim, često korišćenim nivoima (Business Starter, Standard, Plus) nemaju pristup ovoj funkciji, iako i dalje imaju osnovno sprovođenje 2SV i deo kontrola deljenja opisanih dalje u tekstu.

Šta treba uraditi

• Za organizacije sa odgovarajućom licencom, definisati pristupne nivoe (access levels) koji ograničavaju pristup osetljivim aplikacijama (Gmail, Drive) isključivo sa upravljanih, usklađenih uređaja — isti princip provere stanja uređaja opisan za Exchange Online device compliance u prethodnom delu serije
• Rasporediti Endpoint Verification na upravljane uređaje kako bi Context-Aware Access politike imale stvaran, ažuran signal o stanju uređaja (enkripcija, zaključavanje ekrana, verzija operativnog sistema) na osnovu kojeg donose odluke
• Za organizacije bez odgovarajuće licence, osloniti se na osnovno sprovođenje 2SV i kontrole deljenja kao polaznu, i dalje značajnu liniju odbrane, sa mogućnošću naknadne nadogradnje licence kad budžet i bezbednosni zahtevi to opravdaju
• Kombinovati Context-Aware Access sa integracijom spoljnog identity provajdera (Okta, Entra ID) preko SSO-a gde organizacija već ima uspostavljenu centralizovanu identity infrastrukturu, umesto vođenja potpuno odvojene politike pristupa specifične samo za Google Workspace

Drive deljenje — najčešći, a najlakše sprečiv izvor curenja podataka

Ovo zaslužuje poseban naglasak jer predstavlja konfiguraciju koja je specifična za Google Workspace (Exchange Online/SharePoint imaju analogan, ali drugačije strukturiran rizik) i istovremeno jednu od najčešće citiranih grešaka u praksi. Podešavanje deljenja "Anyone with the link" (bilo ko sa linkom) čini dokument dostupnim svakome ko dobije taj link, bez ikakve dalje autentifikacije ili provere identiteta — ako se link nenamerno prosledi dalje, indeksira se od strane pretraživača, ili jednostavno procuri, sadržaj postaje efektivno javan, bez obzira na originalnu nameru osobe koja je dokument delila.

Šta treba uraditi

• Onemogućiti opciju "Anyone with the link" deljenja na nivou cele organizacije kao podrazumevano stanje, postavljajući "Off (restricted)" kao podrazumevanu vrednost za nove fajlove
• Ograničiti eksterno deljenje na poverljive, unapred definisane domene (npr. poznati poslovni partneri) gde je eksterna saradnja stvarno potrebna, umesto potpunog, neselektivnog dozvoljavanja deljenja sa bilo kojim eksternim nalogom
• Redovno pregledati postojeće, već deljene dokumente kroz Admin Console izveštaje — dokumenti podeljeni pre uvođenja strožih pravila ostaju deljeni po starim, permisivnijim uslovima sve dok se eksplicitno ne isprave
• Obučiti korisnike o razlici između deljenja sa konkretnim, imenovanim osobama i deljenja "sa bilo kim ko ima link" — čest, nenameran uzrok curenja podataka je jednostavno biranje pogrešne, šire opcije iz praktičnosti, ne zlonamera

OAuth consent phishing — rizik specifičan za platforme sa bogatim ekosistemom aplikacija trećih strana

Ovo je tehnika vredna detaljnog objašnjenja, jer predstavlja zaobilazan put koji ne zahteva krađu lozinke niti zaobilaženje 2SV u klasičnom smislu. Napadač kreira naizgled legitimnu, često i uverljivo imenovanu aplikaciju trećeg lica, i putem phishing mejla ili lažne stranice navodi korisnika da tu aplikaciju autorizuje kroz standardan, legitiman Google OAuth ekran za odobrenje pristupa. Korisnik, videvši poznat, autentičan Google interfejs za odobrenje, često ne obraća dovoljno pažnje na to koje tačno dozvole aplikacija traži (čitanje mejlova, pristup Drive fajlovima, slanje mejlova u ime korisnika) i jednostavno klikne "Dozvoli". Nakon odobrenja, napadačeva aplikacija dobija trajan, programski pristup nalogu — bez ikad saznanja lozinke, i bez potrebe da ikad zaobiđe 2SV, jer je korisnik sam, svojevoljno, odobrio taj pristup.

Šta treba uraditi

• Ograničiti koje OAuth aplikacije trećih strana korisnici uopšte smeju da autorizuju, kroz Admin Console kontrolu pristupa aplikacijama — dozvoliti samo aplikacije sa unapred proverene, odobrene liste za osetljivije organizacije, ili bar zahtevati administratorsko odobrenje za aplikacije koje traže širok pristup (čitanje mejla, pristup Drive-u) pre nego što bilo koji korisnik može da ih autorizuje
• Redovno pregledati listu već autorizovanih aplikacija trećih strana kroz Admin Console i ukloniti pristup aplikacijama koje nemaju jasnu, i dalje važeću poslovnu svrhu — isti princip periodične revizije koji se provlači kroz svaku seriju na ovom blogu, ovde primenjen na OAuth grantove umesto na korisničke naloge ili dozvole
• Obučiti korisnike da prepoznaju OAuth consent ekran kao tačku odluke koja zaslužuje pažnju, ne kao rutinski korak koji se automatski potvrđuje — konkretan primer u obuci (pokazati stvaran, ali sumnjiv OAuth zahtev za širok pristup) daje bolji rezultat od apstraktnog upozorenja
• Za posebno osetljive, visoko-privilegovane naloge (super admin, izvršno osoblje), razmotriti upis u Google-ov Advanced Protection Program (APP) — program dizajniran specifično za naloge visokog rizika, sa strožim zahtevima za autentifikaciju i dodatnim ograničenjima upravo protiv ovakvih, suptilnijih tehnika napada

Gmail phishing i malware zaštita — konfigurabilna, ne samo podrazumevana

Isti princip koji smo naglasili za Defender for Office 365 u prethodnom delu serije primenjuje se i ovde — Gmail dolazi sa solidnom baznom zaštitom, ali napredne mogućnosti (sandboxing sumnjivih priloga, dodatno označavanje mejlova sa neverifikovanih izvora) zahtevaju svesnu konfiguraciju iznad podrazumevanog stanja.

Šta treba uraditi

• Uključiti napredne opcije phishing i malware zaštite u Gmail podešavanjima, uključujući sandboxing sumnjivih priloga pre isporuke, gde licenca to podržava
• Konfigurisati dodatno upozorenje ili označavanje za mejlove koji dolaze sa domena van organizacije, posebno onih koji oponašaju interne adrese ili izvršno osoblje — direktna primena principa impersonation zaštite opisanih u drugom delu serije, sada kroz Google Workspace specifičnu konfiguraciju
• Kombinovati ovo sa SPF/DKIM/DMARC podešavanjima iz prvog dela serije — Google Workspace, kao i Exchange Online, zahteva eksplicitno podešavanje DKIM potpisivanja kroz Admin Console za svaki domen, ne dolazi automatski uključeno po difoltu

Audit logovi i Security Center — vidljivost kao preduslov za odgovor

Isti princip centralizovane vidljivosti koji se provlači kroz celu ovu seriju blogova ima ovde konkretnu implementaciju kroz Admin Console izveštaje i Security Center investigation alat.

Šta treba uraditi

• Pregledati Security Health stranicu (Admin Console → Security → Security Health) redovno — ovo daje strukturisan, brz pregled trenutne konfiguracije naspram Google-ove preporučene bazne linije, direktno ukazujući na podešavanja koja padaju ispod preporučenog praga
• Konfigurisati alert centar sa prioritetnim upozorenjima — sumnjiva prijava, masovno deljenje dokumenata, DLP incidenti — kako bi bezbednosno relevantni događaji generisali aktivno obaveštenje, ne samo pasivan zapis u logu
• Izvoziti audit logove (prijave i administratorske akcije) redovno kroz Reports API ka centralnom SIEM sistemu gde organizacija ima takvu infrastrukturu, po istom principu centralizovanog logovanja koji se provlači kroz svaku seriju na ovom blogu
• Uspostaviti jasan, dokumentovan proces odgovora za kompromitovan nalog — trenutan reset lozinke, opoziv svih aktivnih sesija, pregled nedavne aktivnosti na znake curenja podataka, i ponovna registracija 2SV — pripremljen unapred, ne smišljen prvi put u trenutku stvarnog incidenta

Ovim se zaokružuje cela serija o email bezbednosti — od tehničke autentifikacije (SPF, DKIM, DMARC), preko anti-phishing i BEC principa nezavisnih od platforme, do konkretne primene kroz dve najrasprostranjenije poslovne platforme, Exchange Online i Google Workspace. Isti obrazac koji povezuje ovu seriju sa svakom prethodnom na ovom blogu ostaje nepromenjen do kraja: tehnička kontrola postavlja osnovu, ali disciplina held pristupa, kontinuirano praćenje, i realno razumevanje granica onoga što tehnologija sama može da spreči određuju stvarnu razliku između organizacije koja izgleda bezbedna na papiru i one koja to zaista jeste.