Cómo mejorar la seguridad en el teletrabajo.

Estos días el teletrabajo está más presente en nuestras vidas de lo que ha estado nunca. Por culpa del famoso COVID-19 (a.k.a. Coronavirus) muchas empresas han tenido que instaurar el trabajo en remoto para todos sus empleados de la noche a la mañana, sin casi tiempo para prepararse y sin tener otra opción.

Algunas empresas ya tenían políticas de teletrabajo y ha tenido menos impacto…. Aún así, ¿estamos preparados para un escenario 100% remoto?

En las siguientes líneas vamos a ver acciones que ayudarán a nuestra empresa a minimizar el impacto de esta situación en su operativa. Para los ejemplos me basaré en Google Cloud Platform por ser la nube que mejor conozco, pero seguro que casi todo lo aquí expuesto puede realizarse sobre otras nubes u otros servicios.

El problema: saturación de la red interna y configuración de los accesos VPN

Por razones de seguridad o legislativas, muchas empresas necesitan tener su propia red interna donde ejecutar determinados procesos. A estos recursos solo se puede acceder desde dentro de la red o haciendo uso de una conexión VPN.

Los dos grandes problemas de un escenario con gran número de conexiones en remoto es la sobrecarga de la red interna y la necesidad de asegurar que todos los equipos pueden conectarse mediante un cliente VPN, pudiendo acceder a las herramientas necesarias para su día a día.

Una manera de minimizar estos problemas consiste en migrar a la nube pública la mayor cantidad de estos servicios, dejando solo los procesos imprescindibles con acceso interno/vpn.

Con un enfoque como este, conseguiremos que un menor número de empleados necesite conectarse a la VPN, menos equipos que configurar, mantener y, sobre todo, menos tráfico.

Usando Software como Servicio

Uno de nuestros grandes aliados es el software como servicio (SaaS), que nos permite usar aplicaciones de manera segura sin necesidad de tener nosotros el software.

¿Alguien se imagina hoy en día que una nueva empresa montara sus propios servidores de correo electrónico? Pues hay otras muchas herramientas que pueden ser usadas como SaaS, veamos unos ejemplos.

Dicho de otra manera, además de quitarnos todo el problema de gestionar y mantener la infraestructura, las soluciones SaaS facilitan el teletrabajo, ya que podemos usar estas herramientas desde donde quiera que estemos.

Asegurando el acceso mediante las cuentas Google

“Un gran poder conlleva una gran responsabilidad”, esta famosa cita de la película Amelie nos recuerda que aunque podamos exponer nuestros sistemas a Internet tendremos que estar más atentos a la seguridad, sobre todo a las claves de los usuarios.

De poco nos sirve todo el cifrado del mundo si usamos la misma clave para varios sistemas y, encima, esta clave se la damos al primer email sospechoso que nos la pide…

Las cuentas de Google (y otras muchas) son usadas para acceder a gran cantidad de servicios de terceros usando lo que se llama la autenticación delegada. ¿Os imagináis un mundo en el que no pudiéramos utilizar nuestras cuentas favoritas para acceder a otros sitios?

Muchas veces es mejor tener solo una contraseña, y tenerla segura, que una contraseña en cada puerto (y bien apuntada en un post it).

Las cuentas de Google nos permiten asegurarlas contra accesos indeseados usando un doble (o múltiple) factor de autenticación MFA. De esta forma, no bastará con saber la clave para loguearse correctamente, con lo que nuestra seguridad aumentará.

Actualmente, incluso las cuentas públicas de Google nos ofrecen la opción de añadir el doble factor con estas opciones:

• Mediante clave enviada al móvil: este método es muy usado por los bancos para garantizar las transacciones. Consiste en el envío de una clave al número de teléfono para añadir a la contraseña y validar que somos nosotros. En este otro post contamos cómo hacerlo de manera efectiva en Android.
• Google prompts: un poco más sencillo ya que un aviso en nuestro móvil nos dirá qué dispositivo se quiere conectar a nuestra cuenta y con solo pulsar ok ya estaría todo.
• Security keys: la más segura de las tres opciones, dispositivos físicos que garantizan la identidad. Por poco más de 30 euros puedes tener una de estas llaves (hay móviles que ya tienen integradas llaves de seguridad).

Si bien en las cuentas personales activar esta seguridad depende del usuario, en las cuentas de empresa (ya sea si tenemos G Suite o Cloud Identity) es el administrador el que tiene el control, pudiendo definir la seguridad mínima para cada grupo dentro de su organización.

