Mitä poikkeus maksaa
Landing zone suunnitellaan kerran ja laajennetaan käytössä, ja juuri siitä sen varsinainen tarina alkaa. Ensimmäinen projekti tiukan deadlinen kanssa saa subscriptionsa hierarkian ulkopuolelta, koska policy-review olisi kestänyt sprintin yli. Toimittaja, joka jumittui Contributor-oikeuksilla perjantai-iltapäivänä, saa Owner-oikeudet Management Groupille ja pitää ne, koska go-liven jälkeen kukaan ei enää muista asiaa. Ja kun hubin palomuuri hidastaa spoken liikennettä, spoke saa peeringin suoraan, hubin ohi. Jokainen näistä päätöksistä oli tilanteessaan järkevä, ja jokainen on yhä voimassa.
Seuraukset ovat konkreettisia. Hierarkian ulkopuolinen subscription ei peri policya, joten policy ei myöskään suojaa sitä. Owner Management Group -tasolla periytyy jokaiselle sen alla olevalle subscriptionille, myös niille, joita ei tuolloin vielä ollut. Peering ilman reittiä palomuurille on verkkoväylä, jota teidän SOC ei näe. Azure Landing Zone Review asettaa suunnitelman ja nykytilan päällekkäin Cloud Adoption Frameworkin kahdeksan design arean mukaisesti ja järjestää poikkeamat niiden seurausten, ei ikänsä, mukaan.
Cloud Adoption Frameworkin kahdeksat design areat
Microsoft on jakanut landing zonen päätökset kahdeksaan design areaan, koska muuten suurin osa virheistä piiloutuu tiimien välisiin rakoihin: verkostotiimi rakentaa hubin, identity-tiimi jakaa roolit, eikä kumpikaan kirjanpito kerro, kuka policy-poikkeuksen hyväksyi. Käymme kaikki kahdeksan läpi samalla kysymyksellä: mitä oli suunniteltu, mitä on rakennettu ja mitä ero tarkoittaa.
Azure Billing ja Entra-tenant
Enrollment, laskutushierarkia ja tenant, jolle kaikki nojaa. Yrityskaupasta peräisin oleva toinen tenant on harvoin ongelma, kunnes joku joutuu yhdistämään lisenssit, identiteetit ja laskut.
Identity ja Access Management
Roolit alustatason, Service Principalit ja PIM. Owner Root Management Groupilla periytyy äänettömästi jokaiselle myöhemmin luotavalle subscriptionille.
Resource Organization
Management Group -hierarkia, subscription-rakenne, nimet ja tagit. Väärässä Management Groupissa olevat workloadit perivät väärät policyit, ja se huomataan vasta auditissa.
Network Topology ja Connectivity
Hub-and-Spoke tai Virtual WAN, hybridiyhteys, DNS, palomuuri, Private Endpointit. Peering hubin ohi on teknisesti siisti ja SOCille näkymätön.
Security
Defender for Cloud, salaus, Key Vaultit ja kaikki, mikä sijaitsee alustalla workloadin sijaan. Defender-suunnitelma, joka on aktiivinen vain osassa subscriptioita, suojaa täsmälleen tuon osan.
Management
Monitoring, logging, backup ja recovery. Puuttuvat Diagnostic Settings eivät näy normaalissa käytössä vaan incidentin aikana, kun tarvitaan logeja, joita ei koskaan kirjoitettu.
Governance
Azure Policy, initiatiivit, poikkeukset ja kustannusten hallinta. Exemptionilla on vanhenemispäivä, jos joku on sen asettanut. Useimmilla ei ole.
Platform Automation ja DevOps
Infrastructure as Code, pipelinelit, Azure Verified Modulet. Alustalla, jota muutetaan portaalin kautta, on kaksi totuutta: repositoryssa oleva ja Azuressa oleva. Jälkimmäinen on se voimassa oleva.
Näin se etenee
- Haastattele tiimiHaastattele tiimiAloitamme ihmisistä, jotka operoivat alustaa, ei työkalusta: arkkitehtuuri, välineet, operatiiviset prosessit, strategia. Useimmilla myöhemmin skannerin löytämillä havainnoilla on taustansa, ja kun taustan tuntee, osaa arvioida löydön oikein. Tietoinen päätös on eri asia kuin unohtunut väliaikaisratkaisu.
- Lue ympäristöLue ympäristöSen jälkeen luemme ympäristön työkalujen avulla: Management Groupit, policyit ja exemptionit, roolimääritykset, verkkoväylät, Diagnostic Settingsit, kustannukset. Automatisoidusti ja ajantasaista Cloud Adoption Frameworkia vasten, ei kolme vuotta vanhaa versiota.
- Järjestä löydöksetJärjestä löydöksetTyökalu löytää poikkeaman, haastattelu selittää sen, ja vasta yhdessä ne muodostavat prioriteetin. Listan kärkeen nousee se, mikä perii oikeuksia tai estää logien kirjoittamisen, ja alemmalle sijalle se, mikä rikkoo nimeämiskäytäntöä. Löydös ilman seurauksia on muistiinpano, ei toimeksianto.
- Käy raportti läpiKäy raportti läpiSaatte raportin, jossa on kypsyystaso jokaiselle design arealle, löydökset ja suositukset, ja käymme sen yhdessä läpi. Ei siksi, että tuntisitte sata löydöstä, vaan siksi, että maanantaina tiedätte, mistä aloittaa.
Raportti järjestyksellä
Saatte raportin, joka arvioi landing zonenne Cloud Adoption Frameworkin kahdeksan design arean mukaisesti: kypsyystaso alueittain, priorisoidut löydökset ja suositukset, jotka alustatiimi voi toteuttaa ilman meiltä kysymistä. Lisäksi erottelun, johon mikään skanneri ei pysty: kumpi frameworkista poikkeaminen oli tietoinen päätös ja kumpi vahinko. Raportti on tarkoitettu alustatiimeille ja IT-johdolle, jotka ovat operoineet landing zonea jo muutaman vuoden ja haluavat tietää, mitä on muuttunut, sekä ympäristössä että frameworkissa. Jos edessä on migraatio, kannattaa tarkastaa perusta ennen muuttoa. Jos alusta on otettu haltuun toimittajalta, tarvitaan toinen silmäpari, joka ei ole rakentanut sitä, mitä arvioi. Toteutus ei sisälly tähän. Se toteutetaan erillisenä projektina, kanssamme, kumppanin kanssa tai oman tiimin voimin.
Ja sen jälkeen
Mitä meiltä kysytään etukäteen
Ensimmäisissä keskusteluissa esitetyt kysymykset, vastattuna niin kuin vastaamme ne siellä.
Tarvitsemmeko siihen landing zonen glueckkanjalta?
Ei. Arvioimme jokaisen landing zonen, olipa se peräisin Enterprise-Scale-templatesta, toiselta toimittajalta tai portaalin kautta kasvanut. Mittapuu on Cloud Adoption Framework, ei meidän Azure Foundationimme. Se, että suosittelemme sitä, jos raportti antaa aihetta, ei ole yllätys, mutta ei myöskään ehto.
Mitä eroa on reviewillä ja Preventive Servicesin Modul Azurella?
Kysymyksessä, joka esitetään. Modul Azure kysyy, miten hyökkääjä pääsee subscriptionilta hallintatasolle, ja päättyy kovennusroadmappiin. Landing Zone Review kysyy, kannateleeko alusta kokonaisuutena: organisaatio, verkko, governance, operointi, automaatio, kustannukset. Security on siinä yksi kahdeksasta design areasta. Jos haluaa molemmat, kannattaa aloittaa reviewillä, koska se toimittaa kartan, jolle moduuli merkitsee reitit.
Mitä oikeuksia tarvitsette?
Lukuoikeudet. Analyysiin riittää Reader-rooli ylimmällä Management Groupilla täydennettynä Cost Managementin lukuoikeuksilla. Emme muuta mitään, ja tunnukset poistetaan reviewin jälkeen. Se, että review voidaan suorittaa Reader-oikeuksilla, on jo itsessään löydös: landing zone, jossa se ei onnistu, on löytänyt ensimmäisen aiheensa.
Tarkastatteko myös kustannukset?
Kyllä, koska landing zonessa niillä on samat juurisyyt kuin governance-löydöksillä. Ilman tageja laskua ei voi kohdistaa millekään tiimille, ilman budget-alerteja unohtunut VM huomataan vasta kuun lopussa, ja reservointi, jota kukaan ei ylläpidä, maksaa kapasiteetista, jota kukaan ei käytä. Sieltä nousevat havainnot kirjataan raporttiin lukuineen.
Kuinka kauan review kestää?
Haastattelu ja analyysi vievät muutaman päivän. Teidän puoleltanne se vaatii haastatteluajan, lukuoikeuksien myöntämisen ja tilaisuuden, jossa käymme raportin läpi. Vaativampi osuus on se, mitä teette listan kanssa sen jälkeen, ja se kuuluu teille.
Sisältyykö toteutus mukaan?
Ei, ja se on tarkoituksellista. Review, joka priorisoi omia jatkotoimeksiantojaan, ei ole review. Saatte järjestyksen ja suositukset, toteutus etenee erillisenä projektina, kanssamme, kumppanin kanssa tai oman tiimin voimin. Jos landing zone halutaan sen jälkeen rakentaa uudelleen, Azure Foundation on siihen tie.
