Saltar a contenido

Las condiciones para una cibernéticoLos elementos Cleanroom Plataforma independiente

Máquina

OS

CPU

RAM

Disco

Recomendamos dividir el disco usando LVM para proporcionar una mayor flexibilidad si el tamaño de la máquina necesita ser revisado durante el uso.

Los diferentes tipos de servidores tienen diferentes patrones de uso de disco, con volúmenes que también difieren.

Este servidor tendrá un volumen creciente en los siguientes directorios:

  • /var/log/: directorio que contiene los diversos registros del sistema.
  • /var/lib/postgresql/15/main/: directorio que contiene datos de la base de datos local.
  • /var/ipdiva/: directorio que contiene datos específicos del producto.

El aislamiento de los diferentes directorios en diferentes particiones no es obligatorio, pero se recomienda.

Punto de montaje Opciones Tamaño mínimo (GB)
/boot No se puede, no se puede, no se puede. 1
/opt No lo sé, no lo sé. 1
/tmp No lo sé, no lo sé. 4
/srv No lo sé, no lo sé. 1
/home No se puede, no se puede, no se puede. 6
/usr No se 6
/var No se sabe 5
/var/log No se puede, no se puede, no se puede. 5
/var/tmp No se puede, no se puede, no se puede. 2
swap No hay opción Dependiendo de la RAM (la mitad menos)
/ No hay opción 2 GB o más dependiendo del espacio disponible en disco

Ejemplo

Para un servidor con 4 GB de RAM (que requiere 2 GB de swap), el espacio en disco requerido con el particionamiento anterior es de un mínimo de 35 GB.

Este servidor experimentará un aumento de volumen en los siguientes directorios:

  • /var/log/: directorio que contiene los diversos registros del sistema.
  • /var/lib/ipdiva/carerecord/recording/: directorio que contiene los archivos que se están registrando actualmente; por lo tanto, se trata de un directorio de almacenamiento temporal.
  • /var/lib/ipdiva/carerecord/archives/: directorio predeterminado que contiene los archivos gráficos del producto.
  • /var/ipdiva/care/sshrecord/: directorio predeterminado que contiene los archivos no gráficos (SSH) del producto.

El aislamiento de los diferentes directorios en diferentes particiones no es obligatorio, pero se recomienda.

Punto de montaje Opciones Tamaño mínimo (GB)
/boot No se puede, no se puede, no se puede. 1
/opt No lo sé, no lo sé. 1
/tmp No lo sé, no lo sé. 4
/srv No lo sé, no lo sé. 1
/home No se puede, no se puede, no se puede. 6
/usr No se 6
/var No lo sé, no lo sé. 5
/var/log No se puede, no se puede, no se puede. 5
/var/tmp No se puede, no se puede, no se puede. 2
swap No hay opción Dependiendo de la RAM (la mitad menos)
/ No hay opción 2 GB o más dependiendo del espacio disponible en disco

Ejemplo

Para un servidor con 4 GB de RAM (que requiere 2 GB de swap), el espacio en disco requerido con el particionamiento anterior es de un mínimo de 35 GB.

Sin embargo, se recomienda encarecidamente asignar más espacio en disco para archivos gráficos temporales o a largo plazo con el punto de montaje /var a menos que los archivos sean subcontratados {target="_blank"}.

Este servidor tendrá un volumen creciente en los siguientes directorios:

  • /var/log/: directorio que contiene los diversos registros del sistema.
  • /home/systanciahtml5share/: directorio de almacenamiento temporal para los archivos intercambiados con aplicaciones HTML5.

El aislamiento de los diferentes directorios en diferentes particiones no es obligatorio, pero se recomienda.

Punto de montaje Opciones Tamaño mínimo (GB)
/boot No se puede, no se puede, no se puede. 1
/opt No lo sé, no lo sé. 1
/tmp No lo sé, no lo sé. 4
/srv No lo sé, no lo sé. 1
/home No se puede, no se puede, no se puede. 6
/usr No se 6
/var No lo sé, no lo sé. 5
/var/log No se puede, no se puede, no se puede. 5
/var/tmp No se puede, no se puede, no se puede. 2
swap No hay opción Dependiendo de la RAM (la mitad menos)
/ No hay opción 2 GB o más dependiendo del espacio disponible en disco

