¿Cómo debo configurar el acceso de emergencia a los secretos críticos de la empresa en caso de que me “golpee un autobús”?

146

Trabajo como desarrollador principal y administrador de TI para una pequeña empresa. Quiero asegurarme de que los negocios puedan continuar incluso si de repente no estoy disponible por alguna razón. Gran parte de lo que hago requiere acceso a una serie de servidores (a través de ssh basados en claves), servicios en la nube y otra infraestructura segura de aplicaciones. Algunos de estos servicios utilizan MFA, ya sea utilizando aplicaciones de MFA dedicadas (como Amazon) o SMS.

¿Cómo me aseguro de que mi plan y mi documentación "atropellados por un autobús" estén completos y completos, pero que esta documentación no sea en sí misma un riesgo para la seguridad?

La documentación se alojará en un servidor de archivos compartidos detrás de nuestra VPN, pero también se puede acceder a ella mediante una interfaz web de terceros que coloca una interfaz similar a "DropBox" en la parte superior del servidor de archivos base (es decir, autenticación, escritorio). sincronización, intercambio de archivos, etc). Los archivos se encuentran en una ubicación donde solo yo, y otros administradores del servidor de archivos pueden verlos.

¿Cómo debo administrar los "secretos" (contraseñas, claves privadas, acceso MFA) en esta documentación para garantizar que siga siendo integral sin comprometer la seguridad?

    
pregunta AndrewSwerlick 30.11.2015 - 17:55
fuente

8 respuestas

79

Mi consejo sería eliminar los secretos del buzón y guardarlos en otro lugar. Sus instrucciones deben ser fácilmente legibles para cualquier persona, pero pueden incluir instrucciones sobre cómo obtener acceso a la parte de los datos debidamente protegida. Eso le permite separar el lado de accesibilidad de las cosas del lado de seguridad.

Una vez que pueda pensar en la seguridad por sí mismo, puede comenzar a hacer la pregunta real de cuánto necesita proteger estas claves. Esta es una pregunta de lógica de negocios, así que consulte a su gerencia. Usted podría:

  • Tener una contraseña para un archivo que todos conozcan
  • Tenga un archivo configurado con varias contraseñas para que cada individuo mantenga su propia copia.
  • Tener un archivo bloqueado por un algoritmo M-out-of-of (el equivalente digital de requerir dos teclas para desbloquear una caja fuerte).
  • Se requiere un algoritmo M-out-of-of con una contraseña 'maestra' independientemente del grupo de individuos que desbloquee el archivo, y que un maestro se encuentre físicamente en una caja fuerte a prueba de falsificaciones que usted verifique de vez en cuando .

Usa la creatividad aquí. Independientemente de lo que haga, el desacoplamiento de las "instrucciones" con la "información confidencial" lo libera para salvaguardar adecuadamente la información y luego proporcionar instrucciones sobre cómo obtener esos datos más adelante.

Sus decisiones de lógica empresarial también incluirán preguntas sobre el tiempo de actividad. Si algo sale mal en su vida, ¿cuánto tiempo tiene otro administrador para hacerse cargo de su trabajo antes de que se vea afectado el negocio? Considere qué tan bien replicadas desea que estén estas instrucciones e información confidencial en caso de fallas en el servidor. Cuando estaba administrando un servidor y necesitaba almacenar instrucciones sobre cómo restaurarlo desde una copia de seguridad, usé el propio wiki del servidor para almacenar esa información para una fácil visualización, pero obviamente eso no sería tan útil en un escenario de falla, por lo que también tenía una copia en la máquina virtual de desarrollo de esa máquina, guardó copias de ella en 3 PC separadas y una copia impresa. No podía garantizar que la impresión se mantendría actualizada, pero me aseguré de que podía hacer lo mejor posible.

Esto también señala algo que no siempre es parte de un plan del bus: la degradación elegante. No todos los escenarios de golpear por el autobús implican ser golpeados por un autobús. Algunos implican que solo eres inaccesible en un momento desafortunado. Algunos implican que se vaya de la empresa, pero que esté disponible para una o dos preguntas. Otros no lo hacen. Considere la posibilidad de estratificar el plan. Los pequeños contratiempos pueden estar muy bien protegidos, mientras que los percances más grandes aún pueden resultar en pérdidas comerciales mientras que todos se unen, pero nada permanente. Para usar mi plan de restauración de copia de seguridad como ejemplo, casi se garantizó que la versión impresa no estaba completamente actualizada. Pero si un relámpago destruyó todas las computadoras de una cuadra de la ciudad, era aún más útil que nada. Por otro lado, si el servidor solo tenía un disco duro y tenía que restaurar desde la copia de seguridad, la versión que mantenía sincronizada en el cuadro de desarrollo estaba casi sin duda actualizada.

Ejemplo de este fallo: era un usuario en una red administrada por KERBEROS por un administrador que desconfiaba de los demás y no tenía un plan de chocar con un autobús. Cuando él ... se fue, tuvimos una fiesta de piratería para intentar romper su servidor. Al final, nuestro mejor plan improvisado de golpe por autobús fue limpiar las máquinas (cada una de ellas) y comenzar desde cero. Tenga en cuenta que, si bien este no fue el mejor plan (de hecho, ¿creo que es el peor plan?), El negocio siguió avanzando. Nos quedamos estancados durante unos dos días y tuvimos un montón de clientes malhumorados. En palabras de Dune de Frank Herbert, "la especia debe fluir". Incluso en el peor de los casos (que puede implicar un incidente curioso que involucra la unidad de disco duro de su servidor lanzada fuera del bus y golpearlo en la cabeza, destruyendo todos los registros del plan de chocar con un bus), el negocio hace tengo una manera de seguir moviéndome ... ¡pero estoy de acuerdo en intentar elevar un poco la barra!

    
respondido por el Cort Ammon 30.11.2015 - 18:16
fuente
74

Consigue un dispositivo USB. Ponga todos los secretos en el USB, preferiblemente en un archivo KeePass. En la documentación, diga a la nueva persona dónde está el USB y cómo desbloquearlo, pero coloque el dispositivo en una ubicación física segura como la oficina del propietario, la caja fuerte de la compañía, una caja de seguridad, etc. En algún lugar fuera del alcance de la Público, y alejado de las miradas indiscretas de otros empleados.

Las ventajas de este plan son:

  • No está en internet ni en la red interna
  • Puede estar seguro de que el nuevo empleado al menos ha logrado convencer a la persona a cargo de la ubicación de almacenamiento de que es auténtico (y lo más probable es que los empleados de alto nivel la flanquen para que incluso se acerquen a su ubicación de almacenamiento).
  • Si alguien trata de llegar al flashdrive antes que usted, eh, si el bus proverbial lo golpea, es probable que alguien piense para sí mismo: "Hmm, Andrew sigue vivo. ¿Por qué alguien está tocando esto?"
  • Si alguien encuentra su documentación, la cantidad de daño que podrían hacer es limitada (especialmente si lograron ingresar a través de Internet; muy pocas personas van a viajar por carretera para obtener su información).

Para encontrar las golosinas, necesitan 1) su documentación, 2) acceso físico, 3) estar "añorando los fiordos". El USB también es un paquete pequeño y ordenado para la siguiente persona: ¡plug and play! O pánico, dependiendo de lo importante que seas para la empresa.

    
respondido por el Ohnana 30.11.2015 - 18:16
fuente
29

Crear cuentas de 'solo uso de emergencia'

Para la mayoría de los sistemas, tendrá algún tipo de cuentas privilegiadas que se utilizan en su administración diaria, que pueden personalizarse o no según la política de su organización.

Al igual que con cualquier credencial, puede perder el acceso a ellos por varias razones, ya sea por la persona que sabe que un autobús lo atropella, o por perder el almacenamiento seguro previsto de esa credencial (por ejemplo, perder una computadora en un incendio) o de alguna manera logrando cambiar una contraseña a algo que no saben, etc.

Lo que puede ser útil es crear cuentas separadas para sistemas clave que tienen acceso completo, pero que no están diseñados para el uso diario. Esto implica:

  1. En este momento, nadie puede acceder a ellos, ninguna persona conoce las contraseñas necesarias.
  2. Si alguien accede a ellos, todos deberían estar informados (ya que no se supone que ocurra en circunstancias normales). Por ejemplo, los scripts automatizados que envían correos electrónicos a múltiples usuarios clave al iniciar sesión, todas las acciones de esas cuentas se registran y su control diario se encenderá si algo se ejecuta desde esas cuentas.
  3. Cuando sea necesario, las personas pueden obtener acceso a estas cuentas; una forma sencilla es generar una contraseña o clave largas, imprimirlas, colocarlas en un sobre sellado y firmado y guardarlas en una caja fuerte.

Ponga sus procedimientos de copia de seguridad y credenciales allí

Cuando mantiene sus procedimientos, el plan de acceso directo al autobús y las listas de credenciales secundarias de la forma que le resulte más conveniente, solo asegúrese de que estos documentos o bases de datos de contraseñas también sean accesibles desde la cuenta de uso de emergencia.

    
respondido por el Peteris 30.11.2015 - 19:50
fuente
11

Tal vez una solución mejor para su situación es diseñar el sistema de tal manera que, incluso si lo golpea un autobús y sus credenciales se pierden para siempre, no sucede nada malo.

Quizás es mejor pensar en el problema como dos problemas, autenticación y autorización .

La autenticación establece que usted es quien dice ser. Algunos sistemas pueden saber que una solicitud provino realmente de usted porque solo alguien con sus credenciales pudo haber hecho la solicitud, y solo usted conoce las credenciales.

La autorización establece que se le permite hacer una cosa determinada. Una solicitud puede ser auténtica pero no autorizada.

Si al menos dos personas están autorizadas para hacer algo, entonces no importa si una de ellas es atropellada por un autobús. Alice puede ser asesinada por un autobús, y el conocimiento de sus credenciales se pierde para siempre. Pero Bob conoce sus propias credenciales y está autorizado a hacer cualquier cosa que Alice pueda hacer.

Si el sistema está diseñado de tal manera que cualquier persona pueda ser golpeada por un autobús y matada literalmente, también significa que es posible revocar las credenciales de una persona. Los ex empleados, especialmente aquellos que salen en malas condiciones, son una responsabilidad de seguridad. No puede obligar a un ex empleado a olvidar una contraseña, por lo que para estar seguro, debe cambiar todas sus contraseñas compartidas cada vez que un empleado se retire. En la práctica esto es demasiado doloroso y no está hecho. No compartir las contraseñas en primer lugar resuelve el problema.

Nunca compartir contraseñas también conserva responsabilidad . No puede dirigir un negocio sin administradores, pero le gustaría tener la capacidad de saber si un administrador en particular abusa de sus poderes. En última instancia, la amenaza de terminación o litigio disuade a cualquier administrador del abuso. Si las contraseñas son compartidas, entonces "debe haber sido uno de los otros administradores con la contraseña" es una defensa plausible.

A veces te encuentras en situaciones en las que parece imposible evitar compartir una contraseña. Pero generalmente hay una solución, incluso si no es inmediatamente obvia.

¿Necesita compartir contraseñas de root? No, no puedes tener una contraseña de root y, en su lugar, utilizar sudo .

¿Qué pasa con las credenciales de raíz de AWS? Puedes usar IAM en su lugar.

¿Tal vez tienes una aplicación web que no puedes evitar? Es posible que no pueda solucionar este problema pero puede cubrirlo: use un administrador de contraseñas que permita compartir credenciales entre varios usuarios. (Sé que LastPass puede hacer esto). Mientras aún está compartiendo la contraseña, al menos tiene un medio automatizado para cambiarla y distribuir el conocimiento de la nueva contraseña. Cambie la contraseña al menos cada vez que un empleado se vaya, pero preferiblemente con más frecuencia.

    
respondido por el Phil Frost 01.12.2015 - 22:40
fuente
6

La mayoría de las respuestas aquí se refieren al manejo de credenciales, probablemente debido a esta pregunta explícita en el OP:

  

¿Cuál es la mejor manera de administrar los "secretos" (contraseñas, claves privadas, acceso MFA) en esta documentación para garantizar que siga siendo exhaustiva sin comprometer la seguridad?

Sin embargo, el título hace una pregunta diferente, que no veo dirigida:

  

Desarrollar un impacto seguro mediante un plan de autobús

La respuesta a la pregunta que es la automatización.

En los devops, encuentro que la mayor parte del lado del servidor de la posición se divide en dos categorías:

  • Corregir la infraestructura : por lo general, no hay nada que automatizar: cada problema es diferente. En esos casos, la familiaridad con la infraestructura (servidores, red, cómo interactúan los desarrolladores con los repositorios de Git) es clave.

  • Mantener la infraestructura : crear nuevas instancias de VM, configurar Apache , habilitar dev acceso a recursos, etc. Este es el lugar donde la automatización es más visible.

