Le 2FA doit-il être activé sur les comptes de service?
Voir le titre. Je suis impliqué dans un audit de sécurité en ce moment et je me demande si 2FA devrait être activé non seulement sur les comptes de connexion humains mais également sur les comptes de service (comptes non humains)? Si oui, comment est-ce normalement géré? Quelqu'un doit encore être à l'autre bout pour confirmer le droit 2FA? Et serait-ce principalement une chose unique lors de la configuration ou aurait-il besoin de reconfirmer périodiquement la demande 2FA?
Le problème avec l'exigence de l'AMF sur les comptes de service, c'est qu'elle devrait être entièrement automatisée. Par exemple, un OTP basé sur le temps .
Mais comme cet OTP est basé sur une graine secrète, il s'agit en fait d'un autre mot de passe stocké dans une configuration disponible pour le compte de service. Et il ne donne donc aucune sécurité supplémentaire réelle au-dessus de celle d'un seul facteur tel qu'un mot de passe.
L'authentification multifacteur est certainement possible sans intervention humaine.
Cependant, cela nécessite un défi de cadre.
Lorsque vous traitez avec des humains, les trois facteurs typiques d'authentification sont quelque chose que vous savez (mot de passe), quelque chose que vous avez (appareil/programme TOTP, téléphone avec SMS, accès à un e-mail compte, etc.), et quelque chose que vous êtes (biométrie). Vous ne pouvez pas combiner différentes choses à partir du même facteur et l'appeler authentification multifactorielle. C'est-à-dire qu'une empreinte digitale et un scan de la rétine ne sont pas 2FA, mais une empreinte digitale et un mot de passe sont 2FA.
La biométrie ne fonctionne pas sur un réseau, que vous analysiez les empreintes digitales d'un humain ou que vous "empreignez" un ordinateur, car vous ne pouvez pas vérifier que le client ne ment pas à moins qu'un agent de confiance ne soit à vos côtés. "Le client est entre les mains de l'ennemi." - Raph Koster (Game designer, pas expert en sécurité, mais les conseils sont bien appliqués.) Sans cet agent de confiance, la biométrie n'est utile que pour l'identification, pas pour l'authentification (*).
Le facteur d'authentification suivant, quelque chose que vous avez, est généralement indiscernable de quelque chose que vous savez lorsque vous êtes un ordinateur. Les graines TOTP, les mots de passe, les jetons de session, les clés privées RSA, etc. ne sont que des octets vers un ordinateur et résideront à un moment donné dans la RAM. Les humains peuvent s'en tirer avec des graines TOTP, des jetons de session, des clés cryptographiques, etc., comme deuxièmes facteurs, car les humains sont très peu susceptibles de pouvoir les mémoriser, ils ont donc besoin d'accéder à du matériel séparé (ou au moins quelque chose d'écrit).
Cependant, il y a des choses qu'un ordinateur ne peut pas "savoir" à l'avance. Si vous avez un périphérique matériel qui effectue des opérations cryptographiques et stocke la clé privée à l'intérieur d'une manière qui ne peut pas être copiée (sans preuve évidente de falsification), comme un dongle U2F, alors cela peut être considéré comme quelque chose que l'ordinateur a mais ne fait pas '' t sais. De même, les informations envoyées hors bande peuvent également être considérées comme quelque chose que possède l'ordinateur, plutôt que comme quelque chose qu'il sait. Par exemple, un jeton peut être envoyé par e-mail, FTPd ou envoyé par SMS. Selon votre modèle de menace, le simple fait d'ouvrir une connexion sur un autre port peut être suffisant pour tromper les outils de surveillance automatisés, même si je ne lui ferais pas confiance contre une écoute indiscrète active.
En parlant de modèles de menace, les modèles de menace actuels contre les utilisateurs utilisant des mots de passe ne sont pas le fait que ce n'est qu'un facteur. Le modèle de menace est que la plupart des utilisateurs réutilisent des mots de passe, ont des mots de passe à faible entropie et que presque toutes les données humaines ont été incluses dans plusieurs violations de données, y compris de nombreuses violations de données qui n'ont jamais été détectées ou signalées. Étant donné que les ordinateurs n'ont aucun problème à mémoriser des mots de passe très longs et vraiment aléatoires, et peuvent mémoriser chaque mot de passe qui leur est donné, il est trivial de configurer un mot de passe à entropie élevée unique pour chaque compte de service.
Notes de bas de page:
(*) L'identification est différente de l'authentification en ce sens que je peux m'identifier comme la reine de Mars, mais je ne peux pas être authentifiée comme la reine de Mars. Un nom d'utilisateur est une identification, mais un nom d'utilisateur et un mot de passe sont une authentification. Une empreinte digitale est une identification, mais une empreinte digitale prise avec un agent de confiance supervisant le processus est l'authentification.
L'emplacement du réseau comme "quelque chose que vous êtes"
Une façon d'améliorer la sécurité des services qui nécessitent une connexion automatisée à des comptes spécifiques consiste à augmenter l'authentification sécurisée (par exemple, un certificat client tls/ssh) avec des limites réseau strictes - si un service automatisé doit se connecter deux fois par jour du système A au système B , le système B devrait non seulement authentifier la demande, mais refuser toutes les connexions pour ce service/port/compte qui ne proviennent pas de l'adresse IP du système A.
Identifiants non copiables
Une autre façon d'aborder les secrets des services automatisés consiste à les rendre non copiables, c'est-à-dire que le logiciel exécutant la logique métier n'a pas complet accès à ces informations d'identification, mais seulement un lien vers un "système de signature" 'sur un HSM ou "software-HSM", qui ne permettent généralement pas d'extraire les secrets mais uniquement leur utilisation de manière restreinte. Dans ce cas, si le système principal est compromis, il ne peut toujours pas copier les secrets à utiliser ultérieurement à volonté, ils ne peuvent y accéder qu'en temps réel sans pouvoir contourner la journalisation, les limites de débit et autres restrictions.
2FA pour les comptes de service n'est pas nécessaire et ce serait pénible si vous le configuriez réellement.
Imaginez que vous auriez potentiellement 100 comptes de service, chaque fois que votre système s'arrêterait et que vous devriez vous réauthentifier, vous devriez confirmer le 2FA à chaque fois par vous-même, si vous ne le faites pas, le 2FA serait inutile.
Façons de sécuriser un compte de service:
- Rotation fréquente des mots de passe (aucun humain n'a besoin de se souvenir des mots de passe, vous pouvez potentiellement les faire pivoter chaque semaine)
- Augmentez la complexité des mots de passe (vous pouvez potentiellement utiliser 24 caractères ou plus)
- S'il s'agit d'un environnement Windows, utilisez des comptes de service Windows, cette option devrait vous offrir une sécurité suffisante. https://docs.Microsoft.com/en-us/windows/security/identity-protection/access-control/service-accounts
Je ne sais vraiment pas ce que les auditeurs recherchent après avoir demandé cela, mais si vous leur fournissez suffisamment de preuves que vos comptes de service sont sécurisés, cela devrait aller.
Donc, le nœud, certainement dans le contexte de la question, est quel niveau de protection est nécessaire pour de tels comptes de service? Quels sont les risques? Et comment pouvez-vous les atténuer? Et, compte tenu de l'angle d'audit, pouvez-vous montrer comment vous avez fait ce compromis? Et suivez-vous les risques résiduels?
Je fais généralement un modèle simple d'acteur et de menace - en accordant une attention particulière aux exigences non fonctionnelles telles que la disponibilité, l'accès dans des cas exceptionnels, la robustesse, la gouvernance et la fluidité organisationnelle.
En général, je trouve que les comptes de service se répartissent alors en trois blocs 1) ceux qui sont largement utilisés dans l'organisation et dont le "pouvoir" vous pouvez minimiser dans une mesure où les risques de 2FA ou d'une autre complexité commencent à surpondérer les risques d'un "partage". secret'. 2) Ceux qui sont couramment assez puissants car ce sont les services de maintenance, les mises à niveau et ce qui ne tourne pas et 3) ceux qui sont vraiment vos exceptions ultimes/de dernier recours - et, bien que rarement utilisés, où vous voulez éviter les pertes accidentelles - même quand les choses vont mal.
La première classe est souvent partagée avec une bonne surveillance, une bonne gouvernance et ce qui n'est pas en tant qu'atténuateurs. Ou vous amène à construire un bastion/une interface Web bien sécurisé sur quelque chose avec une sécurité solide - qui ne permet de déclencher que quelques opérations de routine très spécifiques.
Pour la troisième classe - l'analyse trouve souvent l'introduction de 2FA ou similaire très indésirable - car ils doivent travailler dans des situations extrêmes où la fragilité est un problème. Ainsi, on a souvent recours à des mots de passe hors ligne dans des enveloppes scellées dans des coffres-forts - pour minimiser les risques de divulgation et de vol. Et obtenez la robustesse (et salée/hachages à la fin de la validation/serveur) en retour. Vous associez ensuite cela à votre gouvernance physique et à votre processus d'audit.
Mais c'est cette classe moyenne qui est toujours en cause - très puissante, souvent utilisée. Et parfois par plusieurs personnes. Mais vous ne voulez vraiment pas d'imposteurs ou de perte de ce niveau d'accès. Même, ou surtout, lorsque vous changez de personnel, découvrez une faille de sécurité, etc.
Donc, ici, le compromis est entre la "douleur" de 2FA contre la convivialité.
D'après mon expérience, vous constatez souvent qu'une sorte d'atténuation 2FA aide à votre évaluation globale des risques - car elle peut apporter une capacité de non-clonage à l'image tout en supprimant la nécessité de faire défiler des choses comme les mots de passe ou le risque de diffuser les accès trop largement.
Les solutions courantes sont des jeux de clés x509 ou SSH sur des jetons USB ou des cartes à puce (parfois même sans code PIN). Comme ceux-ci ancrent l'authentification à un point dans le temps et dans l'espace.
Non à 2FA, oui aux certificats clients
Selon Geir Emblemsvag réponse, 2FA n'est qu'un autre mot de passe. C'est un peu une solution de contournement pour sacs de viande les humains et leurs mots de passe à faible entropie.
Mais les machines sont rapides , et pourraient (ou mieux, devraient ) fonctionner avec une entropie très élevée dans chaque accès . Aucune donnée ne doit jamais passer en texte brut.
La validation du certificat client sur le serveur/service est un moyen de garantir cela. Cela garantit que les données sont toujours cryptées, et vous obtenez une authentification de service et une identification gratuite.