Teletrabajo con entornos Windows y coronavirus

Si bien algunas empresas están ya habituadas a permitir a sus empleados realizar trabajo en remoto, con la pandemia del coronavirus muchas otras se han visto forzadas a utilizar recursos limitados para un gran número de trabajadores.

Lo primero de todo, debemos tener en cuenta los servicios nativos cloud, los cuales permiten realizar tareas desde cualquier sitio de forma habitual. Por otro lado, el acceso a recursos locales dentro de la empresa debe asegurarse de diferentes formas:

  • Sistemas de alimentación ininterrumpida deben proveer corriente a los servidores o equipos con disponibilidad, algo básico pero necesario.
  • Seguridad de red activa, abrir un puerto o varios para permitir un servicio (por ejemplo de conexión remota) debe conllevar su monitorización activa en busca de patrones o usos inadeacuados. Firewall dedicados o Azure Bastion por ejemplo.
  • Autenticación de doble factor, donde sea posible y factible, como punto de verificación de identidad de humanos frente a máquinas.
  • Sistemas operativos y antivirus actualizados, no debería llegar una pandemia para tener este punto mínimo cubierto.

Dentro de los entornos corporativos con recursos limitados, se han habilitado ordenadores para su acceso por escritorio remoto, si bien las soluciones RDS/VDI/WVD son muy capaces, para PYMES puede no ser una opción asequible en todos los casos. Por ello debemos tener en cuenta cuando habilitamos el acceso remoto:

  • Separar y securizar redes según los perfiles y requisitos de acceso
  • Establecer directivas de red suficientes
  • Monitorizar y controlar los usuarios permitidos

Si llegados a este punto permitimos el acceso remoto al puesto de trabajo habitual de un trabajador, deberemos tener en cuenta adicionalmente:

Debemos estar seguros lo que supone introducir un ordenador dentro de la red corporativa, así como tener en mente primero a las personas y luego a las máquinas.

 

 

Exportación de certificado X.509 codificado en PEM

La digitalización en la administración pública no lleva precisamente un ritmo rápido… y tampoco lo ponen fácil a usuarios finales…

Veremos como para dar de alta un proveedor en FACe, o gestionar su renovación, nos solicitan certificado en formato PEM. Por simplificar, tal como en un fichero de texto Word o una hoja de Excel tenemos diferentes formatos y versiones con los que podemos trabajar, con el certificado nos pasa lo mismo.

En este caso PEM se codifica en Base64 encerrado entre la cabecera «—–BEGIN CERTIFICATE—–» y el fin de contenido con «—–END CERTIFICATE—–«.

Sin entrar en detalles técnicos, por ilustrar con un ejemplo, el texto «Este frase sería codificada» en base 64 contendría: «RXN0ZSBmcmFzZSBzZXLDrWEgY29kaWZpY2FkYQ==»

Este tipo de certificados se basan en el estándar «Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile» siguiendo la normativa RFC 5280. Gracias a ello podemos identificar el propietario, emisor (Autoridad de Certificación), fecha de caducidad, fecha de misión… basándonos en infraestructura de clave pública (PKI – Public Key Infraestructure)

Por tanto lo que nos están pidiendo es un «certificado X.509 codificado en formato PEM».
En un escenario habitual en un entorno Windows donde tenemos almacenado el certificado accedemos ejecutando el comando «mmc.exe» (existen otras opciones de visualización pero esta funciona en todas las versiones de Windows hasta ahora)

Nos aparecerá una ventana de consola, y bajo la opción del menú «Archivo» la opción: «Agregar o quitar complemento»

A continuación seleccionamos «Certificado» entre los complementos disponibles y pulsamos en agregar: 

Seleccionamos «Mi cuenta de usuario» teniendo en cuenta que los certificados mostrados son los del usuario que ha iniciado sesión en el equipo:

Dentro de «Personal» / «Certificados» nos mostrará todos los disponibles del usuario actual. El icono del listado, muestra una pequeña llave en aquellos certificados de los que disponemos la parte privada:

Haciendo clic con el botón derecho sobre el certificado pulsamos en «Todas las tareas» y «Exportar». Debemos seleccionar el formato de codificación X.509, no debemos exportar la clave privada en este caso:

Indicamos una ruta de nuestro ordenador para guardar el certificado, pulsando con el botón derecho sobre el certificado «Abrir con…» y seleccionamos el editor de texto Bloc de notas nos mostrará:

Con este contenido ya podemos copiar y pegar en la página de FACe de proveedores.

 

Seudonimización y anonimización de datos personales en la RGPD

La utilización de técnicas de encriptación, índices alternativos y otros elementos de seguridad no garantizan la anonimización de datos mientras sea posible acceder a la misma información atravesando un camino más complejo, pese a ello permitiendo identificar indirectamente a la misma persona física o conjunto de datos.

Ninguna técnica de anonimización carece de deficiencias, aunque algunas de ellas permiten disociar la información suficiente como para no poner en peligro la privacidad suponen la alteración inherente de las fuentes.

En ciertos escenarios, con grandes valores de una muestra sería posible de manera eficiente suprimir los datos no relevantes identificativos de un individuo. Por ejemplo, la estadística de afección de una enfermedad cardiológica en una región no necesita mostrar el nombre del paciente.

Además de la eliminación de datos no relevantes, también es posible realizar su generalización. Por ejemplo, sustituimos la edad por un rango o la localidad por un código postal más amplio.

