Service Web dans le service d’applications, Azure SQL DB

Les identités gérées sont un outil essentiel en Azure pour contrôler qui peut accéder aux données de votre organisation. Voici comment les profiter dans un service Web natif du cloud.

Dans un post précédent, Codage Azure 2: Configuration d’une base de données Azure SQLJ’ai créé une base de données Azure SQL et, dans mon dernier post, Codage Azure 3: Déploiement d’un service Web à un service d’applicationun service Web squelette que j’ai déployé sur un service d’applications. L’étape suivante consiste à fournir un code de ce service Web qui accédera à la base de données et s’assurera également que seulement Ce code, en cours d’exécution dans ce service d’application, peut accéder à la base de données.

Dans cet article, je vais fournir des antécédents sur l’outil que j’utiliserai pour contrôler l’accès (identités gérées). Je couvrirai ensuite comment configurer une identité gérée, puis configurer le service d’application tenant mon service Web (et le service Web lui-même) pour utiliser cette identité gérée. Dans mon prochain article, je couvrirai ce qui doit être fait dans la base de données pour travailler avec l’identité gérée (et suggérer également comment contrôler l’accès réseau à la base de données).

Comprendre les identités

Premièrement, une terminologie ID ENTRA. Lorsque vous vous connectez à Azure, la terminologie actuelle est que vous présentez un ensemble d’identification (nom, mot de passe, authentification multi-facteurs) qui vous donnent droit à une identité utilisateur. Une identité utilisateur a des informations de compte (par exemple, nom, adresse, adresse e-mail, poste de travail, etc.) et des autorisations pour effectuer des activités dans Azure (par exemple, lire vos propres informations de Microsoft Graph, les achats à guichet unique d’Azure pour les informations utilisateur).

Votre identité est «quelque chose qui peut bénéficier d’autorisations» et peut également être classé comme un «directeur de sécurité». Plus précisément, votre identité utilisateur peut également être appelée «principal utilisateur». Un autre type de directeur de sécurité est une identité gérée, qui peut être attribuée à une ressource Azure (par exemple, un service d’applications). Une identité gérée est une sorte de «directeur de service»: un capital sans informations de compte qui n’est jamais affecté à un utilisateur. Parce qu’une identité gérée est un directeur de sécurité, il peut – comme une identité utilisateur – se voir attribuer des autorisations.

Si vous êtes intéressé, le terme «identité gérée» fait référence à la façon dont l’identité est attribuée. Pensez-y de cette façon: une identité utilisateur est attribuée comme un utilisateur se connecte, et cette identité reste active jusqu’à ce que l’utilisateur se connecte. Une identité gérée, cependant, est attribuée lorsque la ressource démarre et est active jusqu’à ce que la ressource s’arrête – elle est gérée par Azure et non par les activités d’un utilisateur.

Il existe deux types d’identités gérées: attribuée au système et attribué par l’utilisateur. Une identité attribuée par le système est générée pour une ressource (par exemple, un service d’application) par Azure et a une durée de vie qui correspond à la ressource. Si le service APP est créé, une identité gérée attribuée par le système lui est attribuée. Et puis si ce service d’applications est supprimé, toute autorisation attribuée à cette identité attribuée par le système devra être recréée.

Une identité attribuée par l’utilisateur, en revanche, est une identité qui est créée indépendamment de toute ressource Azure et peut être affectée à toute ressource (ou ensemble de ressources). Une identité gérée attribuée par l’utilisateur peut même être créée avant toute ressource avec laquelle l’identité sera utilisée est créée. Une identité attribuée par l’utilisateur survivra également à la suppression de toute ressource qui lui est attribuée et peut, par exemple, être réappliqué (avec ses autorisations) à cette ressource lorsque la ressource est recréée.

Il y a d’autres avantages à une identité gérée attribuée par l’utilisateur. Si, par exemple, vous avez plusieurs ressources qui ont besoin des mêmes autorisations, une identité gérée avec ces autorisations pourrait être partagée avec toutes les ressources qui ont besoin d’autorisations identiques. Comme ces autorisations changent (en supposant que ces autorisations doivent être modifiées pour toutes les ressources), vous n’avez qu’à mettre à jour cette identité gérée partagée.

