Bewerken

Communicatie tussen services beperken

Azure
Microsoft Entra ID
Azure App Service

In dit voorbeeldscenario wordt de communicatie tussen twee Azure-back-endservices op zowel de toepassings- als netwerklagen beperkt. Communicatie kan alleen stromen tussen services die dit expliciet toestaan, waarbij het aan het principe van minimale bevoegdheden wordt gekoppeld. In dit voorbeeld wordt Azure-app Service gebruikt om de services te hosten, maar u kunt vergelijkbare technieken gebruiken voor Azure Functions-apps.

Communicatiebeperkingen tussen services vormen slechts één onderdeel van een algehele beveiligingsstrategie op basis van zorgvuldige planning, bedreigingsmodellering en de levenscyclus van beveiligingsontwikkeling. Algemene beveiligingsplanning moet bedrijfs-, nalevings-, regelgevings- en andere niet-functionele vereisten omvatten.

Potentiële gebruikscases

Hoewel het huidige scenario zich richt op netwerkbeperkingen, omarmen veel organisaties nu een zero trust-beveiligingsmodel dat ervan uitgaat dat er sprake is van een inbreuk, dus de netwerklaag is van secundair belang.

Architectuur

Diagram showing both network layer and application layer communications restrictions between two Azure App Service backend services.

Download een Visio-bestand van deze architectuur.

Gegevensstroom

In het diagram ziet u beperkte communicatie van Service A naar Service B. Op tokens gebaseerde autorisatie beperkt de toegang op de toepassingslaag en service-eindpunten beperken de toegang op de netwerklaag.

Autorisatie op basis van tokens

Een met OpenID Verbinding maken (OIDC)compatibele bibliotheek, zoals de Microsoft Authentication Library (MSAL), ondersteunt deze clientreferentiestroom op basis van tokens. Zie Scenario: Daemon-toepassing die web-API's aanroept en de voorbeeldtoepassing voor het daemon-scenario voor meer informatie.

  1. Zowel Service A als Service B registreren in Microsoft Entra ID. Service A heeft clientreferenties in een gedeeld geheim of certificaatformulier.
  2. Service A kan zijn eigen clientreferenties gebruiken om een toegangstoken voor Service B aan te vragen.
  3. Microsoft Entra ID biedt een toegangstoken met een service B-doelgroep of aud-claim .
  4. Service A injecteert het token als een bearer-token in de HTTP-autorisatieheader van een aanvraag naar Service B, volgens de specificatie van het gebruik van het OAuth 2.0-token.
  5. Service B valideert het token om ervoor te zorgen dat de aud claim overeenkomt met de Service B-toepassing.

Service B gebruikt een van de volgende methoden om ervoor te zorgen dat alleen specifiek toegestane clients, Service A in dit geval, toegang kunnen krijgen:

  • Valideer de token-appid-claim. Service B kan de token-appid-claim valideren, waarmee wordt aangegeven welke geregistreerde Microsoft Entra-toepassing het token heeft aangevraagd. Service B controleert de claim expliciet op basis van een bekende lijst met bellers voor toegangsbeheer.

  • Controleer op rollen in het token. Op dezelfde manier kan Service B controleren op bepaalde rollen die zijn geclaimd in het binnenkomende token, om ervoor te zorgen dat Service A expliciete toegangsmachtigingen heeft.

  • Gebruikerstoewijzing vereisen. De eigenaar of beheerder van de service B kan ook Microsoft Entra-id configureren om gebruikerstoewijzing te vereisen, zodat alleen toepassingen met expliciete machtigingen voor de Service B-toepassing een token kunnen ophalen voor Service B. Service B hoeft vervolgens niet te controleren op specifieke rollen, tenzij hiervoor bedrijfslogica is vereist.

    Een gebruikerstoewijzingsvereiste instellen voor toegang tot Service B:

    1. Schakel in Microsoft Entra ID gebruikerstoewijzing in voor Service B.
    2. Stel ten minste één app-rol beschikbaar voor Service B waarvoor Service A toestemming kan vragen. De AllowedMemberTypes voor deze rol moeten zijn opgenomen Application.
    3. Vraag app-toestemming voor Service A aan voor de rol beschikbaar gemaakte service B.
      1. Selecteer een machtiging toevoegen in de sectie API-machtigingen van de Service A-app-registratie en selecteer vervolgens de Service B-toepassing in de lijst.
      2. Selecteer toepassingsmachtigingen in het scherm API-machtigingen aanvragen, omdat deze back-endtoepassing wordt uitgevoerd zonder een aangemelde gebruiker. Selecteer de rol Beschikbaar gemaakte service B en selecteer vervolgens Machtigingen toevoegen.
    4. Beheerderstoestemming verlenen aan de aanvraag voor service A-toepassingsmachtigingen. Alleen een eigenaar of beheerder van de service B kan toestemming geven voor de aanvraag voor service-A-machtigingen.

Service-eindpunten

In de onderste helft van het architectuurdiagram ziet u hoe u de communicatie tussen services op de netwerklaag kunt beperken:

  1. De Service A-web-app maakt gebruik van regionale VNet-integratie om alle uitgaande communicatie te routeren via een privé-IP-adres binnen het IP-bereik van het integratiesubnet.
  2. Service B heeft service-eindpunten die binnenkomende communicatie alleen toestaan vanuit web-apps in het integratiesubnet van Service B.

Zie Azure-app Service-toegangsbeperkingen instellen voor meer informatie.

Onderdelen

