Dela via

Metodtips för alla isoleringsarkitekturer

  • Artikel

Följande är designöverväganden för alla isoleringskonfigurationer. I det här innehållet finns det många länkar. Vi länkar till innehåll i stället för att duplicera det här, så att du alltid har åtkomst till den senaste informationen.

Allmän vägledning om hur du konfigurerar Microsoft Entra-klienter (isolerade eller inte) finns i distributionsguiden för Microsoft Entra-funktioner.

Kommentar

För alla isolerade klienter rekommenderar vi att du använder tydlig och differentierad varumärkesanpassning för att undvika mänskliga fel när du arbetar i fel klientorganisation.

Isoleringssäkerhetsprinciper

När du utformar isolerade miljöer är det viktigt att tänka på följande principer:

  • Använd endast modern autentisering – Program som distribueras i isolerade miljöer måste använda anspråksbaserad modern autentisering (till exempel SAML, * Auth, OAuth2 och OpenID Connect) för att kunna använda funktioner som federation, Microsoft Entra B2B-samarbete, delegering och ramverket för medgivande. På så sätt går äldre program som är beroende av äldre autentiseringsmetoder som NT LAN Manager (NTLM) inte vidare i isolerade miljöer.

  • Framtvinga stark autentisering – Stark autentisering måste alltid användas vid åtkomst till isolerade miljötjänster och infrastruktur. När det är möjligt bör lösenordslös autentisering som Windows för företag Hello eller en FIDO2-säkerhetsnycklar användas.

  • Distribuera säkra arbetsstationer - Säkra arbetsstationer tillhandahåller mekanismen för att säkerställa att plattformen och den identitet som plattformen representerar är korrekt intygade och skyddade mot utnyttjande. Två andra metoder att tänka på är:

    • Använd Windows 365 Računar u oblaku (Cloud PC) med Microsoft Graph API.

    • Använd villkorsstyrd åtkomst och filtrera för enheter som ett villkor.

  • Eliminera äldre förtroendemekanismer – Isolerade kataloger och tjänster bör inte upprätta förtroenderelationer med andra miljöer via äldre mekanismer som Active Directory-förtroenden. Alla förtroenden mellan miljöer bör upprättas med moderna konstruktioner som federations- och anspråksbaserad identitet.

  • Isolera tjänster – Minimera ytangreppsområdet genom att skydda underliggande identiteter och tjänstinfrastruktur från exponering. Aktivera endast åtkomst via modern autentisering för tjänster och säker fjärråtkomst (även skyddad av modern autentisering) för infrastrukturen.

  • Rolltilldelningar på katalognivå – Undvik eller minska antalet rolltilldelningar på katalognivå (användaradministratör för katalogomfång i stället för AU-omfång) eller tjänstspecifika katalogroller med kontrollplansåtgärder (Kunskapsadministratör med behörighet att hantera medlemskap i säkerhetsgrupper).

Förutom vägledningen i den allmänna driftsguiden för Microsoft Entra rekommenderar vi även följande överväganden för isolerade miljöer.

Etablering av mänsklig identitet

Privilegierade konton

Etablera konton i den isolerade miljön för administrativ personal och IT-team som driver miljön. På så sätt kan du lägga till starkare säkerhetsprinciper, till exempel enhetsbaserad åtkomstkontroll för säkra arbetsstationer. Som beskrivs i föregående avsnitt kan icke-produktionsmiljöer potentiellt använda Microsoft Entra B2B-samarbete för att registrera privilegierade konton till icke-produktionsklienter med samma hållning och säkerhetskontroller som är utformade för privilegierad åtkomst i produktionsmiljön.

Molnbaserade konton är det enklaste sättet att etablera mänskliga identiteter i en Microsoft Entra-klientorganisation och passar bra för miljöer med gröna fält. Men om det finns en befintlig lokal infrastruktur som motsvarar den isolerade miljön (till exempel förproduktion eller hantering av Active Directory-skogen) kan du överväga att synkronisera identiteter därifrån. Detta gäller särskilt om den lokala infrastruktur som beskrivs häri används för IaaS-lösningar som kräver serveråtkomst för att hantera lösningsdataplanet. Mer information om det här scenariot finns i Skydda Microsoft 365 från lokala attacker. Synkronisering från isolerade lokala miljöer kan också behövas om det finns specifika krav för regelefterlevnad, till exempel endast autentisering med smartkort.

Kommentar

Det finns inga tekniska kontroller för identitetsbevisning för Microsoft Entra B2B-konton. Externa identiteter som etableras med Microsoft Entra B2B är bootstrappade med en enda faktor. Åtgärden är till för att organisationen ska ha en process för att bevisa de identiteter som krävs innan en B2B-inbjudan utfärdas och regelbundna åtkomstgranskningar av externa identiteter för att hantera livscykeln. Överväg att aktivera en princip för villkorsstyrd åtkomst för att styra MFA-registreringen.

Outsourcing av högriskroller

För att minimera interna hot är det möjligt att outsourca åtkomst till roller som global administratör och privilegierad rolladministratör för att vara hanterad tjänstleverantör med Hjälp av Azure B2B-samarbete eller delegera åtkomst via en CSP-partner eller lighthouse. Den här åtkomsten kan styras av intern personal via godkännandeflöden i Azure Privileged Identity Management (PIM). Den här metoden kan avsevärt minska inifrån hot. Det här är en metod som du kan använda för att uppfylla efterlevnadskrav för kunder som har problem.

