Service Fabric-toepassings- en servicebeveiliging
Een microservicesarchitectuur kan veel voordelen opleveren. Het beheren van de beveiliging van microservices is echter een uitdaging en verschilt van het beheren van traditionele monolithische toepassingen.
Met een monolith wordt de toepassing doorgaans uitgevoerd op een of meer servers in een netwerk en is het eenvoudiger om de weergegeven poorten en API's en IP-adressen te identificeren. Er is vaak één perimeter of grens en één database die moet worden beveiligd. Als dit systeem wordt aangetast vanwege een beveiligingsschending of -aanval, is het waarschijnlijk dat alles binnen het systeem beschikbaar is voor de aanvaller. Met microservices is het systeem complexer. Services worden gedecentraliseerd en gedistribueerd over veel hosts en worden gemigreerd van host naar host. Met de juiste beveiliging beperkt u de bevoegdheden die een aanvaller kan krijgen en de hoeveelheid gegevens die beschikbaar zijn in één aanval door één service te schenden. Communicatie is niet intern, maar gebeurt via een netwerk en er zijn veel blootgestelde poorten en interacties tussen services. Weten wat deze service-interacties zijn en wanneer ze plaatsvinden, is essentieel voor de beveiliging van uw toepassing.
Dit artikel is geen handleiding voor microservicesbeveiliging, er zijn veel van dergelijke bronnen online beschikbaar, maar beschrijft hoe verschillende aspecten van beveiliging kunnen worden uitgevoerd in Service Fabric.
Verificatie en autorisatie
Het is vaak nodig dat resources en API's die door een service worden weergegeven, worden beperkt tot bepaalde vertrouwde gebruikers of clients. Verificatie is het proces van het betrouwbaar vaststellen van de identiteit van een gebruiker. Autorisatie is het proces dat API's of services beschikbaar maakt voor sommige geverifieerde gebruikers, maar niet voor andere.
Verificatie
De eerste stap bij het nemen van vertrouwensbeslissingen op API-niveau is verificatie. Verificatie is het proces van het betrouwbaar vaststellen van de identiteit van een gebruiker. In microservicescenario's wordt verificatie doorgaans centraal verwerkt. Als u een API-gateway gebruikt, kunt u verificatie naar de gateway offloaden. Als u deze aanpak gebruikt, moet u ervoor zorgen dat de afzonderlijke services niet rechtstreeks kunnen worden bereikt (zonder de API-gateway), tenzij er extra beveiliging is ingesteld om berichten te verifiëren, ongeacht of ze afkomstig zijn van de gateway of niet.
Als services rechtstreeks kunnen worden geopend, kan een verificatieservice zoals Microsoft Entra ID of een speciale verificatiemicroservice die fungeert als een beveiligingstokenservice (STS) worden gebruikt om gebruikers te verifiëren. Vertrouwensbeslissingen worden gedeeld tussen services met beveiligingstokens of cookies.
Voor ASP.NET Core is het primaire mechanisme voor het verifiëren van gebruikers het ASP.NET Core Identity-lidmaatschapssysteem. ASP.NET Core Identity slaat gebruikersgegevens (inclusief aanmeldingsgegevens, rollen en claims) op in een gegevensarchief dat is geconfigureerd door de ontwikkelaar. ASP.NET Core Identity ondersteunt tweeledige verificatie. Externe verificatieproviders worden ook ondersteund, zodat gebruikers zich kunnen aanmelden met bestaande verificatieprocessen van providers zoals Microsoft, Google, Facebook of Twitter.
Autorisatie
Na verificatie moeten services gebruikerstoegang autoriseren of bepalen wat een gebruiker kan doen. Met dit proces kan een service API's beschikbaar maken voor sommige geverifieerde gebruikers, maar niet voor alle. Autorisatie is orthogonaal en onafhankelijk van verificatie, wat het proces is om te bepalen wie een gebruiker is. Verificatie kan een of meer identiteiten maken voor de huidige gebruiker.
ASP.NET Kernautorisatie kan worden uitgevoerd op basis van de rollen van gebruikers of op basis van aangepast beleid, waaronder het inspecteren van claims of andere heuristieken.
Toegang beperken en beveiligen met behulp van een API-gateway
Cloudtoepassingen hebben meestal een gateway in de front-end nodig om een centraal ingangspunt te bieden voor gebruikers, apparaten of andere toepassingen. Een API-gateway bevindt zich tussen clients en services en is het toegangspunt voor alle services die uw toepassing biedt. Het fungeert als een omgekeerde proxy, routeringsaanvragen van clients naar services. Het kan ook verschillende kruislingse taken uitvoeren, zoals verificatie en autorisatie, TLS-beëindiging en snelheidsbeperking. Als u geen gateway implementeert, moeten clients aanvragen rechtstreeks verzenden naar front-endservices.
In Service Fabric kan een gateway elke staatloze service zijn, zoals een ASP.NET Core-toepassing of een andere service die is ontworpen voor inkomend verkeer, zoals Traefik, Event Hubs, IoT Hub of Azure API Management.
API Management kan rechtstreeks worden geïntegreerd met Service Fabric, zodat u API's kunt publiceren met een uitgebreide set routeringsregels voor uw back-endService Fabric-services. U kunt de toegang tot back-endservices beveiligen, DOS-aanvallen voorkomen met behulp van beperking of API-sleutels, JWT-tokens, certificaten en andere referenties verifiëren. Lees het overzicht van Service Fabric met Azure API Management voor meer informatie.
Toepassingsgeheimen beheren
Geheimen kunnen gevoelige informatie zijn, zoals opslag verbindingsreeks s, wachtwoorden of andere waarden die niet mogen worden verwerkt in tekst zonder opmaak. In dit artikel wordt Azure Key Vault gebruikt om sleutels en geheimen te beheren. Het gebruik van geheimen in een toepassing is echter platformneutraal in de cloud, zodat toepassingen overal kunnen worden geïmplementeerd in een cluster dat wordt gehost.
De aanbevolen manier om serviceconfiguratie-instellingen te beheren, is via serviceconfiguratiepakketten. Configuratiepakketten zijn versiebeheer en kunnen worden bijgewerkt via beheerde rolling upgrades met statusvalidatie en automatisch terugdraaien. Dit is de voorkeur aan globale configuratie, omdat het de kans op een wereldwijde servicestoring vermindert. Versleutelde geheimen zijn geen uitzondering. Service Fabric heeft ingebouwde functies voor het versleutelen en ontsleutelen van waarden in een configuratiepakket Instellingen.xml-bestand met behulp van certificaatversleuteling.
In het volgende diagram ziet u de basisstroom voor geheimbeheer in een Service Fabric-toepassing:
Deze stroom bestaat uit vier hoofdstappen:
- Haal een certificaat voor gegevenscodering op.
- Installeer het certificaat in uw cluster.
- Versleutel geheime waarden bij het implementeren van een toepassing met het certificaat en injecteer deze in het Instellingen.xml-configuratiebestand van een service.
- Versleutelde waarden uit Instellingen.xml lezen door te ontsleutelen met hetzelfde coderingscertificaat.
Azure Key Vault wordt hier gebruikt als een veilige opslaglocatie voor certificaten en als een manier om certificaten te installeren op Service Fabric-clusters in Azure. Als u niet implementeert in Azure, hoeft u Key Vault niet te gebruiken om geheimen in Service Fabric-toepassingen te beheren.
Zie Toepassingsgeheimen beheren voor een voorbeeld.
De hostingomgeving beveiligen
Met behulp van Azure Service Fabric kunt u toepassingen beveiligen die worden uitgevoerd in het cluster onder verschillende gebruikersaccounts. Service Fabric helpt ook bij het beveiligen van de resources die worden gebruikt door toepassingen op het moment van implementatie onder de gebruikersaccounts, bijvoorbeeld bestanden, mappen en certificaten. Hierdoor worden actieve toepassingen, zelfs in een gedeelde gehoste omgeving, veiliger van elkaar.
Het toepassingsmanifest declareert de beveiligingsprinciplen (gebruikers en groepen) die nodig zijn om de service(s) en beveiligde resources uit te voeren. Naar deze beveiligingsprinciplen wordt verwezen in beleidsregels, zoals run-as, eindpuntbinding, pakketdeling of beveiligingstoegangsbeleid. Beleidsregels worden vervolgens toegepast op servicebronnen in de sectie ServiceManifestImport van het toepassingsmanifest.
Wanneer u principals declareren, kunt u ook gebruikersgroepen definiëren en maken, zodat een of meer gebruikers aan elke groep kunnen worden toegevoegd om samen te worden beheerd. Dit is handig wanneer er meerdere gebruikers zijn voor verschillende serviceinvoerpunten en ze bepaalde algemene bevoegdheden moeten hebben die beschikbaar zijn op groepsniveau.
Service Fabric-toepassingen worden standaard uitgevoerd onder het account waaronder het Fabric.exe-proces wordt uitgevoerd. Service Fabric biedt ook de mogelijkheid om toepassingen uit te voeren onder een lokaal gebruikersaccount of lokaal systeemaccount, dat is opgegeven in het toepassingsmanifest. Zie Een service uitvoeren als een lokaal gebruikersaccount of lokaal systeemaccount voor meer informatie. U kunt ook een opstartscript voor een service uitvoeren als een lokaal gebruikers- of systeemaccount.
Wanneer u Service Fabric uitvoert op een zelfstandig Windows-cluster, kunt u een service uitvoeren onder Active Directory-domeinaccounts of door groepen beheerde serviceaccounts.
Beveiligde containers
Service Fabric biedt een mechanisme voor services in een container voor toegang tot een certificaat dat is geïnstalleerd op de knooppunten in een Windows- of Linux-cluster (versie 5.7 of hoger). Dit PFX-certificaat kan worden gebruikt voor het verifiëren van de toepassing of service of voor beveiligde communicatie met andere services. Zie Een certificaat importeren in een container voor meer informatie.
Daarnaast biedt Service Fabric ook ondersteuning voor gMSA (beheerde serviceaccounts voor groepen) voor Windows-containers. Zie GMSA instellen voor Windows-containers voor meer informatie.
Communicatie tussen beveiligde services
In Service Fabric wordt een service ergens in een Service Fabric-cluster uitgevoerd, meestal verdeeld over meerdere VM's. Service Fabric biedt verschillende opties voor het beveiligen van uw servicecommunicatie.
U kunt HTTPS-eindpunten inschakelen in uw ASP.NET Core- of Java-webservices .
U kunt een beveiligde verbinding tot stand brengen tussen de omgekeerde proxy en services, waardoor een end-to-end beveiligd kanaal mogelijk is. Verbinding maken het beveiligen van services wordt alleen ondersteund wanneer omgekeerde proxy is geconfigureerd om te luisteren op HTTPS. Lees omgekeerde proxy in Azure Service Fabric voor informatie over het configureren van de omgekeerde proxy. Verbinding maken een beveiligde service beschrijft hoe u een beveiligde verbinding tot stand brengt tussen de omgekeerde proxy en services.
Het Reliable Services-toepassingsframework biedt enkele vooraf gemaakte communicatiestacks en hulpprogramma's die u kunt gebruiken om de beveiliging te verbeteren. Meer informatie over het verbeteren van de beveiliging wanneer u externe services gebruikt (in C# of Java) of met WCF.
Eindpuntcertificaat opnemen in Service Fabric-toepassingen
Als u het certificaat voor het toepassingseindpunt wilt configureren, voegt u het certificaat toe door een EndpointCertificate-element toe te voegen, samen met het element Gebruiker voor het principal-account aan het toepassingsmanifest. Standaard is het principal-account NetworkService. Hiermee wordt het beheer van de persoonlijke sleutel-ACL van het toepassingscertificaat voor de opgegeven principal geboden.
<ApplicationManifest … >
...
<Principals>
<Users>
<User Name="Service1" AccountType="NetworkService" />
</Users>
</Principals>
<Certificates>
<EndpointCertificate Name="MyCert" X509FindType="FindByThumbprint" X509FindValue="[YourCertThumbprint]"/>
</Certificates>
</ApplicationManifest>
Toepassingsgegevens at rest versleutelen
Elk knooppunttype in een Service Fabric-cluster dat wordt uitgevoerd in Azure, wordt ondersteund door een virtuele-machineschaalset. U kunt met behulp van een Azure Resource Manager-sjabloon gegevensschijven koppelen aan de schaalsets die gezamenlijk het Service Fabric-cluster vormen. Als uw services gegevens opslaan op een gekoppelde gegevensschijf, kunt u deze gegevensschijven versleutelen om uw toepassingsgegevens te beveiligen.