Donc, si vous créez un service d’applications, puis attribuez une identité gérée attribuée par l’utilisateur, vous pouvez donner cette identité gérée quelles que soient les autorisations du service Web qui s’exécute à l’intérieur de ce service d’application. Si vous supprimez et recréez plus tard ce service d’applications, il vous suffit de réaffecter l’identité gérée au nouveau service d’applications pour restaurer l’accès à la base de données.

Et, bien que les identités gérées soient une grande chose, elles ne sont qu’une solution complète pour les ressources dont les autorisations sont entièrement gérées par ENTRA ID (comptes de stockage Azure, par exemple). Pour la plupart des ressources, cependant, les seules autorisations attribuées par ID ENTRA à une identité sont les autorisations requises pour gérer la ressource (créer / supprimer la ressource, modifier les paramètres de la ressource, consulter les journaux d’audit de la ressource). Ces ressources auront un système interne pour attribuer des autorisations à une identité.

Et c’est ainsi qu’Azure SQL fonctionne, par exemple: toute identité peut accéder à Azure SQL. Mais, comme vous le verrez, c’est la sécurité interne d’Azure SQL qui contrôle les tables à laquelle l’identité peut accéder et ce que l’identité est autorisée à faire avec les tables auxquelles il peut accéder (lire les lignes, ajouter de nouvelles lignes, etc.).

Créer une identité gérée

Sur la base de tout cela, la première étape de la sécurisation du service APP avec son service Web dans la base de données Azure SQL consiste à créer une identité gérée. Vous n’aurez peut-être pas d’autorisations pour ce faire et vous auriez besoin d’obtenir un administrateur pour le faire pour vous. Une fois l’identité créée, cependant, le créateur peut utiliser l’identité gérée Contrôle d’accès (IAM) page pour vous donner accès à l’identité gérée. Les deux rôles pertinents sont:

• Opérateur d’identité géré: Compte tenu de ce rôle, vous pouvez attribuer l’identité aux ressources Azure (par exemple, votre service d’applications) mais ne pouvez pas modifier les autorisations attribuées à l’identité. C’est tout ce dont vous avez besoin pour sécuriser le service Web dans la base de données Azure SQL car c’est le système de sécurité interne d’Azure SQL qui contrôlera ce que le service Web pourra faire.

• Contributeur d’identité géré: peut créer, supprimer et modifier les identités Azure. Cette identité est requise si vous devez ajouter ou supprimer les autorisations de l’identité

Si vous pouvez créer des identités gérées, les étapes sont:

1. Surfez au Portail azurentrer Identités gérées dans la zone de recherche qui apparaît en haut de la page.
2. Quand Identités gérées apparaît dans la liste déroulante, double-cliquez sur la page d’identité gérée.
3. À la fin gauche du menu en haut de la page, cliquez sur le + Créer Choix pour ouvrir la page d’identité gérée de Créer des utilisateurs.
4. Sur cette page, comme pour toute ressource Azure, vous devrez attribuer votre identité gérée à un abonnement, un groupe de ressources et une région. (J’ai utilisé le groupe de ressources WarehouseMgmt et région Central Canada pour les autres ressources de cette application.)
5. Dans le nom TextBox, donnez un nom à votre identité gérée qui reflète les autorisations que vous y attribuerez. (J’ai utilisé WarehouseMgmtDBAccess.)
6. Cliquez sur Examen + créer bouton pour commencer à créer votre identité gérée.

Les identités gérées prennent très peu de temps à créer, vous devriez donc pouvoir cliquer sur Aller à la ressource Bouton presque immédiatement pour surfer sur la page d’aperçu de votre identité gérée. À partir de cette page, copiez le ID client et enregistrer une copie de celui-ci à utiliser plus tard.

En utilisant l’identité gérée

L’étape suivante consiste à attribuer l’identité à votre service d’application:

1. Dans le portail Azure, surfez sur votre service d’applications.
2. Dans le menu à gauche, élargissez le Paramètres menu et sélectionner Identité Pour afficher la page d’identité à droite.
3. Sur la page d’identité, passez à la Utilisateur affecté languette.
4. À l’extrémité gauche du menu à travers la page, cliquez sur le + Ajouter Choix pour ouvrir le panneau d’identité géré Ajouter un utilisateur à droite.
5. Dans le panneau, à partir de la zone déroulante en haut du panneau, choisissez l’abonnement que vous avez utilisé pour votre identité gérée.
6. Dans le Identités gérées affectées par l’utilisateur TextBox, commencez à taper le nom de votre identité gérée. Lorsque votre identité gérée apparaît dans le panneau, mettez une coche à côté.
7. Cliquez sur le panneau Ajouter bouton.

Mise à jour du code de service Web

Vous pouvez ajouter le code à votre service Web pour accéder à votre base de données Azure SQL à l’aide de l’identité gérée que vous avez affectée au service APP. Tout d’abord, assurez-vous d’avoir activé l’autorisation dans le fichier Program.cs de votre service, comme ceci:

app.UseAuthorization();

Toute version du SQLClient à partir de la version 3 sur réduit l’accès à votre base de données Azure SQL en toute sécurité pour configurer votre chaîne de connexion. En supposant que vous utilisez ADO.NET, votre chaîne de connexion doit inclure ces paramètres:

• Serveur: L’URL de votre serveur de base de données préfixé avec «TCP:» (Dans mon cas, c’est TCP: WarehousedBserver.Database.Windows.net)
• ID de l’utilisateur: L’ID client de votre identité gérée que vous avez copiée plus tôt (c’est-à-dire, pas Le nom ou l’ID d’objet de votre identité géré)
• Catalogue initial: Le nom de votre base de données (dans mon cas, c’est WarehouseDB)
• Authentification: Réglez ceci sur « Activing Managed Identity »

Mettre tout cela ensemble qui signifie, dans mon cas, que ma chaîne de connexion ressemble à ceci:

SqlConnection con =
  new SqlConnection(@"Server=tcp:warehousedbserver.database.windows.net;
  User Id=<managed identity Client Id from the Managed Identity’s Overview page>;
  Initial Catalog=WarehouseDB;
  Authentication='Active Directory Managed Identity';");

Une API minimale dans le fichier Program.cs de mon service Web .NET 8 qui implémente une méthode GET qui renvoie un tableau d’objets JSON à partir de ma base de données Azure SQL à partir de <URL of my App Service>/products ressemblerait à ceci:

app.MapGet("/products", () =>
{
  List<Product> prds = new List<Product>();
  Product prd = null;
    SqlConnection con =
      new SqlConnection(@"Server=tcp:warehousedbserver.database.windows.net;
      User Id=<Client Id of the managed identity>;
      Initial Catalog=WarehouseDB;
      Authentication='Active Directory Managed Identity';");
  con.Open();
  using (SqlCommand command =
      new SqlCommand("Select * from SalesLT.Product", con))
  {
    using (SqlDataReader reader = command.ExecuteReader())
    {
      while (reader.Read())
      {
        prd = new Product();
        prd.ProductId =
        reader.GetInt32("ProductId");
        prd.Name = reader.GetString("Name");
        prd.ListPrice = reader.GetDecimal("ListPrice");
        prds.Add(prd);
      }
    }
  }
  return prds;
})
.WithName("GetAllProducts")
.WithOpenApi();

Étapes suivantes

Bien que ce soit un joli code, cela ne fonctionnera pas encore. L’étape suivante consiste à donner votre autorisation d’identité gérée pour accéder aux tables dans votre base de données Azure SQL – c’est mon prochain article.

Je dois également souligner que je ne suis pas content d’inclure toutes ces informations dans mon code source où il est disponible pour quiconque peut consulter le code. Je vais résoudre ce problème dans un article ultérieur où j’intégrerai le coffre-fort et la configuration de l’application d’Azure. Vous ne devriez pas non plus prendre la simplicité de l’utilisation d’une identité gérée avec Azure SQL comme typique – il y a plus à faire, comme vous le verrez lorsque je créerai un frontend pour cette application.

Mais le prochain article fera fonctionner ce code.