Etablering av icke-mänsklig identitet

Konton för nödåtkomst

Microsoft rekommenderar att organisationer har två molnbaserade konton för nödåtkomst permanent tilldelade rollen Global administratör . Dessa konton är mycket privilegierade och tilldelas inte till specifika individer. Kontona är begränsade till nödsituations- eller "break glass"-scenarier där normala konton inte kan användas eller alla andra administratörer av misstag är utelåst. Dessa konton bör skapas enligt rekommendationerna för kontot för nödåtkomst.

Azure-hanterade identiteter

Använd Azure-hanterade identiteter för Azure-resurser som kräver en tjänstidentitet. Kontrollera listan över tjänster som stöder hanterade identiteter när du utformar dina Azure-lösningar.

Om hanterade identiteter inte stöds eller inte är möjliga kan du överväga att etablera tjänstens huvudnamnsobjekt.

Hybridtjänstkonton

Vissa hybridlösningar kan kräva åtkomst till både lokala och molnbaserade resurser. Ett exempel på ett användningsfall skulle vara ett program som använder ett tjänstkonto i AD DS för åtkomst till lokala domänanslutna servrar och även har ett konto i Microsoft Entra-ID eftersom det kräver åtkomst till Microsoft Online Services.

Lokala tjänstkonton har vanligtvis inte möjlighet att logga in interaktivt, vilket innebär att de i molnscenarier inte kan uppfylla starka krav på autentiseringsuppgifter, till exempel multifaktorautentisering. I det här scenariot ska du inte använda ett tjänstkonto som har synkroniserats lokalt, utan i stället använda en hanterad identitet \ tjänstens huvudnamn. För tjänstens huvudnamn (SP) använder du ett certifikat som autentiseringsuppgifter eller skyddar SP med villkorsstyrd åtkomst.

Om det finns tekniska begränsningar som inte gör detta möjligt och samma konto måste användas för både lokalt och i molnet, implementerar du kompenserande kontroller som villkorsstyrd åtkomst för att låsa hybridkontot som ska komma från en specifik nätverksplats.

Resurstilldelning

En företagslösning kan bestå av flera Azure-resurser och dess åtkomst bör hanteras och styras som en logisk tilldelningsenhet – en resursgrupp. I det scenariot kan Microsoft Entra-säkerhetsgrupper skapas och associeras med rätt behörigheter och rolltilldelning för alla lösningsresurser, så att lägga till eller ta bort användare från dessa grupper resulterar i att tillåta eller neka åtkomst till hela lösningen.

Vi rekommenderar att du använder gruppbaserad licensiering och säkerhetsgrupper för Microsoft usluge som förlitar sig på att en användare har en licensplatstilldelning som en förutsättning innan du ger åtkomst (till exempel Dynamics 365, Power BI).

Microsoft Entra-molnbaserade grupper kan styras internt från molnet när de kombineras med Microsoft Entra-åtkomstgranskningar och Microsoft Entra-berättigandehantering.

Microsoft Entra-ID stöder också direkt användartilldelning till SaaS-tjänster från tredje part (till exempel Salesforce, Service Now) och lokala program för enkel inloggning och identitetsetablering. Direkttilldelningar till resurser kan styras internt från molnet när de kombineras med Microsoft Entra-åtkomstgranskningar och Microsoft Entra-berättigandehantering. Direkttilldelning kan passa bra för slutanvändartilldelning.

Vissa scenarier kan kräva att du beviljar åtkomst till lokala resurser via lokalni Active Directory säkerhetsgrupper. I dessa fall bör du överväga synkroniseringscykeln till Microsoft Entra-ID när du utformar process-SLA.

Autentiseringshantering

I det här avsnittet beskrivs vilka kontroller som ska utföras och vilka åtgärder som ska utföras för hantering av autentiseringsuppgifter och åtkomstprinciper baserat på organisationens säkerhetsstatus.

Hantering av autentiseringsuppgifter

Starka autentiseringsuppgifter

Alla mänskliga identiteter (lokala konton och externa identiteter som etablerats via B2B-samarbete) i den isolerade miljön måste etableras med starka autentiseringsuppgifter, till exempel multifaktorautentisering eller en FIDO-nyckel. Miljöer med en underliggande lokal infrastruktur med stark autentisering, till exempel smartkortautentisering, kan fortsätta att använda smartkortautentisering i molnet.

Lösenordslösa autentiseringsuppgifter

En lösenordslös lösning är den bästa lösningen för att säkerställa den mest praktiska och säkra autentiseringsmetoden. Lösenordslösa autentiseringsuppgifter som FIDO-säkerhetsnycklar och Windows Hello za posao rekommenderas för mänskliga identiteter med privilegierade roller.

Lösenordsskydd

Om miljön synkroniseras från en lokalni Active Directory skog bör du distribuera Microsoft Entra-lösenordsskydd för att eliminera svaga lösenord i din organisation. Microsoft Entra smart lockout bör också användas i hybrid- eller molnbaserade miljöer för att låsa ute dåliga aktörer som försöker gissa användarnas lösenord eller använda råstyrkemetoder för att komma in.

Lösenordshantering via självbetjäning

