Enmilocalfunciona

Thoughts, stories and ideas.

Esquema Nacional de Seguridad: Amazon Web Services

Publicado por Sergio Lecuona el

CloudAmazon AWSSeguridadProgramacionENS

Este artículo es el primero de una serie en los que trataré de explicar la aplicación del Esquema Nacional de Seguridad sobre plataformas de diferentes proveedores Cloud.

Empezando aquí por la introducción al Esquema Nacional de Seguridad y por su aplicación específica sobre entornos desplegados sobre Amazon Web Services.

¿Qué es el Esquema Nacional de Seguridad?

Empecemos por el principio:

Cuando hablamos del Esquema Nacional de Seguridad (de aquí en adelante ENS), nos estamos refiriendo a un marco normativo que recoge un conjunto de medidas, recomendaciones y estándares que tienen como objetivo establecer la política de seguridad en el acceso a los medios digitales, garantizando la seguridad de la información en el ámbito de las TI y las comunicaciones.

Este conjunto de medidas son el resultado de un “trabajo coordinado por el Ministerio de la Presidencia, posteriormente por el Ministerio de Política Territorial y Administración Pública […] con el apoyo del Centro Criptológico Nacional (CCN) y la participación de todas las administraciones públicas, incluyendo las universidades públicas (CRUE)”.

El primer desarrollo del ENS se llevó a cabo allá en 2010, sufriendo modificaciones importantes en 2015. El año pasado, en 2022, sufrió su última actualización a través del Real Decreto 311/2022.

Los principios que gobiernan el ENS deben tomarse como Fundamentos, si bien en ningún lugar se aterrizan aplicaciones o medidas prácticas concretas a ejecutar para su cumplimiento. Los Principios Básicos que lo componen son puntos de referencia que deben tenerse en cuenta a la hora de tomar decisiones orientadas a garantizar la seguridad de la información.

Es curioso que, dentro de tanta seriedad, la documentación oficial sobre el ENS en la propia página web del Centro Criptológico Nacional, se permite un momento poético hablando así de estos principios básicos:

¿Qué empresas deben certificarse?

En general, el ENS es de aplicación obligatoria para las Administraciones Públicas y organismos vinculados; y en concreto, para cualquier sistema que dé servicio al ciudadano, entendiendo por estos sistemas entornos como Sedes Electrónicas, Registros Electrónicos o cualquier Sistema de la Información accesible electrónicamente por ciudadanos, que permitan el ejercicio de derechos o que recaben información y estados de procedimientos administrativos oficiales.

Además de esto, las infraestructuras críticas también deben cumplir con el ENS. En este caso lo lleva el Centro Nacional de Protección de Infraestructuras críticas (CNPIC).

¿Qué significa la coletilla “Nivel Alto”?

Dentro del ENS se contemplan diferentes niveles de criticidad de los sistemas, en función también de la criticidad de la información que se debe proteger, y por ello existen los niveles BAJO, MEDIO y ALTO.

El nivel Alto del ENS es el más exigente dentro del Esquema, y está diseñado para proteger aquellos sistemas que manejan información y datos que podrían tener un impacto significativo sobre la confidencialidad o integridad en caso de verse comprometidos. Por ello, en el ENS-Nivel Alto encontraremos las medidas más rigurosas en cuanto a su implementación.

A la hora de determinar si un sistema debe cumplir con el Nivel Bajo, Medio o Alto, tendríamos que analizar los sistemas desde cinco perspectivas diferentes: Disponibilidad, Integridad, Confidencialidad, Autenticidad y Trazabilidad. Si en cualquiera de estas dimensiones marcamos el Nivel Alto entonces el conjunto completo de nuestro sistema tendría que cumplir con los requerimientos del ENS-Nivel Alto.

Por ejemplo, a la hora de clasificar los sistemas tendríamos que hacernos una serie de preguntas:

En cuanto a CONFIDENCIALIDAD: ¿Si se conocieran los datos qué tipo de daño producirían?

  • Irreparable -> Nivel ALTO
  • Reparable -> Nivel MEDIO
  • Fácilmente reparable -> Nivel BAJO

En cuanto a DISPONIBLIDAD: En caso de parada del servicio por culpa de un incidente, ¿cuál sería el SLA a cumplir?

  • Menor a 4 horas -> Nivel ALTO
  • Entre 4 horas y un día -> Nivel MEDIO
  • Más de un día -> Nivel Bajo

