Dela via


Metodtips för batchsäkerhet och efterlevnad

Den här artikeln innehåller vägledning och metodtips för att förbättra säkerheten när du använder Azure Batch.

Som standard har Azure Batch-konton en offentlig slutpunkt och är offentligt tillgängliga. När en Azure Batch-pool skapas etableras poolen i ett angivet undernät i ett virtuellt Azure-nätverk. Virtuella datorer i Batch-poolen nås som standard via offentliga IP-adresser som Batch skapar. Beräkningsnoder i en pool kan kommunicera med varandra när det behövs, till exempel för att köra uppgifter med flera instanser, men noder i en pool kan inte kommunicera med virtuella datorer utanför poolen.

Diagram som visar en typisk Batch-miljö.

Många funktioner är tillgängliga för att hjälpa dig att skapa en säkrare Azure Batch-distribution. Du kan begränsa åtkomsten till noder och minska nodernas identifiering från Internet genom att etablera poolen utan offentliga IP-adresser. Beräkningsnoderna kan kommunicera säkert med andra virtuella datorer eller med ett lokalt nätverk genom att etablera poolen i ett undernät i ett virtuellt Azure-nätverk. Och du kan aktivera privat åtkomst från virtuella nätverk från en tjänst som drivs av Azure Private Link.

Diagram som visar en säkrare Batch-miljö.

Poolkonfiguration

Pooler kan konfigureras i något av två nodkommunikationslägen, klassiskt eller förenklat. I den klassiska nodkommunikationsmodellen initierar Batch-tjänsten kommunikation till beräkningsnoderna, och beräkningsnoder kräver även kommunikation till Azure Storage. I den förenklade nodkommunikationsmodellen initierar beräkningsnoder kommunikation med Batch-tjänsten. På grund av det begränsade omfånget för inkommande/utgående anslutningar som krävs och inte kräver utgående åtkomst i Azure Storage för baslinjeåtgärd, rekommenderar vi att du använder den förenklade nodkommunikationsmodellen. Den klassiska nodkommunikationsmodellen dras tillbaka den 31 mars 2026.

Batch-kontoautentisering

Batch-kontoåtkomst stöder två autentiseringsmetoder: Delad nyckel och Microsoft Entra-ID.

Vi rekommenderar starkt att du använder Microsoft Entra-ID för Batch-kontoautentisering. Vissa Batch-funktioner kräver den här autentiseringsmetoden, inklusive många av de säkerhetsrelaterade funktioner som beskrivs här. Autentiseringsmekanismen för tjänst-API:et för ett Batch-konto kan begränsas till endast Microsoft Entra-ID med egenskapen allowedAuthenticationModes . När den här egenskapen har angetts avvisas API-anrop med autentisering med delad nyckel.

Allokeringsläge för Batch-kontopool

När du skapar ett Batch-konto kan du välja mellan två poolallokeringslägen:

  • Batch-tjänst: Standardalternativet, där de underliggande vm-skalningsuppsättningsresurserna som används för att allokera och hantera poolnoder skapas i Batch-ägda prenumerationer och visas inte direkt i Azure-portalen. Endast Batch-poolerna och noderna är synliga.
  • Användarprenumeration: De underliggande vm-skalningsuppsättningsresurserna skapas i samma prenumeration som Batch-kontot. Dessa resurser visas därför i prenumerationen, utöver motsvarande Batch-resurser.

Med användarprenumerationsläget skapas virtuella Batch-datorer och andra resurser direkt i din prenumeration när en pool skapas. Användarprenumerationsläge krävs om du vill skapa Batch-pooler med Azure Reserved VM Instances, använda Azure Policy på vm-skalningsuppsättningsresurser och/eller hantera kärnkvoten för prenumerationen (delas mellan alla Batch-konton i prenumerationen). Du måste registrera din prenumeration med Azure Batch och koppla kontot till ett Azure Key Vault för att kunna skapa ett Batch-konto i läget Användarprenumeration.

Begränsa åtkomst till nätverksslutpunkter

Slutpunkter för Batch-nätverk

Som standard används slutpunkter med offentliga IP-adresser för att kommunicera med Batch-konton, Batch-pooler och poolnoder.

Batch-konto-API

När ett Batch-konto skapas skapas en offentlig slutpunkt som används för att anropa de flesta åtgärder för kontot med hjälp av ett REST-API. Kontoslutpunkten har en bas-URL med formatet https://{account-name}.{region-id}.batch.azure.com. Åtkomst till Batch-kontot skyddas med kommunikation till kontoslutpunkten som krypteras med HTTPS och varje begäran autentiseras med antingen delad nyckel eller Microsoft Entra-autentisering.