Användare som behöver ändra eller återställa sina lösenord är en av de största volymkällorna och kostnaden för supportsamtal. Förutom kostnaden är det ett grundläggande steg att ändra lösenordet som ett verktyg för att minska en användarrisk för att förbättra organisationens säkerhetsstatus. Distribuera som minst lösenordshantering med självbetjäning för mänskliga konton och testkonton med lösenord för att avleda supportsamtal.

Lösenord för externa identiteter

Genom att använda Microsoft Entra B2B-samarbete kan externa användare som partner, utvecklare och underleverantörer använda sina egna autentiseringsuppgifter för att få åtkomst till företagets resurser. Detta minskar behovet av att införa fler lösenord i de isolerade klientorganisationer.

Kommentar

Vissa program, infrastruktur eller arbetsflöden kan kräva en lokal autentiseringsuppgift. Utvärdera detta från fall till fall.

Autentiseringsuppgifter för tjänstens huvudnamn

I scenarier där tjänstens huvudnamn behövs använder du certifikatautentiseringsuppgifter för tjänstens huvudnamn eller villkorsstyrd åtkomst för arbetsbelastningsidentiteter. Om det behövs använder du klienthemligheter som ett undantag från organisationens princip.

I båda fallen kan Azure Key Vault användas med Hanterade Azure-identiteter, så att körningsmiljön (till exempel en Azure-funktion) kan hämta autentiseringsuppgifterna från nyckelvalvet.

Kontrollera det här exemplet om du vill skapa tjänstens huvudnamn med självsignerat certifikat för autentisering av tjänstens huvudnamn med certifikatautentiseringsuppgifter.

Åtkomstprinciper

I följande avsnitt finns rekommendationer för Azure-lösningar. Allmän vägledning om principer för villkorsstyrd åtkomst för enskilda miljöer finns i metodtipsen för villkorsstyrd åtkomst, Microsoft Entra Operations Guide och Villkorlig åtkomst för Nulta pouzdanost:

  • Definiera principer för villkorlig åtkomst för Windows Azure Service Management API-molnappen för att framtvinga identitetssäkerhetsstatus vid åtkomst till Azure Resource Manager. Detta bör omfatta kontroller på MFA och enhetsbaserade kontroller för att endast aktivera åtkomst via säkra arbetsstationer (mer om detta i avsnittet Privilegierade roller under Identitetsstyrning). Använd dessutom villkorsstyrd åtkomst för att filtrera efter enheter.

  • Alla program som registreras i isolerade miljöer måste ha explicita principer för villkorsstyrd åtkomst som en del av registreringsprocessen.

  • Definiera principer för villkorsstyrd åtkomst för registrering av säkerhetsinformation som återspeglar en säker rot av förtroendeprocessen lokalt (till exempel för arbetsstationer på fysiska platser, som kan identifieras av IP-adresser, som anställda måste besöka personligen för verifiering).

  • Överväg att använda villkorlig åtkomst för att begränsa arbetsbelastningsidentiteter. Skapa en princip för att begränsa eller bättre kontrollera åtkomst baserat på plats eller andra relevanta omständigheter.

Autentiseringsutmaningar

  • Externa identiteter som etablerats med Microsoft Entra B2B kan behöva återskapa autentiseringsuppgifter för multifaktorautentisering i resursklientorganisationen. Detta kan vara nödvändigt om en åtkomstprincip mellan klientorganisationer inte har konfigurerats med resursklientorganisationen. Det innebär att registrering till systemet är bootstrapped med en enda faktor. Med den här metoden är riskreduceringen att organisationen har en process för att bevisa användaren och riskprofilen för autentiseringsuppgifter innan en B2B-inbjudan utfärdas. Definiera dessutom villkorsstyrd åtkomst till registreringsprocessen enligt beskrivningen tidigare.

  • Använd inställningar för åtkomst mellan klientorganisationer för externa identiteter för att hantera hur de samarbetar med andra Microsoft Entra-organisationer och andra Microsoft Azure-moln via B2B-samarbete och B2B-direktanslutning.

  • För specifik enhetskonfiguration och kontroll kan du använda enhetsfilter i principer för villkorsstyrd åtkomst för att rikta in sig på eller exkludera specifika enheter. På så sätt kan du begränsa åtkomsten till Azure-hanteringsverktyg från en utsedd säker administratörsarbetsstation (SAW). Andra metoder som du kan använda är att använda Azure Virtual Desktop, Azure Bastion eller Cloud PC.

  • Faktureringshanteringsprogram som Azure EA-portalen eller MCA-faktureringskonton representeras inte som molnprogram för villkorlig åtkomst. Som en kompenserande kontroll definierar du separata administrationskonton och riktar principer för villkorsstyrd åtkomst till dessa konton med villkoret "Alla appar".

Identitetshantering

Privilegierade roller

