Jaa

Identiteetille ja sen ulkopuolella – Yhden arkkitehdin näkökulma

  • Artikkeli

Tässä artikkelissa Microsoftin tekninen pääarkkitehti Alex Shteynberg käsittelee Microsoft 365:n ja muiden Microsoftin pilvipalvelujen käyttöönoton tärkeimpiä suunnittelustrategioita yritysorganisaatioille.

Tietoja tekijästä

Alex Shteynbergin kuva.

Olen tekninen pääarkkitehti New Yorkin Microsoft Technology Centerissä. Työskentelen enimmäkseen suurten asiakkaiden kanssa ja monimutkaisissa vaatimuksissa. Näkökulmani ja mielipiteeni perustuvat näihin vuorovaikutuksiin, eivätkä ne välttämättä koske kaikkia tilanteita. Jos kuitenkin voimme auttaa asiakkaita monimutkaisimpien haasteiden kanssa, voimme auttaa kaikkia asiakkaita.

Työskentelen yleensä yli 100 asiakkaan kanssa vuosittain. Vaikka jokaisella organisaatiolla on ainutlaatuisia ominaisuuksia, on mielenkiintoista nähdä trendejä ja yleisyyksiä. Yksi trendi on esimerkiksi monen asiakkaan toimialakohtainen kiinnostus. Pankin konttori voi olla myös kahvila ja yhteisökeskus.

Omassa roolissani keskityn auttamaan asiakkaita pääsemään parhaaseen tekniseen ratkaisuun yksilöllisten liiketoimintatavoitteidensa saavuttamiseksi. Keskityn virallisesti käyttäjätietoihin, suojaukseen, tietosuojaan ja vaatimustenmukaisuuteen. Rakastan sitä, että nämä koskettavat kaikkea, mitä teemme. Se antaa minulle mahdollisuuden osallistua useimpiin projekteihin. Tämä toiminta pitää minut kiireisenä ja nauttimassa tästä roolista.

Asun New Yorkissa (paras!) ja nautin todella sen kulttuurin, ruoan ja ihmisten (ei liikenteen) monimuotoisuudesta. Rakastan matkustaa, kun voin ja toivon näkeväni suurimman osan maailmasta elinaikanani. Tutkin parhaillaan Afrikan-matkaa oppiakseni villieläimistä.

Pääperiaatteet

  • Yksinkertainen on usein parempi: Voit tehdä (melkein) mitä tahansa tekniikalla, mutta se ei tarkoita, että sinun pitäisi. Erityisesti suojaustilanteissa monet asiakkaat ovat ylitekniikkaratkaisuja. Pidän tästä videosta Googlen Stripe-konferenssista tämän kohdan alaviivaamiseksi.
  • Ihmiset, prosessi, teknologia: Suunnittelu ihmisille prosessin parantamiseksi, ei ensin tekninen. "Täydellisiä" ratkaisuja ei ole. Meidän on tasapainotettava eri riskitekijöitä ja päätöksiä, jotka voivat olla erilaisia kullekin yritykselle. Liian moni asiakas suunnittelee menetelmää, jota käyttäjät myöhemmin välttävät.
  • Keskity ensin "miksi" ja "miten" myöhemmin: Ole ärsyttävä 7-vuotias lapsi, jolla on miljoona kysymystä. Oikeaan vastaukseen ei saada, jos emme tiedä oikeita kysymyksiä. Monet asiakkaat tekevät oletuksia siitä, miten asioiden on toimittava sen sijaan, että määrittävät liiketoimintaongelman. Käytettävissä on aina useita polkuja.
  • Aiempien parhaiden käytäntöjen pitkä häntä: Tunnista, että parhaat käytännöt muuttuvat valon nopeudella. Jos tarkastelit Microsoft Entra yli kolme kuukautta sitten, olet todennäköisesti vanhentunut. Kaikki tässä sisältö voi muuttua julkaisun jälkeen. "Paras" -vaihtoehto tänään ei ehkä ole sama kuuden kuukauden kuluttua.

Perusaikataulun käsitteet

Älä ohita tätä osaa. Huomaan usein, että minun on palattava näihin artikkeleihin myös asiakkaille, jotka ovat käyttäneet pilvipalveluja jo vuosia. Valitettavasti kieli ei ole tarkka työkalu. Käytämme usein samaa sanaa tarkoittamaan eri käsitteitä tai eri sanoja tarkoittamaan samaa käsitettä. Käytän usein seuraavaa kaaviota perusterminologian ja hierarkiamallin muodostamiseen.

Kuva vuokraajasta, tilauksesta, palvelusta ja tiedoista.

Kun opit uimaan, on parempi aloittaa uima-altaasta eikä keskellä merta. En yritä olla teknisesti tarkka tämän kaavion kanssa. Se on malli, jossa käsitellään joitakin peruskäsitteitä.

Kaaviossa:

  • Vuokraaja = Microsoft Entra ID esiintymä. Se on hierarkian yläreunassa tai kaavion tasolla 1. Voimme pitää tätä tasoa "rajana", jossa kaikki muu esiintyy (Microsoft Entra B2B syrjään). Kaikki Microsoft enterprise cloud -palvelut ovat osa yhtä näistä vuokraajista. Kuluttajapalvelut ovat erillisiä. Vuokraaja näkyy dokumentaatiossa Esimerkiksi Microsoft 365 -vuokraajana, Azure-vuokraajana ja WVD-vuokraajana. Huomaan usein, että nämä variaatiot aiheuttavat hämmennystä asiakkaille.
  • Palvelut/tilaukset, kaavion taso 2, kuuluvat yhteen vuokraajaan ja vain yhteen vuokraajaan. Useimmat SaaS-palvelut ovat 1:1, eikä niitä voi siirtää ilman siirtoa. Azure on erilainen, voit siirtää laskutuksen ja/tai tilauksen toiseen vuokraajaan. Monien asiakkaiden on siirrettävä Azure-tilauksia. Tällä skenaariolla on useita vaikutuksia. Tilauksen ulkopuolella olevia objekteja ei siirrellä. Esimerkiksi roolipohjainen käyttöoikeuksien valvonta (Azure RBAC), Microsoft Entra objekteja (ryhmät, sovellukset, käytännöt jne.) ja joitakin palveluita (Azure Key Vault, datatiilet jne.). Älä siirrä palveluita ilman hyvää liiketoimintatarvetta. GitHubissa jaetaan komentosarjoja, joista voi olla hyötyä siirtämisessä.
  • Tietyllä palvelulla on yleensä jonkinlainen alitason raja tai taso 3 (L3). Tämän rajan avulla voidaan ymmärtää esimerkiksi suojauksen, käytäntöjen ja hallinnon erottaminen. Valitettavasti en tiedä mitään univormun nimeä. Esimerkkejä L3:n nimistä ovat: Azure-tilaus = resurssi; Dynamics 365 CE = esiintymä; Power BI = työtila; Power Apps = ympäristö; ja niin edelleen.
  • Taso 4 on todellisten tietojen sijaintipaikka. Tämä tietotaso on monimutkainen artikkeli. Jotkin palvelut käyttävät Microsoft Entra ID RBAC:ssä, toiset eivät. Käsittelen tätä hieman, kun käsittelemme delegointiartikkeleita.