El rol de la automatización en el último es obvio, la clave para solucionar problemas en el primero es la automatización en el segundo . Los scripts automáticos de Python y Bash sirven como documentación viva de lo que se espera de los servidores y la red: cuando el flujo de trabajo cambia, son los scripts los que cambian. Git registra los cambios que pueden ser aplicables a servidores más antiguos, y los mensajes de confirmación de git son explícitos.

    
respondido por el dotancohen 01.12.2015 - 10:53
fuente
2

Esta no es otra idea sobre cómo hacerlo per se, sino un punto para señalar algo que aún no se ha discutido pero que es muy importante. Estoy procediendo desde el punto de vista de que estos secretos son realmente críticos para el negocio.

Pruebas.

Se han postulado algunos escenarios de recuperación de desastres. Algunos son simples, otros son más complejos. A mayor complejidad, mayor razón para probar. Este problema se deriva de cómo se prueba que alguien se "elimina" de la escena en un entorno empresarial crítico. Pasar una ronda de 20 mm a través de su servidor de producción durante las operaciones navideñas, con su principal informático incomunicado, será difícil de obtener a través del tablero de su fábrica de juguetes. Este es el dilema que enfrenta el tablero. Si es importante, necesitas probarlo. Aunque es demasiado importante para probar?

Las cosas simples te atraparán. Alguien ha mencionado poner datos en cajas fuertes. Genial. Mucha gente guarda sus cajas fuertes en el sótano donde está seguro y lejos de las personas. También es el lugar que inicialmente se llena de agua después de un incendio menor. Otro; su empleado de nómina poco ferviente ha estado haciendo cosas realmente poco fiables con su nómina. La policía entra y confisca todos sus servidores para la investigación subsiguiente. Se necesita un año para recuperarlos. No pongas los ojos en blanco, sucede.

La continuidad del negocio es un arte bastante establecido, así que haz lo que hacen la NASA, Google, Barclays, el ejército y las centrales nucleares. Hacer redundancia. Lamento decirlo, Andrew, pero tú eres el principal riesgo para la empresa en este escenario. La junta debe ser consciente de esto, y usted y al menos parte de su kit deben ser redundantes (en el sentido de la duplicación).

Mientras tanto, pídale al director de operaciones que obtenga un seguro de persona crítica y / o un seguro de continuidad comercial.

    
respondido por el Paul Uszak 04.12.2015 - 15:22
fuente
1

Estoy en una situación muy similar a la de un administrador de TI único para una empresa de tamaño medio con una gran cantidad de software personalizado dispersos y poco relacionados en diferentes plataformas. Peor que eso, escribí todo el software para la compañía en los últimos diez años, desde su sistema POS a reservas en línea, un CMS casero, software de capacitación para empleados, etc. En este punto, soy la única persona que entiende o ha tenido Incluso visto la fuente de esas cosas. A medida que la compañía creció, más de una vez me pidieron que no me atropellara un autobús. Le diré cuál ha sido nuestra solución a esto.

  1. Comprende que habrá una interrupción. Gestionar las expectativas. Si la empresa no desea contratar a una persona redundante, probablemente una bien pagada, para aprender todo lo que sabe, entonces debe esperar que haya una curva de aprendizaje muy pronunciada para cualquier persona que necesite acudir durante una emergencia y Intenta llenar tus zapatos. Esto es cierto sin importar cuán grande sea su documentación.

  2. Asegúrese de que las facturas del servicio vayan a la empresa, no a usted.

  3. Continuidad del documento comercial. En un momento se me pidió que escribiera un documento que se expone en un lenguaje sencillo, que el CEO de la empresa pueda leer, exactamente qué servidores tenemos, qué hay en cada servidor, qué hace cada pieza de software y las contraseñas de aquellos. cuentas Dentro de eso hay notas y consejos para todos los que vinieron y necesitaron seguir funcionando. Sin embargo, según (1) se entiende que se necesitaría un libro para explicar en detalle las funciones, los problemas y limitaciones conocidos y la estructura de todo el software. Por lo tanto, este documento contiene lo esencial, con la esperanza de que una vez que alguien haya ingresado en el código comience a ver las tareas de cron y a leer los comentarios, y controlar cómo funciona.

Actualizo el documento de continuidad cuando sea necesario, PGP lo cifra para que solo lo puedan abrir el CEO de la empresa y yo mismo, y lo subo a su servidor web en una dirección que él sepa. El CEO es responsable de mantener segura su clave PGP. Eso es todo lo que hay que hacer.

