Selles artiklis soovime näidata, kuidas Microsoft Teamsiga töötamine kasutajate, IT-administraatorite ja infoturbetöötajate vaatevinklist välja näeb.
Esiteks, teeme selgeks, mille poolest Teams erineb enamikust teistest Microsofti toodetest nende Office 365 (lühidalt O365) pakkumises.
Teams on ainult klient ja tal pole oma pilverakendust. Ja see majutab andmeid, mida ta haldab erinevates O365 rakendustes.
Näitame teile, mis toimub "kapoti all", kui kasutajad töötavad Teamsis, SharePoint Online'is (edaspidi SPO) ja OneDrive'is.
Kui soovite liikuda Microsofti tööriistade abil turvalisuse tagamise praktilise poole juurde (1 tund kursuse koguajast), soovitame tungivalt kuulata meie Office 365 ühiskasutusauditi kursust, mis on saadaval See kursus hõlmab ka O365 jagamisseadeid, mida saab muuta ainult PowerShelli kaudu.
Tutvuge Acme Co sisemise projektimeeskonnaga.
Selline näeb see meeskond Teamsis välja pärast selle loomist ja selle liikmetele vastava juurdepääsu andmist selle meeskonna omaniku Amelia poolt:
Meeskond hakkab tööle
Linda annab mõista, et tema loodud kanalisse paigutatud boonusmakseplaani failile pääsevad juurde ainult James ja William, kellega nad seda arutasid.
James omakorda saadab sellele failile juurdepääsu lingi personalitöötajale Emmale, kes ei ole meeskonna liige.
William saadab MS Teamsi vestluses teisele meeskonnaliikmele lepingu kolmanda osapoole isikuandmetega:
Ronime kapoti alla
Zoey saab nüüd Amelia abiga igal ajal kedagi meeskonda lisada või sealt eemaldada:
Linda, postitades kriitiliste andmetega dokumenti, mis oli mõeldud kasutamiseks ainult kahele tema kolleegile, tegi selle loomisel vea tüübiga Kanal ja fail sai kättesaadavaks kõigile meeskonnaliikmetele:
Õnneks on O365 jaoks olemas Microsofti rakendus, milles saate (kasutades seda täielikult muudel eesmärkidel) kiiresti millistele kriitilistele andmetele on juurdepääs absoluutselt kõigil kasutajatel?, kasutades testimiseks kasutajat, kes on ainult kõige üldisema turvarühma liige.
Isegi kui failid asuvad privaatkanalites, ei pruugi see olla garantii, et neile pääseb juurde vaid teatud ring inimesi.
Jamesi näites andis ta lingi Emma failile, mis pole isegi meeskonna liige, rääkimata juurdepääsust privaatkanalile (kui see oleks üks).
Selle olukorra halvim on see, et me ei näe selle kohta teavet kuskil Azure AD turvarühmades, kuna juurdepääsuõigused antakse sellele otse.
Williami saadetud PD-fail on Margaretile kättesaadav igal ajal ja mitte ainult võrgus vesteldes.
Ronime kuni vöökohani
Mõtleme selle edasi. Esiteks vaatame, mis täpselt juhtub, kui kasutaja loob MS Teamsis uue meeskonna:
- Azure AD-s luuakse uus Office 365 turberühm, mis hõlmab meeskonnaomanikke ja meeskonnaliikmeid
- SharePoint Online'is (edaspidi SPO) luuakse uus meeskonna sait.
- SPO-s luuakse kolm uut kohalikku (kehtib ainult selles teenuses) rühma: Omanikud, Liikmed, Külastajad
- Muudatusi tehakse ka Exchange Online'is.
MS Teamsi andmed ja nende asukoht
Teams ei ole andmeladu ega platvorm. See on integreeritud kõigi Office 365 lahendustega.
- O365 pakub palju rakendusi ja tooteid, kuid andmeid hoitakse alati järgmistes kohtades: SharePoint Online (SPO), OneDrive (OD), Exchange Online, Azure AD
- Andmeid, mida jagate või saate MS Teamsi kaudu, salvestatakse nendele platvormidele, mitte Teamsi enda sees
- Sel juhul on riskiks kasvav trend koostööle. Igaüks, kellel on juurdepääs andmetele SPO ja OD platvormidel, saab teha need kättesaadavaks kõigile organisatsioonis või väljaspool seda
- Kõik meeskonna andmed (v.a privaatkanalite sisu) kogutakse SPO saidile, mis luuakse meeskonna loomisel automaatselt
- Iga loodud kanali jaoks luuakse selle SPO saidi kausta Dokumendid automaatselt alamkaust:
- Kanalite failid laaditakse üles SPO Teamsi saidi kausta Dokumendid vastavatesse alamkaustadesse (nimega sama, mis kanalil)
- Kanalile saadetud e-kirjad salvestatakse Kanali kausta alamkausta "E-kirjad"
- Uue privaatse kanali loomisel luuakse selle sisu salvestamiseks eraldi SPO sait, millel on sama struktuur, nagu ülalpool tavaliste kanalite puhul (oluline – iga privaatkanali jaoks luuakse oma spetsiaalne SPO sait)
- Vestluste kaudu saadetud failid salvestatakse saatva kasutaja OneDrive'i kontole (kausta "Microsoft Teamsi vestlusfailid") ja neid jagatakse vestluses osalejatega
- Vestluse ja kirjavahetuse sisu salvestatakse vastavalt kasutaja ja meeskonna postkasti peidetud kaustadesse. Praegu ei ole võimalik neile täiendavat juurdepääsu saada.
Karburaatoris on vesi, pilsis on leke
Põhipunktid, mida on oluline kontekstis meeles pidada infoturbe:
- Juurdepääsukontroll ja arusaamine sellest, kellele võib olulistele andmetele õigusi anda, kantakse üle lõppkasutaja tasemele. Ei ole tagatud täielik tsentraliseeritud juhtimine või jälgimine.
- Kui keegi jagab ettevõtte andmeid, on teie pimealad teistele nähtavad, kuid mitte teile.
Me ei näe Emmat inimeste loendis, kes kuuluvad meeskonda (Azure AD turvarühma kaudu), kuid tal on juurdepääs konkreetsele failile, mille lingi James talle saatis.
Samuti ei saa me teada tema võimest Teamsi liidese kaudu failidele juurde pääseda:
Kas me saame kuidagi teavet selle kohta, millisele objektile Emmal on juurdepääs? Jah, saame, kuid ainult uurides juurdepääsuõigusi kõigele või konkreetsele objektile SPO-s, mille suhtes meil on kahtlusi.
Olles selliseid õigusi uurinud, näeme, et Emmal ja Chrisil on objektile õigused SPO tasemel.
Chris? Me ei tunne ühtegi Chrisi. Kust ta tuli?
Ja ta "tuli" meie juurde "kohalikust" SPO turbegrupist, mis omakorda hõlmab juba Azure AD turvagruppi, koos meeskonna "Haldustega" liikmetega.
Saab, Microsoft Cloud App Security (MCAS) suudab valgustada meid huvitavaid küsimusi, pakkudes vajalikul tasemel arusaamist?
Kahjuks ei... Kuigi me näeme Chrisi ja Emmat, ei näe me konkreetseid kasutajaid, kellele on juurdepääs antud.
Juurdepääsu võimaldamise tasemed ja meetodid O365-s – IT väljakutsed
Lihtsaim protsess organisatsioonide perimeetris asuvatele failimäludele juurdepääsu võimaldamiseks ei ole eriti keeruline ega anna praktiliselt võimalusi antud juurdepääsuõigustest mööda hiilida.
O365-l on ka palju võimalusi koostööks ja andmete jagamiseks.
- Kasutajad ei saa aru, miks piirata juurdepääsu andmetele, kui nad saavad lihtsalt anda lingi kõigile kättesaadavale failile, kuna neil puuduvad infoturbe alased elementaarsed teadmised või nad eiravad riske, tehes eeldusi oma kahjude vähese tõenäosuse kohta. esinemine
- Selle tulemusena võib kriitiline teave organisatsioonist lahkuda ja saada kättesaadavaks paljudele inimestele.
- Lisaks on palju võimalusi pakkuda üleliigset juurdepääsu.
Microsoft on O365-s pakkunud ilmselt liiga palju võimalusi juurdepääsu kontrolli loendite muutmiseks. Sellised sätted on saadaval rentniku, saitide, kaustade, failide, objektide endi ja nende linkide tasemel. Jagamisvõimaluste sätete konfigureerimine on oluline ja seda ei tohiks tähelepanuta jätta.
Pakume võimalust osaleda tasuta, ligikaudu pooleteisetunnisel videokursusel nende parameetrite seadistamise kohta, mille link on toodud selle artikli alguses.
Ilma kaks korda mõtlemata saate blokeerida kogu välise failijagamise, kuid siis:
- Osa O365 platvormi võimalusi jääb kasutamata, eriti kui osa kasutajaid on harjunud neid kodus või eelmisel töökohal kasutama
- „Kogenud kasutajad“ „aitavad“ teistel töötajatel teie seatud reegleid rikkuda muul viisil
Jagamisvalikute seadistamine hõlmab järgmist:
- Iga rakenduse jaoks erinevad konfiguratsioonid: OD, SPO, AAD ja MS Teams (mõned konfiguratsioonid saavad teha ainult administraator, mõnda saavad teha ainult kasutajad ise)
- Seadete konfiguratsioonid üürniku tasemel ja iga konkreetse saidi tasemel
Mida see infoturbe jaoks tähendab?
Nagu eespool nägime, ei saa täielikke autoriteetseid andmetele juurdepääsu õigusi näha ühes liideses:
Seega, selleks, et mõista, kellel on juurdepääs IGALE konkreetsele failile või kaustale, peate iseseisvalt looma juurdepääsumaatriksi, kogudes selle jaoks andmeid, võttes arvesse järgmist:
- Teamsi liikmed on nähtavad Azure AD-s ja Teamsis, kuid mitte SPO-s
- Meeskonnaomanikud saavad määrata kaasomanikke, kes saavad meeskonnaloendit iseseisvalt laiendada
- Meeskondades võivad olla ka VÄLISED kasutajad – "Külalised"
- Jagamiseks või allalaadimiseks pakutavad lingid ei ole Teamsis ega Azure AD-s nähtavad – ainult SPO-s ja ainult pärast tüütut linkide klõpsamist
- Juurdepääs ainult SPO saidile pole Teamsis nähtav
Tsentraliseeritud kontrolli puudumine tähendab, et sa ei saa:
- Vaadake, kellel on juurdepääs millistele ressurssidele
- Vaadake, kus kriitilised andmed asuvad
- Täitke regulatiivsed nõuded, mis nõuavad teenuse planeerimisel privaatsuspõhist lähenemist
- Tuvastage kriitiliste andmete puhul ebatavaline käitumine
- Piirata rünnakuala
- Valige nende hinnangu põhjal tõhus viis riskide vähendamiseks
Kokkuvõte
Kokkuvõtteks võib öelda, et
- O365-ga koostööd valivate organisatsioonide IT-osakondade jaoks on oluline omada kvalifitseeritud töötajaid, kes suudavad nii tehniliselt jagamisseadete muudatusi ellu viia kui ka põhjendada teatud parameetrite muutmise tagajärgi, et koostada O365-ga töötamise poliitikad, mis on kokku lepitud teabega turva- ja äriüksused
- Infoturbe jaoks on oluline, et oleks võimalik igapäevaselt või isegi reaalajas läbi viia andmetele juurdepääsu, IT- ja äriosakondadega kokkulepitud O365 poliitika rikkumiste audit ning antud juurdepääsu õigsuse analüüs. , samuti näha rünnakuid nende rentniku O365 iga teenuse vastu
Allikas: www.habr.com