Modifier

Microservices serverless intégrés au réseau virtuel

Gestion des API Azure
Azure Cosmos DB
Azure Functions
Azure Key Vault
Réseau virtuel Azure

Dans cette solution Azure, les contrôles Azure API Management (APIM) accèdent à l’API par le biais d’un point de terminaison managé unique. Le backend de l’application se compose de deux applications de microservices Azure Functions interdépendantes qui créent et gèrent des dossiers de patients et des enregistrements d’audit. APIM et les deux applications de fonction accèdent l’un à l’autre via un réseau virtuel verrouillé.

Cet article et le projet de code associé analysent le scénario d’exemple jusqu’aux principaux composants techniques, pour servir de structure à des implémentations spécifiques. La solution automatise tous les déploiements de code d’infrastructure avec Terraform et inclut l’intégration, l’unité et le test de charge automatisés.

Architecture

Le diagramme suivant représente le flux de demande de création d’un dossier de patient :

Diagram showing virtual network integrated microservices.

Téléchargez un fichier Visio de cette architecture.

Workflow

  1. Les services et clients extérieurs envoient une requête POST à APIM, avec un corps de données contenant des informations sur le patient.
  2. APIM appelle la fonction CreatePatient dans l’API Patient avec les informations du patient donné.
  3. La fonction CreatePatient dans l’API Patient appelle la fonction CreateAuditRecord dans l’application de fonction API Audit pour créer un enregistrement d’audit.
  4. La fonction CreateAuditRecord de l’API Audit crée l’enregistrement d’audit dans Azure Cosmos DB et renvoie une réponse de réussite à la fonction CreatePatient de l’API Patient.
  5. La fonction CreatePatient crée le document du patient dans Azure Cosmos DB et renvoie une réponse de réussite à APIM.
  6. Les services et clients extérieurs reçoivent la réponse de réussite de la part d’APIM.

Components

Cette solution utilise les composants suivants :

  • Azure API Management (APIM) est une plateforme multicloud hybride dédiée à la gestion des API dans tous les environnements. Dans cette solution, APIM contrôle l’accès interne et tiers à l’API Patient qui permet la lecture et/ou l’écriture de données. APIM permet une intégration facile à différents mécanismes d’authentification.

  • Azure Functions est une plateforme de calcul serverless qui gère de petites portions de code pilotées par les événements. L’infrastructure cloud fournit les serveurs mis à jour nécessaires pour exécuter les fonctions à grande échelle. La solution actuelle utilise un ensemble de deux microservices d’API Azure Functions qui créent et gèrent les opérations pour les résultats d’analyses des patients et les enregistrements d’audit.

  • Azure Virtual Network fournit un environnement d’application isolé et hautement sécurisé en limitant l’accès au réseau à des sous-réseaux ou adresses IP spécifiques. APIM et Azure Functions prennent en charge la restriction d’accès et le déploiement dans les réseaux virtuels. Cette solution utilise l’intégration de réseau virtuel régional pour déployer les deux applications de fonction dans le même réseau virtuel dans la même région.

  • Azure Key Vault stocke, chiffre et gère l’accès aux clés, certificats et chaînes de connexion de manière centralisée. Cette solution gère les clés d’hôte Azure Functions et les chaînes de connexion Azure Cosmos DB dans un Key Vault auquel seules les identités spécifiées peuvent accéder.

  • Azure Cosmos DB est une base de données serverless entièrement gérée avec mise à l’échelle automatique et instantanée. Dans la solution actuelle, les deux microservices stockent des données dans Azure Cosmos DB à l’aide du pilote Node.js MongoDB. Les services ne partagent pas de données et vous pouvez déployer chaque service dans sa propre base de données indépendante.

  • Application Insights, une fonctionnalité d’Azure Monitor, fournit des rapports sur les performances, l’utilisation, la disponibilité et le comportement des applications pour détecter et diagnostiquer les anomalies.

    Les défaillances dans une architecture basée sur des microservices sont souvent réparties sur plusieurs composants et ne peuvent pas être diagnostiquées en examinant les services séparément. La possibilité de mettre en corrélation les données de télémetrie entre composants est essentielle pour diagnostiquer ces problèmes. La télémétrie Application Insights centralise la journalisation tout au long du pipeline de requête afin de détecter les anomalies en matière de performances. La télémetrie partage un ID d’opération commun, ce qui permet de mettre tous les composants en corrélation.

    APIM et le runtime Azure Functions intègrent la prise en charge d’Application Insights pour générer et mettre en corrélation un grand nombre de données de télémétrie, notamment la sortie d’application standard. Les applications de fonction utilisent le Kit de développement logiciel (SDK) Node.js d’Application Insights pour suivre manuellement les dépendances et d’autres données de télémétrie personnalisées.

    Pour plus d’informations sur le suivi des données de télémétrie distribuées dans cette solution, consultez Données de télémétrie distribuées.