Eräät muut käsitteet, joihin monet asiakkaat (ja Microsoftin työntekijät) ovat mielestäni hämmentyneitä tai joihin liittyy kysymyksiä, ovat esimerkiksi seuraavat ongelmat:

  • Kuka tahansa voi luoda useita vuokraajia ilman kustannuksia. Et tarvitse siihen valmisteltavaa palvelua. Minulla on kymmeniä. Kunkin vuokraajan nimi on yksilöllinen Microsoftin maailmanlaajuisessa pilvipalvelussa (toisin sanoen kahdella vuokraajalla ei voi olla samaa nimeä). Ne ovat kaikki TenantName.onmicrosoft.com muodossa. On myös prosesseja, jotka luovat vuokraajia automaattisesti (hallitsemattomat vuokraajat). Tämä tulos voi tapahtua esimerkiksi silloin, kun käyttäjä rekisteröityy yrityspalveluun sähköpostitoimialueella, jota ei ole missään muussa vuokraajassa.
  • Hallitussa vuokraajassa siihen voidaan rekisteröidä useita DNS-toimialueita . Tämä tulos ei muuta alkuperäisen vuokraajan nimeä. Tällä hetkellä vuokraajan nimeäminen uudelleen ei ole helppoa (muu kuin siirto). Vaikka vuokraajan nimi ei ole nykyään teknisesti kriittinen, tämä todellisuus saattaa rajoittaa joitakin ihmisiä.
  • Varaa vuokraajanimi organisaatiollesi, vaikka et vielä aikoisi ottaa palveluita käyttöön. Muussa tapauksessa joku voi ottaa sen sinulta eikä ole yksinkertaista prosessia sen palauttamiseksi (sama ongelma kuin DNS-nimet). Kuulen tämän aivan liian usein asiakkailta. Vuokraajan nimen tulisi olla myös keskusteluartikkeli.
  • Jos omistat DNS-nimitilan, lisää kaikki nämä nimitilat vuokraajissasi. Muussa tapauksessa voidaan luoda tämänniminen hallitsematon vuokraaja , mikä aiheuttaa häiriöitä sen hallitsemiseksi.
  • DNS-nimitila (esimerkiksi contoso.com) voi kuulua vain yhteen vuokraajaan. Vaatimuksella on vaikutuksia eri skenaarioihin (esimerkiksi sähköpostin toimialueen jakamiseen sulautumisen tai hankinnan aikana jne.). DNS-ali (kuten div.contoso.com) voidaan rekisteröidä eri vuokraajaan, mutta sitä on vältettävä. Rekisteröimällä ylimmän tason toimialuenimen kaikkien alitoimialueiden oletetaan kuuluvan samaan vuokraajaan. Usean vuokraajan skenaarioissa (kuten seuraavassa selitetään) suosittelen yleensä toisen ylimmän tason toimialuenimen käyttämistä (kuten contoso.ch tai ch-contoso.com).
  • Kenen tulisi "omistaa" vuokraaja? Näen usein asiakkaita, jotka eivät tiedä, kuka tällä hetkellä omistaa vuokraajan. Tämä tiedon puute on merkittävä punainen lippu. Soita Microsoftin tuen ASAP-kutsulle. Aivan yhtä ongelmallista on, kun palvelun omistaja (usein Exchange-järjestelmänvalvoja) on määritetty hallinnoimaan vuokraajaa. Vuokraaja sisältää kaikki palvelut, joita saatat haluta tulevaisuudessa. Vuokraajan omistajan on oltava ryhmä, joka voi päättää kaikkien pilvipalveluiden käyttöönotosta organisaatiossa. Toinen ongelma on, kun vuokraajan omistajaryhmää pyydetään hallitsemaan kaikkia palveluita. Tätä menetelmää ei skaalata suurissa organisaatioissa.
  • Ali-/supervuokraajan käsitettä ei ole. Jostain syystä tämä myytti toistuu jatkuvasti. Tämä koskee myös Azure Active Directory B2C -vuokraajia. Kuulen liian monta kertaa: "B2C-ympäristöni on XYZ-vuokraajassani" tai "Ohjevalikko siirtää Azure-vuokraajani Microsoft 365 -vuokraajaan?"
  • Tässä asiakirjassa keskitytään pääasiassa kaupalliseen maailmanlaajuisesti olevaan pilvipalveluun, koska sitä useimmat asiakkaat käyttävät. Joskus on hyödyllistä tietää maakohtaisista pilvipalveluista. Maakohtaisilla pilvipalveluilla on muita keskustelunaiheita, jotka eivät kuulu tämän keskustelun piiriin.

Perustietojen artikkelit

Microsoftin käyttäjätietoympäristöstä on paljon dokumentaatiota – Microsoft Entra ID. Ihmisille, jotka ovat juuri aloittamassa, se tuntuu usein ylivoimaiselta. Vaikka olet oppinut siitä, pysyminen jatkuvan innovaation ja muutoksen mukana voi olla haastavaa. Asiakasvuorovaikutuksessani toimin usein "kääntäjänä" liiketoimintatavoitteiden ja "Good, Better, Best" -lähestymistapojen välillä näiden huolenaiheiden (ja ihmisten "cliff notes" näiden artikkelien välillä). Harvoin on täydellistä vastausta, ja "oikea" päätös on erilaisten riskitekijöiden tasapaino. Seuraavaksi on joitakin yleisiä kysymyksiä ja sekaannusalueita, joista minulla on taipumus keskustella asiakkaiden kanssa.

Valmistelu

