„Dar merge.” De ce am migrat totuși infrastructura și emailul în Microsoft 365

A fost unul dintre primele proiecte HAVOC IT și, la prima vedere, nu exista nimic urgent de reparat. Cele patru stații de lucru funcționau, oamenii își făceau treaba, iar cele cinci căsuțe de email găzduite în cPanel trimiteau și primeau mesaje fără probleme evidente.

Majoritatea activității companiei se desfășura oricum în Outlook, Word și Excel, împreună cu documente PDF. Din perspectiva utilizatorilor, lucrurile funcționau. Nu aveam un server căzut, nu aveam un serviciu indisponibil și nici un incident care să ne oblige să intervenim.

Cu alte cuvinte, sistemul mergea.

Și tocmai de aici a pornit proiectul. Nu toate schimbările de infrastructură trebuie să înceapă după ce ceva se strică. Uneori întrebarea nu este dacă sistemul funcționează astăzi, ci dacă modul în care este construit mai corespunde felului în care compania vrea să lucreze mâine.

Ce înseamnă, de fapt, „merge”

Din perspectiva celui care lucrează zilnic pe calculator, lucrurile erau destul de simple. Pornea stația, deschidea Outlook, trimitea emailuri, modifica un Excel, lucra într-un document Word și consulta PDF-urile de care avea nevoie. Dacă toate acestea funcționează, este normal să consideri că infrastructura este în regulă.

Din perspectiva administrării IT însă apar alte întrebări. Cum gestionăm identitățile utilizatorilor? Cum retragem accesul dacă cineva pleacă? Cum administrăm mai multe stații fără să intervenim manual pe fiecare dintre ele? Cum aplicăm politici comune și ce vizibilitate avem asupra endpoint-urilor?

Mai exista și problema accesului la documente. Dacă un utilizator avea nevoie să lucreze din afara biroului, puteam construi o soluție clasică bazată pe VPN și acces la resursele locale. Tehnic era perfect posibil.

Dar înainte să construiești o soluție merită uneori să te întrebi dacă problema mai trebuie să existe în forma respectivă.

De ce Microsoft 365

Nu am plecat de la ideea că cPanel este nesigur sau că orice infrastructură locală trebuie mutată în cloud. Ar fi o concluzie prea simplă. cPanel poate fi administrat corect, iar Microsoft 365 poate fi configurat foarte prost.

În cazul acestui client, avantajul Microsoft 365 era faptul că mai multe componente care până atunci erau administrate separat puteau fi aduse într-un model comun. Identitățile utilizatorilor puteau fi gestionate prin Microsoft Entra ID, dispozitivele puteau fi administrate prin Intune, emailul putea fi mutat în Exchange Online, iar documentele companiei puteau fi organizate în SharePoint.

Clientul avea licențe Microsoft 365 Business Premium, ceea ce ne oferea și Microsoft Defender for Business pentru protecția endpoint-urilor. Nu trebuia să cumpărăm separat o platformă EDR doar pentru aceste câteva dispozitive și nici nu trebuia să construim o infrastructură disproporționat de complexă pentru dimensiunea companiei.

Nu încercam să transformăm patru calculatoare într-un mediu enterprise.

Încercam doar să administrăm mai simplu patru calculatoare.

Cinci mailbox-uri și mai mult decât schimbarea unui MX

Partea de email era găzduită în cPanel și cuprindea cinci căsuțe poștale. Mutarea către Exchange Online nu însemna însă doar schimbarea înregistrării MX și așteptarea mesajelor noi.

În căsuțele existente se afla deja corespondența utilizatorilor, iar aceasta trebuia păstrată. Mesajele și structura folderelor de email au fost migrate prin IMAP către Exchange Online, astfel încât utilizatorii să își regăsească istoricul după mutare.

Este o diferență importantă aici: o migrare IMAP mută mesajele și folderele de email, nu un mailbox Exchange complet cu calendare, contacte și task-uri. În cazul nostru, ceea ce trebuia păstrat era corespondența existentă, așa că metoda se potrivea proiectului.

