05 · Implémenter la sécurité pour les bases de données

Version : 1.2 · Date : 2026-10-21 · Domaine 2 de l'examen : Stockage sécurisé, bases de données et mise en réseau (25 à 30 %)

En une phrase : une base Azure SQL se protège par couches : le réseau décide qui peut atteindre la passerelle, Microsoft Entra ID décide qui peut se connecter, le chiffrement (TDE, Always Encrypted) et le masquage protègent la donnée elle-même, et l'audit plus Defender for Databases voient et signalent ce qui se passe.

Ce que l'examen demande#

Repris mot pour mot du guide d'étude SC-500, version anglaise :

Les compléments de l'ancienne AZ-500 (Cosmos DB, PostgreSQL et MySQL, sauvegardes, SQL Server sur VM) sont en section 8.

1. Les bases à maîtriser#

1.1 La famille Azure SQL#

Le logical server n'est pas une machine : c'est un point d'administration commun (firewall, Microsoft Entra admin, audit, TDE protector) pour un ensemble de bases, joignable à <serveur>.database.windows.net.

1.2 Plan de contrôle et plan de données#

C'est la clé de beaucoup de questions :

Être Owner de l'abonnement ne donne pas le droit de lire les tables : il faut être un principal dans la base (ou le server admin).

1.3 Les rôles Azure intégrés pour SQL et la séparation des tâches#

Séparation des tâches voulue par Microsoft : celui qui crée le serveur ou le Microsoft Entra admin ne peut pas désactiver les protections, et celui qui règle la sécurité ne peut pas changer l'administrateur.

2. Sécuriser le réseau#

2.1 Les IP firewall rules (SQL Database)#

À la création, le firewall bloque tout accès au public endpoint. On ouvre par des règles :

Ordre d'évaluation d'une connexion venant d'Internet :

flowchart TD
    A[Connexion TDS vers monserveur.database.windows.net] --> B{IP dans une règle<br/>au niveau de la base demandée ?}
    B -- Oui --> OK[Connexion autorisée à cette base]
    B -- Non --> C{IP dans une règle<br/>au niveau du serveur ?}
    C -- Oui --> OK2[Connexion autorisée à toutes les bases]
    C -- Non --> KO[Connexion refusée]
    OK --> AUTH[Puis authentification SQL ou Entra]
    OK2 --> AUTH

Points d'examen :

• « Allow Azure services and resources to access this server » crée la règle 0.0.0.0 - 0.0.0.0 (AllowAllWindowsAzureIps). Elle autorise tous les services Azure, y compris ceux d'autres clients. Elle est sur Non par défaut à la création depuis le portail. Préférer les virtual network rules ou un private endpoint.
• Une modification du firewall peut mettre jusqu'à 5 minutes à s'appliquer (sauf base contenue sans partenaire de basculement) ; DBCC FLUSHAUTHCACHE force l'actualisation.
• Le firewall n'authentifie personne : il permet seulement d'essayer de se connecter.

# Règle au niveau du serveur (CLI)
az sql server firewall-rule create --resource-group rg-data-prd --server sql-app-prd \
  -n AdminBureau --start-ip-address 203.0.113.10 --end-ip-address 203.0.113.10

-- Règle au niveau de la base (T-SQL, dans la base concernée)
EXECUTE sp_set_database_firewall_rule @name = N'AppFront',
   @start_ip_address = '198.51.100.20', @end_ip_address = '198.51.100.20';

2.2 Les virtual network rules (service endpoints)#

Une virtual network rule autorise un sous-réseau précis. Elle s'appuie sur un service endpoint de type Microsoft.Sql activé sur le sous-réseau : le trafic reste sur la dorsale Azure et le serveur reconnaît le sous-réseau d'origine.

