Azure-vuokralaisesi on käytäntöjen kaatopaikka
Pilvipalveluiden käyttöönottokehys: Kuinka hallintaryhmät korjaavat sietämäsi tietoturvakaaoksen
Ensimmäisenä päivänään Marta avasi Azure-portaalin ja laski suoraan pääkäyttäjäryhmän alaisuudessa olevat tilaukset. Neljäkymmentäseitsemän.
Ei hierarkiaa. Ei periytyviä käytäntöjä. Ei yhtenäistä RBAC-palvelua. Tietoturvahälytykset syttyvät Defender for Cloudissa ilman selkeää omistajaa. Jokainen tiimi oli varannut tarvitsemansa resurssit silloin, kun he sitä tarvitsivat, sillä kenellä tahansa omistajan oikeuksilla kyseisellä viikolla.
Vuokralainen oli kasvanut kolme vuotta. Kukaan ei ollut koskaan vetänyt rajaa maahan ja sanonut: Näin asiat on täällä järjestetty.
Tämä on yleisin kypsän Azure-ympäristön tila. Kyse ei ole yhden resurssin tietomurrosta tai virheellisestä määrityksestä, vaan rakenteellisesta ongelmasta; kaiken muun mahdollistavan tietoturvaperustan puuttumisesta.
Johtoryhmä ei ole organisaatiokaavio
Ensimmäinen virhe, jonka useimmat joukkueet tekevät Azure-hallintaryhmät kohtelee niitä kuin organisaatiokaavionsa heijastusta. Rahoitustilaukset talousryhmän alla. Markkinointi markkinoinnin alla. IT IT:n alla. Siististi diaesityksessä. Hyödytön turvallisuuden kannalta.
Johtoryhmiä on olemassa yhdestä syystä: antaakseen sinulle paikan, johon voit määrittää tehtäviä Azure-käytäntö ja RBAC-roolit, jotka periytyvät alaspäin jokaiselle niiden alapuolella olevalle tilaukselle ja resurssille. Tämä tarkoittaa, että hierarkian tulisi heijastaa tietoturvan tilaa ja yhteysvaatimuksia, ei liiketoimintayksiköitä.
CAF-johtoryhmän ohjeistus on selvä: pidä hierarkia tasaisena (tavoitteena on kolme tai neljä tasoa) ja vastusta syvyyden vetoa. Kuusitasoinen hierarkia on olemassa alustan rajana, eikä sitä pitäisi koskaan päästä lähelle.
”Älä monista organisaatiorakennettasi syvälle sisäkkäiseksi hallintaryhmähierarkiaksi. Käytä hallintaryhmiä käytäntöjen määrittämiseen laskutuksen sijaan ja RBAC-tarkoituksiin.” – Microsoft CAF, Hallintaryhmät
Toimiva arkkitehtuuri
Azuren laskeutumisvyöhykkeen viitearkkitehtuuri määrittelee hallintaryhmärakenteen, joka on validoitu tuhansissa yrityskäyttöönotoissa. Se näyttää tältä.
Välijuuri: Sijaitsee suoraan vuokraajan päätason alapuolella. Kaikki muut ryhmät sijaitsevat täällä. Eristää hierarkian pääryhmästä ja sallii olemassa olevien tilausten siirtämisen sisään.
foorumiSisältää hallinnan, yhdistettävyyden, identiteetin ja tietoturvan aliryhmät. Nämä isännöivät jaettuja infrastruktuuritilauksia, joista koko organisaatiosi on riippuvainen.
TurvallisuusMicrosoft Sentinelille, lokitietojen kerääjille ja SIEM-työkaluille on oma tilaus. Tietoturvatiimi omistaa tämän. Kukaan muu.
videonhallintaAzure Monitor Logs -työtila, lokianalytiikkaratkaisut ja valvontainfrastruktuuri.
LiitännätAzure-palomuuri, virtuaalinen WAN, DNS-yksityiset vyöhykkeet, verkkoyhdyskäytävät. Valtatie, jota pitkin työkuormasi kulkevat.
IdentiteettiAD DS -toimialueen ohjauskoneisiin tarkoitetut virtuaalikoneet tai Microsoft Entra -toimialueen palvelut työkuormille, jotka vaativat perinteistä toimialueelle liittymistä, LDAP:tä tai Kerberosta. Pelkkää Entra ID:tä käyttävät organisaatiot ohittavat tämän ryhmän yleensä kokonaan.
LaskeutumisalueetKaikkien työkuormatilausten pääryhmä. Käytäntömääritykset koskevat kaikkea, mitä tiimisi rakentaa.
CorpTyökuormat, jotka tarvitsevat hybridiyhteyden takaisin paikalliseen järjestelmään Connectivity-kohdan keskittimen kautta.
VerkossaTyökuormat, jotka tarvitsevat suoran internet-yhteyden, virtuaaliverkon avulla tai ilman.
hiekkalaatikotErillään yrityksistä ja verkosta. Vähemmän rajoittava käytäntö. Vain kokeiluun ja tutkimukseen.
Käytöstä poistettuPoistoa odottavat laskeutumisvyöhykkeet. Siirretty tänne ennen kuin Azure poistaa ne 30–60 päivän kuluttua.
Tämä ei ole teoreettinen malli. Kun käyttöönotto tapahtuu Azure Landing Zones Bicep -mallien kautta, saat hierarkian, RBAC-määritykset ja alkuperäisen käytäntöjoukon yhdessä käyttöönottotyönkulussa.
Politiikka virtaa alaspäin. Siinä se pointti onkin.
Jokainen hallintaryhmätasolla määritetty Azure-käytäntö tai käytäntöaloite periytyy jokaiselle sen alapuolella olevalle tilaukselle ja resurssiryhmälle. Määritä käytäntö Intermediate Root -ryhmällesi, niin se koskee kaikkia. Määritä se laskeutumisvyöhykkeille, niin se koskee kaikkia työkuormatilauksia, niin yritys- kuin online-versioitakin.
Näin varmistat tietoturvan skaalautuvasti ilman manuaalisia toimia. CAF-turvallisuussuunnittelualue suosittelee tiettyjä peruskäytäntöjä verkko- ja yritysverkkoihin kytketyille laskeutumisalueille:
Nämä määritetään kerran Landing Zones -hallintaryhmässä, ja jokainen Corpiin tai Onlineen myytävä työkuormatilaus perii ne automaattisesti. Uutta palvelua valmisteleva kehittäjätiimi saa jo vaatimustenmukaisen tilauksen ennen ensimmäisen resurssinsa käyttöönottoa.
Pohjimmiltaan politiikka: ole konservatiivinen.
CAF-ohjeistus suosittelee nimenomaisesti käytäntöjen määrittämisen rajoittamista juuritason hallintaryhmässä. On vaikea selvittää, miksi juuritasolta peritty käytäntö estää seitsemän tasoa alempana olevan käyttöönoton. Määritä vain laajimmat ja yleismaailmallisimmat ohjausobjektit juuritasolle. Kaikki erityiset ohjausobjektit menevät laskeutumisvyöhykkeille tai niiden alapuolelle.
RBAC hallintaryhmän laajuudessa: Käytä sitä huolellisesti
RBAC-määritykset periytyvät myös alaspäin. Tämä tarkoittaa, että osallistujan roolin määrittäminen tiimille hallintaryhmätasolla antaa heille pääsyn kaikkiin kyseisen ryhmän tilauksiin – ja kaikkiin tulevaisuudessa lisättäviin tilauksiin.
Se on voimakas. Se on myös vaarallinen väärinkäytettynä. johtoryhmän suositukset ovat eksplisiittisiä: älä määritä sovellustiimin oikeuksia RBAC:n kautta hallintaryhmän laajuusalueilla. Anna heille käyttöoikeudet tilaus- tai resurssiryhmätasolla – yleensä tämä käsitellään tilausmyyntiprosessin kautta.
Alustatiimit ovat poikkeus. He tarvitsevat usein tilaustenvälisen käyttöoikeuden työnsä suorittamiseen. Mutta jopa sen tulisi olla suojattua. Microsoft siirtyy Privileged Identity Managementiin (PIM) — juuri oikea-aikainen käyttöoikeus, ei pysyviä oikeuksia. Alustakehittäjällä ei pitäisi olla pysyvää omistajaa jokaiselle vuokraajan tilaukselle, koska se on kätevää.
Hiekkalaatikot ja pysyvien poikkeusten houkutus
Jokainen laskeutumisalueen arkkitehtuuri tarvitsee hiekkalaatikkoryhmän. Hiekkalaatikon hallintaryhmällä on tarkoituksella vähemmän rajoittava käytäntöjoukko, koska siellä tiimit kokeilevat, tutkivat uusia Azure-palveluita ja rikkovat asioita turvallisesti. Se on sen tehtävä.
Vikatilassa hiekkalaatikosta tulee vahingossa pysyvä tuotantoympäristö. Prototyyppi, jota ei koskaan siirretty Corpille. Kertaluonteinen prosessi, joka on edelleen käynnissä tilauksessa, jonka piti olla väliaikainen. Käytöstä poistettujen ryhmällä on syynsä: tilaukset, jotka pysyvät tarkoituksensa ulkopuolella, kuuluvat sinne, eivätkä hiekkalaatikoihin loputtomiin.
Määritä oletusarvoinen hallintaryhmä, jotta uudet tilaukset eivät päädy päätason hallintaryhmään. Millään päätason tilauksella ei ole käytäntöjen periytymistä eikä määriteltyä RBAC-rakennetta. Aseta oletusarvoksi Sandboxit. Ainakin silloin on olemassa raja.
Aluepohjaiset hierarkiat: Älä tee sitä
Yksi toistuvimmista virheistä usean alueen käyttöönotoissa on rakentaa hallintaryhmäpuu, joka heijastaa maantiedettä. Eurooppa-ryhmä. Amerikka-ryhmä. Aasian ja Tyynenmeren ryhmä. Se näyttää järjestelmälliseltä. Se taistelee sinua vastaan joka käänteessä.
CAF on yksiselitteinen: älä luo hallintaryhmiä pelkästään eri Azure-alueiden mallintamista varten. Älä muuta hierarkiaasi usean alueen käytön perusteella. Ainoa poikkeus ovat aidot sääntelyvaatimukset; tietojen sijainti ja tietojen suvereniteetti, joissa tarvitset sijaintiin perustuvia käytäntöjä. Tässä tapauksessa sijaintiin perustuva rakenne tietyllä hierarkian tasolla on puolustettava. Mukavuus ei ole kelpoisuusperuste.
Martan toinen viikko
Ensimmäisen viikkonsa loppuun mennessä Martalla oli ehdotus paperilla: Intermediate Root -ryhmä, sen alla Platform ja laskeutumisalueet, tilaukset yhdistetty Corpiin tai Onlineen niiden yhteystarpeiden perusteella, ja tietoturvatiimin Sentinel-työtila siirrettiin erilliseen tietoturvatilaukseen Platformin alle.
Toinen viikko oli migraatio. Neljäkymmentäseitsemän tilausta ei järjesty uudelleen. Mutta kun rakenne oli paikoillaan, käytäntöjen periytyminen teki raskaan työn. Defender for Cloud -suositukset lakkasivat olemasta melua ja niistä tuli käytännöllisiä. Uudet tiimit saivat sääntöjen mukaiset tilaukset heti ensimmäisenä päivänä. Hälytykset saivat omistajat.
Juuri tätä hyvin jäsennelty hallintaryhmähierarkia tarjoaa: perustan, jolle johdonmukainen, täytäntöönpanokelpoinen ja auditoitava tietoturva on mahdollista. Sitä ei voi kiinnittää jälkikäteen. Hierarkian on oltava etusijalla.
Hierarkian oikeanlaiseksi saaminen on vaikein osa
Useimmat organisaatiot ottavat Cloud Adoption Frameworkin tietoturvan hallinnan käyttöön liian myöhään. Kun tilausten määrä on kasvanut, käytännöt ovat epäjohdonmukaisia ja RBAC-määritykset ovat levinneet laajemmalle kuin kukaan täysin ymmärrä. Toimivan vuokralaisen uudelleenarkkitehtuuri on vaikeampaa kuin sen rakentaminen alusta alkaen, ja päätökset moninkertaistuvat: jokainen uusi tilaus perii nykyisen rakenteen, parempaan tai huonompaan suuntaan.
Fortytwo työskentelee organisaatioiden kanssa juuri tässä käännekohdassa: auttaa alusta- ja tietoturvatiimejä suunnittelemaan laskeutumisalueiden arkkitehtuureja, jotka kestävät todellista operatiivista painetta, ja kääntää CAF-periaatteet käyttöönotettaviksi Bicep- ja käytäntökonfiguraatioiksi, jotka toimivat juuri sinun ympäristössäsi. Jos Azure-vuokralaisesi on kasvanut nopeammin kuin sen hallinta, tämä on keskustelu, jossa sinun kannattaa keskustella.
Puhu meille
Soita meille, jos haluat keskustella haasteistasi tai kysymyksistäsi.
