ST-EAL1 Savvy
Versión del documento: 1.5
Fecha: 12/07/2018
Savvy M2C Communications
rsión del documento: 1.5
Communications
2
Savvy Data Systems S.L.
C.I.F. B-75092114
C/ Portuetxe 45-A 4-4
20018 San Sebastián-Donostia
Telephone: +34 943 317 074
Savvy Data Systems S.L.
Donostia (Gipuzkoa)
+34 943 317 074
3
CONTENIDO
Contenido................................
1 Introducción................................
1.1 Referencia a la declaración de seguridad
1.2 Referencia del TOE
1.3 Resumen del producto
1.4 Resumen del TOE
1.4.1 Tipo de TOE
1.4.2 Uso del TOE
1.4.3 Características de seguridad del TOE
1.4.4 Software y hardware requerido por el TOE para su operación
1.5 Descripción del TOE
1.5.1 Ámbito físico del TOE: Componentes
1.5.2 Ámbito lógico del TOE
2 Declaraciones de conformidad
2.1 Conformidad respecto a la norma CC
2.2 Conformidad respecto a Perfiles de Protección
3 Objetivos de seguridad
3.1 Objetivos de seguridad para el entorno operacional
4 Definición de componentes extendidos
5 Requisitos de seguridad del TOE
5.1 Requisitos funcionales de seguridad
5.2 Requisitos de garantía de seguridad
5.3 Justificación de los Requisitos de garantía de seguridad
5.4 Dependencias de los Requisitos funcionales de seguridad
6 Especificación Resumida del TOE
................................................................................................
................................................................................................
Referencia a la declaración de seguridad................................................................
ferencia del TOE................................................................................................
Resumen del producto................................................................
Resumen del TOE ................................................................................................
Tipo de TOE ................................................................................................
Uso del TOE ................................................................................................
Características de seguridad del TOE................................................................
Software y hardware requerido por el TOE para su operación
Descripción del TOE................................................................................................
Ámbito físico del TOE: Componentes................................................................
Ámbito lógico del TOE................................................................
Declaraciones de conformidad................................................................
Conformidad respecto a la norma CC ................................................................
Conformidad respecto a Perfiles de Protección................................
Objetivos de seguridad................................................................
Objetivos de seguridad para el entorno operacional................................
Definición de componentes extendidos ................................................................
Requisitos de seguridad del TOE ................................................................
Requisitos funcionales de seguridad................................................................
Requisitos de garantía de seguridad................................................................
icación de los Requisitos de garantía de seguridad................................
Dependencias de los Requisitos funcionales de seguridad................................
Especificación Resumida del TOE ................................................................
.................................................................. 3
...................................................... 5
................................... 5
..................................... 5
............................................................... 5
....................................... 5
........................................ 5
........................................ 6
................................. 6
Software y hardware requerido por el TOE para su operación ......................... 6
.................................... 8
................................. 8
........................................................ 8
......................................................... 11
...................................... 11
....................................................... 11
.................................................................... 12
............................................... 12
........................................... 13
...................................................... 14
........................................ 14
........................................ 16
......................................... 16
...................................... 16
..................................................... 18
4
5
1 INTRODUCCIÓN
1.1 Referencia a la declaración de seguridad
Título: ST-EAL1 Savvy M2C Communications
Versión: 1.5
Autor: Savvy Data Systems S
Fecha de publicación: 1
1.2 Referencia del TOE
Nombre: Savvy M2C Communications
Versión: 1.3
Desarrollador: Savvy Data Systems
1.3 Resumen del producto
La solución M2C que ofrece Savvy Data Systems está pensada para ser desplegada en
plantas de fabricación. El dispositivo captador
máquinas) a través de la red de planta, realiza un mecanismo de autodespliegue por el cual
capaz de establecer una conexión automática a través de la red de Internet contra el Cloud de
Savvy Data Systems, comenzará a captar datos de diversos orígenes y serán enviados al Cloud a
través de un canal cifrado por TLS
realizar la configuración del captador, la gestión de la plataforma y la consulta de los datos
recogidos por el captador en tiempo real.
1.4 Resumen del TOE
El TOE es el modelo de comunicación captador
conectan de forma segura los
cómo se gestiona esa conexión desde estos servidores
segura a través de la interfaz web para visualizar da
plataforma con el servidor web
En el caso del captador se trata de una aplicación Java corriendo en una máquina Ubuntu.
Los servidores Data Frontend también se trata
máquina Ubuntu, que se encuentran en un Data Center
interfaz web corre en una máquina Ubuntu sobre Apache ta
1.4.1 Tipo de TOE
Aunque el tipo de producto que ofrece Savvy Data Systems se
como software, el TOE únicamente consiste en la gestión de las comunicaciones entre captador
Cloud y el acceso a la interfaz web (comunicación con el usuario). Por lo tanto, se define como
tipo: “Canales de comunicaciones”.
declaración de seguridad
Savvy M2C Communications
Savvy Data Systems S.L.
12/07/2018
Referencia del TOE
Savvy M2C Communications
Savvy Data SystemsS.L.
Resumen del producto
M2C que ofrece Savvy Data Systems está pensada para ser desplegada en
plantas de fabricación. El dispositivo captador (o Savvy Smart Box) se conecta a la máquina (o
máquinas) a través de la red de planta, realiza un mecanismo de autodespliegue por el cual
capaz de establecer una conexión automática a través de la red de Internet contra el Cloud de
Savvy Data Systems, comenzará a captar datos de diversos orígenes y serán enviados al Cloud a
través de un canal cifrado por TLS v1.2. Desde la interfaz web, los usuarios autorizados pueden
realizar la configuración del captador, la gestión de la plataforma y la consulta de los datos
recogidos por el captador en tiempo real.
odelo de comunicación captador-Cloud / Cloud-usuario, es d
los dispositivos captadores con el Cloud (servidores Data
gestiona esa conexión desde estos servidores y cómo se conecta un cliente
a través de la interfaz web para visualizar datos, configurar captadores y/o gestionar la
con el servidor web.
En el caso del captador se trata de una aplicación Java corriendo en una máquina Ubuntu.
Los servidores Data Frontend también se tratan de una aplicación en Java corriendo sobre un
máquina Ubuntu, que se encuentran en un Data Center contratado a una compañía externa
interfaz web corre en una máquina Ubuntu sobre Apache también en el Data Center contratado.
Aunque el tipo de producto que ofrece Savvy Data Systems se trata tanto de hardware
como software, el TOE únicamente consiste en la gestión de las comunicaciones entre captador
Cloud y el acceso a la interfaz web (comunicación con el usuario). Por lo tanto, se define como
tipo: “Canales de comunicaciones”.
M2C que ofrece Savvy Data Systems está pensada para ser desplegada en
se conecta a la máquina (o
máquinas) a través de la red de planta, realiza un mecanismo de autodespliegue por el cual es
capaz de establecer una conexión automática a través de la red de Internet contra el Cloud de
Savvy Data Systems, comenzará a captar datos de diversos orígenes y serán enviados al Cloud a
os usuarios autorizados pueden
realizar la configuración del captador, la gestión de la plataforma y la consulta de los datos
usuario, es decir cómo se
(servidores DataFrontend, DF),
y cómo se conecta un cliente de manera
tos, configurar captadores y/o gestionar la
En el caso del captador se trata de una aplicación Java corriendo en una máquina Ubuntu.
corriendo sobre una
contratado a una compañía externa. La
mbién en el Data Center contratado.
trata tanto de hardware
como software, el TOE únicamente consiste en la gestión de las comunicaciones entre captador-
Cloud y el acceso a la interfaz web (comunicación con el usuario). Por lo tanto, se define como
6
1.4.2 Uso del TOE
Todos los canales de comunicación mencionados anteriormente utilizan TLS
captadores solo se pueden conectar con
certificado y además deben acreditarse a la hora de establecer la conexión, sin posi
(conlleva bloqueo inmediato).
El uso del TOE por parte del usuario, dada su naturaleza, solo puede darse en la interfaz
web. Tiene un mecanismo de autenticación en dos pasos en la que se verifican los dispositivos
desde los que se accede y bloqueos en función del número de intentos fallidos en el login.
1.4.3 Características de seguridad del TOE
Las características de seguridad que implementa el TOE son las siguientes:
 Conexión de los
residente en los captadores abre una serie de conexiones de forma segura contra el
servicio Cloud usando TLS
conecta (certificados pinneados) y autenticándose con su código y clave de
dispositivo, pudiéndo
Savvy Data Systems
 Gestión de la c
la identificación y autorización de las conexiones de los captadores. Realizan la
recepción de datos a través de TLS
rotación y revocación de certi
necesidad de validación de la cadena de certificación y de entidades externas, para
tener una mayor seguridad y precisión.
 Gestión del login en la interfaz web:
con un certificado válido emitido por COMODO RSA DomainValidationSecure Server
CA. Para acceder a cualquier apartado de la interfaz web, es necesario identificarse
y autenticarse. Además, se cuenta con un proceso de autenticación en dos pasos
para verificar el di
desafío para prevenir ataques replay
1.4.4 Software y hardware requerido por el TOE para su operación
Captador: PC Industrial con Intel(R) Celeron(R) CPU N2930 @
Puede correr sobre Ubuntu Server 14.04 LTS
Java 8.
Servidor DF: Servidor virtualizado en el D
E5-2683 v3 @ 2.00GHz, 2 cores y 4 GB de RAM.
Ubuntu Server 16.04 LTS y puede utilizar
Servidor Web: Servidor virtualizado en el D
E5-2683 v3 @ 2.00GHz, 4 cores y 8 GB de RAM.
Ubuntu Server 16.04 LTS, puede utilizar
mantiene actualizado a nuevas versiones por actualizaciones de segur
Todos los canales de comunicación mencionados anteriormente utilizan TLS
captadores solo se pueden conectar con el Cloud debido a que comprueban la firma del
certificado y además deben acreditarse a la hora de establecer la conexión, sin posi
(conlleva bloqueo inmediato).
El uso del TOE por parte del usuario, dada su naturaleza, solo puede darse en la interfaz
web. Tiene un mecanismo de autenticación en dos pasos en la que se verifican los dispositivos
y bloqueos en función del número de intentos fallidos en el login.
Características de seguridad del TOE
Las características de seguridad que implementa el TOE son las siguientes:
Conexión de los dispositivos captadores con el Cloud: el software en Java
idente en los captadores abre una serie de conexiones de forma segura contra el
servicio Cloud usando TLS v1.2, comprobando la identidad del servidor al que se
conecta (certificados pinneados) y autenticándose con su código y clave de
dispositivo, pudiéndose autenticar únicamente los dispositivos autorizados por
Savvy Data Systems (en caso de fallo, supone bloqueo automático)
Gestión de la conexión con los captadores desde el Cloud: los servidores gestionan
la identificación y autorización de las conexiones de los captadores. Realizan la
recepción de datos a través de TLS v1.2. Se ha desarrollado un mecanismo de
rotación y revocación de certificados sin necesidad de parada y evitando la
necesidad de validación de la cadena de certificación y de entidades externas, para
tener una mayor seguridad y precisión.
Gestión del login en la interfaz web: siempre se redirecciona a HTTPS, contando
certificado válido emitido por COMODO RSA DomainValidationSecure Server
CA. Para acceder a cualquier apartado de la interfaz web, es necesario identificarse
y autenticarse. Además, se cuenta con un proceso de autenticación en dos pasos
para verificar el dispositivo desde el que se conecta. Se tiene también un sistema de
desafío para prevenir ataques replay y un sistema de bloqueo por IP
Software y hardware requerido por el TOE para su operación
Captador: PC Industrial con Intel(R) Celeron(R) CPU N2930 @ 1.83GHz y 4 GB de RAM.
sobre Ubuntu Server 14.04 LTS o Ubuntu Server 16.04 LTS y puede utilizar
F: Servidor virtualizado en el Data Center contratado con Intel(R) Xeon(R) CPU
2683 v3 @ 2.00GHz, 2 cores y 4 GB de RAM. Puede correr sobre Ubuntu Server 14.04 LTS
puede utilizar Java 7 o Java 8.
b: Servidor virtualizado en el Data Center contratado con Intel(R) Xeon
2683 v3 @ 2.00GHz, 4 cores y 8 GB de RAM. Puede correr sobre Ubuntu Server 14.04 LTS
puede utilizar Java 7 o Java 8, PHP 5.5.9 o PHP 7.2 y
mantiene actualizado a nuevas versiones por actualizaciones de seguridad).
Todos los canales de comunicación mencionados anteriormente utilizan TLS v1.2. Los
loud debido a que comprueban la firma del
certificado y además deben acreditarse a la hora de establecer la conexión, sin posibilidad de fallo
El uso del TOE por parte del usuario, dada su naturaleza, solo puede darse en la interfaz
web. Tiene un mecanismo de autenticación en dos pasos en la que se verifican los dispositivos
y bloqueos en función del número de intentos fallidos en el login.
Las características de seguridad que implementa el TOE son las siguientes:
el software en Java
idente en los captadores abre una serie de conexiones de forma segura contra el
, comprobando la identidad del servidor al que se
conecta (certificados pinneados) y autenticándose con su código y clave de
se autenticar únicamente los dispositivos autorizados por
(en caso de fallo, supone bloqueo automático).
los servidores gestionan
la identificación y autorización de las conexiones de los captadores. Realizan la
Se ha desarrollado un mecanismo de
ficados sin necesidad de parada y evitando la
necesidad de validación de la cadena de certificación y de entidades externas, para
siempre se redirecciona a HTTPS, contando
certificado válido emitido por COMODO RSA DomainValidationSecure Server
CA. Para acceder a cualquier apartado de la interfaz web, es necesario identificarse
y autenticarse. Además, se cuenta con un proceso de autenticación en dos pasos
Se tiene también un sistema de
y un sistema de bloqueo por IP.
1.83GHz y 4 GB de RAM.
puede utilizar Java 7 o
con Intel(R) Xeon(R) CPU
sobre Ubuntu Server 14.04 LTS o
con Intel(R) Xeon(R) CPU
sobre Ubuntu Server 14.04 LTS o
o PHP 7.2 y Apache (se
7
Plataforma de pruebas utilizada en la evaluación de seguridad.
Para la evaluación se ha utilizado la siguiente plataforma de pruebas
Captador: PC Industrial con Intel(R) Celeron(R) CPU N2930
Ubuntu Server 14.04 LTS y Java 7
Servidor DF: Servidor virtualizado en el D
E5-2683 v3 @ 2.00GHz, 2 cores
Servidor Web: Servidor virtualizado en el D
E5-2683 v3 @ 2.00GHz, 4 cores y 8 GB de RAM, con
Apache 2.4.7.
El TOE consiste en la parte del firmware (marcada en verde) encargada de gestionar las
comunicaciones. Ambas figuras representan el mismo concepto, solo que cada una representa un
punto de vista diferente.
Plataforma de pruebas utilizada en la evaluación de seguridad.
Para la evaluación se ha utilizado la siguiente plataforma de pruebas, todo bajo TLS v1.2
PC Industrial con Intel(R) Celeron(R) CPU N2930 @ 1.83GHz y 4 GB de RAM, con
Java 7.
F: Servidor virtualizado en el Data Center contratado con Intel(R) Xeon(R) CPU
2683 v3 @ 2.00GHz, 2 cores y 4 GB de RAM, con Ubuntu Server 14.04 LTS y
b: Servidor virtualizado en el Data Center contratado con Intel(R) Xeon(R) CPU
2.00GHz, 4 cores y 8 GB de RAM, con Ubuntu Server 14.04 LTS,
El TOE consiste en la parte del firmware (marcada en verde) encargada de gestionar las
figuras representan el mismo concepto, solo que cada una representa un
, todo bajo TLS v1.2:
@ 1.83GHz y 4 GB de RAM, con
con Intel(R) Xeon(R) CPU
y Java 7.
con Intel(R) Xeon(R) CPU
Java 7, PHP 5.5.9 y
El TOE consiste en la parte del firmware (marcada en verde) encargada de gestionar las
figuras representan el mismo concepto, solo que cada una representa un
8
1.5 Descripción del TOE
1.5.1 Ámbito físico del TOE: Componentes
La parte del TOE correspondiente al
encuentra dentro de un archivo en Java, un .jar, llamado “clienteIC.jar”. En cuanto a la parte del
TOE correspondiente al Cloud, no se entrega nada al usuario.
de archivos compilados en Java
envía un email en el que se le informa de que se le ha creado una cuenta de usuario con su cuenta
de correo y que debe establecer una contraseña a través del enlace incluido también en el
mensaje. La parte web se trata de un conjunto de archivos PHP.
interacción del usuario, únicamente para su instalación y configuración de red, por lo que se
ofrece una guía que detalla estos pasos
de captador – XXXXXXXX - Versión 1.
acceso web – Versión 1.3) que describe las interfaces del TOE accesibles por el usuario
diferentes roles vía email en form
personalizadas.
1.5.2 Ámbito lógico del TOE
Desde el punto de vista del ámbito lógico del TOE, se cuentan con las siguientes
características de seguridad:
 Conexión de los dispositivos captadores con el Cloud:
serie de conexiones seguras contra el servicio Cloud denominadas canales.
Normalmente la salida se consigue a través del puerto 443, aunque se puede
trabajar con un gran número de puertos
abiertos desde Java utilizando TLS
digital del certificado del servidor, el firmware del cliente cuenta con un keystore
con 5 certificados
conexión con uno de los 5 certificados del servidor
el siguiente punto. Una vez establecido el canal seguro de comunicación, el
dispositivo debe autenticarse utilizando un código y una clave de dispositivo. Si se
autentica incorrectamente, se bloquea
 Gestión de la conexión de los captadores desde el Cloud:
servidores, en los que se ejecuta el código en Java de recepción de datos. Todos
tienen el mismo código y la carga es gestionada
distribuido, que los servidores administran de forma colaborativa.
puerto de escucha, al que se conectan los dispositivos de captura y validan la
conexión del dispositivo. La escucha se hace mediante un soc
se crea mediante un contexto TLS
momento esté vigente.
mecanismo que permite la rotación y la revocación sin necesidad de parada y
evitando la necesidad de validación de la cadena de certificación y de entidades
externas. Los certificados son creados en una máquina virtual controlada en las
instalaciones de Savvy Data Systems. Se crean 5 certificados autofirmados
el objetivo de los mismos no es permitir a los captadores la validación de la cadena
Descripción del TOE
Ámbito físico del TOE: Componentes
La parte del TOE correspondiente al captador se entrega instalado junto con el captador. Se
un archivo en Java, un .jar, llamado “clienteIC.jar”. En cuanto a la parte del
TOE correspondiente al Cloud, no se entrega nada al usuario. Se encuentra dentro de un
en Java. La parte web del TOE es accesible por Internet y al usuario se le
envía un email en el que se le informa de que se le ha creado una cuenta de usuario con su cuenta
de correo y que debe establecer una contraseña a través del enlace incluido también en el
La parte web se trata de un conjunto de archivos PHP. Los captadores no requieren de la
únicamente para su instalación y configuración de red, por lo que se
que detalla estos pasos, en formato papel entregada junto con el captador
Versión 1.3). Para la interfaz web se entrega una pequeña
que describe las interfaces del TOE accesibles por el usuario
en formato pdf y además se ofrecen formaciones presenciales
Ámbito lógico del TOE
Desde el punto de vista del ámbito lógico del TOE, se cuentan con las siguientes
Conexión de los dispositivos captadores con el Cloud: el software en Java abre una
serie de conexiones seguras contra el servicio Cloud denominadas canales.
Normalmente la salida se consigue a través del puerto 443, aunque se puede
trabajar con un gran número de puertos o vía proxy. Estos canales son sockets
ertos desde Java utilizando TLS v1.2. El captador entonces verifica la huella
digital del certificado del servidor, el firmware del cliente cuenta con un keystore
con 5 certificados que se utilizan para probar la identidad del servidor
conexión con uno de los 5 certificados del servidor. Se explica con mayor detalle en
el siguiente punto. Una vez establecido el canal seguro de comunicación, el
dispositivo debe autenticarse utilizando un código y una clave de dispositivo. Si se
incorrectamente, se bloquea inmediatamente.
Gestión de la conexión de los captadores desde el Cloud: se trata de una granja de
servidores, en los que se ejecuta el código en Java de recepción de datos. Todos
tienen el mismo código y la carga es gestionada mediante un algoritmo de balanceo
distribuido, que los servidores administran de forma colaborativa.
puerto de escucha, al que se conectan los dispositivos de captura y validan la
conexión del dispositivo. La escucha se hace mediante un socket tipo servidor que
e crea mediante un contexto TLS v1.2, cargando el certificado que en ese
momento esté vigente. Para rotar y revocar certificados, se ha desarrollado un
mecanismo que permite la rotación y la revocación sin necesidad de parada y
evitando la necesidad de validación de la cadena de certificación y de entidades
externas. Los certificados son creados en una máquina virtual controlada en las
instalaciones de Savvy Data Systems. Se crean 5 certificados autofirmados
e los mismos no es permitir a los captadores la validación de la cadena
captador se entrega instalado junto con el captador. Se
un archivo en Java, un .jar, llamado “clienteIC.jar”. En cuanto a la parte del
Se encuentra dentro de un conjunto
La parte web del TOE es accesible por Internet y al usuario se le
envía un email en el que se le informa de que se le ha creado una cuenta de usuario con su cuenta
de correo y que debe establecer una contraseña a través del enlace incluido también en el
Los captadores no requieren de la
únicamente para su instalación y configuración de red, por lo que se
a junto con el captador (Ficha
pequeña guía (Guía de
que describe las interfaces del TOE accesibles por el usuario y los
se ofrecen formaciones presenciales
Desde el punto de vista del ámbito lógico del TOE, se cuentan con las siguientes
el software en Java abre una
serie de conexiones seguras contra el servicio Cloud denominadas canales.
Normalmente la salida se consigue a través del puerto 443, aunque se puede
. Estos canales son sockets TCP
. El captador entonces verifica la huella
digital del certificado del servidor, el firmware del cliente cuenta con un keystore
del servidor y aceptar la
Se explica con mayor detalle en
el siguiente punto. Una vez establecido el canal seguro de comunicación, el
dispositivo debe autenticarse utilizando un código y una clave de dispositivo. Si se
se trata de una granja de
servidores, en los que se ejecuta el código en Java de recepción de datos. Todos
mediante un algoritmo de balanceo
distribuido, que los servidores administran de forma colaborativa. Cada DF abre un
puerto de escucha, al que se conectan los dispositivos de captura y validan la
ket tipo servidor que
, cargando el certificado que en ese
ara rotar y revocar certificados, se ha desarrollado un
mecanismo que permite la rotación y la revocación sin necesidad de parada y
evitando la necesidad de validación de la cadena de certificación y de entidades
externas. Los certificados son creados en una máquina virtual controlada en las
instalaciones de Savvy Data Systems. Se crean 5 certificados autofirmados, ya que
e los mismos no es permitir a los captadores la validación de la cadena
9
de certificación hasta una entidad firmante superior. En su lugar, los captadores
validan la clave pública del certificado contra el almacén local de claves públicas
válidas que tienen
diferente. Se crean dos almacenes de claves diferentes. El primero irá instalado en
los captadores, y contiene las 5 claves públicas. El segundo irá instalado en los DFs,
y contiene únicament
momento. También se crean 12 sobres sellados “ICE” (In Case of Emergency),
siendo tres copias impresas de cada una de las 4 claves privadas de
rotación/revocación. Cada uno de los sobres ICE ind
mecanismos criptográficos utilizados. Las tres copias (cuatro sobres por copia) son
entregadas a tres personas de alto cargo en la empresa (Director Gerente,
Responsable de Área de Negocio, y Director Técnico), quienes las guar
seguro y secreto. Los sobres están debidamente codificados para que nadie ajeno a
este procedimiento conozca su razón de ser ni su forma de aplicación. Por tanto, el
almacén de claves de los captadores tiene cargadas las claves públicas firmad
5 certificados diferentes, siendo uno de ellos es el que está vigente (en uso por los
servidores DF), y los otros 4 son usados para los casos en los que sea necesario
ejecutar una rotación y/o revocación.
 Gestión del login en la interfaz web:
bien el servidor web escucha en el puerto 80, solo se mantiene por compatibilidad.
Se cuenta con un certificado válido emitido por COMODO RSA
DomainValidationSecure Server CA. La clave es RSA de 2048 bits y el algoritmo
usado para la firma es SHA256. Por otro lado, el servidor web
conexiones TLS
acceso mediante login. El proceso de autenticación en dos pasos se encarga de
verificar el dispos
nuevo, enviándole
en el código de verificación, se permiten tres intentos. Una vez superados, es
necesario volver a comenzar
un usuario tiene la posibilidad de controlar y eliminar los dispositivos autorizados
asociados a su cuenta. Tras 30 días sin conectarse desde un dispositivo, éste
necesitará una nueva verificación. Una ve
envía un email con un código que hay que insertar para completar la verificación
del dispositivo. La validación del login sigue dos pasos, primero se envía el usuario
junto con un desafío creado en el formulario
replay y se comprueba que existe en la base de datos. A continuación se
comprueba que la clave enviada en el formulario coincide con la clave del usuario
que ha devuelto en la consulta anterior. Las claves se almacenan e
tras un proceso criptográfico con
caso de fallo al intentar identificarse o autenticarse, no se aporta más información
que credenciales inválidas. Se tiene establecido un mecanismo de bloqueo
en el que tras múltiples fallos se bloquea dicha IP. En caso de que se haya realizado
un bloqueo, el mensaje sigue siendo de credenciales inválidas, nunca se da más
de certificación hasta una entidad firmante superior. En su lugar, los captadores
validan la clave pública del certificado contra el almacén local de claves públicas
válidas que tienen instalado. Cada uno de ellos utiliza un mecanismo criptográfico
diferente. Se crean dos almacenes de claves diferentes. El primero irá instalado en
los captadores, y contiene las 5 claves públicas. El segundo irá instalado en los DFs,
y contiene únicamente el par de claves pública y privada que está vigente en este
momento. También se crean 12 sobres sellados “ICE” (In Case of Emergency),
siendo tres copias impresas de cada una de las 4 claves privadas de
rotación/revocación. Cada uno de los sobres ICE indica su número de sobre y los
mecanismos criptográficos utilizados. Las tres copias (cuatro sobres por copia) son
entregadas a tres personas de alto cargo en la empresa (Director Gerente,
Responsable de Área de Negocio, y Director Técnico), quienes las guar
seguro y secreto. Los sobres están debidamente codificados para que nadie ajeno a
este procedimiento conozca su razón de ser ni su forma de aplicación. Por tanto, el
almacén de claves de los captadores tiene cargadas las claves públicas firmad
5 certificados diferentes, siendo uno de ellos es el que está vigente (en uso por los
servidores DF), y los otros 4 son usados para los casos en los que sea necesario
ejecutar una rotación y/o revocación.
Gestión del login en la interfaz web: siempre se redirecciona a HTTPS, aunque si
bien el servidor web escucha en el puerto 80, solo se mantiene por compatibilidad.
Se cuenta con un certificado válido emitido por COMODO RSA
DomainValidationSecure Server CA. La clave es RSA de 2048 bits y el algoritmo
usado para la firma es SHA256. Por otro lado, el servidor web solo acepta
conexiones TLS v1.2. Para acceder a la información y a la gestión, se requiere de un
acceso mediante login. El proceso de autenticación en dos pasos se encarga de
verificar el dispositivo cuando un usuario se intenta identificar desde un dispositivo
enviándole un email a su cuenta de correo con un código. En caso de fallo
en el código de verificación, se permiten tres intentos. Una vez superados, es
necesario volver a comenzar con el proceso. Además, desde la propia plataforma,
un usuario tiene la posibilidad de controlar y eliminar los dispositivos autorizados
asociados a su cuenta. Tras 30 días sin conectarse desde un dispositivo, éste
necesitará una nueva verificación. Una vez validadas las credenciales del usuario se
envía un email con un código que hay que insertar para completar la verificación
del dispositivo. La validación del login sigue dos pasos, primero se envía el usuario
junto con un desafío creado en el formulario vía Ajax para evitar ataques tipo
replay y se comprueba que existe en la base de datos. A continuación se
comprueba que la clave enviada en el formulario coincide con la clave del usuario
que ha devuelto en la consulta anterior. Las claves se almacenan e
tras un proceso criptográfico con una salt aleatoria que es almacenada también.
caso de fallo al intentar identificarse o autenticarse, no se aporta más información
que credenciales inválidas. Se tiene establecido un mecanismo de bloqueo
en el que tras múltiples fallos se bloquea dicha IP. En caso de que se haya realizado
un bloqueo, el mensaje sigue siendo de credenciales inválidas, nunca se da más
de certificación hasta una entidad firmante superior. En su lugar, los captadores
validan la clave pública del certificado contra el almacén local de claves públicas
instalado. Cada uno de ellos utiliza un mecanismo criptográfico
diferente. Se crean dos almacenes de claves diferentes. El primero irá instalado en
los captadores, y contiene las 5 claves públicas. El segundo irá instalado en los DFs,
e el par de claves pública y privada que está vigente en este
momento. También se crean 12 sobres sellados “ICE” (In Case of Emergency),
siendo tres copias impresas de cada una de las 4 claves privadas de
ica su número de sobre y los
mecanismos criptográficos utilizados. Las tres copias (cuatro sobres por copia) son
entregadas a tres personas de alto cargo en la empresa (Director Gerente,
Responsable de Área de Negocio, y Director Técnico), quienes las guardan en lugar
seguro y secreto. Los sobres están debidamente codificados para que nadie ajeno a
este procedimiento conozca su razón de ser ni su forma de aplicación. Por tanto, el
almacén de claves de los captadores tiene cargadas las claves públicas firmadas de
5 certificados diferentes, siendo uno de ellos es el que está vigente (en uso por los
servidores DF), y los otros 4 son usados para los casos en los que sea necesario
se redirecciona a HTTPS, aunque si
bien el servidor web escucha en el puerto 80, solo se mantiene por compatibilidad.
DomainValidationSecure Server CA. La clave es RSA de 2048 bits y el algoritmo
solo acepta
. Para acceder a la información y a la gestión, se requiere de un
acceso mediante login. El proceso de autenticación en dos pasos se encarga de
itivo cuando un usuario se intenta identificar desde un dispositivo
un email a su cuenta de correo con un código. En caso de fallo
en el código de verificación, se permiten tres intentos. Una vez superados, es
con el proceso. Además, desde la propia plataforma,
un usuario tiene la posibilidad de controlar y eliminar los dispositivos autorizados
asociados a su cuenta. Tras 30 días sin conectarse desde un dispositivo, éste
z validadas las credenciales del usuario se
envía un email con un código que hay que insertar para completar la verificación
del dispositivo. La validación del login sigue dos pasos, primero se envía el usuario
vía Ajax para evitar ataques tipo
replay y se comprueba que existe en la base de datos. A continuación se
comprueba que la clave enviada en el formulario coincide con la clave del usuario
que ha devuelto en la consulta anterior. Las claves se almacenan en base de datos
una salt aleatoria que es almacenada también. En
caso de fallo al intentar identificarse o autenticarse, no se aporta más información
que credenciales inválidas. Se tiene establecido un mecanismo de bloqueo por IP
en el que tras múltiples fallos se bloquea dicha IP. En caso de que se haya realizado
un bloqueo, el mensaje sigue siendo de credenciales inválidas, nunca se da más
10
información. Solo pueden eliminar los bloqueos los usuarios
plataforma.
información. Solo pueden eliminar los bloqueos los usuarios administradores de la
administradores de la
11
2 DECLARACIONES DE CONF
2.1 Conformidad respecto a la norma CC
Esta Declaración de Seguridad cumple con lo indicado en la norma
3.1, Parte 2 release 5, y Parte 3 release
2.2 Conformidad respecto a Perfiles de Protección
Esta Declaración de Seguridad no declara el cumplimiento de ningún Perfil de Protección.
ECLARACIONES DE CONFORMIDAD
Conformidad respecto a la norma CC
Esta Declaración de Seguridad cumple con lo indicado en la norma Common Criteria
, y Parte 3 release 5, para un nivel de evaluación EAL1.
respecto a Perfiles de Protección
Esta Declaración de Seguridad no declara el cumplimiento de ningún Perfil de Protección.
Common Criteria versión
Esta Declaración de Seguridad no declara el cumplimiento de ningún Perfil de Protección.
12
3 OBJETIVOS DE SEGURIDA
3.1 Objetivos de seguridad para el entorno operacional
 OE.1 Acceso físico al captador protegido: el acceso físi
autorizado de confianza.
 OE.2 Administrador de confianza en el captador: el usuario no tiene permisos de
root sobre el captador
de root el personal autorizado de
 OE.3 Acceso físico al Cloud protegido: el acceso físico está impedido por la propia
seguridad perimetral del Data Center contratado
 OE.4 Cloud protegido por firewall: firewall seguro que únicamente permite
conexiones exte
(personal de confianza)
Web.
 OE.5 Navegador web TLS v1.2
navegadores que usan TLS v1.2
 OE.6 Administrador de confianza en la plataforma: Los usuarios administradores de
la plataforma únicamente son personal de confianza de Savvy Data Systems.
BJETIVOS DE SEGURIDAD
Objetivos de seguridad para el entorno operacional
Acceso físico al captador protegido: el acceso físico está restringido a personal
autorizado de confianza.
Administrador de confianza en el captador: el usuario no tiene permisos de
sobre el captador para la ejecución de comandos, únicamente tiene permisos
root el personal autorizado de confianza de Savvy Data Systems.
Acceso físico al Cloud protegido: el acceso físico está impedido por la propia
imetral del Data Center contratado.
Cloud protegido por firewall: firewall seguro que únicamente permite
conexiones externas mediante SSH desde la oficina de Savvy Data Systems
(personal de confianza). El puerto 443 está abierto al exterior en servidores DF y
Navegador web TLS v1.2: el servidor web solo acepta peticiones de
gadores que usan TLS v1.2.
nistrador de confianza en la plataforma: Los usuarios administradores de
la plataforma únicamente son personal de confianza de Savvy Data Systems.
co está restringido a personal
Administrador de confianza en el captador: el usuario no tiene permisos de
, únicamente tiene permisos
confianza de Savvy Data Systems.
Acceso físico al Cloud protegido: el acceso físico está impedido por la propia
Cloud protegido por firewall: firewall seguro que únicamente permite
rnas mediante SSH desde la oficina de Savvy Data Systems
. El puerto 443 está abierto al exterior en servidores DF y
: el servidor web solo acepta peticiones de
nistrador de confianza en la plataforma: Los usuarios administradores de
la plataforma únicamente son personal de confianza de Savvy Data Systems.
13
4 DEFINICIÓN DE COMPONE
No se definen componentes extendidos
EFINICIÓN DE COMPONENTES EXTENDIDOS
No se definen componentes extendidos
14
5 REQUISITOS DE SEGURID
5.1 Requisitos funcionales de seguridad
Class FDP
 FDP_IFC Information Flow Control Policy
o FDP_IFC.1
information flow control SFPs be in place for a subset of the possible
operations on a subset of inf

 FDP_IFF Information Flow Control Functions
o FDP_IFF.1
information, and on subjects that cause that information to flow and on
subjects that act as recipients
must be enforced by the function, and describes how security attributes
are derived by the function.





EQUISITOS DE SEGURIDAD DEL TOE
uisitos funcionales de seguridad
FDP_IFC Information Flow Control Policy
FDP_IFC.1 Subset information flow control, requires that each identified
information flow control SFPs be in place for a subset of the possible
operations on a subset of information flows in the TOE.
FDP_IFC.1.1 The TSF shall enforce the [Savvy M2C
control SFP] on [
Subjects: Savvy Smart Boxes
Information: network packets of the communication established
between the Savvy Smart Boxes and the cloud of Savvy
Systems
Operations: allow, deny
].
FDP_IFF Information Flow Control Functions
FDP_IFF.1 Simple security attributes, requires security attributes on
information, and on subjects that cause that information to flow and on
subjects that act as recipients of that information. It specifies the rules that
must be enforced by the function, and describes how security attributes
are derived by the function.
FDP_IFF.1.1 The TSF shall enforce the [Savvy M2C
control SFP] based on the following types of subject and
information security attributes:
[
Subject - Savvy Smart Boxes with security attributes: ID, password
Information - network packets with security attributes: source IP
address
].
FDP_IFF.1.2 The TSF shall permit an information flow bet
controlled subject and controlled information via a controlled
operation if the following rules hold: [if the source IP address of
the packets coming from the Savvy Smart Box is not blocked in
the cloud and the ID and passwords of the Savvy Smart Bo
correct, then the communication is allowed. Otherwise, the
communication is denied].
FDP_IFF.1.3 The TSF shall enforce the [no additional rules
FDP_IFF.1.4 The TSF shall explicitly authorise an information flow
based on the following rules: [no additional rules rules
FDP_IFF.1.5 The TSF shall explicitly deny an information flow based
on the following rules: [no additional rules].
Subset information flow control, requires that each identified
information flow control SFPs be in place for a subset of the possible
.
M2C information flow
Information: network packets of the communication established
between the Savvy Smart Boxes and the cloud of Savvy Data
Simple security attributes, requires security attributes on
information, and on subjects that cause that information to flow and on
of that information. It specifies the rules that
must be enforced by the function, and describes how security attributes
M2C information flow
types of subject and
Savvy Smart Boxes with security attributes: ID, password
network packets with security attributes: source IP
The TSF shall permit an information flow between a
controlled subject and controlled information via a controlled
if the source IP address of
the packets coming from the Savvy Smart Box is not blocked in
the cloud and the ID and passwords of the Savvy Smart Box are
correct, then the communication is allowed. Otherwise, the
no additional rules].
The TSF shall explicitly authorise an information flow
itional rules rules].
FDP_IFF.1.5 The TSF shall explicitly deny an information flow based
15
 FDP_ITT Internal TOE transfer
o FDP_ITT.1 Basic Internal transfer protection
protected when

Class FIA
 FIA_AFL Authentication failures
o FIA_AFL.1 Authentication failure handling
terminate the session establishment process after a specified number of
unsuccessful user authentication attempts. It also requires that, after
termination of the session establishment process, the TSF be able to
disable the user account or the point of entry (e.g. workstation) from which
the attempts were made until an administrator


 FIA_UAU User authentication
o FIA_UAU.2
authenticated before any other action will be allowed by the TSF.

o FIA_UAU.7 Protected authentication feedback
feedback information is provided to the user during the authentication.

 FIA_UID User identification
o FIA_UID.2 User identification before any action
themselves before any other action will be allowed by the TSF.

Class FPT
 FPT_ITT Internal TOE TSF data transfer
o FPT_ITT.1 Basic internal TSF data transfer protection
be prot
FDP_ITT Internal TOE transfer
FDP_ITT.1 Basic Internal transfer protection, requires that user data be
protected when transmitted between parts of the TOE.
FDP_ITT.1.1: The TSF shall enforce the [Savvy M2C
flow control SFP] to prevent the [disclosure and
user data when it is transmitted between physically
parts of the TOE.
Authentication failures
FIA_AFL.1 Authentication failure handling requires that the TSF be able to
terminate the session establishment process after a specified number of
unsuccessful user authentication attempts. It also requires that, after
mination of the session establishment process, the TSF be able to
disable the user account or the point of entry (e.g. workstation) from which
the attempts were made until an administrator-defined condition occurs.
FIA_AFL.1.1: The TSF shall detect when [five (5)
authentication attempts occur related to [failed login attemps
FIA_AFL.1.2: When the defined number of unsuccessful
authentication attempts has been [met], the TSF shall [
address].
FIA_UAU User authentication
FIA_UAU.2 User authentication before any action, requires that users are
authenticated before any other action will be allowed by the TSF.
FIA_UAU.2.1: The TSF shall require each user to be successfully
authenticated before allowing any other TSF-mediated actions on
behalf of that user.
FIA_UAU.7 Protected authentication feedback, requires that only limited
feedback information is provided to the user during the authentication.
FIA_UAU.7.1: The TSF shall provide only [the character ‘
character of the password] to the user while the authentication is
in progress.
FIA_UID User identification
FIA_UID.2 User identification before any action, requires that users identify
themselves before any other action will be allowed by the TSF.
FIA_UID.2.1: The TSF shall require each user to be successfully
identified before allowing any other TSF-mediated actions on
behalf of that user.
Internal TOE TSF data transfer
FPT_ITT.1 Basic internal TSF data transfer protection, requires that TSF data
be protected when transmitted between separate parts of the TOE.
requires that user data be
transmitted between parts of the TOE.
M2C information
and modification] of
user data when it is transmitted between physically-separated
requires that the TSF be able to
terminate the session establishment process after a specified number of
unsuccessful user authentication attempts. It also requires that, after
mination of the session establishment process, the TSF be able to
disable the user account or the point of entry (e.g. workstation) from which
defined condition occurs.
ive (5)] unsuccessful
failed login attemps].
When the defined number of unsuccessful
], the TSF shall [block the IP
User authentication before any action, requires that users are
authenticated before any other action will be allowed by the TSF.
The TSF shall require each user to be successfully
mediated actions on
requires that only limited
feedback information is provided to the user during the authentication.
the character ‘*’ for each
] to the user while the authentication is
requires that users identify
themselves before any other action will be allowed by the TSF.
ll require each user to be successfully
mediated actions on
requires that TSF data
ected when transmitted between separate parts of the TOE.
16

Class FTA
 FTA_SSL Session locking and termination
o FTA_SSL.4
terminate the user's own interactive sessions.

 FTA_TSE TOE session establishment
o FTA_TSE.1
users access to the TOE based on attributes.

5.2 Requisitos de garantía de seguridad
El desarrollo y evaluación del TOE se realizará conforme al siguiente nivel de garantía:
 EAL1
5.3 Justificación de los Requisitos de garantía de seguridad
La garantía de seguridad deseada para este tipo de TOE según las exigencias del mercado es
la proporcionada por el nivel de evaluación
5.4 Dependencias de los Requisitos funcionales de seguridad
Todas las dependencias, tanto en los requisito
garantía se han satisfecho, salvo la dependencia del requisito de FDP_IFF.1 con FMT_MSA.3. El
The TSF shall protect TSF data from [disclosure and modification
when it is transmitted between separate parts of the TOE.
Session locking and termination
FTA_SSL.4 User-initiated termination, provides capabilities for the user to
terminate the user's own interactive sessions.
FTA_SSL.4.1: The TSF shall allow user-initiated termination of the
user's own interactive session.
FTA_TSE TOE session establishment
FTA_TSE.1 TOE session establishment, provides requirements for denying
users access to the TOE based on attributes.
FTA_TSE.1.1: The TSF shall be able to deny session establishment
based on [blocked IP and valid credentials].
Requisitos de garantía de seguridad
desarrollo y evaluación del TOE se realizará conforme al siguiente nivel de garantía:
Justificación de los Requisitos de garantía de seguridad
La garantía de seguridad deseada para este tipo de TOE según las exigencias del mercado es
la proporcionada por el nivel de evaluación equivalente EAL1.
Dependencias de los Requisitos funcionales de seguridad
Todas las dependencias, tanto en los requisitos funcionales de seguridad como los de
garantía se han satisfecho, salvo la dependencia del requisito de FDP_IFF.1 con FMT_MSA.3. El
disclosure and modification]
when it is transmitted between separate parts of the TOE.
provides capabilities for the user to
initiated termination of the
provides requirements for denying
The TSF shall be able to deny session establishment
desarrollo y evaluación del TOE se realizará conforme al siguiente nivel de garantía:
La garantía de seguridad deseada para este tipo de TOE según las exigencias del mercado es
s funcionales de seguridad como los de
garantía se han satisfecho, salvo la dependencia del requisito de FDP_IFF.1 con FMT_MSA.3. El
17
TOE no implementa funcionalidad de gestión asociada a los atributos de seguridad de la política
de control de flujo definida en FDP_IFF.1/FDP_IFC.1. Estos atributos de seguridad son establecidos
por personal de Savvy en la fase previa de instalación y no son modificados durante la operación
habitual del TOE.
TOE no implementa funcionalidad de gestión asociada a los atributos de seguridad de la política
a en FDP_IFF.1/FDP_IFC.1. Estos atributos de seguridad son establecidos
por personal de Savvy en la fase previa de instalación y no son modificados durante la operación
TOE no implementa funcionalidad de gestión asociada a los atributos de seguridad de la política
a en FDP_IFF.1/FDP_IFC.1. Estos atributos de seguridad son establecidos
por personal de Savvy en la fase previa de instalación y no son modificados durante la operación
18
6 ESPECIFICACIÓN RESUMIDA DEL
A continuación se indica, para cada u
son implementados por el TOE.
FDP_IFC.1 y FDP_IFF.1
Cuando un captador se conecta contra el Cloud, éste envía sus credenciales de conexión (ID
y password) únicas asignadas
Savvy Data Systems durante el montaje del captador. El Cloud comprueba que la dirección IP del
captador no está bloqueada y que las credenciales recibidas están dadas de alta en el sistema y
son correctas. Si esto se cumple, se permite la comunicación entre el Cloud y el captador. En caso
de que las credenciales sean incorrectas, se bloquea automáticamente dicha dirección IP. No se
permite ningún fallo o intento adicional.
FDP_ITT.1 y FPT_ITT.1
La comunicación entre captador y Cloud se realiza utilizando TLS
Cloud-usuario se realiza también a través de TLS
aplicación que explica cómo se controla la conexión.
FIA_AFL.1
Tras 5 intentos fallidos
desde la que se intenta acceder
FIA_UAU.2
Cuando se entra a la interfaz web, tanto a gestión como a presentación, lo primero que se
solicita es el login (si tiene la opción de recordar c
que sea la primera vez que se entra desde ese dispositivo, se necesita validarlo mediante el
mecanismo de autenticación en dos pasos.
FIA_UAU.7
En caso de fallo en la autenticación o de estar bloqueado, el me
siempre es el mismo: Invalid credentials.
FIA_UID.2
Cuando se entra a la interfaz web, tanto a gestión como a presentación, lo primero que se
solicita es el login (si tiene la opción de recordar crede
que sea la primera vez que se entra desde ese dispositivo, se necesita validarlo mediante el
mecanismo de autenticación en dos pasos.
FTA_SSL.4
El usuario, tanto usuario común como usuario administrador,
puede eliminar un dispositivo autorizado desde el que ha accedido
ESUMIDA DEL TOE
A continuación se indica, para cada uno de los requisitos funcionales de seguridad, cómo
son implementados por el TOE.
Cuando un captador se conecta contra el Cloud, éste envía sus credenciales de conexión (ID
y password) únicas asignadas y dadas de alta en el sistema por el personal técnico de confianza de
Savvy Data Systems durante el montaje del captador. El Cloud comprueba que la dirección IP del
captador no está bloqueada y que las credenciales recibidas están dadas de alta en el sistema y
umple, se permite la comunicación entre el Cloud y el captador. En caso
de que las credenciales sean incorrectas, se bloquea automáticamente dicha dirección IP. No se
permite ningún fallo o intento adicional.
entre captador y Cloud se realiza utilizando TLS v1.2. La comunicación
usuario se realiza también a través de TLS v1.2. Para FDP_ITT, se ha definido una nota de
aplicación que explica cómo se controla la conexión.
5 intentos fallidos de acceso desde la misma dirección IP, se bloquea dicha dirección IP
desde la que se intenta acceder.
Cuando se entra a la interfaz web, tanto a gestión como a presentación, lo primero que se
solicita es el login (si tiene la opción de recordar credenciales, se entra directamente). En caso de
que sea la primera vez que se entra desde ese dispositivo, se necesita validarlo mediante el
mecanismo de autenticación en dos pasos.
En caso de fallo en la autenticación o de estar bloqueado, el mensaje que se muestra
siempre es el mismo: Invalid credentials.
Cuando se entra a la interfaz web, tanto a gestión como a presentación, lo primero que se
solicita es el login (si tiene la opción de recordar credenciales, se entra directamente). En
que sea la primera vez que se entra desde ese dispositivo, se necesita validarlo mediante el
mecanismo de autenticación en dos pasos.
tanto usuario común como usuario administrador, a través de la plataforma,
n dispositivo autorizado desde el que ha accedido, incluido el dispositivo desde el
no de los requisitos funcionales de seguridad, cómo
Cuando un captador se conecta contra el Cloud, éste envía sus credenciales de conexión (ID
r el personal técnico de confianza de
Savvy Data Systems durante el montaje del captador. El Cloud comprueba que la dirección IP del
captador no está bloqueada y que las credenciales recibidas están dadas de alta en el sistema y
umple, se permite la comunicación entre el Cloud y el captador. En caso
de que las credenciales sean incorrectas, se bloquea automáticamente dicha dirección IP. No se
. La comunicación
Para FDP_ITT, se ha definido una nota de
, se bloquea dicha dirección IP
Cuando se entra a la interfaz web, tanto a gestión como a presentación, lo primero que se
nciales, se entra directamente). En caso de
que sea la primera vez que se entra desde ese dispositivo, se necesita validarlo mediante el
nsaje que se muestra
Cuando se entra a la interfaz web, tanto a gestión como a presentación, lo primero que se
nciales, se entra directamente). En caso de
que sea la primera vez que se entra desde ese dispositivo, se necesita validarlo mediante el
a través de la plataforma,
, incluido el dispositivo desde el
19
que está conectado. En ese caso, se le cerrará su sesión y será necesario que se acredite de
nuevo.
FTA_TSE.1
Para denegar el establecimiento de sesión,
También se comprueba si las credenciales de acceso son válidas.
En ese caso, se le cerrará su sesión y será necesario que se acredite de
Para denegar el establecimiento de sesión, se comprueba si una IP está bloqueada o no
También se comprueba si las credenciales de acceso son válidas.
En ese caso, se le cerrará su sesión y será necesario que se acredite de
se comprueba si una IP está bloqueada o no.