În paralel am configurat DNS-ul domeniului pentru Microsoft 365. Înregistrarea MX a fost schimbată pentru ca mesajele noi să ajungă în Exchange Online, iar Autodiscover a fost configurat astfel încât Outlook să poată identifica automat serviciul Exchange corespunzător.

SPF, DKIM și DMARC

Odată cu mutarea emailului am configurat și mecanismele de autentificare a domeniului: SPF, DKIM și DMARC.

SPF declară ce infrastructură este autorizată să trimită mesaje pentru domeniul respectiv. În cazul nostru, Microsoft 365 trebuia să fie recunoscut drept una dintre sursele legitime de email.

Pentru DKIM am publicat cele două înregistrări CNAME cerute de Microsoft 365, selector1 și selector2. La un moment dat unul dintre selectori este folosit pentru semnarea mesajelor, iar existența celui de-al doilea permite rotația cheilor DKIM fără întreruperea autentificării.

DMARC completează mecanismul prin verificarea alinierii dintre domeniul pe care utilizatorul îl vede în câmpul From și domeniile autentificate prin SPF sau DKIM. Tot prin DMARC poate fi definită politica aplicată mesajelor care pretind că provin de la domeniu, dar nu trec verificările necesare.

SPF, DKIM și DMARC nu fac phishingul imposibil și nici nu îl împiedică pe cineva să încerce să falsifice domeniul. Rolul lor este să reducă șansele ca un astfel de mesaj să fie acceptat de serverul destinatar ca mesaj legitim trimis în numele companiei.

Pentru utilizatori, toate acestea trebuiau să rămână aproape invizibile. După migrare trebuiau să își deschidă Outlook-ul și să continue să lucreze.

SharePoint în loc să construim accesul în jurul unui VPN

Partea de documente a fost probabil schimbarea care s-a potrivit cel mai natural modului în care oamenii lucrau deja. Majoritatea activității lor se întâmpla în Outlook, Word, Excel și în jurul documentelor PDF.

O variantă ar fi fost să păstrăm fișierele în infrastructura locală și să configurăm accesul din exterior prin VPN. Utilizatorul s-ar fi conectat mai întâi în rețeaua companiei, apoi ar fi accesat resursele locale folosind mecanismele de autentificare existente, inclusiv NTLM acolo unde infrastructura îl folosea.

Tehnic, soluția ar fi funcționat.

Dar dacă un utilizator are nevoie în principal de un Excel, un document Word sau un PDF, nu este obligatoriu să îl introduci mai întâi într-un VPN și apoi într-o rețea locală doar pentru a ajunge la fișier. În cazul acesta, problema putea fi rezolvată mai simplu.

Am creat o structură SharePoint pentru documentele companiei, iar accesul putea fi legat direct de identitatea Microsoft 365 a utilizatorului. Documentele puteau fi accesate din browser sau din aplicațiile Office folosite deja în activitatea zilnică, fără ca o stație fizică din birou să rămână punctul prin care trebuia să treacă fiecare acces.

Asta nu înseamnă că SharePoint este „mai bun decât VPN-ul”. Cele două rezolvă probleme diferite.

Dacă ai un ERP disponibil doar în LAN, o aplicație internă, un server care trebuie să rămână on-premises sau alte resurse locale, VPN-ul poate fi exact soluția corectă. Dar nu avea sens să construim o dependență față de VPN doar pentru a accesa documente Office care puteau fi gestionate direct în Microsoft 365.

Patru calculatoare pot fi administrate centralizat fără să complici lucrurile

Pe partea de endpoint-uri aveam patru workstation-uri. Nu era nevoie de zeci de politici și nici de un model construit pentru mii de dispozitive.

Stațiile au fost integrate în ecosistemul Microsoft, iar Intune ne oferea un mecanism central pentru administrarea dispozitivelor și aplicarea politicilor de care aveam nevoie. Pentru securitatea endpoint-urilor puteam folosi Microsoft Defender for Business, inclus în licența Microsoft 365 Business Premium a clientului.

