Me voy de una empresa y tengo demasiadas contraseñas/claves

Soy un desarrollador de software europeo y estoy cambiando de empresa. Para hacer mi trabajo, durante los años he recibido (de mi jefe y colegas) muchos secretos compartidos no personales, como:

  • contraseñas de cuentas raíz (por ejemplo, AWS, Google Cloud, Azure, ...)
  • acceso a servidores (contraseñas y/o claves SSH)
  • Credenciales de cuentas en línea de la empresa (por ejemplo, GitHub, plataformas de aprendizaje electrónico, ...)
  • claves API

Claramente, cualquier persona con este tipo de información podría hacer cosas desagradables, como acceder a los datos del cliente o incluso eliminar depósitos S3. No hace falta decir que algo así sería enorme para una pequeña empresa.

Para ser claro: quiero dejar a mi empleador actual en buenos términos. A pesar de que mi contrato no me requería un período de preaviso, propuse quedarme un mes después de mi anuncio para preparar el equipo (documentar cosas, ayudar a contratar a alguien más, etc.). Incluso le dije a mi jefe y a mis colegas que podrán enviarme un mensaje de texto después de mi licencia si necesitan mi ayuda.

Mi jefe inicialmente estaba bastante "bien" con mi renuncia; sin embargo, durante los últimos días comenzó a comportarse de una manera extraña conmigo (saludos fríos, "olvidar" enviarme una copia en algunos correos electrónicos, ...). Tal vez esas cosas solo están en mi cabeza, sin embargo, me gustaría protegerme contra cualquier tipo de problema futuro. ¿Qué pasaría si un día un colega mío destruyera accidentalmente una base de datos? Para protegerse, ¿me culparía porque yo tenía las contraseñas?

Esos detalles de acceso se almacenan en el correo electrónico de mi empresa (que perdería el acceso después de salir), en mi computadora (la política es "traiga su propia computadora portátil") o en mi cuenta de Google (utilizo "guardar contraseña" en Chrome). Esas no son las mejores prácticas, pero todos los demás hacen lo mismo. Claramente limpiaré mi computadora/cuentas después de salir, pero no habrá evidencia de que no imprimí o memoricé dichos secretos.

Como nota final del desorden, no podrán rotar claves/contraseñas a corto plazo (por ejemplo, el día siguiente a mi salida). Algunas contraseñas nunca se cambiaron desde que se crearon las cuentas, incluso después de que otros empleados se fueran.

¿Qué harías?

¿Son estas contraseñas las que todos comparten? ¿O son contraseñas particulares de su identificación? Es decir, ¿ustedes a) comparten la cuenta "admin" y todos conocen la contraseña de la misma.......... o b) tienen su propia cuenta "throwaway_admin" y su propia contraseña que nadie mas sabe ? Si la cuenta "throwaway_admin" se eliminó a las 5:00 de la hora de salida, ¿sería suficiente?
Un buen punto en su defensa, si es necesario, es que los que se fueron anteriormente también tienen acceso ya que las contraseñas nunca se han cambiado...
@Harper Tengo toneladas de cuentas de "administrador" (p. ej., acceso a la raíz de la cuenta de AWS, claves SSH raíz de servidores, claves de API) y algunas cuentas de "mi nombre" (p. ej., cuenta de AWS IAM). Mi problema es sobre el primer tipo de secretos, sería fácil eliminar/desactivar cuentas individuales en mi último día frente a mi jefe. ¡Gracias!
@SolarMike tiene razón, además, en mi país, este tipo de delito es personal, por lo que en un tribunal deben demostrar que yo borré un cubo S3 hipotético. ¡No quiero ir al grano para demostrar que no soy un imbécil!
en lo que respecta a "una base de datos destruida accidentalmente" o cualquier problema similar: si su dba o el técnico de TI interno valen su dinero, todas las conexiones y operaciones de los clientes, incluidos los detalles de quién, dónde y cuándo, se almacenarán en un registro de todos modos para que Sería difícil culparlo, a menos que logre eludir sus firewalls y comprometa y capture su sistema de forma remota y limpie incluso los registros de los enrutadores y firewalls;)

Respuestas (10)

¿Qué harías?

Haría una lista de todos estos inicios de sesión y me ofrecería a ayudar a la persona encargada de cambiarlos todos. A medida que se completaba cada cambio de contraseña (por la otra persona, usando contraseñas desconocidas para mí), lo tachaba de la lista.

Durante mi último mes, enviaría la lista actualizada con cada uno de mis informes de estado semanales y luego la lista final en mi último día.

Si alguno permanecía sin cambios, descansaría tranquilo, sabiendo que les di un mes junto con todo lo que necesitaban para hacer el trabajo.

Esta es una respuesta razonable pero no protege suficientemente al empleado que se va. El temor de Throwaway no es que la empresa encuentre algún daño por violación de seguridad después de que él se vaya, sino que encuentren algún daño por violación de seguridad y lo culpen a él . Throwaway quiere demostrar que ya no tiene acceso a los activos protegidos de la empresa.
@AIBreveleri: La empresa optó por dar credenciales compartidas a sus empleados en lugar de utilizar cuentas de usuario específicas que se pueden desactivar individualmente. Eso está en ellos, no en OP. Si OP simplemente alerta a la empresa mucho antes de su fecha de salida que las contraseñas de estas credenciales (enumeradas por OP) deben cambiarse; eso es suficiente para cubrir OP. Si las contraseñas no han sido cambiadas, la empresa es responsable de las consecuencias de no cambiar esas contraseñas. La respuesta de Joe ya contiene más diligencia de la que (mínimamente) se requiere para cubrir el trasero de OP, no es suficiente.
Deje que se cierren ya que las contraseñas se cambian de la original.
Esto casi va demasiado lejos en algunos aspectos y, sin embargo, no lo suficiente, en mi opinión. Proporcionaría un documento con la lista, afirmaría que "<empleado> realizará el mejor esfuerzo posible para limpiar los administradores de contraseñas de las credenciales antes mencionadas y que <empleador> no responsabilizará a <empleado> por la fuga o el uso posterior de las credenciales antes mencionadas "... pídale a un abogado que lo revise y haga que tanto el <empleado> como el <empleador> lo firmen. (IN BLOOOOD) ... déjelo en manos del empleador en ese momento si las credenciales representan un riesgo tal cual, pero cúbrase el culo.
O, al menos, asegúrese de haber enviado una declaración por escrito de que ha borrado los créditos de sus cachés, recomiéndelos y confíe en que todos se rotarán después de su partida... Y, probablemente, envíe su dirección personal una copia de este correo electrónico (quizás sin la lista enumerada de cuentas para las que tenía credenciales).
Esta es una respuesta razonable. No es responsabilidad de los OP ocuparse de la seguridad de TI al dejar la empresa. Un buen departamento de TI debe saber EXACTAMENTE quién tiene qué acceso y hacer los cambios apropiados cuando alguien se va. Hacer una lista no debería ser necesario, pero demuestra buena fe.
Agregaría priorizar cada contraseña que se pueda usar desde Internet. Saber la contraseña de algún servidor al que no se puede acceder desde Internet es menos crítico.

De hecho, eres vulnerable a ese tipo de acusación. Sin embargo, esto es en parte un lío de su propia creación, porque hasta ahora no ha utilizado buenas prácticas de seguridad. Lo sabes, y no lo insistiré.

Generalmente hay tres tipos de modelo de seguridad para un sitio web orientado a servicios.

  • Un inicio de sesión (cuenta/contraseña) para la cuenta corporativa. Se espera que todos los usuarios de la empresa compartan la contraseña y cualquiera de ellos puede causar caos. MailChimp es así, por ejemplo.
  • Una cuenta maestra/contraseña para la cuenta corporativa. Es posible simplemente compartir esa contraseña, pero también brindan la posibilidad de crear subcuentas individuales : un nombre de usuario/contraseña para cada empleado. Cada actividad se registra en su subcuenta PayPal funciona así: mis inicios de sesión para ABC Company son ABCCo-Harper y ABCCo-HarperAdmin. (El primero solo está priv'd para punto de venta).
  • El sitio solo permite cuentas de humanos reales , luego asocia empresas con humanos. Los ejemplos son una "página" comercial de Facebook, en la que cualquier cantidad de humanos son administradores, colaboradores o anunciantes.

Los servidores en sus propias instalaciones seguramente aceptan el modelo de "subcuenta"; deje de compartir la raíz y configure cuentas de administrador con sudo.

Desenredando esta red retorcida

Es demasiado tarde para hacer lo más importante: desviarse de su camino para seleccionar proveedores con arquitecturas de contraseña sólidas. Al configurar nuestros sistemas comerciales, fui muy selectivo al respecto; sin embargo, la mitad de nuestras cuentas son del tipo de contraseña compartida porque muy pocos proveedores admiten cuentas sub/reales.

En los sitios de "solo cuentas humanas reales", el sitio ya lo ha obligado a adoptar un modelo de seguridad competente . En este momento: asegúrese de que los humanos correctos en su empresa tengan una cuenta y promuévalos adecuadamente; al menos uno debe ser el rango más alto. En su último día: dígale al sistema que disocie su cuenta con el activo de la empresa. Pan comido.

En sitios capaces de subcuentas individuales, en este momento : configure subcuentas para los humanos correctos en su empresa, incluido usted mismo, emita contraseñas y olvide las contraseñas que les proporcionó. Asegúrese de que el personal apropiado tenga la contraseña maestra y pídales que la cambien de inmediato. En tu último día : aléjate y no vuelvas a iniciar sesión en tu subcuenta. Deberían borrarlo , pero si no lo hacen, ¿a quién le importa? El diario del sistema probará que no hiciste nada.

En todos los demás sitios, primero: asegúrese de que las personas relevantes tengan las contraseñas correctas.

Tiene una variedad de contraseñas que no han cambiado durante demasiado tiempo. Cámbialos. Eso también se aplica a cualquier contraseña que haya almacenado de una manera que sepa que es estúpida. Suponga que está comprometido y cámbielo AHORA y déles la nueva contraseña. Debe hacer esto ahora, mientras todavía hay un mes de tiempo de recuperación. Hacer esto en la última semana es demasiado tarde.

Y limpia detrás de ti mismo; una vez que las haya restablecido, elimine todas las contraseñas de lugares donde no deberían estar, como correos electrónicos (!), documentos de Google y similares. No estoy seguro de cómo me siento acerca de los administradores de contraseñas; están lejos de lo peor y no lejos de ser la forma menos mala de lidiar con eso.

Y no hagas ningún lío nuevo; Si alguien te pide una contraseña, no la envíes por correo electrónico, twittees o envíes mensajes de Facebook. Para de hacer eso. Escríbalo en un papel, ciérrelo en un sobre y entrégueselo. La seguridad física es su problema. O llámalos por teléfono y léeselo.

Distribuir nuevas contraseñas

Estoy lidiando con pelos puntiagudos tecnófobos , así que escribo contraseñas en papel. Hago un documento de MS-Word que enumera cada cuenta y ABCDEFG donde irían las contraseñas. Eso puede ser distribuido electrónicamente. Luego tengo otra hoja que dice simplemente ABCDEFG con un espacio para una contraseña para cada uno, y que entrego en mano. Para los gerentes de pelo puntiagudo que es poco probable que las usen, pongo las contraseñas maestras en un sobre que dice "¡Contraseñas maestras! No abrir excepto en caso de emergencia".

En cuanto a la generación de contraseñas, finalmente me quedé sin discos de AOL :) Así que uso un trozo de perl y /usr/lib/dict/words para generar una contraseña de tipo CorrectHorseBatteryStaple ajustada para funcionar en la mayoría de los sitios y ser compatible con dispositivos móviles ( es decir, no está escribiendo turnos más que caracteres).

Hacer que se reinicien detrás de ti

Cuando les distribuya nuevas contraseñas, envíeles un correo electrónico por separado informándoles profesionalmente que ha cambiado las contraseñas, la lista de cuentas para las que ha cambiado las contraseñas y diga que proporcionó la lista de contraseñas en papel (o como sea). CC esto a su dirección de correo electrónico personal, fuera del sitio, y BCC a su abogado . No hace falta decir que este correo electrónico NO debe contener ninguna contraseña .

Luego, al salir, envíeles otro correo electrónico de la misma manera para recordarles que dejará la empresa a partir de la fecha/hora y cambie las contraseñas compartidas detrás de usted. Nuevamente, CC para su personal y BCC para su abogado.

Realmente, en este punto, has hecho todo lo que puedes hacer. Si tienen problemas, usted y su abogado muestran esos documentos en la corte, demostrando que era su responsabilidad cambiar las contraseñas detrás de usted, y usted les dijo eso . (Por supuesto, también niega haber hecho algo, pero al mostrar su negligencia, socava cualquier reclamo de daños).

Con suerte, si hace lo que le digo, los habrá "animado" a la idea de cambiar sus contraseñas de vez en cuando. Ellos también saben que necesitan hacerlo; acabas de hacer el trabajo pesado por ellos.

Ahora, inscriba a un aliado en la empresa para restablecer las contraseñas detrás de usted.

NO, bajo ninguna circunstancia, inicie sesión en una cuenta "para ver si cambiaron la contraseña". ¡No importa lo curioso que seas! Ni siquiera debería poseer más contraseñas; deberías haberlos eliminado de donde sea que guardes las contraseñas. Sea minucioso. Ciertamente, si hay un litigio, citarán su computadora portátil y una lista de cuentas de 1 contraseña, etc. Si muestran que guardó contraseñas, eso socavará su defensa de que no fue usted.

Gracias por el tiempo dedicado a escribir una respuesta tan buena. Creo que funcionará para la mayoría de las personas en mi posición. Todavía estoy en problemas porque solo me queda 1 semana y cambiar alguna contraseña/clave sería un verdadero PITA (por malas prácticas establecidas antes de mi llegada, por ejemplo, una clave API puede compartirse entre varios servicios, nadie recuerda cuál, vamos cambiarlo y ver lo que se rompe). Mi otro temor es: si les pido que cambien todo lo que sé, ¿sospecharán (ya que nadie tiene una lista clara de todas las credenciales de la empresa) que estoy planeando hacer algo desagradable con los secretos olvidados (sin cambiar)?
Realmente dudo que infieran alguna mala intención. Lo verían como un movimiento de CYA, ¡que es exactamente lo que es!, y probablemente lo ignorarían. Solo necesita hacer su parte de la entrega de la contraseña de la manera más responsable posible y dejar un rastro en papel de lo que hizo. De modo que tenga ese rastro en papel para presentarlo en el tribunal si hay una disputa. O, alternativamente, renuncias, ellos hacen lo que sea, * alguien más es despedido y dicen 'Santo cielo, ese tipo nos eliminará, ¿dónde están todas esas notas desechables que nos dieron?'
@throwaway también, la seguridad siempre es un inconveniente. Naturaleza de la bestia. Prepararse mal lo hace mucho más inconveniente, que es el problema que enfrentan hoy.

Como gerente de TI con más de 2 décadas en el campo, puedo decirle que no hay nada que deba hacer. La seguridad de TI adecuada significa que el departamento debe tener registros de qué usuarios o aplicaciones tienen acceso a qué recursos. Cuando alguien se va, o hay una auditoría, o simplemente se cambian contraseñas/claves/etc. en un horario, estos registros deben ser referenciados y actualizados. Desafortunadamente, no todos los departamentos de TI hacen esto, lo que los deja vulnerables sin saberlo.

Si bien no es necesario, hacer una lista de todo lo que tiene acceso muestra buena fe a su empresa. Puede que no sea una mala idea decirles que inviertan en un sistema de control de contraseñas adecuado.

En primer lugar, identificaría a las personas/persona que asumirá su función. Si no puede encontrar a esa persona, conviértala en su administrador.

Abra una cuenta corporativa de LastPass (otro inicio de sesión seguro, con cargo directo a la empresa). Invítese a usted mismo y a su persona de reemplazo a la cuenta. Agregue todos los detalles de inicio de sesión que ha asegurado (de manera insegura) en su correo electrónico.

Cualquier inicio de sesión que esté vinculado directamente a usted, cámbielo para que use detalles corporativos. Por ejemplo, en lugar de registrarse como 'fred.bloggs@example.com', use 'systems@example.com', que luego puede conducir a una lista de distribución.

A medida que agregue identidades a lastPass, elimínelas de cualquier sistema al que pueda acceder después de salir. También deshabilite cualquier información de inicio de sesión personal (por ejemplo, sus cuentas de usuario de AWS; NO elimine las cuentas de usuario raíz :)) una vez que sepa que ya no las necesitará.

Mantenga un registro en Excel de todos los cambios realizados (p. ej., 'Cuenta de AWS 123456: se cambió la contraseña de Fred Bloggs'; no ingrese ninguna información secreta). Entregue ese registro a su gerente cuando se vaya, desvincule su cuenta personal de LastPass (si estaba conectada a la cuenta corporativa) y envíe un correo electrónico a su gerente sugiriéndole encarecidamente que cambie la contraseña maestra de LastPass y todas las cuentas dentro.

Como alguien más dijo anteriormente; no intente iniciar sesión en ninguna cuenta 'para ver si se cambió la contraseña'. No desea que aparezca ningún registro de auditoría de sus accesos después de que se haya ido.

Preferiría una solución en el sitio como KeePass2, en lugar de dar las contraseñas a un servicio de terceros como LastPass.

Cuando se encuentra en este tipo de posición crítica, lo profesional que debe hacer es redactar un documento/manual de entrega para quien lo suceda en el puesto.

Esto incluiría cualquier conocimiento específico del rol, procedimientos paso a paso para cualquier cosa importante o específica del trabajo, y una sección que incluya nombres de usuario y contraseñas.

Esto sirve como referencia para la siguiente persona y se convierte en parte de los recursos de la empresa. He visto documentos de traspaso que hice hace más de una década que todavía están en uso varias personas más tarde, con ellos simplemente actualizándolos o agregándolos a lo largo de los años. Un buen documento de entrega es un recurso valioso de capacitación y referencia.

Tómese su tiempo y hágalo correctamente. Los hago completos con capturas de pantalla, diagramas y procedimientos desglosados ​​en lo básico como si los lectores fueran principiantes.

¿Qué harías? ¡Gracias de antemano!

Hacer nada. Si aún tiene la capacidad de iniciar sesión en cualquier cuenta después de su último día, ¡no lo haga! Sí, la empresa puede sufrir algún tipo de violación de seguridad y usted puede ser acusado, pero mientras deje de iniciar sesión en esas cuentas, no habrá evidencia de irregularidades de su parte.

Si te fuiste en buenos términos, ni siquiera deberían considerarte sospechoso si ocurre alguna violación de seguridad. He dejado empresas con información tan privilegiada y tuve el autocontrol de no intentar usarla. Haz lo mismo y no deberías tener nada de qué preocuparte.

Aclaremos algunas cosas antes de hacer una recomendación:

Cuando se vaya, se espera que ya no acceda a la red de su empresa, por lo general a través del manual del empleado, un NDA, etc., algún tipo de acuerdo, si no está vigente a. tu patrón es tonto b. todavía no debe acceder más a la causa de la red de la ética.

Entonces, en lo que respecta a usted, una vez que se haya ido, deje de preocuparse por eso, no será dueño de nada, incluida su cuenta y el correo electrónico del trabajo.

Ahora, si quieres ser amable... crea un documento o mejor aún un archivo keepass y compártelo. Puede verificar Keepass en la fuente.

Probablemente sea demasiado tarde para esto, pero si puede o en el futuro, aproveche una tecnología como Active Directory/LDAP con un almacén de claves centralizado. La configuración de su empresa es espagueti.

En este momento, lo mejor que puedes hacer es pasarle todo a otra persona. Si es posible, deben actualizar todas las contraseñas, claves y secretos, y colocarlos en un almacén de claves protegido por seguridad.

Con tales tecnologías, tendría un conjunto centralizado de usuarios, roles, grupos y permisos. Con el ecosistema adecuado, como Active Directory con Azure Key Vault, todos los secretos pueden centralizarse y ocultarse detrás de una política que define el conjunto de permisos adecuado.

Además, por ejemplo, puede usar Active Directory para casi todo. El correo electrónico, el entorno de Azure, los inicios de sesión del servidor, etc. Todo es una cuenta de dominio, y todo está siempre oculto por una cosa: el inicio de sesión de su dominio. Esto es elegante.

Cuando un empleado sale del lugar de trabajo, su cuenta simplemente se deshabilita y, por lo tanto, su acceso a todas las claves y secretos también se deshabilita. Su acceso a cada servidor, control de fuente o entorno de nube está deshabilitado. Está muy limpio. Solo se necesita una arquitectura empresarial adecuada. Es posible que existan algunas herramientas de migración, pero mover todas las teclas sería un poco complicado, dependiendo de cómo las almacenó (Excel, bloc de notas, servilletas, etc.)

No necesitas hacer nada. En el ordenamiento jurídico, existe el estándar de "inocente hasta que se pruebe su culpabilidad". Eso significa que si tienen una brecha de seguridad y te culpan por ello, tienen que demostrar ante el tribunal que fuiste tú quien los hackeó usando tus credenciales. Lo cual, dado su espagueti de seguridad, probablemente no podrán hacer incluso si los pirateaste, por lo que legalmente probablemente no seas responsable de nada (IANAL).

Profesionalmente, lo que deberías hacer es decirles "estas son las cosas a las que sé que tengo acceso" (puedes tener acceso a otras cosas que no sabes/has olvidado) y enumerar tantas como puedas. Luego envíe ese correo electrónico a su jefe y/o al departamento de seguridad de la información de su empresa. Después de eso, no hay mucho que puedas hacer; es su trabajo revocar sus permisos y asegurarse de que no tenga acceso después de que se vaya. Si eligen no hacer eso, eso está en su cabeza, no en la tuya. En cuanto a tu responsabilidad, éticamente (y probablemente también legalmente) no deberías usar esas credenciales que tienes, aunque sigan siendo válidas, por ningún motivo , después de tu último día en la oficina. Lo cual, estoy seguro, probablemente era tu plan de todos modos y no necesitaba reafirmarse, pero eso'

Como nota final del desorden, no podrán rotar claves/contraseñas a corto plazo (por ejemplo, el día siguiente a mi salida). Algunas contraseñas nunca se cambiaron desde que se crearon las cuentas, incluso después de que otros empleados se fueran.

Eso está mal, no tiene sentido y hay que instarles a que cambien esta política. Puede parecer una solicitud grosera, pero las consecuencias si alguien hace daño con esas credenciales y lo acusan pueden ser mucho peores que el riesgo de quemar puentes con la empresa.

Le escribiría un correo electrónico al jefe como:

Estimado jefe, este correo es para recordar que todavía tengo acceso a las siguientes cuentas: . Dado que me iré en , le pido amablemente que tome medidas durante este período de tiempo para cambiar las credenciales y asignarlas a otras personas. Atentamente

El último día (o unos días antes), enviaría otro correo indicando claramente que si no se cambian las credenciales, tomaré acciones legales para protegerme.

Además, BCC envía ambos correos a su abogado.

"Tomaré acciones legales para protegerme". ¿Como? Suena como una amenaza bastante vacía.
Bueno, deja que el jefe decida si quiere correr el riesgo de descubrir si realmente es una amenaza vacía, o prefiere simplemente cambiar las contraseñas. Sin embargo, si envía BCC a su abogado en los correos electrónicos anteriores, al menos puede demostrar que solicitó que lo desvinculen de las cuentas.
Creo que probablemente no quisiste decir pretender , que es un falso amigo con algunas (¿todas?) lenguas romances. En inglés, pretender significa actuar como si algo fuera cierto cuando sabes que no lo es . Creo que probablemente quiso decir " tiene que intentar que cambien esta política ".
@PeterTaylor tienes razón, gracias. Lo he reformulado.