Nedan visas några principer för identitetsstyrning som ska beaktas i alla klientkonfigurationer för isolering.

  • Ingen stående åtkomst – Inga mänskliga identiteter ska ha stående åtkomst för att utföra privilegierade åtgärder i isolerade miljöer. Rollbaserad åtkomstkontroll i Azure (RBAC) integreras med Microsoft Entra Privileged Identity Management (PIM). PIM tillhandahåller just-in-time-aktivering som bestäms av säkerhetsgrindar som multifaktorautentisering, arbetsflöde för godkännande och begränsad varaktighet.

  • Antal administratörer – Organisationer bör definiera lägsta och högsta antal människor som har en privilegierad roll för att minska riskerna för affärskontinuitet. Med för få privilegierade roller kanske det inte finns tillräckligt med tidszonstäckning. Minska säkerhetsriskerna genom att ha så få administratörer som möjligt, enligt principen med lägsta behörighet.

  • Begränsa privilegierad åtkomst – Skapa grupper som endast är molnbaserade och rolltilldelningsbara för hög behörighet eller känsliga privilegier. Detta ger skydd för de tilldelade användarna och gruppobjektet.

  • Minst privilegierad åtkomst – Identiteter bör endast beviljas de behörigheter som krävs för att utföra de privilegierade åtgärderna per roll i organisationen.

    • Med anpassade Azure RBAC-roller kan du utforma minst privilegierade roller baserat på organisationens behov. Vi rekommenderar att definitioner av anpassade roller redigeras eller granskas av specialiserade säkerhetsteam och minskar risken för oavsiktliga överdrivna privilegier. Redigering av anpassade roller kan granskas via Azure Policy.

    • Om du vill undvika oavsiktlig användning av roller som inte är avsedda för bredare användning i organisationen använder du Azure Policy för att explicit definiera vilka rolldefinitioner som kan användas för att tilldela åtkomst. Läs mer från det här GitHub-exemplet.

  • Privilegierad åtkomst från säkra arbetsstationer – All privilegierad åtkomst ska ske från säkra och låsta enheter. Genom att separera dessa känsliga uppgifter och konton från arbetsstationer och enheter som används dagligen skyddar du privilegierade konton från nätfiskeattacker, sårbarheter i program och operativsystem, olika personifieringsattacker och stöld av autentiseringsuppgifter, till exempel loggning av tangenttryckningar, Pass-the-Hash och Pass-The-Ticket.

Vissa metoder som du kan använda för att använda säkra enheter som en del av din berättelse om privilegierad åtkomst är att använda principer för villkorsstyrd åtkomst för att rikta in sig på eller exkludera specifika enheter, använda Azure Virtual Desktop, Azure Bastion eller Cloud PC, eller skapa Azure-hanterade arbetsstationer eller arbetsstationer för privilegierad åtkomst.

  • Skyddsmekanismer för privilegierad rollprocess – Organisationer måste definiera processer och tekniska skyddsräcken för att säkerställa att privilegierade åtgärder kan utföras när det behövs samtidigt som de uppfyller regelkraven. Exempel på skyddsräcken är:

    • Kvalificering av människor med privilegierade roller (till exempel heltidsanställd/leverantör, behörighetsnivå, medborgarskap)

    • Explicit inkompatibilitet för roller (även kallat uppdelning av uppgifter). Exempel är team med Microsoft Entra-katalogroller som inte ska ansvara för att hantera privilegierade Roller i Azure Resource Manager och så vidare.

    • Oavsett om direkta användar- eller grupptilldelningar föredras för vilka roller.

  • Övervakning av IAM-tilldelningar utanför Microsoft Entra PIM automatiseras inte via Azure-principer. Åtgärden är att inte bevilja rollen Prenumerationsägare eller Administratör för användaråtkomst till teknikteam. Skapa i stället grupper som tilldelats minst privilegierade roller, till exempel Deltagare och delegera hanteringen av dessa grupper till ingenjörsteam.

Resursåtkomst

  • Attestering – Identiteter som har privilegierade roller bör granskas regelbundet för att hålla medlemskapet aktuellt och motiverat. Microsoft Entra-åtkomstgranskningar integreras med Azure RBAC-roller, gruppmedlemskap och externa Identiteter för Microsoft Entra B2B.

  • Livscykel – Privilegierade åtgärder kan kräva åtkomst till flera resurser, till exempel verksamhetsprogram, SaaS-program och Azure-resursgrupper och prenumerationer. Med Microsoft Entra Entitlement Management kan du definiera åtkomstpaket som representerar en uppsättning resurser som tilldelas användare som en enhet, upprätta en giltighetsperiod, arbetsflöden för godkännande och så vidare.

Livscykelhantering för klientorganisation och prenumeration

Klientorganisationslivscykel

  • Vi rekommenderar att du implementerar en process för att begära en ny Microsoft Entra-klientorganisation för företag. Processen bör ta hänsyn till:

    • Affärsmotiv för att skapa den. Att skapa en ny Microsoft Entra-klientorganisation ökar komplexiteten avsevärt, så det är viktigt att ta reda på om en ny klientorganisation är nödvändig.

    • Azure-molnet där det ska skapas (till exempel Commercial, Government och så vidare).

    • Oavsett om det är produktion eller inte

    • Krav på katalogdatahemvist

    • Vem som ska hantera det

    • Utbildning och förståelse för vanliga säkerhetskrav.

  • Efter godkännande kommer Microsoft Entra-klientorganisationen att skapas, konfigureras med nödvändiga baslinjekontroller och registreras i faktureringsplanet, övervakning och så vidare.

  • Regelbunden granskning av Microsoft Entra-klienterna i faktureringsplanet måste implementeras för att identifiera och identifiera skapande av klientorganisationer utanför den styrda processen. Mer information finns i avsnittet Inventering och synlighet i det här dokumentet.

  • Skapande av Azure AD B2C-klientorganisationer kan styras med hjälp av Azure Policy. Principen körs när en Azure-prenumeration är associerad med B2C-klientorganisationen (en förutsättning för fakturering). Kunder kan begränsa skapandet av Azure AD B2C-klientorganisationer till specifika hanteringsgrupper.

  • Det finns inga tekniska kontroller för att underordna skapandet av klienter till en organisation. Aktiviteten registreras dock i granskningsloggen. Registreringen till faktureringsplanet är en kompenserande kontroll vid grinden. Detta måste kompletteras med övervakning och aviseringar i stället.

