Quels dossiers pouvez-vous exclure de l’antivirus pour SQL Server ?
Une exclusion pour une charge de travail et un hôte non protégé sont deux décisions différentes. Limitez l’exception à l’interaction démontrée et conservez les autres contrôles.
Deux phrases sont employées l’une pour l’autre dans les revues de bases de données, et elles veulent dire des choses très différentes. L’une affirme qu’une charge de travail précise a besoin d’une exception précise ; l’autre affirme que l’hôte n’a plus besoin de protection de point de terminaison. La première est une décision d’ingénierie délimitée, la seconde est un risque sans propriétaire. Les séparer est toute la tâche, et elle commence par ce que le serveur fait réellement.
Deux phrases qui se ressemblent
Une exception nomme un chemin, un processus ou un type de fichier et en donne la raison. Un abandon retire un contrôle d’une machine et en donne la raison à la place. Les deux peuvent produire des chiffres de performance comparables et des postures de sécurité totalement différentes.
Un serveur de base de données est un mauvais candidat à l’abandon parce qu’il stocke les données dont tout le reste dépend. Il est aussi un mauvais candidat pour une politique de niveau poste de travail, car l’analyse de fichiers qu’une base de données garde ouverts provoque des problèmes qu’un poste de travail ne voit jamais. La position honnête se situe au milieu, et elle doit être argumentée plutôt que supposée. C’est cet argument qu’une revue doit consigner.
Comparez l’exception et l’abandon
Placez les deux options côte à côte sur quatre points : ce qui reste protégé, ce qui devient exposé, qui détient la décision et quelles preuves la soutiennent.
Une exception délimitée laisse le reste de l’hôte sous la même protection qu’avant, garde la décision chez un propriétaire nommé et repose sur un symptôme reproduit. Un abandon retire la protection de tout et repose généralement sur l’affirmation que la machine n’est pas exposée. Cette affirmation doit résister aux rôles réels du serveur, car les partages de fichiers, les serveurs liés, les tâches de l’agent et les transferts de fichiers administratifs créent tous une exposition qu’un pare-feu ne voit jamais. Une seule colonne de la comparaison ci-dessous survit à un changement de propriétaire, car elle consigne ce qui a été décidé et pourquoi.
| Point | Scoped exception | Blanket exclusion |
|---|---|---|
| Coverage | Only the named paths or processes | The whole host |
| Evidence needed | A reproduced interaction | An argument about exposure |
| Owner | A named reviewer with a date | Usually nobody |
| Behaviour after an update | Reviewed again | Silently inherited |
Limitez une exception à l’interaction démontrée
Partez du symptôme plutôt que d’une liste. Un conflit d’accès aux fichiers, une pression sur les ressources et une requête lente se présentent différemment dans les journaux et mènent à des corrections différentes. Reproduisez le symptôme avec la protection active, puis identifiez le chemin ou le processus exact concerné.
Les candidats typiques sont les fichiers de base de données, les fichiers journaux, les sauvegardes et les fichiers de catalogue de texte intégral, et les recommandations de Microsoft sur les logiciels antivirus et SQL Server restent la référence pour la version déployée et le produit de sécurité. Ne copiez pas une liste depuis un autre serveur et ne supposez pas qu’un seul nom de service couvre chaque composant installé. La plus petite exception qui traite l’interaction démontrée est celle à proposer. Tout ce qui est plus large a besoin de son propre argument.
Get-MpPreference | Select-Object -ExpandProperty ExclusionPath
Get-MpComputerStatus | Select-Object AntivirusEnabled, RealTimeProtectionEnabledVérifiez cette liste au regard du rôle du serveur, car une exception ajoutée pour un incident tend à rester pour toujours. Une brève note à côté de chaque entrée suffit à rendre le prochain audit possible.
Conservez les contrôles réseau et d’identité
Une exception de point de terminaison ne dit rien sur qui peut atteindre la base de données. La politique du pare-feu devrait encore limiter quelles sources peuvent ouvrir une session SQL ou d’administration, et les comptes applicatifs devraient encore borner ce que ces sessions peuvent faire.
Un VPN appartient à la même conversation et est souvent mal utilisé comme argument. Restreindre le chemin d’accès ne valide pas les fichiers, les scripts ou les requêtes qui arrivent par lui. Un tunnel chiffré est aussi opaque à un capteur réseau, donc la visibilité qu’un capteur vous donne n’est pas celle qu’un agent d’hôte vous donne. Ce sont des flux de preuves différents, et aucun ne remplace l’autre. La gestion des correctifs, des outils d’administration de confiance et un chemin de restauration éprouvé restent des responsabilités distinctes avec leurs propres propriétaires. L’hygiène des rôles en fait partie aussi : la navigation, les téléchargements et les tâches de partage de fichiers sans rapport devraient rester hors de l’hôte de base de données, sauf si son propriétaire les a explicitement acceptés.
Testez le changement, puis assumez-le
Testez avec une charge de travail représentative et les contrôles de sécurité qui comptent, puis comparez la stabilité, le débit et la protection continue plutôt que seulement l’erreur d’origine.
Get-MpThreatDetection | Sort-Object InitialDetectionTime -Descending | Select-Object -First 5
Get-WinEvent -LogName 'Microsoft-Windows-Windows Defender/Operational' -MaxEvents 20Conservez un chemin de retour arrière pris en charge et un propriétaire qui réexamine l’exception après les mises à jour de composants ou de produit, car une exception écrite pour une build peut survivre à la raison de son existence. Consignez la portée, la raison et la date de revue au même endroit que l’enregistrement de build du serveur. Sans cela, le prochain relecteur hérite d’une liste sans argument derrière elle. Une exception n’est défendable que tant que sa raison est encore vraie.