Overwegingen voor identiteits- en toegangsbeheer voor de azure Integration Services-landingszoneversneller
Dit artikel bouwt voort op de richtlijnen in het Azure-landingszone-ontwerpgebied voor identiteits- en toegangsbeheer. De richtlijnen in het volgende artikel helpen u bij het identificeren van ontwerpoverwegingen en aanbevelingen die betrekking hebben op identiteits- en toegangsbeheer dat specifiek is voor de implementatie van Azure Integration Services (AIS). Als AIS is geïmplementeerd ter ondersteuning van bedrijfskritieke platforms, moeten de richtlijnen voor de ontwerpgebieden van de Azure-landingszone ook worden opgenomen in uw ontwerp.
Overzicht van identiteits- en toegangsbeheer (IAM)
In dit artikel verwijst Identiteits- en toegangsbeheer (IAM) naar de verificatie- en autorisatieopties die beschikbaar zijn voor het implementeren of onderhouden van resources in Azure. In de praktijk gaat het hierbij om het identificeren van welke identiteiten gemachtigd zijn om resources te maken, bij te werken, te verwijderen en te beheren via Azure Portal of via de Resource Manager-API.
IAM is een afzonderlijke overweging van eindpuntbeveiliging, waarmee wordt gedefinieerd welke identiteiten uw services kunnen aanroepen en openen. Eindpuntbeveiliging wordt behandeld in het afzonderlijke beveiligingsartikel in deze reeks. Dat gezegd hebbende, overlappen de twee ontwerpgebieden soms elkaar: voor sommige services in Azure wordt de toegang tot het eindpunt geconfigureerd via dezelfde RBAC-besturingselementen die worden gebruikt om de toegang tot de resources te beheren.
Ontwerpoverwegingen
Bepaal de grenzen van het Azure-resourcebeheer voor de resources die u implementeert, rekening houdend met de scheiding van taken en operationele efficiëntie.
Controleer de Activiteiten van Azure-beheer en -beheer die u nodig hebt om uw teams uit te voeren. Houd rekening met de AIS-resources die u gaat implementeren en hoe u deze gaat gebruiken. Bepaal de best mogelijke verdeling van verantwoordelijkheden binnen uw organisatie.
Ontwerpaanaanvelingen
Beheerde identiteiten gebruiken voor resources voor integratieservices. Zie het beveiligingsartikel in deze reeks voor een gedetailleerde beschrijving van deze aanbeveling.
Gebruik Microsoft Entra-id voor verificatie bij resources van integratieservices.
Houd rekening met het toegangsniveau dat nodig is voor rollen binnen uw organisatie en pas het principe van minimale bevoegdheden per rol toe. Deze rollen kunnen bijvoorbeeld platformeigenaren, workloadeigenaren, devops-technici en systeembeheerders zijn.
Gebruik het principe van minimale bevoegdheden om na te gaan welke rollen u nodig hebt om uw AIS-toepassingen te beheren en te onderhouden. Vragen die in dit verband moeten worden gesteld:
Wie moet logboekbestanden weergeven uit bronnen zoals Application Insights, Log Analytics en Opslagaccounts?
Moet iemand de oorspronkelijke aanvraaggegevens bekijken (inclusief gevoelige gegevens)?
Waar kunnen oorspronkelijke aanvraaggegevens worden weergegeven (bijvoorbeeld alleen vanuit uw bedrijfsnetwerk)?
Wie kunt u de uitvoeringsgeschiedenis voor een werkstroom bekijken?
Wie kan een mislukte uitvoering opnieuw indienen?
Wie toegang nodig tot API Management-abonnementssleutels?
Wie kunt de inhoud van een Service Bus-onderwerp of -abonnement bekijken of metrische gegevens over wachtrij/onderwerp bekijken?
Wie moet Key Vault kunnen beheren?
Wie moet sleutels, geheimen en certificaten kunnen toevoegen, bewerken of verwijderen in Key Vault?
Wie moet sleutels, geheimen of certificaten in Key Vault kunnen bekijken en lezen?
Hebben de bestaande ingebouwde Microsoft Entra-rollen en -groepen betrekking op de vereisten die u hebt geïdentificeerd?
Maak aangepaste rollen om de toegang te beperken of om meer granulariteit te bieden ten opzichte van machtigingen wanneer ingebouwde rollen de toegang niet voldoende vergrendelen. Voor toegang tot de callback-URL voor een logische app is bijvoorbeeld één machtiging vereist, maar er is geen ingebouwde rol voor dat type toegang, behalve 'Inzender' of 'Eigenaar', die te breed zijn.
Bekijk het gebruik van Azure Policy om de toegang tot bepaalde resources te beperken of naleving van het bedrijfsbeleid af te dwingen. U kunt bijvoorbeeld een beleid maken waarmee alleen API Management-API's kunnen worden geïmplementeerd die gebruikmaken van versleutelde protocollen.
Bekijk algemene activiteiten die betrokken zijn bij het beheer en beheer van AIS in Azure en wijs RBAC-machtigingen op de juiste manier toe. Zie de bewerkingen van de resourceprovider voor meer informatie over de beschikbare machtigingen.
Enkele voorbeelden van veelvoorkomende Azure-beheeractiviteiten zijn:
| Azure-resource | Azure-resourceprovider | Activiteiten |
|---|---|---|
| App Service-plan | Microsoft.Web/serverfarms | Lees-, join-, restart-, get VNet-Verbinding maken ions |
| API-verbinding | Microsoft.Web/connections | Bijwerken, bevestigen |
| Logic Apps en Functions | Microsoft.Web/sites | Lezen, Starten, Stoppen, Opnieuw opstarten, Wisselen, Configuratie bijwerken, Diagnostische gegevens lezen, VNet-Verbinding maken ionen ophalen |
| Integratieaccount | Microsoft.Logic/integrationAccounts | Assembly's lezen/toevoegen/bijwerken/verwijderen, lezen/bijwerken/bijwerken/verwijderen Kaarten, schema's lezen/bijwerken/verwijderen, overeenkomsten lezen/toevoegen/bijwerken/verwijderen, lezen/bijwerken/verwijderen partners |
| Service Bus | Microsoft.ServiceBus | Lezen, Verbinding maken ion-tekenreeks ophalen, DR-configuratie bijwerken, wachtrijen lezen, onderwerpen lezen, abonnementen lezen |
| Opslagaccount | Microsoft.Storage/storageAccounts | Lezen, Wijzigen (bijvoorbeeld uitvoeringsgeschiedenis van werkstroom) |
| API Management | Microsoft.ApiManagement | Een gebruiker registreren/verwijderen, API's lezen, autorisaties beheren, cache beheren |
| KeyVault | Microsoft.KeyVault/vaults | Een kluis maken, toegangsbeleid bewerken |
Volgende stap
Bekijk de kritieke ontwerpgebieden om volledige overwegingen en aanbevelingen voor uw architectuur te maken.