Sophos SIEM : connecter Azure Event Hubs et les logs Blob

Sophos Next-Gen SIEM ingère des sources personnalisées via Azure Event Hubs ou Azure Storage Account. Event Hubs fournit un flux ; pour Storage, une Azure Function fournie lit les fichiers d’un chemin Blob et les transmet. Ces configurations ne sont pas interchangeables.

Les deux exigent une souscription Next-Gen SIEM, une souscription Azure active et les droits nécessaires dans Sophos Fusion/Azure. Une source préparée doit réellement écrire les journaux dans le hub ou conteneur. La configuration générale exige un rôle Admin/Super Admin adapté ; limiter les droits Azure aux ressources et au déploiement autorisés.

Le guide des transports aide au choix. Ce chemin n’est ni un collector syslog hébergé dans Azure ni un remplacement automatique d’une intégration cloud ou Microsoft 365 existante.

Event Hubs : prérequis et accès

Les tiers Standard, Premium et Dedicated sont pris en charge, pas Basic. La documentation Sophos actuelle exige un hub accessible depuis Internet et mentionne toutes les adresses IPv4. C’est un prérequis architectural de sécurité, pas une recommandation générale d’exposer un hub privé existant. En cas de conflit avec les règles réseau, clarifier avec responsables et Sophos avant de modifier le pare-feu.

Les catégories choisies doivent déjà être envoyées au hub, par exemple via les diagnostics Azure Monitor. La source détermine les données fournies ; une connexion réussie n’active pas rétroactivement tous les audits.

1. Dans Azure, ouvrir le Event Hubs namespace voulu et noter Host name dans Overview.
2. Sous Entities > Event Hubs, ouvrir le bon hub et noter Name, sans confondre namespace et hub.
3. Dans le hub, ouvrir Settings > Shared access policies > Add et créer une policy dédiée à Sophos.
4. Choisir Listen. Le parcours de lecture décrit n’exige pas de droits supplémentaires d’envoi ou d’administration.
5. Ouvrir la policy et protéger sa Primary Connection String. Elle contient un secret ; namespace, policy et éventuel EntityPath doivent correspondre au hub visé.

Ne pas copier cette chaîne réelle dans tickets ou KB. Documenter responsable et procédure de rotation prise en charge par Azure.

Connecter Event Hubs dans Sophos Fusion

1. Ouvrir Security Operations > Integrations > Marketplace > Custom.
2. Sous Azure Event Hubs, choisir Set Up, puis un nom unique dans Add an integration.
3. Renseigner les valeurs vérifiées dans Event Hubs Namespace Hostname, Event Hubs Name, Event Hubs Primary Connection String.
4. Créer avec Done et vérifier Configured integrations.
5. Suivre un nouvel événement autorisé jusqu’au hub puis Sophos : source, tenant, heure et champs doivent correspondre.

Le consumer Sophos utilise dynamiquement les partitions disponibles, jusqu’à 200 partitions. Ce n’est pas une garantie de débit. Le responsable du hub dimensionne le serveur. ServerBusyException dans API Query Log peut signaler une limite de débit. Vérifier volume et capacité avant d’ajouter partitions ou consumers ; Sophos renvoie au support pour augmenter les consumers parallèles. Recréer sans cesse l’intégration ne corrige pas la capacité.

Storage : chemin Blob et plan Function

Il faut un Storage Account, un Blob Container contenant les journaux et un plan Azure Function pris en charge. Isolated est exclu. Sophos documente :

• Basic : B1, B2, B3.
• Dynamic : Y1.
• Premium : P0V3, P1MV3, P1V2, P1V3, P2MV3, P2V2, P2V3, P3MV3, P3V2, P3V3, P4MV3, P5MV3.

Cette liste date du 5 octobre 2026. Vérifier offre, région, capacité et coûts avant déploiement. Un tier Event Hubs ne constitue pas le choix du plan Function.

Data Source Key désigne le dossier où les journaux sont créés dans le conteneur. Pour MicrosoftInsights/2024-02-03/02hr/part=01/00004.json, Sophos donne MicrosoftInsights comme clé. Employer son propre préfixe, pas automatiquement cet exemple ni le nom complet du fichier. Un mauvais préfixe peut exclure des fichiers utiles ou ingérer d’autres données.

Déployer Storage et Azure Function

1. Identifier compte Storage, conteneur, préfixe et plan dans le bon compte Azure. Vérifier d’abord un objet de test récent dans le chemin prévu.
2. Dans Sophos, ouvrir Security Operations > Integrations > Marketplace > Custom, puis Set Up sous Azure Storage Accounts.
3. Saisir nom d’intégration, Storage Account Name, Function App Name et Data Source Key. Le nom de fonction décrit l’usage, par exemple ApplicationMetierLogsForwarder, sans remplacer le contrôle des ressources créées.
4. Choisir Azure Function Service Plan Type, Azure Function Service Plan Code et Azure Function Service Plan Num Workers. Valeur documentée par défaut : 1 ; maximum 3 pour Basic B2/B3. Ajouter des workers n’est pas un dépannage universel.
5. Avec Done, générer le modèle ARM AzureFunction.json, téléchargé automatiquement. Le protéger et vérifier ressources, droits et coûts avant exécution.
6. Dans Azure, ouvrir le déploiement d’un modèle personnalisé, choisir Build your own template in the editor, charger AzureFunction.json, puis Save.
7. Choisir ou créer la Resource Group. Le Storage Account peut résider dans une autre subscription ou Resource Group que la Function. Adapter Storage Account Subscription ID et Storage Account Resource Group uniquement selon cette différence réelle.
8. Vérifier avec Review + Create, puis Create après validation interne. Contrôler déploiement, Function créée et intégration Sophos.

La source doit continuer d’écrire dans le bon conteneur. Un ARM réussi ne prouve ni ce chemin ni la transmission. Ne pas supposer l’ingestion rétroactive complète des anciens fichiers ; confirmer l’historique voulu séparément.

Valider le flux et isoler les erreurs

Sophos cite Azure Commercial Cloud et les environnements documentés US Government/DoD/GCC/GCC-High. Cela ne garantit pas tous les tenants ou régions ; vérifier environnement et endpoint avant déploiement.

Documenter un événement nouveau et inoffensif pour chaque transport. Pour Event Hubs, contrôler source, flux, policy Listen et connexion ; pour Storage, chemin Blob puis déploiement/erreurs Function. Comparer ensuite statut et méthode de recherche confirmée dans Sophos.

Les types pris en charge sont normalisés selon leur intégration ; d’autres peuvent arriver dans generic. Le guide SIEM des parsers et limites de détection décrit les contrôles supplémentaires. Un connecteur vert, fichier ou compteur Event Hubs ne prouve ni normalisation complète ni détection. Pour des événements partiellement absents, examiner catégories, période et champs avant d’élargir les droits.

Préparer pause et retrait

Documenter les sources partageant hub, conteneur, policy ou Function. Suspendre par la procédure d’export prise en charge pour la source et vérifier le résultat. Ne pas supprimer un hub ou compte Storage partagé pour cela.

Après clarification de l’historique, preuves, dépendances et redémarrage, retirer connexion dédiée, ressources inutiles et secrets selon leurs procédures. La suppression Sophos ne garantit ni effacement historique ni fin de tous les coûts Azure. Après retour arrière, revalider l’ancien chemin nécessaire avec un événement de test.