Chaque date et les jalons doivent être réalistes dans un exercice de sécurisation de son identité.
Dans un projet comme Active Directory, les dates sont certes importantes, peu importe les tâches : déploiement ou sécurisation.
Mais, la sécurisation elle-même est cruciale pour la protection de l’infrastructure informatique, au niveau global.
De ce fait, la remédiation ne peut être une simple histoire de date uniquement !
Une fois de plus, la date d’échéance relative à une correction tardive est toujours gonflante puisqu’elle peut être anticipée ou évitée 🙈
Sécuriser son IDP
Il faut prendre soin de son IDP, cela va de soi.
Aactive Diretory, souvent notre premier IDP, se trouve à gérer les identités, les accès ainsi que les droits dans un réseau d’entreprise. Logiquement, sa sécurisation commence dès la conception.
En conséquence, sa remédiation et/ou sa sécurisation tardive(s) soulève(ent) de nombreuses questions et problématiques ; cela, en raison de la complexité des dépendances entre les systèmes et les risques de dysfonctionnements, e.g. si les configurations sont modifiées de manière inappropriée, la production peut être lourdement impactée/handicapée. Une date ne peut être un prétexte pour cela !
C’est pourquoi, il faut être logique(s) et pragmatique(s), puisqu’une simple décision sur papier peut ne pas être compatible avec la vraie vie d’une exploitation.
Etant donné que le papier ne refuse pas l’encre, la posture globale avec une ambition de sécurisation est à adopter avec subtilité.
Être pragmatique(s), c’est comprendre et accepter :
- La complexité de la structure Active Directory et de son interaction avec la cryptographie (PKI ADCS par exemple),
- La bonne gestion des droits et des privilèges,
- Le contrôle des accès et de l’authentification,
- La sécurisation des contrôleurs de domaine #dc, #coreservice
- L’obsolescence de certains protocoles et le cycle de vie des comptes #iam … on peut imaginer les adhérences avec les applications,
- La nécessité des audits continus,
- La protection contre les attaques (mouvement latéraux/verticaux, usurpation et cætera),
- Les plans de récupération après sinistre PCA, PDAI et PRA,
- La nécessité d’une sensibilisation des utilisateurs et surtout des administrateurs,
- La difficulté de certains points de remédiation, non technique et hors #ad.
Finalement, comprendre et acceper, c’est tout simplement être réaliste dès le départ ; c’est à dire, dès la conception d’Active Directory et dès la définition de la politique de sécurisation d’une infrastructure. Si cette dernière a un côté historique, il faut être réaliste dès la prise de décision quant à la sécurisation.
Remédiation, stratégie et date
De toute évidence, la remédiation et la sécurisation nécessitent une approche globale et transverse. Il faut donc une vision globale et un bon niveau technique.
L’exercice n’est pas que technique ; et, il combine une série de contrôles. Une vraie politique de sécurité (souvent manquante (sic)) et des mesures de formation sont nécessaires.
Active Directory étant un élément central des infrastructures IT, son bon niveau de sécurité doit être pensé de manière stratégique.
La stratégie implique tout le monde sans exception, je pense particulièrement aux VIP qui ne sont que des utilisateurs comme les autres. Ces mêmes VIP ne doivent surtout pas faire des choix diamétralement opposés aux recommandations techniques … à moins que ces VIP soient des experts en la matière. Je ne demande qu’à voir 🤐
Pour les infrastructures avec d’énormes dettes historiques, une date reste une date. C’est bien d’avoir des jalons, mais à l’impossible nul n’est tenu ! De surcroit, quand la stratégie vient timidement pas à pas 🙈
Imposer une date sans analyse revient simplement à stresser la production, rien d’autre.
Dans un projet de sécurisation Active Directory, le problème n’est jamais Active Directory.
Annuaire et applications
J’ose espérer que les experts Active Directory ne sont pas suicidaires jusqu’au point de vouloir corriger chaque application 💀
Si l’état d’une infrastructure part à la dérive, c’est qu’il y a des défauts majeurs omniprésents depuis longtemps, e.g. l’absence de stratégie, aucune politique claire donc aucune gouvernance.
L’intégration d’une solution, quelle qu’elle soit, s’étudie sérieusement si les architectes travaillent convenablement.
Un annuaire est déployé pour des raisons liées au business, et tout le monde s’accorde à sécuriser son business instinctivement sans trop sourciller. Comme l’IT supporte le business, il est où le problème pour s’investir sérieusement ? Seuls les ignares pensent que l’IT est un centre de coût ! 🤣
Evidement que l’IT est un centre de profit 👈
Les applications restent la plupart du temps la source du décalage du niveau de sécurité par rapport à l’état de l’art. Certaines d’entre elles sont parfois historiques. Tenter de sécuriser Active Directory sans se concentrer sur ses applications est donc simplement irréaliste.
Quelque part, on peut s’affranchir des dates butoirs arbitraires de façon simple :
- Assurer sérieusement les exercices d’architecture avant d’agir,
- Tendre vers l’état de l’art dans chacune de ses analyses et réflexions,
- Refuser les demi-mesures,
- Faire de la sécurité un exercice permanent.
Conslusion
Le design et le suivi ont leur importance dans la sécurisation, peu importe la taille de l’infrastructure.
Aussi, la sécurité n’est pas une histoire d’agenda, d’argent ou de mode. La sécurité est un prérequis de ma fenêtre et tout part du bon sens avant tout.
L’équilibre entre le business et la technique est déterminant pour garantir le succès et l’image d’une entreprise. La technique ne doit pas par conséquent être du grand n’importe quoi, simplement pour satisfaire la direction avec ses dates farfelues.
Pour faire de sa sécurité informatique un sujet passionnant et objectif, il faut avoir le bon mindset avant tout.