Pourquoi utiliser des certificats personnalisés?

Chaque installation de Tableau Server n’a pas besoin de certificats personnalisés, mais pour les entreprises qui doivent respecter des exigences de conformité réglementées de l’industrie (FIPS par exemple), la possibilité d’utiliser des certificats personnalisés à la place des certificats auto-signés est cruciale. Ces étapes peuvent également être nécessaires pour résoudre les problèmes détectés lors des analyses de sécurité qui signalent la présence de certificats internes auto-signés. Vos équipes informatiques et de sécurité devraient vous indiquer si vous avez besoin d’utiliser des certificats personnalisés.

Services prenant en charge les certificats personnalisés

Les services internes suivants prennent en charge les certificats personnalisés. Utilisez le nom du service avec l’option --name de tsm security internal-cert set et tsm security internal-cert reset. Pour voir les noms de service disponibles, exécutez tsm security internal-cert list sans l’option --name.

• TLS simple (certificat de serveur et clé, avec une chaîne facultative) :

  apiGateway, gatewayInternal, hyper, jmx, thrift, tsigLogs, relationshipService, recommendationsService, vizportalMetadataApi, et backgrounderMetadataApi

• TLS mutuel (mTLS), qui nécessite un certificat client et une clé en plus du certificat du serveur :

  activemqMTLS, coordinationService

  Remarque : Le service de coordination peut également être configuré avec sa propre commande si vous choisissez d’utiliser un certificat séparé à cette fin. Pour plus d’informations, consultez (Facultatif) Configuration d’un certificat personnalisé séparé pour le service de coordination ci-dessous.

En outre, tsm security internal-cert set-all gère les sous-systèmes préexistants suivants :

• Référentiel SSL (PostgreSQL), Contrôleur TSM SSL et OpenSearch (Serveur d’indexation et de recherche).

  Lorsque vous utilisez set-all, le certificat du serveur est mappé aux certificats de nœud et de service, le certificat client est mappé au client ActiveMQ et à l’administrateur OpenSearch, et la chaîne est mappée à l’autorité de certification OpenSearch.

Exigences en matière de certificat

Les certificats et les clés que vous fournissez à ces commandes doivent répondre aux exigences suivantes :

• Les certificat doivent être des certificats X.509 valides codés au format PEM. Les clés privées doivent être au format PKCS#1 ou PKCS#8.

• Les algorithmes de clé RSA et ECC (EC/ECDSA) sont pris en charge. Les clés DSA sont rejetées.

• Les clés chiffrées sont prises en charge. Utilisez les options --passphrase et --client-passphrase pour transmettre la phrase de passe.

• Ce n’est pas obligatoire de fournir un fichier de chaîne, mais la plupart des déploiements en requièrent un. Pour une autorité de certification (CA) privée ou interne, la CA racine doit être incluse dans la chaîne. La CA racine ne peut être omise que si le certificat a été émis par une CA publique connue qui est déjà approuvée par la JVM. La CA racine doit également être installée dans le système d’exploitation et le magasin de confiance Java sur tous les nœuds.

• Vérification du nom d’hôte : le certificat du contrôleur TSM doit inclure le nom de domaine qualifié complet du nœud du contrôleur (FQDN) en tant que nom commun (CN) ou en tant que nom alternatif du sujet DNS (SAN), par exemple, DNS:<value returned by the Linux hostname command>. Cela seul permet la validation. Les autres certificats internes ne valident pas les noms d’hôte à ce stade. Pour que le certificat reste valide lorsque le contrôleur TSM se déplace vers un nœud différent, émettez le certificat avec des SAN qui couvrent chaque nœud du groupement pouvant exécuter le contrôleur, ou utilisez un SAN générique pour le domaine partagé (par exemple, DNS:*.corp.example.com).

• Utilisation étendue des clés (EKU) : ne définissez pas l’EKU sur serverAuth ni sur clientAuth uniquement. Vous pouvez laisser l’EKU non définie ou la définir sur les deux valeurs, mais pas sur une individuellement.

La fonctionnalité de certificats personnalisés Tableau Server introduit un certain nombre de nouvelles commandes d’interface en ligne de commande TSM. Celles-ci permettent aux administrateurs de désigner les certificats que Tableau Server doit utiliser pour la communication entre les services internes. Les nouvelles commandes incluent une série de sous-commandes sous tsm security internal-cert, ainsi qu’une série similaire de sous-commandes sous tsm security coordination-service-internal-cert, qui sont spécifiques au service de coordination.