Sécuriser la base de données Azure SQL vers le service d’application

Il n’y a rien de plus important que d’obtenir l’accès aux données de votre organisation. Voici comment configurer votre base de données Azure SQL afin que seules les applications autorisées puissent y accéder.

Dans Codage Azure 4: sécuriser un service Web dans un service d’application pour accéder à une base de données Azure SQLJ’ai créé et attribué une identité gérée à un service d’applications détenant un service Web qui accède à une base de données Azure SQL. Dans cet article, je vais profiter de cette identité pour autoriser uniquement ce service d’application (ou plutôt le service Web exécuté à l’intérieur du service d’application) pour accéder à ma base de données. Après cela, je vais montrer comment sécuriser davantage votre base de données en utilisant quelque chose de moins «basé sur le cloud»: les adresses IP.

Comme je l’ai discuté dans mon article précédent, une identité gérée et un utilisateur sont tous deux des exemples de directeurs de service – IE, des choses auxquelles vous pouvez attribuer des autorisations (les utilisateurs ont également des informations de compte qui leur sont attribuées). L’un des endroits où vous pouvez utiliser un directeur de service est dans une base de données Azure SQL, à condition que vous ayez configuré votre ressource de base de données Azure SQL pour utiliser l’identifiant ENTRA comme fournisseur d’authentification, comme je l’ai fait dans Codage Azure 2: Configuration d’une base de données Azure SQL.

Attribution des autorisations

Dans une base de données, «donner des autorisations» commence par la configuration de votre identité gérée en tant qu’utilisateur pour votre base de données. Pour ce faire, démarrez SQL Server Management Studio et connectez-vous à votre serveur de base de données Azure SQL (dans mon cas, c’est WareHoudBserver.Database.Windows.Net).

Ajout de l’identité gérée

Pour ajouter votre identité gérée en tant qu’utilisateur:

1. Dans le volet d’explorateur d’objets à gauche, développez le Bases de données Node pour afficher votre base de données (ma base de données est appelée WareHoudB).
2. Fermer dans votre base de données Sécurité nœud pour accéder au Utilisateurs Node (vous devrez peut-être actualiser votre vue une ou deux fois avant que le nœud de sécurité ne s’affiche).
3. Cliquez avec le bouton droit sur le sur le Utilisateurs nœud et, dans le menu contextuel, sélectionnez «nouvel utilisateur» pour afficher le Utilisateur de la base de données – Nouveau dialogue.
4. En haut de la boîte de dialogue, dans le Type d’utilisateur boîte de dialogue, sélectionnez Utilisateur externe (Dans ce cas, votre identité gérée par ID Azure ENTRA).
5. Dans le Nom d’utilisateur TextBox, entrez le nom de votre identité gérée (dans mon cas, c’est WarehouseManagementDBAccess).
6. Cliquez sur le bouton OK pour ajouter votre identité gérée en tant qu’utilisateur dans votre base de données.

Votre utilisateur apparaîtra désormais dans SQL Server Management Studio, sous le nœud des utilisateurs de votre base de données. Pour confirmer que votre utilisateur a des autorisations de connexion:

1. Cliquez avec le bouton droit sur votre nouvel utilisateur et sélectionnez Propriétés Pour ouvrir le Propriétés de la base de données dialogue.
2. Dans le menu à gauche de cette boîte de dialogue, sélectionnez Autorisation pour afficher les autorisations de votre utilisateur.
3. Dans la liste étiquetée Explicitefaites défiler vers le bas vers le Connecter entrée.
4. Assurez-vous que la case à cocher dans le Accorder la colonne est vérifiée.

Vous pouvez ajouter des paramètres / autorisations supplémentaires pour votre ressource Azure SQL à votre identité gérée (par exemple, donnez à votre identité un rôle de base de données ou un schéma par défaut). Cependant, moins l’identité a des fonctionnalités dans cette ressource, plus votre base de données est sécurisée. Le minimum que vous devez fournir est l’accès à des tables individuelles dans la base de données, et cela ne nécessite rien de plus que les autorisations de connexion déjà accordées.

Ajout d’autorisations de table

L’étape suivante consiste à donner à votre utilisateur d’identité géré l’accès à la table dont elle a besoin. Au départ, tout ce que je veux que mon identité puisse faire est de renvoyer toutes les lignes de la table Saleslt.Products de mon entrepôt. Pour ce faire:

1. Toujours dans le volet d’explorateur d’objets de SQL Server Management Studio, développez le Bases de données nœud.
2. Sous le nœud de base de données, développez l’entrée de votre base de données Azure SQL (dans mon cas, c’est WarehousedB).
3. À l’intérieur de ce nœud de base de données, élargissez le Tables Node et clic droit sur la table à laquelle vous souhaitez donner à votre identité un accès géré (dans mon cas, Saleslt.Products).
4. Dans le menu contextuel, sélectionnez Propriétés Pour afficher le Propriétés de la table dialogue
5. Dans le menu dans le côté gauche de la boîte de dialogue, sélectionnez Autorisation Pour ouvrir un nouveau panneau à droite.
6. Dans ce panneau, cliquez sur le Recherche bouton pour ouvrir le Sélectionnez des utilisateurs ou des rôles dialogue.
7. Dans cette boîte de dialogue, cliquez sur le Parcourir bouton pour ouvrir le Parcourir les objets Dialogue qui comprendra, par exemple, votre identité gérée.
8. Dans la liste de cette boîte de dialogue, cochez votre identité gérée (dans mon cas, c’est WarehouseMgmtdBaccess).
9. Cliquez sur D’ACCORD Bouton pour fermer la boîte de dialogue et retourner à la boîte de dialogue Sélectionnez les utilisateurs ou les rôles.
10. Cliquez sur cette boîte de dialogue D’ACCORD Bouton pour revenir à la boîte de dialogue Propriétés de la table.
11. Accorder colonne (je viens de vérifier la colonne de subvention pour Sélectionner autorisation).
12. Cliquez sur D’ACCORD

Configuration des adresses

Mais nous pouvons faire un peu plus pour nous assurer que seul notre service Web peut accéder à notre base de données Azure SQL en tirant parti des adresses TCP de votre service d’application et du pare-feu intégré d’Azure SQL.

Adresses de service d’application

Votre service d’application dispose d’un ensemble d’adresses TCP sortantes qui sont utilisées lorsque votre service Web envoie une demande (par exemple, les demandes envoyées à votre base de données Azure SQL). You can find those outbound addresses on your App Service’s Overview page or from your App Service’s left-hand menu under Paramètres | Réseautage. In either place, look for the label

• Serveur
• Base de données

Les règles au niveau de la base de données sont d’abord traitées et, si votre service d’application est refusé à ce niveau, votre demande sera rejetée quel que soit le paramètre au niveau du serveur. Les règles au niveau de la base de données peuvent avoir du sens si vous autorisez un grand nombre d’utilisateurs au niveau du serveur et que vous souhaitez ensuite refuser sélectivement l’accès aux bases de données individuelles pour les utilisateurs ou les ressources autorisées à accéder au niveau de la base de données. Il s’agit d’une stratégie qui ajoute de la complexité à votre configuration de sécurité et les règles au niveau de la base de données résultantes sont beaucoup moins visibles que celles définies dans le portail Azure.

1. et pas
2. Sécurité | Réseautage
3. Sous Règles de pare-feu
4. Nom de règle
5. Dans le
6. Dans le TextBox, entrez l’adresse IP la plus élevée.
7. Cliquez sur D’ACCORD

You’ve now whitelisted your App Service for your database. Ce qui soulève la question: sans cette règle en place, comment votre service d’application a-t-il pu accéder à votre ressource de base de données?

Jusqu’à présent, votre service d’applications a eu accès via une exception de pare-feu qui permet à tous les services et ressources Azure d’envoyer des demandes à votre serveur de base de données. Vous devez désactiver cela maintenant (sinon, mettre les adresses IP de votre service d’application est redondante).

Autoriser les services et les ressources Azure… . EtCochez cette case et cliquez sur le Sauvegarder bouton en bas de la page pour commettre vos modifications.

peut faire quelque chose ne signifie pas que vous devrait Faites quelque chose. Plus vous prenez de mesures pour garantir l’accès à vos applications, plus il est probable que, au fil du temps et que les changements apportent du temps, votre application échouera.

Si, par exemple, vous détruisez et recréez votre service d’applications, il peut obtenir un nouvel ensemble d’adresses sortantes … De nouvelles adresses qui, bien sûr, seront incompatibles avec les paramètres du pare-feu de votre base de données. Alternativement, si vous modifiez le plan de service de votre service d’application, de base, standard ou premium à Premium2 ou Premium3, votre service d’application obtiendra des adresses sortantes supplémentaires qui, encore une fois, ne seront pas blanches dans le pare-feu de votre base de données, mais votre service d’application sera utilisé.

Et vous ne pouvez rien faire du tout et avoir toujours le changement d’adresses IP de votre service d’application – Microsoft fait pas garantir que ce sont des adresses statiques. Les équipes Azure essaient cependant d’envoyer des notifications d’adresse IP changent environ 90 jours avant le changement, vous donnant le temps de planifier le changement.

Vous pouvez y remédier juste en «être prudent» lors de la création de votre service d’applications, mais un meilleur choix serait de profiter des modèles d’Azure pour définir les services. Je couvrirai cela dans un post ultérieur. Alternativement, si vous aimez cette idée de la liste blanche de votre service d’application mais que vous préférez avoir une adresse IP statique garantie, vous pouvez envisager de mettre à niveau (et de payer) un Environnement de service d’application.

Ou vous pouvez décider que l’exception par défaut qui limite l’accès à votre ressource de base de données à d’autres éléments de votre locataire Azure peut être suffisante. Je ne suis pas là pour juger.

Étapes suivantes

Maintenant que vous avez un niveau de données (votre base de données Azure SQL) et un niveau intermédiaire (votre service d’applications tenant votre service Web), vous avez besoin d’un frontend. Avant de couvrir cela, cependant, maintenant que vous avez déployé du code, il est logique d’activer le débogage et la journalisation. Je vais couvrir cela dans mon prochain post et, après cela, je procurerai la création de fronts côté client et côté serveur.