Microsoft Entra ID ei ratkaise hallinnon puutetta identiteettimaailmassasi! Käyttäjätietojen hallinnan tulee olla kriittinen elementti pilvipäätöksistä riippumatta. Hallintovaatimukset muuttuvat ajan myötä, minkä vuoksi se on ohjelma eikä työkalu.

Microsoft Entra Connect vs. Microsoft Identity Manager (MIM) vs. jotain muuta (kolmas osapuoli tai mukautettu)? Tallenna omat ongelmasi nyt ja tulevaisuudessa ja valitse Microsoft Entra Connect. Tässä työkalussa on kaikenlaisia älyä, jotka käsittelevät erikoisia asiakaskokoonpanoja ja jatkuvia innovaatioita.

Joitakin reunatapauksia, jotka saattavat ajaa kohti monimutkaisempaa arkkitehtuuria:

  • Minulla on useita AD-puut, joiden välillä ei ole verkkoyhteyttä. On olemassa uusi vaihtoehto, jonka nimi on Pilvipalvelun valmistelu.
  • Minulla ei ole Active Directorya, enkä halua asentaa sitä. Microsoft Entra Connect voidaan määrittää synkronoimaan LDAP:stä (kumppani saattaa olla tarpeen).
  • Samat objektit on valmisteltava useille vuokraajille. Tätä skenaariota ei teknisesti tueta, mutta se riippuu määritelmästä "sama".

Tuleeko minun mukauttaa oletusarvoisia synkronointisääntöjä (suodatinobjektit, määritteiden muuttaminen, vaihtoehtoinen kirjautumistunnus jne.)? Vältä sitä! Käyttäjätietoympäristö on vain yhtä arvokas kuin sitä käyttävät palvelut. Vaikka voit tehdä kaikenlaisia pähkinäisia määrityksiä, tähän kysymykseen vastaamiseksi sinun on tarkasteltava vaikutusta sovelluksiin. Jos suodatat sähköpostia käyttäviä objekteja, online-palvelut GAL on epätäydellinen. Jos sovellus käyttää tiettyjä määritteitä, näiden määritteiden suodattamisen vaikutukset ovat arvaamattomat ja niin edelleen. Se ei ole identiteettitiimin päätös.

XYZ SaaS tukee Just-in-Time (JIT) -valmistelua, miksi minun täytyy synkronoida? Katso edellinen kappale. Monet sovellukset tarvitsevat toiminnallisuutta varten profiilitietoja. Et voi käyttää GAL-osoitetta, jos kaikki sähköpostia käyttävät objektit eivät ole käytettävissä. Sama koskee käyttäjien valmistelua sovelluksissa, jotka on integroitu Microsoft Entra ID.

Todennus

Salasanan hajautetun tietojen synkronointi (PHS) vs. läpivientitodentaminen (PTA) vs. liittoutuminen.

Yleensä liittoa ympäröivät intohimoiset väittelyt . Yksinkertaisempi on yleensä parempi ja siksi käyttää PHS: tä, ellei sinulla ole hyvää syytä olla käyttämättä. Saman vuokraajan eri DNS-toimialueille voi myös määrittää eri todennusmenetelmiä.

Jotkut asiakkaat mahdollistavat liittoutumisen ja PHS:n pääasiassa:

Opastan usein asiakkaita asiakkaan todennustyönkulun läpi selventääkseni joitakin väärinkäsityksiä. Tulos näyttää samalta kuin seuraavassa kuvassa, joka ei ole yhtä hyvä kuin siihen pääsemisen vuorovaikutteinen prosessi.

Esimerkki luonnoslehtiökeskustelusta.

Tämän tyyppinen luonnoslehtiöpiirros havainnollistaa, missä suojauskäytäntöjä sovelletaan todennuspyynnön työnkulussa. Tässä esimerkissä Active Directory -liittoutumispalvelun (AD FS) kautta pakotettuja käytäntöjä sovelletaan ensimmäiseen palvelupyyntöön, mutta ei seuraaviin palvelupyyntöihin. Tämä on vähintään yksi syy siirtää suojauksen hallinta pilveen mahdollisimman paljon.

Olemme jahdanneet unelmaa kertakirjautumisesta (SSO) niin kauan kuin muistan. Jotkut asiakkaat uskovat voivansa saavuttaa kertakirjautumisen valitsemalla "right" federation (STS) -palveluntarjoajan. Microsoft Entra ID voi auttaa merkittävästi ottamaan käyttöön kertakirjautumisominaisuuksia, mutta mikään STS ei ole maaginen. On olemassa liian monta vanhaa todennusmenetelmää, joita käytetään edelleen kriittisissä sovelluksissa. Microsoft Entra ID laajentaminen kumppaniratkaisuilla voi käsitellä monia näistä skenaarioista. Kertakirjautuminen on strategia ja matka. Et pääse sinne siirtymättä kohti sovellusten standardeja. Tähän artikkeliin liittyy matka salasanattomaan todennukseen, johon ei myöskään ole maagista vastausta.

Monimenetelmäinen todentaminen (MFA) on nykyään välttämätöntä (täältä lisätietoja). Kun lisäät siihen käyttäjän käyttäytymisanalytiikkaa , sinulla on ratkaisu, joka estää yleisimmät kyberhyökkäykset. Jopa kuluttajapalvelut siirtyvät vaatimaan monimenetelmäistä todentamista. Tapaan silti monia asiakkaita, jotka eivät halua siirtyä moderniin todennustapaan . Suurin kuulemieni argumentti on, että se vaikuttaa käyttäjiin ja vanhoihin sovelluksiin. Joskus hyvä potku voi auttaa asiakkaita etenemään - Exchange Online ilmoittaneet muutoksista. Monet Microsoft Entra raportit ovat nyt käytettävissä, jotta asiakkaat voivat käsitellä tätä siirtymää.

Lupa

Wikipedian mukaan "valtuutus" on käyttöoikeuskäytännön määrittäminen. Monet käyttäjät pitävät sitä kykynä määrittää objektin käyttöoikeuksien ohjausobjekteja (tiedosto, palvelu ja niin edelleen). Nykyisessä kyberuhkien maailmassa tämä konsepti kehittyy nopeasti dynaamiseksi politiikaksi, joka voi reagoida erilaisiin uhkavektoreihin ja muokata käyttöoikeuksien valvontaa nopeasti vastauksena niihin. Jos esimerkiksi käytän pankkitiliäni epätavallisesta sijainnista, saan ylimääräisiä vahvistusvaiheita. Jotta voimme lähestyä tätä todellisuutta, meidän on tarkasteltava itse politiikan lisäksi uhkien havaitsemisen ja signaalien korrelaatiomenetelmien ekosysteemiä.

