M365 drošība: ko pārbaudīt pirms auditors to atrod

Ievads

M365 drošības labākā prakse nav stāsts par vienu rīku vai vienu iestatījumu. Ikdienā problēma sākas citur: piekļuves tiesības aug ātrāk nekā cilvēku maiņas, faili tiek glabāti dažādās vietās ar atšķirīgiem nosaukumu paradumiem, bet drošības pārskati tiek skatīti tikai pēc incidenta. Tieši tāpēc konsultanta darbā vispirms jāsalāgo identitāte, dati, ierīces un administrēšana, nevis jāmeklē viens “drošais” slēdzis. Microsoft drošas nākotnes iniciatīvas modeļi un prakse ir organizēti pēc sešiem SFI pīlāriem, un katrs no tiem sniedz atkārtojamus norādījumus reāliem riskiem, tostarp identitātes apdraudējumiem un mantotām sistēmām [1]. Praktiski tas nozīmē: pārskatīt, kurš tieši drīkst piekļūt kritiskām vidēm, kur tiek glabāti sensitīvi dokumenti, kā tiek nosaukti faili un mapes, un kā tiek kontrolēta jaunu platformu, tostarp aģentu, ieviešana. Ja uzņēmumā ir 50–500 darbinieku, drošības robežas visbiežāk pārrauj nevis sarežģīti uzbrukumi, bet nepamanīti izņēmumi ikdienas procesos. Tāpēc šī pieeja sākas ar skaidriem soļiem: no identitātes līdz datu glabāšanai, no uzraudzības līdz drošai pārvaldībai.

1. Identitātes pārbaude kā pirmais kontroles punkts

Ja identitātes pārbaude M365 vidē tiek atstāta uz “vēlāk”, pārējie drošības slāņi sāk balstīties uz pieņēmumu, ka lietotājs tiešām ir tas, par ko uzdodas. Praktiskajā darbā tas parasti nozīmē vienu no trim scenārijiem: neaktīvs konts joprojām darbojas pēc darbinieka maiņas, vecs autentifikācijas veids paliek ieslēgts, vai lietotājs pieslēdzas no jaunas ierīces bez papildu pārbaudes. Tieši šeit sākas M365 drošības labākā prakse — identitāte kļūst par pirmo kontroles punktu, nevis par formālu pierakstu politikā.

Cēlonis parasti nav viena kļūda, bet process bez skaidras robežas: piekļuve tiek piešķirta ātrāk, nekā tiek pārskatīts, ar kādu metodi persona autentificējas. Tāpēc pirmais solis ir sakārtot autentifikācijas metodes un pēc tam tikai piesiet tām piekļuvi. Microsoft SFI modeļi un prakse ir organizēti pēc sešiem SFI pīlāriem, un tie ir veidoti kā praktiskas, atkārtojamas norādes risku mazināšanai [1].

Risinājuma soļi Microsoft 365 vidē:

1. Atver Microsoft Entra admin center.
2. Ej uz Protection → Conditional Access un pārskati politikas, kas attiecas uz visiem lietotājiem.
3. Atver Identity → Users → konkrēto lietotāju un pārbaudi sign-in riska un autentifikācijas metožu statusu.
4. Ej uz Protection → Authentication methods un atstāj ieslēgtas tikai tās metodes, kuras uzņēmums tiešām izmanto atbalsta procesā.
5. Ja organizācijā ir augstāks risks, piesien piekļuvi no nezināmām ierīcēm tikai pēc papildu pārbaudes, nevis ļauj automātisku ieeju no jebkura konteksta.

Kā pārbaudīt, ka tas strādā: jauna pieslēgšanās no neatpazītas ierīces izraisa papildu pārbaudi, bet ikdienas darbs no pārvaldītas ierīces notiek bez lieka traucējuma. Tādā brīdī identitātes kontrole darbojas kā filtrs, nevis kā šķērslis visiem lietotājiem. Nākamais solis ir samazināt pašu piekļuves apjomu, jo pat laba identitātes pārbaude neaizsargā pret liekām tiesībām.

Praksē tas nozīmē skaidru atdalījumu starp to, ko lietotājs drīkst darīt ikdienā, un to, ko drīkst tikai administratīvās lomās.

2. M365 drošības labākā prakse piekļuves tiesību samazināšanai

