Considérations sur la sécurité

Le protocole d'authentification Kerberos, pris en charge par les contrôleurs de domaine Windows 2000 ou version ultérieure, peut uniquement être utilisé dans le contexte d'une limite d'approbation. L'authentification Kerberos est le processus utilisé pour effectuer l'authentification mutuelle entre agents et serveurs Operations Manager. L'authentification mutuelle agent/serveur est obligatoire pour toutes les communications entre agents et serveurs dans Operations Manager Shell.

Un groupe d'administration Operations Manager n'a pas la possibilité d'effectuer la détection et l'analyse en dehors de la limite d'approbation Kerberos dans laquelle il se trouve. Toutefois, étant donné que le protocole d'authentification par défaut pour les ordinateurs Windows qui ne sont pas joints à un domaine Active Directory est NTLM, un autre mécanisme est nécessaire pour prendre en charge l'authentification mutuelle. Cela se fait par le biais de l'échange de certificats entre agents et serveurs.

Lorsque les communications Operations Manager doivent franchir les limites d'approbation, par exemple lorsqu'un serveur à analyser se trouve dans un domaine Active Directory non approuvé, autre que celui du groupe d'administration qui effectue l'analyse, des certificats permettent de satisfaire les conditions requises pour l'authentification mutuelle. Lors de la configuration manuelle, il est possible d'obtenir des certificats et de les associer aux ordinateurs et aux services Operations Manager exécutés sur ces derniers. Lorsqu'un service devant communiquer avec un service situé sur un autre ordinateur démarre et tente de s'authentifier, l'authentification mutuelle peut avoir lieu après un échange de certificats.

Pour plus d'informations sur l'obtention et l'utilisation de certificats pour l'authentification mutuelle, consultez Déploiement d'un serveur de passerelle.

Il existe quatre types d'autorités de certification Microsoft :

• racine d'entreprise ;

• secondaire d'entreprise ;

• racine autonome ;

• secondaire autonome.

• Les deux types d'autorités de certification d'entreprise requièrent les services de domaine Active Directory, ce qui n'est pas le cas pour les autorités de certification autonomes. N'importe laquelle de ces autorités de certification peut émettre les certificats nécessaires pour l'authentification mutuelle des agents/serveurs dans les limites d'approbation.

Habituellement, une infrastructure d'autorité de certification se compose d'une autorité de certification racine qui signe ses propres certificats et certifie elle-même et d'une ou plusieurs autorités de certification secondaires, qui sont certifiées par la racine. Les serveurs d'autorité de certification secondaires sont ceux que demande un certificat de service, alors que la racine est mise hors ligne et conservée en lieu sûr. Pour plus d'informations sur la conception des certificats, consultez Infrastructure Planning and Design (Planification et conception de l'infrastructure) et Authentification et chiffrement des données pour les ordinateurs Windows.

L'Assistant Détection vous permet de rechercher les ordinateurs UNIX et Linux et de les ajouter au groupe d'administration en tant qu'objets gérés. Durant le processus, Operations Manager requiert que l'ordinateur UNIX et Linux détecté génère un certificat auto-signé. Ce certificat est ensuite utilisé pour l'authentification mutuelle avec le serveur d'administration. Lorsque la détection SSH est activée, la génération, la signature et l'échange des certificats se déroulent comme suit :

1. Lors de l'exécution de l'Assistant Détection sur le serveur d'administration, l'ordinateur UNIX ou Linux détecté doit générer un certificat auto-signé.

2. Le serveur d'administration effectuant la détection émet une demande d'obtention de certificat à l'ordinateur UNIX ou Linux.

3. L'ordinateur UNIX ou Linux retourne le certificat au serveur d'administration.

4. Le serveur d'administration effectuant la détection crée une paire de clés et son propre certificat auto-signé. Il génère une paire de clés et un certificat auto-signé uniquement lorsqu'il détecte le premier ordinateur UNIX ou Linux. Le serveur d'administration importe ensuite son propre certificat dans son magasin de certificats approuvés. Après quoi, il signe le certificat UNIX ou Linux à l'aide de sa clé privée. Lorsque le serveur d'administration signe d'autres certificats d'ordinateurs UNIX ou Linux par la suite, il réutilise la clé privée du serveur d'administration générée lors de la première signature.

5. Le serveur d'administration effectuant la détection émet alors une demande Put afin de replacer le certificat, maintenant signé par le serveur d'administration, sur l'ordinateur UNIX ou Linux qui l'avait généré au départ. La couche de communication WSMAN de l'ordinateur UNIX ou Linux est redémarrée, de manière à activer le nouveau certificat généré par l'ordinateur UNIX\Linux.

