Auditrice securite infrastructure
Comment auditer la securite de votre SharePoint Server en 7 etapes
Avec la recente exploitation active de CVE-2026-45659, auditer la securite de votre SharePoint Server n'est plus optionnel. Voici la methodologie en 7 etapes que nous appliquons chez WebGuard Agency — adaptable a toute taille d'infrastructure.
Cet audit couvre les versions SharePoint Server Subscription Edition, 2019 et Enterprise 2016 en deploiement on-premises. SharePoint Online est gere par Microsoft et ne necessite pas le meme type d'audit infrastructure — mais la revue des permissions et configurations reste pertinente.
Vue d'ensemble : les 7 etapes de l'audit
— Etape 1 : Inventaire complet de votre infrastructure SharePoint
Avant toute analyse de securite, vous devez savoir exactement ce que vous protegez. Un inventaire incomplet est la premiere cause de failles non detectees : le serveur SharePoint oublie, l'environnement de test non patche, la ferme legacy jamais decommissionnee. Commencez par documenter l'integralite de votre infrastructure SharePoint.
Connectez-vous a l'Administration Centrale SharePoint et relevez les informations suivantes : version et edition (Subscription Edition, 2019, Enterprise 2016), numero de build exact, nombre de serveurs dans la ferme, roles de chaque serveur (frontend, application, recherche, base de donnees), et topologie reseau. Utilisez la commande PowerShell suivante pour obtenir la version precise :
# Version de la ferme SharePoint
(Get-SPFarm).BuildVersion
# Serveurs de la ferme et leurs roles
Get-SPServer | Select Name, Role, Status | Format-Table -AutoSize
# Applications web
Get-SPWebApplication | Select Name, Url, ContentDatabases | Format-List
N'oubliez pas les environnements hors production. Les serveurs de developpement et de pre-production sont souvent negliges dans la gestion des correctifs, mais ils peuvent fournir un point d'entree aux attaquants s'ils sont accessibles depuis le reseau interne. Documentez egalement les solutions tierces installees (workflows, composants WebPart personnalises, solutions farm) car elles peuvent introduire des vulnerabilites specifiques.
- ☑ Version et edition de chaque instance SharePoint
- ☑ Numero de build exact (comparaison avec les derniers KB)
- ☑ Topologie : serveurs, roles, bases de donnees
- ☑ Environnements hors production (dev, test, preprod)
- ☑ Solutions tierces et composants personnalises deployes
- ☑ Comptes de service (ferme, app pool, crawl, contenu)
— Etape 2 : Audit des correctifs de securite et mises a jour
L'audit des correctifs est critique — c'est souvent la ou se trouvent les vulnerabilites les plus graves et les plus facilement exploitables. Le cas recent de CVE-2026-45659 (ajoutee au catalogue CISA KEV le 1er juillet 2026 apres exploitation active) illustre parfaitement ce risque : le correctif etait disponible depuis mai 2026, mais les organisations qui ne l'avaient pas applique se sont retrouvees exposees a des attaques reelles.
Comparez le numero de build de votre SharePoint avec les derniers correctifs de securite publies par Microsoft. Le site officiel SharePoint Updates (docs.microsoft.com) maintient un historique complet des mises a jour cumulatives (CU) et des correctifs de securite pour chaque version. Verifiez egalement que les prerequis sont a jour : .NET Framework, Windows Server updates, SQL Server patches.
# Verifier les mises a jour installees
Get-SPProduct -Local | Select ProductName, PatchableUnitDisplayName, LatestPatch
# Comparer avec la base de correctifs
# Verifier le Patch Level actuel
(Get-SPFarm).BuildVersion.ToString()
# Lister les KB installes sur le serveur
Get-HotFix | Where-Object { $_.HotFixID -like "KB5*" } | Sort InstalledOn -Descending | Select -First 20
Portez une attention particuliere aux correctifs de securite des 6 derniers mois. Toute vulnerabilite non patchee avec un score CVSS superieur a 7.0 doit etre signalee comme critique dans votre rapport d'audit. Les vulnerabilites figurant au catalogue CISA KEV doivent etre traitees avec la plus haute priorite, independamment de leur score CVSS.
— Etape 3 : Revue des permissions et du modele d'acces
Le modele de permissions SharePoint est puissant mais complexe, et sa mauvaise gestion est une source majeure de risques. Des permissions trop larges augmentent la surface d'attaque (comme pour CVE-2026-45659 ou un simple Site Member peut exploiter la faille), tandis que des permissions mal documentees rendent la detection d'acces illegitimes quasi impossible.
Commencez par une cartographie des niveaux de permissions : qui sont les administrateurs de collection de sites, les proprietaires de sites, les membres, les visiteurs ? Identifiez les comptes avec des permissions elevees qui ne devraient pas les avoir (accumulation de droits au fil du temps), les groupes Active Directory trop larges utilises dans les permissions SharePoint, et les liens de partage externes non controles.
# Lister les administrateurs de collection de sites
Get-SPSite -Limit All | ForEach-Object {
Write-Output "$($_.Url) - Admin: $($_.Owner.LoginName) - SecondAdmin: $($_.SecondaryContact.LoginName)"
}
# Identifier les utilisateurs avec Full Control
$web = Get-SPWeb "https://sharepoint.votreentreprise.com"
$web.RoleAssignments | ForEach-Object {
$_.RoleDefinitionBindings | Where-Object { $_.Name -eq "Full Control" } | ForEach-Object {
Write-Output "$($_.Parent.Member.LoginName) - Full Control"
}
}
# Verifier les permissions heritees vs explicites
Get-SPWeb -Site "https://sharepoint.votreentreprise.com" -Limit All |
Where-Object { -not $_.HasUniqueRoleAssignments } | Select Url
Verifiez egalement les comptes de service : le compte de la ferme SharePoint, les comptes des pools d'applications, et le compte de crawl. Ces comptes ont souvent des privileges excessifs sur Active Directory ou SQL Server. Appliquez le principe du moindre privilege : chaque compte ne doit disposer que des droits strictement necessaires a son fonctionnement.
— Etape 4 : Hardening de la configuration SharePoint
Le hardening consiste a securiser la configuration de SharePoint en desactivant les fonctionnalites inutiles, en restreignant les protocoles et en appliquant les bonnes pratiques de securite recommandees par Microsoft et l'ANSSI. C'est souvent l'etape ou l'on decouvre le plus d'ecarts entre la configuration reelle et les bonnes pratiques.
Points de verification prioritaires :
| Point de controle | Configuration securisee | Risque si absent |
|---|---|---|
| ViewState MAC | Actif + cle unique par ferme | Deserialization RCE |
| Custom errors | customErrors mode="On" en prod | Fuite d'informations |
| HTTPS/TLS | TLS 1.2+ obligatoire, HTTP redirige | Interception MitM |
| En-tetes HTTP | HSTS, X-Content-Type, CSP | XSS, clickjacking |
| Inline download | AllowedInlineDownloadedMimeTypes restreint | Execution de code cote client |
| App isolation | Domaine d'apps dedie (apps.votredomaine.com) | Vol de cookies de session |
| Comptes de service | Comptes managed service (MSA/gMSA) | Compromission laterale AD |
Verifiez egalement que le reporting des erreurs detaillees est desactive en production (CallStack="false" dans web.config), que les web services inutilises sont desactives, et que la politique de mots de passe des comptes de service est robuste (longueur >= 20 caracteres, rotation reguliere ou MSA).
Besoin d'un audit professionnel de votre SharePoint ?
WebGuard Agency realise des audits de securite SharePoint complets en 3 a 5 jours : inventaire, correctifs, permissions, hardening, exposition, surveillance et rapport de remediation priorise. Premiere consultation gratuite.
Demander un devis audit SharePoint →— Etape 5 : Evaluation de l'exposition reseau
L'exposition reseau determine directement le niveau de risque de votre SharePoint Server. Un serveur accessible depuis Internet est infiniment plus expose qu'un serveur uniquement accessible depuis le LAN interne. Cette etape vise a cartographier precisement comment et par qui votre SharePoint est joignable.
Verifiez les points suivants :
- ▶Publication Internet — Votre SharePoint est-il accessible depuis Internet via un reverse proxy (HAProxy, Nginx, Apache), un WAF (F5, Imperva, Cloudflare), ou Azure AD Application Proxy ? Si oui, quels endpoints sont exposes ?
- ▶Segmentation interne — Le serveur SharePoint est-il dans un VLAN dedie ? Quels postes utilisateurs peuvent l'atteindre directement ? Y a-t-il des regles de pare-feu entre les segments ?
- ▶Ports et services — Outre les ports HTTP/HTTPS (80/443), quels autres ports sont ouverts ? SQL Server (1433) est-il accessible depuis le meme reseau ? Les ports d'administration (Administration Centrale, PowerShell remoting) sont-ils restreints ?
- ▶DNS et certificats — Les enregistrements DNS pointent-ils correctement ? Les certificats TLS sont-ils valides et pas sur le point d'expirer ? Utilisez-vous des certificats wildcards (risque en cas de compromission) ?
Pour les instances exposees a Internet, verifiez ce qui est visible depuis l'exterieur en utilisant des outils comme Shodan, Censys, ou simplement nmap depuis une adresse IP externe. Comparez la surface exposee avec ce qui devrait l'etre selon votre politique de securite. Tout ecart est une anomalie a corriger.
Zones d'exposition reseau SharePoint
— Etape 6 : Analyse des logs et capacites de surveillance
La capacite a detecter une compromission repose entierement sur la qualite de votre journalisation et de votre surveillance. SharePoint genere plusieurs types de logs qui, correctement configures et analyses, permettent de detecter des tentatives d'exploitation, des acces anormaux et des comportements suspects.
Les sources de logs a verifier :
- ▶Logs ULS (Unified Logging Service) — Journaux internes de SharePoint. Verifiez qu'ils sont actifs, que le niveau de verbosity est suffisant (Medium minimum) et que la retention est d'au moins 14 jours.
- ▶Logs IIS — Tous les acces HTTP/HTTPS. Indispensables pour detecter les requetes malveillantes, les tentatives d'exploitation de CVE et les scans automatises. Format W3C recommande avec tous les champs actives.
- ▶Windows Event Logs — Evenements de securite Windows (logon, logoff, failed logon, privilege use). Essentiels pour tracer l'utilisation des comptes de service.
- ▶SharePoint Audit Logs — Journal d'audit natif SharePoint (acces documents, modifications permissions, suppressions). Verifiez que l'audit est active sur les collections de sites sensibles.
- ▶Integration SIEM — Les logs sont-ils centralises dans un SIEM (Sentinel, Wazuh, Splunk) ? Des regles de detection specifiques a SharePoint existent-elles ?
# Verifier la configuration des logs ULS
Get-SPDiagnosticConfig | Select LogLocation, DaysToKeepLogs, LogMaxDiskSpaceUsageEnabled
# Activer l'audit sur une collection de sites
$site = Get-SPSite "https://sharepoint.votreentreprise.com"
$site.Audit.AuditFlags = [Microsoft.SharePoint.SPAuditMaskType]::All
$site.Audit.Update()
# Verifier si l'audit est active
$site.Audit.AuditFlags
L'element critique est la capacite de detection en temps reel. Sans integration SIEM et sans regles d'alerte specifiques, vos logs ne sont qu'un historique forensique — utile apres un incident mais inutile pour le prevenir. Configurez au minimum des alertes pour : les echecs d'authentification repetes, les creations de fichiers .aspx (potentiels webshells), les modifications de permissions a haut privilege, et les acces depuis des IP ou pays inhabituels.
— Etape 7 : Rapport de remediation priorise
L'audit n'a de valeur que s'il debouche sur un plan d'action concret et priorise. Votre rapport de remediation doit classer les constatations par niveau de criticite et fournir pour chaque point : la description du risque, la preuve technique, la recommandation de correction, le niveau d'effort estime et le delai de correction recommande.
Structure recommandee pour le rapport :
- C Critique (remediation < 48h) — Vulnerabilites exploitees activement (CISA KEV), exposition Internet non securisee, comptes de service compromis ou mot de passe par defaut.
- H Haute (remediation < 14 jours) — Correctifs de securite manquants (CVSS >= 7.0), permissions excessives sur des donnees sensibles, absence de MFA sur les comptes administrateurs.
- M Moyenne (remediation < 30 jours) — Configuration de hardening manquante, logs insuffisants, certificats proches de l'expiration, documentation absente.
- B Basse (remediation < 90 jours) — Ameliorations de configuration mineures, optimisations de performance liees a la securite, recommandations d'architecture a long terme.
Incluez egalement dans votre rapport une section "quick wins" identifiant les corrections a fort impact et faible effort. Par exemple : activer le MFA sur les comptes admin SharePoint, mettre a jour les certificats TLS, ou desactiver les services inutilises. Ces actions rapides demontrent une amelioration immediate de la posture de securite et motivent les equipes pour les actions plus lourdes.
Enfin, planifiez un audit de suivi dans 3 a 6 mois pour verifier que les recommandations ont ete implementees et evaluer l'evolution de la posture de securite. La securite n'est pas un projet ponctuel mais un processus continu.
— Outils recommandes pour l'audit SharePoint
| Outil | Usage | Type |
|---|---|---|
| SharePoint Management Shell | Inventaire, configuration, permissions | Natif (gratuit) |
| SPDocKit / ShareGate | Audit permissions, rapports de conformite | Commercial |
| Nmap / Nessus | Scan de ports, detection de vulnerabilites | Open source / Commercial |
| Wazuh / Microsoft Sentinel | SIEM, centralisation logs, alerting | Open source / Cloud |
| testssl.sh / SSL Labs | Audit configuration TLS/SSL | Gratuit |
— Liens utiles et ressources complementaires
- ▶SharePoint CVE-2026-45659 : faille RCE critique exploitee activement — Contexte complet de la derniere menace
- ▶Auditer l'exposition SharePoint externe en 7 etapes
- ▶Zero-Trust pour PME en 2026 : guide pratique
- ▶Methodologie d'audit de securite — Framework general WebGuard
- ▶Services WebGuard Agency — Audit, pentest, SOC manage
Vous preferez confier l'audit a des experts ?
WebGuard Agency realise des audits de securite SharePoint Server complets avec rapport de remediation priorise, chiffrage des couts de correction et accompagnement a la mise en oeuvre. Nos auditeurs interviennent sous 48h, sur site ou a distance.
Pour aller plus loin
Questions frequentes
Vous ne trouvez pas la reponse a votre question ?
Veille cybersecurite
Recevez chaque semaine les dernieres menaces, vulnerabilites et bonnes pratiques directement dans votre boite mail.
Pas de spam. Desinscription en un clic. Environ 1 email par semaine.
— Pret a renforcer votre cybersecurite ?
Rejoignez les entreprises qui font confiance a WebGuard Agency pour proteger leurs actifs numeriques. Premier audit offert.