Intégrer Azure Stack Hub à des solutions de supervision à l’aide du transfert syslog

Cet article explique comment utiliser syslog pour intégrer l’infrastructure Azure Stack Hub à des solutions de sécurité externes déjà déployées dans votre centre de données. Un exemple est un système SIEM (Security Information Event Management). Le canal syslog présente des audits, des alertes et des journaux d’activité de sécurité provenant de tous les composants de l’infrastructure Azure Stack Hub. Utilisez le transfert Syslog pour intégrer des solutions de supervision de la sécurité et pour récupérer la totalité des audits, alertes et journaux de sécurité afin de les stocker et les conserver.

À compter de la mise à jour 1809, Azure Stack Hub dispose d’un client syslog intégré qui, une fois configuré, émet des messages syslog avec la charge utile au format d’événement commun (CEF).

Le diagramme suivant décrit l’intégration d’Azure Stack Hub avec un SIEM externe. Deux modèles d’intégration doivent être pris en compte : le premier (en bleu) correspond à l’infrastructure Azure Stack Hub qui englobe les machines virtuelles d’infrastructure et les nœuds Hyper-V. Tous les audits, journaux d’activité de sécurité et alertes provenant de ces composants sont recueillis et exposés de manière centralisée par le biais de syslog avec une charge utile au format CEF. Ce modèle d’intégration est décrit dans cet article.

Le deuxième modèle d’intégration est celui représenté en orange et couvre les contrôleurs de gestion de carte mère (BMC), l’hôte de gestion du cycle de vie du matériel (HLH), les machines virtuelles et les appliances virtuelles qui exécutent le logiciel de surveillance et de gestion du partenaire matériel, ainsi que les commutateurs de fin de rack (TOR). Ces composants étant propres au partenaire matériel, contactez celui-ci pour obtenir une documentation sur la façon de les intégrer à un SIEM externe.

Configurer le transfert de Syslog

Dans Azure Stack Hub, le client syslog prend en charge les configurations suivantes :

1. Syslog sur TCP, avec authentification mutuelle (client et serveur) et chiffrement TLS 1.2 : Dans cette configuration, le serveur syslog et le client syslog peuvent tous les deux vérifier l’identité de l’autre par le biais de certificats. Les messages sont envoyés via un canal chiffré TLS 1.2.
2. Syslog sur TCP avec authentification du serveur et chiffrement TLS 1.2 : dans cette configuration, le client syslog peut vérifier l’identité du serveur syslog via un certificat. Les messages sont envoyés via un canal chiffré TLS 1.2.
3. Syslog sur TCP, sans chiffrement : dans cette configuration, les identités du client syslog et du serveur syslog ne sont pas vérifiées. Les messages sont envoyés en texte clair sur TCP.
4. Syslog sur UDP, sans chiffrement : dans cette configuration, les identités du client syslog et du serveur syslog ne sont pas vérifiées. Les messages sont envoyés en texte clair via UDP.

Applets de commande pour configurer le transfert de Syslog

La configuration du transfert de Syslog requiert l’accès au point de terminaison privilégié (PEP). Deux applets de commande PowerShell ont été ajoutées au pep pour configurer le transfert syslog :

### cmdlet to pass the syslog server information to the client and to configure the transport protocol, the encryption and the authentication between the client and the server

Set-SyslogServer [-ServerName <String>] [-ServerPort <UInt16>] [-NoEncryption] [-SkipCertificateCheck] [-SkipCNCheck] [-UseUDP] [-Remove]

### cmdlet to configure the certificate for the syslog client to authenticate with the server

Set-SyslogClient [-pfxBinary <Byte[]>] [-CertPassword <SecureString>] [-RemoveCertificate] [-OutputSeverity]

Paramètres d’applet de commande

Paramètres du cmdlet Set-SyslogServer :

Paramètres du cmdlet Set-SyslogClient :

Configurer le transfert syslog avec le chiffrement TCP, l’authentification mutuelle et le chiffrement TLS 1.2

Dans cette configuration, le client syslog dans Azure Stack Hub transfère les messages au serveur syslog via TCP, avec chiffrement TLS 1.2. Pendant la négociation initiale, le client vérifie que le serveur fournit un certificat valide et approuvé. Le client fournit également un certificat au serveur comme preuve de son identité. Cette configuration est la plus sécurisée car elle fournit une validation complète de l’identité du client et du serveur, et envoie des messages via un canal chiffré.