En este punto vamos a hacer una sutil transición al modo tutorial para ver paso a paso cómo activar esta opción como administrador G suite o Cloud Identity.

---Modo tutorial activado---

1. Ir admin.google.com y entrar con la cuenta de administrador (una buena práctica es que los administradores tengan cuentas para el día a día y de administración separadas):

2. Entrar en seguridad y dentro de la configuración básica activar el check e ir a opciones avanzadas de la verificación en dos pasos:

3. En este apartado podemos forzar a nuestros usuarios a activar esta necesaria medida de seguridad y definir cuándo se hará efectiva la nueva configuración y qué métodos consideramos seguros. Lo más seguro sería solo aceptar las llaves de seguridad. Importante a tener en cuenta es que abajo a la izquierda tenemos un filtro para los grupos, no tiene sentido aplicar las mismas restricciones a unos usuarios que a otros.

---Modo tutorial desactivado---

Añadiendo seguridad a nuestras aplicaciones cloud

Cada vez es más común desarrollar aplicaciones empresariales en la nube. Si bien el uso de estas aplicaciones es seguro, muchas veces nos interesa poner una capa extra de seguridad (en las aplicaciones gran parte de la seguridad recae sobre los desarrolladores que, como humanos que somos, fallamos a veces).

Gracias al IAP (Identity Aware Proxy) podemos poner de manera fácil un control por encima de nuestra aplicación que valide que los usuarios (o grupos de usuarios) tienen acceso a la aplicación antes de acceder realmente a ella.

Este sistema pide que te registres con tu cuenta de Google antes de alcanzar la aplicación, las llamadas no autorizadas son bloqueadas por la red antes de entrar.

Este servicio es mucho más fácil de configurar que una VPN y nos permite controlar de manera sencilla quién puede acceder a qué aplicaciones.

En el momento de escribir esto, podemos usar el IAP con estos productos:

• App Engine.
• Load Balancer (Para GKE y grupos de instancias).
• Máquinas virtuales (Tanto SSH como TCP).
• Sistemas on-premise.

Para demostrar lo fácil que es configurar un IAP, vamos a volver al modo tutorial para configurar el acceso a una aplicación App Engine.

---Modo tutorial activado---

1. En la consola de GCP, buscamos iap para encontrar el servicio.

2. En la pestaña de https veremos nuestra aplicación App Engine y los LB https que tengamos en el proyecto.

3. Como podemos ver, en esta ocasión tenemos tres servicios que componen nuestra aplicación (dos normales y uno admin). Activamos el interruptor de app engine para bloquear cualquier acceso no autorizado. Fijándonos bien, hay selectores a la izquierda que nos permiten seleccionar si queremos dar permisos a toda la aplicación o solo a unos servicios determinados. Para este ejemplo, lo primero que vamos a hacer es configurar que cualquier usuario pueda entrar en el servicio “default”, para ello seleccionamos la casilla del servicio y configuramos el permiso “secured web user” para “AllUsers”. Otra opción sería “AllAunthenticatedUsers” que obliga a tener una cuenta Google para acceder.

4. En el servicio “uncle-ben” lo que queremos es que solo puedan entrar los usuarios de nuestra organización. Esto lo indicamos añadiendo en el campo miembros el dominio de la organización que queramos que pueda entrar.

5. Por último, activamos a un grupo concreto el acceso al servicio admin. Recordemos que para dar permisos siempre es mejor usar grupos que cuentas nominales. Una vez configurado comprobamos que si intentamos acceder desde otra cuenta a un servicio securizado seremos bloqueados correctamente.

---Modo tutorial desactivado---

Y para terminar, una reflexión

En este post hemos visto cómo podemos depender menos de las VPNs para poder continuar trabajando desde cualquier sitio y de manera segura. Todo el mundo que me conoce sabe que soy “muy fan” de las aplicaciones cloud native.

Personalmente, soy partidario de ir eliminando las aplicaciones internas y he comprobado que se puede desarrollar, mantener y debuggear una aplicación perfectamente sin tener nunca que entrar en la máquina (¡¡Viva el serverless!!).

Aunque, supongo que no todo el mundo pensará como yo. Si eres uno de ellos, te invito a dejar un comentario con tus argumentos, todo ello desde la tranquilidad (que esto no es Twitter).