Ejemplo

Para un servidor con 4 GB de RAM (que requiere 2 GB de swap), el espacio en disco requerido con el particionamiento anterior es de un mínimo de 35 GB.

-8<-- [fin de disco]

--8<-- [Comienzo: introducción del certificado]

cyberelements Cleanroom utiliza el cifrado TLS para las comunicaciones internas y HTTPS para asegurar el acceso a la web, lo que requiere el uso de varios certificados x509. La información a continuación resume los diferentes certificados requeridos, su propósito y la configuración mínima.

--8<-- [fin del certificado-introducción]

-8<-- [Comienzo: aviso de certificado]

Constraint de seguridad del certificado

Independientemente del certificado utilizado, asegúrese de que cumple con el nivel de seguridad OpenSSL 2, que puede resumirse de la siguiente manera:

  • El certificado y los certificados de sus autoridades de certificación deberán tener una clave privada de al menos 2048 bits con cifrado RSA, DSA y DH; en el caso de las claves de curva elíptica (ECC), deberán tener al menos 224 bits.
  • La firma del certificado no debe ser MD5 o SHA-1 (se prefiere SHA-512).

--8<-- [fin: aviso del certificado]

-8<-- [Comienzo: certificado-med-web]

Recomendación

El certificado web debe ser emitido preferentemente por una autoridad de certificación pública (CA) que sea reconocida como confiable.
Esto garantizará que los usuarios no reciban ninguna alerta relacionada con el certificado utilizado (siempre que sea válido y cubra el nombre con el que el usuario inició la conexión) sin ninguna acción adicional. El uso de un certificado emitido por un PKI interno requiere la implementación del certificado de CA en las estaciones de trabajo de los usuarios.

El certificado web debe cumplir las siguientes restricciones para sus atributos:

  • El período de validez del certificado no podrá exceder de 398 días (13 meses).
  • La función hash utilizada para la firma debe ser parte de la familia SHA-2; recomendamos SHA-512.
  • El certificado y los certificados de sus autoridades de certificación deben tener una clave privada de al menos 2048 bits con cifrado RSA, DSA y DH; para las claves de curva elíptica (ECC), deben ser al menos 224 bits. Recomendamos un tamaño de 4096 bits para RSA y un tamaño de curva ECDSA secp384r1 de 384 bits.
  • El Common Name el atributo debe tener como valor el nombre DNS (o comodín) para el que está destinado el certificado.
  • El Key Usage el atributo debe tener los valores critical, digitalSignature y keyEncipherment.
  • El Extended Key Usage el atributo debe tener el id-kp-serverAuth (OpenSSL utiliza el serverAuth de las cantidades).
  • El Subject Alternative Name el atributo debe contener al menos una entrada correspondiente al nombre DNS primario; se pueden añadir otras entradas para cubrir otros nombres DNS o direcciones IP.

Formato de certificado aceptado: P12 o PEM (con dos archivos, uno para el certificado y otro para la clave privada).

-8<-- [fin:certificado-med-web] -No, no es cierto.

-8<-- [Comienzo: certificado-med-ssl]

El certificado de enrutador SSL debe cumplir las siguientes restricciones para sus atributos:

  • El período de validez del certificado no podrá exceder de 1095 días (3 años).
  • La función hash utilizada para la firma debe ser parte de la familia SHA-2; recomendamos SHA-512.
  • El certificado y los certificados de sus autoridades de certificación deben tener una clave privada de al menos 2048 bits con cifrado RSA, DSA y DH; para las claves de curva elíptica (ECC), deben ser al menos 224 bits. Recomendamos un tamaño de 4096 bits para RSA y un tamaño de curva ECDSA secp384r1 de 384 bits.
  • El Common Name atributo debe tener como su valor la dirección IP o un nombre DNS redirigiendo a IP_MED_SSL.
  • El Key Usage el atributo debe tener los valores critical, digitalSignature y keyEncipherment.
  • El Extended Key Usage el atributo debe tener el valor serverAuth.

