09.03.2012. Hace unos meses se decidió en la empresa un cambio de CRM. La necesidad de uno más potente y versátil era ya inaplazable debido al fuerte crecimiento que habíamos sufrido. Tras el estudio de varias alternativas, elegimos uno que se adaptaba completamente a nuestras necesidades y -como pueden imaginar por el título del artículo-, este CRM estaba en la nube.
Como responsable de Seguridad de la empresa, sentí un ligero vértigo en el estómago al analizar el nuevo escenario. Somos una compañía especializada en Seguridad de la Información y tenemos que dar ejemplo. Por ello podemos presumir de tener un entorno de seguridad muy completo: firewall de última generación, IPS con capacidad de mitigar ataques DDoS avanzados, sistema de autenticación fuerte con tokens, accesos VPN SSL granular, un potente sistema de control de acceso a la red (NAC, por sus siglas en inglés) que también controla USB y aplicaciones que corren en los equipos, pasarelas de filtrado web y de correo con motores para evitar la fuga de información… Pero ahora: ¿de qué nos servía toda esa tecnología para proteger la información de la empresa si gran parte de sus datos iban a estar fuera? ¿Cómo puedo garantizar ahora su confidencialidad, integridad y disponibilidad?
Por las mismas fechas pude leer un informe de Gartner en el que se vaticinaba que en los próximos cuatro años la adopción de cloud computing iba a pasar de un tres a un 43 por ciento, así que estaba claro que era momento de ponerse manos a la obra y estudiar a fondo la seguridad que ofrecían las empresas de Software como Servicio (SaaS) y cómo se podían integrar con lo que teníamos.
El primer punto al que me dediqué y sobre el que vamos a tratar a fondo es la autenticación en la nube, y la primera pregunta llegó en seguida.
¿Qué tipos puedo usar?
Prácticamente cualquier sistema de autenticación que se nos ocurra con aquellos proveedores que te permitan usar Security Assertion Markup Language (SAML), como por ejemplo Google Apps. SAML es un estándar para el intercambio de autenticación y autorización entre diferentes dominios de seguridad. El proveedor SaaS que integre SAML utilizará nuestros IdP (Identity Provider) para autenticar al usuario, permitiéndonos así la integración de cualquier servicio web con nuestro propio sistema de autenticación. El proceso se puede ver en el siguiente esquema proporcionado por Google (Figura 1). Sabiendo que podía integrarlo con prácticamente cualquier sistema de autenticación, la segunda pregunta que surgió fue:
¿Cuál es más apropiado?
Había que fijar unos requisitos que permitiesen mantener un buen nivel de seguridad, pero también basados en las nuevas posibilidades que ofrecen los servicios en la nube.
Ha de usar múltiples factores (mínimo dos). Recordemos la regla de los tres factores. Para tener la máxima garantía de que una persona es quien dice ser, ha de presentar algo que sabe (por ejemplo, una contraseña), algo que tiene (por ejemplo, una llave o una tarjeta de acceso) y algo que es parte de sí (una huella digital).
‘Cloud’ facilita la movilidad, pero no tiene sentido gastar en autenticación lo que se ahorra con SaaS
Ha de facilitar la movilidad. Una de las ventajas del cloud computing es que podemos acceder desde cualquier dispositivo que se halle en cualquier lugar. Otra característica relevante es que ha de ser económico, pues el ahorro de costes es también uno de los puntos fuertes de los servicios en la nube, por lo que no tiene sentido gastarnos en autenticación lo que nos ahorramos en un SaaS. Una vez fijados, vamos a ver a continuación qué tipos de autenticación cumplen con estos requisitos.
Basado en contraseñas
Se trata del nivel más básico e inseguro de autenticación que podemos tener. Un solo factor, que no cambia con demasiada frecuencia y que además puede ser interceptado. Además, si queremos conseguir que las contraseñas sean mínimamente fuertes tenemos que obligar al usuario a componer sus contraseñas de forma cada vez más compleja y a que las modifiquen frecuentemente. El resultado es que las cuentas sebloquean, las contraseñas expiran y todo esto genera mucho trabajo y pérdida de tiempo al personal de informática.
Certificados digitales
Los certificados digitales podrían ser una buena opción. Incluyen dos factores (poseer el certificado y saber el PIN de acceso a él), incluso tres, si usamos un lector de huellas. Además, están cada vez más extendidos y no es caro montar una Clave de Infraestructura Pública (PKI, en siglas inglesas), por lo que cumplen ya dos requisitos. Pero, ¿facilitan la movilidad? El problema es que un certificado y su clave privada tienen que estar en algún sitio almacenados. Si está en el repositorio de claves del sistema operativo, dependemos del ordenador en el que esté. Si se encuentra en una tarjeta inteligente, dependemos de que el ordenador donde vayamos a usarla tenga lector para tarjetas. Si lo almacenamos en un USB tendríamos menos problemas, pero seguiríamos sin poder trabajar desde una tablet o un teléfono.
‘Tokens hardware’
Los tokens en hardware son esos dispositivos con forma de llavero o de tarjeta que nos muestran un número diferente cada cierto tiempo. Para autenticarte has de introducir un PIN previamente memorizado. Tenemos dos factores de autenticación y además no tenemos que conectar el token a ningún dispositivo, por lo que es un sistema que facilita mucho la movilidad. Sería perfecto si no fuera por los costes. Y, sobre todo, no debido a los costes del dispositivo en sí, sino a los que ocasionan las continuas pérdidas y olvidos de estos dispositivos por parte de los usuarios. Si se utilizan tokens hardware, se ha de tener siempre algunos en stock para responder rápidamente a las pérdidas y, además, preparar al personal de help desk para que se haga cargo de las incidencias mencionadas.
‘Tokens software’
El sistema es prácticamente igual que el mencionado anteriormente, salvo que el OTP (On-Time Password) se genera en una aplicación que se ejecuta en un smartphone. Cumplimos con dos factores también, y es bastante común que los usuarios tengan móvil, de modo que no supone un coste adicional. Tampoco afecta a la movilidad, por lo que son sistemas bastante interesantes. Un pero podría ser que también se pueden olvidar o que no todos los usuarios tengan teléfono inteligente.
Códigos SMS
Este sistema es el preferido por los bancos. Cuando queremos acceder, indicamos usuario y contraseña y se nos envía un SMS con un codigo que hemos de introducir para continuar. No hay costes de dispositivos, no es necesario un móvil inteligente y los SMS son baratos. Podrían considerarse dos factores, ya que es un código que se envía a un teléfono (algo propio) y previamente se ha introducido en la web la contraseña. Estaríamos ante uno de los mejores sistemas si no hay un volumen alto de SMS, si no fuera porque ya existen troyanos para smartphones que pueden reenviar a Internet estos códigos y conseguir así hacer incluso transferencias de nuestra cuenta.
Posiciones de un OTP
Quizá este es el sistema más innovador de todos los que he encontrado. Consiste en lo siguiente: un usuario memoriza un PIN de cuatro digitos que corresponden con las posiciones de un OTC (One Time Code), que siempre cambia. Cada vez que un usuario intenta autenticarse, o bien se le envía un SMS con 10 dígitos diferentes o bien se le muestra en la página web de autenticación una imagen con 10 dígitos ofuscados para evitar el reconocimiento de caracteres. En todos los casos, el usuario introduce en el PC los dígitos correspondientes a las posiciones que sabe de su PIN. El sistema es multifactor, facilita la movilidad y además es económico porque si los usuarios no usan móviles, siempre podemos usar la imagen cambiante de 10 dígitos que se muestran en la web para autenticarnos al introducir el usuario. Además, el usuario nunca introduce el PIN en el teclado por lo que evitamos cualquier keylogger.