Cele mai importante riscuri Microsoft 365 nu provin din lipsa unei singure tehnologii, ci din combinația dintre identități insuficient protejate, privilegii permanente, acces excesiv la date, protecție incompletă a emailului, logging insuficient și recovery netestat. Controlul real apare când aceste zone sunt configurate, monitorizate și susținute de dovezi verificabile.
O compromitere de cont Microsoft 365 nu începe, de regulă, cu un atac sofisticat asupra infrastructurii.
Poate începe cu un utilizator insuficient protejat, o regulă de redirecționare creată discret într-o căsuță poștală sau un administrator cu privilegii permanente.
Aceste situații pot expune date sensibile, afecta operațiunile și lăsa organizația fără suficiente dovezi pentru a demonstra ce s-a întâmplat, cine a avut acces și dacă măsurile de control funcționau.
Microsoft 365 oferă capabilități extinse pentru identitate, colaborare, protecția informației, endpoint security și monitorizare.
Dar tehnologia disponibilă nu înseamnă automat control.
Diferența este dată de configurare, ownership, monitorizare și dovezile păstrate pentru verificarea eficacității controalelor.
01. Cum trebuie evaluate riscurile Microsoft 365
O evaluare utilă nu pornește de la o listă generică de setări recomandate.
Pornește de la procesele critice, tipurile de date prelucrate, conturile privilegiate, dependența de serviciile cloud și obligațiile aplicabile organizației.
Pentru organizațiile aflate în domeniul de aplicare NIS2 sau pentru furnizorii care susțin servicii și procese critice, aceeași configurație greșită poate produce consecințe foarte diferite în funcție de impactul asupra operațiunilor.
Directiva NIS2 include între măsurile de management al riscului securitatea lanțului de aprovizionare, controlul accesului, continuitatea activității, backupul, evaluarea eficacității măsurilor de securitate și utilizarea autentificării multifactor sau a autentificării continue atunci când este adecvat.
Vezi textul oficial al Directivei (UE) 2022/2555 — NIS2 .
Cadrul practic poate fi păstrat simplu: identificăm expunerea, evaluăm impactul și probabilitatea, atribuim un owner, implementăm remedierea și verificăm dovada.
O politică aprobată fără rapoarte de conformitate, jurnale, rezultate de test sau revizuiri periodice rămâne o intenție.
02. MFA incomplet sau insuficient de rezistent la phishing
Autentificarea multifactor este una dintre cele mai importante bariere împotriva compromiterii identității.
O implementare parțială poate însă crea o falsă senzație de siguranță.
Problemele apar prin excluderi vechi, metode de autentificare mai slabe, conturi administrative tratate la fel ca utilizatorii obișnuiți sau politici Conditional Access care nu acoperă toate scenariile relevante.
Riscul devine material atunci când un atacator obține parola prin phishing, credential reuse sau compromiterea credențialelor și găsește o metodă de autentificare insuficient protejată.
Pentru rolurile administrative, Microsoft recomandă politici Conditional Access care impun metode de autentificare rezistente la phishing.
Acestea pot include passkeys/FIDO2, Windows Hello for Business și certificate-based authentication, în funcție de arhitectură și scenariul de utilizare.
Vezi documentația Microsoft: Require phishing-resistant MFA for administrator roles .
Remedierea nu înseamnă doar activarea MFA.
Este necesară aplicarea prin politici Conditional Access , separarea conturilor administrative, reducerea excluderilor la cazuri documentate și revizuirea periodică a metodelor de autentificare.
Ce trebuie să rămână ca dovadă
- inventarul excluderilor Conditional Access;
- politicile aprobate și configurația implementată;
- acoperirea MFA;
- metodele de autentificare utilizate;
- rezultatele testelor pentru scenarii de acces neautorizat.
03. Privilegii permanente și administrare fără PIM/JIT
Conturile cu roluri administrative permanente reprezintă o țintă cu impact ridicat.
Compromiterea unui administrator cu privilegii extinse poate permite modificarea politicilor, crearea de identități, schimbarea metodelor de autentificare sau obținerea persistenței în tenant.
Principiul minimului privilegiu trebuie aplicat nu doar la nivel de rol, ci și la durată, context și justificare.
Microsoft Entra Privileged Identity Management permite gestionarea accesului privilegiat temporar, inclusiv activări just-in-time și controale precum justificare, aprobare și MFA.
Aceste mecanisme pot introduce un mic efort operațional, în special în intervențiile urgente.
Soluția nu este însă păstrarea privilegiilor permanente din comoditate, ci existența unor proceduri de urgență și a unor conturi break-glass protejate, monitorizate și testate.
Vezi și: ce este accesul PIM și modelul Just-In-Time .
Dovezile relevante
- lista rolurilor privilegiate;
- istoricul activărilor PIM;
- justificările și aprobările;
- access reviews;
- testele periodice ale conturilor de urgență.
Un export punctual nu este suficient.
Controlul trebuie să demonstreze că revizuirea se repetă și că accesul care nu mai este justificat este retras.
04. Acces extern necontrolat în Teams, SharePoint și OneDrive
Colaborarea externă este necesară pentru proiecte, furnizori și clienți.
Devine risc atunci când organizația nu mai poate răspunde clar la trei întrebări: ce date sunt partajate, cu cine și pentru cât timp?
Linkurile anonime, invitații rămași activi după finalizarea unei colaborări, permisiunile moștenite și grupurile cu acces prea larg sunt exemple tipice de expunere.
Impactul nu se limitează la pierderea confidențialității.
Documentele pot conține date personale, informații comerciale, arhitecturi tehnice, contracte sau chiar dovezi de conformitate.
Microsoft permite configurarea nivelurilor de external sharing pentru SharePoint și OneDrive, limitarea utilizatorilor care pot partaja extern și gestionarea accesului guest.
Vezi: Microsoft SharePoint and OneDrive external sharing .
Pentru informațiile sensibile, sensitivity labels, restricțiile de acces și revizuirile periodice trebuie aliniate cu procesele reale de business.
Ce verificăm
- external sharing configuration;
- guest inventory;
- anonymous links;
- site și group permissions;
- access reviews;
- sensitivity labels și restricțiile aplicate.
05. Protecție insuficientă împotriva phishingului și BEC
Business Email Compromise este periculos tocmai pentru că exploatează procese reale: facturi, schimbări de cont bancar, aprobări de plată sau solicitări urgente aparent venite din partea managementului.
Filtrele antispam și antiphishing sunt necesare, însă nu elimină nevoia unor controale tehnice și operaționale suplimentare.
Un atacator care compromite o căsuță poștală poate urmări conversațiile existente și poate încerca să creeze reguli de inbox sau mecanisme de forwarding pentru a menține accesul la fluxurile de comunicare.
Protecția trebuie să combine politicile antiphishing, protecția împotriva impersonării și, acolo unde licențierea și arhitectura o permit, capabilități precum Safe Links și Safe Attachments.
SPF, DKIM și DMARC trebuie de asemenea configurate și monitorizate în funcție de domeniile și serviciile care trimit email în numele organizației.
Pentru procesele financiare, controalele tehnice trebuie completate de verificări independente pentru modificările de cont bancar sau instrucțiunile de plată.
06. Logging insuficient și retenție nealiniată cu investigația
Fără logging adecvat, organizația poate ajunge să nu poată răspunde credibil la întrebările de bază după un incident.
Ce identitate a fost utilizată?
Ce fișiere au fost accesate?
Ce reguli sau configurații au fost modificate?
Cât timp a persistat activitatea malițioasă?
Microsoft Purview Audit oferă capabilități și perioade de retenție care depind de licențiere, configurație și tipurile de activitate.
Organizația nu ar trebui, prin urmare, să presupună că retenția implicită este automat suficientă pentru propriile scenarii de investigație.
Vezi documentația Microsoft Purview Audit retention policies .
Este necesar să se stabilească ce evenimente sunt critice, unde sunt colectate, cine le monitorizează și cât timp trebuie păstrate.
Retenția trebuie corelată cu timpul realist de detectare, obligațiile aplicabile și capacitatea de investigație.
07. Backup confundat cu continuitatea operațională
Faptul că datele sunt găzduite într-o platformă cloud nu înseamnă că organizația și-a rezolvat automat toate scenariile de recuperare.
Ștergerea accidentală, ștergerea malițioasă, erorile de configurare, expirarea retenției sau compromiterea unui cont privilegiat pot afecta datele și capacitatea de lucru.
Microsoft oferă mecanisme native de retenție și recuperare, precum și Microsoft 365 Backup pentru scenarii de restaurare în Exchange Online, SharePoint și OneDrive.
Decizia privind utilizarea controalelor native, Microsoft 365 Backup sau a unei soluții suplimentare trebuie făcută pornind de la cerințele reale ale organizației.
Întrebarea corectă nu este doar „avem backup?”.
Întrebarea este în cât timp putem recupera procesul și câtă informație ne permitem să pierdem.
Aceste cerințe trebuie traduse în RTO și RPO și validate prin teste de restaurare.
08. Copilot și AI utilizate fără reguli de date și ownership
Microsoft 365 Copilot funcționează peste identitatea, datele și controalele existente în ecosistemul Microsoft 365 și operează în contextul permisiunilor utilizatorului.
Tocmai de aceea, permisiunile incorecte devin importante.
Dacă utilizatorii au deja acces excesiv la site-uri SharePoint, documente sau spații de colaborare, Copilot poate face informația respectivă mai ușor de descoperit și utilizat în limitele accesului existent.
Microsoft recomandă pregătirea unui secure and governed data foundation pentru Copilot și identificarea conținutului overshared înainte și în timpul adopției.
Vezi: Microsoft 365 Copilot architecture, data protection and auditing .
Governance-ul trebuie însă să depășească configurația tehnică.
Organizația trebuie să știe ce instrumente și use case-uri AI utilizează, cu ce date, cine este owner și ce reguli se aplică.
Obligațiile EU AI Act depind de rolul organizației, tipul sistemului și cazul concret de utilizare.
Nu orice utilizare Copilot generează automat aceleași obligații. Este însă necesară o analiză structurată a use case-urilor, datelor, riscurilor și responsabilităților aplicabile.
Dovezile utile pentru AI governance
- inventarul instrumentelor și use case-urilor AI;
- owner și scop documentat;
- evaluări de risc;
- reguli de utilizare acceptabilă;
- data classification și access reviews;
- aprobări și excepții;
- audit records și revizuiri periodice.
09. De la setări izolate la un sistem de control verificabil
Cele mai multe organizații nu au o singură problemă în Microsoft 365.
Au un cumul de excepții istorice, permisiuni extinse, configurații vechi și responsabilități insuficient definite.
Prioritizarea trebuie să înceapă cu riscurile care pot produce cel mai mare impact: identitatea, privilegiile, accesul la date, colaborarea externă, capacitatea de detectare și continuitatea proceselor critice.
Un registru de risc bine construit leagă fiecare constatare de:
- activul afectat;
- scenariul de amenințare;
- impactul de business;
- probabilitate;
- owner;
- măsura de remediere;
- termen;
- dovada de închidere.
Această disciplină permite managementului să decidă informat și auditorilor să verifice nu doar existența tehnologiei, ci eficacitatea controlului.
Într-un mediu Microsoft 365 matur, întrebarea nu mai este doar ce licențe sau funcții sunt active.
Întrebarea utilă nu este „ce licențe avem?”
Întrebarea este dacă organizația poate demonstra că identitățile, datele și serviciile sale critice rămân sub control atunci când apare un incident.
Putem demonstra că MFA acoperă identitățile relevante?
Putem demonstra că privilegiile sunt temporare și revizuite?
Știm ce date sunt partajate extern?
Putem reconstrui un incident din logurile disponibile?
Putem restaura datele în intervalele asumate de business?
Știm ce date poate accesa Copilot prin permisiunile existente?
Dacă aceste răspunsuri nu pot fi susținute cu dovezi actuale, problema nu mai este doar una de configurare.
Este o problemă de control.