mardi 20 janvier 2015

Comment mettre à mal toute la sécurité du SI : le mot de passe administrateur

Et hop,

me revoilà pour un nouvel article:

Le mot de passe administrateur!

J'entends souvent: il faut que l'utilisateur soit administrateur de son poste, qu'il soit "autonome".

Ou encore que le mot de passe d'administrateur du domaine est connu par d'anciens salariés...

Bref autant de situations à fort risque, avec un SI impossible à gérer et pérenniser à la clé.

Petit rappel concernant le mot de passe administrateur local du poste:

Sur les postes Windows, le compte "administrateur" est désactivé depuis Windows Vista, et le premier utilisateur créé est un utilisateur membre du groupe "administrateurs" (administrators en anglais, si vous utilisez des fichiers xml pour la création automatique des users).

Ceci pour plusieurs raisons:
  • Une attaque par bruteforce nécessite déjà de connaître le nom d'utilisateur en plus du mot de passe.
  • Sur la plupart des systèmes XP, en exécutant un démarrage en mode sans échec, miraculeusement le compte administrateur apparaissait, et aucun mot de passe n'était défini sur ce compte. Donc nous étions administrateur sans même connaitre un seul mot de passe de la machine, ni aucune compétence en hacking.
  • le SID de l'administrateur est connu et fini par 500, donc idéal pour quelqu'un qui espionnerait un réseau en vue d'obtenir les privilèges admin.
  • ...
Bref, vous avez compris, le compte administrateur local n'a aucun intérêt pour vous, si ce n'est créer une faille de sécurité dans votre réseau, d'où le fait qu'il ait été désactivé par défaut.
Inutile donc de le réactiver comme je le vois trop souvent!

J'en profite pour rappeler que les comptes locaux sont stockés dans une base SAM, qui sert à l'authentification, et qu'il est très simple de modifier le mot de passe le mot de passe de n'importe quel utilisateur d'une machine locale. Il suffit d'environ 30 secondes pour mettre le mot de passe que l'on souhaite, ce n'est donc pas une sécurité, plus une protection basique.

Maintenant attaquons nous au cœur du sujet, à savoir le mot de passe administrateur du domaine, ou de l'entreprise.

Cette fois s'attaquer au stockage des mots de passe, comme on le ferait en local avec une base SAM, est une toute autre affaire.
On utilise une authentification Kerberos, et les comptes sont stockés dans l'AD.


Dans cette configuration, la faille est humaine, puisque bien souvent le mot de passe administrateur du domaine est donné aux techniciens, aux sociétés extérieures qui viennent installer un logiciel spécifique, au stagiaire qui sort à peine de l'école, au beau frère qui connaît bien l'informatique car il a facebook à la maison...bref à n'importe qui.

Règle numéro 1: 
Le mot de passe admin du domaine n'est connu que par vous seul! Vous fournissez une copie au dirigeant de l'entreprise pour qu'il le stocke dans un endroit sécurisé, type coffre fort de l'entreprise.

Règle numéro 2:
Vous créez un compte spécifique d'administration pour chaque utilisateur, avec les droits associés. Si un utilisateur ne doit s'occuper que des sauvegardes, il est inutile de lui donner des privilèges supérieurs aux actions qu'il a à accomplir (je ne parle même pas de la confidentialité ni de l'intégrité des données).

Exemple: Alex aura son compte alex.machin@domain.local, et son compte alex.machinADMIN@domain.local. Comme cela pour les opérations courantes, il utilisera son compte "normal", et quand il aura besoin d'une élévation de privilèges il utilisera son compte "admin".

Règle numéro 3:
La règle numéro 2 s'applique à tous, même (surtout) à vous!

Règle numéro 4:
Dès qu'un utilisateur quitte la société, on supprime ses deux comptes, celui d'utilisation classique et celui d'administration.

Règle numéro 5:
Pour les applications qui ont besoin de fonctionner avec des privilèges élevés, il est nécessaire d'utiliser les comptes de service. Ou alors alternative peu pratique, mais fonctionnelle et sécurisée, on créé un compte par application.