6. Désormais, lorsque le serveur d'administration demande à l'ordinateur UNIX ou Linux de s'authentifier, ce dernier lui fournit le certificat approuvé. Le serveur d'administration lit la signature sur le certificat qui lui est présenté, vérifie qu'il s'agit d'une signature approuvée (la signature est sa propre clé privée, enregistrée dans son propre magasin de certificats approuvés) et il accepte le certificat comme preuve que l'ordinateur UNIX ou LINUX est réellement celui qu'il croit.

7. Le serveur d'administration de détection utilisera les informations d'identification UNIX ou Linux, comme configuré dans le profil d'identification approprié, pour s'authentifier avec l'ordinateur UNIX ou Linux. Pour plus de détails, consultez la section Planification de profils d'identification UNIX ou Linux.

Une fois que l'ordinateur UNIX ou Linux est géré par le serveur d'administration qui effectue la détection, l'exécution des détections de packs d'administration et des flux de travail commence. Pour s'exécuter correctement, ces flux de travail requièrent l'utilisation d'informations d'identification. Ces informations d'identification, les objets, les classes ou le groupe auxquels elles s'appliquent et les ordinateurs sur lesquels elles seront distribuées sont définis par les profils d'identification. Deux profils d'identification sont importés lors de l'importation de packs d'administration UNIX dans votre groupe d'administration. Il s'agit des profils suivants :

• Profil de compte d'action Unix : ce profil d'identification et les informations d'identification UNIX ou Linux connexes sont utilisés pour des activités de basse sécurité sur les ordinateurs UNIX ou Linux désignés.