El formato del certificado aceptado es P12.

-8<-- [fin:certificado-med-ssl] -8<-- [fin:certificado-med-ssl] -8<-- [fin:certificado-med-ssl]

-8<-- [Comienzo: certificado-med-guardián]

El certificado de perro guardián debe cumplir las siguientes restricciones para sus atributos:

  • El período de validez del certificado no podrá exceder de 1095 días (3 años).
  • La función hash utilizada para la firma debe ser parte de la familia SHA-2; recomendamos SHA-512.
  • El certificado y los certificados de sus autoridades de certificación deben tener una clave privada de al menos 2048 bits con cifrado RSA, DSA y DH; para las claves de curva elíptica (ECC), deben ser al menos 224 bits. Recomendamos un tamaño de 4096 bits para RSA y un tamaño de curva ECDSA secp384r1 de 384 bits.
  • El Common Name el atributo debe tener un valor que sea un nombre de identificación para el Watchdog, por ejemplo Watchdog.
  • El Key Usage el atributo debe tener los valores critical y digitalSignature.
  • El Extended Key Usage el atributo debe tener el valor clientAuth.

El formato del certificado aceptado es P12.

-8<-- [fin:certificado-med-guardián]

--8<-- [Comienzo: certificado-med-cliente]

El certificado cliente cyberelements Cleanroom debe cumplir las siguientes restricciones para sus atributos:

  • El período de validez del certificado no podrá exceder de 1095 días (3 años).
  • La función hash utilizada para la firma debe ser parte de la familia SHA-2; recomendamos SHA-512.
  • El certificado y los certificados de sus autoridades de certificación deben tener una clave privada de al menos 2048 bits con cifrado RSA, DSA y DH; para las claves de curva elíptica (ECC), deben ser al menos 224 bits. Recomendamos un tamaño de 4096 bits para RSA y un tamaño de curva ECDSA secp384r1 de 384 bits.
  • El atributo Common Name debe tener un valor que sea un nombre de identificación del cliente, por ejemplo cyberelements-cleanroom-client.
  • El Key Usage el atributo debe tener los valores critical y digitalSignature.
  • El Extended Key Usage el atributo debe tener el valor clientAuth.

Formato de certificado aceptado: P12 con una contraseña de ** al menos 8 caracteres alfanuméricos** (no se admiten caracteres especiales, letras con acento o guiones).

--8<-- [fin:certificado-med-cliente]

--8<-- [Comienzo: certificado-con-interserver]

El certificado Cleanroominterserver cyberelements debe cumplir las siguientes restricciones para sus atributos:

  • El período de validez del certificado no podrá exceder de 1095 días (3 años).
  • La función hash utilizada para la firma debe ser parte de la familia SHA-2; recomendamos SHA-512.
  • El certificado y los certificados de sus autoridades de certificación deben tener una clave privada de al menos 2048 bits con cifrado RSA, DSA y DH; para las claves de curva elíptica (ECC), deben ser al menos 224 bits. Recomendamos un tamaño de 4096 bits para RSA y un tamaño de curva ECDSA secp384r1 de 384 bits.
  • El Common Name El atributo debe tener un nombre de identificación como su valor, por ejemplo interserver-cleanroom.
  • El Key Usage el atributo debe tener los valores critical y digitalSignature.
  • El Extended Key Usage el atributo debe tener el valor clientAuth.

Formato de certificado aceptado: P12 con una contraseña de al menos 8 caracteres sin caracteres especiales.

--8<-- [fin de:certificado-con-interservidor]

-8<-- [Comienzo: certificado-gw]

