Service Fabric-program och tjänstsäkerhet
En arkitektur för mikrotjänster kan medföra många fördelar. Att hantera säkerheten för mikrotjänster är dock en utmaning och skiljer sig från att hantera traditionell monolitisk programsäkerhet.
Med en monolit körs programmet vanligtvis på en eller flera servrar i ett nätverk och det är lättare att identifiera de exponerade portarna och API:erna och IP-adressen. Det finns ofta en perimeter eller gräns och en databas att skydda. Om systemet komprometteras på grund av ett säkerhetsintrång eller en attack är det troligt att allt i systemet kommer att vara tillgängligt för angriparen. Med mikrotjänster är systemet mer komplext. Tjänsterna är decentraliserade och distribuerade över många värdar och migreras från värd till värd. Med rätt säkerhet begränsar du de privilegier som en angripare kan få och mängden data som är tillgängliga i en enda attack genom att bryta mot en tjänst. Kommunikationen är inte intern, men sker via ett nätverk och det finns många exponerade portar och interaktioner mellan tjänster. Att veta vad dessa tjänstinteraktioner är och när de sker är avgörande för din programsäkerhet.
Den här artikeln är inte en guide till säkerhet för mikrotjänster, det finns många sådana resurser tillgängliga online, men beskriver hur olika säkerhetsaspekter kan utföras i Service Fabric.
Autentisering och auktorisering
Det är ofta nödvändigt att resurser och API:er som exponeras av en tjänst begränsas till vissa betrodda användare eller klienter. Autentisering är en process för att på ett tillförlitligt sätt fastställa en användares identitet. Auktorisering är den process som gör API:er eller tjänster tillgängliga för vissa autentiserade användare men inte andra.
Autentisering
Det första steget för att fatta förtroendebeslut på API-nivå är autentisering. Autentisering är en process för att på ett tillförlitligt sätt fastställa en användares identitet. I mikrotjänstscenarier hanteras autentisering vanligtvis centralt. Om du använder en API Gateway kan du avlasta autentiseringen till gatewayen. Om du använder den här metoden kontrollerar du att de enskilda tjänsterna inte kan nås direkt (utan API Gateway) om inte ytterligare säkerhet finns för att autentisera meddelanden oavsett om de kommer från gatewayen eller inte.
Om tjänster kan nås direkt kan en autentiseringstjänst som Microsoft Entra-ID eller en dedikerad mikrotjänst för autentisering som fungerar som en säkerhetstokentjänst (STS) användas för att autentisera användare. Förtroendebeslut delas mellan tjänster med säkerhetstoken eller cookies.
För ASP.NET Core är den primära mekanismen för att autentisera användare det ASP.NET Core Identity-medlemskapssystemet. ASP.NET Core Identity lagrar användarinformation (inklusive inloggningsinformation, roller och anspråk) i ett datalager som konfigurerats av utvecklaren. ASP.NET Core Identity stöder tvåfaktorautentisering. Externa autentiseringsleverantörer stöds också, så att användare kan logga in med befintliga autentiseringsprocesser från leverantörer som Microsoft, Google, Facebook eller Twitter.
Auktorisering
Efter autentiseringen måste tjänsterna auktorisera användaråtkomst eller avgöra vad en användare kan göra. Med den här processen kan en tjänst göra API:er tillgängliga för vissa autentiserade användare, men inte för alla. Auktorisering är ortoggonisk och oberoende av autentisering, vilket är processen att fastställa vem en användare är. Autentisering kan skapa en eller flera identiteter för den aktuella användaren.
ASP.NET Core-auktorisering kan göras baserat på användarnas roller eller baserat på anpassad princip, vilket kan omfatta granskning av anspråk eller andra heuristiker.
Begränsa och skydda åtkomst med hjälp av en API-gateway
Molnprogram behöver ofta en klientdelsgateway som enda åtkomstpunkt för ingång för användare, enheter och andra program. En API-gateway finns mellan klienter och tjänster och är startpunkten för alla tjänster som ditt program tillhandahåller. Den fungerar som en omvänd proxy och dirigerar begäranden från klienter till tjänster. Den kan också utföra olika övergripande uppgifter som autentisering och auktorisering, TLS-avslutning och hastighetsbegränsning. Om du inte distribuerar en gateway måste klienter skicka begäranden direkt till klientdelstjänster.
I Service Fabric kan en gateway vara valfri tillståndslös tjänst, till exempel ett ASP.NET Core-program eller en annan tjänst som är utformad för inkommande trafik, till exempel Traefik, Event Hubs, IoT Hub eller Azure API Management.
API Management integreras direkt med Service Fabric, så att du kan publicera API:er med en omfattande uppsättning routningsregler till dina Service Fabric-tjänster i serverdelen. Du kan skydda åtkomsten till serverdelstjänster, förhindra DOS-attacker med hjälp av begränsning eller verifiera API-nycklar, JWT-token, certifikat och andra autentiseringsuppgifter. Mer information finns i Översikt över Service Fabric med Azure API Management.
Hantera programhemligheter
Hemligheter kan vara känslig information, till exempel lagring anslutningssträng, lösenord eller andra värden som inte ska hanteras i oformaterad text. Den här artikeln använder Azure Key Vault för att hantera nycklar och hemligheter. Att använda hemligheter i ett program är dock molnplattformsoberoende för att tillåta att program distribueras till ett kluster som finns var som helst.
Det rekommenderade sättet att hantera tjänstkonfigurationsinställningar är via tjänstkonfigurationspaket. Konfigurationspaket är versionshanterade och uppdaterbara via hanterade löpande uppgraderingar med hälsoverifiering och automatisk återställning. Detta rekommenderas för global konfiguration eftersom det minskar risken för ett globalt tjänststopp. Krypterade hemligheter är inget undantag. Service Fabric har inbyggda funktioner för kryptering och dekryptering av värden i ett konfigurationspaket Inställningar.xml-fil med hjälp av certifikatkryptering.
Följande diagram illustrerar det grundläggande flödet för hemlig hantering i ett Service Fabric-program:
Det finns fyra huvudsteg i det här flödet:
- Hämta ett datachiffreringscertifikat.
- Installera certifikatet i klustret.
- Kryptera hemliga värden när du distribuerar ett program med certifikatet och mata in dem i en tjänsts konfigurationsfil Inställningar.xml.
- Läs krypterade värden från Inställningar.xml genom att dekryptera med samma krypteringscertifikat.
Azure Key Vault används här som en säker lagringsplats för certifikat och som ett sätt att få certifikat installerade på Service Fabric-kluster i Azure. Om du inte distribuerar till Azure behöver du inte använda Key Vault för att hantera hemligheter i Service Fabric-program.
Ett exempel finns i Hantera programhemligheter.
Skydda värdmiljön
Genom att använda Azure Service Fabric kan du skydda program som körs i klustret under olika användarkonton. Service Fabric hjälper också till att skydda de resurser som används av program vid tidpunkten för distributionen under användarkontona, till exempel filer, kataloger och certifikat. Detta gör program som körs, även i en delad värdbaserad miljö, säkrare från varandra.
Programmanifestet deklarerar de säkerhetsobjekt (användare och grupper) som krävs för att köra tjänsterna och säkra resurser. Dessa säkerhetsobjekt refereras till i principer, till exempel kör som-, slutpunktsbindning, paketdelning eller säkerhetsåtkomstprinciper. Principer tillämpas sedan på tjänstresurser i avsnittet ServiceManifestImport i programmanifestet.
När du deklarerar huvudnamn kan du också definiera och skapa användargrupper så att en eller flera användare kan läggas till i varje grupp som ska hanteras tillsammans. Detta är användbart när det finns flera användare för olika startpunkter för tjänsten och de måste ha vissa vanliga behörigheter som är tillgängliga på gruppnivå.
Som standard körs Service Fabric-program under det konto som Fabric.exe-processen körs under. Service Fabric ger också möjlighet att köra program under ett lokalt användarkonto eller lokalt systemkonto, som anges i programmanifestet. Mer information finns i Kör en tjänst som ett lokalt användarkonto eller lokalt systemkonto. Du kan också köra ett tjänststartskript som ett lokalt användar- eller systemkonto.
När du kör Service Fabric i ett fristående Windows-kluster kan du köra en tjänst under Active Directory-domänkonton eller grupphanterade tjänstkonton.
Säkra containrar
Service Fabric tillhandahåller en mekanism för tjänster i en container för att komma åt ett certifikat som är installerat på noderna i ett Windows- eller Linux-kluster (version 5.7 eller senare). Det här PFX-certifikatet kan användas för att autentisera programmet eller tjänsten eller för säker kommunikation med andra tjänster. Mer information finns i Importera ett certifikat till en container.
Dessutom stöder Service Fabric även gMSA (grupphanterade tjänstkonton) för Windows-containrar. Mer information finns i Konfigurera gMSA för Windows-containrar.
Säker tjänstkommunikation
I Service Fabric körs en tjänst någonstans i ett Service Fabric-kluster, vanligtvis distribuerat över flera virtuella datorer. Service Fabric erbjuder flera alternativ för att skydda din tjänstkommunikation.
Du kan aktivera HTTPS-slutpunkter i dina ASP.NET Core- eller Java-webbtjänster .
Du kan upprätta en säker anslutning mellan omvänd proxy och tjänster, vilket möjliggör en säker kanal från slutpunkt till slutpunkt. Anslut till säkra tjänster stöds endast när omvänd proxy har konfigurerats för att lyssna på HTTPS. Information om hur du konfigurerar omvänd proxy finns i Omvänd proxy i Azure Service Fabric. Anslut till en säker tjänst beskriver hur du upprättar en säker anslutning mellan omvänd proxy och tjänster.
Reliable Services-programramverket innehåller några fördefinierade kommunikationsstackar och verktyg som du kan använda för att förbättra säkerheten. Lär dig hur du förbättrar säkerheten när du använder tjänstmoting (i C# eller Java) eller med hjälp av WCF.
Inkludera slutpunktscertifikat i Service Fabric-program
Om du vill konfigurera programmets slutpunktscertifikat inkluderar du certifikatet genom att lägga till ett EndpointCertificate-element tillsammans med användarelementet för huvudkontot i programmanifestet. Som standard är huvudkontot NetworkService. Detta ger hantering av den privata nyckel-ACL:en för programcertifikatet för det angivna huvudkontot.
<ApplicationManifest … >
...
<Principals>
<Users>
<User Name="Service1" AccountType="NetworkService" />
</Users>
</Principals>
<Certificates>
<EndpointCertificate Name="MyCert" X509FindType="FindByThumbprint" X509FindValue="[YourCertThumbprint]"/>
</Certificates>
</ApplicationManifest>
Kryptera programdata i vila
Varje nodtyp i ett Service Fabric-kluster som körs i Azure backas upp av en VM-skalningsuppsättning. Genom att använda en Azure Resource Manager-mall, kan du ansluta datadiskar till skalningsuppsättningen som utgör Service Fabric-klustret. Om dina tjänster sparar data på en ansluten datadisk kan du kryptera dessa datadiskar för att skydda dina programdata.