Microsoft Entra ID käytäntömoduuli otetaan käyttöön ehdollisten käyttöoikeuksien käytäntöjen avulla. Tämä järjestelmä on riippuvainen muiden uhkien havaitsemisjärjestelmien tiedoista dynaamisten päätösten tekemiseksi. Yksinkertainen näkymä olisi seuraavanlainen:

Microsoft Entra ID.

Kaikkien näiden signaalien yhdistäminen mahdollistaa tällaiset dynaamiset käytännöt:

  • Jos laitteessasi havaitaan uhka, tietojen käyttö on rajoitettu verkkoon vain ilman latauskykyä.
  • Jos lataat epätavallisen paljon tietoja, kaikki lataamaasi on salattu ja rajoitettu.
  • Jos käytät palvelua hallitsemattomassa laitteessa, et voi käyttää erittäin arkaluontoisia tietoja, mutta sinulla on oikeus käyttää ei-hallittuja tietoja ilman mahdollisuutta kopioida niitä toiseen sijaintiin.

Jos hyväksyt tämän valtuutuksen laajennetun määritelmän, sinun on toteutettava lisäratkaisuja. Käyttöönotettavat ratkaisut määräytyvät sen mukaan, miten dynaamisia haluat käytännön olevan ja mitkä uhat haluat priorisoida. Tällaisia järjestelmiä ovat esimerkiksi seuraavat:

Microsoft Entra ID lisäksi eri palveluilla ja sovelluksilla on omat valtuutusmallinsa. Joitakin näistä malleista käsitellään myöhemmin delegointiosiossa.

Tarkastuksen

Microsoft Entra ID on yksityiskohtaiset valvonta- ja raportointitoiminnot. Nämä raportit eivät kuitenkaan yleensä ole ainoa tietolähde, jota tarvitaan suojauspäätösten tekemiseen. Katso lisätietoja tästä aiheesta delegointiosiosta.

Exchangea ei ole

Älä panikoi! Exchangea (tai SharePointia ja niin edelleen) ei poisteta käytöstä. Se on edelleen keskeinen palvelu. Tarkoitan, että jo jonkin aikaa teknologiatoimittajat ovat siirtäneet käyttäjäkokemuksia (UX) useiden palvelujen komponentteihin. Microsoft 365:ssä yksinkertainen esimerkki on modernit liitteet, joihin sähköpostin liitteet tallennetaan SharePoint Onlineen tai OneDriveen.

Tiedoston liittäminen sähköpostiviestiin.

Kun tarkastelet Outlook-asiakasohjelmaa, näet monia palveluja, jotka on "yhdistetty" osana tätä käyttökokemusta, ei vain Exchangea. Tällaisia ryhmiä ovat esimerkiksi Microsoft Entra ID, Microsoft Search, Sovellukset, Profiili, yhteensopivuus ja Microsoft 365 -ryhmät.

Outlook-käyttöliittymä, jossa on kuvaselitteitä.

Lue lisää Microsoft Fluid Framework tulevien ominaisuuksien esikatselua varten. Esikatselussa voin nyt lukea Teams-keskusteluja ja vastata niihin suoraan Outlookissa. Itse asiassa Teams-asiakas on yksi tämän strategian näkyvimmistä esimerkeistä.

Kaiken kaikkiaan on yhä vaikeampaa vetää selkeä raja Microsoft 365:n ja muiden Microsoftin pilvipalveluiden välille. Pidän sitä suurena etuna asiakkaille, koska he voivat hyötyä kokonaisinnovaatiosta kaikessa, mitä teemme, vaikka he käyttäisivät yhtä osaa. Melko siisti ja sillä on kauaskantoisia vaikutuksia monille asiakkaille.

Nykyään monet IT-asiakasryhmät on jäsennelty tuotteiden ympärille. Se on loogista paikalliselle maailmalle, koska tarvitset asiantuntijan kullekin tietylle tuotteelle. Olen kuitenkin iloinen siitä, että minun ei tarvitse enää koskaan korjata Active Directory- tai Exchange-tietokannan virheitä, koska nämä palvelut ovat siirtyneet pilvipalveluun. Automaatio (eli eli pilvipalvelu) poistaa tiettyjä toistuvia manuaalisia töitä (katso, mitä tehtaille tapahtui). Nämä tehtävät korvataan kuitenkin monimutkaisemmillä vaatimuksilla, jotta voidaan ymmärtää palveluiden välistä vuorovaikutusta, vaikutusta, liiketoiminnan tarpeita ja niin edelleen. Jos olet valmis oppimaan, pilvimuunnos mahdollistaa erinomaiset mahdollisuudet. Ennen teknologiaan siirtymistä keskustelen usein asiakkaiden kanssa IT-taitojen ja tiimirakenteiden muutosten hallinnasta.

