Productos secos 丨 gestión de autoridad y seguridad de DolphinDB

La base de datos DolphinDB proporciona un sistema de control de acceso potente, flexible y seguro. El controlador, como centro de gestión de la autoridad, utiliza el cifrado RSA para cifrar la información clave del usuario.

La función principal:

Proporcionar roles de usuarios y grupos para facilitar el control de acceso
Proporcione 8 tipos de control de permisos para adaptarse a varios escenarios
Ricas funciones de control de acceso
La vista de funciones se encarga de proteger la privacidad de los datos y proporcionar resultados de análisis
Autenticación dinámica de tareas de programación de tareas y transmisión de datos para garantizar la seguridad del sistema
Utilice RSA para cifrar la información clave del usuario
Admite SSO, simplifica el inicio de sesión y facilita la expansión del sistema

1. Resumen de permisos

1.1 Usuarios y grupos

Los usuarios y los grupos son entidades que tienen permisos. Un usuario puede pertenecer a varios grupos y un grupo también puede incluir varios usuarios.

Al introducir el concepto de grupos, puede configurar y administrar fácilmente los permisos para usuarios con los mismos permisos. Los permisos reales finales de los usuarios son los permisos de los propios usuarios, más los permisos de los grupos a los que pertenecen.

1.2 Administrador del sistema

Cuando el clúster DolphinDB se inicia por primera vez, creará automáticamente un administrador del sistema con el nombre de usuario "admin" y la contraseña "123456". Este administrador tiene todos los permisos, como crear o eliminar bases de datos, leer y escribir todas las tablas, crear o eliminar tablas de datos en la base de datos, usar todas las vistas de funciones, ejecutables o scripts de prueba. Este administrador puede crear o eliminar otros administradores. Una vez que se acaban de crear otros administradores, pueden crear o eliminar otros administradores, usuarios o grupos, pero no tienen ningún otro permiso. Los administradores pueden autorizarse a sí mismos o entre sí. Tenga en cuenta que el administrador "admin" no se puede eliminar.

El administrador puede usar las funciones o comandos createUser, deleteUser, createGroup, ddeleteGroup, addGroupMember, dlelteGroupMember, getUserAccess, getUserList, getGroupList, resetPwd para realizar operaciones convenientes en usuarios y grupos.

1.3 Categoría de permiso

DolphinDB proporciona los siguientes 8 tipos de permisos:

TABLE_READ: leer datos de la tabla de datos especificada
TABLE_WRITE: escribe datos en la tabla de datos especificada
DBOBJ_CREATE: crea un objeto (tabla de datos) en la base de datos especificada
DBOBJ_DELETE: Elimina el objeto (tabla de datos) en la base de datos especificada
VIEW_EXEC: Vista de función de ejecución
DB_MANAGE: crear y eliminar bases de datos
SCRIPT_EXEC: ejecutar archivo de script
TEST_EXEC: ejecutar prueba unitaria

Entre ellos, los primeros 5 tipos deben proporcionar objetos de operación y los últimos 3 tipos no necesitan proporcionar objetos de operación.

Tenga en cuenta que las bases de datos y las tablas de datos involucradas en la configuración de permisos están todas establecidas en el Sistema de archivos distribuido (DFS).

1.4 Configuración de permisos

Solo el administrador puede establecer permisos y solo puede realizar operaciones de permisos en el nodo de control. No se ha concedido ni prohibido ningún permiso al usuario o grupo recién creado. Los administradores pueden usar comandos de concesión / denegación / revocación para establecer los permisos de usuarios o grupos. Los 8 permisos en 1.3 se pueden usar como el valor del parámetro accessType de estos tres comandos.

Los siguientes dos ejemplos ilustran el funcionamiento de la configuración de permisos.

Ejemplo 1

Inicio de sesión de administrador:

login(`admin, `123456)

Crear usuario NickFoles:

createUser("NickFoles","AB123!@")

Otorgue al usuario NickFoles el permiso para leer cualquier tabla de datos DFS:

grant("NickFoles",TABLE_READ,"*")

Evite que el usuario NickFoles cree o elimine bases de datos:

deny("NickFoles",DB_MANAGE)

Cree el grupo SBMVP y agregue el usuario NickFoles al grupo:

createGroup("SBMVP", "NickFoles")

Otorgue permiso al grupo SBMVP para crear tablas de datos en las bases de datos "dfs: // db1" y "dfs: // db2":

grant("SBMVP",DBOBJ_CREATE,["dfs://db1","dfs://db2"])

Por último, los permisos del usuario NickFoles son: puede acceder a todas las tablas de datos, no puede crear ni eliminar bases de datos y puede crear tablas de datos en dfs: // db1 y dfs: // db2.

Ejemplo 2

Los permisos de usuario se pueden configurar fácilmente a través de grupos:

createUser("EliManning", "AB123!@")  
createUser("JoeFlacco","CD234@#")  
createUser("DeionSanders","EF345#$")  
createGroup("football", ["EliManning","JoeFlacco","DeionSanders"])  
grant("football", TABLE_READ, "dfs://TAQ/quotes")  
grant("DeionSanders", DB_MANAGE)

Este ejemplo crea 3 usuarios y 1 grupo, y estos tres usuarios pertenecen al grupo. Otorgue a este grupo de tablas de datos legibles los permisos dfs: // TAQ? Quotes y solo otorgue al usuario permisos DeionSanders para crear y eliminar bases de datos.

Ejemplo 3

Puede utilizar otorgar o denegar para otorgar o denegar permisos a todos los objetos (representados por *). Por ejemplo, para darle al usuario JoeFlacco el permiso para leer cualquier tabla de datos DFS:

grant("JoeFlacco",TABLE_READ,"*")

Al usar otorgar o denegar todos los objetos, solo puede usar revocar para todos los objetos. Si revocar no es válido para un solo objeto:

revoke("JoeFlacco",TABLE_READ,"dfs://db1/t1")

El comando anterior no es válido.

revoke("JoeFlacco",TABLE_READ,"*")

El comando anterior cancela el permiso del usuario JoeFlacco para leer cualquier tabla de datos DFS.

De manera similar, después de usar otorgar o denegar para otorgar o rechazar permisos a un grupo, solo puede usar revocar en el reagrupamiento para cancelar la configuración de permisos. Si se utiliza revocar para que un miembro del grupo cancele la configuración de permisos, no es válido.

1.5 Reglas de determinación de autoridad

La autoridad final del usuario está determinada por la propia autoridad del usuario y la autoridad de todos los grupos a los que pertenece. Diferentes grupos pueden entrar en conflicto con las reglas de un determinado usuario y cierta autoridad. Las siguientes son reglas para determinar los permisos:

Si a un usuario se le concede un permiso determinado en al menos un grupo, y el permiso no está prohibido en ningún grupo, el usuario tiene este permiso.
Si un usuario tiene un permiso determinado en al menos un grupo, incluso si el usuario tiene este permiso en otros grupos, el permiso también está prohibido. En este caso, si el usuario desea obtener este permiso, el administrador debe usar revocar o conceder en todos los grupos que prohíben el permiso para cancelar estas prohibiciones de permisos, y el usuario recibe este permiso en al menos un grupo. Tenga en cuenta que, en las reglas anteriores, para facilitar la descripción, los propios usuarios también pueden considerarse un grupo especial.

createUser("user1","123456")  
createUser("user2","123456")  
createGroup("group1")  
createGroup("group2")  
addGroupMember(["user1","user2"],"group1")
addGroupMember(["user1","user2"],"group2")
grant("user1",TABLE_READ,"*")  
deny("group1",TABLE_READ,"dfs://db1/t1")  
deny("group2",TABLE_READ,"dfs://db1/t2")

El resultado de las tres líneas anteriores es que el usuario user1 puede leer todas las tablas de datos excepto "dfs: // db1 / t1" y "dfs: // db1 / t2".

grant("user2",TABLE_WRITE,"*")  
deny("group1",TABLE_WRITE,"*")  
grant("group2",TABLE_WRITE,"dfs://db1/t2")

El resultado de las tres líneas anteriores es que los usuarios user1 y user2 no pueden escribir datos en ninguna tabla de datos.

1.6 Control de permisos basado en la vista de funciones

La vista de función proporciona una forma flexible de controlar el acceso del usuario a la tabla de datos, lo que permite a los usuarios obtener la información generada por la vista de función sin dar permiso al usuario para leer todos los datos originales en la tabla de datos. Solo el administrador del sistema tiene la autoridad para crear y eliminar vistas de funciones.

El administrador define una vista de funciones:

def countTradeAll(){  
	return exec count(*) from loadTable("dfs://TAQ","Trades")  
}
addFunctionView(countTradeAll)  
grant("NickFoles",VIEW_EXEC,"countTradeAll")

Inicie sesión con el nombre de usuario NickFoles y ejecute la vista countTradeAll

countTradeAll()

Aunque el usuario NickFoles no tiene acceso a la tabla "dfs: // TAQ / Trades", puede ejecutar la vista de funciones en este ejemplo para obtener el número de filas en la tabla.

La vista de funciones también puede tomar parámetros. El usuario puede ingresar los parámetros para obtener el resultado correspondiente al usarlo. En el siguiente ejemplo, creamos una vista de función para obtener todos los registros de transacciones de una determinada acción en un día determinado.

def getTrades(s, d){
	return select * from loadTable("dfs://TAQ","Trades") where sym=s, date=d
}
addFunctionView(getTrades)
grant("NickFoles",VIEW_EXEC,"getTrades")

Inicie sesión con el nombre de usuario NickFoles y especifique el código bursátil y la fecha en la vista de ejecución getTrades:

getTrades("IBM", 2018.07.09)

2. Programación de programas y control de permisos en la informática de transmisión

La programación del programa y la computación de flujo se ejecutan en segundo plano. En muchos casos, no hay un inicio de sesión explícito, por lo que la verificación de permisos es algo diferente del caso del inicio de sesión explícito del usuario. Ambos tipos de tareas en segundo plano se ejecutan como el usuario que creó la tarea.

2.1 Configuración de permisos de trabajos de programación

La programación del programa significa que los usuarios especifican ejecutar una serie de tareas en un momento específico y con una frecuencia específica, que se utiliza principalmente para escenarios comerciales de procesamiento por lotes.

login("NickFoles","AB123!@")  
def readTable(){  
	read_t1=loadTable("dfs://db1","t1")  
	return exec count(*) from read_t1  
}  
scheduleJob("readTableJob","read DFS table",readTable,minute(now()),date(now()),date(now())+1,'D');

Independientemente de si NickFoles tiene permiso para leer "dfs: // db1 / t1", la tarea readTable se puede configurar correctamente.

Cuando la tarea readTable se está ejecutando, si el usuario NickFoles tiene permiso para leer "dfs: // db1 / t1", se ejecutará con éxito, de lo contrario, la autenticación fallará.

Además, al utilizar el comando deleteScheduleJob, el administrador del sistema puede eliminar tareas creadas por otros usuarios, y los usuarios que no son administradores solo pueden eliminar tareas creadas por ellos mismos.

2.2 configuración de permisos de transmisión

Cuando un usuario usa la función subscribeTable para suscribirse a datos en tiempo real de una tabla de datos de transmisión y guardarlos en la tabla de datos, debe confirmar que tiene permiso para escribir en esta tabla de datos.

login("NickFoles","AB123!@")
def saveTradesToDFS(mutable dfsTrades, msg): dfsTrades.append!(select today() as date, * from msg)  
subscribeTable("NODE1", "trades_stream", "trades", 0, saveTradesToDFS{trades}, true, 1000, 1)

En el ejemplo anterior, la tarea de procesamiento de datos de transmisión guarda los datos recibidos en la tabla de datos dfsTrades. Cuando se ejecuta esta tarea de procesamiento de datos de flujo, el sistema identificará dinámicamente si NickFoles tiene permiso para escribir en la tabla de datos dfsTrades; de lo contrario, la autenticación fallará.

3. Utilice HTTPS para lograr una comunicación segura

DolphinDB admite el uso del protocolo de seguridad HTTPS para comunicarse con la web.

3.1 Habilitar la configuración HTTPS

Dos formas de configurar HTTPS:

Agregue enableHTTPS = true al archivo de configuración del nodo de control
Agregue -enableHTTPS true a la línea de comando para iniciar el nodo de control

3.2 Configuración del certificado HTTPS

DolphinDB utiliza una política de seguridad de verificación de certificados del lado del servidor. De forma predeterminada, se generará un certificado de fabricación propia y el cliente debe instalar el certificado del servidor; de lo contrario, el navegador solicitará una conexión insegura. Cada servidor físico necesita un certificado, por lo que el nodo de control y el nodo proxy necesitan generar un certificado, y el nodo de datos usa el certificado generado por el nodo proxy en el mismo servidor físico. Los usuarios también pueden adquirir certificados certificados por terceros.

3.2.1 Certificación de terceros

Cambie el nombre del certificado de terceros a server.crt y cópielo en la carpeta de claves en el directorio de inicio del nodo de control y del nodo de agente. Si la carpeta de claves no existe, debe crearla manualmente. Dado que el certificado de terceros lo emite una autoridad reconocida, el navegador confía en el certificado de forma predeterminada y no es necesario instalarlo manualmente. Este método es adecuado para la mayoría de los escenarios de aplicación.

3.2.2 Instalar certificado hecho por uno mismo

Al comunicarse dentro de un pequeño clúster cerrado, los usuarios también pueden utilizar un certificado de fabricación propia para la comunicación segura de OPENSSL, pero instalar un certificado de fabricación propia es un poco engorroso. El proceso específico es el siguiente:

Establecer publicName Debido a que es necesario conocer el nombre de dominio de la computadora para generar el certificado, establezca esta opción en el nombre de dominio de la computadora para el servidor físico que necesita generar el certificado, que se puede configurar en la línea de comandos o en el archivo de configuración . El siguiente es un ejemplo de una línea de comando para iniciar el nodo de control en Linux. Aquí http://www.ABCD.com es el nombre de dominio de la computadora donde se encuentra el nodo de control.

./dolphindb -enableHTTPS true -home master -publicName www.ABCD.com -mode controller -localSite 192.168.1.30:8500:rh8500 -logFile  ./log/master.log

2. Verifique si el certificado se generó correctamente
Inicie el nodo de control y verifique si hay un archivo de certificado hecho por usted mismo server.crt y un archivo de clave privada serverPrivate.key en la carpeta de claves en el directorio de inicio .

3. Instale el certificado hecho por usted mismo en el centro de certificados de crédito del navegador. Las diferentes opciones de instalación del navegador son ligeramente diferentes. Tome Google Chrome como ejemplo. Seleccione Configuración-> Avanzado-> Administrar certificados-> AUTORIDADES-> Importar e importar el servidor generado archivo .crt anterior.

Ingrese https://www.XXXX.com:8500/ en el navegador para acceder al administrador de clústeres. Si se muestra un pequeño candado verde en la barra de direcciones del navegador, significa que el certificado se instaló correctamente y es posible el acceso HTTPS.

4. Admite SSO (inicio de sesión único)

En la interfaz de administración del clúster, puede hacer clic en cualquier nodo de datos para vincularlo al cuaderno de ese nodo. Salte del nodo de control al nodo de datos, es posible que se acceda a un servidor físico diferente (acceso entre dominios). DolphinDB proporciona SSO para que los usuarios no tengan que volver a iniciar sesión en el sistema cuando acceden a diferentes servidores físicos durante las operaciones del clúster.

DolphinDB proporciona dos funciones de API para SSO:

getAuthenticatedUserTicket () Obtiene el ticket cifrado del usuario actualmente conectado
authenticateByTicket (ticket) Utilice el ticket obtenido anteriormente para iniciar sesión en el sistema

Los desarrolladores de DolphinDB pueden utilizar estas interfaces de forma fácil y segura para ampliar el sistema.