Azure Resource Manager

Förutom åtgärder som är specifika för ett Batch-konto gäller hanteringsåtgärder för enskilda och flera Batch-konton. Dessa hanteringsåtgärder nås via Azure Resource Manager.

Batchhanteringsåtgärder via Azure Resource Manager krypteras med HTTPS och varje begäran autentiseras med Microsoft Entra-autentisering.

Beräkningsnoder för batchpool

Batch-tjänsten kommunicerar med en Batch-nodagent som körs på varje nod i poolen. Tjänsten instruerar till exempel nodagenten att köra en uppgift, stoppa en uppgift eller hämta filerna för en aktivitet. Kommunikation med nodagenten aktiveras av en eller flera lastbalanserare, vars antal beror på antalet noder i en pool. Lastbalanseraren vidarebefordrar kommunikationen till önskad nod, där varje nod hanteras av ett unikt portnummer. Lastbalanserare har som standard offentliga IP-adresser kopplade till sig. Du kan också fjärransluta poolnoder via RDP eller SSH (den här åtkomsten är aktiverad som standard med kommunikation via lastbalanserare).

Batch compute node OS

Batch stöder både Linux- och Windows-operativsystem. Batch stöder Linux med en justerad nodagent för en delmängd av Linux OS-distributioner. Vi rekommenderar att operativsystemet hålls uppdaterat med de senaste korrigeringarna som tillhandahålls av OS-utgivaren.

Vi rekommenderar att du aktiverar automatisk os-uppgradering för Batch-pooler, vilket gör att den underliggande Azure-infrastrukturen kan samordna uppdateringar över hela poolen. Det här alternativet kan konfigureras så att det inte indisrupteras för aktivitetskörning. Automatisk operativsystemuppgradering stöder inte alla operativsystem som Batch stöder. Mer information finns i stödmatrisen för automatisk os-uppgradering av vm-skalningsuppsättningar. För Windows-operativsystem kontrollerar du att du inte aktiverar egenskapen virtualMachineConfiguration.windowsConfiguration.enableAutomaticUpdates när du använder automatisk operativsystemuppgradering i Batch-poolen.

Batchstöd för avbildningar och nodagenter fasas ut över tid, vanligtvis i linje med tidslinjer för utgivarens support. Vi rekommenderar att du undviker att använda bilder med förestående EOL-datum (end-of-life) eller bilder som har passerat EOL-datumet. Det är ditt ansvar att regelbundet uppdatera din vy över EOL-datumen som är relevanta för dina pooler och migrera dina arbetsbelastningar innan EOL-datumet inträffar. Om du använder en anpassad avbildning med en angiven nodagent kontrollerar du att du följer Batch-supportens slutdatum för den avbildning som den anpassade avbildningen härleds till eller justeras för. En bild utan ett angivet batchSupportEndOfLife datum anger att ett sådant datum ännu inte har fastställts av Batch-tjänsten. Frånvaro av ett datum anger inte att respektive bild kommer att stödjas på obestämd tid. Ett EOL-datum kan läggas till eller uppdateras i framtiden när som helst. EOL-datum kan identifieras via API:etListSupportedImages, PowerShell eller Azure CLI.

Windows OS Transport Layer Security (TLS)

Batch-nodagenten ändrar inte standardvärden på operativsystemnivå för SSL/TLS-versioner eller chiffersvitordning. I Windows styrs SSL/TLS-versioner och chiffersvitordning på operativsystemnivå, och därför antar Batch-nodagenten de inställningar som anges av avbildningen som används av varje beräkningsnod. Även om Batch-nodagenten försöker använda de säkraste inställningarna som är tillgängliga när det är möjligt kan den fortfarande begränsas av inställningar på operativsystemnivå. Vi rekommenderar att du granskar standardinställningarna på operativsystemnivån och ställer in dem på rätt sätt för det säkraste läge som kan användas för arbetsflödet och organisationens krav. Mer information finns i Hantera TLS för tillämpning av chifferpaket och TLS-registerinställningar för SSL/TLS-versionskontroll för Schannel SSP. Observera att vissa inställningsändringar kräver en omstart för att börja gälla. Användning av ett nyare operativsystem med moderna säkerhetsstandarder eller en anpassad avbildning med ändrade inställningar rekommenderas i stället för att använda sådana inställningar med en Batch-startaktivitet.

Begränsa åtkomsten till Batch-slutpunkter

Det finns flera funktioner för att begränsa åtkomsten till de olika Batch-slutpunkterna, särskilt när lösningen använder ett virtuellt nätverk.