Tipiska kļūda praksē ir dot piekļuvi “uz ērtību”: cilvēks saņem vairāk tiesību, nekā nepieciešams konkrētajam uzdevumam, un šīs tiesības paliek spēkā arī pēc projekta beigām. Tas notiek īpaši bieži vietnēs, grupās un koplietotajās mapēs, kur īpašnieks baidās apturēt darbu un izvēlas piešķirt vēl vienu dalībnieku ar rediģēšanas tiesībām. Rezultāts ir pārāk plašs piekļuves apjoms, kas vēlāk apgrūtina gan auditu, gan incidentu izmeklēšanu.

Kāpēc tā rodas? Tāpēc, ka piekļuve bieži tiek veidota pa vienam izņēmumam, nevis pa noteiktu modeli. Kad nav skaidra standarta, lietotājs saņem tiesības “uz vietas”, bet neviens nepārskata, vai šīs tiesības sakrīt ar lomu. M365 drošības labākā prakse šeit sākas ar vienkāršu principu: piešķir tik daudz, cik vajag darbam šodien, un ne vairāk.

Pareizā konfigurācija ikdienas darbā:

• SharePoint vietnēs izmanto grupas, nevis individuālus ierakstus katram lietotājam.
• Atsevišķi tur īpašniekus, dalībniekus un viesus, lai rediģēšana nesajauktos ar pārvaldību.
• Microsoft Entra admin center pārskati regulāri skaidri parāda, kur vēl joprojām ir vecas piekļuves saites un kuras grupas vairs neatbilst lomām.
• OneDrive koplietošanā izvēlies konkrētus cilvēkus, nevis “ikviens ar saiti”, ja saturs nav publisks.

Šī konfigurācija samazina arī sekundāro risku: ja kāds konts tiek kompromitēts, uzbrucējs neiegūst plašāku teritoriju nekā nepieciešams. Ja piekļuves tiesības netiek sašaurinātas, viena kļūda lietotāja kontā pārvēršas par lielāku datu ekspozīciju visā vidē. Tieši tāpēc šo soli neatstāj pēc identitātes pārbaudes, bet veido kā tās turpinājumu.

Praktiskā secība ir vienkārša: sakārto grupas, izņem liekos īpašniekus, un tikai tad pārej uz ierīču un sesiju kontroli, jo tā strādā vislabāk tad, ja jau ir skaidrs, kam vispār drīkst pieslēgties.

3. Ierīču un sesiju aizsardzība bez lietotāju darba bremzēšanas

Šeit parasti redzamas divas pieejas. Pirmā ir stingra, bet smagnēja: katrai darbībai liek papildu apstiprinājumu, un lietotāji sāk meklēt apvedceļus. Otrā ir pārāk vaļīga: ierīce pieslēdzas vienreiz, un pēc tam sesija turpinās bez pietiekamas pārbaudes, pat ja konteksts mainās. Abas pieejas rada problēmas, tikai dažādos veidos. M365 drošības labākā prakse ir izmantot kontekstu, nevis vienādi sodīt visus lietotājus.

Stingrā pieeja der vietās, kur dati ir jutīgi, piekļuve notiek no neregulārām ierīcēm vai ir liels risks, ka pieslēgšanās notiks ārpus pārvaldītās vides. Vaļīgā pieeja der tikai tad, ja organizācija jau ir sakārtojusi ierīču atbilstību un uzticas konkrētam darba modelim. Microsoft SFI modeļi un prakse iesaka slāņotu pieeju aģentu padziļinātai aizsardzībai un drošināt uz aģentiem balstītas sistēmas, lai samazinātu risku, neapturot inovācijas [1]. Tas pats princips strādā arī sesijās: slāņi tiek likti tur, kur risks pieaug.

Ieteikums praksē:

• Microsoft Entra admin center atver Protection → Conditional Access un izveido politiku ar nosacījumu “device platform”, “location” un “sign-in risk”.
• Atsevišķi nosaki uzticamas ierīces, kurām ļauj piekļuvi ar mazāku traucējumu.
• Uz nepārvaldītām ierīcēm piespiedi īsāku sesijas dzīves ciklu un papildu pārbaudi sensitīviem resursiem.
• Microsoft Defender for Cloud Apps izmanto, lai monitorētu aktīvās sesijas un pārtrauktu riskantas darbības bez pilnas piekļuves bloķēšanas visam lietotājam.