Règle numéro 6:
On applique la règle numéro 1! :)

Voilà ça peut paraître peu, et évident, pourtant dans la grande majorité des organisations ces simples règles basiques ne sont pas respectées, et lorsqu'un salarié quitte l'entreprise, ou lorsqu'une attaque se présente, on commence seulement à se poser des questions.

Je vous laisse donc méditer sur ce sujet, en attendant les prochains articles pour avoir un SI parfait et maîtrisé.


vendredi 2 janvier 2015

IGDLA, où comment gérer l'imbrication de groupes sous Windows

Et hop, mon premier article...
Je devais expliquer à mes élèves comment gérer des groupes, les étendues, et comment donner des permissions à des utilisateurs sur des ressources.

Il existe pléthore de sites traitant de ce sujet, mais hélas je n'ai trouvé aucun article qui était à la fois simple, explicite, compréhensible facilement, et "à jour".
Voilà pourquoi je dégaine ma cyberplume.

Comment gérer les accès à des ressources dans un système d'exploitation?

Il y a plusieurs manières de faire, celles pratiquées par la plupart des entreprises, et la bonne!

Ici je ne vais pas expliquer comment fonctionne un groupe, ni quelles étendues utiliser, juste comment bien les nommer et gérer ceux-ci.
Je vous renvoie à un article (en anglais) beaucoup plus exhaustif si vous voulez tout connaitre des groupes:
Ce que je vois (trop) souvent, ce sont des droits donnés à des utilisateurs directement...C'est franchement une solution d'amateur, car c'est impossible à gérer! En plus bonjour la compétence de la personne qui a mis ça en place...

Ce que je vois également, ce sont des groupes domaine local...mais qui n'ont ni un nom explicite, ni de différenciation entre la lecture et l'écriture. Il existe toujours dans ce cas là des utilisateurs avec des droits nominatifs sur une ressource, car ils sont "seuls" à occuper une fonction dans l'entreprise par exemple...
Évidemment il est nécessaire de créer un groupe même si l'utilisateur est unique...il est probable qu'il parte en congés, qu'un collaborateur rejoigne l'entreprise, etc.
Dans ce cas l'ajout d'une personne au groupe existant est beaucoup plus simple.

Les Best Practices:

Heureusement il existe des best practices, qui rendent la vie l'administration de votre système beaucoup plus facile.

Premier point, le nommage des groupes de sécurité:

Il est nécessaire d'avoir des noms qui permettent en un clin d’œil de savoir les éléments suivants:
  • Quelle est la portée du groupe.
  • A qui s'adresse le groupe.
  • A quoi il va donner accès.
  • Quels droits effectifs il va donner sur cette ressource.
 Exemple:
DL_Comptables_Exercices comptables_RW
Je sais donc identifier que ce groupe est un groupe domaine Local, qui est composé des comptables, qui va donner des droits en Lecture Écriture (ReadWrite) sur mon dossier Exercices comptables.

IGDLA? I Go Direction Los Angeles?

Maintenant que nous avons des noms de groupes explicites et qui répondent à une règle de nommage, voici la logique d'imbrication des groupes à respecter, j'ai nommé IGDLA! (ou IGUDLA dans une organisation multidomaines).

Identité
Global (étendue du groupe)
Domaine Local (étendue du groupe)
Accès

Graphique issu du cours officiel Microsoft 22-410 , modifié par mes soins.


Pour reprendre le graphique, une identité (user par exemple) est membre d'un groupe global "ventes", qui est lui même membre d'un groupe "ACL_Sales_Read", qui a un accès en lecture sur un dossier du système de fichier.

