Le problème avec l'exigence d'authentification MFA 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 ne s'agit en fait que d'un autre mot de passe stocké dans une configuration disponible pour le compte de service. Et cela n'apporte donc pas de réelle sécurité supplémentaire au-delà de celle d'un seul facteur tel qu'un mot de passe.

L'authentification multifacteur est certainement possible sans intervention humaine.

Cependant, elle nécessite un défi de trame.

Lorsqu'il s'agit d'humains, les trois facteurs typiques de l'authentification sont quelque chose que vous connaissez (mot de passe), quelque chose que vous avez (appareil / programme TOTP, téléphone avec SMS, accès à un compte de messagerie, etc.) et quelque chose que vous êtes (biométrie). Vous ne pouvez pas combiner différentes choses du même facteur et l'appeler authentification multifactorielle. C'est-à-dire qu'une empreinte digitale et une analyse 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 numérisiez les empreintes digitales d'un humain ou que vous soyez " empreinte digitale "d'un ordinateur, car vous ne pouvez pas vérifier que le client ne ment pas à moins d'avoir un agent de confiance en attente. "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 prochain facteur d'authentification , quelque chose que vous avez, est généralement indiscernable de quelque chose que vous connaissez 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 en ayant des graines TOTP, des jetons de session, des clés cryptographiques, etc.

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 est considéré comme quelque chose que l'ordinateur possède mais ne le fait pas ' t sais. De même, les informations envoyées hors bande peuvent également être considérées comme quelque chose de l'ordinateur, plutôt que comme quelque chose qu'il connaît. Par exemple, un jeton peut être envoyé par e-mail, FTPd ou envoyé par SMS. En fonction de votre modèle de menace, le simple fait d'ouvrir une connexion sur un port différent peut être suffisant pour tromper les outils de surveillance automatisés, même si je ne lui ferais pas confiance contre une écoute active.

En parlant de modèles de menaces, l'actuel les modèles de menaces 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 les mots de passe, ont des mots de passe à faible entropie, et que presque toutes les données humaines ont été incluses dans de multiples 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 simple de configurer un mot de passe unique et à haute entropie pour chaque compte de service.

Notes en 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 une authentification.

L'emplacement du réseau en tant que "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 est d'augmenter l'authentification sécurisée (par exemple, un certificat client tls / ssh) avec un réseau strict limites - si un service automatisé doit se connecter deux fois par jour du système A au système B, le système B doit non seulement authentifier la demande, mais refuser toute connexion pour ce service / port / compte qui ne provient pas de l'adresse IP de système A.

Identifiants non copiables

Une autre façon d'aborder les secrets des services automatisés est de les rendre non copiables, c'est-à-dire que le logiciel exécutant la logique métier n'a pas un accès complet à ces identifiants, mais uniquement un lien vers un 'système de signature' sur un HSM ou un "logiciel-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, ils ne peuvent y accéder qu'en temps réel sans pouvoir contourner la journalisation, les limites de débit et autres restrictions.

La 2FA pour les comptes de service n'est pas nécessaire et ce serait pénible si vous la configuriez.

Imaginez que vous auriez potentiellement 100 comptes de service, chaque fois que votre système s'arrêterait et que vous devrait se ré-authentifier, vous devrez confirmer le 2FA à chaque fois par vous-même, si vous ne le faisiez pas, le 2FA serait inutile.

Façons de sécuriser un compte de service:

• Faites une 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 plus de 24 caractères )
• S'il s'agit d'un environnement Windows utilisant des comptes de service Windows, cette option devrait vous fournir une sécurité suffisante. https://docs.microsoft.com/en-us/windows/security/identity- protection / contrôle d'accès / comptes de service

Je ne sais vraiment pas ce que les auditeurs recherchent en faisant cette demande, mais si vous leur fournissez suffisamment de preuves que vos comptes de service sont sécurisés, ça devrait aller.

Le point crucial, certainement dans le contexte de la question, est de savoir quel niveau de protection est nécessaire pour ces comptes de service? Quels sont les risques? Et comment pouvez-vous les atténuer? Et, étant donné l'angle de l'audit, pouvez-vous montrer comment vous avez fait ce compromis? Et suivez-vous les risques résiduels?

Je crée généralement un modèle d'acteur simple & Threath - 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 divisent alors en trois blocs 1) ceux qui sont largement utilisés dans l'organisation et dont vous pouvez minimiser le `` pouvoir '' dans une mesure où les risques de 2FA ou d'une autre complexité commencent à surpasser les risques d'un «secret partagé». 2) Ceux qui sont généralement assez puissants car ils sont ce qui concerne la maintenance, les mises à niveau et ce qui ne tourne pas autour et 3) ceux qui sont vraiment vos exceptions ultimes / de dernier recours - et, bien que rarement utilisés, où vous voulez éviter les pertes par inadvertance - même quand les choses sont désastreuses.

La première classe est souvent des secrets partagés avec une bonne surveillance, une bonne gouvernance et quoi encore en tant qu'atténuateurs. Ou vous amène à construire un bastion / interface Web bien sécurisé sur quelque chose avec une sécurité solide - qui ne permet que de déclencher 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 le risque de vol de divulgation &. Et obtenez de la robustesse (et salé / hachages côté 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 le problème - 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, apprenez une faille de sécurité, et ainsi de suite.

Le compromis est donc ici entre la «douleur» de la 2FA et la convivialité.

D'après mon expérience, vous constatez souvent qu'une sorte d'atténuation 2FA aide dans votre évaluation globale des risques - car elle peut apporter la non-capacité de clonage à l'image tout en supprimant le besoin de cycle des choses comme les mots de passe ou le risque de diffuser trop largement l’accès.

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 la réponse de Geir Emblemsvag, 2FA n'est qu'un autre mot de passe. C'est un peu une solution de contournement pour les humains sacs de viande et leurs mots de passe à faible entropie.

Mais les machines sont rapides , et pourraient (ou mieux, devraient ) fonctionnent 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 chiffrées et vous obtenez une authentification et une identification de service gratuitement.