Ja šo uzstādījumu neizlabo, problēma nav tikai drošībā, bet arī lietotāju pieredzē: cilvēki sāk uzskatīt drošību par šķērsli un meklē informācijas dublējumus ārpus M365. Ja politika ir pārdomāta, sesija tiek pastiprināta tikai tad, kad mainās risks, un ikdienas darbs paliek plūstošs. Tālāk svarīgi sakārtot pašus datus, jo piekļuve un sesija dod maz labuma, ja dokumenti tiek glabāti bez skaidras robežas un nosaukumu disciplīnas.

Nākamajā solī uzmanība pāriet no cilvēka un ierīces uz pašu informāciju: kur tā dzīvo, kā tā tiek marķēta un kad tā tiek dzēsta vai arhivēta.

4. Datu klasifikācija un glabāšanas robežas SharePoint un OneDrive

Šī sadaļa sākas ar praktisku realitāti: dati M365 vidē bieži tiek glabāti “tur, kur tobrīd bija ērti”, nevis tur, kur tiem ir skaidrs dzīves cikls. Tas rada trīs riskus — pārāk plašu koplietošanu, neskaidru saglabāšanas termiņu un grūtības atrast īsto versiju, kad notiek audits vai strīds. SharePoint un OneDrive nav vienkārši mapes failiem; tie ir pārvaldības slāņi, kuriem jāstrādā kopā ar klasifikāciju un glabāšanas robežām.

Precīza instrukcija Microsoft 365 vidē:

1. Microsoft Purview portal atver Information protection un izveido sensitivitātes etiķetes pēc datu tipiem, nevis pēc departamentiem vien.
2. Ej uz Data lifecycle management un definē glabāšanas politiku dokumentiem, kuri vairs nav aktīvi darba failus.
3. SharePoint admin center izvēlies vajadzīgo vietni un pārskati vietnes dalībniekus, ārējo koplietošanu un satura tipu izmantošanu.
4. Document Library → Settings → Versioning settings ieslēdz versiju kontroli bibliotēkām, kur notiek līgumu, procedūru vai prasību grozījumi.
5. OneDrive admin center pārskati koplietošanas iestatījumus un nosaki, vai ārējās saites ir atļautas tikai konkrētām situācijām, nevis visam saturam.

Biežākās kļūmes katrā solī ir vienkāršas, bet dārgas: etiķetes izveido, bet nepieskaita lietotāju grupām; glabāšanas politika ir uzrakstīta, bet neattiecas uz pareizo vietņu tipu; versiju kontrole ir izslēgta bibliotēkā, kur dokumenti mainās visbiežāk; ārējā koplietošana ir atstāta vispārīgi atvērta, lai “netraucētu darbam”. SharePoint telpu līdzeklis ir atzīts par novecojušu, sākot ar 2025. gada martu [2], tāpēc 3D vai telpiskam saturam Microsoft iesaka skatīties uz Microsoft Mesh, bet SharePoint telpās, kad tas tomēr tiek lietots, ieteicami GLB un GLTF formāta 3D modeļi [2]. Tas ir labs atgādinājums, ka arī satura tipam jāseko platformas atbalstam, nevis ieradumam.

Rezultātā dokumenti iegūst skaidru dzīves ciklu: aktīvs saturs paliek darba vietās, jutīgāks saturs tiek marķēts un pieejams tikai noteiktām lomām, bet novecojušais saturs tiek aizvērts vai pārvaldīts pēc noteikta termiņa. Kad šī robeža ir ieviesta, nākamais drošības līmenis vairs nav haotiska failu sakārtošana, bet konsekventa darbplūsma visā M365 vidē.

5. M365 drošības labākā prakse failu nosaukumiem un mapēm

Faila nosaukums un mapes ceļš M365 vidē nav tikai kārtības jautājums. Tie tieši ietekmē to, kā pārlūks, SharePoint un sinhronizācija nolasa failu. Ja nosaukumā ieliek speciālās rakstzīmes, atsevišķos gadījumos fails tīmekļa pārlūkprogrammā ielādējas nepareizi [2]. Tas nozīmē, ka drošības politika sākas jau tajā brīdī, kad lietotājs nosauc dokumentu, nevis tad, kad dokuments jau ir publicēts. Praktiskā M365 drošības labākā prakse šeit ir vienkārša: nosaukumus veido ar lielajiem burtiem, mazajiem burtiem vai cipariem, bez liekiem simboliem, un mapju struktūru uztur prognozējamu [2].

