Méthodes d'authentification pour votre serveur

L'accès à une instance ou à une base de données nécessite d'abord que l'utilisateur soit authentifié. Le type d'authentification de chaque instance détermine comment et où un utilisateur sera vérifié.

Important: Le type d'authentification DATA_ENCRYPT est obsolète et pourrait être supprimé dans une édition ultérieure. Pour crypter les données en transit entre les clients et les bases de données, nous vous recommandons d'utiliser la fonction de cryptage de la base de données Db2 les bases de données, nous vous recommandons d'utiliser la prise en charge par le système de base de données de Transport Layer Security (TLS) Db2 système de base de données de Transport Layer Security (TLS). Pour plus d'informations, voir Chiffrement des données en transit

Le type d'authentification est stocké dans le fichier de configuration sur le serveur. Il est initialement défini lors de la création de l'instance. Il existe un type d'authentification par instance, qui couvre l'accès à ce serveur de base de données et à toutes les bases de données sous son contrôle.

Si vous prévoyez d'accéder à des sources de données à partir d'une base de données fédérée, vous devez prendre en compte le traitement de l'authentification de la source de données et les définitions des types d'authentification fédérée.

Changement d'utilisateur sur une connexion sécurisée explicite

Pour les applications CLI/ODBC et XA CLI/ODBC , le mécanisme d'authentification utilisé lors du traitement d'une demande de changement d'utilisateur nécessitant une authentification est le même que celui utilisé pour établir à l'origine la connexion sécurisée elle-même. Par conséquent, tous les autres attributs de sécurité négociés (par exemple, algorithme de chiffrement, clés de chiffrement et noms de plug-in) utilisés lors de l'établissement de la connexion sécurisée explicite sont supposés être identiques pour toute authentification requise pour une demande de changement d'utilisateur sur cette connexion sécurisée. Les applications Java™ permettent de modifier la méthode d'authentification lors d'une demande de changement d'utilisateur (à l'aide d'une propriété de source de données).

Etant donné qu'un objet de contexte sécurisé peut être défini de sorte que le changement d'utilisateur sur une connexion sécurisée ne nécessite pas d'authentification, afin de tirer pleinement parti du changement d'utilisateur sur une fonction de connexion sécurisée explicite, les plug-in de sécurité écrits par l'utilisateur doivent pouvoir:
  • Accepter un jeton d'ID utilisateur uniquement
  • Renvoyer un Db2® d'autorisation valide pour cet identifiant d'utilisateur
Remarque: Une connexion sécurisée explicite ne peut pas être établie si le type d'authentification CLIENT est actif.

Types d'authentification fournis

Les types d'authentification suivants sont fournis:
SERVER
Indique que l'authentification se produit sur le serveur via le mécanisme de sécurité en vigueur pour cette configuration, par exemple, via un module de plug-in de sécurité. Le mécanisme de sécurité par défaut est que si un ID utilisateur et un mot de passe sont spécifiés lors de la tentative de connexion ou de connexion, ils sont envoyés au serveur et comparés aux combinaisons d'ID utilisateur et de mot de passe valides sur le serveur pour déterminer si l'utilisateur est autorisé à accéder à l'instance.
Remarque: Le code du serveur détecte si une connexion est locale ou distante. Pour les connexions locales, lorsque l'authentification est SERVER, un ID utilisateur et un mot de passe ne sont pas requis pour que l'authentification aboutisse.
SERVER_ENCRYPT
Indique que le serveur accepte les schémas d'authentification SERVER chiffrés. Si l'authentification du client n'est pas spécifiée, le client est authentifié à l'aide de la méthode sélectionnée sur le serveur. L'ID utilisateur et le mot de passe sont chiffrés lorsqu'ils sont envoyés sur le réseau du client au serveur.
Lorsque la méthode d'authentification négociée entre le client et le serveur est SERVER_ENCRYPT, vous pouvez choisir de chiffrer l'ID utilisateur et le mot de passe à l'aide d'un algorithme AES (Advanced Encryption Standard) 256 bits. Pour ce faire, définissez le paramètre de configuration du gestionnaire de base de données alternate_auth_enc . Ce paramètre de configuration possède trois valeurs:
  • NOT_SPECIFIED (valeur par défaut) signifie que le serveur accepte l'algorithme de chiffrement proposé par le client, y compris un algorithme AES 256 bits.
  • AES_CMP signifie que si le client qui se connecte propose le chiffrement DES mais que seul le chiffrement AES est pris en charge, le serveur renégocie en faveur du chiffrement AES.
  • AES_ONLY signifie que le serveur accepte uniquement le chiffrement AES. Si le client ne prend pas en charge ce chiffrement, la connexion est rejetée.