In dit scenario worden de volgende Azure-services gebruikt:

  • Azure-app Service fungeert als host voor zowel Service A als Service B, waardoor automatisch schalen en hoge beschikbaarheid mogelijk zijn zonder infrastructuur te hoeven beheren.
  • Microsoft Entra ID is de cloudservice voor identiteits- en toegangsbeheer waarmee services worden geverifieerd en OAuth 2.0-tokenautorisatie wordt ingeschakeld.
  • Azure Virtual Network is de fundamentele bouwsteen voor privénetwerken in Azure. Met Azure Virtual Network kunnen resources zoals virtuele Azure-machines (VM's) veilig communiceren met elkaar, internet en on-premises netwerken.
  • Azure-service-eindpunten bieden beveiligde en directe connectiviteit met Azure-services via een geoptimaliseerde route in het Backbone-netwerk van Azure en bieden alleen toegang vanaf het bereik van privé-bron-IP's in het integratiesubnet.
  • Microsoft Authentication Library (MSAL) is een bibliotheek die compatibel is met OIDC, waarmee een service toegangstokens van Microsoft Entra-id kan ophalen met behulp van een clientreferentiestroom.

Alternatieven

Er zijn verschillende alternatieven voor het voorbeeldscenario.

Beheerde identiteit

In plaats van zich te registreren als een toepassing met Microsoft Entra ID, kan Service A een beheerde identiteit gebruiken om een toegangstoken op te halen. Beheerde identiteit zorgt ervoor dat operators geen referenties hoeven te beheren voor een app-registratie.

Hoewel met een beheerde identiteit Service A een token kan ophalen, biedt service A geen Registratie van een Microsoft Entra-app. Voor andere services om een toegangstoken voor Service A zelf aan te vragen, heeft Service A nog steeds een Microsoft Entra-app-registratie nodig.

U kunt een beheerde identiteit niet toewijzen aan een app-rol via Azure Portal, alleen via de Azure PowerShell-opdrachtregel. Zie Een beheerde identiteit toegang tot een toepassingsrol toewijzen met behulp van PowerShell voor meer informatie.

Azure Functions

U kunt de services in Azure Functions hosten in plaats van App Service. Als u de toegang op de netwerklaag wilt beperken met behulp van regionale VNet-integratie, moet u de Functions-apps hosten in een App Service-plan of een Premium-abonnement. Zie Azure Functions-netwerkopties voor meer informatie.

Ingebouwde App Service-verificatie en -autorisatie

In dit scenario wordt de autorisatiecode ontworpen met de rest van de bedrijfslogica door tokenvalidatie uit te voeren als onderdeel van de toepassingscode. Ingebouwde App Service-verificatie en -autorisatie, of Easy Auth, kan ook eenvoudige tokenvalidatie uitvoeren voordat een aanvraag naar een service wordt verzonden. De service is vervolgens afhankelijk van de hostinginfrastructuur om niet-geautoriseerde aanvragen te weigeren.

Als u App Service-verificatie en -autorisatie wilt configureren, stelt u het autorisatiegedrag in op Aanmelden met Microsoft Entra-id. Met deze instelling worden tokens gevalideerd en wordt alleen de toegang tot geldige tokens beperkt.

Het nadeel van het gebruik van Easy Auth is dat de service de verificatie- en autorisatiebeveiliging verliest als deze ergens anders wordt verplaatst. Hoewel App Service-verificatie en -autorisatie werkt voor eenvoudige scenario's, moeten complexe autorisatievereisten logica gebruiken vanuit de toepassingscode.

Service-eindpunten versus privé-eindpunten

In dit scenario worden service-eindpunten gebruikt in plaats van privé-eindpunten, omdat alleen service-eindpunten toegang tot een web-app vanuit een bepaald subnet toestaan. Het filteren van inkomend verkeer op privé-eindpunten wordt niet ondersteund via netwerkbeveiligingsgroepen (NSG's) of met behulp van App Service-toegangsbeperkingen. Elke service met netwerklijn-of-sight kan communiceren met het privé-eindpunt van een webtoepassing. Dit beperkt het nut van privé-eindpunten voor het vergrendelen van verkeer op de netwerklaag.

Overwegingen

  • Regionale VNet-integratie van App Service biedt één integratiesubnet voor elk App Service-plan. Alle web-apps in hetzelfde plan kunnen worden geïntegreerd met hetzelfde subnet en dezelfde set privé-uitgaande IP-adressen delen. Het ontvangen van services kan niet onderscheiden van welke web-app het verkeer afkomstig is. Als u de oorspronkelijke web-app wilt identificeren, moet u de web-apps implementeren in afzonderlijke App Service-plannen, elk met een eigen integratiesubnet.

  • Elk werkrolexemplaren in een App Service-plan neemt een afzonderlijk privé-IP-adres in het integratiesubnet in beslag. Als u de schaal wilt plannen, moet u ervoor zorgen dat het integratiesubnet groot genoeg is om aan de verwachte schaal te voldoen.

Kostenoptimalisatie

Prijzen voor dit scenario zijn afhankelijk van uw specifieke infrastructuur en vereisten. Microsoft Entra ID heeft gratis tot Premium-lagen, afhankelijk van de behoeften. De kosten voor Azure-app Service of andere hosts variëren met uw specifieke schaal- en beveiligingsvereisten, zoals beschreven in Alternatieven en Overwegingen.

Als u de kosten voor uw scenario wilt berekenen, raadpleegt u de Azure-prijscalculator.

Inzenders

Dit artikel wordt onderhouden door Microsoft. De tekst is oorspronkelijk geschreven door de volgende Inzenders.

Hoofdauteur:

Volgende stappen