Autres solutions

  • La solution actuelle nécessite une clé d'abonnement pour accéder au point de terminaison APIM, mais vous pouvez également utiliser l'authentification Microsoft Entra.
  • En plus d'exiger des clés d'accès API, vous pouvez utiliser l'authentification App Service intégrée d'Azure Functions pour activer l'autorisation Microsoft Entra pour les identités managées des API.
  • Vous pouvez remplacer le point de terminaison Azure Cosmos DB dans cette solution par un autre service MongoDB sans modifier le code.
  • Pour améliorer la sécurité d’Azure Cosmos DB, vous pouvez verrouiller le trafic des bases de données Azure Cosmos DB vers les applications de fonction.
  • Les composants tels qu’Azure Cosmos DB peuvent envoyer des données de télémétrie à Azure Monitor, où celles-ci sont mises en corrélation avec les données de télémétrie issues d’Application Insights.
  • Vous pouvez utiliser le portail Azure ou Azure CLI au lieu de Terraform pour les tâches de rotation de clés Key Vault.
  • Vous pouvez utiliser un système tel que Azure DevOps ou GitHub Actions au lieu de Terraform pour automatiser le déploiement de la solution.
  • Pour une plus grande disponibilité, cette solution peut être déployée dans plusieurs régions. Configurez les fonctionnalités multimaîtres dans Azure Cosmos DB, utilisez la prise en charge multirégion intégrée d’APIM et déployez les applications Azure Function dans des régions jumelées.

Détails du scénario

Cet article décrit une solution intégrée pour la gestion des dossiers médicaux. Un établissement de santé doit stocker numériquement de grands volumes de données médicales sensibles dans le cloud. Les systèmes internes et tiers doivent pouvoir lire et écrire les données de manière sécurisée via une interface de programmation d’applications (API). Toutes les interactions avec les données doivent être enregistrées dans un registre d’audit.

Cas d’usage potentiels

  • Accéder à des données très sensibles à partir de points de terminaison externes désignés.
  • Implémenter un audit sécurisé pour les opérations d’accès aux données.
  • Intégrer des applications de microservices interdépendantes avec un accès et une sécurité communs.
  • Utiliser des fonctionnalités de sécurité de réseau virtuel tout en bénéficiant des économies et de la flexibilité d’un système serverless.

Avantages

Les applications serverless comme Azure Functions offrent, entre autres avantages, un coût intéressant et la possibilité d’utiliser uniquement les ressources de calcul nécessaires, au lieu de payer à l’avance pour des serveurs dédiés. Cette solution permet à Azure Functions d’utiliser des restrictions d’accès au réseau virtuel pour des raisons de sécurité, sans impliquer le coût ni la surcharge opérationnelle des environnements Azure App Service.

APIM contrôle l’accès interne et tiers à un ensemble de microservices d’API reposant sur Azure Functions. L’API Patient fournit des opérations de création, lecture, mise à jour et suppression pour les patients et leurs résultats d’analyses. L’application de fonction API Audit fournit des opérations pour créer des entrées d’audit.