Asta însemna că zona de protecție nu se limita la antivirusul clasic. Defender for Business oferă inclusiv capabilități de endpoint detection and response, vizibilitate asupra amenințărilor și instrumente pentru identificarea vulnerabilităților dispozitivelor.

Nu scopul nostru era însă să activăm fiecare funcție doar pentru că exista în licență. Avantajul era că aveam un punct central din care puteam administra dispozitivele și un set de instrumente de securitate pe care îl puteam adapta dimensiunii reale a clientului.

Dacă mâine trebuia schimbată o politică, verificată starea unui dispozitiv, retras un acces sau pregătită o stație nouă, mecanismul exista deja.

Identitatea a devenit punctul comun

Una dintre schimbările mai puțin vizibile pentru utilizator, dar importante pentru administrare, a fost faptul că identitatea începea să lege toate aceste componente.

Același utilizator avea identitatea administrată în Microsoft Entra ID, își folosea contul pentru Microsoft 365, își accesa emailul prin Exchange Online și putea primi acces la documentele din SharePoint. Dispozitivul pe care lucra putea fi, la rândul lui, administrat prin Intune.

Asta nu înseamnă că Microsoft 365 elimină automat toate problemele de securitate sau administrare. Dar reduce numărul de sisteme separate pe care trebuie să le urmărești și îți permite să construiești mai coerent în jurul identității utilizatorului.

Pentru un mediu cu patru stații poate părea o diferență minoră.

În administrarea de zi cu zi, însă, tocmai mediile mici beneficiază de faptul că nu trebuie să construiești câte o soluție separată pentru fiecare lucru.

„Dar merge” poate fi un argument foarte bun

Există o tentație în IT de a considera orice tehnologie veche drept o problemă care trebuie rezolvată.

Nu suntem de acord cu ideea asta.

Dacă un sistem funcționează, poate fi administrat în siguranță și răspunde cerințelor organizației, simplul fapt că există ceva mai nou nu este un motiv suficient pentru înlocuire.

„Dar merge” poate fi un argument foarte bun.

Doar că merită urmat de încă o întrebare:

Merge și pentru ceea ce vrem să facem în continuare?

În cazul clientului acesta, răspunsul era doar parțial. Emailul funcționa, stațiile funcționau, iar documentele puteau fi accesate. Dar modelul de lucru se potrivea mai bine unei infrastructuri în care identitatea, dispozitivele, emailul și documentele puteau fi gestionate mai unitar.

Decizia nu a fost între un sistem „vechi și prost” și unul „nou și bun”.

A fost între două moduri de a organiza aceeași muncă.

Unul dintre primele noastre proiecte

Migrarea nu a fost spectaculoasă. Au fost patru stații de lucru, cinci mailbox-uri, configurarea Microsoft 365, migrarea mesajelor prin IMAP, modificările DNS, SPF, cele două înregistrări DKIM, DMARC, Exchange Online, SharePoint, Intune și partea de protecție a endpoint-urilor.

Mare parte din muncă s-a făcut în câteva ore, la o cafea.

Nu a existat un server căzut pe care să îl readucem la viață și nici o companie blocată până când terminam intervenția. Am avut, în schimb, avantajul că lucrurile încă funcționau și puteam face schimbarea fără presiunea unui incident în desfășurare.

Și poate tocmai de aceea proiectul merită locul lui în Jurnalul IT.

Pentru că una dintre cele mai bune perioade în care poți schimba o infrastructură este atunci când încă funcționează. Ai timp să verifici, să migrezi și să testezi înainte ca o problemă să transforme aceeași schimbare într-o urgență.

În cazul acesta am plecat de la patru calculatoare, cinci adrese de email și niște documente Word, Excel și PDF de care oamenii aveau nevoie pentru munca de zi cu zi.

Nu am încercat să construim ceva mai complicat decât era necesar.

Am încercat doar să alegem o infrastructură care se potrivea mai bine modului în care oamenii lucrau deja.