Guide préliminaire Veritas NetBackup™ pour les communications sécurisées

Last Published:
Product(s): NetBackup (8.1)
    1.  
      Guide préliminaire NetBackup pour les communications sécurisées
    2.  
      À propos des communications sécurisées dans NetBackup
    3.  
      Déploiement des certificats basés sur l'ID d'hôte pendant l'installation
    4.  
      Déploiement des certificats sur les hôtes pendant les mises à niveau
    5. Fonctionnement de la communication sécurisée avec les nœuds d'un cluster d'un serveur maître
      1.  
        À propos des clients NetBackup installés sur les nœuds d'une application en cluster
    6.  
      Quand un jeton d'autorisation est requis lors du déploiement de certificat
    7.  
      Pourquoi il faut associer les noms d'hôte (ou adresses IP) aux ID d'hôte
    8.  
      Réinitialisation des attributs d'hôte ou de l'état de la communication d'hôte
    9.  
      Modifications apportées à la récupération de catalogue
    10.  
      Modifications apportées à A.I.R. (Auto Image Replication)
    11.  
      Fonctionnement des hôtes avec des certificats révoqués
    12.  
      Processus de communication quand un hôte ne peut pas se connecter directement au serveur maître
    13.  
      Les certificats de sécurité sont-ils sauvegardés
    14.  
      Processus de communication avec les serveurs de médias hérités dans le cadre d'une configuration en cloud
    15.  
      Communication des hôtes NetBackup 8.1 avec les hôtes NetBackup 8.0 et antérieurs
    16. Scénarios d'échec de communication
      1.  
        Échec pendant la communication avec les hôtes 8.0 ou antérieurs
      2.  
        Échec de la sauvegarde de catalogue
    17. Sécuriser la prise en charge de la communication pour les autres hôtes dans le domaine NetBackup
      1.  
        Communication entre le serveur maître NetBackup 8.1 et le serveur d'OpsCenter 8.1
      2.  
        Sécuriser la prise en charge de la communication pour BMR

Pourquoi il faut associer les noms d'hôte (ou adresses IP) aux ID d'hôte

Les hôtes peuvent être référencés avec plusieurs noms.

Par exemple, lorsqu'il existe plusieurs interfaces réseau ou que les hôtes sont référencés à la fois par des noms courts et des noms de domaine complet (FQDN).

Pour que la communication sécurisée aboutisse dans NetBackup 8.1, vous devez associer tous les noms d'hôte associés à l'ID d'hôte correspondant. Le nom de client d'un hôte défini par NetBackup (ou nom principal) est automatiquement associé à son ID d'hôte lors du déploiement du certificat. D'autres noms d'hôte sont découverts pendant la communication et peuvent être associés automatiquement à l'ID d'hôte correspondant ou apparaître dans la liste des mappages à approuver. Effectuez cette configuration dans les propriétés Gestion des hôtes sur le serveur maître.

Pour plus d'informations sur le mappage d'ID d'hôte à un nom d'hôte, consultez le Guide de sécurité et de chiffrement NetBackup.

https://www.veritas.com/content/support/en_US/doc-viewer.21733320-127424841-0.v126691093-127424841.html

Exemples de configurations ayant plusieurs noms d'hôte :

  • Si vous utilisez plusieurs interfaces réseau, un hôte dispose d'un nom d'hôte public et d'un nom d'hôte privé.

  • Un hôte peut avoir un nom court et un nom de domaine complet (FQDN).

  • Un hôte peut être associé à son adresse IP.

  • Pour un système de fichiers ou une base de données en cluster, un hôte est associé à son nom de nœud et au nom virtuel du cluster.

Tenez compte des éléments suivants :

  • Les agents Exchange, SharePoint et SQL Server imposent également de configurer les informations d'hôte dans les propriétés d'hôte Mappage de restauration d'application distribuée sur le serveur maître.

  • Pour les environnements hautement disponibles, l'agent SQL Server n'exige plus de seconde politique contenant le cluster ou les noms de nœud AG. Vous devez également définir les autorisations des restaurations redirigées pour le cluster ou les nœuds AG. Pour que les sauvegardes et les restaurations d'un cluster SQL Server ou d'un groupe de disponibilité aboutissent, il suffit de configurer les mappages dans les propriétés de Gestion des hôtes et les propriétés d'hôte Mappage de restauration d'application distribuée.

Le diagramme suivant montre le processus de mappage d'ID d'hôte à un nom d'hôte :

Le mappage d'ID d'hôte à un nom d'hôte s'exécute comme suit :

  1. Le nom de domaine complet de l'hôte 2 est associé à son ID d'hôte lors du déploiement du certificat.

  2. L'hôte 1 lance une connexion sécurisée vers l'hôte 2 en utilisant le nom court. Les deux hôtes échangent leur certificats basés sur un ID d'hôte dans le cadre de la négociation TLS.

  3. L'hôte 1 envoie l'ID d'hôte et le nom court de l'hôte 2 au serveur maître pour validation.

  4. Le serveur maître recherche l'ID d'hôte et le nom court dans sa base de données. Comme le nom d'hôte court fourni n'est pas encore associé àl'ID de l'hôte 2, l'une des opérations suivantes est exécutée :

    • Si l'option Mapper automatiquement l'ID d'hôte aux noms d'hôte est sélectionnée dans la console d'administration NetBackup et que le nom court n'est pas déjà associé à un autre ID d'hôte, le nom court découvert est associé automatiquement à l'ID de l'hôte 2, et l'hôte 1 est invité à continuer la connexion.

    • Si l'option Mapper automatiquement l'ID d'hôte aux noms d'hôte n'est pas sélectionnée ou que le nom court est déjà associé à un autre ID d'hôte, le mappage découvert est ajouté à la liste des approbations en attente, et l'hôte 1 est invité à abandonner la connexion. Le mappage doit être approuvé manuellement pour que les connexions à l'hôte 2 utilisant le même nom court aboutissent.

  5. La connexion est établie entre les hôtes si le mappage est approuvé. Si le mappage n'est pas approuvé, la connexion est abandonnée.