Skydda din Azure-miljö
Nu när du förstår hur du kontrollerar dina miljöer och skyddar dina distributionspipelines kan du inaktivera mänsklig åtkomst till dina kontrollerade miljöer. I den här lektionen får du lära dig hur du strukturerar användarnas behörigheter till Azure-miljöer. Inklusive hur du tillåter åtkomst i nödsituationer och hur du granskar eventuella ändringar som sker i din Azure-egendom.
Blockera mänsklig åtkomst
Genom att blockera mänsklig åtkomst till dina kontrollerade miljöer ser du till att oavsiktliga eller skadliga ändringar inte kan kringgå teamets gransknings- och automatiserade distributionsprocesser. Om du inte blockerar mänsklig åtkomst kan någon oavsiktligt kringgå de kontroller som du har ägnat så mycket tid åt att planera och implementera i hela lagringsplatsen och pipelines.
Utan att blockera kontroller är det också lätt för någon att oavsiktligt bryta något. Anta till exempel att en användare har två kopior av Azure Portal öppna. Den ena är för en testmiljö och den andra är för produktionsmiljön. När användaren växlar fram och tillbaka mellan webbläsarflikar är det enkelt för dem att oavsiktligt göra ändringar i en produktionsmiljö som var avsedd för en testmiljö.
Om du vill blockera mänsklig åtkomst kan du använda rollbaserad åtkomstkontroll i Azure (RBAC). I RBAC skapar du rolltilldelningar för att definiera:
- Vilka användare, grupper eller tjänstens huvudnamn kan komma åt en definierad uppsättning Azure-resurser (omfånget).
- Vad dessa användare, grupper eller tjänstens huvudnamn kan göra när de kommer åt resurserna ( rollen).
Azure RBAC innehåller många inbyggda rolltyper, bland annat:
- Läsare, som har skrivskyddad åtkomst till miljön.
- Deltagare, som kan ändra resurser.
- Ägare, som kan ändra resurser och bevilja åtkomst till andra.
Det är viktigt att bevilja åtkomst i ett lämpligt omfång. Om din organisation följer den rekommenderade metoden att använda dedikerade Azure-prenumerationer för varje miljö bör du överväga att använda Azure-hanteringsgrupper för att förenkla omfånget för dina rolltilldelningar. Om din organisation använder en enda Azure-prenumeration för alla dina miljöer bör du undvika att ge människor åtkomst till hela prenumerationen, eftersom alla resurser, inklusive dina kontrollerade miljöer, ärver den behörigheten.
Dricks
Rolltilldelningar är Azure Resource Manager-resurser (ARM). Det innebär att du kan konfigurera dina Azure RBAC-rolltilldelningar i kod, till exempel med hjälp av Bicep.
När du planerar dina rolltilldelningar måste du bestämma vad som passar din organisation. Anta till exempel att din organisation skapar separata prenumerationer för var och en av dina miljöer. Du kan välja att ge administratörer och utvecklare Läsare åtkomst till dina kontrollerade miljöer. Med den rollen kan de komma åt produktionsmiljön inom Azure Portal för att granska konfigurationen av dina resurser, visa mått och loggar och undersöka problem eller buggar utan att göra några ändringar i miljön.
Så här kan du konfigurera dina rolltilldelningar för ditt leksaksföretags miljöer för både dina Azure-administratörer och utvecklarna som skriver din kod och dina skript:
| Miljönamn | Kontrollnivå | Administratörsbehörighet | Utvecklarbehörighet |
|---|---|---|---|
| Utveckling | Styrd | Läsare | Läsare |
| Test | Styrd | Läsare | Läsare |
| Mellanlagring | Styrd | Läsare | Läsare |
| Produktion | Styrd | Läsare | Läsare |
| Demo | Okontrollerad | Ägare | Deltagare |
| Prestandatest | Okontrollerad | Ägare | Ingen |
| Intrångstest | Okontrollerad | Ägare | Ingen |
| PR-recensioner | Okontrollerad | Ägare | Ägare |
| Sandbox-miljö för utveckling | Okontrollerad | Ägare | Ägare |
När du planerar dina rolltilldelningar kontrollerar du att du testar dem noggrant. Ibland kan hanteringsåtgärder kräva behörigheter som inte är uppenbara. Ge dina teammedlemmar möjlighet att testa allt sitt dagliga arbete med de behörigheter som du planerar att använda. Granska eventuella problem som de upplever.
Granska dina rolltilldelningar regelbundet. Se till att du inte av misstag har beviljat åtkomst till fel personer eller beviljat åtkomst som är för bred.
Åtkomst till dataplan
Det finns två typer av åtgärder i Azure:
- Kontrollera planåtgärder för att hantera resurserna i din prenumeration.
- Dataplansåtgärder för att få åtkomst till funktioner som en resurs exponerar.
Du skulle till exempel använda en kontrollplansåtgärd för att skapa ett lagringskonto. Du använder en dataplansåtgärd för att ansluta till lagringskontot och komma åt de data som det innehåller.
När du blockerar direkt användaråtkomst till dina Azure-resurser bör du också tänka på hur den här begränsningen gäller för dataplansåtgärder. Distributionsprocessen kan till exempel lagra nyckeln för ett lagringskonto på en plats som en administratör kan komma åt. Administratören kan potentiellt använda nyckeln för att kringgå dina kontroller och komma åt lagringskontots dataplan direkt.
Allt fler Azure-resurser stöder konfiguration av åtkomstkontroll för dataplanet med hjälp av Microsoft Entra-ID. Det här stödet minskar sannolikheten för att du läcker nycklar eller beviljar dataplansåtkomst oavsiktligt. Det är en bra idé att använda Microsoft Entra-ID för dataplansåtkomst var du än kan.
Åtkomst till nödsituationer
Ibland inträffar nödsituationer och någon måste snabbt få åtkomst till en produktionsmiljö för att undersöka eller lösa ett problem. Det är viktigt att planera och repetera hur du vill hantera dessa nödsituationer i god tid innan de inträffar. Du vill inte behöva skynda dig för att svara mitt i ett avbrott.
En metod att tänka på är ett break-glass-konto, som är ett särskilt användarkonto som har högre behörighetsnivåer än användarna normalt har. Det heter ett break-glass-konto eftersom det kräver något ovanligt för att få tillgång till dess autentiseringsuppgifter, ungefär som att bryta glaset på en brandlarmpanel. Du kan tillhandahålla ett säkert sätt för dina operatörer att få åtkomst till autentiseringsuppgifterna för break-glass-kontot. Dessa operatorer kan sedan logga in som konto för att utföra nödändringar.
Sekvensen med steg för att använda ett break-glass-konto är:
- Användaren försöker utföra en nödändring med hjälp av sitt normala konto, men åtgärden blockeras eftersom det normala användarkontot inte har tillräcklig behörighet.
- Användaren kommer åt autentiseringsuppgifterna för break-glass-kontot och loggar in som den användaren.
- Användaren (som fungerar som ett break-glass-konto) får utföra åtgärden.
Användningen av break-glass konton kräver en hög nivå av disciplin. Deras användning bör reserveras för verkliga nödsituationer. Hantera och skydda sina autentiseringsuppgifter noggrant eftersom kontot är mycket privilegierat. Det är en bra idé att ändra autentiseringsuppgifterna för break-glass-konton ofta för att minimera risken för att de har exponerats eller komprometterats.
Break-glass-konton delas ofta i ett team, så det är svårt att spåra vem som har använt dem och vad dessa användare gjorde. Ett annat sätt att använda break-glass-konton är att använda funktionen Microsoft Entra Privileged Identity Management (PIM). Det gör att en användares eget konto tillfälligt kan beviljas en högre behörighetsnivå.
Sekvensen med steg för att använda PIM är:
Användaren försöker utföra en nödsituationsändring med hjälp av sitt normala konto, men åtgärden blockeras eftersom det normala användarkontot inte har tillräcklig behörighet.
Användaren kontaktar PIM och begär en tillfällig behörighetshöjning.
PIM kan utföra ytterligare validering av användarens identitet eller be om godkännande från någon, beroende på hur den har konfigurerats för organisationen.
Om begäran är auktoriserad uppdaterar PIM tillfälligt användarens behörigheter.
Användaren kan utföra åtgärden.
När den definierade tidsperioden har förflutit återkallar PIM de utökade behörigheter som användaren har beviljats.
Både PIM och Azure skriver omfattande granskningsloggar som hjälper dig att förstå vem som har begärt utökade behörigheter och varför. Loggarna spårar också vad de gjorde i din miljö när behörigheterna beviljades.
Kommentar
PIM kräver en premiumlicens för Microsoft Entra-ID.
När nödsituationen är slut
När en nödsituation är slut är det viktigt att ha en process för att återgå till normal drift. Du bör följa den här processen innan för lång tid har förflutit, eller så riskerar du att glömma viktig information eller lämna konfigurationer i ett icke-säkerhetstillstånd.
Granska noggrant Azure- och PIM-granskningsloggarna för att förstå de ändringar som utfördes i dina kontrollerade miljöer, särskilt din produktionsmiljö.
Viktigt!
Någon som använder PIM eller ett break-glass-konto kan ha möjlighet att ge sitt vanliga användarkonto bredare åtkomst än det borde ha gjort. De kan också använda de tillfälliga behörigheterna för att få åtkomst till dataplansnycklar som de kan fortsätta att använda när deras behörigheter har återkallats.
Granska noggrant all användning av dina break-glass-konton eller PIM. Återkalla eller rotera nycklar som kan ha exponerats under nödsituationen.
Strax efter nödsituationen synkroniserar du om dina infrastruktur-som-kod-tillgångar med eventuella ändringar som gjordes under nödsituationen. Anta till exempel att en administratör som en del av lösningen på ett brådskande problem ökade SKU:n för en Azure App Service-plan manuellt. Uppdatera distributionsmallarna så att de innehåller den nya SKU:n i resurskonfigurationen. I annat fall kan SKU:n återställas till det tidigare värdet under nästa vanliga distribution från din pipeline och orsaka ett nytt avbrott.
Granska ändringar i Din Azure-miljö
Det är också en bra idé att konfigurera granskning och loggning i hela Azure-miljön och att övervaka specifika händelser eller hot.
Överväg att använda ett SIEM-verktyg (säkerhetsinformation och händelsehantering), till exempel Microsoft Sentinel. Du kan använda det här verktyget för att samla in och analysera loggar från din Azure-egendom, och även från Azure DevOps, GitHub och andra system. Du kan använda Sentinel för att övervaka oväntade eller obehöriga ändringar av dina Azure-resurser. Du kan också importera pipelinens granskningsloggar och utlösa aviseringar när händelser inträffar, till exempel när en administratör ändrar en grenskyddsprincip på lagringsplatsen.