Prenumerationens livscykel

Nedan följer några saker att tänka på när du utformar en reglerad livscykelprocess för prenumerationer:

  • Definiera en taxonomi med program och lösningar som kräver Azure-resurser. Alla team som begär prenumerationer bör ange sin "produktidentifierare" när de begär prenumerationer. Den här informationstaxonomi avgör:

    • Microsoft Entra-klientorganisation för att etablera prenumerationen

    • Azure EA-konto som ska användas för att skapa prenumerationer

    • Namngivningskonvention

    • Tilldelning av hanteringsgrupp

    • Andra aspekter som taggning, korsladdning, användning av produktvyer och så vidare.

  • Tillåt inte att ad hoc-prenumeration skapas via portalerna eller på annat sätt. Överväg i stället att hantera prenumerationer programmatiskt med Hjälp av Azure Resource Manager och hämta förbruknings- och faktureringsrapporter programmatiskt. Detta kan hjälpa till att begränsa prenumerationsetablering till behöriga användare och framtvinga dina policy- och taxonomimål. Vägledning om hur du följer AZOps-huvudkonton kan användas för att skapa en praktisk lösning.

  • När en prenumeration etableras skapar du Microsoft Entra-molngrupper för att lagra de Azure Resource Manager-standardroller som krävs av programteam som Deltagare, Läsare och godkända anpassade roller. På så sätt kan du hantera Rolltilldelningar i Azure RBAC med styrd privilegierad åtkomst i stor skala.

    1. Konfigurera grupperna så att de blir berättigade till Azure RBAC-roller med hjälp av Microsoft Entra PIM med motsvarande kontroller, till exempel aktiveringsprincip, åtkomstgranskningar, godkännare och så vidare.

    2. Delegera sedan hanteringen av grupperna till lösningsägare.

    3. Som skyddsmekanism ska du inte tilldela produktägare till roller som administratör för användaråtkomst eller ägare för att undvika oavsiktlig direkt tilldelning av roller utanför Microsoft Entra PIM, eller eventuellt ändra prenumerationen till en helt annan klientorganisation.

    4. För kunder som väljer att aktivera prenumerationshantering mellan klientorganisationer i icke-produktionsklienter via Azure Lighthouse kontrollerar du att samma åtkomstprinciper från det produktionsprivilegierade kontot (till exempel privilegierad åtkomst endast från skyddade arbetsstationer) tillämpas när du autentiserar för att hantera prenumerationer.

  • Om din organisation har förgodkända referensarkitekturer kan prenumerationsetablering integreras med resursdistributionsverktyg som Azure Blueprints eller Terraform.

  • Med tanke på klienttillhörigheten till Azure-prenumerationer bör prenumerationsetablering vara medveten om flera identiteter för samma mänskliga aktör (anställd, partner, leverantör och så vidare) över flera klientorganisationer och tilldela åtkomst därefter.

EA- och MCA-roller

  • Azure Enterprise-avtalsportalen (Azure EA) integreras inte med Azure RBAC eller villkorlig åtkomst. Lösningen för detta är att använda dedikerade administrationskonton som kan riktas mot principer och ytterligare övervakning.

  • Azure EA Enterprise-portalen tillhandahåller ingen granskningslogg. För att minimera detta bör du överväga en automatiserad styrd process för att etablera prenumerationer med de överväganden som beskrivs ovan och använda dedikerade EA-konton och granska autentiseringsloggarna.

  • Microsoft korisnički ugovor-roller (MCA) integreras inte internt med PIM. Du kan minimera detta genom att använda dedikerade MCA-konton och övervaka användningen av dessa konton.

Azure AD B2C-klienter

  • I en Azure AD B2C-klientorganisation stöder de inbyggda rollerna inte PIM. För att öka säkerheten rekommenderar vi att du använder Microsoft Entra B2B-samarbete för att registrera teknikteamen som hanterar CUSTOMER Identity Access Management (CIAM) från din Azure-klientorganisation, tilldelar dem till Azure AD B2C-privilegierade roller och tillämpar principer för villkorsstyrd åtkomst på dessa dedikerade administrationskonton.

  • Azure AD B2C-klientprivilegerade roller är inte integrerade med Microsoft Entra-åtkomstgranskningar. Åtgärden är att skapa dedikerade konton i organisationens Microsoft Entra-klientorganisation, lägga till dessa konton i en grupp och utföra regelbundna åtkomstgranskningar i den här gruppen.

  • Om du följer riktlinjerna för nödåtkomst för Microsoft Entra-ID ovan bör du överväga att skapa motsvarande konton för nödåtkomst utöver de externa administratörer som beskrivs ovan.

  • Vi rekommenderar att det logiska ägarskapet för den underliggande Microsoft Entra-prenumerationen för B2C-klientorganisationen överensstämmer med CIAM-teknikteamen på samma sätt som resten av Azure-prenumerationerna används för B2C-lösningarna.

Operations

Följande är ytterligare operativa överväganden för Microsoft Entra-ID, som är specifika för flera isolerade miljöer. I Azure Cloud Adoption Framework, Microsoft Cloud Security Benchmark och Microsoft Entra Operations-guiden finns detaljerad vägledning för att hantera enskilda miljöer.