Le chiffrement AES peut être utilisé uniquement lorsque la méthode d'authentification négociée entre le client et le serveur est SERVER_ENCRYPT.

JETON_CHIFFREMENT_SERVEUR
Indique que le serveur accepte l'authentification par jeton ou les schémas d'authentification SERVER chiffrés.

Si l'authentification du client est TOKEN, le client est authentifié à l'aide de l'authentification par jeton.

Si l'authentification du client est SERVER_ENCRYPT, le client est authentifié à l'aide d'un ID utilisateur et d'un mot de passe chiffré.

Si l'authentification du client n'est pas spécifiée, le client utilise un type d'authentification dépendant du type de données d'identification fourni.

Pour les autres types d'authentification, une erreur d'authentification est renvoyée.

Cette valeur est valide uniquement pour SRVCON_AUTH et ne peut pas être spécifiée pour AUTHENTICATION. Le type d'authentification du client ne peut pas être spécifié en tant que SERVER_ENCRYPT_TOKEN.

CLIENT
Attention: avec l'édition de Db2 11.5.9, le type d'authentification CLIENT est obsolète. N'utilisez pas ce type d'authentification à l'avenir, car il n'est pas sécurisé dans de nombreuses situations et pourrait être supprimé dans une version ultérieure.
Indique que l'authentification a lieu sur la partition de base de données où l'application est appelée à l'aide de la sécurité du système d'exploitation. L'ID utilisateur et le mot de passe spécifiés lors d'une tentative de connexion ou de connexion sont comparés aux combinaisons d'ID utilisateur et de mot de passe valides sur le noeud client afin de déterminer si l'ID utilisateur est autorisé à accéder à l'instance. Aucune autre authentification ne sera effectuée sur le serveur de base de données. Cela est parfois appelé connexion unique.

Si l'utilisateur effectue une connexion locale ou client, il n'est connu que du poste de travail client local.

Si l'instance distante possède l'authentification CLIENT, deux autres paramètres déterminent le type d'authentification final: trust_allclnts et trust_clntauth.

Sécurité de niveau CLIENT pour les clients TRUSTED uniquement:

Les clients de confiance sont des clients dotés d'un système de sécurité local fiable.

Lorsque le type d'authentification CLIENT a été sélectionné, une option supplémentaire peut être sélectionnée pour la protection contre les clients dont l'environnement d'exploitation ne possède pas de sécurité inhérente.

Pour vous protéger contre les clients non sécurisés, l'administrateur peut sélectionner l'authentification de client sécurisé en définissant le paramètre trust_allclnts sur NO. Cela implique que toutes les plateformes sécurisées peuvent authentifier l'utilisateur pour le compte du serveur. Les clients non dignes de confiance sont authentifiés sur le serveur et doivent fournir un ID utilisateur et un mot de passe. Vous utilisez le paramètre de configuration trust_allclnts pour indiquer si vous faites confiance aux clients. La valeur par défaut de ce paramètre est YES.

Remarque: il est possible de faire confiance à tous les clients (trust_allclnts est YES) mais certains de ces clients sont des clients qui ne disposent pas d'un système de sécurité natif pour l'authentification.

Vous pouvez également souhaiter effectuer l'authentification sur le serveur même pour les clients de confiance. Pour indiquer où valider les clients de confiance, utilisez le paramètre de configuration trust_clntauth . La valeur par défaut de ce paramètre est CLIENT.

Remarque: Pour les clients de confiance uniquement, si aucun ID utilisateur ou mot de passe n'est explicitement fourni lors de la tentative de connexion ou de ATTACH, la validation de l'utilisateur s'effectue au niveau du client. Le paramètre trust_clntauth est utilisé uniquement pour déterminer où valider les informations fournies dans les clauses USER ou USING.

Pour se protéger contre tous les clients, y compris les clients JCC de type 4 sous z/OS® et System i, mais à l'exclusion des clients Db2 natifs sous z/OS, OS/390®, VM, VSE et System i, définissez le paramètre 'trust_allclnts sur DRDAONLY. Seuls ces clients sont dignes de confiance pour effectuer une authentification côté client. Tous les autres clients doivent fournir un ID utilisateur et un mot de passe à authentifier par le serveur.