Ikdienā problēma parādās ļoti konkrēti. Dokumentu augšupielādē ar nosaukumu, kas satur rakstzīmes no e-pasta tēmas rindas, ārēja saite uz failu strādā vienā vietā, bet citā vietā atver tukšu lapu, un cilvēki sāk pārsūtīt pievienotos failus pa e-pastu, jo “SharePoint neiet”. Tieši tur rodas drošības risks: faila nosaukums tiek uztverts kā tehniska detaļa, lai gan tas ietekmē koplietošanas stabilitāti. SharePoint telpās Microsoft iesaka turēties pie GLB un GLTF 3D modeļu formātiem, kad tas ir iespējams, un Microsoft iesaka izpētīt Microsoft Mesh jaunam tīrskata 3D saturam M365 vidē; tas parāda to pašu principu — izvēlētais formāts un nosaukuma disciplīna nosaka, vai saturs darbojas paredzami [2].

Ko ar to iesākt praksē:

• izveido vienotu nosaukumu standartu komandām un vietnēm;
• iedzīvini to dokumentu bibliotēku lietošanas instrukcijā;
• pārskati esošās mapes, kurās redzami simboli, kas izraisa ielādes problēmas;
• vienojies, ka svarīgi dokumenti netiek pārdēvēti ar “skaistiem”, bet tehniski riskantiem nosaukumiem.

Rezultāts praksē ir vienkāršs: dokumenti atveras paredzami, saites neplīst tik bieži, un atbalsta komanda tērē mazāk laika failu labojumiem, kas patiesībā ir slēpts procesu risks. Kad šī kārtība ir nostiprināta, nākamais solis ir skatīties, kas dokumentu drīkst redzēt un pārsūtīt tālāk.

6. Sensitīvu vietņu un dokumentu koplietošanas kontrole

Praksē sensitīvas SharePoint vietnes bieži rodas nevis no slikta dizaina, bet no laba nodoma: projekts jāpalaiž ātri, tāpēc vietne tiek atvērta plašāk, nekā vajadzīgs. Vienā projektā redzams tipisks scenārijs: finanšu vai personāla komanda ievieto dokumentus vietnē, kurā ir pārāk plašas dalīšanās tiesības, un pēc tam katrs jauns dalībnieks manto to pašu modeli. Šādos brīžos problēma nav tikai “kam piekļuve”, bet “kā piekļuve tiek dotas un uzturētas”. M365 drošības labākā prakse šeit nozīmē kontrolēt koplietošanu vietnes līmenī, nevis paļauties uz atsevišķu lietotāju disciplinētu uzvedību.

Kas tiek mainīts praksē: SharePoint vietnes īpašnieks pārskata Site permissions, bet bibliotēkas līmenī lieto Document Library → Settings → Permissions for this document library, lai atdalītu jutīgu dokumentu grupas no vispārīgas komandas plūsmas. Ja saturs ir īpaši sensitīvs, koplietošana netiek balstīta uz “Anyone” tipa ērtību, bet tiek sakārtota pa konkrētiem cilvēkiem vai grupām. Tajā pašā laikā vietnes informācijas klasifikācija, ārējās koplietošanas statuss un saites derīgums jāpārbauda vietnes iestatījumos, lai vietne nepārvērstos par noklusētu datu apmaiņas punktu. Šī ir robeža, ko konsultants redz regulāri: kad piekļuves modelis ir pārāk vienkāršots, lietotāji neapzināti kopīgo vairāk, nekā vajadzīgs, un pēc tam bezpeļņas “labojumi” ar manuālu dzēšanu neatrisina sākotnējo kļūdu.

Ko mainīt uzreiz:

1. pārskatīt, kuras vietnes satur sensitīvus dokumentus;
2. atsevišķi sakārtot vietnes īpašniekus un dokumentu bibliotēku tiesības;
3. pārbaudīt, vai ārējā koplietošana ir nepieciešama tieši šai vietnei;
4. vienot koplietošanas modeli ar datu klasifikāciju, lai sensitīvie faili neatrodas vispārīgā darba plūsmā.

Rezultātā sensitīvs saturs nepazūd “pa ceļam” plašās saites un pārmantotu atļauju dēļ. Nākamais posms ir nevis tikai redzēt, kas notiek, bet pamanīt risku, pirms tas pārvēršas incidentā.

7. Uzraudzība, kas fiksē risku, nevis tikai notikumu