Roller och ansvarsområden mellan miljöer

Företagsomfattande SecOps-arkitektur – Medlemmar i drift- och säkerhetsteam från alla miljöer i organisationen bör gemensamt definiera följande:

  • Principer för att definiera när miljöer behöver skapas, konsolideras eller föråldrades.

  • Principer för att definiera hanteringsgruppshierarki för varje miljö.

  • Faktureringsplan (EA-portalen/MCA) säkerhetsstatus, driftstatus och delegeringsmetod.

  • Processen för att skapa klientorganisationen.

  • Taxonomi för företagsprogram.

  • Etableringsprocess för Azure-prenumerationer.

  • Gränser för isolering och administrationsautonomi och riskbedömning i team och miljöer.

  • Vanliga baslinjekonfigurations- och säkerhetskontroller (tekniska och kompenserande) och operativa baslinjer som ska användas i alla miljöer.

  • Vanliga standardprocedurer och verktyg som omfattar flera miljöer (till exempel övervakning, etablering).

  • Enades om delegering av roller i flera miljöer.

  • Ansvarsfördelning mellan miljöer.

  • Gemensam hantering av leveranskedjan för privilegierade arbetsstationer.

  • Namngivningskonventioner.

  • Korrelationsmekanismer mellan miljöer.

Skapande av klientorganisation – Ett specifikt team bör äga skapandet av klientorganisationen enligt standardiserade procedurer som definieras av SecOps-arkitekturen i hela företaget. Detta omfattar:

  • Underliggande licensetablering (till exempel Microsoft 365).

  • Registrering till företagets faktureringsplan (till exempel Azure EA eller MCA).

  • Skapa En Azure-hanteringsgruppshierarki.

  • Konfiguration av hanteringsprinciper för olika perimeterr, inklusive identitet, dataskydd, Azure och så vidare.

  • Distribution av säkerhetsstacken per överenskommen cybersäkerhetsarkitektur, inklusive diagnostikinställningar, SIEM-registrering, CASB-registrering, PIM-registrering och så vidare.

  • Konfiguration av Microsoft Entra-roller baserat på överenskommen delegering.

  • Konfiguration och distribution av inledande privilegierade arbetsstationer.

  • Etablera konton för nödåtkomst.

  • Konfiguration av identitetsetableringsstack.

Arkitektur för verktyg mellan miljöer – Vissa verktyg som identitetsetablering och källkontrollpipelines kan behöva fungera i flera miljöer. Dessa verktyg bör betraktas som viktiga för infrastrukturen och måste utformas, utformas, implementeras och hanteras som sådana. Därför bör arkitekter från alla miljöer vara involverade när verktyg mellan miljöer behöver definieras.

Inventering och synlighet

Azure-prenumerationsidentifiering – För varje identifierad klientorganisation kan en global Microsoft Entra-administratör höja åtkomsten för att få insyn i alla prenumerationer i miljön. Den här höjningen tilldelar dem den inbyggda rollen Administratör för användaråtkomst i rothanteringsgruppen.

Kommentar

Den här åtgärden är mycket privilegierad och kan ge administratören åtkomst till prenumerationer som innehåller extremt känslig information om dessa data inte har isolerats korrekt.

Aktivera läsåtkomst för att identifiera resurser – Hanteringsgrupper aktiverar RBAC-tilldelning i stor skala över flera prenumerationer. Kunder kan bevilja en läsarroll till ett centraliserat IT-team genom att konfigurera en rolltilldelning i rothanteringsgruppen, som sprids till alla prenumerationer i miljön.

Resursidentifiering – När du har fått resursläsningsåtkomst i miljön kan Azure Resource Graph användas för att fråga efter resurser i miljön.

Loggning och övervakning

Central hantering av säkerhetsloggar – Mata in loggar från varje miljö på ett centraliserat sätt genom att följa konsekventa metodtips i olika miljöer (till exempel diagnostikinställningar, loggkvarhållning, SIEM-inmatning och så vidare). Azure Monitor kan användas för att mata in loggar från olika källor, till exempel slutpunktsenheter, nätverk, operativsystems säkerhetsloggar och så vidare.

Detaljerad information om hur du använder automatiserade eller manuella processer och verktyg för att övervaka loggar som en del av dina säkerhetsåtgärder finns i säkerhetsåtgärdsguiden för Microsoft Entra.

Vissa miljöer kan ha regelkrav som begränsar vilka data (om några) som kan lämna en viss miljö. Om centraliserad övervakning mellan miljöer inte är möjlig bör teamen ha operativa procedurer för att korrelera identitetsaktiviteter mellan miljöer för gransknings- och kriminaltekniska ändamål, till exempel laterala förflyttningsförsök mellan miljöer. Vi rekommenderar att de unika objektidentifierarna identifierar mänskliga identiteter som tillhör samma person kan identifieras, eventuellt som en del av identitetsetableringssystemen.

Loggstrategin måste innehålla följande Microsoft Entra-loggar för varje klientorganisation som används i organisationen:

  • Inloggningsaktivitet

  • Granskningsloggar

  • Riskhändelser

Microsoft Entra ID tillhandahåller Azure Monitor-integrering för inloggningsaktivitetsloggen och granskningsloggarna. Riskhändelser kan matas in via Microsoft Graph API.

