¿Hay algún sistema de autenticación cuyo protocolo siempre notifique a la "cuenta de destino" de la suplantación?

Navega tus respuestas
2

Hay muchas formas de suplantación:

  • Sudo en * nix
  • suplantación de la aplicación ( send as en Exchange)
  • Cualquier usuario privilegiado (helpdesk) que inicie sesión como usuario para no revelar la contraseña
  • Administrador de RunAs en Windows

Estoy buscando un sistema de autenticación que, a su vez, defina una secuencia de pasos para:

  1. Registrar todos los intentos de suplantación válidos
  2. Asegura la visualización de esos intentos al propietario de la cuenta
  3. El propietario de la cuenta acepta pasivamente o los marca como sospechosos.

En cierto sentido, esto podría estar codificado como un RFC, similar a la forma en que se reporta la UCE de spam, o el informe de DMARC.

Mi objetivo es trasladar esta lógica a un sistema de autenticación propietario, mantener el formato de registro igual y, si es posible, rastrear y actualizar la disposición de cada intento.

No estoy intentando volver a trabajar la rueda aquí, y creo que debería existir algún trabajo previo.

    
pregunta random65537 26.01.2017 - 16:53
fuente

1 respuesta

2

El problema aquí es que todas las formas de suplantación se llevan a cabo por diferentes motivos:

  • sudo se usa normalmente para permitir que un usuario con privilegios bajos realice tareas que normalmente requieren privilegios de nivel superior
  • La suplantación de Exchange se puede usar para permitir que cualquier usuario de cualquier nivel de privilegio envíe mensajes como otro usuario, pero sin permitir otras funciones de la cuenta
  • La suplantación de Helpdesk tiende a permitir que los usuarios con altos privilegios (personal de TI) asuman el rol de usuarios con menos privilegios (todos los demás) para fines específicos (en este caso, "privilegio" se relaciona solo con el acceso al sistema, no con la jerarquía de la empresa ). Sin embargo, también se puede usar para permitir el monitoreo de actividades donde existe la sospecha de que un empleado está haciendo algo incorrecto, por ejemplo.
  • RunAs es esencialmente lo mismo que sudo en este contexto

Como resultado, todos tienen diferentes requisitos para el registro y la notificación:

  • sudo: debe registrar la cuenta de usuario real y las actividades realizadas
  • Intercambio: es probable que tenga que registrar al usuario original, pero las actividades se registran como parte del uso normal, y dado que el usuario legítimo normalmente otorga el permiso, puede tener un implícito "esta acción fue realizada por el titular de la cuenta principal" estado, incluso si un usuario suplantador realmente lo realizó. Considere la posibilidad de que una secretaria envíe una carta en nombre de un gerente: generalmente se considera que el gerente es el "remitente", incluso si no presionaron "enviar" ellos mismos.
  • Helpdesk: se debe registrar la suplantación, pero puede ser difícil / imposible registrar las actividades específicas realizadas. Por ejemplo, podrían simplemente mostrarle a un usuario cómo encontrar un diálogo dentro de un sistema complejo, donde el único método de registro sería observar dónde estaban los clics del mouse y posiblemente tomar capturas de pantalla en esos momentos. Si el empleado está siendo investigado, notificarlo puede comprometer la investigación.

Debido a este problema, no es realmente un tema que se preste a la estandarización en una RFC; habría tantas exclusiones y excepciones que sería casi inútil y prácticamente imposible construir un sistema interoperable.

Los pasos que ha descrito no funcionarán con algunos de los ejemplos que tiene:

  • sudo - ¿a quién notificarías? La cuenta de root? ¿Cómo accede alguien? ¡A través de sudo, en muchos sistemas modernos!
  • Exchange: un uso común es que las personas puedan responder a los correos electrónicos mientras el destinatario del correo electrónico está de permiso. Si tenían que obtener la aprobación para cada intento, ese caso de uso cae. Estaría bien para otros casos de uso, como que una persona prepare los correos electrónicos en nombre de otra.
  • Helpdesk: un caso de uso común es solucionar problemas al iniciar sesión en cuentas. Si un usuario no puede iniciar sesión, no puede aceptar que la suplantación sea válida hasta que el problema sea
respondido por el Matthew 01.02.2017 - 18:21
fuente

Lea otras preguntas en las etiquetas

Con los derechos de acceso de SAP_ALL, ¿puede alguien ejecutar un ejecutable en el servidor ABAP de SAP Netweaver? ¿Qué es proxyjudge.info?