Estas técnicas de anonimización denominadas generalmente k-anonymity han ido evolucionando, introduciendo mejoras para evitar revertir el anonimato centrados en dos posibles factores:

  • La homogeneidad de la muestra, es decir, un valor sensible dentro de un conjunto determinado de registros en los que los valores son idénticos. Por ejemplo, el 99% de la muestra de pacientes obtenida en la micronesia no contiene haplogrupo de tipo M, con lo que sería más sencillo identificar ese 1% restante de origen indio.
  • Conocimientos genéricos, por ejemplo, conociendo un rango determinado de edad en la que los accidentes de tráfico son más frecuentes es posible extraer un grupo de datos reducido con ciertas características.

Al igual que sucede con los cifrados, el esfuerzo de tiempo/dinero debe ser lo suficientemente alto para que su realización no salga a cuenta por parte del atacante. El análisis de riesgos y la adopción de buenas prácticas, protocolos, formación del personal… definen la intención y diligencia del responsable del fichero.

Pese a todo ello, la identificación indirecta sigue siendo un riesgo difícil de abordar o proteger. Si varias empresas disponen de datos anonimizados independientemente, sería posible cruzarlos para llegar a identificar a una persona concreta. Por ejemplo, datos de movimientos de un banco, resultados médicos de una revisión, pólizas de seguros contratadas, datos demográficos de una localidad…

Tal vez ahora se vea más claro el valor y poder de la información que manejan algunas empresas nacidas de internet como Google, Linkedin, PayPal o Facebook por poner nombres a las bases de datos.

Deben analizarse los peligros de reidentificación según los objetivos y finalidad de la información anonimizada, teniendo claro el umbral de riesgo aceptable.

Una vez repasadas alguna de los conceptos de anonimización, podemos entrar en lo que los perfiles jurídicos denominan seudonimización: sustitución de un atributo (normalmente único) por otro en un registro; dentro de un perfil técnico que haya ideado una base de datos relacional lo denominaría: clave primaria, con su ejemplo más sencillo de utilizar un DNI como tal, un valor autonumérico o un GUID.

Si bien estas técnicas vienen aplicándose en cualquier base de datos relacional, las recomendaciones sugieren (si no se ha hecho todavía) la adición de una capa adicional de seguridad a los datos, a las claves u a ambos, de cifrado con clave secreta. Si además añadimos un valor aleatorio (salt) y funciones hash de cálculo para su comprobación, el coste efectivo frente a un ataque se incrementa.

Teniendo en cuenta el almacenamiento que suele realizarse de las claves y contraseñas, sería aconsejable utilizar técnicas adicionales mixtas. Por ejemplo, si en lugar de basarnos solo en las contraseñas utilizamos datos biométricos en un canal seguro, es decir, una lectura de iris, un patrón de voz o una huella dactilar es otro dato binario más al que podemos aplicar un hash determinado, pero si el canal de obtención es único y seguro podemos combinarlo con una autenticación doble, poniendo las cosas más difíciles en caso de intentos de acceso no autorizados a la información.

 

 

Autenticación doble en Microsoft 365 y Outlook.com

La autenticación de doble factor añade una seguridad adicional a nuestra cuentas siempre conectadas. No es infalible pero si necesaria para datos/operaciones críticas, el juego del gato y el ratón en seguridad es continuo, como Hesperbot.

Actualmente podemos:

La opción más ágil es a traves de la aplicación Microsoft Authenticator, despues del baile de nombres que ha sufrido la app, esta disponible para Android, Windows y iPhone nos mostrará un código o un mensaje de aceptación según prefiramos.

En el caso de las cuentas de Microsoft, es necesario diferenciar las de Office 365 empresarial y las de Outlook/Live el proceso de configuración y creación de contraseñas para aplicaciones no compatibles es diferente a día de hoy:

Office 365 -> Configuración -> Seguridad y Privacidad -> «Actualice los número de teléfono que usa para la seguridad de la cuenta»

No es una opción muy destacada en la configuración, debería tener su propia sección o aparecer más claramente pero bueno…

En la parte superior aparecerá la opción «Contraseñas de aplicación» donde podemos dar un nombre para identificar donde hemos usado la contraseña. Una vez creada no es posible volver a verla, solo podremos eliminarla y volver a crear otra:

NOTA: En el caso de realizar la configuración de la app por primera vez, deberemos seguir el asistente inicial desde el botón «Configurar»

Con Office 365 nos permite dar nombre a las contraseñas:

 

URL para Office 365: https://account.activedirectory.windowsazure.com/AppPasswords.aspx

URL para Outlook/live: https://account.live.com/proofs/AppPassword

 

 

Exportar certificados SSL con CA intermedias incluidas

Los certificados SSL emitidos que requieran de entidades intermedias, a la hora de exportar es posible añadirlos en un único PFX (Personal Information Exchange). En cualquier equipo con el certificado que queremos exportar y el certificado intermedio de confianza instalado (en este caso RapidSSL)

Seleccionamos exportar con la clave privada para tener el archivo PFX con contraseña correspondiente:

Debemos seleccionar «Export all extended properties» para incluir toda la información en un único archivo:

Si exportamos, con y sin, esta opción veremos que el archivo generado difiere en tamaño igualmente. Ya podremos importar sin problemas en cualquier dispositivo, servicio cloud o similar.