Använda privata slutpunkter

Azure Private Link ger åtkomst till Azure PaaS Services och Azure-värdbaserade kundägda/partnertjänster via en privat slutpunkt i ditt virtuella nätverk. Du kan använda Private Link för att begränsa åtkomsten till ett Batch-konto från det virtuella nätverket eller från ett peer-kopplat virtuellt nätverk. Resurser som mappas till Private Link är också tillgängliga lokalt via privat peering via VPN eller Azure ExpressRoute.

Om du vill använda privata slutpunkter måste ett Batch-konto konfigureras på rätt sätt när det skapas. konfigurationen för offentlig nätverksåtkomst måste vara inaktiverad. När de har skapats kan privata slutpunkter skapas och associeras med Batch-kontot. Mer information finns i Använda privata slutpunkter med Azure Batch-konton.

Skapa pooler i virtuella nätverk

Beräkningsnoder i en Batch-pool kan kommunicera med varandra, till exempel för att köra uppgifter med flera instanser, utan att kräva ett virtuellt nätverk (VNET). Noder i en pool kan dock som standard inte kommunicera med virtuella datorer som ligger utanför poolen i ett virtuellt nätverk och som har privata IP-adresser, till exempel licensservrar eller filservrar.

Om du vill tillåta att beräkningsnoder kommunicerar säkert med andra virtuella datorer, eller med ett lokalt nätverk, kan du konfigurera en pool så att den finns i ett undernät i ett virtuellt Azure-nätverk.

När poolerna har offentliga IP-slutpunkter måste undernätet tillåta inkommande kommunikation från Batch-tjänsten för att kunna schemalägga uppgifter och utföra andra åtgärder på beräkningsnoderna och utgående kommunikation för att kommunicera med Azure Storage eller andra resurser efter behov av din arbetsbelastning. För pooler i konfigurationen för virtuell dator lägger Batch till nätverkssäkerhetsgrupper (NSG:er) på den nätverksgränssnittsnivå som är kopplad till beräkningsnoder. Dessa NSG:er har regler för att aktivera:

  • Inkommande TCP-trafik från Batch-tjänstens IP-adresser
  • Inkommande TCP-trafik för fjärråtkomst
  • Utgående trafik på valfri port till det virtuella nätverket (kan ändras enligt NSG-regler på undernätsnivå)
  • Utgående trafik på valfri port till Internet (kan ändras enligt NSG-regler på undernätsnivå)

Du behöver inte ange NSG:er på undernätsnivå för virtuella nätverk eftersom Batch konfigurerar sina egna NSG:er. Om du har en NSG som är associerad med det undernät där Batch-beräkningsnoder distribueras, eller om du vill tillämpa anpassade NSG-regler för att åsidosätta de tillämpade standardvärdena, måste du konfigurera den här NSG:n med minst de inkommande och utgående säkerhetsreglerna för att tillåta Batch-tjänstkommunikation till poolnoderna och poolnodkommunikationen till Azure Storage.

Mer information finns i Skapa en Azure Batch-pool i ett virtuellt nätverk.

Skapa pooler med statiska offentliga IP-adresser

Som standard är de offentliga IP-adresserna som är associerade med pooler dynamiska. de skapas när en pool skapas och IP-adresser kan läggas till eller tas bort när en pool ändras. När aktivitetsprogram som körs på poolnoder behöver åtkomst till externa tjänster kan åtkomsten till dessa tjänster behöva begränsas till specifika IP-adresser. I det här fallet är det inte hanterbart att ha dynamiska IP-adresser.

Du kan skapa statiska offentliga IP-adressresurser i samma prenumeration som Batch-kontot innan poolen skapas. Du kan sedan ange dessa adresser när du skapar poolen.

Mer information finns i Skapa en Azure Batch-pool med angivna offentliga IP-adresser.

Skapa pooler utan offentliga IP-adresser

Som standard tilldelas alla beräkningsnoder i en konfigurationspool för virtuella Azure Batch-datorer en eller flera offentliga IP-adresser. Dessa slutpunkter används av Batch-tjänsten för att schemalägga uppgifter och för kommunikation med beräkningsnoder, inklusive utgående åtkomst till Internet.

Om du vill begränsa åtkomsten till dessa noder och minska identifieringen av noderna från Internet, kan du etablera poolen utan offentliga IP-adresser.

Mer information finns i Skapa en pool utan offentliga IP-adresser.

Begränsa fjärråtkomst till poolnoder

Som standard tillåter Batch att en nodanvändare med nätverksanslutning ansluter externt till en beräkningsnod i en Batch-pool med hjälp av RDP eller SSH.

