Guide de sécurité et de chiffrement NetBackup™
- Informations préliminaires pour les communications sécurisées dans NetBackup
- Scénarios d'échec de communication
- Augmentation de la sécurité dans NetBackup
- Modèles de déploiement de la sécurité
- Audit des opérations NetBackup
- Événements d'audit
- Section I. Gestion des identités et des accès
- À propos de la gestion des identités et des accès
- Domaines AD et LDAP
- Clés d'accès
- Clés d'API
- Fichier auth.conf
- Contrôle d'accès basé sur les rôles
- Carte à puce ou certificat numérique
- Authentification unique (SSO)
- Audit amélioré
- Configuration d'audit amélioré
- Sécurité de NetBackup Access Control (NBAC)
- Configuration de NBAC (NetBackup Access Control)
- Configuration des propriétés de l'hôte de contrôle d'accès pour le serveur maître et de médias
- Boîte de dialogue Propriétés d'hôte du contrôle d'accès pour le client
- Dépannage de la gestion de l'accès
- Points de vérification de Windows
- Points de vérification UNIX
- Points de vérification dans un environnement mixte avec un serveur maître UNIX
- Points de vérification dans un environnement mixte avec un serveur maître Windows
- Détermination de l'accès à NetBackup
- Affichage des autorisations d'utilisateur particulières des groupes d'utilisateurs NetBackup
- Section II. Chiffrement des données en transit
- Autorité de certification NetBackup et certificats NetBackup
- À propos des utilitaires de gestion de la sécurité
- À propos de la gestion des hôtes
- Ajout de mappages partagés ou de cluster
- Autoriser ou ne pas autoriser le renouvellement de certificat automatique
- À propos des paramètres de sécurité globale
- À propos des certificats basés sur le nom d'hôte
- À propos des certificats basés sur l'ID d'hôte
- À l'aide de l'utilitaire de gestion de certificat pour émettre et déployer des certificats basés sur l'ID d'hôte
- À propos des niveaux de sécurité de déploiement de certificats NetBackup
- Installation de la confiance avec le serveur maître (Autorité de certification)
- Renouvellement des certificats basés sur l'ID d'hôte
- À propos de la gestion des jetons pour les certificats basés sur l'ID d'hôte
- À propos de la liste de révocations des certificats basés sur l'ID d'hôte
- Révocation de certificats basés sur l'ID d'hôte
- Déploiement de certificat basé sur l'ID d'hôte dans une configuration en cluster
- Déploiement d'un certificat basé sur un ID d'hôte sur un hôte NetBackup en cluster
- Migration de l'autorité de certification NetBackup
- Configuration du chiffrement des données en transit (DTE)
- Configuration du mode DTE sur un client
- Modification du mode DTE d'une image de sauvegarde
- Fonctionnement des paramètres de configuration DTE dans différentes opérations NetBackup
- Autorité de certification externe et certificats externes
- A propos de la prise en charge d'une autorité de certification externe dans NetBackup
- Options de configuration pour les certificats signés par une autorité de certification externe
- ECA_CERT_PATH pour les serveurs et clients NetBackup
- À propos des listes de révocation des certifications pour l'autorité de certification externe
- À propos de l'inscription de certificats
- Configuration d'un certificat externe pour le serveur Web NetBackup
- À propos de la configuration de certificat externe pour un serveur maître en cluster
- Régénération de clés et de certificats
- Autorité de certification NetBackup et certificats NetBackup
- Section III. Chiffrement des données au repos
- Sécurité du chiffrement des données au repos
- A propos du chiffrement de client NetBackup
- Configuration du chiffrement standard sur des clients
- Configuration de chiffrement standard à partir du serveur
- Configuration du chiffrement hérité sur les clients
- A propos de la configuration du chiffrement hérité à partir du client
- Configuration du chiffrement hérité du serveur
- Degré de sécurité de fichier de clé hérité supplémentaire pour clients UNIX
- Service Gestion des clés NetBackup
- À propos de KMS conforme à la norme FIPS
- Installation du KMS
- Configuration de KMS
- Groupes de clés et enregistrements de clé
- Présentation des états d'enregistrement de clé
- Configuration de NetBackup pour fonctionner avec le KMS
- Utilisation de KMS pour le chiffrement
- Éléments constitutifs d'une base de données KMS
- Commandes de l'interface de ligne de commande (CLI)
- A propos de l'exportation et de l'importation de clés à partir de la base de données KMS
- Dépannage du KMS
- Service Gestion des clés externe
- Configuration des informations d'authentification du KMS
- Configuration du KMS
- Création de clés dans un KMS externe
- Utilisation de plusieurs serveurs KMS
- Sécurité du chiffrement des données au repos
- Conformité FIPS dans NetBackup
- Configuration du mode FIPS dans votre domaine NetBackup
- Pour désactiver le mode FIPS pour NetBackup
- Compte de services Web NetBackup
- Exécution de services NetBackup avec un compte utilisateur sans privilège (utilisateur du service)
- À propos d'un compte utilisateur du service NetBackup
- Immuabilité et ineffaçabilité des données dans NetBackup
- Détection d'anomalies de sauvegarde
- À propos de la détection des anomalies de sauvegarde
- Détection de malwares
- À propos de l'analyse antimalware
Data center multiple avec NBAC complet
L'exemple d'un data center multiple avec NBAC complet est défini comme un support ppur un grand groupe d'hôtes (plus de 50) qui couvre deux régions géographiques ou plus et peuvent être connectées par un réseau étendu (WAN). Dans cet exemple, un data center est à Londres et l'autre data center est à Tokyo. Les deux data centers sont connectés par une connexion WAN dédiée.
Cet environnement est très semblable au data center multiple avec le serveur maître et le serveur de médias de NBAC. Les principales différences sont que tous les hôtes participant à l'environnement de NetBackup sont identifiés de manière fiable avec les informations d'authentification et des administrateurs non racine peuvent gérer les clients NetBackup en fonction des niveaux d'accès configurables. Les identités des utilisateurs peuvent se trouver dans des référentiels globaux tels que l'annuaire Active Directory sous Windows ou NIS sous UNIX. Les identités peuvent également se trouver dans des référentiels en local (mot de passe UNIX, domaine Windows local) sur ces hôtes prenant en charge un courtier d'authentification.
Le data center multiple avec NBAC complet inclut ce qui suit :
NetBackup couvre deux régions géographiques ou plus par le biais d'un réseau étendu (WAN)
Semblable aux détails pour le data center multiple avec le serveur maître et le serveur de médias de NBAC, excepté la racine ou l'administrateur sur le client L'administration non racine des clients et des serveurs est permise dans cette configuration.
Pour les systèmes client, vous pouvez configurer les utilisateurs qui ne sont ni utilisateur racine, ni administrateur pour qu'ils puissent effectuer des sauvegardes et restaurations locales (configuration par défaut)
L'environnement facilite la connexion de tous les hôtes autorisés faisant partie de NetBackup
Exige que tous les hôtes utilisent NetBackup version 7.7. ou ultérieure.
Figure : Data center multiple avec NBAC complet affiche un exemple d'un data center multiple avec NBAC complet.
Le tableau suivant décrit les composants de NetBackup qui sont utilisés pour un data center multiple avec NBAC complet mis en application.
Tableau : Composants de NetBackup utilisés pour un data center multiple avec NBAC complet mis en application
Composant |
Description |
---|---|
Data center de Londres |
Le data center de Londres contient le courtier racine, le courtier d'authentification 1, l'interface graphique utilisateur 1, le moteur d'autorisation, le serveur maître, le serveur de médias 1 et les clients 1 et 5. Le data center de Londres contient également la bande de données déchiffrée pour les clients 1, 5 et 10. Le data center de Londres se connecte au data center de Tokyo par une connexion WAN dédiée. |
Data center de Tokyo |
Le data center de Tokyo contient le courtier d'authentification 2, l'interface graphique utilisateur 2, le serveur de médias 2 et les clients 10 et 11. Le data center de Tokyo contient également la bande de données déchiffrée pour les clients 10 et 11. Le data center de Tokyo se connecte au data center de Londres par une connexion WAN dédiée. |
Réseau étendu (WAN) |
Spécifie le lien WAN dédié qui connecte le data center de Londres au data center de Tokyo. Le WAN fournit la connectivité entre le courtier racine et le courtier d'authentification 1 et le courtier d'authentification 2. De plus, le WAN fournit la connectivité entre le courtier racine et le courtier d'authentification 1 et l'interface graphique utilisateur 2 avec le serveur de médias 2. Le WAN connecte le serveur maître à l'interface graphique utilisateur 2, le serveur de médias 2 et les clients 10 et 11. Enfin, le WAN connecte le serveur de médias 1 au client 10. |
Serveur maître |
Le serveur maître, situé dans le data center de Londres, communique avec le courtier racine et le courtier d'authentification 1. Il communique également avec l'interface graphique utilisateur 1, le moteur d'autorisation et le serveur de médias 1. Le serveur maître communique aussi avec l'interface graphique utilisateur 2 et le serveur de médias 2 et les clients 10 et 11 à Tokyo. |
Serveurs de médias |
Précise que dans cet exemple de data center multiple, il existe deux serveurs de médias. Le serveur de médias 1 est situé dans le data center de Londres et le serveur de médias 2 est situé dans le data center de Tokyo. A Londres, le serveur de médias 1 communique avec le serveur maître, le courtier racine et le courtier d'authentification 1, le moteur d'autorisation et les clients 1, 5 et 10. Le serveur de médias 1 enregistre des données non chiffrées sur bande pour les clients 1, 5 et 10. A Tokyo, le serveur de médias n° 2 échange des données avec le serveur maître, le courtier racine, le courtier d'authentification n° 1 et le moteur d'autorisation à Londres par le biais du réseau étendu. Le serveur de médias 2 communique également avec l'interface graphique utilisateur 2 et les clients 10 et 11 à Tokyo. Le serveur de médias n° 2 enregistre des données non chiffrées sur bande pour les clients n° 10 et n° 11. |
Interfaces graphiques utilisateur |
Précise que dans cet exemple de data center multiple, il existe deux interfaces graphiques utilisateur. L'interface graphique utilisateur 1 se trouve à Londres et l'interface graphique utilisateur 2 se trouve à Tokyo. Les interfaces graphiques utilisateur des consoles d'administration à distance reçoivent les informations d'authentification des courtiers. Les interfaces graphiques utilisateur utilisent ces informations d'authentification pour accéder aux fonctions des serveurs de médias et serveurs maîtres. A Londres, l'interface graphique utilisateur 1 reçoit des informations d'authentification du courtier d'authentification 1.L'interface graphique utilisateur 1 a accès aux fonctionnalités du serveur maître et des serveurs de médias 1 et 2. A Tokyo, l'interface graphique utilisateur 2 reçoit des informations d'authentification du courtier d'authentification 2. L'interface graphique utilisateur 2 a accès aux fonctionnalités du serveur maître et des serveurs de médias 1 et 2. |
Courtier racine |
Précise que dans une installation de data center multiple, un seul courtier racine est requis. Le courtier racine peut parfois être associé au courtier d'authentification. Dans l'exemple suivant, le courtier racine et le courtier d'authentification sont affichés comme même composant et se trouvent dans le data center de Londres. A Londres, le courtier d'authentifcation authentifie le courtier d'authentification 1, également à Londres, et le courtier d'authentification 2 à Tokyo. Le courtier racine n'authentifie pas les clients. |
Courtiers d'authentification |
Spécifie qu'il peut y avoir plus d'un courtier d'authentification dans une installation de data center. Le courtier d'authentification peut parfois être associé au courtier racine. Dans l'installation de ce data center, deux courtiers d'authentification sont utilisés. Le courtier d'authentification authentifie le serveur maître, le serveur de médias, l'interface graphique utilisateur et les clients en établissant des informations d'authentification pour chacun d'entre eux. Le courtier d'authentification authentifie également un utilisateur via une invite de commande. A Londres, le courtier d'authentification 1 authentifie des informations d'authentification avec le serveur maître, le serveur de médias 1, l'interface graphique utilisateur 1 et les clients 1 et 5. Tous les serveurs et clients NetBackup à Tokyo et à Londres s'authentifient auprès du courtier d'authentification 1 à Londres. L'interface graphique utilisateur 1 authentifie le courtier d'authentification 1 à Londres. L'interface graphique utilisateur 2 authentifie le courtier d'authentification 2 à Tokyo. |
Moteur d'autorisation |
Un seul moteur d'autorisation est requis dans une installation de data center. Le moteur d'autorisation communique avec le serveur maître et le serveur de médias pour vérifier les autorisations d'un utilisateur authentifié. Ces autorisations déterminent les fonctionnalités disponibles pour l'utilisateur. Le moteur d'autorisation enregistre également les groupes d'utilisateurs et les autorisations. Le moteur d'autorisation réside à Londres et communique avec le serveur maître et le serveur de médias 1. Le moteur d'autorisation communique également via le réseau étendu WAN pour autoriser l'accès au serveur de médias 2 à Tokyo. Remarque : Le moteur d'autorisation se trouve sur le serveur maître en tant que processus de daemon. Il est affiché dans le schéma en tant qu'image distincte à titre d'exemple uniquement. |
Bandes |
Spécifie que les bandes de données déchiffrées sont produites dans les data centers de Londres et de Tokyo. A Londres, la bande déchiffrée est enregistrée pour les clients 1, 5 et 10 et stockée sur site dans le data center de Londres. A Tokyo, la bande chiffrée est écrite pour les clients 10 et 11 et est stockée hors site dans le data center de Tokyo. Notez que même si le client 10 se trouve à Tokyo et qu'il sauvegardé à Tokyo, le client 10 est également sauvegardé à Londres. |
Clients |
Spécifie que les clients se trouvent dans les data centers de Londres et de Tokyo. A Londres, le client 1 est un type de NetBackup standard. Le client 5 est un type de serveur Web situé dans la zone démilitarisée. Tous les types de client peuvent être gérés par le serveur maître et faire sauvegarder leurs données sur bande par le client 5 du serveur de médias 1. Le client 5 communique avec NetBackup à l'aide des ports NetBackup uniquement via le pare-feu interne. Le client 5 reçoit également des connexions Internet en utilisant seulement des ports réservés au HTTP via le pare-feu externe. A Tokyo, le client 10 est un type de NetBackup standard. Le client 11 est un type de serveur Web situé dans la zone démilitarisée. Tous les types de client peuvent être gérés par le serveur maître et faire sauvegarder leurs données sur bande par le client 11 du serveur de médias 2. Le client 5 communique avec NetBackup à l'aide des ports NetBackup uniquement via le pare-feu interne. Le client 11 reçoit également des connexions Internet en utilisant des ports réservés au HTTP via le pare-feu externe |
Pare-feux internes |
Spécifie qu'il peut y avoir deux pare-feux internes dans cet exemple de data center multiple. Un pare-feu interne se trouve à Londres et l'autre à Tokyo. A Londres, le pare-feu interne permet à NetBackup d'accéder au client 5 de serveur Web se trouvant dans la zone démilitarisée. A Londres, le pare-feu interne permet à NetBackup d'accéder au client 11 de serveur Web se trouvant dans la zone démilitarisée. Vous ne pouvez activer que les ports NetBackup sélectionnés et les ports de certaines applications pour transmettre des données par le biais du pare-feu interne depuis et vers la zone démilitarisée. Des ports HTTP sont ouverts dans le pare-feu externe et ne sont pas autorisés à passer par le pare-feu interne. |
Zones démilitarisées (DMZ) |
Spécifie qu'il peut y avoir deux zones démilitarisées dans cet exemple de data center multiple. Une zone démilitarisée se trouve à Londres et l'autre à Tokyo. A Londres, la zone démilitarisée fournit une zone d'opérations "sécurisée" pour le client 5 de serveur Web entre le pare-feu interne et le pare-feu externe. Le client 5 de serveur Web de la zone démilitarisée peut échanger des données avec NetBackup via le pare-feu interne en utilisant les ports NetBackup affectés. Le client 5 de serveur Web peut également communiquer sur Internet par le biais du pare-feu externe en utilisant uniquement des ports HTTP. A Tokyo, la zone démilitarisée fournit une zone d'opérations "sécurisée" pour le client 11 de serveur Web entre le pare-feu interne et le pare-feu externe. Le client 11 de serveur Web de la zone démilitarisée peut échanger des données avec NetBackup via le pare-feu interne à l'aide des ports NetBackup affectés. Le client 11 de serveur Web peut également communiquer sur Internet par le biais du pare-feu externe en utilisant uniquement des ports HTTP. |
Pare-feux externes |
Spécifie qu'il peut y avoir deux pare-feux internes dans cet exemple de data center multiple. Un pare-feu externe se trouve à Londres et l'autre à Tokyo. A Londres, le pare-feu externe permet aux utilisateurs externes d'accéder au client 5 de serveur Web situé dans la zone démilitarisée depuis Internet en passant par des ports HTTP. Les ports NetBackup sont ouverts pour que le client 5 de serveur Web puisse communiquer via le pare-feu interne avec NetBackup. Les ports NetBackup ne peuvent pas passer par le pare-feu externe pour se connecter à Internet. Seuls les ports HTTP du client 5 de serveur Web peuvent passer par le pare-feu externe pour se connecter à Internet. A Tokyo le pare-feu externe permet aux utilisateurs externes d'accéder au client 11 de serveur Web situé dans la zone démilitarisée depuis Internet en passant par des ports HTTPS. Les ports NetBackup sont ouverts pour que le client 11 de serveur Web puisse communiquer via le pare-feu interne avec NetBackup. Les ports NetBackup ne peuvent pas passer par le pare-feu externe pour se connecter à Internet. Seuls les ports HTTP du client 11 de serveur Web peuvent passer par le pare-feu externe pour se connecter à Internet. |
Internet |
Spécifie qu'il ne peut y avoir qu'un seul Internet mais deux connexions Internet dans cet exemple de data center multiple. Une connexion Internet se trouve à Londres et l'autre à Tokyo. Internet est un ensemble de réseaux d'ordinateurs connectés entre eux par des câbles de cuivre, des câbles de fibre optique ou par des connexions sans fil. A Londres, le client 5 de serveur Web peut envoyer et recevoir des données sur Internet à l'aide des ports HTTP et en passant par le pare-feu externe. A Tokyo, le client 11 de serveur Web peut envoyer et recevoir des données sur Internet à l'aide des ports HTTP et en passant par le pare-feu externe. |