Un poco de historia
Después de una conferencia sobre HighLoad ++ 2017. Miré este informe, "Cómo despedimos al administrador", en la grabación. El orador dijo que todas las compañías web tienen problemas con las contraseñas, y tuve una idea de cómo resolver esto. Lo más probable es que alguien ya lo haya hecho, pero para ser honesto, no lo sé, solo quiero describirlo, entonces tal vez alguien lo haga o de alguna manera lo haré yo mismo. Espero que si alguien decide hacer algo como esto, sea de código abierto.
En realidad, una descripción del problema y cómo resolverlo.
¿Cuál es el problema, por extraño que sea en las contraseñas mismas, o más bien, para que los empleados sin escrúpulos no las retiren de la empresa?
Hay dos opciones para resolver este problema.
- Publique todos los cambios en el sitio personalmente al jefe de la empresa.
- Inventar y hacer algo.
En general, actuamos sobre la segunda opción. El primero es difícil y costoso si la empresa está compuesta por un pequeño número de personas.
Lo que hay que hacer está decidido, ahora debe decidir cómo hacerlo.
Aquí a la vez la idea más simple, ¿por qué no hacer un proxy? Bueno, lo más probable es un super proxy. El esquema de trabajo es básicamente simple y lo dibujé a continuación.
Figura 1 - Esquema general del sistemaComo se puede ver en el diagrama y la idea en sí, el elemento principal aquí será un servidor proxy.
Sus tareas son las siguientes:
- En consecuencia, acepte el tráfico, o incluso trabaje a nivel de los comandos SSH y SFTP, para empezar, y envíe una respuesta del servidor del cliente a un especialista.
- Autenticación y autorización de un especialista.
- Verificando la legitimidad de los equipos, esto se puede hacer más tarde.
La estructura del servidor proxy en sí será la siguiente:
Figura 2 - Diagrama de bloques del componente superproxyProxy: tráfico proxy directo a través de SSH, (S) FTP, HTTP, HTTPS
CA (Control de acceso): controla el acceso especializado a los recursos del cliente.
SAP (Sever Admin Panel): directamente el servidor con el que el administrador se comunica a través del panel de control.
Núcleo: el núcleo del sistema en sí mismo es la gestión de solicitudes entre módulos y gestión de modelos.Creo que el acceso debe abordarse por separado, porque todo se inició debido a esto.
Todos los usuarios están incluidos en las políticas de grupo, las políticas de grupo definen reglas para el acceso a los servidores del cliente, así como las reglas a las que los administradores del sistema obedecen. Las políticas grupales tienen una estructura jerárquica, cada nivel superior tiene sus propios poderes como el nivel inferior. Desde el principio existe una política '.', Que incluye todos los permisos para todo y puede incluir un usuario, el administrador principal. Luego hay dos grupos para políticas, administradores de sistemas y proyectos.
Tabla dinámica: administradores y sus derechos| Título del rol | Derechos de acceso | |
|---|
| Administrador de directivas de grupo | Edición de usuarios grupales | |
| Administrador de directivas de grupo | Crear política de grupo | Crear eliminar y editar usuarios en la directiva de grupo |
| Administrador de gestión de usuarios | Eliminar un usuario de la Política de grupo | Crear eliminar y editar usuarios |
| Administrador de respaldo | Leer información sobre usuarios y administradores | Lectura de entradas de políticas grupales |
| Administrador jefe | Todo lo demás, además de editar y eliminar políticas de grupo | Forzar cambios de contraseña en servidores cliente |
Las propias políticas de grupo contienen un registro de servidor al que se aplica esta política.
Y los usuarios tienen las siguientes reglas, que se establecen para cada usuario o grupo por separado, de hecho, estos son valores booleanos que determinan si el objeto tiene acceso HTTP / HTTPS al panel de control de recursos (panel de administración), SFTP / FTP, acceso SSH.
Ahora algunas palabras sobre el panel de control y el cliente.
El panel de control o todo está claro, pero debe volver a escribir, eso estaría claro.
Panel de control Directamente necesario para administrar las políticas de grupo y el servidor en su conjunto, un super proxy. Distribuido como una aplicación independiente o servicio web.
En consecuencia, los administradores tienen acceso al panel de control.
El cliente es simple en apariencia, complejo por dentro.
El cliente necesita una aplicación, en el caso de HTTP (S), teóricamente, esta aplicación puede ser un navegador configurado directamente para funcionar a través de un servidor proxy, y nuestro servidor proxy tendrá que meterse en el tráfico. En general, lo más probable es que sea necesario desarrollar una aplicación separada que funcione a través de SSH, (S) FTP, HTTP (S), con servidores cliente, a través de nuestro servidor superproxy, o incluso será más fácil de instalar y comunicarse con el servidor del cliente en sí es un servidor superproxy, y en el cliente instalado en la computadora, todo el proceso simplemente será emulado por especialistas.
Considere el ejemplo de HTTP (S).
- El cliente envía una solicitud de comunicación con el cliente al servidor proxy.
- El servidor super proxy lo permite o no, si lo permite, el propio servidor super proxy levanta la conexión e inicia sesión en el panel de control.
- El servidor proxy estupendo recibe directamente la página principal del panel de administración.
- El super servidor proxy pasa esta página al cliente, reemplazando la dirección del recurso del cliente con un marcador especial.
- El especialista sigue los enlaces o rellena los campos en el navegador y envía el formulario. Los datos van a un servidor super proxy.
- El servidor super proxy reemplaza los tokens de nuevo a la dirección del recurso del cliente y, en consecuencia, lo envía directamente al recurso del cliente.
Con el trabajo en SSH, puede transferir texto puro. Y directamente desde el servidor superproxy al recurso del cliente, se eleva una conexión SSH normal.
Algo como esto Espero sus comentarios en los comentarios y enlaces a los repositorios, si alguien decide hacer un sistema de este tipo.