Följande diagram visar de olika datakällor som måste införlivas som en del av övervakningsstrategin:

Azure AD B2C-klienter kan integreras med Azure Monitor. Vi rekommenderar övervakning av Azure AD B2C med samma kriterier som beskrivs ovan för Microsoft Entra-ID.

Prenumerationer som har aktiverat hantering mellan klientorganisationer med Azure Lighthouse kan aktivera övervakning mellan klientorganisationer om loggarna samlas in av Azure Monitor. Motsvarande Log Analytics-arbetsytor kan finnas i resursklientorganisationen och kan analyseras centralt i hanteringsklientorganisationen med hjälp av Azure Monitor-arbetsböcker. Mer information finns i Övervaka delegerade resurser i stor skala – Azure Lighthouse.

Säkerhetsloggar för operativsystemets hybridinfrastruktur

Alla operativsystemsloggar för hybrididentitetsinfrastruktur bör arkiveras och övervakas noggrant som ett nivå 0-system, med tanke på konsekvenserna för ytan. Detta omfattar:

  • AD FS-servrar och webbprogramproxy

  • Microsoft Entra Connect

  • Programproxyagenter

  • Tillbakaskrivningsagenter för lösenord

  • Gatewaydatorer för lösenordsskydd

  • NPS som har RADIUS-tillägget för Microsoft Entra-multifaktorautentisering

Microsoft Entra Connect Health måste distribueras för att övervaka identitetssynkronisering och federation (om tillämpligt) för alla miljöer.

Kvarhållning av logglagring – Alla miljöer bör ha en sammanhängande strategi för kvarhållning av logglagring, design och implementering för att underlätta en konsekvent verktygsuppsättning (till exempel SIEM-system som Azure Sentinel), vanliga frågor, undersöknings- och kriminaltekniska spelböcker. Azure Policy kan användas för att konfigurera diagnostikinställningar.

Övervakning och loggkontroll – De operativa uppgifterna kring identitetsövervakning bör vara konsekventa och ha ägare i varje miljö. Som beskrivs ovan ska du sträva efter att konsolidera dessa ansvarsområden mellan miljöer i den utsträckning som tillåts av regelefterlevnad och isoleringskrav.

Följande scenarier måste övervakas och undersökas explicit:

  • Misstänkt aktivitet – Alla Microsoft Entra-riskhändelser bör övervakas för misstänkt aktivitet. Alla klienter bör definiera nätverket med namnet platser för att undvika brusidentifieringar på platsbaserade signaler. Microsoft Entra ID Protection är inbyggt integrerat med Azure Security Center. Vi rekommenderar att alla undersökningar av riskidentifiering omfattar alla miljöer som identiteten etableras (till exempel om en mänsklig identitet har en aktiv riskidentifiering i företagsklientorganisationen bör teamet som driver den kundinriktade klientorganisationen även undersöka aktiviteten för motsvarande konto i den miljön).

  • UEBA-aviseringar (User Entity Behavioral Analytics) – UEBA bör användas för att få insiktsfull information baserat på avvikelseidentifiering. Microsoft Microsoft 365 Defender för Cloud Apps tillhandahåller UEBA i molnet. Kunder kan integrera lokala UEBA från Microsoft Microsoft 365 Defender for Identity. MCAS läser signaler från Microsoft Entra ID Protection.

  • Aktivitet för konton för nödåtkomst – All åtkomst med hjälp av konton för nödåtkomst bör övervakas och aviseringar skapas för undersökningar. Den här övervakningen måste innehålla:

    • Inloggningar

    • Hantering av autentiseringsuppgifter

    • Eventuella uppdateringar av gruppmedlemskap

    • Programtilldelningar

  • Faktureringshanteringskonton – Med tanke på känsligheten för konton med faktureringshanteringsroller i Azure EA eller MCA och deras betydande behörighet rekommenderar vi att du övervakar och aviserar:

    • Inloggningsförsök av konton med faktureringsroller.

    • Alla försök att autentisera till andra program än EA-portalen.

    • Alla försök att autentisera till andra program än Azure Resource Management om du använder dedikerade konton för MCA-faktureringsuppgifter.

    • Tilldelning till Azure-resurser med dedikerade konton för MCA-faktureringsuppgifter.

  • Privilegierad rollaktivitet – Konfigurera och granska säkerhetsaviseringar som genereras av Microsoft Entra PIM. Om låsning av direkta RBAC-tilldelningar inte kan tillämpas fullt ut med tekniska kontroller (till exempel att rollen Ägare måste beviljas produktteam för att utföra sitt jobb) övervakar du direkt tilldelning av privilegierade roller utanför PIM genom att generera aviseringar när en användare tilldelas direkt åtkomst till prenumerationen med Azure RBAC.

  • Klassiska rolltilldelningar – Organisationer bör använda den moderna Azure RBAC-rollinfrastrukturen i stället för de klassiska rollerna. Därför bör följande händelser övervakas:

    • Tilldelning till klassiska roller på prenumerationsnivå

  • Konfigurationer för hela klientorganisationen – Alla konfigurationstjänster för hela klientorganisationen bör generera aviseringar i systemet.

    • Uppdatera anpassade domäner

    • Uppdatera varumärkesanpassning

    • Microsoft Entra B2B-lista över tillåtna/blockera

    • Microsoft Entra B2B tillåtna identitetsprovidrar (SAML-ID:er via direkt federation eller sociala inloggningar)

    • Ändringar av principer för villkorsstyrd åtkomst

  • Objekt för program och tjänstens huvudnamn

    • Nya program/tjänstens huvudnamn som kan kräva principer för villkorsstyrd åtkomst

    • Programmedgivandeaktivitet

  • Hanteringsgruppsaktivitet – Följande identitetsaspekter av hanteringsgrupper bör övervakas:

    • RBAC-rolltilldelningar på MG

    • Azure-principer som tillämpas på MG

    • Prenumerationer som flyttats mellan MG:er

    • Ändringar av säkerhetsprinciper i rot-MG

  • Anpassade roller

    • Uppdateringar av definitionerna för anpassade roller

    • Nya anpassade roller har skapats

  • Anpassade regler för uppdelning av uppgifter – Om dina organisationer har fastställt regler för uppdelning av uppgifter använder du Inkompatibla åtkomstpaket för Microsoft Entra-berättigandehantering för att framtvinga uppdelning av uppgifter och skapa aviseringar eller konfigurera periodiska granskningar för att upptäcka överträdelser av administratörer.