Chaque application de fonction stocke ses données dans une base de données Azure Cosmos DB indépendante. Azure Key Vault conserve de manière sécurisée l’ensemble des clés, secrets et chaînes de connexion associés aux applications et aux bases de données. La télémétrie Application Insights et Azure Monitor centralisent la journalisation sur l’ensemble du système.

Considérations

Ces considérations implémentent les piliers d’Azure Well-Architected Framework qui est un ensemble de principes directeurs qui permettent d’améliorer la qualité d’une charge de travail. Pour plus d’informations, consultez Microsoft Azure Well-Architected Framework.

Prenez en compte les points suivants lorsque vous implémentez cette solution :

Sécurité

La sécurité fournit des garanties contre les attaques délibérées, et contre l’utilisation abusive de vos données et systèmes importants. Pour plus d’informations, consultez Vue d’ensemble du pilier Sécurité.

En raison de la confidentialité des données, la sécurité est primordiale dans cette solution. La solution utilise divers mécanismes pour protéger les données :

  • Gestion de la passerelle APIM
  • Restrictions de l’accès au réseau virtuel
  • Clés d’accès au service et chaînes de connexion
  • Gestion des clés et des chaînes de connexion dans Key Vault
  • Rotation des clés Key Vault
  • Identités de service managées

Vous pouvez protéger votre instance Gestion des API Azure contre les attaques par déni de service distribué (DDoS) avec Azure DDoS Protection. Azure DDoS Protection fournit des fonctionnalités améliorées d’atténuation des risques pour la défense contre les attaques DDoS volumétriques et par protocole.

Pour plus d’informations sur le modèle de sécurité de cette solution, consultez Modèle de sécurité pour la communication entre API Management, les applications Functions et Azure Cosmos DB.

Gestion de la passerelle API

Le système est accessible publiquement uniquement par le point de terminaison APIM managé unique. Le sous-réseau APIM limite le trafic entrant aux adresses IP du nœud de passerelle spécifié.

APIM permet une intégration facile à différents mécanismes d’authentification. La solution actuelle nécessite une clé d'abonnement, mais vous pouvez également utiliser Microsoft Entra ID pour sécuriser le point de terminaison APIM sans avoir à gérer les clés d'abonnement dans APIM.

Réseau virtuel

Pour éviter d’exposer publiquement les API et les fonctions, Azure Virtual Network limite l’accès réseau des API et fonctions à des sous-réseaux ou adresses IP spécifiques. API Management et Azure Functions prennent en charge la restriction d’accès et le déploiement dans les réseaux virtuels.

Les applications de fonction peuvent limiter l’accès au sous-réseau des IPv4, IPv6 et du réseau virtuel. Par défaut, une application de fonction autorise tous les accès mais dès que vous ajoutez une ou plusieurs restrictions d’adresses ou de sous-réseaux, l’application refuse tout autre trafic réseau.

Dans cette solution, les applications de fonction autorisent les interactions uniquement au sein de leur propre réseau virtuel. L’API Patient autorise les appels provenant du sous-réseau APIM en ajoutant celui-ci à sa liste d’autorisation. L’API Audit autorise la communication avec l’API Patient en ajoutant le sous-réseau de l’API Patient à sa liste d’autorisation. Les API refusent le trafic provenant d’autres sources.

La solution utilise l’intégration de réseau virtuel régional pour intégrer APIM et les applications de fonction dans le même réseau virtuel et la même région Azure. Différents aspects importants doivent être pris en compte pour utiliser l’intégration de réseau virtuel régional :

  • Vous devez utiliser la référence SKU Azure Functions Premium pour avoir l’intégration et l’extensibilité de réseau virtuel régional.
  • Vous devez utiliser la référence SKU Developer ou Premium APIM pour activer la connectivité VNET
  • Etant donné que vous déployez les applications de fonction dans un sous-réseau du réseau virtuel, vous devez configurer les restrictions d’accès des applications de fonction pour autoriser le trafic provenant des autres sous-réseaux du réseau virtuel.
  • L’intégration de réseau virtuel régional limite uniquement le trafic sortant d’Azure Function vers le réseau virtuel. Le trafic entrant est toujours routé en dehors du réseau virtuel, bien que limité par la liste d’accès de l’application.