Le paramètre trust_clntauth est utilisé pour déterminer où les clients mentionnés précédemment sont authentifiés: si trust_clntauth est défini sur CLIENT, l'authentification a lieu sur le client. Si trust_clntauth est SERVER, l'authentification est effectuée sur le client lorsqu'aucun ID utilisateur et mot de passe ne sont fournis et sur le serveur lorsqu'un ID utilisateur et un mot de passe sont fournis.

Tableau 1. Modes d'authentification utilisant les combinaisons de paramètres TRUST_ALLCLNTS et TRUST_CLNTAUTH.
trust _ allclnts trust _ clntauth Authentification non sécurisée du client DRDA (pas d'ID utilisateur ni de mot de passe) Authentification non sécurisée du client DRDA (avec ID utilisateur et mot de passe) Tication automatique du client non DRDA sécurisé (pas d'ID utilisateur et de mot de passe) Tication automatique du client non DRDA sécurisé (avec ID utilisateur et mot de passe) Authentification automatique du client DRDA (pas d'ID utilisateur et de mot de passe) Authentification automatique du client DRDA (avec ID utilisateur et mot de passe)
OUI CLIENT CLIENT CLIENT CLIENT CLIENT CLIENT CLIENT
OUI SERVER CLIENT SERVER CLIENT SERVER CLIENT SERVER
NO CLIENT SERVER SERVER CLIENT CLIENT CLIENT CLIENT
NO SERVER SERVER SERVER CLIENT SERVER CLIENT SERVER
DRDAONLY CLIENT SERVER SERVER SERVER SERVER CLIENT CLIENT
DRDAONLY SERVER SERVER SERVER SERVER SERVER CLIENT SERVER
DATA_ENCRYPT
Le serveur accepte les schémas d'authentification SERVER chiffrés et le chiffrement des données utilisateur. L'authentification fonctionne de la même manière que celle affichée avec SERVER_ENCRYPT. L'ID utilisateur et le mot de passe sont chiffrés lorsqu'ils sont envoyés sur le réseau du client au serveur.

Les données utilisateur suivantes sont chiffrées lors de l'utilisation de ce type d'authentification:

  • Instructions SQL et XQuery.
  • Données de variable de programme SQL.
  • Données de sortie provenant du traitement par le serveur d'une instruction SQL ou XQuery et incluant une description des données.
  • Tout ou partie des données de l'ensemble de réponses résultant d'une requête.
  • Flux de données LOB (Large Object).
  • Descripteurs SQLDA.
DATA_ENCRYPT_CMP
Le serveur accepte les schémas d'authentification SERVER chiffrés et le chiffrement des données utilisateur. En outre, ce type d'authentification permet la compatibilité avec les produits de niveau inférieur qui ne prennent pas en charge le type d'authentification DATA_ENCRYPT. Ces produits sont autorisés à se connecter avec le type d'authentification SERVER_ENCRYPT et sans chiffrer les données utilisateur. Les produits prenant en charge le nouveau type d'authentification doivent l'utiliser. Ce type d'authentification est uniquement valide dans le fichier de configuration du gestionnaire de base de données du serveur et n'est pas valide lorsqu'il est utilisé dans la commande CATALOG DATABASE .
KERBEROS
Utilisé lorsque le client et le serveur Db2 se trouvent sur des systèmes d'exploitation qui prennent en charge le protocole de sécurité Kerberos . Le protocole de sécurité Kerberos effectue l'authentification en tant que service d'authentification tiers en utilisant la cryptographie classique pour créer une clé secrète partagée. Cette clé devient les données d'identification d'un utilisateur et est utilisée pour vérifier l'identité des utilisateurs lors de toutes les demandes de services réseau ou locaux. La clé élimine la nécessité de transmettre le nom d'utilisateur et le mot de passe sur le réseau sous forme de texte en clair. L'utilisation du protocole de sécurité Kerberos permet l'utilisation d'une connexion unique à un serveur de base de données Db2 distant. Le type d'authentification KERBEROS est pris en charge sur différents systèmes d'exploitation. Pour plus d'informations, voir la section relative aux informations connexes.

L'authentification Kerberos fonctionne comme suit:

  1. Un utilisateur qui se connecte à la machine client à l'aide d'un compte de domaine s'authentifie auprès du centre de distribution de clés (KDC) Kerberos sur le contrôleur de domaine. Le centre de distribution de clés émet un ticket d'octroi d'autorisations (TGT) pour le client.
  2. Lors de la première phase de la connexion, le serveur envoie au client le nom du principal cible, qui est le nom du compte de service pour le service de serveur de base de données Db2 . En utilisant le nom principal cible du serveur et le ticket d'octroi de cible, le client demande un ticket de service auprès du service d'octroi de ticket (TGS) qui se trouve également sur le contrôleur de domaine. Si le ticket d'octroi de ticket du client et le nom du principal cible du serveur sont valides, TGS émet un ticket de service pour le client. Le nom principal enregistré dans le répertoire des bases de données peut être spécifié sous la forme name/instance@REALM. (Ceci s'ajoute aux formats DOMAIN\userID etxxx.xxx.com acceptés sous Windows)
  3. Le client envoie ce ticket de service au serveur à l'aide du canal de communication (qui peut être, par exemple, TCP/IP).
  4. Le serveur valide le ticket serveur du client. Si le ticket de service du client est valide, l'authentification est terminée.

