¿Qué precauciones debo tomar al crear usuarios que serán utilizados por aplicaciones y no por personas?

21

Tengo algunas aplicaciones que necesitan acceder a un bus de servicios web . Las aplicaciones propias que acceden al bus se autentican mediante un servicio web en ese bus, pero en este caso necesito que las aplicaciones de terceros accedan a algunos servicios web en el bus.

Estas aplicaciones de terceros deben autenticarse en un LDAP ( OID de Oracle ). Necesito crear un usuario y una contraseña para cada aplicación que deba autenticarse.

¿Existe una forma más segura de autenticar estas aplicaciones de terceros en el bus de servicios web?

¿Qué precauciones debo tomar al crear estos usuarios en el OID?

¿Qué precauciones debo tomar al crear usuarios que serán utilizados por las aplicaciones y no por las personas?

    
pregunta Eloy Roldán Paredes 24.12.2015 - 08:54
fuente

3 respuestas

8

La identificación y el seguimiento son importantes pero sorprendentemente difíciles.

Primero, etiquete las cuentas en el directorio para que pueda identificarlas como identificaciones de no usuarios.

Cada cuenta que no sea de usuario debe estar asociada con un propietario de cuenta, alguien responsable de proteger el sistema al que accede. Almacene la identidad del propietario en la entrada del directorio del usuario que no es usuario, de modo que si va a buscarlos más tarde, sabrá con quién debe ser contactado. Recuerde que los propietarios vienen y van con promociones de empleados, facturación, etc., por lo que es posible que necesite un departamento u otra etiqueta de organización para ir con la identificación del empleado. La membresía de grupo puede ayudar aquí. Además, a medida que los empleados se van, sus cuentas de directorio pueden eliminarse, lo que hace que una ID desconocida sea inútil. Un nombre es al menos alguien que otras personas pueden ayudarlo a rastrear.

También puede ser útil saber con qué máquina están asociadas las cuentas. Mantenga esa información en su directorio, también.

Si tiene un sistema de solicitud formal, donde las personas ingresan sus requisitos para solicitar la cuenta, la máquina, etc., almacenaría el número de solicitud en la entrada del directorio. Pero tenga en cuenta que los sistemas de seguimiento de solicitudes pueden cambiarse y que la información asociada con los números de seguimiento emitidos hace 5 años puede que ya no esté disponible. También le recomiendo que mantenga la información del propietario y la máquina en el registro.

Si aún no tiene un proceso de revisión formal para sus cuentas, tenga en cuenta que cuando lo implemente, tendrá una gran cantidad de cuentas de no usuarios en su directorio. Estos datos lo ayudarán a identificar a los revisores (los propietarios del sistema deben revisarlos para determinar si son apropiados en forma periódica). Considere mantener los datos de revisión con el registro; es posible que incluso desee mantener la última información revisada en / por en el directorio para proporcionar a los auditores.

La razón principal para mantener esta información es en caso de un compromiso. Durante la fase de respuesta, debe poder identificar rápidamente a las personas asociadas con la cuenta para poder cambiar las contraseñas, escanear los sistemas y rastrearlos rápidamente, con un mínimo esfuerzo. Tenga en cuenta que es posible que deba realizar esta actividad sin alertar a los propietarios del sistema, al menos mientras la investigación esté activa. También es posible que deba proporcionar información de revisión a los investigadores. Es una triste realidad que el compromiso puede originarse en una fuente interna.

Para responder el resto de su pregunta, debe generar una contraseña larga, utilizando un generador de contraseñas criptográficamente seguro (no aleatorio () de javascript). Si puede asignar estas cuentas y contraseñas sin involucrar a personas, utilizando una herramienta de administración de contraseñas, eso es aún mejor. Hay sistemas comerciales que se vinculan con los servidores ldap para hacer mucho de esto (ya que usted es una tienda de Oracle, debe consultar con su representante de cuenta porque venden dicho sistema).     

respondido por el John Deters 31.12.2015 - 17:29
fuente
3

En general, no hay una gran diferencia entre los usuarios creados para la automatización y los usuarios creados para personas reales. Aún debe limitar el acceso que cada usuario tiene a solo lo que se requiere.

Es un poco más ambiguo pensar cómo segmentar el acceso de servicios de terceros a un recurso confiable. Una persona normalmente solo tiene una cuenta y no creamos varias cuentas por usuario (con algunas excepciones). Pero su "servicio" puede ser pensado de múltiples maneras. Solo usted puede determinar cómo delinear esto, y si diferentes partes de lo que podría considerar como un solo servicio podrían necesitar diferentes niveles de acceso.

Como ejemplo, hay un servidor de correo conocido conocido como postfix. En un nivel alto, puede pensar en postfix como un solo servicio. En un nivel inferior, está realmente diseñado múltiples procesos que conforman cada servicio dentro de él. Cada proceso tiene la menor cantidad de privilegios necesarios para realizar el trabajo.

Con un software de terceros, puede o no haber podido lograr una forma de hacer las cosas con los "menos privilegios". Pero sigue siendo una importante consideración de diseño al configurar la automatización que no es tan relevante cuando se trata con personas reales.

    
respondido por el Steve Sether 31.12.2015 - 17:09
fuente
3
  1. Otro comentarista sugirió usar certificados en lugar de LDAP. Pero no recomendaré el uso de 2 mecanismos de autenticación si no puede hacerlo fácilmente. Tener un sistema de autenticación asegurará que haya menos probabilidades de implementaciones deficientes.
  2. Para contraseñas seguras, use un algoritmo generador "UUID tipo 4"; esto le dará una cadena aleatoria que se adaptará a usted (no será adivinable).
  3. Los usuarios que no son utilizados por la aplicación tienen la debilidad de tener los permisos completos del usuario, mientras que cualquiera que tenga acceso a ellos puede controlarlos (por lo tanto, los ex empleados aún pueden tener acceso a ellos). dichas aplicaciones se administran (junto con sus permisos; solo se otorgan permisos suficientes para que funcionen). Administre también la caducidad de la contraseña con precaución: si una aplicación no incorpora dicha opción de caducidad y se habilita, es posible que deje de funcionar en un momento inesperado.
respondido por el John ingmar 01.01.2016 - 13:37
fuente

Lea otras preguntas en las etiquetas