Seuls les environnements App Service offrent un isolement complet du réseau virtuel au niveau du réseau. L’implémentation des environnements App Service peut nécessiter beaucoup plus de frais et d’efforts qu’Azure Functions qui prend en charge l’intégration de réseau virtuel régional. La mise à l’échelle des environnements AppService est également moins élastique.

Clés d'accès

Vous pouvez appeler les applications de fonction et APIM sans utiliser de clés d’accès. Toutefois, pour des raisons de sécurité, il n’est pas recommandé de désactiver les clés d’accès. Par conséquent, tous les composants de cette solution exigent une clé d’accès.

  • Une clé d’abonnement est requise pour accéder à APIM. Les utilisateurs doivent donc inclure Ocp-Apim-Subscription-Key dans les en-têtes HTTP.
  • Une clé d’accès d’API est requise pour toutes les fonctions de l’application de fonction API Patient. APIM doit donc inclure x-functions-key dans l’en-tête HTTP lors de l’appel de l’API Patient.
  • Une clé d’accès d’API est requise pour appeler CreateAuditRecorddans l’application de fonction API Audit. L’API Patient doit donc inclure x-functions-key dans l’en-tête HTTP lors de l’appel de la fonction CreateAuditRecord.
  • Les deux applications de fonction utilisent Azure Cosmos DB comme magasin de données. Elles doivent donc utiliser des chaînes de connexion pour accéder aux bases de données Azure Cosmos DB.

Stockage Key Vault

Bien qu’il soit possible de conserver les clés d’accès et les chaînes de connexion dans les paramètres de l’application, cette pratique n’est pas recommandée, car toute personne ayant accès à l’application peut voir les clés et les chaînes. La meilleure pratique, en particulier pour les environnements de production, consiste à conserver les clés et les chaînes dans Azure Key Vault, et d’utiliser les références Key Vault pour appeler les applications. Key Vault autorise uniquement l’accès aux identités managées spécifiées.

APIM utilise une stratégie de trafic entrant pour mettre en cache la clé d’hôte de l’API Patient en vue d’améliorer les performances. Pour les tentatives suivantes, APIM commence par rechercher la clé dans son cache.

  • APIM récupère la clé d’hôte de l’API Patient auprès de Key Vault, la met en cache et la place dans un en-tête HTTP lors de l’appel de l’application de fonction API Patient.
  • L’application de fonction API Patient récupère la clé d’hôte de l’API Audit auprès de Key Vault et la place dans un en-tête HTTP lors de l’appel de l’application de fonction API Audit.
  • Le runtime d’Azure Function valide les clés présentes dans les en-têtes HTTP pour les demandes entrantes.

Rotation des clés

La rotation des clés Key Vault permet d’améliorer la sécurité du système. Vous pouvez organiser une rotation automatique des clés de façon régulière, ou le faire manuellement ou à la demande en cas de fuite.

Plusieurs paramètres doivent être mis à jour pour la rotation des clés:

  • La clé d’hôte de l’application de fonction elle-même
  • Le secret dans Key Vault qui stocke la clé d’hôte
  • La référence Key Vault dans les paramètres de l’application de fonction, pour faire référence à la dernière version du secret
  • La référence Key Vault dans la stratégie de mise en cache APIM pour l’API Patient

La solution actuelle utilise Terraform pour la plupart des tâches de rotation de clés. Pour plus d’informations, consultez Modèle de rotation de clés avec Terraform.

Identités managées

