Ya se que el titulo parece prepotente, pero creo que es el que más se ajusta al contenido. Vamos a ello.
Ante todo toca montar una base para sentar un lenguaje común.
Así que tenemos cuatro tipos de actores
- El responsable de seguridad: Es quien se encarga de que tengamos una política de seguridad definida con sus riesgos, controles, e inventario de los diferentes datos a proteger. Sin alguien que se encargue de analizar los riesgos de los diferentes datos almacenados por la compañía, conseguir la aprobación por las altas instancias (sean lo que sean) de que riesgos se aceptan o asumen y cuales debemos mitigar y por último hacer el seguimiento adecuado de que todo está en orden y no han crecido setas, se han disparado costes o afectamos en demasía al negocio. Este/a señor/a no tiene ni porque tocar un Firewall o un Antivirus, pero debe saber que son y para que sirven.
- El propietario de los datos: Este es quien conoce el dato y su función y sensibilidad en la empresa y por tanto es quien tiene que decir qué nivel de servicio y garantías requiere cada tipo de datos y cuál podría ser la afectación al negocio en caso de perdida (ya sea picar de nuevo todo el archivo en papel o cerrar y a otra cosa). Si existe alguna legislación al respecto también debería estar al tanto. Aquí podríamos tener el departamento de Recursos Humanos con los datos relativos a las nóminas, formación o cualquier cosa que lleven.
- El custodio de los datos: Este/a buen/a señor/a es quien se encarga de aplicar la política de seguridad en los datos. Ya puede ir desde hacer backup de ellos, a llevar el sistema de gestión de identidades o que las transacciones económicas se hagan cifradas mediante el algoritmo X. Aquí tendríamos gente de IT
- El usuario de los datos: Pues las buenas personas/equipos que utilizan los datos para su trabajo diario. La persona del call-center que te llama para ofrecerte una super ADSL, el robot de la planta de montaje para saber que después del tornillo A453j toca el A235t o el acceso contra el API de Facebook para conocer tus amigos. Lo que vulgarmente llamaríamos cliente de los datos
Y luego que quiero decir con datos “seguros”, pues que dispongan de garantías para:
- La disponibilidad: Los datos deben estar disponibles cuando y donde se necesiten para el negocio
- La confidencialidad: Los datos sólo deben ser accesibles para quien tenga acceso autorizado
- La integridad: Debemos poder asegurar que los datos no se han modificado de forma no autorizada (una corrupción de los mismo, también lo vulnera)
- No-Repudio: Muy simple,pero delante de cualquier dato (modificado o no) debe existir un ente que se haga responsable de ello y no pueda “escurrir el bulto”
Por tanto al Responsable de Seguridad le toca definir unas políticas de seguridad para los datos según lo que le diga el Propietario de los datos controlando los riesgos de forma que tengan sentido para el negocio (nadie quiere perder nada,pero hay veces que debemos asumir una posibilidad de perdida del x% para mantener el negocio activo, el tema es proteger por menos coste del que implicaría recuperar los datos y su afectación al negocio).
Vamos a ver que consideraciones se hará el CISO en cada uno de los tipos de Cloud
SaaS
Aquí delegamos completamente el control al proveedor, así que si lleva una gestión de identidades conforme a la política (para depende de qué, un password sobra, para otras cosas tocará exigir soluciones en tokens o certificados), si el nivel de servicio ofrecido por el proveedor cuadra con las políticas y ya que seguimos siendo los responsables de esos datos (los clientes te los ceden a ti), mejor guardarnos las espaldas y poder exigir al proveedor que nos deje realizar auditorias y/o acceso a auditorias de terceras partes que sean de nuestra confianza.
Si tenemos todo esto controlado, solo nos queda el riesgo de que tengan un bug en el código y mis datos se “escapen”, aquí podemos pedir indemnidad, aceptar el riesgo tal cual o cualquier solución que nos satisfaga.
Ya que aquí estamos al máximo nivel de abstracción no podremos entrar en el cómo se hacen las cosas, pero si en el qué exigimos para nuestros datos.
PaaS
El proveedor en estos casos nos proporciona la infraestructura de servidores de aplicación y todos los middleware necesarios para que podamos desplegar nuestro código, así que aquí nos “comemos” los bugs del código y los debemos tratar como riesgos internos (o pedir indemnidad al proveedor de la aplicación…)
Una vez asumido que el código tiene un riesgo de errores que provoquen perdidas en los datos asumible, toca asegurar que la parte del proveedor no nos introduce riesgos no controlados.
Normalmente un PaaS se divide entre servidores de aplicación y almacenamiento, así que vayamos por partes.
- Servidores de aplicaciones: Debemos poder acceder a nuestra aplicación mediante la seguridad que requiramos (si no nos permiten SSL, está complicado…), debemos controlar que hacemos con los ficheros temporales (nunca dejar copias de datos sensibles en sitios donde no se esperan…), si son muy sensibles, guárdalos cifrados, y si permitimos que el proveedor pueda hacer volcados de memoria, controlar que se hará con aquello. Si no confiamos en el equipo del proveedor, mejor buscarnos otro, si confiamos, solo tenemos que tener en cuenta el riesgo que alguna manzana podrida pueda entrar, al igual que lo tendríamos que tener en cuenta en In-house
- Almacenamiento: Otra vez la confianza, si quieres reducir el riesgo hasta niveles aceptables, cifra todo lo que guardes (en fichero o DB), así en caso de que se pierda el HW no tiene porque perderse los datos. Por lo que respecta a la disponibilidad de los mismos, asegúrate que se realizan backups y saben restaurarlos (pide cada X tiempo un restore) en el fondo es una auditoria por tu parte
Y como es lógico, SLA que cumpla tus necesidades y que sea creíble, y para evitar problemas futuros, asegúrate poder auditar el entorno que afecta a tu servicio cuando quieras. El papel lo aguanta todo, así que si detectas algo que no cuadra te tocará incrementar el riesgo y buscar formas de mitigarlo que sean aceptables para el negocio
IaaS
Aquí el proveedor solo nos da servidores (físicos o virtuales) y almacenamiento tonto (ficheros o bloques), en un entorno más o menos compartido. Ya que puede ser que la máquina que tengamos al lado sea de otra compañía, mejor asegurar que todas las comunicaciones privilegiadas se realizan entre máquinas que se conocen, esto lo podemos hacer mediante herramientas del proveedor, pero si el riesgo es demasiado, podemos utilizar IPSec con una buena PKI y solo se puedan hablar máquinas con certificados adecuados, los nuestros.
Es muy típico que las máquinas se desplieguen sobre hosts y si pasa algo se redesplieguen sobre otro dejando sus datos en esos discos, aquí también te prometen que se usan herramientas para limpiar los datos, pero si no quieres que alguien venda por eBay los datos de tus clientes, ¡cifra!, los temporales, los ficheros, las base de datos, todo lo que sea sensible.
Que estén en el Cloud y replicados no implica que no se pueda perder el acceso momentáneamente (horas o días), así que si esto te puede afectar al negocio, busca soluciones dentro el mismo proveedor o con otros, si son otros pierdes dinero (volumen de compra, complejidad de gestión, implantación, etc.) pero reduces el riesgo de errores repetidos en todos los nodos, toca evaluar riesgos 🙂
Y por último el SLA, qué te ofrece este proveedor y cómo lo hago para llegar al nivel del servicio que espera el negocio (que vendrá del análisis de riesgos)
Conclusión
Tal y como lo veo, no existe ningún motivo para considerar el Cloud seguro o inseguro (almenos no más seguro o inseguro que un In-house o un Housing) y todo pasa por analizar claramente las necesidades del negocio, cruzarlo con la oferta de servicios del proveedor Cloud, hacer un análisis de riesgos y confrontarlo con la política (que se podría cambiar si es justificado) y proponer las soluciones para que el riesgo se haga aceptable. Nunca llegaremos a un riesgo 0 en nada, básicamente porque hay el factor humano en todo ello, así que si tu negocio se puede aprovechar del Cloud, no lo pares porque si, analiza y páralo con fundamento o implántalo con garantías
Hace unos años la seguridad en estos sistemas era bastante mala ya que muchas veces se llegó a filtrar información confidencial de algunas empresas pero con el paso del tiempo cada vez ha ido mejorando hasta ser algo realmente complicado de piratear