El certificado Edge Gateway deberá cumplir las siguientes restricciones para sus atributos:

  • El período de validez del certificado no podrá exceder de 1095 días (3 años).
  • La función hash utilizada para la firma debe ser parte de la familia SHA-2; recomendamos SHA-512.
  • El certificado y los certificados de sus autoridades de certificación deben tener una clave privada de al menos 2048 bits con cifrado RSA, DSA y DH; para las claves de curva elíptica (ECC), deben ser al menos 224 bits. Recomendamos un tamaño de 4096 bits para RSA y un tamaño de curva ECDSA secp384r1 de 384 bits.
  • El Common Name atributo debe tener un valor que identifique el lógico Edge GatewayEste nombre tiene la siguiente forma: <GW_NAME>@<ORGANIZATION_NAME>, donde <GW_NAME> corresponde al nombre del Edge Gateway (como se introduce en la consola de administración) y <ORGANIZATION_NAME> corresponde al nombre de la organización a la que se refiere el Edge Gateway se conectará.
  • El Key Usage el atributo debe tener los valores critical y digitalSignature.
  • El Extended Key Usage el atributo debe tener el valor clientAuth.

El formato del certificado aceptado es P12.

--8<-- [fin del certificado-gw]

-8<-- [Comienzo: certificado-gw-careserver]

El certificado de servicio de registro deberá cumplir las siguientes restricciones en cuanto a sus atributos:

  • El período de validez del certificado no podrá exceder de 1095 días (3 años).
  • La función hash utilizada para la firma debe ser parte de la familia SHA-2; recomendamos SHA-512.
  • El certificado y los certificados de sus autoridades de certificación deben tener una clave privada de al menos 2048 bits con cifrado RSA, DSA y DH; para las claves de curva elíptica (ECC), deben ser al menos 224 bits. Recomendamos un tamaño de 4096 bits para RSA y un tamaño de curva ECDSA secp384r1 de 384 bits.
  • El Common Name El atributo debe tener el nombre de FQDN o al menos el nombre de la Edge Gateway la máquina como su valor.
  • El Key Usage el atributo debe tener los valores critical, digitalSignature y keyEncipherment.
  • El Extended Key Usage el atributo debe tener el valor serverAuth.

El formato del certificado aceptado es P12.

-8<-- [fin:certificado-gw-careserver] -No, no es cierto.

El certificado de la pasarela HTML5 debe cumplir las siguientes restricciones para sus atributos:

  • El período de validez del certificado no podrá exceder de 1095 días (3 años).
  • La función hash utilizada para la firma debe ser parte de la familia SHA-2; recomendamos SHA-512.
  • El certificado y los certificados de sus autoridades de certificación deben tener una clave privada de al menos 2048 bits con cifrado RSA, DSA y DH; para las claves de curva elíptica (ECC), deben ser al menos 224 bits. Recomendamos un tamaño de 4096 bits para RSA y un tamaño de curva ECDSA secp384r1 de 384 bits.
  • El Common Name atributo debe tener un valor que identifique el lógico Edge GatewayEste nombre tiene la siguiente forma: <HTML5_GW_NAME>@<ORGANIZATION_NAME>, donde <HTML5_GW_NAME> corresponde al nombre del Edge Gateway (como se introduce en la consola de administración) y <ORGANIZATION_NAME> corresponde al nombre de la organización a la que se refiere el Edge Gateway se conectará.
  • El Key Usage el atributo debe tener los valores critical y digitalSignature.
  • El Extended Key Usage el atributo debe tener el valor clientAuth.

El formato del certificado aceptado es P12.

--8<-- [fin del certificado]

--8<-- [Comienzo: registro directo del certificado]

El certificado deberá cumplir las siguientes restricciones en cuanto a sus atributos:

  • El período de validez del certificado no podrá exceder de 1095 días (3 años).
  • La función hash utilizada para la firma debe ser parte de la familia SHA-2; recomendamos SHA-512.
  • El certificado y los certificados de sus autoridades de certificación deben tener una clave privada de al menos 2048 bits con cifrado RSA, DSA y DH; para las claves de curva elíptica (ECC), deben ser al menos 224 bits. Recomendamos un tamaño de 4096 bits para RSA y un tamaño de curva ECDSA secp384r1 de 384 bits.
  • El Common Name Este atributo debe tener un valor que sea el nombre abreviado, FQDN, o cualquier otro nombre que identifique de manera única la máquina.
  • El Key Usage el atributo debe tener los valores critical y digitalSignature.
  • El Extended Key Usage el atributo debe tener el valor clientAuth.

El formato del certificado aceptado es P12.

--8<-- [fin: certificado-grabación directa]

Red de transporte de personas

A. El cibernéticoLos elementos Cleanroom La plataforma independiente requerirá:

  • 2 direcciones IP para el servidor Mediation Controller (cargadas por la misma interfaz de red)
  • 1 dirección IP por Edge Gateway o por cada máquina de la puerta de enlace HTML5

El servidor Mediation Controller generalmente se coloca en una DMZ, pero también se puede colocar en una DMZ privada o alojada en una nube pública. Esto dependerá del caso de uso de la plataforma (por ejemplo: acceso remoto para proveedores de servicios o asegurar el acceso interno a áreas protegidas).

Los servidores Edge Gateway generalmente se colocan en la LAN, en VLAN que les permiten comunicarse con los recursos de destino.

Los servidores de la puerta de enlace HTML5 pueden colocarse en la LAN o en la DMZ. Esta documentación proporciona la instalación del componente de la puerta de enlace HTML5 en el servidor Edge Gateway, es decir, en la LAN.

Para identificar mejor las diferentes direcciones de las máquinas, se hará referencia a ellas en la documentación de la siguiente manera:

nombre de la dirección IP significado
IP_MED_WEB Dirección IP primaria del servidor Mediation Controller, que permite el acceso a las consolas web.
IP_MED_SSL Segunda dirección IP del servidor Mediation Controller utilizado por el componente de enrutador SSL.
IP_GW Dirección IP del servidor Edge Gateway
IP_HTML5_GW Dirección IP del servidor de la puerta de enlace HTML5.

Info

La información de flujo mostrada supone que el Mediation Controller el servidor está ubicado en la DMZ y que el Edge Gateway El servidor también tiene el rol de puerta de enlace HTML5 ubicado en la LAN.

Las direcciones IP de Mediation Controller pueden ser direcciones IP públicas asignadas directamente al servidor Mediation Controller o direcciones IP públicas que están NATed a direcciones IP privadas (recomendado).