• Profil de compte à privilèges élevés Unix : ce profil d'identification et les informations d'identification UNIX ou Linux connexes sont utilisés pour des activités protégées par un plus haut niveau de sécurité et qui, par conséquent, requièrent des privilèges plus élevés sur l'ordinateur UNIX ou Linux. Il peut s'agir du compte racine (mais ce n'est pas obligatoire).

Vous devez configurer ces profils à l'aide des informations d'identification appropriées pour l'ordinateur UNIX ou Linux, afin que les flux de travail de pack d'administration qui les utilisent fonctionnent correctement.

Operations Manager contrôle l'accès aux groupes, tâches, affichages et fonctions administratives qui sont analysés par le biais de l'affectation de comptes d'utilisateur à des rôles. Dans Operations Manager, un rôle associe un type de profil (opérateur, opérateur avancé, administrateur) et une étendue (les données auxquelles le rôle peut accéder). En général, les groupes de sécurité Active Directory sont affectés à des rôles, puis des comptes individuels sont affectés à ces groupes. Avant le déploiement, planifiez des groupes de sécurité Active Directory pouvant être ajoutés à ceux-ci, ainsi que des rôles personnalisés, si nécessaire. Ainsi, il sera possible d'ajouter des comptes d'utilisateur individuels aux groupes de sécurité.

Operations Manager fournit les définitions de rôle initiales suivantes.

Vous pouvez ajouter des groupes de sécurité Active Directory ou des comptes individuels à n'importe lequel de ces rôles prédéfinis. Dans ce cas, ces utilisateurs individuels disposeront des privilèges de rôle donnés sur les objets de l'étendue définie.

Operations Manager vous permet également de créer des rôles personnalisés basés sur les profils Opérateur, Opérateur en lecture seule, Auteur et Opérateur Avancé. Lorsque vous créez le rôle, vous pouvez réduire l'étendue des groupes, tâches et affichages auxquels le rôle a accès. Par exemple, vous pouvez créer le rôle « Opérateur Exchange » et limiter l'étendue aux groupes, affichages et tâches se rapportant à Exchange. Les comptes d'utilisateur affectés à ce rôle pourront uniquement exécuter des actions de niveau Opérateur sur des objets associés à Exchange.

Les utilisateurs de votre entreprise appelés à interagir fréquemment avec Operations Manager, par exemple un administrateur Exchange affecté au rôle Opérateur Exchange, doit être en mesure de détecter les nouvelles alertes. Pour ce faire, il peut surveiller l'affichage de nouvelles alertes dans la console Opérateur ou Operations Manager peut l'en informer par le biais des canaux de communications pris en charge.Operations Manager prend en charge les notifications par courrier électronique, la messagerie instantanée, les SMS ou les radiomessages. Les destinataires que vous spécifiez dans Operations Manager reçoivent des notifications contenant des informations en rapport avec leurs rôles. Un destinataire Operations Manager est un simple objet doté d'une adresse valide à laquelle les notifications sont envoyées. Par exemple, il peut s'agir d'une adresse SMTP pour les notifications par messagerie électronique.

Par conséquent, il est logique d'associer l'affectation de rôle à l'appartenance à un groupe de notification par le biais d'un groupe de sécurité ayant accès à la messagerie. Par exemple, créez un groupe de sécurité Administrateurs Exchange et ajoutez-lui des utilisateurs ayant les connaissances et les autorisations nécessaires pour résoudre des problèmes liés à Exchange. Affectez ce groupe de sécurité à un rôle Administrateur Exchange personnalisé, afin que les utilisateurs aient accès aux données et à la messagerie électronique. Créez ensuite un destinataire en utilisant l'adresse SMTP du groupe de sécurité ayant accès à la messagerie.

Lors du déploiement, les comptes de service suivants doivent être opérationnels. Si vous utilisez des comptes de domaine et si la stratégie d'expiration des mots de passe par défaut de votre objet de stratégie de groupe de domaine est définie comme requis, vous devrez changer les mots de passe des comptes de service conformément à la planification, utiliser des comptes système requérant peu de maintenance ou configurer les comptes de manière à ce que les mots de passe n'expirent jamais.

Lorsque vous déployez Operations Manager, vous pouvez être amené à enregistrer un nom principal de service dans certaines configurations. Les noms principaux de service sont utilisés par l'authentification Kerberos pour le client afin qu'il s'authentifie mutuellement avec le serveur. Pour plus d'informations, consultez What Are Service Publication and Service Principal Names? (Que sont les noms principaux de service et la publication du service ?).

Lorsque vous installez Operations Manager, vous sélectionnez un compte pour le service de configuration System Center et le service d'accès aux données System Center. Pour plus d'informations, voir Déploiement de System Center 2012 - Operations Manager.

Attention
Ne modifiez pas les autorisations Active Directory par défaut pour permettre à un compte d'effectuer des modifications sans restriction de son propre nom principal de service.

Si vous sélectionnez le système local comme compte de service d'accès aux données System Center, le compte peut créer le nom principal de service approprié. Aucune configuration supplémentaire n'est requise.

Si vous utilisez un compte de domaine, vous devez enregistrer un nom principal de service pour chaque serveur d'administration. Utilisez l'outil de ligne de commande SETSPN. Pour plus d'informations sur l'exécution de cet outil, consultez Setspn Overview (Vue d'ensemble de Setspn).

Enregistrez le nom netbios et le nom de domaine complet du serveur d'administration à l'aide de la syntaxe suivante :

setspn –a MSOMSdkSvc/<netbios name> <DAS account domain>\<DAS account name>

setspn –a MSOMSdkSvc/<fqdn> <DAS account domain>\<DAS account name>

Conseil
Vous pouvez répertorier les noms principaux de service enregistrés pour le compte d'utilisateur ou un ordinateur avec la syntaxe suivante : setspn –l <DAS account name> setspn –l <fqdn>

Si vous utilisez l'équilibrage de la charge réseau ou un équilibrage de charge matériel, le service d'accès aux données de System Center doit être exécuté sous un compte de domaine. Outre la configuration déjà décrite, vous devez également enregistrer le nom équilibrée de charge, à l'aide de la syntaxe suivante :

setspn –a MSOMSdkSvc/<load balanced name> <DAS account domain>\<DAS account name>

Les agents se trouvant sur des ordinateurs gérés peuvent exécuter des tâches, des modules et des analyses à la demande, ou suite à des conditions prédéfinies. Par défaut, toutes les tâches sont exécutées à l'aide des informations d'identification d'un compte d'action d'agent. Dans certains cas, le compte d'action d'agent peut avoir des droits et privilèges insuffisants pour exécuter une action donnée sur l'ordinateur.Operations Manager prend en charge l'exécution de tâches par les agents dans le contexte d'un autre ensemble d'informations d'identification appelé Compte d'identification. À l'instar d'un destinataire, un compte d'identification est un simple objet créé dans Operations Manager. Il est mappé à un compte d'utilisateur Active Directory. Le profil d'identification qui est alors utilisé mappe le compte d'identification à un ordinateur spécifique. Lorsqu'une règle, tâche ou analyse, associée à un profil d'identification lors du développement d'un pack d'administration, doit s'exécuter sur un ordinateur cible, l'exécution s'effectue à l'aide du compte d'identification spécifié.

Operations Manager fournit plusieurs comptes et profils d'identification prédéfinis et vous pouvez en créer d'autres, si nécessaire. Il est également possible de modifier les informations d'identification Active Directory auxquelles est associé un compte d'identification. Dans ce cas, vous devrez planifier, créer et maintenir à jour des informations d'identification Active Directory supplémentaires spécialement à cet effet. Ces comptes se comportent comme des comptes de service en ce qui concerne l'expiration des mots de passe, les services de domaine Active Directory, les emplacements et la sécurité.

Vous devrez collaborer avec les auteurs de packs d'administration lors de demandes de comptes d'identification. Pour plus d'informations, consultez la section Index to Security-related Information for Operations Manager (Index pour les informations relatives à la sécurité pour Operations Manager).