Andra övervakningsöverväganden – Azure-prenumerationer som innehåller resurser som används för Log Management bör betraktas som kritisk infrastruktur (nivå 0) och låsas till säkerhetsåtgärdsteamet i motsvarande miljö. Överväg att använda verktyg som Azure Policy för att framtvinga ytterligare kontroller för dessa prenumerationer.

Driftverktyg

Designöverväganden för verktyg mellan miljöer :

  • När det är möjligt bör operativa verktyg som används i flera klientorganisationer utformas för att köras som ett Microsoft Entra-program för flera klientorganisationer för att undvika omdistribution av flera instanser på varje klientorganisation och undvika driftineffektivitet. Implementeringen bör innehålla auktoriseringslogik i för att säkerställa att isoleringen mellan användare och data bevaras.

  • Lägg till aviseringar och identifieringar för att övervaka automatisering mellan miljöer (till exempel identitetsetablering) och tröskelvärden för felsäkerhet. Du kanske till exempel vill ha en avisering om avetablering av användarkonton når en viss nivå, eftersom det kan tyda på ett fel eller driftfel som kan ha stor inverkan.

  • All automatisering som samordnar uppgifter mellan miljöer bör användas som högprivilegierat system. Det här systemet bör vara hem för den högsta säkerhetsmiljön och hämta från externa källor om data från andra miljöer krävs. Dataverifiering och tröskelvärden måste tillämpas för att upprätthålla systemintegriteten. En vanlig uppgift mellan miljöer är identitetslivscykelhantering för att ta bort identiteter från alla miljöer för en avslutad medarbetare.

IT-tjänsthanteringsverktyg – Organisationer som använder ITSM-system (IT Service Management), till exempel ServiceNow, bör konfigurera microsoft Entra PIM-rollaktiveringsinställningar för att begära ett biljettnummer som en del av aktiveringssyftena.

På samma sätt kan Azure Monitor integreras med ITSM-system via IT Service Management Connector.

Operativa metoder – Minimera operativa aktiviteter som kräver direkt åtkomst till miljön till mänskliga identiteter. Modellera dem i stället som Azure Pipelines som kör vanliga åtgärder (till exempel lägga till kapacitet i en PaaS-lösning, köra diagnostik och så vidare) och modellera direkt åtkomst till Azure Resource Manager-gränssnitten till scenarier med "break glass".

Driftutmaningar

  • Aktiviteten för övervakning av tjänstens huvudnamn är begränsad för vissa scenarier

  • Microsoft Entra PIM-aviseringar har inget API. Åtgärden är att ha en regelbunden granskning av dessa PIM-aviseringar.

  • Azure EA-portalen tillhandahåller inte övervakningsfunktioner. Åtgärden är att ha dedikerade administrationskonton och övervaka kontoaktiviteten.

  • MCA tillhandahåller inte granskningsloggar för faktureringsuppgifter. Åtgärden är att ha dedikerade administrationskonton och övervaka kontoaktiviteten.

  • Vissa tjänster i Azure som behövs för att driva miljön måste distribueras om och konfigureras om mellan miljöer eftersom de inte kan vara flera klientorganisationer eller flera moln.

  • Det finns ingen fullständig API-täckning i Microsoft Online Services för att helt uppnå infrastruktur som kod. Åtgärden är att använda API:er så mycket som möjligt och använda portaler för resten. Det här initiativet med öppen källkod hjälper dig att fastställa en metod som kan fungera för din miljö.

  • Det finns ingen programmatisk funktion för att identifiera resursklientorganisationer som har delegerad prenumerationsåtkomst till identiteter i en hanterande klientorganisation. Om en e-postadress till exempel har aktiverat en säkerhetsgrupp i den contoso.com klientorganisationen för att hantera prenumerationer i den fabrikam.com klientorganisationen, har administratörer i contoso.com inte något API för att upptäcka att den här delegeringen ägde rum.

  • Specifik övervakning av kontoaktivitet (till exempel break-glass-konto, faktureringshanteringskonto) tillhandahålls inte direkt. Åtgärden är till för att kunder ska kunna skapa egna aviseringsregler.

  • Konfigurationsövervakning för hela klientorganisationen tillhandahålls inte direkt. Åtgärden är till för att kunder ska kunna skapa egna aviseringsregler.

Nästa steg