Y escucha, si ni siquiera te dejan relajarte después de que te mueras, es hora de pedir un aumento.

    
respondido por el joshstrike 06.12.2015 - 19:12
fuente
-1

Su solución, para ser completa, debe ser una combinación de controles de procedimiento y técnicos. La mejor manera de entenderlo es ver que los controles tecnológicos brindan la capacidad de mejorar la seguridad de sus procedimientos. Hacen posibles algunos controles y otros más fáciles de ejecutar.

Teniendo esto en cuenta, dependerá en gran medida de cómo uses tu PKI. Si está en una organización más pequeña, las restricciones de presupuesto pueden limitar lo que puede hacer, pero si es posible, recomendaría un Módulo de seguridad de hardware (HSM) para proteger sus claves privadas, al menos, las claves privadas de su CA interna, si tienes una. Los proveedores en este espacio incluyen Thales y SafeNet.

En cuanto a las contraseñas, existen varias soluciones de administración de contraseñas diseñadas para servir a las organizaciones. Lo más importante que debe buscar es una de estas dos cosas: una solución que ofrece la capacidad de otorgar a un usuario los privilegios de acceso necesarios para realizar su trabajo dentro de una ventana de tiempo predefinida sin tener que dar a dicho usuario la contraseña real para el sistema / aplicación, Y / O un sistema diseñado para soportar el conocimiento dividido secreto (donde nadie tiene la contraseña completa).

Algunos proveedores de seguridad ofrecen un medio para crear una separación de roles adicional en lo que puede hacer un administrador de dominio de AD o un administrador de base de datos (por ejemplo, pueden agregar usuarios a grupos, pero no habilitar la capacidad de abrir / modificar archivos) esa membresía de ese grupo normalmente les da derecho a eso, esa capacidad sería manejada por otro administrador que tampoco puede agregar / eliminar usuarios a los grupos. Un proveedor de este tipo es Vormetric: hacen esto con el producto de cifrado de datos en reposo.

Si bien el apoyo ejecutivo es importante para el éxito de la estrategia de seguridad de cualquier organización, se vuelve especialmente importante en ausencia de una solución de proveedor que ofrezca estas capacidades, porque eso significa que probablemente deba intensificar sus programas de conciencia de seguridad para fomente el tipo de cambio cultural que admitirá los controles de procedimiento necesarios a los que la mayoría de los usuarios de TI no están acostumbrados: donde los privilegios de administrador de empresa y dominio están estrictamente controlados, y se otorgan solo después de que se otorgue la aprobación de la administración de cambios, y solo durante una ventana de tiempo específica . Los administradores de TI deben incorporar contraseñas de varias personas + controles físicos.

Los ejemplos incluyen el uso de 2 a 4 personas para generar la mitad de una contraseña de 12 caracteres. Un par de personas genera la contraseña y la ingresa en el campo "Nueva contraseña". El segundo par vuelve a ingresar los componentes de la contraseña que creó el primer par (para ayudar a garantizar que uno del primer par no maliciosamente o no escriba mal la contraseña cada vez, haciendo que la cuenta sea inaccesible una vez que se cambie la contraseña). El uso de un segundo par de personal también garantiza que las contraseñas sean legibles como están escritas. Una vez que se cambia la contraseña, los fragmentos de la contraseña se almacenan en sobres opacos separados, se sellan, se etiquetan y se depositan en bolsas a prueba de manipulaciones. Las bolsas se pueden dejar caer en una caja de seguridad física. Replique el proceso para el almacenamiento de copias de seguridad fuera del sitio, pero incorpore procesos para garantizar que las actualizaciones de contraseñas se repliquen cada vez para cada sitio. Si el almacenamiento a prueba de manipulaciones no es suficiente, busque una caja fuerte de doble combinación aprobada por GSA (X-10 Kaba Mas, por ejemplo), e incorpore el mismo procedimiento de conocimiento dividido. Para obtener protección adicional, almacene la caja fuerte en un lugar con un sistema de cámaras de CCTV que monitorea el área e incorpore una advertencia a todos los empleados de que cualquier persona que se encuentre en el área sin permiso previo por escrito para ingresar puede estar sujeta a la terminación. desde la parte superior.

Realmente solo depende de su modelo de amenaza y del apetito que tenga su organización por la seguridad.

    
respondido por el PurpleDragon 30.11.2015 - 18:15
fuente

Lea otras preguntas en las etiquetas