Y así para el conjunto de las cinco dimensiones según las tablas publicadas por el CCN.

¿Existen guías prácticas sobre las medidas a tomar?

El Centro Criptológico Nacional tiene una serie de guías publicadas que permiten aterrizar a requisitos algo más concretos las medidas a tomar en diferentes tipologías de plataformas. Podéis encontrar todas estas guías en el siguiente enlace:
https://www.ccn-cert.cni.es/guias/guias-series-ccn-stic/800-guia-esquema-nacional-de-seguridad.html

Por ejemplo, referente a las medidas a adoptar sobre Amazon Web Services, hay siete guías diferentes publicadas:

  • CCN-STIC-887G: Guía de Configuración segura para Monitorización y gestión AWS
  • CCN-STIC-887F: Guía de respuesta a incidentes de seguridad en AWS
  • CCN-STIC-887D: Guía de configuración segura Multi-Cuenta AWS
  • CCN-STIC-887C: Guía de configuración segura de conectividad híbrida en AWS
  • CCN-STIC-887A: Guía de configuración segura AWS
  • CCN-STIC-887: Perfil de cumplimiento específico para AWS Servicio de Cloud Corporativo
  • CCN-STIC-887E: Guía de configuración segura Amazon WorkSpaces

¿Qué medidas concretas pueden adoptarse para certificar los entornos desplegados sobre Amazon Web Services?

En primer lugar, comenzaremos hablando del Modelo de Responsabilidad Compartida de AWS:

Se trata de un modelo que diferencia el ámbito de responsabilidad de los diferentes elementos de las infraestructuras, siendo esta responsabilidad compartida entre Amazon Web Services y sus clientes.

Por parte de AWS se opera, administra y controla los componentes del sistema operativo host y la capa de virtualización hasta la seguridad física de las instalaciones en las que funcionan los servicios

Por parte de los clientes se asume la responsabilidad y la administración del sistema operativo (incluidas las actualizaciones y los parches de seguridad), de cualquier otro software de aplicaciones asociado y de la configuración del firewall o de los diferentes grupos de seguridad que ofrece AWS, así como en general de la configuración, despliegue y uso que se realice de sus servicios gestionados.

Por tanto, los clientes deben reflexionar bien sobre qué servicios de AWS utilizan y la manera en que se ejecutan y configuran ya que ello determinará el cumplimiento de los estándares nacionales como el ENS.

Por la parte que recae bajo la responsabilidad de AWS se dispone de la certificación de categoría Alta del ENS ya que “han sido auditados y encontrados conforme con las exigencias del Real Decreto 3/2010, de 8 de enero, por el que se regula el Esquema Nacional de Seguridad en el ámbito de la Administración electrónica”. Esta acreditación se cumple en 25 Regiones de AWS, entre las que se encuentra, obviamente, la nueva Región de España.

Podéis descargaros el certificado desde la página web de Amazon Web Services:
https://d1.awsstatic.com/es_ES/certifications/ENSHighCertificate.pdf

También podemos obtener un listado de todos los servicios gestionados de AWS certificados bajo el ENS-Nivel Alto en esta URL: https://aws.amazon.com/es/compliance/services-in-scope/ENS-High/

Pero, tal y como indicamos, la certificación del proveedor Cloud no garantiza el cumplimiento de los entornos por el uso que se haga de sus servicios, sino que también recae sobre la responsabilidad del cliente la aplicación de medidas que garanticen el cumplimiento del Estándar en sus entornos.