Il est possible de cataloguer les bases de données sur la machine client et de spécifier explicitement le type d'authentification Kerberos avec le nom de principal cible du serveur. De cette manière, la première phase de la connexion peut être contournée.

Si un ID utilisateur et un mot de passe sont spécifiés, le client demande le ticket d'octroi de ticket pour ce compte utilisateur et l'utilise pour l'authentification.

JETON_KERBEROS_TOKEN
Indique que le serveur accepte l'authentification par jeton ou l'authentification Kerberos .

Si l'authentification du client est TOKEN, le client est authentifié à l'aide de l'authentification par jeton.

Si l'authentification du client est Kerberos, le client est authentifié à l'aide du système de sécurité Kerberos .

Si l'authentification du client n'est pas spécifiée, le client utilise un type d'authentification dépendant du type de données d'identification fourni. X

Si l'authentification du client n'est pas spécifiée, le client utilise un type d'authentification dépendant du type de données d'identification fourni.

Pour les autres types d'authentification, une erreur d'authentification est renvoyée.

Cette valeur est valide uniquement pour SRVCON_AUTH et ne peut pas être spécifiée pour AUTHENTICATION. Le type d'authentification du client ne peut pas être spécifié en tant que KERBEROS_TOKEN.

CHIFFRE_SERVEUR_KRB
Indique que le serveur accepte l'authentification KERBEROS ou les schémas d'authentification SERVER chiffrés. Si l'authentification du client est KERBEROS, le client est authentifié à l'aide du système de sécurité Kerberos . Si l'authentification du client est SERVER_ENCRYPT, le client est authentifié à l'aide d'un ID utilisateur et d'un mot de passe de chiffrement. Si l'authentification du client n'est pas spécifiée, le client utilisera Kerberos s'il est disponible, sinon il utilisera le chiffrement de mot de passe. Pour les autres types d'authentification client, une erreur d'authentification est renvoyée. Le type d'authentification du client ne peut pas être spécifié en tant que KRB_SERVER_ENCRYPT
Remarque: Les types d'authentification Kerberos sont pris en charge sur les clients et les serveurs s'exécutant sur des systèmes d'exploitation spécifiques. Pour plus d'informations, voir la section relative aux informations connexes. Pour les systèmes d'exploitation Windows, les machines client et serveur doivent appartenir au même domaine Windows ou à des domaines sécurisés. Ce type d'authentification doit être utilisé lorsque le serveur prend en charge Kerberos et que certaines, mais pas toutes, des machines client prennent en charge l'authentification Kerberos .
KRB_SVR_ENC_TOKEN
Indique que le serveur accepte l'authentification par jeton, l'authentification Kerberos ou les schémas d'authentification SERVER chiffrés. Voir la description de KRB_SERVER_ENCRYPT pour plus d'informations sur le comportement de Kerberos et de SERVER_ENCRYPT. Cette valeur est valide uniquement pour SRVCON_AUTH et ne peut pas être spécifiée pour AUTHENTICATION. Le type d'authentification du client ne peut pas être spécifié en tant que KRB_SVR_ENC_TOKEN.
GSSPLUGIN
Indique que le serveur accepte l'authentification par jeton, l'authentification Kerberos ou les schémas d'authentification SERVER chiffrés. Pour plus d'informations sur le comportement de Kerberos et de SERVER_ENCRYPT , voir la description de KRB_SERVER_ENCRYPT . Cette valeur est valide uniquement pour SRVCON_AUTH et ne peut pas être spécifiée pour AUTHENTICATION. Le type d'authentification du client ne peut pas être spécifié en tant que KRB_SVR_ENC_TOKEN.
JETON_PLUGIN_GSSS
Indique que le serveur accepte l'authentification par jeton ou l'authentification par plug-in.