Fuente Destino Puerto de destino Comentarios
Estación de trabajo del usuario IP_MED_WEB TCP 443 (si se utiliza el puerto estándar) Permitir el acceso a las consolas web y aplicaciones que se ejecutan directamente en el navegador.
Estación de trabajo del usuario IP_MED_SSL TCP 443 (si se utiliza el puerto estándar) Establecer un túnel TLS para cifrar el flujo que pasa a través de la cibernéticoLos elementos Cleanroom El cliente.
IP_GW IP_MED_WEB TCP 443 (si se utiliza el puerto estándar) Cuando el Edge Gateway se encuentra en una red remota. Conexión al sistema de emparejamiento Edge Gateway.
IP_GW IP_MED_SSL TCP 443 (si se utiliza el puerto estándar) Cuando el Edge Gateway Se conecta al router SSL para establecer un túnel TLSv1.3 y enrutar las comunicaciones del producto a través de él.
Fuente Destino Puerto de destino Comentarios
IP_MED_WEB Repositorios de Debian TCP 80 Se requiere para la instalación cibernéticoLos elementos Cleanroom La documentación y los dispositivos virtuales utilizan los datos de las aplicaciones de la red para facilitar la gestión de las dependencias y mantener el sistema actualizado. ftp.fr.debian.org y security.debian.org.
IP_MED_WEB packages.microsoft.com El número de la señal Repositorio de Microsoft para instalar y actualizar controladores MS SQL. Sólo se requiere si se desea el acceso a una base de datos MS SQL (las aplicaciones virtuales tienen controladores MS SQL).
IP_MED_WEB Servidor de tiempo NTP UDP 123 Opcional si el servidor necesita sincronizar su reloj con un servidor en la DMZ. Por defecto, se utilizan los grupos de Debian: 0.debian.pool.ntp.org, 1.debian.pool.ntp.org, 2.debian.pool.ntp.org y 3.debian.pool.ntp.org.
IP_MED_WEB Servidor SMTP El número de los miembros de la Comisión Se requiere si se debe utilizar un servidor SMTP para el envío de correos electrónicos y se encuentra en la WAN.
IP_MED_WEB Servidor de DNS UDP 53 y Se requiere para la resolución de DNS. Puede ubicarse en la WAN o DMZ.
IP_MED_WEB api.neomia.ai TCP 443 (Opcional) Conexión a las API del producto MFA biométrico de comportamiento Neomia Pulse {target="_blank"}.
IP_MED_WEB EU: keepersecurity.eu
US: keepersecurity.com
AU: keepersecurity.com.au
CA: keepersecurity.ca
JP: keepersecurity.jp		 TCP 443 (Opcional) Conexión con la bóveda Keeper EPM {target="_blank"} dependiendo de su ubicación.
Fuente Destino Puerto de destino Comentarios
IP_MED_WEB Servidor de tiempo NTP UDP 123 (en inglés) Si el servidor necesita sincronizar su reloj con un servidor en la DMZ.
IP_MED_WEB Servidor SMTP TCP 25, 465, 587 Se requiere si se debe utilizar un servidor SMTP para enviar correos electrónicos y se encuentra en la DMZ.
IP_MED_WEB Servidor de base de datos TCP 1433, 5432, o cualquier otro puerto personalizado Se requiere si desea utilizar una base de datos externa ubicada en la DMZ.
IP_MED_WEB Servidor de DNS UDP 53 y Se requiere para la resolución de DNS. Puede ubicarse en la DMZ o en la WAN.
Fuente Destino Puerto de destino Comentarios
IP_GW Repositorios de Debian TCP 80 Se requiere para la instalación cibernéticoLos elementos Cleanroom La documentación y los dispositivos virtuales utilizan los datos de las aplicaciones de la red para facilitar la gestión de las dependencias y mantener el sistema actualizado. ftp.fr.debian.org y security.debian.org.
IP_GW Servidor de DNS UDP 53 y Se requiere para la resolución de DNS. Opcional si hay un servidor DNS disponible en la LAN o DMZ.
IP_GW servidor de tiempo NTP UDP 123 Opcional si el servidor necesita sincronizar su reloj con un servidor en la LAN o DMZ. Por defecto, se utilizan los grupos de Debian: 0.debian.pool.ntp.org, 1.debian.pool.ntp.org, 2.debian.pool.ntp.org y 3.debian.pool.ntp.org.
IP_GW Proveedor de SMS TCP 443 (Opcional) Conexión a las API de los proveedores de SMS soportadas por ** elementos cibernéticos ** Cleanroom.
Fuente (s) Destino (s) Puerto de destino (s) Comentarios (s)
IP_GW
IP_HTML5_GW		 IP_MED_WEB TCP 443 (si se utiliza el puerto estándar) Conexión con el sistema de emparejamiento Edge Gateway.
IP_GW
IP_HTML5_GW		 IP_MED_SSL TCP 443 (si se utiliza el puerto estándar) Conexión al enrutador SSL para establecer un túnel TLSv1.3 y enrutar las comunicaciones del producto a través de él.
Estación de trabajo del cliente IP_MED_WEB TCP 443 (si se utiliza el puerto estándar) Conexión a las distintas consolas web del producto.
Estación de trabajo del cliente IP_MED_SSL TCP 443 (si se utiliza el puerto estándar) Establecer un túnel TLS para cifrar el flujo que pasa a través de la cibernéticoLos elementos Cleanroom El cliente.
Estación de trabajo del administrador IP_MED_WEB Conexión TCP 22 SSH al servidor Mediation Controller.
Fuente Destino Puerto de destino Comentarios
IP_GW Servidor de DNS UDP 53 y Se requiere para la resolución de DNS. Opcional si se utiliza un servidor DNS para la WAN o la DMZ.
IP_GW Servidores LDAP o AD TCP 389 o 636 cibernéticoLos elementos Cleanroom conexión a un servidor LDAP o AD.
IP_GW Servidores AD TCP 139 y 445 Rotación de contraseñas de cuentas AD, utilizada sólo si no es posible la rotación a través de LDAPS.
IP_GW Servidores de RDP TCP/UDP 3389 (si se utiliza el puerto estándar) Conexión desde cibernéticoLos elementos Cleanroom a los servidores RDP.
IP_GW servidores SSH TCP 22 (si se utiliza el puerto estándar) Conexión desde ** elementos cibernéticos ** Cleanroom a servidores SSH.
IP_GW servidores VNC TCP 5900 (si se utiliza el puerto estándar) Conexión desde ** elementos cibernéticos ** Cleanroom a servidores VNC.
IP_GW Servidores web TCP 80 o 443 (si se utiliza el puerto estándar) Conexión desde cibernéticoLos elementos Cleanroom a los servidores web.
IP_GW Servidores de tienda de Citrix TCP 443 (si se utiliza el puerto estándar) Conexión desde cibernéticoLos elementos Cleanroom a los servidores de las tiendas Citrix.
IP_GW Servidores de aplicaciones Citrix El TCP 1494 Conexión desde cibernéticoLos elementos Cleanroom a los servidores de aplicaciones Citrix (lanzamiento de una aplicación o escritorio con el cliente ICA).
IP_GW Servidores de archivos TCP 139 y 445 Conexión desde ** elementos cibernéticos ** Cleanroom a servidores de archivos.
IP_GW Servidor de base de datos TCP 1433, 5432 o cualquier otro puerto personalizado Se requiere si desea utilizar una base de datos externa ubicada en la LAN (por ejemplo, para transferir la base de datos de Vault).
IP_GW Servidores de RDP TCP 139 y 445 Desarrollo del agente de registro a través de la consola de administración.
Estación de trabajo cliente IP_GW TCP [puerto definido por el administrador] Conexión de acceso SSH directa.
Estación de trabajo cliente IP_GW TCP 3389 Conexión de acceso RDP directa.
Servidores RDP IP_GW TCP 8443 Conexión entre el agente de grabación y el Edge Gateway para cargar la grabación de la sesión del usuario.
Estación de trabajo del administrador IP_GW Conexión TCP 22 SSH al servidor Edge Gateway.