Pour configurer le transfert de Syslog avec TCP, authentification mutuelle et chiffrement TLS 1.2, exécutez ces deux applets de commande sur une session PEP :

# Configure the server
Set-SyslogServer -ServerName <FQDN or ip address of syslog server> -ServerPort <Port number on which the syslog server is listening>

# Provide certificate to the client to authenticate against the server
Set-SyslogClient -pfxBinary <Byte[] of pfx file> -CertPassword <SecureString, password for accessing the pfx file>

Le certificat client doit avoir la même racine que celui fourni lors du déploiement d’Azure Stack Hub. Il doit également contenir une clé privée.

##Example on how to set your syslog client with the certificate for mutual authentication.
##This example script must be run from your hardware lifecycle host or privileged access workstation.

$ErcsNodeName = "<yourPEP>"
$password = ConvertTo-SecureString -String "<your cloudAdmin account password" -AsPlainText -Force
 
$cloudAdmin = "<your cloudAdmin account name>"
$CloudAdminCred = New-Object System.Management.Automation.PSCredential ($cloudAdmin, $password)
 
$certPassword = $password
$certContent = Get-Content -Path C:\cert\<yourClientCertificate>.pfx -Encoding Byte
 
$params = @{ 
    ComputerName = $ErcsNodeName 
    Credential = $CloudAdminCred 
    ConfigurationName = "PrivilegedEndpoint" 
}

$session = New-PSSession @params
 
$params = @{ 
    Session = $session 
    ArgumentList = @($certContent, $certPassword) 
}
Write-Verbose "Invoking cmdlet to set syslog client certificate..." -Verbose 
Invoke-Command @params -ScriptBlock { 
    param($CertContent, $CertPassword) 
    Set-SyslogClient -PfxBinary $CertContent -CertPassword $CertPassword }

Configurer le transfert syslog avec le chiffrement TCP, l’authentification du serveur et le chiffrement TLS 1.2

Dans cette configuration, le client syslog dans Azure Stack Hub transfère les messages au serveur syslog via TCP, avec chiffrement TLS 1.2. Pendant la négociation initiale, le client vérifie également que le serveur fournit un certificat valide et approuvé. Cette configuration empêche le client d’envoyer des messages vers des destinations non approuvées. TCP avec authentification et chiffrement est la configuration par défaut et représente le niveau minimal de sécurité que Microsoft recommande pour un environnement de production.

Set-SyslogServer -ServerName <FQDN or ip address of syslog server> -ServerPort <Port number on which the syslog server is listening>

Si vous souhaitez tester l’intégration de votre serveur syslog au client Azure Stack Hub à l’aide d’un certificat auto-signé ou non approuvé, vous pouvez utiliser ces indicateurs pour ignorer la validation du serveur effectuée par le client pendant la négociation initiale :

 # Skip validation of the Common Name value in the server certificate. Use this flag if you provide an IP address for your syslog server
 Set-SyslogServer -ServerName <FQDN or ip address of syslog server> -ServerPort <Port number on which the syslog server is listening>
 -SkipCNCheck

 # Skip the server certificate validation entirely
 Set-SyslogServer -ServerName <FQDN or ip address of syslog server> -ServerPort <Port number on which the syslog server is listening>
 -SkipCertificateCheck

Configurer le transfert syslog avec TCP et sans chiffrement

Dans cette configuration, le client syslog dans Azure Stack Hub transfère les messages au serveur syslog via TCP, sans chiffrement. Le client ne vérifie pas l’identité du serveur, ni ne fournit son propre identité au serveur pour vérification :

Set-SyslogServer -ServerName <FQDN or ip address of syslog server> -ServerPort <Port number on which the syslog server is listening> -NoEncryption

Configuration du transfert syslog avec UDP et sans chiffrement

Dans cette configuration, le client syslog dans Azure Stack Hub transfère les messages au serveur syslog via UDP, sans chiffrement. Le client ne vérifie pas l’identité du serveur, ni ne fournit son propre identité au serveur pour vérification :

Set-SyslogServer -ServerName <FQDN or ip address of syslog server> -ServerPort <Port number on which the syslog server is listening> -UseUDP

Bien que UDP sans chiffrement soit le plus simple à configurer, il ne fournit pas de protection contre les attaques man-in-the-middle et l’écoute des messages.