Dans cette solution, APIM et les applications de fonction utilisent des identités de service managé attribuées par le système (MSI) Azure pour accéder aux secrets Key Vault. Key Vault propose les stratégies d’accès individuelles suivantes pour l’identité managée de chaque service :

  • APIM peut obtenir la clé d’hôte de l’application de fonction API Patient.
  • L’application de fonction API Patient peut obtenir la clé d’hôte de l’API Audit et la chaîne de connexion Azure Cosmos DB pour son magasin de données.
  • L’application de fonction API Audit peut obtenir la chaîne de connexion Azure Cosmos DB pour son magasin de données.

Optimisation des coûts

L’optimisation des coûts consiste à examiner les moyens de réduire les dépenses inutiles et d’améliorer l’efficacité opérationnelle. Pour plus d’informations, consultez Vue d’ensemble du pilier d’optimisation des coûts.

Le principal avantage des applications serverless comme Azure Functions est la réduction des coûts permise par la facturation à l’utilisation, au lieu de payer à l’avance pour des serveurs dédiés. La prise en charge du réseau virtuel nécessite un plan Azure Functions Premium, moyennant des frais supplémentaires. Azure Functions Premium offre une prise en charge pour l’intégration de réseau virtuel régional, tout en prenant en charge la mise à l’échelle dynamique. La référence SKU Azure Functions Premium inclut l’intégration de réseau virtuel sur APIM.

Pour obtenir plus d’informations et utiliser la calculatrice de prix, consultez Tarification d’Azure Functions.

Azure Functions peut également être hébergé sur des machines virtuelles App Service. Seuls les environnements App Service (ASE) offrent un isolement complet du réseau virtuel au niveau du réseau. Les ASE peuvent se révéler bien plus onéreux qu’un plan Azure Functions qui prend en charge l’intégration de réseau virtuel régional, et leur mise à l’échelle est moins élastique.

Déployer ce scénario

Le code source pour cette solution se trouve sur la page Azure VNet-Integrated Serverless Microservices.

Le code source TypeScript de l’API PatientTest et de l’API Audit se trouvent dans le dossier /src. Chaque source d’API comporte un conteneur dev dans lequel tous les composants requis sont installés, pour vous familiariser rapidement.

Les deux API proposent une suite complète de tests unitaires et d’intégration automatisés afin d’éviter les régressions lorsque vous apportez des modifications. Le projet est également configuré pour le linting avec ESLint, afin de conserver les styles de code et d’éviter les erreurs involontaires. Les fichiers README respectifs des services contiennent des informations sur l’exécution des tests et du linting.

Déploiement de Terraform

Le dossier /env du projet de code inclut des scripts et des modèles pour le déploiement de Terraform. Terraform déploie APIM et les applications de fonction, puis les configure de sorte qu’elles utilisent l’instance Application Insights déployée. Terraform configure également toutes les ressources et configurations, notamment le verrouillage réseau et le modèle de sécurité de la clé d’accès.

Le fichier README du déploiement explique comment déployer l’environnement Terraform dans votre abonnement Azure. Le dossier /env inclut également un conteneur dev dans lequel tous les composants requis sont installés pour le déploiement Terraform.

Tests de charge Locust

Pour évaluer les performances d’une API, vous pouvez exécuter un test de charge sur une API avec les tests de charge Locust inclus. Locust est un outil de test de charge open source. Les tests sont écrits en Python. Vous pouvez exécuter ces tests de charge localement ou à distance dans un cluster Azure Kubernetes Service (AKS). Les tests effectuent diverses opérations sur le point de terminaison APIM et vérifient les comportements par rapport à des critères de réussite et d’échec.

Contributeurs

Cet article est géré par Microsoft. Il a été écrit à l’origine par les contributeurs suivants.

Auteur principal :

  • Hannes Nel | Responsable d’ingénierie de logiciel principal

Pour afficher les profils LinkedIn non publics, connectez-vous à LinkedIn.

Étapes suivantes

Les architectures suivantes couvrent les principaux scénarios de Gestion des API :

Les articles suivants couvrent des scénarios de fonctions clés :