Base de datos

cyberelements Cleanroom utiliza diferentes bases de datos (DB) para su funcionamiento.

  1. Base de datos de configuración del sistema. Esta base de datos se utiliza para almacenar todas las configuraciones de la interfaz de administración /system. En una instalación independiente, esta base de datos es creada y administrada directamente por el producto utilizando un servidor PostgreSQL instalado en el servidor Mediation Controller.
  2. Cada organización creada en el Mediation Controller La base de datos de la organización se encuentra en el servidor de la base de datos de la organización. Mediation Controller El servidor de datos de la red de datos de la red de datos de la red de datos de la red de datos de la red de datos de la red de datos de la red de datos de la red de datos de la red de datos de la red de datos de la red de datos de la red de datos de la red de datos de la red de datos de la red de datos de la red de datos de la red de datos de la red de datos de la red de datos de la red.
  3. Cada organización creada activa la creación de un DB específico para el vault de producto, que se almacena por defecto en el Mediation Controller Esta base de datos puede ser externalizada a la red local siempre que se disponga de un servidor de Edge Gateway puede acceder a ella.

Cuando se utilicen bases de datos externas, los tipos de base de datos admitidos son:

Licencia

El servidor Mediation Controller requiere una licencia para funcionar.
La licencia puede obtenerse de Systancia utilizando el siguiente formulario de solicitud de licencia: Solicitar una licencia

Certificados