Si l'authentification du client est TOKEN, le client est authentifié à l'aide de l'authentification par jeton.

Si l'authentification du client est GSSPLUGIN, le client est authentifié à l'aide du premier plug-in pris en charge par le client dans la liste des plug-in pris en charge par le serveur.

Si l'authentification du client n'est pas spécifiée, le client utilise un type d'authentification dépendant du type de données d'identification fourni.

Pour les autres types d'authentification, une erreur d'authentification est renvoyée.

Cette valeur est valide uniquement pour SRVCON_AUTH et ne peut pas être spécifiée pour AUTHENTICATION. Le type d'authentification du client ne peut pas être spécifié en tant que GSSPLUGIN_TOKEN.

GSS_SERVER_ENCRYPT
Indique que le serveur accepte l'authentification par plug-in ou les schémas d'authentification de serveur chiffrés. Si l'authentification du client se produit via un plug-in, le client est authentifié à l'aide du premier plug-in pris en charge par le client dans la liste des plug-in pris en charge par le serveur.

Si l'authentification client n'est pas spécifiée et qu'une connexion implicite est effectuée (c'est-à-dire que le client ne fournit pas d'ID utilisateur et de mot de passe lors de l'établissement de la connexion), le serveur renvoie une liste de plug-in pris en charge par le serveur, le schéma d'authentification Kerberos (si l'un des plug-in de la liste est basé sur Kerberos) et le schéma d'authentification de serveur chiffré. Le client est authentifié à l'aide du premier plug-in pris en charge qui se trouve dans le répertoire des plug-in client. Si le client ne prend en charge aucun des plug-in de la liste, il est authentifié à l'aide du schéma d'authentification Kerberos . Si le client ne prend pas en charge le schéma d'authentification Kerberos , il est authentifié à l'aide du schéma d'authentification de serveur chiffré et la connexion échoue en raison d'un mot de passe manquant. Un client prend en charge le schéma d'authentification Kerberos s'il existe un plug-in Kerberos fourni par Db2 pour le système d'exploitation, ou un plug-in Kerberosest spécifié pour le paramètre de configuration du gestionnaire de base de données srvcon_gssplugin_list .

Si l'authentification du client n'est pas spécifiée et qu'une connexion explicite est établie (c'est-à-dire que l'ID utilisateur et le mot de passe sont fournis), le type d'authentification est équivalent à SERVER_ENCRYPT. Dans ce cas, le choix de l'algorithme de chiffrement utilisé pour chiffrer l'ID utilisateur et le mot de passe dépend de la définition du paramètre de configuration du gestionnaire de base de données alternate_auth_enc .

JETON_SVR_GSS_ENC_TOKEN
Indique que le serveur accepte l'authentification par jeton, l'authentification GSSPLUGIN ou les schémas d'authentification SERVER chiffrés. Pour plus d'informations sur le comportement de GSSPLUGIN et de SERVER_ENCRYPT, voir la description de GSS_SERVER_ENCRYPT .

Cette valeur est valide uniquement pour SRVCON_AUTH et ne peut pas être spécifiée pour AUTHENTICATION. Le type d'authentification du client ne peut pas être spécifié en tant que GSS_SVR_ENC_TOKEN.

Authentification par jeton
Lorsque le paramètre de configuration du gestionnaire de base de données SRVCON_AUTH a été configuré avec l'un des paramètres SERVER_ENCRYPT_TOKEN, KERBEROS_TOKEN, KRB_SVR_ENC_TOKEN, GSSPLUGIN_TOKEN, GSS_SVR_ENC_TOKEN, le serveur peut accepter différents jetons pour l'authentification. Le serveur doit être configuré avec un fichier de configuration de jeton valide. Les types de jeton pris en charge dans le fichier de configuration de jeton doivent être les types spécifiés par le client lors de la connexion dans le paramètre ACCESSTOKENTYPE . Pour plus de détails, voir Authentification par jeton.