Tenemos varias contraseñas que deben ser conocidas por más de una persona en nuestra empresa. Por ejemplo, la contraseña de administrador de nuestros enrutadores de Internet, la contraseña de nuestro servidor web y también algunas contraseñas "que no son de TI", como los códigos de seguridad.
Actualmente, utilizamos un sistema ad hoc de "contraseñas estándar" para sistemas de bajo valor, y el intercambio verbal de contraseñas para sistemas más importantes / potencialmente dañinos. Creo que la mayoría de la gente estaría de acuerdo en que este no es un buen sistema.
Lo que nos gustaría es una solución de software para almacenar contraseñas "compartidas", con acceso para cada uno limitado a las personas que realmente lo necesitan. Idealmente, esto provocaría o exigiría cambios periódicos de contraseña. También debería poder indicar quién tiene acceso a una contraseña en particular ( por ejemplo , ¿quién conoce la contraseña de root para el servidor XYZ?)
¿Puede sugerir alguna solución de software para almacenar y compartir contraseñas? ¿Hay algo en particular de lo que tener cuidado?
¿Cuál es la práctica común en las pequeñas y medianas empresas para esto?
Respuestas:
Me enfrento a este problema cada vez que voy a una nueva startup. Lo primero que hago es hacer un par de "Contraseñas seguras" con un programa como este (o uno de sus derivados):
http://passwordsafe.sourceforge.net/
Establezca combinaciones fuertes y vótelas en un recurso compartido de red. Segmento por área de responsabilidad ... infraestructura central, servidores de producción, dev / QA, etc.
Una vez que hay suficiente impulso, y suponiendo que tengo las dependencias adecuadas del entorno de Windows, me gusta mover a todos a esto:
http://www.clickstudios.com.au/passwordstate.html
Tiene características para credenciales compartidas y personales.
fuente
No debe olvidarse la necesidad de poder revocar las contraseñas si un empleado se va / es despedido. Se han observado varios casos en los medios populares de empleados despedidos y 'regresando' a su empresa usando contraseñas que aún estaban activas después de que se fueron.
Esto es típicamente 2 partes:
Otro factor importante es garantizar que se siga la política de contraseñas cuando se realizan los cambios; por ejemplo, ¿cómo sabe que no se usó la misma contraseña en varias cuentas o que no se usó una contraseña débil?
fuente
Trabajo en una pequeña tienda de TI y hemos estado usando Secret Server durante el año pasado para administrar nuestras contraseñas para nuestros dispositivos de red y las necesidades del cliente.
Ofrecen una "edición de instalación" o una edición en línea / alojada. Usamos la edición alojada por menos de $ 100 / año (5 usuarios) y podemos acceder a esta información de contraseña de forma segura a través del navegador web dondequiera que vayamos. Si realmente le preocupa la seguridad, instálela en su propio servidor y solo acceda a ella a través de LAN o VPN.
Además, mi administrador de contraseñas basado en web "personal" favorito ahora ofrece una "edición comercial": PassPack .
No estoy seguro de cómo funciona en este escenario en comparación con Secret Server, pero cualquiera de las soluciones debería ser mucho más versátil y segura que los trozos de papel, las aplicaciones de escritorio o ( jadear ) recordando cosas en su cabeza. Para el problema del "punto único de falla", cualquiera de estos productos permite una fácil exportación a CSV.
fuente
He estado usando LastPass por un tiempo y me encanta. Pasé un poco de tiempo investigando esta pregunta el año pasado y me gustó cómo lo había hecho LastPass.
fuente
Secundo la recomendación de Adam de PasswordSafe, con los datos en una carpeta de red. Tengo dos consideraciones en esta área. Una es tener una única versión, de modo que todos los que necesitan los datos obtengan los datos actuales.
1- PasswordSafe utiliza un formato estandarizado para el archivo, por lo que hay otras soluciones que pueden leerlo, incluido KeePass.
2- Coloque el archivo de contraseña en un recurso compartido seguro y tenga un script nocturno que lo copie en un par de ubicaciones en la red. Tal vez cópielo en un recurso compartido en otro servidor (fuera del sitio si es posible) y en una unidad USB que quede en el servidor. ¡Desea que el archivo tenga al menos un lugar donde no esté protegido por una contraseña que esté almacenando!
3- Almacene el instalador (o la versión ejecutable del programa) en los mismos lugares que el archivo de clave, para que pueda acceder rápidamente si es necesario.
4- Haga que las personas abran el archivo SOLO LECTURA, a menos que tengan que hacer un cambio.
5- Si es necesario, puede crear múltiples archivos de contraseña, uno para las credenciales que todos los miembros del equipo necesitan y otro para las credenciales de las cosas realmente sensibles.
Yo no recomendaría pasar a una solución basada en web. Una solución alojada internamente podría estar bien, pero parece ser un problema. También me preocupa que sea un único punto de falla.
fuente
Comparto la responsabilidad de algunos sistemas con los empleados de uno de mis clientes. Acordamos utilizar un esquema de contraseña para las cuentas más utilizadas. Otras contraseñas se almacenan en una lista en papel de pares (número, contraseña) mantenida por el Jefe de TI del cliente. Los nombres de usuario y hosts se almacenan en una base de datos de fácil acceso. Las contraseñas se entregan según sea necesario.
fuente
Práctica común en pequeñas y medianas empresas:
Tres lugares en los que he trabajado han utilizado documentos separados para detallar contraseñas para diferentes sistemas. Un documento para los enrutadores y cortafuegos, otro para el acceso a los servidores y otro para desarrolladores (por ejemplo, detalles de inicio de sesión para conexiones de bases de datos). El acceso a las aplicaciones tiende a no estar documentado (supongo que, para la mayoría, inicia sesión como usted mismo con derechos de administrador).
El administrador de la red solo ve el documento de contraseña del enrutador, y las personas que tienen acceso a este documento se enumeran en este archivo. Sus términos de empleo establecen que los inicios de sesión y las contraseñas a los que tienen acceso son privados y no se deben compartir con otros. Similar para los administradores de sistemas y los desarrolladores.
La realidad es que a veces la contraseña se comparte, pero puede identificar quién necesita saber (y por qué) y cambiar lo que necesita ser cambiado. Funcionó bien en una empresa (software) de 50 empleados.
fuente
Para las contraseñas poco utilizadas, como las cuentas de administrador local en los servidores, las contraseñas del enrutador y el firewall, etc. Estaban escritos en un pedazo de papel en un sobre. Creo que había tres sobres que fueron sellados y firmados por el Jefe, el Administrador del sistema y el Programador principal. Cada individuo tenía una copia de los documentos. En caso de que se usaran las contraseñas, las cambiamos e hicimos nuevos sobres.
En mi trabajo actual, en una organización mucho más grande tenemos solo 15 administradores de sistemas, y un par de miles de usuarios tenemos un método para calcular contraseñas basadas en el nombre de un servidor. Esto incluye un prefijo conocido y un método hash que es lo suficientemente simple como para hacerlo en papel. Cuando las contraseñas deben cambiarse porque alguien se va o no, cambiamos el prefijo o el hash o ambos. De esa manera, aunque no conozco la contraseña de todas las máquinas o dispositivos que me rodean, podría calcularla si la necesitara por algún motivo.
fuente
Hay una publicación de Lifehacker de hoy sobre Passpack , podría valer la pena echarle un vistazo.
fuente
He tenido el mismo problema antes. Terminé construyendo un sistema para manejar esto yo mismo. Almacenaba el nombre de usuario y la contraseña en un formato altamente encriptado dentro de una base de datos con una interfaz web que le permitiría ingresar la información de la cuenta y configurar la seguridad para que solo las personas o grupos correctos pudieran acceder a los datos.
No solicitó cuándo era el momento de cambiar las contraseñas, ya que los servicios en docenas de servidores usaban el mismo inicio de sesión y los cambios en las contraseñas tenían que configurarse con mucha anticipación.
Lo construí con una función de auditoría completa para que cada vez que un empleado mirara un inicio de sesión se registrara para que pudiéramos volcar el registro de auditoría a Excel para los auditores SOX.
fuente
Use GPG con la opción Simétrica para cifrar un archivo de texto con todas las contraseñas. Entonces, todo lo que necesita hacer es proporcionar una frase de paso a otros administradores. Cuando un administrador abandona la empresa, solo vuelve a cifrar el archivo de texto con una nueva frase de contraseña.
fuente
Centrify ha estado trabajando para mí.
fuente
Wow, buen hilo! Nadie ha mencionado mi solución preferida (excepto de pasada), así que le daré un saludo a KeePass. Muy bien extensible, con autenticación basada en contraseña, clave o AD. Hace el trabajo bien para nosotros.
fuente
Para acceder a los servidores:
Proporcione acceso a un servidor y úselo como un jumpbox y administre las cuentas en el jump box. Cualquiera que se supone que es confiable para el jumpbox es confiable para el recurso remoto. De esta manera, todos tienen su propia contraseña y la contraseña en el servidor para la cuenta particular puede mantenerse en secreto.
Para acceder a otros recursos:
Limite el acceso solo al personal esencial. Asegúrese de administrar una lista de usuarios de confianza. Cambie la contraseña cada 90 días y actualice la lista de usuarios de confianza. Notifique a las personas sobre el cambio pendiente con 15, 7 y 1 día de anticipación. Solo distribuya la contraseña a los administradores y permítales determinar quién necesita acceso. Use las utilidades para registrar el acceso y regularmente informe a los usuarios que son sistemas monitoreados de cerca. Cualquier negocio divertido en los servidores debe ser un delito conocido y rescindible.
fuente
Sé que esta no es exactamente la respuesta que desea, pero en mi lugar de trabajo es exactamente la misma, los miembros de confianza del personal reciben las contraseñas relevantes, las contraseñas no se comparten entre los dispositivos y no se escriben. El sistema tiende a funcionar bastante bien, ya que la administración de dispositivos generalmente es responsabilidad de solo un par de miembros del personal. También tenemos una muy buena retención de personal, por lo que se puede generar confianza durante un largo período de tiempo.
fuente
Es posible que desee utilizar algún tipo de software de almacenamiento de contraseñas, de esa manera puede dar a los usuarios autorizados su propio acceso y asegurarse de que la información no se filtre por personas que dejan notas. Una buena probablemente ni siquiera muestra la contraseña, simplemente la deja caer en el portapapeles para cortar y pegar.
fuente
Tenemos un sistema como el Presidente y la Bomba: dos personas conocen la mitad de la contraseña. De esa manera, nunca tendrá una situación en la que un solo administrador no autorizado se active y realice cambios no aprobados por su cuenta.
fuente
Trabajo en una empresa de TI, tenemos muchos clientes, normalmente solucionamos el problema de forma remota. Usamos ssh para iniciar sesión y solucionar problemas. Hemos agregado una clave ssh de máquina a todas las máquinas de nuestros clientes, para que sea útil a otras iniciar sesión y solucionar los problemas, si no estoy allí. Pero la máquina que estamos utilizando para iniciar sesión en los clientes macine es altamente asegurado Si quieres tener buenas contraseñas, mejor usa números y caracteres extra.
Para agregar claves ssh lo siguiente:
1.ssh-keygen -t dsa (Para obtener claves ssh en .ssh / id_dsa.pub
scp .ssh / id_dsa.pub root @ remote: ~ / tmp
En la máquina remota
cat >> /tmp/id_dsa.pub .ssh / optional_keys2
Intenta iniciar sesión para eliminar macine, de otra consola ... :) happy sshhhhhh
fuente
Negarse a utilizar sistemas que requieren una contraseña. Cualquier servidor debe autenticarse con claves SSH, cualquier sitio web con OpenID. Ejecute un proveedor OpenID dentro del firewall.
Obviamente, este escenario implica que todos sus sistemas son accesibles a través de SSH o HTTP, pero funciona para nosotros.
fuente