El servidor /// tab | Mediation Controller Este servidor utiliza cuatro certificados diferentes:

  • Un certificado web para habilitar el HTTPS.
  • Un certificado para el componente del enrutador SSL responsable de la creación de túneles TLS y del enrutamiento del tráfico entre ellos.
  • Un certificado para el componente Watchdog responsable del control del buen funcionamiento del enrutador SSL.
  • Un certificado para el cliente cyberelements Cleanroom que le permita conectarse al enrutador SSL y establecer un túnel TLSv1.3.

Certificado web

Certificado de enrutador SSL

Certificado de perro guardián

cyberelements Cleanroom certificado de cliente

///

Este servidor utiliza dos certificados diferentes:

  • Un certificado para autenticar el componente Edge Gateway con el enrutador SSL.
  • Un certificado para el servicio de registro para que los agentes de registro puedan conectarse a él.

Info

Un Edge Gateway servidor puede tener múltiples Edge Gateway En el caso de los certificados de calidad, el número de certificados que se requieren es el número de Edge Gateway las instancias (excepto en el caso específico de la arquitectura de clúster).

Sin embargo, un Edge Gateway El servidor tiene un solo servicio de grabación, por lo que sólo se requerirá un certificado por máquina.

Edge Gateway Certificado

Certificado de servicio de registro

Este servidor utiliza un único certificado: el que se utiliza para autenticar el componente de la puerta de enlace HTML5 con el enrutador SSL.

Info

Un servidor de puerta de enlace HTML5 puede tener múltiples instancias de puertas de enlace HTML5, que requieren tantos certificados como instancias de puertas de enlace HTML5 (excepto en el caso específico de la arquitectura de clúster).

Certificado de puerto HTML5

El certificado de la pasarela HTML5 debe cumplir las siguientes restricciones para sus atributos:

  • El período de validez del certificado no podrá exceder de 1095 días (3 años).
  • La función hash utilizada para la firma debe ser parte de la familia SHA-2; recomendamos SHA-512.
  • El certificado y los certificados de sus autoridades de certificación deben tener una clave privada de al menos 2048 bits con cifrado RSA, DSA y DH; para las claves de curva elíptica (ECC), deben ser al menos 224 bits. Recomendamos un tamaño de 4096 bits para RSA y un tamaño de curva ECDSA secp384r1 de 384 bits.
  • El Common Name atributo debe tener un valor que identifique el lógico Edge GatewayEste nombre tiene la siguiente forma: <HTML5_GW_NAME>@<ORGANIZATION_NAME>, donde <HTML5_GW_NAME> corresponde al nombre del Edge Gateway (como se introduce en la consola de administración) y <ORGANIZATION_NAME> corresponde al nombre de la organización a la que se refiere el Edge Gateway se conectará.
  • El Key Usage el atributo debe tener los valores critical y digitalSignature.
  • El Extended Key Usage el atributo debe tener el valor clientAuth.

El formato del certificado aceptado es P12.

--8<-- [fin del certificado]

--8<-- [Comienzo: registro directo del certificado]

El certificado deberá cumplir las siguientes restricciones en cuanto a sus atributos:

  • El período de validez del certificado no podrá exceder de 1095 días (3 años).
  • La función hash utilizada para la firma debe ser parte de la familia SHA-2; recomendamos SHA-512.
  • El certificado y los certificados de sus autoridades de certificación deben tener una clave privada de al menos 2048 bits con cifrado RSA, DSA y DH; para las claves de curva elíptica (ECC), deben ser al menos 224 bits. Recomendamos un tamaño de 4096 bits para RSA y un tamaño de curva ECDSA secp384r1 de 384 bits.
  • El Common Name Este atributo debe tener un valor que sea el nombre abreviado, FQDN, o cualquier otro nombre que identifique de manera única la máquina.
  • El Key Usage el atributo debe tener los valores critical y digitalSignature.
  • El Extended Key Usage el atributo debe tener el valor clientAuth.

El formato del certificado aceptado es P12.

--8<-- [fin: certificado-grabación directa]

Para el funcionamiento de acceso directo, el agente de registro directo utiliza un certificado para autenticarse con el servicio de registro de un Edge Gateway.