Protection étendue de l'authentification avec Reporting Services

La protection étendue est un ensemble d’améliorations apportées aux dernières versions du système d’exploitation Microsoft Windows. La protection étendue améliore la façon dont les applications peuvent protéger les informations d'identification et l'authentification. La fonctionnalité ne fournit pas directement de protection contre des attaques spécifiques comme le transfert d'informations d'identification. Cependant, elle offre une infrastructure aux applications comme Reporting Services afin d'appliquer la protection étendue de l'authentification.

La liaison de service et la liaison de canal figurent parmi les améliorations d'authentification les plus importantes de la protection étendue. La liaison au canal utilise un jeton de liaison au canal (CBT) afin de vérifier que le canal de communication établi entre deux extrémités n’a pas été compromis. La liaison de service utilise les noms de principaux du service (SPN) pour valider la destination prévue de jetons d'authentification. Pour plus d'informations générales sur la protection étendue, consultez Integrated Windows Authentication with Extended Protection(Authentification intégrée de Windows avec protection étendue).

SQL Server Reporting Services (SSRS) prend en charge et applique la protection étendue activée dans le système d'exploitation et configurée dans Reporting Services. Par défaut, Reporting Services accepte les demandes qui spécifient l’authentification Negotiate ou NTLM, et peut donc tirer parti de la prise en charge de la protection étendue dans le système d’exploitation et des fonctionnalités de la protection étendue de Reporting Services.

Activer le chiffrement avec la protection étendue

S'applique à : SQL Server

Pour améliorer la sécurité lorsque vous utilisez Authentification Windows, définissez la protection étendue sur Obligatoire et Forcez le chiffrement sur Oui dans Gestionnaire de configuration SQL Server.

Ces paramètres fournissent la configuration la plus sécurisée pour SQL Server.

Mettez à jour vos chaînes de connexion pour prendre en charge ces modifications.

Pour en savoir plus, consultez :

• Se connecter au moteur de base de données avec la protection étendue
• Configurer le moteur de base de données SQL Server pour le chiffrement des connexions
• TDS 8.0
• Se connecter à SQL Server avec le chiffrement strict

Vue d’ensemble de la protection étendue de Reporting Services

SSRS prend en charge et applique la protection étendue activée dans le système d'exploitation. Si le système d'exploitation ne prend pas en charge la protection étendue ou si la fonctionnalité n'a pas été activée dans le système d'exploitation, la fonctionnalité de protection étendue de Reporting Services ne parvient pas à effectuer l'authentification. Reporting Services Extended Protection nécessite également un certificat TLS/SSL. Pour plus d'informations, consultez Configurer des connexions TLS sur un serveur de rapports en mode natif

Les problèmes courants qui surviennent en raison de modifications des paramètres de protection étendue ou de paramètres incorrectement configurés ne se manifestent pas par des messages d’erreur ou des boîtes de dialogue évidents. Les problèmes liés à la configuration et à la compatibilité de la protection étendue entraînent des échecs d’authentification et des erreurs dans les journaux de suivi de Reporting Services.

Mettre à niveau

• La mise à niveau d’un serveur Reporting Services vers SQL Server 2016 ajoute des paramètres de configuration avec les valeurs par défaut au fichier rsreportserver.config. Si les paramètres étaient déjà présents, l'installation de SQL Server 2016 les conserve dans le fichier rsreportserver.config.

• Quand les paramètres de configuration sont ajoutés au fichier de configuration rsreportserver.config, la fonctionnalité de protection étendue de Reporting Services est désactivée par défaut. Vous devez donc activer la fonctionnalité comme indiqué dans cet article. Pour plus d'informations, consultez la section des paramètres de configuration dans cet article.

• La valeur par défaut du paramètre RSWindowsExtendedProtectionLevel est Off.

• La valeur par défaut du paramètre RSWindowsExtendedProtectionScenario est Proxy.

• Le conseiller de mise à niveau ne vérifie pas que le système d'exploitation ou l'installation actuelle de Reporting Services avec prise en charge de la protection étendue est activée.

Champs non couverts par la protection étendue de Reporting Services

La fonctionnalité de protection étendue de Reporting Services ne prend pas en charge les domaines de fonctionnalités et les scénarios suivants :

• Les auteurs d’extensions de sécurité personnalisées de Reporting Services doivent ajouter la prise en charge de la protection étendue à leur propre extension de sécurité.

• Le fournisseur tiers doit mettre à jour les composants tiers ajoutés ou utilisés par une installation de Reporting Services pour prendre en charge la protection étendue. Pour plus d'informations, contactez le fournisseur tiers.

Recommandations et scénarios de déploiement

Les scénarios suivants illustrent plusieurs déploiements et topologies ainsi que la configuration recommandée afin de les sécuriser par la protection étendue Reporting Services.

Direct

Ce scénario décrit la connexion directe à un serveur de rapports, par exemple, un environnement d'intranet.

Scénario	Schéma du scénario	Procédure de sécurisation
Communication TLS directe. Le serveur de rapports applique la liaison du canal entre le client et le serveur de rapports.	1) Application cliente 2) Serveur de rapports	Définissez RSWindowsExtendedProtectionLevel sur Allow ou Require. Affectez la valeur RSWindowsExtendedProtectionScenario à Direct. – La liaison de service n'est pas nécessaire, car le canal TLS est utilisé pour la liaison de canal.
Communication HTTP directe. Le serveur de rapports applique la liaison de service entre le client et le serveur de rapports.	1) Application cliente 2) Serveur de rapports	Définissez RSWindowsExtendedProtectionLevel sur Allow ou Require. Affectez la valeur RSWindowsExtendedProtectionScenario à Any. -Il n’existe aucun canal TLS et, par conséquent, toute application de la liaison de canal est impossible. -La liaison de service peut être validée, mais ne constitue pas une ligne de défense parfaite sans la liaison de canal ; la liaison de service à elle seule se contente de bloquer les menaces de base.

Équilibrage de la charge réseau et proxy

Les applications clientes se connectent à un périphérique ou un logiciel qui effectue une connexion TLS et transmet les informations d'identification au serveur en vue de l'authentification, par exemple, Internet, un réseau extranet ou intranet sécurisé. Le client se connecte à un serveur proxy ou tous les clients utilisent un proxy.

La situation est la même lorsque vous utilisez un périphérique d'équilibrage de la charge réseau.

Scénario	Schéma du scénario	Procédure de sécurisation
Communications HTTP. Le serveur de rapports applique la liaison de service entre le client et le serveur de rapports.	1) Application cliente 2) Serveur de rapports 3) Proxy	Définissez RSWindowsExtendedProtectionLevel sur Allow ou Require. Affectez la valeur RSWindowsExtendedProtectionScenario à Any. -Il n’existe aucun canal TLS et, par conséquent, toute application de la liaison de canal est impossible. -Le serveur de rapports doit être configuré de façon à identifier le serveur proxy pour s’assurer que la liaison de service est correctement appliquée.
Communications HTTP. Le serveur de rapports impose la liaison de canal entre le client et le proxy, ainsi que la liaison de service entre le client et le serveur de rapports.	1) Application cliente 2) Serveur de rapports 3) Proxy	Définir RSWindowsExtendedProtectionLevel à Allow ou Require. Affectez la valeur RSWindowsExtendedProtectionScenario à Proxy. -Le canal TLS vers le proxy est disponible ; par conséquent, la liaison de canal au proxy peut être appliquée. -La liaison de service est également applicable. – Le nom de proxy doit être connu du serveur de rapports et l'administrateur du serveur de rapports doit lui créer une réservation d'URL, avec un en-tête d'hôte ou encore configurer le nom de proxy dans l'entrée BackConnectionHostNames du Registre Windows.
Communications HTTPS indirectes avec un proxy sécurisé. Le serveur de rapports applique la liaison de canal entre le client et le proxy et la liaison de service entre le client et le serveur de rapports.	1) Application cliente 2) Serveur de rapports 3) Proxy	Définir RSWindowsExtendedProtectionLevel à Allow ou Require. Affectez la valeur RSWindowsExtendedProtectionScenario à Proxy. -Le canal TLS vers le proxy est disponible ; par conséquent, la liaison de canal au proxy peut être appliquée. -La liaison de service est également applicable. – Le nom de proxy doit être connu du serveur de rapports et l'administrateur du serveur de rapports doit lui créer une réservation d'URL, avec un en-tête d'hôte ou encore configurer le nom de proxy dans l'entrée BackConnectionHostNames du Registre Windows.

Passerelle

Ce scénario décrit des applications clientes qui se connectent à un dispositif ou à un logiciel qui effectue la connexion TLS et authentifie l'utilisateur. Ensuite, le périphérique ou le logiciel emprunte le contexte de l'utilisateur ou celui d'un autre utilisateur avant d'envoyer une requête au serveur de rapports.

Scénario	Schéma du scénario	Procédure de sécurisation
Communication HTTP indirecte. La passerelle applique la liaison de canal entre le client et la passerelle. Il existe une passerelle menant à la liaison de service du serveur de rapports.	1) Application cliente 2) Serveur de rapports 3) Appareil passerelle	Définissez RSWindowsExtendedProtectionLevel sur Allow ou Require. Affectez la valeur RSWindowsExtendedProtectionScenario à Any. -La liaison de canal entre le client et le serveur de rapports est impossible, car la passerelle emprunte l’identité d’un contexte, créant ainsi un autre jeton NTLM. – Il n'existe aucune connexion TLS entre la passerelle et le serveur de rapports ; la liaison de canal ne peut donc pas être appliquée. -La liaison de service est applicable. -Votre administrateur doit configurer le périphérique de passerelle pour l’application de la liaison de canal.
Communications HTTPS indirectes avec une passerelle sécurisée. La passerelle applique la liaison de canal entre le client et la passerelle et le serveur de rapports applique la liaison de canal entre la passerelle et le serveur de rapports.	1) Application cliente 2) Serveur de rapports 3) Appareil passerelle	Définissez RSWindowsExtendedProtectionLevel sur Allow ou Require. Affectez la valeur RSWindowsExtendedProtectionScenario à Direct. -La liaison de canal entre le client et le serveur de rapports est impossible, car la passerelle emprunte l’identité d’un contexte, créant ainsi un autre jeton NTLM. -La connexion TLS entre la passerelle et le serveur de rapports signifie que la liaison de canal peut être appliquée. -La liaison de service n’est pas obligatoire. -Votre administrateur doit configurer le périphérique de passerelle pour l’application de la liaison de canal.

Combinaison

Ce scénario décrit les environnements Extranet ou Internet où le client connecte un proxy en combinaison avec un environnement intranet où un client se connecte au serveur de rapports.

Scénario	Schéma du scénario	Procédure de sécurisation
Les accès indirects et directs du client au serveur de rapports fonctionnent sans TLS pour les connexions entre le client et le proxy ou le client et le serveur de rapports.	1) Application cliente 2) Serveur de rapports 3) Proxy 4) Application cliente	Définissez RSWindowsExtendedProtectionLevel sur Allow ou Require. Affectez la valeur RSWindowsExtendedProtectionScenario à Any. -La liaison de service entre le client et le serveur de rapports est applicable. – Le nom de proxy doit être connu du serveur de rapports et l'administrateur du serveur de rapports doit lui créer une réservation d'URL, avec un en-tête d'hôte ou encore configurer le nom de proxy dans l'entrée BackConnectionHostNames du Registre Windows.
Accès indirects et directs du client au serveur de rapports sur lequel le client établit une connexion TLS vers le proxy ou le serveur de rapports.	1) Application cliente 2) Serveur de rapports 3) Proxy 4) Application cliente	Définissez RSWindowsExtendedProtectionLevel sur Allow ou Require. Affectez la valeur RSWindowsExtendedProtectionScenario à Proxy. -Channel Binding peut être utilisé. – Le nom de proxy doit être connu du serveur de rapports et l'administrateur du serveur de rapports doit lui créer une réservation d'URL, avec un en-tête d'hôte ou encore configurer le nom de proxy dans une entrée BackConnectionHostNames du Registre Windows.