• Le portail propose d'activer le service endpoint s'il manque.
• Le drapeau IgnoreMissingVNetServiceEndpoint permet de créer la règle avant le service endpoint (pour limiter la coupure du sous-réseau pendant l'activation), mais la règle ne protège rien tant que le service endpoint n'est pas actif.
• Le serveur reste joignable par son public IP : la règle ne fait que filtrer.

2.3 Le private endpoint (Private Link)#

Un private endpoint donne au serveur une IP privée dans votre VNet ; on peut alors fermer le public.

2.4 Public network access, TLS et connection policy#

Onglet Networking du logical server :

Chiffrement en transit : le service impose toujours TLS (ForceEncryption = Yes). Côté client : Encrypt=True et TrustServerCertificate=False (ne jamais faire confiance aveuglément au certificat en production), ou le chiffrement strict de TDS 8.0.

2.5 Le réseau de SQL Managed Instance#

Le IP firewall de SQL Database ne s'applique pas à Managed Instance : tout passe par le NSG.

3. Authentification et autorisation#

3.1 Authentification SQL ou Microsoft Entra#

À retenir :

• Il faut définir un Microsoft Entra admin pour utiliser l'authentification Entra.
• Seuls des utilisateurs Entra peuvent créer d'autres utilisateurs Entra ; au départ, c'est le Microsoft Entra admin.
• Les connexions Entra échouées n'apparaissent pas dans l'audit SQL : elles sont dans les journaux de connexion Entra.

-- Utilisateur de base contenu (sans connexion dans master) pour un groupe, puis une managed identity
CREATE USER [GRP-App-Lecteurs] FROM EXTERNAL PROVIDER;
CREATE USER [app-web-prd] FROM EXTERNAL PROVIDER;          -- nom d'affichage de la managed identity
ALTER ROLE db_datareader ADD MEMBER [GRP-App-Lecteurs];
ALTER ROLE db_datawriter ADD MEMBER [app-web-prd];

Les contained database users sont portables avec la base (geo-replication, déplacement). On peut aussi créer des connexions Entra au niveau serveur (CREATE LOGIN [..] FROM EXTERNAL PROVIDER) puis des utilisateurs FROM LOGIN.

3.2 Microsoft Entra-only authentication#

Elle désactive l'authentification SQL pour tout le serveur ou l'instance (y compris le server admin).

Azure Policy intégrée : Azure SQL Database should have Microsoft Entra-only authentication enabled (et l'équivalent pour Managed Instance ; noms parfois encore en « Azure Active Directory Only »). Effets : Audit (défaut), Deny, Disabled.

Piège : la stratégie Deny agit à la création. Si quelqu'un désactive l'option ensuite, Azure Policy ne l'empêche pas : le serveur apparaît Non conforme dans le rapport.

az sql server ad-only-auth enable --resource-group rg-data-prd --name sql-app-prd
az sql mi ad-only-auth get --resource-group rg-data-prd --name sqlmi-app-prd

Terraform (fournisseur azurerm, ressource azurerm_mssql_server, arguments vérifiés dans le registre) :

resource "azurerm_mssql_server" "app" {
  name                          = "sql-app-prd"
  resource_group_name           = "rg-data-prd"
  location                      = "francecentral"
  version                       = "12.0"
  minimum_tls_version           = "1.2"
  public_network_access_enabled = false           # accès uniquement par private endpoint
  connection_policy             = "Redirect"

  azuread_administrator {
    login_username              = "GRP-SQL-Admins"
    object_id                   = "<id-objet-du-groupe>"   # datasource (groupe Entra existant)
    azuread_authentication_only = true             # pas d'administrateur SQL ni de mot de passe à gérer
  }

  identity {
    type = "SystemAssigned"                        # identité du serveur : TDE avec clé client, audit vers le stockage
  }
}

3.3 Les autorisations dans la base#

• Donner les droits à des rôles de base, jamais directement aux utilisateurs ; créer des rôles personnalisés au plus juste.
• db_owner (et le server admin) : réservé à très peu de personnes.
• EXECUTE AS pour restreindre le contexte d'exécution d'un module.
• Managed Instance offre aussi des rôles au niveau serveur (fixes ou personnalisés).
• Row-Level Security (RLS) : filtre les lignes selon l'utilisateur (5.2).

4. Chiffrer les données#

4.1 Les trois états de la donnée#

4.2 TDE with service-managed key#

• Activé par défaut sur toutes les nouvelles bases.
• Chiffre toute la base (AES) : fichiers de données, journaux et sauvegardes, sans modification de l'application.
• La clé de chiffrement de la base (DEK) est protégée par un built-in server certificate, géré et renouvelé par Microsoft.

4.3 TDE avec customer-managed key (CMK, BYOK)#

Le TDE protector devient une clé à vous, dans Azure Key Vault (FIPS 140-2 niveau 2) ou Azure Key Vault Managed HSM (FIPS 140-2 niveau 3). Il chiffre la DEK de chaque base du serveur (ou de l'instance) ; on peut aussi définir une CMK au niveau d'une base (SQL Database).

stateDiagram-v2
    [*] --> EnLigne
    EnLigne --> AccesPerdu: clé, droit ou Key Vault supprimé
    AccesPerdu --> Inaccessible: environ 10 min (30 min si erreur 4XX)
    Inaccessible --> EnLigne: accès rendu en moins de 30 min (retour automatique)
    Inaccessible --> Restauration: accès rendu après 30 min
    Restauration: Procédure dans le portail
    Restauration --> EnLigne

Piège : pour révoquer une clé compromise sans perte, on fait d'abord la rotation vers une nouvelle clé, on vérifie que toutes les bases l'utilisent, puis on désactive l'ancienne.

4.4 Always Encrypted#

Les colonnes sensibles (carte bancaire, numéro de sécurité sociale) sont chiffrées par le pilote côté client. Le moteur SQL ne voit jamais ni la donnée ni les clés : un DBA ou un opérateur cloud ne lit que du chiffré.

Secure enclaves dans SQL Database : VBS (logiciel, toutes les offres, propriété preferredEnclaveType = VBS) ou Intel SGX (série DC). Les CMK compatibles enclave sont dans Key Vault ou le Windows Certificate Store.

sequenceDiagram
    participant App as Application (pilote AE)
    participant SQL as Azure SQL
    participant KV as Key Vault
    App->>SQL: Requête paramétrée
    SQL-->>App: Métadonnées : colonne chiffrée, CEK chiffrée, emplacement de la CMK
    App->>KV: Déchiffrer la CEK avec la CMK
    KV-->>App: CEK en clair (gardée en cache côté client)
    App->>SQL: Paramètres chiffrés avec la CEK
    SQL-->>App: Résultats chiffrés
    Note over App: Le pilote déchiffre les résultats

Un utilisateur qui a le droit SELECT mais pas accès à la CMK récupère le texte chiffré, pas la donnée.

5. Protéger la donnée elle-même#

5.1 Le Dynamic Data Masking (DDM)#

Masque la donnée dans le résultat de la requête, sans la modifier dans la base. Ce n'est pas du chiffrement : la donnée reste en clair dans la base et les administrateurs la voient ; c'est une protection contre l'exposition aux utilisateurs sans privilège.

• Les administrateurs (server admin, Microsoft Entra admin, db_owner) voient toujours en clair.
• GRANT UNMASK au niveau base, schéma, table ou colonne pour un utilisateur ou un rôle.
• Portail : SQL Database seulement ; Managed Instance : par T-SQL.
• Rôles Azure qui peuvent configurer : SQL Security Manager, SQL DB Contributor, SQL Server Contributor.

ALTER TABLE Data.Membership ALTER COLUMN Email ADD MASKED WITH (FUNCTION = 'email()');
GRANT UNMASK ON Data.Membership (Email) TO ServiceLead;   -- démasquage au niveau colonne

5.2 La Row-Level Security#

La RLS restreint les lignes selon l'utilisateur qui interroge (appartenance à un groupe, SESSION_CONTEXT) : par exemple un commercial ne voit que ses clients. Le prédicat est une fonction table inline, appliquée par une security policy (CREATE SECURITY POLICY), avec deux types de prédicats :

• filter predicate : retire silencieusement les lignes des lectures (SELECT, UPDATE, DELETE) ;
• block predicate : refuse avec une erreur les écritures qui violent la règle (AFTER INSERT, AFTER UPDATE, BEFORE UPDATE, BEFORE DELETE).

Piège : la RLS s'applique aussi à dbo, db_owner et au propriétaire de la table ; ce n'est pas un chiffrement et elle ne protège pas contre un administrateur qui désactive la stratégie (ALTER SECURITY POLICY … WITH (STATE = OFF)).

CREATE SECURITY POLICY Security.SalesFilter
    ADD FILTER PREDICATE Security.fn_securitypredicate(AppUserId) ON dbo.Sales,
    ADD BLOCK PREDICATE  Security.fn_securitypredicate(AppUserId) ON dbo.Sales AFTER INSERT
    WITH (STATE = ON);

5.3 Ledger#

Le ledger apporte une preuve cryptographique que les données n'ont pas été falsifiées (y compris par un DBA).

5.4 Data Discovery & Classification#

Intégrée à SQL Database et Managed Instance :

• Discovery & recommendations : le moteur repère les colonnes sensibles ;
• Labeling persistant des colonnes (étiquette + type d'information), stratégie SQL Information Protection (personnalisable dans Defender for Cloud) ou sensitivity labels Microsoft Purview ;
• Audit de la sensibilité : le champ data_sensitivity_information du journal d'audit indique la sensibilité des données renvoyées par chaque requête.

État au 21/10/2026 : le contrôle d'accès par sensitivity labels Microsoft Purview Information Protection pour Azure SQL est retiré (les stratégies existantes ne sont plus appliquées). La classification et l'audit de sensibilité restent disponibles ; Microsoft encourage Microsoft Purview pour la gouvernance avancée.

5.5 Quelle protection pour quel besoin ?#

6. Azure SQL Auditing#

6.1 SQL Database : auditing policy de serveur ou de base#

• Server-level auditing policy : s'applique aux bases existantes et futures du serveur, toujours, quels que soient les réglages de la base.
• Database-level auditing policy : s'ajoute (ne remplace pas) ; la base est alors auditée deux fois.
• Recommandation Microsoft : audit au niveau serveur seulement, sauf besoin d'une destination, d'une rétention ou d'événements différents pour une base précise. Pour les grosses charges OLTP avec beaucoup de bases, l'audit par base accélère l'exploitation des journaux.
• Les copies, restaurations et géoréplications ne conservent pas une database-level auditing policy envoyée vers Log Analytics ou Event Hubs.

Audit action groups par défaut (requêtes, procédures stockées, connexions réussies et échouées) : BATCH_COMPLETED_GROUP, SUCCESSFUL_DATABASE_AUTHENTICATION_GROUP, FAILED_DATABASE_AUTHENTICATION_GROUP.

6.2 Les destinations#

• Vers Log Analytics ou Event Hubs, le service crée un diagnostic setting SQLSecurityAuditEvents_… : s'il est supprimé, l'audit échoue silencieusement → créer une alerte sur la suppression des diagnostic settings.
• Immutable storage possible : l'option « Allow protected append writes » doit être sur Append blobs (ou Block and append blobs) ; la rétention de l'immutability policy doit être plus courte que la rétention de l'audit SQL.
• Si les Outbound networking restrictions du serveur sont actives, autoriser le FQDN du storage account d'audit.
• Limites : champs statement et data_sensitivity_information tronqués à 4 000 caractères ; les tables temporaires de tempdb ne sont pas auditées ; en charge extrême, des événements peuvent manquer.
• Lire les journaux d'audit exige VIEW DATABASE SECURITY AUDIT dans la base.

# Audit de serveur vers Log Analytics (CLI)
az sql server audit-policy update --resource-group rg-data-prd --name sql-app-prd --state Enabled \
  --log-analytics-target-state Enabled \
  --log-analytics-workspace-resource-id /subscriptions/<sub>/resourceGroups/rg-sec-prd/providers/Microsoft.OperationalInsights/workspaces/law-sec-prd

# Terraform : audit de serveur vers Azure Monitor (le paramètre de diagnostic de la base master est créé à part)
resource "azurerm_mssql_server_extended_auditing_policy" "app" {
  server_id              = azurerm_mssql_server.app.id
  log_monitoring_enabled = true
}

// Activité auditée des dernières 24 h, par action, adresse IP cliente et connexion
AzureDiagnostics
| where Category == "SQLSecurityAuditEvents" and TimeGenerated > ago(24h)
| summarize Evenements = count() by action_name_s, client_ip_s, server_principal_name_s
| order by Evenements desc

// Échecs de connexion SQL (groupe FAILED_DATABASE_AUTHENTICATION_GROUP)
AzureDiagnostics
| where Category == "SQLSecurityAuditEvents" and action_name_s == "DATABASE AUTHENTICATION FAILED"
| summarize Echecs = count() by client_ip_s, server_principal_name_s, bin(TimeGenerated, 1h)

6.3 Auditing of Microsoft support operations#

Trace ce que font les ingénieurs du support Microsoft quand ils accèdent à votre serveur pendant une demande de support.

• SQL Database : bascule « Enable Auditing of Microsoft support operations » sur la page Audit du serveur ; mêmes destinations ; requête AzureDiagnostics | where Category == "DevOpsOperationsAudit".
• Managed Instance : créer un audit de serveur séparé avec OPERATOR_AUDIT = ON (cocher la case sur un audit existant le remplace et ne journalise plus que le support) ; catégorie de diagnostic DevOps operations Audit Logs.

6.4 L'audit de SQL Managed Instance#

Managed Instance utilise SQL Server Audit :

-- Vers un conteneur blob : informations d'identification SAS, puis audit, spécification et activation
CREATE CREDENTIAL [https://stauditprd.blob.core.windows.net/sqlaudit]
  WITH IDENTITY = 'SHARED ACCESS SIGNATURE', SECRET = '<jeton SAS sans le ?>';
CREATE SERVER AUDIT [Audit-Prd] TO URL (PATH = 'https://stauditprd.blob.core.windows.net/sqlaudit', RETENTION_DAYS = 90);

-- Ou vers Log Analytics / Event Hubs : paramètre de diagnostic SQLSecurityAuditEvents, puis
CREATE SERVER AUDIT [Audit-Monitor] TO EXTERNAL_MONITOR;

CREATE SERVER AUDIT SPECIFICATION [Spec-Prd] FOR SERVER AUDIT [Audit-Monitor]
  ADD (SUCCESSFUL_LOGIN_GROUP), ADD (FAILED_LOGIN_GROUP), ADD (BATCH_COMPLETED_GROUP) WITH (STATE = ON);
ALTER SERVER AUDIT [Audit-Monitor] WITH (STATE = ON);

• Le jeton SAS expire : le renouveler sinon l'audit échoue (SSMS crée l'information d'identification automatiquement).
• RETENTION_DAYS absent = 0 = conservation illimitée.

7. Defender for Databases#

7.1 Les quatre plans#

Dans Defender for Cloud > Environment settings, le plan Databases active d'un coup quatre plans, facturés séparément (bouton Select types pour choisir) :

Activation : au niveau abonnement (recommandé : les nouvelles ressources sont protégées automatiquement) ou par ressource (désactiver au niveau abonnement puis activer serveur par serveur : Security > Microsoft Defender for Cloud > Enable Microsoft Defender for SQL). Rôle : SQL Security Manager ou server admin, Owner de l'abonnement pour le plan sur machines (il déploie des stratégies).

az security pricing create -n SqlServers --tier standard
az security pricing create -n OpenSourceRelationalDatabases --tier standard

7.2 SQL Vulnerability Assessment#

Analyse en lecture seule fondée sur les bonnes pratiques Microsoft : configurations, autorisations excessives, données sensibles non protégées, firewall rules. Chaque constat donne une correction (souvent un script). On définit une baseline pour accepter les écarts voulus.

Les API classiques de le Vulnerability Assessment et de la protection avancée sont retirées le 16 août 2027 : migrer vers la express configuration. En Terraform : express_vulnerability_assessment_enabled = true sur azurerm_mssql_server.

7.3 Advanced Threat Protection#

Alertes exploitables (détail de l'activité, tactique MITRE ATT&CK, actions recommandées) dans Defender for Cloud, exportables vers Microsoft Sentinel ou un SIEM :

• injection SQL potentielle (y compris une application qui génère une requête défectueuse) ;
• force brute (nombreux échecs avec des identifiants différents) ;
• accès depuis un emplacement, un centre de données ou un principal inhabituel, application potentiellement dangereuse ;
• activité suspecte, par exemple depuis une machine compromise qui parle à un serveur de commande et contrôle.

Le pilotage global (Secure Score, recommandations, conformité) est au chapitre 10.

8. Compléments AZ-500#

8.1 Azure Cosmos DB#

• Désactiver l'authentification par clés (disableLocalAuth = true, option Key-based authentication: Disable à la création) : seule Microsoft Entra authentication reste possible.
• Data plane RBAC propre à Cosmos DB : rôles intégrés Cosmos DB Built-in Data Reader et Cosmos DB Built-in Data Contributor, rôles personnalisés par dataActions (notDataActions non pris en charge) ; ces attributions ne se gèrent pas dans le portail (CLI, PowerShell, Bicep).
• Réseau : IP firewall, réseaux virtuels, private endpoint (zone privatelink.documents.azure.com).
• Defender for Azure Cosmos DB : 7.1.

az resource update --resource-group rg-data-prd --name cosmos-app-prd \
  --resource-type "Microsoft.DocumentDB/databaseAccounts" --set properties.disableLocalAuth=true

8.2 Azure Database for PostgreSQL et MySQL flexible server#

8.3 Sauvegardes et rétention#

8.4 SQL Server on Azure VMs#

• SQL IaaS Agent extension : fait apparaître les recommandations de sécurité sur la ressource SQL virtual machine.
• Defender for SQL servers on machines pour les vulnérabilités et les menaces.
• Authentification Entra (SQL Server 2022 et plus) : la managed identity choisie doit avoir le rôle Directory Readers ou les rôles d'application Graph User.Read.All, GroupMember.Read.All, Application.Read.All.
• Le reste relève de la sécurité des VM : chiffrement de disque, Bastion, JIT (chapitre 08).

9. Labs conseillés#

À faire dans un abonnement de test, avec une base SQL Database du niveau le moins cher (ou serverless).

Lab 1 · Microsoft Entra-only et managed identity

1. Créer un logical server avec un groupe Entra comme Microsoft Entra admin.
2. Se connecter avec SSMS ou Azure Data Studio en Microsoft Entra MFA ; créer CREATE USER [<managed identity>] FROM EXTERNAL PROVIDER et lui donner db_datareader.
3. Activer Microsoft Entra-only ; tenter une connexion avec l'administrateur SQL : refus. SELECT SERVERPROPERTY('IsExternalAuthenticationOnly') renvoie 1.

Lab 2 · Firewall, règle de base et private endpoint

1. Ajouter une firewall rule serveur pour votre IP ; se connecter.
2. Dans une base, sp_set_database_firewall_rule pour une autre IP ; vérifier dans sys.database_firewall_rules.
3. Créer un private endpoint et la zone privatelink.database.windows.net ; depuis une VM du VNet, nslookup <serveur>.database.windows.net renvoie l'IP privée.
4. Passer Public network access sur Disabled : votre poste reçoit l'erreur 47073, la VM se connecte toujours.

Lab 3 · Masquage, RLS et Always Encrypted

1. Masquer une colonne Email avec email(), se connecter avec un utilisateur sans UNMASK : valeur masquée.
2. Créer une stratégie RLS avec filter predicate : chaque utilisateur ne voit que ses lignes, même db_owner.
3. Chiffrer une colonne avec l'assistant Always Encrypted de SSMS (CMK dans Key Vault) ; la lire sans Column Encryption Setting=Enabled : texte chiffré.

Lab 4 · Audit vers Log Analytics

1. Activer l'audit au niveau serveur vers un espace Log Analytics.
2. Provoquer des échecs de connexion (mauvais mot de passe) et quelques requêtes.
3. Lancer la requête KQL de la section 6.2 : les événements DATABASE AUTHENTICATION FAILED apparaissent après quelques minutes.

Lab 5 · Defender for Azure SQL

1. Activer Defender for Azure SQL sur le serveur (express configuration de le Vulnerability Assessment).
2. Lancer une analyse, ouvrir un constat, appliquer le script de correction ou l'ajouter à la baseline.
3. Observer la recommandation disparaître sans nouvelle analyse (comportement de la express configuration).

10. Les pièges d'examen#

11. Scénarios d'entraînement#

1. Une application App Service se connecte à Azure SQL Database avec un compte SQL dont le mot de passe est dans les paramètres de l'application. Le RSSI veut supprimer ce secret et interdire tout compte SQL. Que faire ?

Activer le managed identity d'App Service, définir un groupe Entra comme Microsoft Entra admin du serveur, créer le contained database user CREATE USER [app] FROM EXTERNAL PROVIDER avec les rôles nécessaires, puis activer Microsoft Entra-only authentication (par un SQL Security Manager) et l'imposer à la création des futurs serveurs avec la stratégie Azure Policy en Deny.

2. Le logical server doit n'être joignable que depuis le VNet de production et le site de Lyon (relié par ExpressRoute), sans aucune exposition Internet. Quelle configuration ?

Private endpoint dans le VNet (zone DNS privatelink.database.windows.net reliée et résolue depuis le site), Public network access : Disabled. Pas de règle de IP firewall nécessaire.

3. Une équipe a activé « Allow Azure services and resources to access this server » pour qu'une Function App se connecte. Quel est le risque et quelle alternative ?

La règle 0.0.0.0 laisse passer n'importe quelle ressource Azure, y compris d'autres abonnements et clients. Alternative : VNet integration de la Function App puis virtual network rule (service endpoint Microsoft.Sql) ou private endpoint.

4. La conformité exige que l'entreprise puisse rendre les données illisibles à tout moment, y compris pour Microsoft. Que proposer ?

TDE avec customer-managed key dans un Key Vault (ou Managed HSM) dédié, soft delete et protection contre la purge, server managed identity avec Key Vault Crypto Service Encryption User, rotation automatique. Révoquer l'accès à la clé rend les bases Inaccessibles.

5. Les conseillers du centre d'appels doivent confirmer un client avec les 4 derniers chiffres de sa carte, sans voir le reste. Les développeurs ne doivent rien voir en production. Que faire ?

Dynamic Data Masking : fonction Carte de crédit sur la colonne, aucun UNMASK pour les conseillers ni les développeurs. Si la menace inclut les DBA, ajouter Always Encrypted (le masquage ne les arrête pas).

6. L'équipe sécurité veut tous les événements d'audit de 40 bases dans Microsoft Sentinel, sans double journalisation.

Server-level auditing policy (toutes les bases, y compris les futures) vers Log Analytics (l'espace de travail Sentinel), audit au niveau base désactivé, alerte sur la suppression du diagnostic setting SQLSecurityAuditEvents.

7. Une Managed Instance doit écrire son audit dans un storage account. Quelles étapes ?

Créer un conteneur privé, une SAS (service Blob), puis en T-SQL CREATE CREDENTIAL (URL du conteneur, SAS sans le ?), CREATE SERVER AUDIT … TO URL, une audit specification serveur ou base, et ALTER SERVER AUDIT … WITH (STATE = ON). Renouveler la SAS avant son expiration. (Ou bien TO EXTERNAL_MONITOR avec un diagnostic setting vers Log Analytics.)

8. Le RSSI veut être alerté d'une injection SQL et connaître les droits excessifs sur 200 serveurs Azure SQL et 30 serveurs SQL sur site.

Activer Defender for Azure SQL au niveau abonnement (Vulnerability Assessment en express configuration + protection avancée) et Defender for SQL servers on machines après avoir connecté les serveurs sur site à Azure Arc.

9. Après une rotation manuelle du TDE protector, un administrateur supprime l'ancienne clé du Key Vault. Une restauration à un instant donné d'il y a 10 jours échoue. Pourquoi ?

Les sauvegardes antérieures à la rotation sont chiffrées avec l'ancien protecteur : il fallait conserver toutes les versions de clé. La restaurer depuis le soft delete du Key Vault (d'où l'intérêt de la purge protection).

10. Une application de comptabilité doit prouver aux commissaires aux comptes qu'aucune écriture n'a été modifiée a posteriori, même par un DBA.

Tables ledger (en ajout seul pour le grand livre), automatic digest storage dans un immutable blob storage verrouillé ou Azure Confidential Ledger, et vérification périodique du ledger.

12. Pour aller plus loin (au-delà de l'examen)#

• Conditional Access : l'authentification Entra vers Azure SQL profite de la MFA et de le Conditional Access (chapitre 01) ; à tester sur les comptes d'administration des bases.
• Failover groups et geo-replication : les firewall rules au niveau base et les utilisateurs contenus sont stockés dans la base et la suivent ; vérifier la configuration de sécurité du serveur secondaire (règles serveur, connexions, accès à la clé TDE).
• Outbound networking restrictions du logical server (outbound_network_restriction_enabled) : limite les FQDN que le moteur peut joindre (anti-exfiltration).
• Microsoft Purview : catalogue, classification et gouvernance des données au-delà de la base.
• Azure Policy pour SQL : imposer TLS 1.2, l'audit, Defender, l'accès public désactivé (chapitre 03).
• Hyperscale avec CMK : chaque serveur de pages compte dans la limite par Key Vault (500 au plus), à surveiller quand la base grossit.

13. Fiche à retenir#

• Plan de contrôle = Azure RBAC ; plan de données = utilisateurs et rôles SQL.
• SQL Server Contributor définit le Microsoft Entra admin mais pas « Microsoft Entra-only » ; SQL Security Manager l'inverse.
• Firewall : règles base (T-SQL seulement, prioritaires, portables) et serveur (256 max, master) ; jusqu'à 5 min.
• 0.0.0.0 « Allow Azure services » = tout Azure, autres clients compris.
• Règle VNet = service endpoint Microsoft.Sql ; private endpoint = IP privée + Refuser l'accès public à cocher.
• Connection policy : Redirect (11000-11999) recommandée, Proxy (1433) ; TLS 1.2 minimum.
• Managed Instance : sous-réseau dédié délégué, NSG + route table obligatoires, point public 3342 désactivé par défaut.
• Microsoft Entra-only : Microsoft Entra admin obligatoire, comptes SQL bloqués (non supprimés), Policy Deny à la création.
• CREATE USER [x] FROM EXTERNAL PROVIDER = utilisateur contenu Entra (groupe, managed identity).
• TDE par défaut ; CMK : identité du serveur, wrapKey/unwrapKey, soft delete + purge, perte d'accès → Inaccessible (≈ 10 min, 30 min pour revenir seul).
• Always Encrypted : CEK (dans la base, chiffrée) + CMK (hors base) ; deterministic = égalité ; enclave = LIKE, tri, in-place encryption.
• DDM masque le résultat (pas un chiffrement) ; UNMASK granulaire ; RLS filtre les lignes ; ledger prouve l'intégrité.
• Auditing : policy serveur (toujours appliquée) recommandée ; base en plus = double ; 3 groupes par défaut ; Stockage / Log Analytics / Event Hubs ; rétention 0 = illimitée.
• MI : CREATE SERVER AUDIT TO URL (SAS) ou TO EXTERNAL_MONITOR ; support Microsoft : audit séparé OPERATOR_AUDIT = ON.
• Defender bases de données = 4 plans : Azure SQL, SQL sur machines (VM, Arc), open source (PostgreSQL, MySQL flexible servers, RDS), Cosmos DB (NoSQL seulement).
• VA express (sans stockage, recommandée) ; API classiques retirées le 16/08/2027.

Références#

Toutes lues le 21/10/2026 sur Microsoft Learn :

• Guide d'étude de l'examen SC-500
• Vue d'ensemble des capacités de sécurité d'Azure SQL Database et SQL Managed Instance
• IP firewall rules Azure SQL Database
• Service endpoints et virtual network rules pour Azure SQL Database
• Azure Private Link pour Azure SQL Database
• Paramètres de connectivité (accès public, TLS minimal, connection policy)
• Architecture de connectivité d'Azure SQL Database
• Architecture de connectivité de SQL Managed Instance
• Configurer le public endpoint de SQL Managed Instance
• Configurer l'authentification Microsoft Entra avec Azure SQL
• Microsoft Entra-only authentication avec Azure SQL
• Azure Policy pour Microsoft Entra-only authentication
• TDE avec customer-managed key
• Always Encrypted
• Always Encrypted avec secure enclaves
• Row-Level Security
• Format du journal d'audit SQL Database
• Dynamic Data Masking
• Vue d'ensemble du registre (ledger)
• Gestion des condensats du registre
• Data Discovery & Classification
• Audit d'Azure SQL Database
• Configurer l'audit pour Azure SQL Database
• Stratégie d'audit au niveau du serveur et de la base de données
• Auditing of Microsoft support operations
• Commencer l'audit d'Azure SQL Managed Instance
• Protéger vos bases de données avec Defender for Databases
• Vue d'ensemble de Defender for Azure SQL
• Vulnerability Assessment SQL (configurations express et classique)
• Defender for SQL servers on machines
• Defender for open-source relational databases
• Defender for Azure Cosmos DB
• Cosmos DB : RBAC et Microsoft Entra ID
• Sécuriser Azure Database pour Azure Database for PostgreSQL flexible server
• Sauvegardes à Long-term retention
• Registre Terraform : azurerm_mssql_server, azurerm_mssql_server_extended_auditing_policy (fournisseur hashicorp/azurerm 5.10.0)