En los puntos previos recogíamos las guías que os pueden ayudar a analizar el cumplimiento, aunque aquí resumimos algunos de los elementos más importantes para tener en cuenta (para tener un listado completo, recomendamos visitar las diferentes guías publicadas en el CCN):

  • Establecer una información precisa de las cuentas de AWS y un método de pago apropiado.
  • Establecer mecanismos robustos de control de acceso que garanticen la identificación de los usuarios y la asignación correcta de permisos, roles y políticas mediante proveedores de identidad centralizados.
  • Establecer una segregación de funciones y tareas para los diferentes usuarios del sistema.
  • Habilitar el doble factor de autenticación para todos los usuarios.
  • Realizar un registro de la actividad mediante servicios como AWS Cloudtrail.
  • Mantener un inventario actualizado de los activos del sistema.
  • Disponer de un mecanismo de parcheado y actualización de los sistemas.
  • Proteger las claves criptográficas durante todo su ciclo de vida a través de servicios como AWS KMS y auditar su uso.
  • Garantizar la continuidad del servicio y su disponibilidad mediante el despliegue en diferentes Availability Zones o Regiones y configurando donde se pueda servicios elásticos y grupos de autoescalado.
  • Monitorizar y realizar un diagnóstico del sistema, estableciendo métricas y alarmas a través de AWS Cloudwatch o herramientas apropiadas de terceros.
  • Implantar un sistema de Detección de Intrusiones, para lo que se recomienda el uso de servicios como AWS GuardDuty.
  • Establecer un perímetro seguro configurando AWS WAF, Shield, Firewall Manager, AWS Network Firewall, etc.
  • Aplicar cifrado en tránsito y en reposo (cifrar snapshots, volúmenes EBS, almacenamiento de instancias RDS, datos en S3, etc).
  • Automatizar la detección de acceso no controlado a datos, para lo que se pueden usar servicios como GuardDuty o Macie.
  • Segregar las redes manteniendo capas públicas y privadas que permitan minimizar la superficie expuesta, configurando adicionalmente reglas ACL que permitan securizar el tráfico de red.
  • Configurar correctamente los Security Groups para garantizar el control de acceso a los servicios.
  • Realizar una calificación de la información manejada.
  • Garantizar la existencia de copias de seguridad.

Como decimos, estas son solo algunas de las configuraciones y medidas necesarias para entender el alcance del ENS-Nivel Alto, pero no debéis tomarlo como un listado exhaustivo y completo que garantice el cumplimiento de este marco.

Conclusiones

Cuando hablamos del Esquema Nacional de Seguridad, en el fondo estamos hablando de un compromiso al que han llegado los diferentes organismos y administraciones para cumplir con las medidas de seguridad que permitan adaptarse a las situaciones y riesgos actuales, buscando un punto de equilibrio que tampoco llegue a asfixiar a las administraciones impidiendo la evolución de los proyectos.

Sin embargo, los tiempos cambian, las tecnologías y tipologías de ataques en materia de ciberseguridad evolucionan y, por ello, el ENS también lo hace. De ahí que las diferentes guías y el propio esquema sufran actualizaciones constantes y se vayan robusteciendo para asegurar que la seguridad y la privacidad sean una práctica contínua presente en todo el ciclo de vida de los proyectos.

En cualquier caso, el ENS no es el único marco a tener en cuenta en nuestros proyectos. Por ejemplo, algunas organizaciones y empresas deciden guiarse por el Cybersecurity Framework del NIST (National Institute of Standards and Security), que presenta el estándar más actualizado en cuanto a arquitecturas de seguridad.

Hemos de ser muy conscientes de los distintos niveles de cumplimientos a los que debemos atenernos en función del tipo de infraestructura, localización geográfica o estándares nacionales que nos apliquen. Hablo, por ejemplo, de revisar el cumplimiento de la Regulación General de Protección de Datos (la famosa GDPR), estándares aplicables a instituciones sanitarias de Estados Unidos como HIPAA, el PCI DSS si trabajamos con datos de métodos de pago, etcéctera, etcétera. Siempre debemos analizar cuáles nos aplican involucrando a los departamentos legales para tener un enfoque completo.

Y no puedo cerrar el artículo sin hacer mención a los propios términos y condiciones de uso de AWS, con sus condiciones particulares de seguridad que tampoco debemos perder de vista y conocer. ¿O es que acaso conocíais ya su famosa cláusula 42.10 caída en el olvido tras la última revisión de los términos?:

"El uso de los Materiales de Lumberyard debe cumplir la política de uso aceptable de AWS […]. Sin embargo, esta restricción no se aplicará en caso de que ocurra (con certificación de los Centros para el Control de Enfermedades de los EEUU o el organismo que lo suceda) de una infección viral generalizada transmitida a través de picaduras o contacto con fluidos corporales que haga que los cadáveres humanos revivan y traten de consumir carne humana viva, sangre, cerebro o tejido nervioso y es probable que conlleve la caída de la civilización organizada."

Fuentes: