Entidad de certificados raíz de QueryGrid Manager
Se puede instalar una instancia de QueryGrid Manager en uno o varios TMS, VM o servidores. Cuando se instala la primera instancia de QueryGrid Manager, QueryGrid Manager genera una entidad emisora de certificados raíz (CA). Si se instalan instancias adicionales de QueryGrid Manager y todas ellas se agrupan en un clúster, la CA raíz generada por la primera instancia de QueryGrid Manager se usa para todo el clúster.
La CA raíz firma los certificados SSL para cada instancia de QueryGrid Manager.
Certificados SSL de QueryGrid Manager
- Instancias adicionales de QueryGrid Manager en el mismo clúster
- Nodos de origen de datos en un sistema
- Viewpoint
- Navegador a documentos de la API de REST de QueryGrid Manager
- Clientes de REST
Cuando se agrega un nodo de origen de datos a un sistema de origen de datos en QueryGrid, una instancia de QueryGrid Manager proporciona al nodo un certificado SSL durante la instalación del software de nodo. El certificado SSL, que está firmado por la CA raíz, permite que el nodo de origen de datos compruebe que se está comunicando con una instancia de QueryGrid Manager de confianza.
Toda la comunicación entre las instancias de QueryGrid Manager y los nodos de origen de datos en el tejido usan HTTPS a través del puerto 9444.
Cuentas de servicio de QueryGrid Manager
Las cuentas de servicio de QueryGrid Manager proporcionan acceso a las API de llamada de QueryGrid Manager. Estas cuentas son internas de QueryGrid Manager y no corresponden a ninguna cuenta de usuario de base de datos o del sistema operativo. Las cuentas de servicio solo proporcionan acceso a datos de configuración y supervisión de QueryGrid.
Las cuentas de servicio denominadas viewpoint y support se crean automáticamente con contraseñas predeterminadas cuando se inicia QueryGrid Manager por primera vez. Teradata recomienda encarecidamente cambiar la contraseña predeterminada de estas cuentas. Para obtener más información sobre el cambio de contraseñas, consulte Cambio de una contraseña de cuenta de servicio, o Restablecimiento de una contraseña de cuenta de servicio si ha olvidado la contraseña.
Las cuentas de servicio se bloquean durante 30 minutos si se realizan 3 intentos de inicio de sesión erróneos en un lapso de 15 minutos debido a una contraseña incorrecta. Ejecute /opt/teradata/tdqgm/bin/unlock-account.sh para desbloquear la cuenta de inmediato.
Autenticación y registro de nodos de origen de datos
Elemento | Descripción |
---|---|
UUID | Actúa como el nombre de usuario del nodo cuando el nodo se autentica para una instancia de QueryGrid Manager. |
Token de acceso de tiempo limitado | Autentica el nodo para poder agregarlo a un origen de datos por primera vez. |
Contraseña generada para la autenticación | Permite que el nodo se autentique en una instancia de QueryGrid Manager después de que el nodo se una a un origen de datos por primera vez. |
Direcciones IP y verificación de nombre de host
Cuando se inicia la primera instancia de QueryGrid Manager, el certificado SSL generado contiene la dirección IP para el servidor, TMS o VM de QueryGrid Manager y los nombres de host conocidos por QueryGrid Manager para que los clientes puedan realizar la verificación del host.
Si a QueryGrid Manager acceden nombres de host o direcciones IP desconocidos, puede agregarlos al certificado SSL mediante la configuración de una propiedad de alias, que puede contener una lista separada por comas de nombres de host o direcciones IP. Los procedimientos para agregar alias se incluyen en los procedimientos de instalación de esta guía.
Transferencia de datos
- Un proceso de tejido se ejecuta en cada nodo asociado que ejecuta QueryGrid.
- El conector establece un canal con el nodo de tejido local para enviar y recibir datos.
- El tejido solo permite conexiones desde procesos de conectores locales en la lista allowed OS user definida en el conector.
- A partir de QueryGrid 2.15, los procesos de tejido se comunican mediante TLS 1.2+.
- Todos los datos se cifran de forma predeterminada y cada proceso de tejido genera un par de claves pública/privada que se utiliza para la autenticación mutua con otros procesos del tejido.
- La clave privada se mantiene en la memoria y la clave pública se envía y distribuye mediante QueryGrid Manager.
- Las claves rotan una vez a la semana.
Usuarios del sistema operativo
La seguridad también depende del usuario del sistema operativo (SO) que usa el software de conector. Puede especificar el usuario del SO para cada conector. El usuario suele ser el mismo usuario que el usuario del origen de datos.
Origen de datos | Usuario |
---|---|
Sistema Teradata | Usuario de Teradata |
Presto | usuario de Starburst |
Hive | el usuario que ejecuta la consulta (que puede ser hive), el usuario de yarn y el usuario que corresponda al principal de Kerberos u otro usuario autorizado |
Spark SQL | el usuario que ejecuta la consulta (que puede ser hive), el usuario de yarn y el usuario que corresponda al principal de Kerberos u otro usuario autorizado |
LDAP y Kerberos
Los mecanismos de seguridad admitidos para un conector de destino difieren para los conectores de Teradata, Presto y Hive. Para obtener información sobre los mecanismos de seguridad específicos para un origen de datos, consulte las secciones sobre seguridad de los conectores correspondientes.
Directrices generales de seguridad para QueryGrid
- Cambie las contraseñas predeterminadas de la cuenta de servicio de QueryGrid Manager durante la instalación. Los procedimientos se proporcionan en esta guía.
- Establezca los permisos apropiados en Viewpoint para limitar los usuarios que pueden editar la configuración de QueryGrid.
- Cree enlaces solo con los orígenes de datos de iniciador que se ejecuten en entornos seguros.
- Use la opción de seguridad adecuada para el entorno al especificar las directivas de comunicación para los enlaces.