Om du vill begränsa fjärråtkomsten till noder använder du någon av följande metoder:

  • Konfigurera PoolEndpointConfiguration för att neka åtkomst. Lämplig nätverkssäkerhetsgrupp (NSG) associeras med poolen.
  • Skapa din pool utan offentliga IP-adresser. Som standard kan dessa pooler inte nås utanför det virtuella nätverket.
  • Associera en NSG med det virtuella nätverket för att neka åtkomst till RDP- eller SSH-portarna.
  • Skapa inga användare på noden. Utan nodanvändare är fjärråtkomst inte möjligt.

Kryptera data

Kryptera data under överföring

All kommunikation till Batch-kontoslutpunkten (eller via Azure Resource Manager) måste använda HTTPS. Du måste använda https:// i de Batch-konto-URL:er som anges i API:er när du ansluter till Batch-tjänsten.

Klienter som kommunicerar med Batch-tjänsten bör konfigureras att använda TLS (Transport Layer Security) 1.2.

Kryptera Batch-data i vila

En del av informationen som anges i Batch-API:er, till exempel kontocertifikat, jobb- och uppgiftsmetadata och aktivitetskommandorader, krypteras automatiskt när den lagras av Batch-tjänsten. Som standard krypteras dessa data med azure batch-plattformshanterade nycklar som är unika för varje Batch-konto.

Du kan också kryptera dessa data med hjälp av kundhanterade nycklar. Azure Key Vault används för att generera och lagra nyckeln, med nyckelidentifieraren registrerad med ditt Batch-konto.

Kryptera beräkningsnoddiskar

Batch-beräkningsnoder har som standard två diskar: en OS-disk och den lokala tillfälliga SSD:en. Filer och kataloger som hanteras av Batch finns på den tillfälliga SSD:n, som är standardplatsen för filer som aktivitetsutdatafiler. Batch-aktivitetsprogram kan använda standardplatsen på SSD eller OS-disken.

För extra säkerhet krypterar du dessa diskar med någon av dessa Azure-diskkrypteringsfunktioner:

Åtkomst till tjänster från beräkningsnoder på ett säkert sätt

Använd poolhanterade identiteter med lämpliga åtkomstbehörigheter som konfigurerats för den användartilldelade hanterade identiteten för att få åtkomst till Azure-tjänster som stöder hanterad identitet, inklusive Azure Key Vault. Om du behöver etablera certifikat på Batch-noder använder du det tillgängliga azure Key Vault VM-tillägget med poolhanterad identitet för att installera och hantera certifikat i batchpoolen. Mer information om hur du distribuerar certifikat från Azure Key Vault med hanterad identitet i Batch-pooler finns i Aktivera automatisk certifikatrotation i en Batch-pool.

Styrning och efterlevnad

Regelefterlevnad

För att hjälpa kunderna att uppfylla sina egna efterlevnadsskyldigheter i reglerade branscher och marknader över hela världen har Azure en stor portfölj med efterlevnadserbjudanden.

Dessa erbjudanden baseras på olika typer av försäkringar, inklusive formella certifieringar, intyg, valideringar, auktoriseringar och utvärderingar som tagits fram av oberoende tredjeparts revisionsföretag, samt avtalsändringar, självutvärderingar och kundvägledningsdokument som tagits fram av Microsoft. Granska den omfattande översikten över efterlevnadserbjudanden för att avgöra vilka som kan vara relevanta för dina Batch-lösningar.

Azure Policy

Azure Policy hjälper till att framtvinga organisationsstandarder och utvärdera efterlevnad i stor skala. Några vanliga användningsområden för Azure Policy är att implementera styrning för resurskonsekvens, regelefterlevnad, säkerhet, kostnad och hantering.

Beroende på poolallokeringsläget och de resurser som en princip ska tillämpas på använder du Azure Policy med Batch på något av följande sätt:

  • Direkt med hjälp av resursen Microsoft.Batch/batchAccounts. En delmängd av egenskaperna för ett Batch-konto kan användas. Din princip kan till exempel innehålla giltiga Batch-kontoregioner, tillåtet poolallokeringsläge och om ett offentligt nätverk är aktiverat för konton.
  • Indirekt med hjälp av resursen Microsoft.Compute/virtualMachineScaleSets. Batch-konton med allokeringsläget för användarprenumerationspoolen kan ha princip inställd på de vm-skalningsuppsättningsresurser som skapas i Batch-kontoprenumerationen. Till exempel tillåtna VM-storlekar och se till att vissa tillägg körs på varje poolnod.

Nästa steg