¿Cómo comparte un equipo de administradores de sistemas las contraseñas de forma segura?


83

¿Cuáles son las mejores prácticas para compartir cientos de contraseñas entre unas pocas personas? Estas contraseñas protegen los datos críticos de la misión y nunca pueden ser visibles más allá de un equipo pequeño.



11
Por cierto cientos es un número muy preocupante. ¿Qué sucede cuando uno de los miembros del equipo es despedido? Actualizar cientos de contraseñas será doloroso.
Zoredache

2
Secundado en la cosa "cientos es un número muy preocupante". Creo que, en primer lugar, es posible que necesite hacer una copia de seguridad y reconsiderar cómo está manejando todo el asunto de la seguridad en lugar de intentar poner yeso en lo que tiene actualmente.
Maximus Minimus

Respuestas:


14

Probablemente escribiría una solución personalizada basada en web alojada en una intranet corporativa. (eche un vistazo a http://lastpass.com para obtener inspiración o para usarla. Compartir contraseñas es una de sus características, aunque puede que no funcione para su volumen).

EDITAR : Claro, la mejor solución, no los comparta. Almacenar contraseñas de texto sin formato en cualquier medio es peligroso, especialmente cuando el propósito de almacenarlas es compartirlas. Hay un número casi infinito de soluciones, cada una con un peligro asociado. ¿Por qué no ponerlos en una imagen de disco encriptada, grabar esa imagen en un solo CD, poner el CD en una caja fuerte que solo un guardia armado pueda abrir y que las personas autorizadas presenten una identificación con foto para desbloquearla?

El punto es que realmente no conocemos su escenario. ¿Por qué compartes cientos de contraseñas de misión crítica? ¿Son para su intranet de backoffice, VPN, o son contraseñas de clientes que mantiene en texto plano por alguna razón? ¿Están todas las personas con las que necesita compartirlo en la misma instalación? ¿Funcionaría realmente una transferencia física como un CD cifrado o una tabla impresa almacenada en una caja fuerte? ¿O están sus administradores de sistemas repartidos por todo el mundo, lo que hace que los medios electrónicos para compartirlos sean la única solución?


50
IMO Construir su propio sistema de seguridad / encriptación casi nunca es el enfoque correcto para un problema.
Zoredache

2
@ Zoredache, eso es un montón de basura. Sin embargo, creo que la solución basada en la web para alojar contraseñas es estúpida, pero dijo msanford, sí dijo intranet. Aún así es arriesgado. Lo mismo para todas las otras soluciones en red.
d -_- b

2
@Zoredache, el OP no está construyendo un sistema de cifrado personalizado, parece que todo lo que necesita es una base de datos segura. @sims No veo nada de malo en una solución web bien diseñada. La respuesta votada sugiere precisamente eso (basado en la web! = Http; basado en la web = almacenado en línea). Es cierto que una vez que leí esta pregunta por segunda vez, estoy de acuerdo en que el modelo básico de compartir toneladas de contraseñas parece ser innecesario, y que se podría llegar a una mejor solución. Pero el PO no ha dado suficiente información para mí hacer ese juicio ...
msanford

2
> @Zoredache, eso es un montón de basura. <Um, Sims, estás volando frente a la mayoría de la gente de cifrado desde el principio. Diseñar el cifrado es difícil, por lo que vale la pena el cifrado aún más difícil. schneier.com/essay-037.html A veces, el mal menor, el que conoces, es la mejor opción, cuando te enfrentas al mal que no conoces (es decir, un diseño que no ha sido probado, no revisado por pares, puede tener errores, pueden tener agujeros de seguridad, etc.)
Avery Payne

1
@Avery: diseñar un sistema criptográfico es difícil y debe dejarse en manos de los expertos, sí. El uso de herramientas probadas, como GPG en un archivo de texto compartido, o Keepass (que usa las implementaciones .NET de AES y SHA-256) no está diseñando su propio sistema.
mfinni

38

La mejor práctica es no compartir las contraseñas. Use herramientas como sudo para permitir a los usuarios obtener el acceso que necesitan desde su propia cuenta. Si tiene algunos usuarios, cada uno debe tener sus propias cuentas donde sea necesario. LDAP (Unix / Linux) y Active Directory son una buena solución para otorgar acceso a múltiples servidores desde una base de datos común.

Cuando sea necesario tener una copia escrita de una contraseña, séllela en un sobre firmado y fechado en el sello. Cambie la contraseña cuando se usa. Cuando se cambia la contraseña, selle un nuevo sobre.

Para contraseñas que realmente necesitan ser compartidas, use una de las herramientas de contraseña como Keepass que puede tener su base de datos en una red. Las herramientas con clientes para múltiples plataformas son mejores. Considere si necesita más de una base de datos. Recuerde que debe confiar realmente en todos los que tienen acceso a estos datos.


+1 para cuentas de usuario sin privilegios para administradores con posible escalada de privilegios, en servidores * nix lo combinaría con el uso de solo la certificación dsa / rsa para sshd. Si está haciendo cosas con herramientas gráficas en Linux, también podría usar una configuración personalizada del juego de políticas.
Aaron Tate

12
Esta. Revocar el acceso de los usuarios cuando usan credenciales compartidas es una pesadilla absoluta. Siempre que sea posible, delegue el acceso a través de una cuenta única de usuarios. Siempre hay algunas situaciones en las que una contraseña común es inevitable, pero 'cientos' de contraseñas compartidas muestran fallas críticas de diseño.
Chris Thorpe

44
Estoy de acuerdo con no compartir normalmente las contraseñas, pero hay muchas situaciones en las que es necesario, como dispositivos de red con un solo inicio de sesión, sitios de proveedores donde todos los administradores de sistemas usan el mismo inicio de sesión para realizar pedidos y usuarios de SQL sa o contraseñas de administrador local donde necesario. Es por eso que creo que KeePass es lo mejor para esto: funciona en múltiples plataformas, permite una gran cantidad de seguridad y organiza fácilmente cientos de contraseñas.
Paul Kroon

2
Tenemos una variación en esto, donde tenemos las contraseñas raíz escritas pero encerradas en una caja fuerte que solo el equipo de sistemas tiene claves para abrir. Nuestras contraseñas raíz son de 16 caracteres y se generan de tal manera que son casi imposibles de recordar. Sí, hay cierta inseguridad allí, pero si alguien entra a la caja fuerte, sospecho que tenemos problemas más grandes.
Frenchie

2
Este es un escenario de caso de uso real para nuestro equipo: compartir contraseñas para aplicaciones basadas en la web donde no admiten múltiples inicios de sesión para una sola cuenta. Entonces, si más de una persona en el equipo necesita poder acceder a esa cuenta, debe haber una manera de compartir las contraseñas de esa cuenta.
Jordan Reiter

11

Hemos ido con KeePass para este propósito exacto. Es un pequeño gran programa que almacena todas sus contraseñas en un archivo de base de datos cifrado. Hay características de seguridad adicionales, como la necesidad de un archivo de clave junto con la contraseña principal para acceder a las contraseñas. Esto permite múltiples capas de seguridad (separe el archivo de clave y la base de datos), al mismo tiempo que es conveniente para todos trabajar con todas las contraseñas diferentes. Por ejemplo, puede ejecutar la aplicación y el archivo de clave desde una unidad USB, pero almacenar la base de datos en su red en algún lugar. Eso requeriría credenciales para el recurso compartido de red, la contraseña principal y la unidad USB física con el archivo de clave.


KeePass parece soportar múltiples plataformas, una gran victoria en mis ojos (trabajo en un entorno de plataforma mixta). La función "auto-type" también parece útil.
Avery Payne

2
Estúpida idea de mantener las contraseñas en la red.
d -_- b

1
@Sims: ¿cómo los comparte? KeePass usa un archivo encriptado para la tienda. Es solo una versión más utilizable de un archivo de texto cifrado con GPG en un servidor Unix al que todos tienen acceso.
mfinni

1
@Sims: normalmente estoy de acuerdo con usted, pero puede ser una situación de seguridad frente a productividad. No me gustaría poner la contraseña de root de un servidor en algo como esto, pero la contraseña de administrador de un conmutador de Capa 2 que solo tiene un inicio de sesión único es un buen candidato para esto. Hay un punto en el que se necesita más trabajo para hacer las cosas de la manera más segura de lo que sería limpiar después de una violación de seguridad. Además, además de todo el cifrado, tendrías seguridad AD / NTFS en el archivo y un poco de oscuridad al colocar el archivo (que se puede llamar cualquier cosa) en una ubicación aleatoria.
Paul Kroon

No estaba pensando en una máquina con Windows. Pero sí, si solo puede tener un usuario para ese interruptor, entonces supongo que tendría sentido. De lo contrario, como dice Bill, diga no a las contraseñas compartidas, que también fue mi punto sobre las claves.
d -_- b

5

¿Cuáles son las mejores prácticas para compartir cientos de contraseñas entre unas pocas personas?

Fácil, esto viene en dos sabores:

  1. No, simple y llanamente. Si elige hacer esto, difiere la autenticación de contraseña a una autoridad externa confiable y controla la autenticación desde allí.

  2. Sí, pero al hacerlo, tiene controles de acceso externos que tienen contraseñas o tokens de seguridad que no están registrados dentro del sistema que usa (es decir, el registro de contraseñas está protegido por otra contraseña que tiene disponibilidad limitada). Hay numerosos problemas con esto.

Estas contraseñas protegen los datos críticos de la misión y nunca pueden ser visibles más allá de un equipo pequeño.

Debería considerar seriamente un servicio de autenticación segura que se integre con un servicio de directorio para abordar el problema. La combinación DS / AS crea una "autoridad" confiable que puede actuar como árbitro para todos sus usuarios y dispositivos. Las cuentas de usuario pueden tener su acceso extraído de la contraseña real utilizada en la autenticación, lo que facilita "desconectar" las contraseñas de la política de acceso. El control de las contraseñas se realiza mediante la desactivación de la cuenta del usuario; así que si un administrador se va, simplemente cierra su cuenta y su acceso desaparece (porque la contraseña de esa persona solo le otorga acceso en función de la validez del DS / AS que confirma que la cuenta es válida).

Esto solo funcionará cuando se encuentre en un entorno que permita que sus dispositivos / programas desvíen sus solicitudes de autenticación a fuentes externas, por lo que puede no ser una solución para usted . Si tiene un porcentaje significativo de dispositivos / programas que pueden acomodar autenticación externa, entonces seguiría y haría esto, solo para consolidar varios cientos de contraseñas en una lista manejable de, por ejemplo, una docena. Si decide seguir esta ruta, hay varias soluciones estándar, conocidas y probadas para esto.

  • Directorio Activo. Probablemente el más conocido del grupo, le ofrece Kerberos como una opción de autenticación y proporciona LDAP para DS básico.
  • Samba / Winbind. Piense en esto como "Active Directory Light", no obtiene todas las características de AD sino un modelo más antiguo basado en NT4 (piense en el hash de LANMAN). Esto se suplantará con la integración AD de Samba 4 y probablemente "desaparecerá".
  • Servicios de directorio de Novell. No sé lo suficiente para recomendarlo, pero sé que todavía existe. Muchas entidades gubernamentales aún ejecutan NDS, por lo que si está trabajando en ese "sector" será de su interés. Novell portó recientemente NDS para que se ejecute como un servicio de Linux, pero no sé si todavía es un producto activo (circa 2005).
  • LDAP + Kerberos. Esto es básicamente Active Directory "casero", menos todas las "características agradables". Sin embargo, también son componentes conocidos con una base de código madura y estable, por lo que la integración de estos servicios suele ser el grado de "personalización" necesaria para que las cosas funcionen.
  • SSH Keys + (inserte el programa de administración del sistema aquí, probablemente títere). Solo es útil cuando tiene SSH en todos los ámbitos y se accede a todos los dispositivos de esta manera. Las claves se pueden entregar y revocar según sea necesario, y las contraseñas se vuelven "irrelevantes" a medida que la clave SSH otorga acceso. El uso de un sistema como puppet le permite actualizar cientos de máquinas emitiendo comandos en masa para agregar / revocar claves SSH.
  • Alguna combinación de lo anterior.

También hay una pregunta de cuánta seguridad necesita. No especificó si por "misión crítica" quiere decir que las ojivas nucleares pueden llover sobre las ciudades, o si "misión crítica" significa que el último envío de Furbies no llegará a la ciudad. Realmente ayudaría si hubiera algo que describiera una evaluación de riesgo / amenaza.


2

Unas pocas cosas:

  • Como han dicho otros, esta es una mala idea. Use un LDAP, etc.
  • Si está comprometido a hacerlo por cualquier razón, al menos consolide las contraseñas. 100 contraseñas no administradas significa que no está actualizando las contraseñas.
  • Mantenlos en papel. Requerir que el personal firme el papel con una tinta de color diferente para que sea más fácil determinar si se copió una hoja.
  • Si está en Unix, use S / KEY para generar contraseñas de un solo uso. Almacene eso en un lugar seguro.

También debe ir más allá de las medidas de seguridad mecánicas de colocar contraseñas de papel en una caja fuerte o encriptarlas. Lea sobre cómo las organizaciones con modelos de seguridad maduros protegen claves y combinaciones seguras. No recomiendo hacer lo que quieres hacer, pero si lo haces:

  • Las personas que usarán las contraseñas no pueden controlar el acceso a las contraseñas. Un grupo distinto de personas bajo una cadena de gestión diferente necesita controlar el acceso a la caja fuerte, al cajón, etc. Si tiene un grupo financiero, pueden ser candidatos. Tal vez el vicepresidente de marketing, etc.
  • Es necesario que haya un registro escrito cuando se abre la caja fuerte y alguien toma posesión de una contraseña.
  • La contraseña debe cambiarse dentro de las 24 horas posteriores a la extracción.

Procedimientos como este son un dolor en el cuello, pero servirán como un incentivo para que las personas adopten prácticas más sensatas. Si no haces algo como lo que describí, no te molestes en seguir los pasos de bloquear las contraseñas, porque de todos modos algún día serás violado.


2

Sé que esta es una vieja pregunta, pero recientemente me encontré con una solución basada en la web de código abierto llamada Corporate Vault que puede ser interesante para algunos. No he tenido oportunidad de probarlo todavía.


1

Usamos un programa llamado Password Safe . es agradable y muy seguro, puede configurar la base de datos en una unidad en red y dar acceso a todos los que lo necesiten y la contraseña a la caja fuerte, que luego almacena todos los nombres de usuario y contraseñas encriptados de forma segura.


1

https://pypi.python.org/pypi/django-pstore/ utiliza el cifrado GPG por usuario para las contraseñas compartidas (y cualquier otro dato que desee compartir). El servidor nunca conoce las contraseñas, solo contiene los datos cifrados. Todos usan su propia clave privada para descifrar los secretos compartidos.

El sistema incluye gestión de derechos: no todos tienen acceso completo.



0

SPB Wallet es una buena manera de usar PW safe por fantasma, pero la billetera SPB le permite sincronizar a un recurso compartido de red y también a su iPhone si obtiene la aplicación. También tiene un generador de contraseñas incorporado y puede generarlas desde contraseñas simples hasta contraseñas extremadamente complejas. También puede copiar la contraseña mientras la contraseña todavía está marcada con asteriscos, por lo que si alguien está mirando, puede copiarla y pegarla sin que nadie vea la contraseña. La aplicación para PC se bloquea automáticamente una vez que no hay actividad durante un período de tiempo definido.


0

Otra opción es Azure Key Vault, que almacena de forma segura sus secretos y le permite permitir el acceso a ellos mediante programación, rotar fácilmente sus contraseñas, etc.


0

Nuestra mejor práctica es compartir la menor cantidad posible de contraseñas.

Por lo tanto, por ejemplo: - usamos my.cnf en el directorio raíz de inicio para las contraseñas de la base de datos - usamos las claves ssh para iniciar sesión en los servidores y tenemos una contraseña raíz que solo se permite a través de la consola (por lo que debe tener acceso físico / bmc al servidor ) - use ldap en todas partes posibles (ssh, bmc, switches, redmine, ....)

Sin embargo, hay algunas situaciones en las que no podemos utilizar este enfoque (como la contraseña de root). Luego usamos keepass en nuestro almacenamiento compartido, pero guardamos tan poco como 10 contraseñas allí necesarias.


-1

Muy buena pregunta Estaría interesado en otras respuestas.

Esto es lo que hago, pero primero recomiendo usar claves precompartidas siempre que sea posible. Sin embargo, no sé si esto es posible con los sistemas Windows.

Dado que la cantidad de contraseñas debe ser pequeña (está utilizando claves siempre que sea posible), uso un archivo de texto encriptado con gpg en un sistema que no tiene NIC. Entonces (1) necesita acceso físico y (2) una contraseña.

editado para mayor claridad


¿Llaves? Como en, ¿llaves USB? ¿Llaves físicas que abren cerraduras? Teclas de tarjeta inteligente? GPG Keys? ¿Claves de contraseña que solo existen en el software en tu cabeza? Combinaciones de lo anterior?
Avery Payne

¡Llaves del coche! JK Para aclarar, me refiero a las teclas ssh. Es por eso que dije que podría no ser posible usar claves previamente compartidas con Windows.
d -_- b
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.