En combinant cette règle avec la règle de nommage précédente, nous aurions un utilisateur, disons Pierre, membre du groupe global "G_Commerciaux" (dans ce cas pas de précision de la cible de l'ACL car il n'y en aura aucune sur ce groupe, c'est le groupe domaine local qui la possèdera), qui est lui même membre du groupe "DL_Commerciaux_Sales_R".

Dans le cas d'une forêt multidomaine, nous intercalerions un groupe Universel entre le groupe global et le groupe domaine local.
Attention toutefois, à utiliser avec parcimonie, un groupe universel est dupliqué dans le catalogue global et est répliqué dans tous les domaines, ce qui peut entrainer des volumes importants sur le long terme. 

Prenons l'exemple d'une holding qui possède plusieurs sociétés (donc plusieurs domaines), avec des comptables dans les deux sociétés.
Les comptables ont besoin d'accéder à un dossier commun une fois le bilan finalisé.
Nous aurions donc un groupe "U_Comptables" qui contiendrait des groupes globaux "G_Comptables" de chaque domaine, et qui serait contenu dans un groupe "DL_comptables_bilans annuels_RW".

Ainsi, les comptables de tous les domaines auraient un accès effectif au dossier "bilans annuels", sans trop surcharger le catalogue global, le tout de manière transparente pour l'administrateur système, qui saurait en un clin d’œil qui a des droits effectifs sur cette ressource.

Pour résumer donc:
  • Pas d'accès à des ressources par des utilisateurs, uniquement à des groupes de sécurité.
  • Un nom explicite pour les groupes de sécurité, qui permette de quasiment tout savoir en un instant, même si nous ne sommes pas la personne qui a mis en place la sécurité.
  • Une imbrication des groupes pour faciliter la gestion.
  • Une utilisation des groupes universels qu'en cas de nécessité.
  • Une utilisation des groupes globaux pour regrouper les fonctions ou lieux géographiques par exemple.
  • Une utilisation des groupes Domaine Locaux pour assigner des droits d'accès effectifs sur des ressources. 
J'espère que ces conseils vous seront utiles, et j'en profite pour remercier Nicolas, qui m'a fait gagner des heures lors de la reprise d'une arborescence, grâce à des groupes bien nommés et identifiés! :)

A Bientôt!

Hello World

Bonjour à tous, et à toutes!

Ça y est, un blog de plus sur la toile...Des bits en plus à référencer, sauvegarder, traiter, analyser...des enregistrements DNS ajoutés...une infrastructure à imaginer, à maintenir, à faire évoluer, bref du travail pour nous les informaticiens.

Ce blog ne traite pas d'une technologie en particulier, mais est le reflet de mon quotidien d'ingénieur système et réseau, de chef de projet, mais également de formateur sur les technologies Microsoft.

Vous trouverez donc dans ce blog des astuces, des tutoriels, des coup de gueule aussi, des retours d'expérience également, et plus largement tout ce qui a un rapport avec les nouvelles technologies.

Je crois en l'innovation, l'innovation dans les technologies, les usages, mais également l'innovation organisationnelle, fonctionnelle, structurelle.
Je suis persuadé qu'on peut chacun à son niveau arriver à travailler avec plaisir et contribuer à améliorer les choses sans cesse...

Je crois également en la formation, le partage de connaissance, la montée en compétences... tout le monde a à y gagner, aussi bien d'un point de vue personnel, que d'un point de vue professionnel.
Mieux vaut former un salarié, et qu'il parte ensuite, que de ne pas le former et qu'il reste...
Je rajouterais qu'un salarié qu'on fait monter en compétences, qui est valorisé, qui progresse avec l'équipe, est un salarié qui préférera rester plutôt que de s'en aller.

J'éprouve le plus grand plaisir à apprendre, mais également à restituer ce que j'ai appris, mes connaissances, et surtout mon expérience pratique sur le terrain du quotidien.

Bref je ne vais pas raconter ma vie ici, mais plutôt partager avec vous toute info qui pourrait être utile pour la découverte de technologies.

Sur ce, je vous dis à très bientôt, et n'hésitez pas à faire comme moi, apprenez, partagez, échangez, remettez en cause, progressez, buvez, vivez!

Pierre