Configuration de la protection étendue de Reporting Services

Le fichier rsreportserver.config contient les valeurs de configuration qui contrôlent le comportement de la protection étendue de Reporting Services.

Pour plus d'informations sur l'utilisation et la modification du fichier rsreportserver.config, consultez le fichier de configuration RsReportServer.config. Les paramètres de protection étendue peuvent également être modifiés et examinés à l'aide d'API WMI. Pour plus d'informations, consultez Méthode SetExtendedProtectionSettings (WMI MSReportServer_ConfigurationSetting).

Si la validation des paramètres de configuration échoue, les types d'authentification RSWindowsNTLM, RSWindowsKerberos et RSWindowsNegotiate sont désactivés sur le serveur de rapports.

Paramètres de configuration pour la protection étendue de Reporting Services

Le tableau suivant donne des informations sur les paramètres de configuration qui figurent dans le fichier rsreportserver.config de protection étendue.

Exemples d'entrées dans le fichier de configuration rsreportserver.config :

<Authentication>  
         <RSWindowsExtendedProtectionLevel>Allow</RSWindowsExtendedProtectionLevel>  
         <RSWindowsExtendedProtectionScenario>Proxy</RSWindowsExtendedProtectionLevel>  
</Authentication>  

Liaison de service et SPN inclus

La liaison de service utilise les noms principaux du service (SPN) pour valider la destination prévue des jetons d'authentification. Reporting Services utilise les informations de réservation d’URL existantes pour générer la liste des SPN considérés comme valides. Les informations de réservation d'URL pour la validation des réservations SPN et URL permettent aux administrateurs système de gérer les deux à la fois à partir d'un seul emplacement.

La liste des SPN valides est mise à jour lorsque l'une des actions suivantes se produit :

• le serveur de rapports démarre.
• Les paramètres de configuration de la protection étendue sont modifiés.
• Le domaine d'application est recyclé.

La liste valide des SPN est spécifique à chaque application. Par exemple, Report Manager et Report Server ont chacun une liste différente de SPN valides calculée.

Les facteurs suivants déterminent les SPN valides calculés pour une application :

• Réservations d'URL.

• Chaque SPN récupéré depuis le contrôleur de domaine pour le compte de service associé à Reporting Services.

• Si une réservation d'URL inclut des caractères génériques (« * » ou « + »), le serveur de rapports ajoute chaque entrée de la collection d'hôtes.

Héberge les sources de collecte.

Le tableau suivant répertorie les sources potentielles pour la collection Hosts.

Pour plus d'informations, consultez Inscrire un nom de principal du service (SPN) pour un serveur de rapports et À propos des réservations et de l'inscription d'URL (Gestionnaire de configuration du serveur de rapports).

Contenu connexe

• Se connecter au moteur de base de données avec la protection étendue
• Vue d'ensemble de la protection étendue de l'authentification
• Authentification intégrée de Windows avec protection étendue
• Avis de sécurité Microsoft : Protection étendue de l’authentification
• Journal des traces du service de serveur de rapports
• Fichier de configuration RsReportServer.config
• Méthode ConfigurationSetting - SetExtendedProtectionSettings
• Essayez de poser une question dans le forum Reporting Services