Unisphere pour PowerMax : Configuration du journal syslog distant

Une chaîne d’approbation de certificats, également appelée chaîne de certificats ou chaîne de confiance, est une série de certificats numériques. Ces certificats vérifient l’authenticité et la fiabilité des entités d’infrastructure à clé publique (PKI), telles qu’un serveur ou un appareil. 

Dans le contexte du journal syslog distant, une chaîne d’approbation de certificats joue un rôle crucial pour garantir la transmission sécurisée des messages de journal entre un client syslog (tel qu’un périphérique réseau) et un serveur syslog.

Pour Unisphere for PowerMax v10.2 et les versions antérieures, les exigences sont les suivantes :

Autorité de certification (CA) racine : La chaîne d’approbation commence par une autorité de certification racine de confiance, qui est une entité bien connue et de confiance qui émet des certificats pour d’autres autorités de certification. La clé publique de l’autorité de certification racine est intégrée dans le magasin d’approbations du client, ce qui permet au client de faire confiance aux certificats émis par l’autorité de certification racine.

Autorité de certification (CA) intermédiaire : L’autorité de certification racine émet un certificat à une autorité de certification intermédiaire, qui est une autorité de certification subordonnée qui émet des certificats aux entités finales, telles que les serveurs ou les appareils. L’autorité de certification racine signe le certificat de l’autorité de certification intermédiaire, établissant ainsi une chaîne d’approbation.

Certificat de serveur : L’autorité de certification intermédiaire émet un certificat sur le serveur syslog, qui inclut la clé publique du serveur et les informations d’identité (telles que le nom d’hôte, l’adresse IP). L’autorité de certification intermédiaire signe le certificat du serveur, en le liant à la chaîne d’approbation.

Pour Unisphere for PowerMax v10.3 et versions ultérieures, les exigences sont les suivantes :
Un nouveau certificat racine auto-signé est requis dans l’environnement du client et doit présenter l’un des éléments suivants :

• Paramètre AIA (Authority Information Access) valide avec des URL actives et accessibles pour la liste de révocation des certificats (CRL)
  OU
• Intervenants du protocole OCSP (Online Certificate Status Protocol)

Lorsqu’un client syslog (tel que, dans ce cas, Unisphere for PowerMax) lance une connexion au serveur syslog, il reçoit le certificat du serveur syslog distant. 

Le client vérifie le certificat en vérifiant les éléments suivants :

1. Le certificat est émis par une autorité de certification intermédiaire de confiance.
2. Le certificat de l’autorité de certification intermédiaire est émis par une autorité de certification racine de confiance.
3. Le certificat n’a pas expiré ou été révoqué.
4. L’objet du certificat (par exemple, nom d’hôte, adresse IP) correspond à l’identité attendue du serveur syslog.

Etablissement de la fiducie :
Si le client parvient à vérifier le certificat du serveur, il établit une relation de confiance avec le serveur. 
Le client peut ensuite utiliser la clé publique du serveur pour chiffrer les messages de journal, garantissant ainsi leur confidentialité et leur intégrité lors de la transmission.
La chaîne d’approbation du certificat garantit que le client syslog peut approuver l’identité du serveur syslog et établir une connexion sécurisée pour la transmission des messages de log. 
Cela est important dans les scénarios syslog distants, où les messages de journal peuvent être transmis via des réseaux non approuvés, tels qu’Internet.

Cette RFC se concentre sur le transport des messages syslog via le protocole TCP (Transmission Control Protocol).

Il définit les éléments suivants :

• L’utilisation de TCP comme protocole de transport pour les messages syslog
• Le protocole TLS syslog, qui assure le chiffrement et l’authentification des messages syslog
• Protocole DTLS (Datagram Transport Layer Security) syslog qui assure le chiffrement et l’authentification des messages syslog via UDP (User Datagram Protocol).
• RFC 5425 fournit un moyen sûr et fiable de transporter les messages syslog via TCP, ce qui est essentiel pour les configurations syslog distantes.

Cette RFC met à jour le protocole syslog pour respecter les limites de la norme RFC 3164. 

Les principales différences sont les suivantes :

• Format d’horodatage amélioré avec résolution en milliseconde
• Introduction d’un élément de données structuré, qui permet une journalisation plus flexible et extensible
• Prise en charge du chiffrement IPv6 et TLS (Transport Layer Security)
• Fonctions de sécurité améliorées, telles que l’authentification et l’autorisation
• La RFC 5424 est rétrocompatible avec la RFC 3164, ce qui permet une transition en douceur vers le nouveau protocole.

Cette RFC décrit le protocole syslog d’origine. 

Il définit le format de message syslog, qui inclut les composants suivants :

• Priorité (une combinaison de facilité et de gravité)
• Horodatage
• Nom d’hôte
• Message

La norme RFC 3164 est encore largement utilisée aujourd’hui, mais présente certaines limites, telles que l’absence d’authentification et de chiffrement.