Kaikille SharePoint-faneille ja -kehittäjille lopeta kysyminen "Miten XYZ voidaan tehdä SharePoint Onlinessa?" Power Automaten (tai Flow'n) käyttäminen työnkulkuun on paljon tehokkaampi ympäristö. Azure Bot Frameworkin avulla voit luoda paremman käyttökokemuksen 500 k:n kohdeluettelollesi. Aloita Microsoft Graphin käyttäminen CSOM-toiminnon sijaan. Microsoft Teams sisältää SharePointin, mutta myös paljon muutakin. Voin luetella monia muitakin esimerkkejä. Tuolla on valtava ja ihana universumi. Avaa ovi ja aloita tutustuminen.

Toinen yleinen vaikutus on yhteensopivuusalueella. Tämä palveluiden välinen lähestymistapa näyttää sekoittavan monet yhteensopivuuskäytännöt täysin. Näen jatkuvasti organisaatioita, joissa todetaan: "Minun on kirjattava kaikki sähköpostit eDiscovery-järjestelmään." Mitä tämä lauseke todella tarkoittaa, kun sähköposti ei ole enää vain sähköposti vaan ikkuna muihin palveluihin? Microsoft 365 sisältää kattavan lähestymistavan vaatimustenmukaisuuteen, mutta ihmisten ja prosessien vaihtaminen on usein paljon vaikeampaa kuin teknologia.

On monia muita ihmisiä ja prosessin vaikutuksia. Mielestäni tämä tekijä on kriittinen ja vähätelty asia. Ehkä enemmänkin toisessa artikkelissa.

Vuokraajan rakenneasetukset

Yksittäinen vuokraaja verrattuna useaan vuokraajan vuokraajaan

Yleensä useimmilla asiakkailla tulisi olla vain yksi tuotantovuokraaja. On monia syitä, miksi useat vuokraajat ovat haastavia (anna sille Bing-haku) tai lue tämä tekninen raportti. Samalla monilla yritysasiakkailla, joiden kanssa työskentelen, on toinen (pieni) vuokraaja IT-oppimista, testausta ja kokeiluja varten. Vuokraajien välinen Azure-käyttö helpottuu Azuren majakan avulla. Microsoft 365:llä ja monilla muilla SaaS-palveluilla on rajat vuokraajien välisille skenaarioille. Microsoft Entra B2B-skenaarioissa on paljon huomioita.

Monet asiakkaat päätyvät useisiin tuotantovuokraajiin fuusion ja hankinnan jälkeen (M&A) ja haluavat yhdistää. Tämä ei ole nykyään yksinkertaista, ja se edellyttäisi Microsoft Consulting Servicesiä (MCS) tai kumppania sekä kolmannen osapuolen ohjelmistoa. Käynnissä on suunnittelutyötä, jonka avulla voidaan käsitellä erilaisia skenaarioita usean vuokraajan asiakkaiden kanssa tulevaisuudessa.

Jotkut asiakkaat valitsevat useamman kuin yhden vuokraajan. Tämän tulisi olla huolellinen päätös ja lähes aina liiketoimintaan perustuva syy! Joitakin esimerkkejä ovat seuraavat syyt:

  • Holding-tyyppinen yritysrakenne, jossa ei tarvita helppoa yhteistyötä eri entiteettien välillä ja jossa on vahvat hallinnolliset ja muut eristystarpeet.
  • Yrityskaupan jälkeen päätetään pitää kaksi entiteettiä erillään.
  • Asiakkaan ympäristön simulointi, joka ei muuta asiakkaan tuotantoympäristöä.
  • Ohjelmistojen kehittäminen asiakkaille.

Näissä usean vuokraajan skenaarioissa asiakkaat haluavat usein pitää jotkin määritykset ennallaan eri vuokraajissa tai raportoida määritysmuutoksista ja ajoista. Tämä tarkoittaa usein siirtymistä manuaalisista muutoksista määrityksiin koodina. Microsoft Premiere -tuki tarjoaa työpajaa tämäntyyppisille vaatimuksille, jotka perustuvat tähän julkiseen IP-osoiteeseen: https://Microsoft365dsc.com.

Multi-Geo

Multi-Geoon tai ei Multi-Geoon. Tämä on kysymys. Microsoft 365 Multi-Geon avulla voit valmistella ja tallentaa lepäävät tiedot maantieteellisiin sijainteihin, joiden valitset täyttävän tietojen sijaintivaatimukset . Tästä ominaisuudesta on monia väärinkäsityksiä. Pidä mielessä seuraavat asiat:

  • Se ei tarjoa suorituskykyetuja. Se voi heikentää suorituskykyä, jos verkon rakenne ei ole oikea. Laitteiden "lähellä" Microsoft-verkkoa ei välttämättä ole tiedoissasi.
  • Se ei ole ratkaisu GDPR:n noudattamiseen. GDPR ei keskity tietojen suvereniteettiin tai tallennussijainteihin. Tietojen suvereniteettiin tai tallennussijainteihin liittyy muitakin yhteensopivuuskehyksiä.
  • Se ei ratkaise hallinnon delegointia (ks. alla) tai tietoesteitä.
  • Se ei ole sama kuin usean vuokraajan, ja se edellyttää lisää käyttäjien valmistelutyönkulkuja .
  • Se ei siirrä vuokraajaasi (Microsoft Entra ID) toiselle maantieteelliselle alueelle.

Hallinnan delegointi

Useimmissa suurissa organisaatioissa tehtävien erottaminen toisistaan ja roolipohjainen käyttöoikeuksien valvonta (RBAC) on välttämätön todellisuus. Pyydän anteeksi etukäteen. Tämä toiminta ei ole niin yksinkertaista kuin jotkut asiakkaat haluavat sen olevan. Asiakas-, laki-, vaatimustenmukaisuus- ja muut vaatimukset ovat erilaisia ja toisinaan ristiriitaisia ympäri maailmaa. Yksinkertaisuus ja joustavuus ovat usein toistensa vastakkaisilla puolilla. Älä ymmärrä minua väärin, voimme tehdä parempaa työtä tässä tavoitteessa. Merkittäviä parannuksia on tehty (ja tulee olemaan) ajan mittaan. Käy paikallisessa Microsoft Technology Centerissä ja selvitä malli, joka sopii liiketoimintavaatimuksiisi lukematta 379 230 asiakirjaa! Keskityn tässä siihen, mitä sinun pitäisi ajatella, enkä siihen, miksi se on tällä tavalla. Tulossa on viisi eri aluetta, joita on suunniiltavana, ja joitakin yleisiä kysymyksiä, joita kohtaan.

Microsoft Entra ID- ja Microsoft 365 -hallintakeskukset

Valmiiden roolien luettelo on pitkä ja kasvava. Kukin rooli koostuu roolien käyttöoikeuksien luettelosta, joka on ryhmitelty yhteen tiettyjen toimintojen suorittamista varten. Näet nämä oikeudet kunkin roolin Kuvaus-välilehdessä. Vaihtoehtoisesti voit nähdä näistä käyttöoikeuksista helpommin luettavan version Microsoft 365 -hallinta Centerissä. Valmiiden roolien määrityksiä ei voi muokata. Ryhmittelen nämä roolit yleensä kolmeen luokkaan:

  • yleinen järjestelmänvalvoja: Tämän "kaikki voimakkaan" roolin pitäisi olla hyvin suojattu samalla tavalla kuin muissakin järjestelmissä. Tyypillisiä suosituksia ovat esimerkiksi seuraavat: ei pysyvää tehtävää ja Microsoft Entra Privileged Identity Management (PIM) käyttöä, vahva todentaminen ja niin edelleen. Kiinnostavaa kyllä, tämä rooli ei oletusarvoisesti anna sinulle käyttöoikeutta kaikkeen. Vaatimustenmukaisuuteen ja Azure-käyttöyhteyksiin liittyvät sekaannukset näkyvät yleensä esillä myöhemmin. Tämä rooli voi kuitenkin aina määrittää käyttöoikeudet vuokraajan muihin palveluihin.
  • Tietyt palvelun järjestelmänvalvojat: Jotkin palvelut (Exchange, SharePoint, Power BI jne.) käyttävät korkean tason hallintarooleja Microsoft Entra ID. Tämä toiminta ei ole johdonmukaista kaikissa palveluissa, ja palvelukohtaisia rooleja käsitellään tarkemmin myöhemmin.
  • Toiminnallinen: On olemassa pitkä (ja kasvava) rooliluettelo, joka keskittyy tiettyihin toimintoihin (vieraskutsuja jne.). Säännöllisesti lisää rooleja lisätään asiakkaiden tarpeiden mukaan.

Kaikkea ei voi delegoida (vaikka erot pienenevät), mikä tarkoittaa, että yleistä järjestelmänvalvojan roolia on joskus käytettävä. Koodina määritykset ja automaatio tulee ottaa huomioon tämän roolin henkilöiden jäsenyyden sijaan.

Huomautus: Microsoft 365 -hallintakeskus käyttöliittymä on käyttäjäystävällisempi, mutta sillä on vain joukko ominaisuuksia verrattuna Microsoft Entra järjestelmänvalvojan kokemukseen. Molemmat portaalit käyttävät samoja Microsoft Entra rooleja, joten muutokset tehdään samassa paikassa. Vihje: jos haluat käyttäjätietojen hallintaan keskittyvän järjestelmänvalvojan käyttöliittymän ilman kaikkia Azure-tarpeettomia osia, käytä -https://aad.portal.azure.com

Mitä nimessä on? Älä tee oletuksia roolin nimestä. Kieli ei ole tarkka työkalu. Tavoitteena on määrittää toiminnot, jotka on delegoitava ennen tarvittavien roolien tarkastelemista. Kun lisäät jonkun "suojauksen lukija" -rooliin, hän ei näe suojausasetuksia kaikissa.

Mahdollisuus luoda mukautettuja rooleja on yleinen kysymys. Tämä ominaisuus on rajoitettu Microsoft Entra tänään (kuten myöhemmin selitetään), mutta se kasvaa toiminnoissa ajan mittaan. Nämä mukautetut roolit ovat mielestäni sovellettavissa Microsoft Entra ID funktioihin, eivätkä ne välttämättä ulottu hierarkiamalliin (kuten aiemmin mainittiin). Aina kun käsittelen "mukautettua", minulla on tapana palata "yksinkertainen on parempi" -pääobjektiini.

Toinen yleinen kysymys on mahdollisuus rajata rooleja hakemiston alijoukkoon. Yksi esimerkki on esimerkiksi "Tukipalvelun järjestelmänvalvoja vain EU:ssa toimiville käyttäjille". Hallinnolliset yksiköt on tarkoitettu tähän skenaarioon vastaamiseksi. Kuten aiemmin kuvattiin, nämä vaikutusalueet ovat mielestäni sovellettavissa Microsoft Entra ID funktioihin, eivätkä ne välttämättä ulota aluetta "alas". Tietyillä rooleilla ei ole merkitystä (yleiset järjestelmänvalvojat, palvelun järjestelmänvalvojat ja niin edelleen).

Nykyään kaikki nämä roolit edellyttävät suoraa jäsenyyttä (tai dynaamista määritystä, jos käytät Microsoft Entra PIM). Tämä tarkoittaa sitä, että asiakkaiden on hallittava näitä rooleja suoraan Microsoft Entra ID, eivätkä nämä roolit voi perustua käyttöoikeusryhmän jäsenyyteen. En pidä siitä, että luon komentosarjoja näiden roolien hallitsemiseksi, koska sitä on suoritettava laajennetuilla oikeuksilla. Suosittelen yleensä ohjelmointirajapinnan integrointia prosessijärjestelmiin, kuten ServiceNow, tai kumppanihallintatyökalujen, kuten Saviyntin, käyttämistä. Tämän ongelman ratkaisemiseksi on meneillään teknisiä töitä ajan mittaan.

Mainitsin pari kertaa Microsoft Entra PIM:stä. On olemassa vastaava Microsoft Identity Manager (MIM) Privileged Access Management (PAM) -ratkaisu paikallisia ohjausobjekteja varten. Voit myös tarkastella Privileged Access Workstations -työasemia ja Microsoft Entra ID -tunnuksien hallinta. On olemassa myös erilaisia kolmannen osapuolen työkaluja, jotka voivat ottaa käyttöön juuri ajoissa, juuri tarpeeksi ja dynaamisen roolin korotuksen. Tämä ominaisuus on yleensä osa laajempaa keskustelua ympäristön suojaamiseksi.

Joskus skenaariot vaativat ulkoisen käyttäjän lisäämistä rooliin (katso edellinen usean vuokraajan osa). Tämä tulos toimii hyvin. Microsoft Entra B2B on toinen suuri ja hauska artikkeli, jossa kerrotaan asiakkaille, ehkä myös toisessa artikkelissa.

Microsoft Defender XDR ja Microsoft 365 Purview -yhteensopivuusportaalit

Sähköposti & yhteiskäyttöroolitMicrosoft Defender-portaalissa ja *Rooliryhmät Microsoft Purview -ratkaisuilleMicrosoft 365 Purview -yhteensopivuusportaalissa ovat kokoelma "rooliryhmiä", jotka ovat erillisiä ja erillisiä kuin Microsoft Entra rooleista. Tämä voi olla hämmentävää, koska joillakin näistä rooliryhmistä on sama nimi kuin Microsoft Entra rooleilla (esimerkiksi suojauksen lukija), mutta niillä voi silti olla eri jäsenyys. Pidän enemmän Microsoft Entra rooleista. Kukin rooliryhmä koostuu yhdestä tai useammasta roolista (katso, mitä tarkoitan saman sanan uudelleenkäyttämisestä?) ja siinä on Microsoft Entra ID jäseniä, jotka ovat sähköpostia käyttäviä objekteja. Voit myös luoda rooliryhmän, jolla on sama nimi kuin roolilla ja joka saattaa sisältää tai ei sisällä kyseistä roolia (vältä sekaannusta).

Tietyssä mielessä nämä käyttöoikeudet ovat Exchange-rooliryhmämallin kehitysasunnon kannalta. Exchange Online on kuitenkin oma rooliryhmän hallintaliittymä. Jotkin Exchange Online rooliryhmät lukitaan ja niitä hallitaan Microsoft Entra ID tai Microsoft Defender XDR ja Microsoft 365 Purview -yhteensopivuusportaaleista, mutta toisilla saattaa olla samat tai samankaltaiset nimet ja niitä hallitaan Exchange Online (mikä aiheuttaa sekaannusta). Suosittelen välttämään Exchange Online käyttöliittymän käyttämistä, ellet tarvitse Exchange-hallinnan käyttöalueita.

Et voi luoda mukautettuja rooleja. Roolit määritetään Microsoftin luomien palveluiden avulla, ja ne kasvavat edelleen uusien palvelujen käyttöönoton aikana. Tämä toiminta on käsitteessä samankaltaista kuin sovellusten Microsoft Entra ID määrittämät roolit. Kun uudet palvelut ovat käytössä, usein on luotava uusia rooliryhmiä, jotta niihin voidaan myöntää tai delegoida käyttöoikeus (esimerkiksi insider-riskinhallinta).

Nämä rooliryhmät edellyttävät myös suoraa jäsenyyttä, eivätkä ne voi sisältää Microsoft Entra ryhmiä. Valitettavasti Microsoft Entra PIM ei tue tällä hetkellä näitä rooliryhmiä. Kuten Microsoft Entra rooleissa, suosittelen yleensä näiden rooliryhmien hallintaa ohjelmointirajapintojen tai kumppanihallintotuotteen, kuten Saviyntin tai muiden, kautta.

Microsoft Defender portaalin ja Microsoft 365 Purview -yhteensopivuusportaalin roolit kattavat Microsoft 365:n, etkä voi rajata näitä rooliryhmiä ympäristön alijoukkoon (kuten voit käyttää hallintayksiköitä Microsoft Entra ID). Monet asiakkaat kysyvät, miten he voivat alipoistaa. Esimerkiksi "luo DLP-käytäntö vain EU-käyttäjille". Jos sinulla on tällä hetkellä oikeudet tiettyyn funktioon Microsoft Defender XDR ja Microsoft 365 Purview -yhteensopivuusportaaleihin, sinulla on oikeudet kaikkeen, mitä tämä toiminto koskee vuokraajassa. Monilla käytännöillä on kuitenkin ominaisuuksia, joiden avulla ne kohdistuvat ympäristön alijoukkoon (esimerkiksi "anna nämä tunnisteet vain näille käyttäjille"). Asianmukainen hallinto ja viestintä ovat keskeinen osa ristiriitojen välttämiseksi. Osa asiakkaista päättää toteuttaa määritys koodina -lähestymistavan alijaon käsittelemiseksi Microsoft Defender XDR ja Microsoft 365 Purview -yhteensopivuusportaaleissa. Jotkin tietyt palvelut tukevat ali delegointia (katso seuraava osio).

Palvelukohtainen

Kuten aiemmin todettiin, monet asiakkaat pyrkivät luomaan hajautetun delegointimallin. Yleinen esimerkki: "Hallitse XYZ-palvelua vain X-divisioonan käyttäjille ja sijainneille" (tai jokin muu dimensio). Kyky tehdä tämä riippuu jokaisesta palvelusta, eikä se ole yhdenmukainen kaikissa palveluissa ja ominaisuuksista. Lisäksi jokaisella palvelulla voi olla erillinen ja yksilöllinen RBAC-malli. Sen sijaan, että keskustelisin kaikista näistä malleista (jotka kestäisivät ikuisesti), lisään kullekin palvelulle asianmukaiset linkit. Tämä luettelo ei ole täydellinen, mutta sen avulla voit aloittaa.

  • Exchange Online – (/exchange/permissions-exo/permissions-exo)
  • SharePoint Online - (/sharepoint/manage-site-collection-administrators)
  • Microsoft Teams – (/microsoftteams/itadmin-readiness)
  • eDiscovery - (.. /yhteensopivuus/index.yml)
    • Käyttöoikeuksien suodatus - (.. /yhteensopivuus/index.yml)
    • Yhteensopivuusrajat - (.. /compliance/set-up-compliance-borders.md)
    • eDiscovery (Premium) - (.. /compliance/overview-ediscovery-20.md)
  • Viva Engage - (/viva/engage/manage-viva-engage-users/manage-viva-engage-admins)
  • Multi-Geo - (.. /enterprise/add-a-sharepoint-geo-admin.md)
  • Dynamics 365 – (/dynamics365/)

Huomautus

Tämä linkki on dokumentaation pääkansiossa. Järjestelmänvalvojan/delegoinnin mallissa on useita erityyppisiä palveluita, joissa on variaatioita.

  • Power Platform – (/power-platform/admin/admin-documentation)

    • Power Apps – (/power-platform/admin/wp-security)

      Huomautus

      järjestelmänvalvoja-/delegointimalleissa on useita tyyppejä, joissa on variaatioita.

    • Power Automate – (/power-automate/environments-overview-admin)

    • Power BI – (/power-bi/service-admin-governance)

      Huomautus: tietoympäristön suojaus ja delegointi (joka Power BI on osa) on monimutkainen alue.

  • Intune – (/mem/intune/fundamentals/role-based-access-control)

  • Microsoft Defender for Endpoint – (/windows/security/threat-protection/microsoft-defender-atp/user-roles)

  • Microsoft Defender XDR - (.. /security/defender/m365d-permissions.md)

  • Microsoft Defender for Cloud Apps – (/cloud-app-security/manage-admins)

  • Stream – (/stream/assign-administrator-user-role)

  • Tietoesteet - (.. /vaatimustenmukaisuus/tietoesteet.md)

Toimintolokit

Microsoft 365:ssä on yhdistetty valvontaloki. Se on hyvin yksityiskohtainen loki, mutta älä lue liikaa nimeen. Se ei ehkä sisällä kaikkea, mitä haluat tai tarvitset suojaus- ja yhteensopivuustarpeitasi varten. Jotkut asiakkaat ovat myös erittäin kiinnostuneita auditoinnista (Premium)..

Esimerkkejä Microsoft 365 -lokeista, joita käytetään muiden ohjelmointirajapintojen kautta, ovat seuraavat ominaisuudet:

On tärkeää tunnistaa ensin kaikki suojaus- ja yhteensopivuusohjelman tarvitsemat lokilähteet. Huomaa myös, että eri lokeilla on erilaiset on-line-säilytysrajat.

Järjestelmänvalvojan delegoinnin näkökulmasta useimmissa Microsoft 365:n toimintolokeissa ei ole sisäistä RBAC-mallia. Jos sinulla on oikeus nähdä loki, näet sen kaiken. Yleinen esimerkki asiakkaan vaatimuksesta on: "Haluan pystyä tekemään kyselyjä vain EU-käyttäjille" (tai jokin muu dimensio). Tämän vaatimuksen saavuttamiseksi meidän on siirrettävä lokit toiseen palveluun. Microsoftin pilvipalvelussa suosittelemme sen siirtämistä joko Microsoft Sentineliin tai Log Analyticsiin.

Ylätason kaavio:

suojaus- ja yhteensopivuusohjelman lokilähteiden kaavio.

Kaavio edustaa sisäisiä ominaisuuksia, joiden avulla voit lähettää lokeja tapahtumatoimintoihin ja/tai Azure-tallennustilaan ja/tai Azure Log Analyticsiin. Kaikki järjestelmät eivät vielä sisällä tätä käyttövalmiita. Näiden lokien lähettämiseksi samaan säilöön on kuitenkin muitakin menetelmiä. Katso esimerkiksi teamsin suojaaminen Microsoft Sentinelillä.

Kaikkien lokien yhdistäminen yhteen tallennussijaintiin tuo lisäetua, kuten ristiinkorrelaatioita, mukautettuja säilytysaikoja, lisätietoja, joita tarvitaan RBAC-mallin tukemiseen, ja niin edelleen. Kun tiedot ovat tässä tallennusjärjestelmässä, voit luoda Power BI -koontinäytön (tai muun tyyppisen visualisoinnin) sopivalla RBAC-mallilla.

Lokeja ei tarvitse ohjata vain yhteen paikkaan. Microsoft 365 -lokien integrointi Microsoft Defender for Cloud Apps tai mukautettuun RBAC-malliin Power BI:ssä voi olla hyödyllistä. Eri säilöillä on erilaiset edut ja yleisöt.

Kannattaa mainita, että Microsoft Defender XDR-nimisessä palvelussa on monipuolinen sisäinen analytiikkajärjestelmä suojausta, uhkia ja haavoittuvuuksia varten.

Monet suuret asiakkaat haluavat siirtää nämä lokitiedot kolmannen osapuolen järjestelmään (esimerkiksi SIEM). Tähän tulokseen on erilaisia lähestymistapoja, mutta yleiset Azure-tapahtumatoiminnot ja Graph ovat hyviä aloituspisteitä.

Azure

Minulta kysytään usein, onko olemassa tapaa erottaa rooleja Microsoft Entra ID, Azuren ja SaaS:n välillä (esimerkiksi Microsoft 365:n yleinen järjestelmänvalvoja, mutta ei Azure). Ei oikeastaan. Usean vuokraajan arkkitehtuuria tarvitaan, jos täydellinen hallinnollinen erittely vaaditaan, mutta se lisää merkittävästi monimutkaisuutta (kuten aiemmin mainittiin). Kaikki nämä palvelut kuuluvat samaan suojaus-/käyttäjätietorajaan (kuten hierarkiamallissa näkyy).

On tärkeää ymmärtää saman vuokraajan eri palveluiden välisiä suhteita. Työskentelen monien asiakkaiden kanssa, jotka rakentavat liiketoimintaratkaisuja Azureen, Microsoft 365:een ja Power Platformiin (ja usein myös paikallisiin ja kolmannen osapuolen pilvipalveluihin). Yksi yleinen esimerkki:

  1. Haluan käsitellä yhdessä asiakirjoja/kuvia/jne. (Microsoft 365)
  2. Lähetä kukin heistä hyväksyntäprosessin kautta (Power Platform)
  3. Kun kaikki osat on hyväksytty, kokoa nämä kohteet yhtenäiseksi toimitukseksi (Azure) Microsoft Graph -ohjelmointirajapinta on paras ystäväsi tässä. Ei mahdotonta, mutta huomattavasti monimutkaisempaa suunnitella ratkaisu, joka kattaa useita vuokraajia.

Azure Role-Based Käyttöoikeuksien hallinta (RBAC) mahdollistaa tarkan käytön hallinnan Azuressa. RBAC:n avulla voit hallita resurssien käyttöoikeuksia myöntämällä käyttäjille oikeudet, joita heidän työnsä edellyttää. Tämän asiakirjan tiedot eivät kuulu tämän asiakirjan piiriin, mutta lisätietoja RBAC:stä on artikkelissa Mikä on roolipohjainen käytönvalvonta (RBAC) Azuressa? RBAC on tärkeä, mutta vain osa Azuren hallintoon huomioitavia seikkoja. Pilvipalvelujen käyttöönottokehys on hyvä lähtökohta oppia lisää. Pidän siitä, miten ystäväni Andres Ravinet ohjaa asiakkaat vaihe vaiheittain eri osien läpi päättääkseen lähestymistavasta. Korkean tason näkymä eri elementeille (ei niin hyvä kuin prosessi todelliseen asiakasmalliin pääsemiseksi) on jotain tämänkaltaista:

Azure-osien ylätason näkymä delegoitua hallintaa varten.

Kuten yllä olevasta kuvasta näkyy, monet muut palvelut tulee ottaa huomioon osana suunnittelua (esim. Azure-käytännöt, Azure Blueprints, hallintaryhmät jne.).

Päätelmä

Tämä artikkeli alkoi lyhyenä yhteenvetona, joka päättyi odotettua pidemmäksi. Toivon, että olet nyt valmis tutustumaan syvällisesti delegointimallin luomiseen organisaatiollesi. Tämä keskustelu on hyvin yleinen asiakkaiden kanssa. Mikään malli ei toimi kaikille. Odotetaan muutamia suunniteltuja parannuksia Microsoftin teknikosta ennen yleisten mallien dokumentointia, joita näemme asiakkaiden välillä. Sillä välin voit tehdä yhteistyötä Microsoft-tilitiimisi kanssa ja järjestää vierailun lähimpään Microsoftin teknologiakeskukseen. Nähdään siellä!