Dois-je exposer mon Active Directory à l'Internet public pour les utilisateurs distants?
J'ai un client dont l'effectif est entièrement composé d'employés distants utilisant un mélange de Apple et PC/ordinateurs portables Windows 7.
Les utilisateurs ne s'authentifient pas pour le moment pour un domaine, mais l'organisation souhaite aller dans cette direction pour plusieurs raisons. Ce sont des machines appartenant à l'entreprise, et l'entreprise cherche à avoir un certain contrôle sur la désactivation des comptes, la stratégie de groupe et une légère prévention de la perte de données (désactiver les médias distants, USB, etc.). serait encombrant, en particulier à l'intersection d'un employé licencié et d'informations d'identification mises en cache sur une machine distante.
La plupart des services de l'organisation sont basés sur Google (courrier, fichier, chat, etc.), donc les seuls services de domaine sont DNS et l'authentification pour leur VPN Cisco ASA.
Le client souhaite comprendre pourquoi il est inacceptable d'exposer ses contrôleurs de domaine au public. De plus, quelle est une structure de domaine plus acceptable pour une main-d'œuvre distante distribuée?
Éditer:
Centrify est utilisé pour une poignée de clients Mac.
Je poste cela comme réponse principalement parce que chacun a sa propre "opinion éclairée" basée sur l'expérience, les informations de tiers, le ouï-dire et les connaissances tribales au sein de l'informatique, mais il s'agit plus d'une liste de citations et de lectures "directement" de Microsoft. J'ai utilisé des guillemets car je suis sûr qu'ils ne filtrent pas correctement toutes les opinions émises par leurs employés, mais cela devrait néanmoins s'avérer utile si vous recherchez des références authoritative directement de Microsoft.
BTW, Je pense aussi qu'il est TRÈS FACILE de dire CONTRÔLEUR DE DOMAINE == Active Directory, ce qui n'est pas tout à fait le cas. AD FS proxies et autres moyens (formulaires basés sur l'authentification pour OWA, EAS, etc.) offrent un moyen "d'exposer" AD lui-même sur le Web pour permettre aux clients de tenter au moins de s'authentifier via AD sans exposer les DC eux-mêmes. Allez sur le site OWA de quelqu'un et essayez de vous connecter et AD obtiendra la demande d'authentification sur un DC backend, donc AD est techniquement "exposé" ... mais est sécurisé via SSL et mandaté via un serveur Exchange.
Citation # 1
Avant de partir "Azure n'est pas AD" ... vous POUVEZ déployer ADDS sur une machine virtuelle Azure.
Mais pour citer les bits pertinents:
N'exposez jamais les STS directement à Internet.
En tant que meilleure pratique de sécurité, placez les instances STS derrière un pare-feu et connectez-les à votre réseau d'entreprise pour éviter toute exposition à Internet. Ceci est important car le rôle STS émet des jetons de sécurité. En conséquence, ils doivent être traités avec le même niveau de protection qu'un contrôleur de domaine. Si un STS est compromis, les utilisateurs malveillants ont la possibilité d'émettre jetons d'accès contenant potentiellement des revendications de leur choix à des applications de parties de confiance et à d'autres STS dans des organisations de confiance.
ergo ... n'exposez pas les contrôleurs de domaine directement à Internet.
Citation # 2
Active Directory - Le mystère UnicodePwd d'AD LDS
L'exposition d'un contrôleur de domaine à Internet est normalement une mauvaise pratique, que cette exposition provienne directement de l'environnement de production ou d'un réseau de périmètre. L'alternative naturelle est pour placer un serveur Windows Server 2008 avec le rôle Active Directory Lightweight Directory Services (AD LDS) en cours d'exécution dans le réseau de périmètre.
Citation # 3 - pas de la SEP ... mais toujours utile pour l'avenir
Active Directory-as-a-Service? Azure, Intune faisant allusion à un futur AD hébergé dans le cloud
En fin de compte, il n'y a pas de bonne réponse "courte" qui réponde aux objectifs de débarrasser le bureau du serveur AD en échange d'une alternative Azure. Alors que Microsoft fait preuve de complaisance en autorisant les clients à héberger les services de domaine Active Directory sur les boîtiers Server 2012 et 2008 R2 dans Azure, leur utilité n'est aussi bonne que la connectivité VPN que vous pouvez rassembler pour votre personnel. DirectAccess, tout en étant une technologie très prometteuse, a les mains liées en raison de ses propres limitations malheureuses.
Citation # 4
Les contrôleurs de domaine et les serveurs AD FS ne doivent jamais être exposés directement à Internet et doivent uniquement être accessibles via VPN
Active Directory (AD) n'a pas été conçu pour ce type de déploiement.
Les modèles de menace utilisés dans la conception du produit supposent un déploiement "derrière le pare-feu" avec une certaine quantité d'acteurs hostiles filtrés à la frontière du réseau. Bien que vous puissiez certainement durcir Windows Server pour être exposé au réseau public, le bon fonctionnement d'Active Directory nécessite une posture de sécurité nettement plus laxiste qu'un hôte renforcé pour les réseaux publics. Un lot de services doit être exposé à partir d'un contrôleur de domaine (DC) pour que AD fonctionne correctement.
La suggestion de Zoredache dans les commentaires, faisant référence en particulier à quelque chose comme OpenVPN fonctionnant comme un service à l'échelle de la machine avec authentification par certificat, pourrait bien être un bon choix. DirectAccess, comme d'autres l'ont mentionné, est exactement ce dont vous avez besoin, sauf qu'il n'a pas le support multiplateforme que vous souhaitez.
En passant: j'ai joué avec l'idée d'utiliser IPSEC en mode transport basé sur des certificats pour exposer AD directement à Internet, mais je n'ai jamais vraiment eu le temps de le faire. Microsoft a apporté des modifications au calendrier de Windows Server 2008/Vista qui auraient rendu cela possible, mais je ne l'ai jamais réellement exercé.
Ce que tout le monde a dit. Je suis particulièrement nerveux au sujet des tentatives de force brute que Christopher Karel a mentionnées. ne présentation au dernier Def Con était sur le sujet:
Vous pensez donc que votre contrôleur de domaine est sécurisé?
JUSTIN HENDRICKS SECURITY ENGINEER, Microsoft
Les contrôleurs de domaine sont les joyaux de la couronne d'une organisation. Une fois qu'ils tombent, tout dans le domaine tombe. Les organisations mettent tout en œuvre pour sécuriser leurs contrôleurs de domaine, mais elles ne parviennent souvent pas à sécuriser correctement le logiciel utilisé pour gérer ces serveurs.
Cette présentation couvrira les méthodes non conventionnelles pour gagner l'administrateur du domaine en abusant des logiciels de gestion couramment utilisés que les organisations déploient et utilisent.
Justin Hendricks travaille au sein de l'équipe de sécurité d'Office 365 où il est impliqué dans le red teaming, les tests de pénétration, la recherche en sécurité, la révision de code et le développement d'outils.
Je suis sûr que vous pouvez trouver de nombreux autres exemples. Je cherchais des articles sur les contrôleurs de domaine et le piratage dans l'espoir d'obtenir une description de la rapidité avec laquelle le DC serait trouvé, etc., mais je pense que cela suffira pour l'instant.
Si vous essayez de convaincre la direction, un bon début serait que:
It goes against Microsoft's Best Practices for Active Directory Deployment.
Mise à jour : Voir cet article technet sur la sécurisation des contrôleurs de domaine contre les attaques, et la section intitulée Perimeter Firewall Restrictions qui dit:
Perimeter firewalls should be configured to block outbound connections
from domain controllers to the Internet.
Et la section intitulée Blocking Internet Access for Domain Controllers quels États:
Launching web browsers on domain controllers should be prohibited not only
by policy, but by technical controls, and domain controllers should not be
permitted to access the Internet
Je suis sûr que vous pouvez créer de la documentation Microsoft à ce sujet, c'est tout. En plus de cela, vous pouvez indiquer les dangers d'un tel mouvement, quelque chose comme:
A gaping hole would be created, possibly resulting in severe data loss and/or loss of company secrets.
Les informations d'identification mises en cache ne sont que cela - mises en cache. Ils fonctionnent pour la machine locale quand il ne peut pas se connecter au domaine, mais si ce compte était désactivé, ils ne fonctionneraient pour aucune ressource réseau (svn, vpn, smb, fbi, cia, etc) donc ils n'ont pas à s'en soucier. Rappelez-vous également que les utilisateurs ont déjà tous les droits sur tous les fichiers de leur dossier de profil sur une machine locale (et probablement un support amovible), donc les informations d'identification désactivées ou non, ils peuvent faire ce qu'ils veulent avec ces données. Ils ne fonctionneraient pas non plus pour la machine locale une fois qu'elle se reconnecterait au réseau.
Faites-vous référence aux services fournis par Active Directory ou un contrôleur de domaine, tels que LDAP? Si tel est le cas, LDAP est souvent interrompu en toute sécurité à des fins d'authentification et d'interrogation d'annuaire, mais la simple désactivation du pare-feu Windows (ou l'ouverture de tous les ports requis au public - même chose dans cet exemple) pourrait entraîner de graves problèmes.
AD ne fait pas vraiment gérer Mac, donc une solution séparée serait nécessaire (pensez à OS X Server). Vous pouvez joindre un Mac à un domaine, mais cela ne fait guère plus que de les laisser authentifier avec les informations d'identification du réseau, définir les administrateurs de domaine en tant qu'administrateurs locaux sur le Mac, etc. Aucune stratégie de groupe. MS essaie de percer ce terrain avec de nouvelles versions de SCCM qui prétendent être en mesure de déployer des applications sur des macs et des boîtes * nix, mais je ne l'ai pas encore vu dans un environnement de production. I crois également que vous pouvez configurer les mac pour se connecter à OS X Server qui s'authentifierait dans votre répertoire AD, mais je peux me tromper.
Cela étant dit, certaines solutions créatives pourraient être conçues, telles que la suggestion d'Evan d'utiliser OpenVPN en tant que service et de désactiver le certificat de la machine si/quand le moment est venu de laisser partir cet employé.
Il semble que tout soit basé sur Google, donc Google agit comme votre serveur LDAP? Je recommanderais à mon client de le conserver dans la mesure du possible. Je ne connais pas la nature de votre entreprise, mais pour les applications Web telles qu'un serveur git ou redmine, même lorsque la configuration en interne peut s'authentifier avec OAuth, en profitant d'un compte Google.
Enfin, une configuration roadwarrior comme celle-ci serait presque nécessite un VPN pour réussir. Une fois que les machines sont entrées dans le bureau et configurées (ou configurées à distance via un script), elles ont besoin d'un moyen de recevoir les modifications de configuration.
Les mac auraient besoin d'une approche de gestion distincte en plus du VPN, c'est dommage qu'ils ne fassent plus de vrais serveurs mac, mais ils avaient des implémentations de politique décentes dans OS X Server la dernière fois que j'ai vérifié (il y a quelques années ).
Il est regrettable que DirectAccess ne soit disponible que sur Win7 + Enterprise Edition, car il est fait sur mesure pour votre demande. Mais ne connaissant pas votre édition et voyant que vous avez MacOS, cela ne fonctionnera pas.
/ Modifier - il semble que certains tiers prétendent avoir des clients DA pour Unices: http://www.centrify.com/blogs/tomkemp/what_is_Microsoft_directaccess_and_unix_linux_interoperability.asp
Il existe des solutions MDM qui peuvent répondre à vos besoins; nous déployons l'un d'entre eux (MAAS360) sur un client qui se trouve dans une position similaire.
Ce serait évidemment un risque de sécurité important. De plus, cela ne fonctionnerait probablement pas aussi bien que vous le souhaiteriez. Si des personnes aléatoires sur Internet peuvent tenter de se connecter à votre environnement AD, il y a de fortes chances que tous vos utilisateurs soient bloqués. Pour toujours. Et la suppression des exigences de verrouillage signifie qu'il est assez facile de vérifier la force brute pour les mots de passe simples.
Plus important encore, vous ne devriez avoir aucun problème à mettre en œuvre votre objectif (les utilisateurs finaux se connectent à un ordinateur portable avec des informations d'identification de domaine) sans rendre les serveurs AD directement accessibles. À savoir, les machines Windows peuvent mettre en cache les dernières connexions réussies X, afin que ces mêmes informations d'identification fonctionnent lorsqu'elles sont déconnectées. Cela signifie que les utilisateurs finaux peuvent se connecter et effectuer un travail utile, sans avoir à toucher à vos serveurs AD. Ils devront évidemment utiliser un VPN pour se connecter à d'autres ressources importantes de l'entreprise et peuvent actualiser les paramètres AD/GPO en même temps.
Ewwhite,
Votre question est extrêmement valable et mérite un examen attentif.
Tous les professionnels de la sécurité recommandent des couches de sécurité devant toute ressource réseau, y compris SPI Firewalls, IDS, Host Based Firewalls, etc. Vous devez toujours utiliser un pare-feu de passerelle de périmètre proxy comme ISA (maintenant TMG) lorsque cela est possible.
Cela dit, Microsoft Active Directory 2003+ n'a présenté aucune vulnérabilité majeure. La technologie LDAP et ses algorithmes de hachage sont généralement très sécurisés. Il est sans doute plus sécurisé que le VPN SSL si ce VPN SSL exécute OpenSSL et est vulnérable aux cordes.
Je voudrais mettre en garde 5 choses:
Soyez préoccupé par les autres services qui font face au réseau tels que Terminal Server, les services DNS, CIFS, et surtout IIS avec son terrible bilan de sécurité.
Utilisez LDAPS avec un certificat de sécurité pour éviter de transmettre des informations d'identification de domaine en texte clair sur le câble. Cela se produit automatiquement après l'installation des services de certificats (utilisez une machine distincte pour PKI)
Mettez un renifleur de paquets sur l'interface et surveillez votre trafic, corrigez tous les mots de passe en texte clair car le pare-feu ou non, si vous n'utilisez pas de VPN ou LDAPS, certains systèmes hérités enverront des mots de passe en texte clair.
Sachez que les attaques MITM peuvent forcer les mécanismes d'authentification natifs à rétrograder et exposer les mots de passe à une authentification NTLM plus faible.
Soyez conscient de certaines vulnérabilités d'énumération des utilisateurs qui peuvent encore exister.
Cela dit, Active Directory a un excellent bilan en matière de sécurité. De plus, MS Active Directory ne stocke pas les mots de passe, uniquement des hachages qui peuvent également atténuer la gravité d'un compromis.
Vous pouvez bénéficier d'une infrastructure de sécurité plus transparente, vous n'avez pas à configurer de serveurs DNS spéciaux ou à utiliser domain.local et vous pouvez utiliser votre domaine réel sur Internet public tel que domain.com.
À mon avis professionnel, le déploiement public de technologies de sécurité comme Active Directory présente un avantage substantiel, alors que d'autres technologies comme Exchange et DNS et les serveurs Web n'offrent tout simplement aucun avantage et tous les risques.
Remarque: si vous déployez Active Directory, il inclura un serveur DNS. Soyez CERTAIN pour désactiver la récursivité sur vos serveurs DNS (activé par défaut) ou vous participerez absolument à des attaques par déni de service.
À votre santé,
-Brian