Supprimer la configuration de transfert de syslog

Pour supprimer la configuration du serveur syslog du client et arrêter le transfert syslog, exécutez l’applet de commande suivante :

Set-SyslogServer -Remove

Pour supprimer le certificat client du client, exécutez l’applet de commande suivante :

Set-SyslogClient -RemoveCertificate

Vérifier la configuration de syslog

Si vous avez correctement connecté le client syslog à votre serveur syslog, vous devez bientôt commencer à recevoir des événements. Si vous ne voyez aucun événement, vérifiez la configuration de votre client syslog en exécutant les applets de commande suivantes.

Pour vérifier la configuration du serveur dans le client syslog :

Get-SyslogServer

Pour vérifier la configuration du certificat dans le client syslog :

Get-SyslogClient

Schéma de message Syslog

Le transfert syslog de l’infrastructure Azure Stack Hub envoie des messages mis en forme au format CEF (Common Event Format). Chaque message syslog est structuré en fonction du schéma <Time> <Host> <CEF payload>.

La charge utile CEF est basée sur la structure suivante, mais le mappage pour chaque champ varie en fonction du type de message (Événement Windows, Alerte créée, Alerte fermée) :

# Common Event Format schema
CEF: <Version>|<Device Vendor>|<Device Product>|<Device Version>|<Signature ID>|<Name>|<Severity>|<Extensions>
* Version: 0.0
* Device Vendor: Microsoft
* Device Product: Microsoft Azure Stack Hub
* Device Version: 1.0

Mappage CEF pour les événements de point de terminaison privilégié

Prefix fields
* Signature ID: Microsoft-AzureStack-PrivilegedEndpoint: <PEP Event ID>
* Name: <PEP Task Name>
* Severity: mapped from PEP Level (details see the PEP Severity table below)
* Who: account used to connect to the PEP
* WhichIP: IP address of ERCS server hosting the PEP

Tableau des événements pour le point de terminaison privilégié (PEP) :

Tableau de gravité PEP :

Mappage CEF pour les événements de point de terminaison de récupération

Prefix fields
* Signature ID: Microsoft-AzureStack-PrivilegedEndpoint: <REP Event ID>
* Name: <REP Task Name>
* Severity: mapped from REP Level (details see the REP Severity table below)
* Who: account used to connect to the REP
* WhichIP: IP address of the device used to connect to the REP

Tableau des événements pour le point de terminaison de récupération :

Tableau de sévérité REP :

Mappage CEF pour les événements Windows

* Signature ID: ProviderName:EventID
* Name: TaskName
* Severity: Level (for details, see the severity table below)
* Extension: Custom Extension Name (for details, see the Custom Extension table below)

Table de gravité pour les événements Windows :

Table d’extension personnalisée pour les événements Windows dans Azure Stack Hub :

Mappage CEF pour les alertes créées

* Signature ID: Microsoft Azure Stack Hub Alert Creation : FaultTypeId
* Name: FaultTypeId : AlertId
* Severity: Alert Severity (for details, see alerts severity table below)
* Extension: Custom Extension Name (for details, see the Custom Extension table below)

Tableau de gravité des alertes :

Table d’extension personnalisée pour les alertes créées dans Azure Stack Hub :

Mappage CEF pour les alertes fermées

* Signature ID: Microsoft Azure Stack Hub Alert Creation : FaultTypeId
* Name: FaultTypeId : AlertId
* Severity: Information

L’exemple suivant montre un message syslog avec une charge utile CEF :

2018:05:17:-23:59:28 -07:00 TestHost CEF:0.0|Microsoft|Microsoft Azure Stack Hub|1.0|3|TITLE: User Account Created -- DESCRIPTION: A user account \<TestUser\> was created for \<TestDomain\>. It's a potential security risk. -- REMEDIATION: Please contact Support. Customer Assistance is required to resolve this issue. Do not try to resolve this issue without their assistance. Before you open a support request, start the log file collection process using the guidance from https://aka.ms/azurestacklogfiles|10

Types d’événements Syslog

Le tableau répertorie tous les types d’événements, événements, schéma de message ou propriétés qui sont envoyés via le canal syslog. Le commutateur détaillé d’installation ne doit être utilisé que si les événements d'information Windows sont nécessaires pour l'intégration SIEM.

Étapes suivantes

stratégie de maintenance Azure Stack Hub