Uzraudzībā bieži iestrēgst kļūda: tiek vākti notikumi, bet netiek skatīts risks. Piemēram, žurnālos redzams, ka lietotājs pieslēdzās, atvēra dokumentu un pēc tam pārsūtīja saiti tālāk. Ja šie dati stāv atsevišķi, drošības komanda redz kustību, bet nesaprot, vai tā ir normāla darba plūsma vai anomālija. Tieši tāpēc monitoringā fokusam jābūt uz risku, nevis tikai uz darbības faktiem. Microsoft SFI modeļi un prakse ir organizēti pēc sešiem SFI pīlāriem, un katrs modelis dod atkārtojamas norādes reālajiem riskiem, tostarp identitātes apdraudējumiem un mantotām sistēmām [1].

Cēlonis šai problēmai parasti ir sadrumstalota telemetrija. Vienā vietā ir audit logs, citā — piekļuves politika, vēl citur — ierīces statuss. Ja komanda šos avotus nesavieno, tā redz tikai notikumu ķēdi bez secinājuma. Risinājuma soļi ir praktiski. Microsoft 365 vidē jāizmanto Microsoft Purview un Audit, jāpārskata Data Loss Prevention brīdinājumi, kā arī Microsoft Entra ID sign-in un risk logs, lai redzētu, vai risks rodas no neparastas atrašanās vietas, negaidītas ierīces vai aizdomīga koplietošanas modeļa. Ja organizācija lieto drošības pārskatus, tiem jāparāda ne tikai “kas notika”, bet arī “kāpēc tas ir svarīgi”.

Lai pārbaudītu, ka uzraudzība strādā, izmanto vienkāršu testu:

• ģenerē kontrolētu koplietošanas notikumu vietnē ar jutīgu saturu;
• pārbaudi, vai tas parādās auditā ar saprotamu kontekstu;
• salīdzini, vai alerts tiek piesaistīts politikai, nevis tikai ierakstīts žurnālā;
• pārskati, vai incidentu triāža saņem pietiekamu informāciju lēmumam.

Praksē tas maina darba ritmu: drošības komanda nepavada laiku, šķirstot atsevišķus notikumus, bet ātrāk atpazīst riskantu uzvedību un pamato nākamo darbību. Kad monitorings sāk dot riska signālus, nākamais jautājums kļūst vēl svarīgāks — kā drošināt AI un aģentus pirms tie nonāk ražošanā.

8. Aģentu un mākslīgā intelekta drošināšana pirms ieviešanas

Tipiska kļūda praksē ir AI risinājumu ieviest kā jaunu rīku bez drošības modeļa. Komanda koncentrējas uz lietojuma scenāriju, bet izlaiž jautājumu, kam aģents drīkst piekļūt, kādus datus tas lasa un kādā veidā tas rīkojas ar ārējām integrācijām. Šī kļūda rodas tāpēc, ka aģents šķiet “tikai palīgs”, lai gan tehniski tas pieslēdzas identitātei, datiem un darbplūsmām. Microsoft iesaka pieeju draudu modelēšanai mākslīgā intelekta sistēmām kā nepārtrauktai inženierijas domāšanai, nevis vienreizējam kontrolsarakstam [1].

Pareizā konfigurācija sākas ar robežām. Ja aģents strādā Microsoft 365 vidē, tam jāpiešķir tieši tās piekļuves tiesības, kas nepieciešamas konkrētajam uzdevumam, nevis visa projekta vai nodaļas datu plašums. Microsoft iesaka izmantot slāņotu pieeju aģentu padziļinātai aizsardzībai un drošināt uz aģentiem balstītas sistēmas, lai samazinātu risku, neapturot inovācijas [1]. Praktiski tas nozīmē: identitātes līmenī jānotur stingra autentifikācija, datu līmenī jānosaka, kāds saturs aģentam ir pieejams, un izpildes līmenī jāierobežo darbības, ko tas drīkst veikt bez papildu pārbaudes. Ja organizācija izmanto Copilot, custom agentus vai integrācijas ar Power Platform, pirms palaišanas pārbauda piešķirtās atļaujas, datu avotus un žurnālošanu.

Ja šo neizlabo, sekas ir paredzamas: aģents sāk redzēt pārāk daudz, pārāk ātri izpilda darbības vai pārmanto tiesības no plašas grupas. Tad drošības incidents rodas nevis no tehniskas kļūmes, bet no slikti definētas uzticamības robežas. Pēc šīs robežas nostiprināšanas nākamais solis ir sasaistīt aģentu drošību ar kopējo piekļuves un uzraudzības modeli visā M365 platformā.

Avoti

Kā KSJ var palīdzēt