Um pouco de fundo
Após uma palestra sobre o HighLoad ++ 2017. Olhei para este relatório, “Como demitimos o administrador”, na gravação. O palestrante disse que todas as empresas da web têm problemas com senhas, e eu tive uma idéia de como resolver isso. Provavelmente alguém já fez isso, mas para ser sincero, não sei, só quero descrever, então talvez alguém faça ou eu mesmo faça. Espero que, se alguém decidir fazer algo assim, será de código aberto.
Na verdade, uma descrição do problema e como resolvê-lo
Qual é o problema, por mais estranho que seja nas próprias senhas, ou melhor, para que funcionários inescrupulosos não as tirem da empresa.
Existem duas opções para resolver esse problema.
- Poste todas as alterações no site pessoalmente no chefe da empresa.
- Inventar e fazer alguma coisa.
Em geral, agimos na segunda opção. O primeiro é difícil e dispendioso se a empresa é composta por um pequeno número de pessoas.
O que fazer é decidido, agora você precisa decidir como fazê-lo.
Aqui, ao mesmo tempo, a idéia mais simples, por que não fazer um proxy? Bem, provavelmente um super proxy. O esquema de trabalho é basicamente simples e desenhei abaixo.
Figura 1 - Esquema geral do sistemaComo pode ser visto no diagrama e na própria ideia, o elemento principal aqui será um servidor proxy.
Suas tarefas são as seguintes:
- Da mesma forma, aceite o tráfego ou trabalhe no nível dos comandos SSH e SFTP para iniciantes e envie uma resposta do servidor do cliente a um especialista.
- Autenticação e autorização de um especialista
- Verificando a legitimidade das equipes, isso pode ser feito posteriormente.
A estrutura do servidor proxy em si será a seguinte:
Figura 2 - Diagrama de blocos do componente super proxyProxy - tráfego de proxy diretamente sobre SSH, (S) FTP, HTTP, HTTPS
CA (acesso de controle) - controla o acesso de especialistas aos recursos do cliente.
SAP (Sever Admin Panel) - Diretamente o servidor com o qual o administrador se comunica através do painel de controle.
Núcleo - O núcleo do sistema em si é gerenciar solicitações entre módulos e gerenciamento de modelos.Acredito que o acesso deve ser tratado separadamente, porque tudo foi iniciado por causa disso.
Todos os usuários estão incluídos nas políticas de grupo, as políticas de grupo definem regras para acesso aos servidores clientes, bem como regras às quais os administradores de sistema obedecem. As políticas de grupo têm uma estrutura hierárquica, cada nível superior tem seus mesmos poderes que o nível inferior. Desde o início, existe uma política '.', Que inclui todas as permissões para tudo e pode incluir um usuário, o administrador principal. Depois, existem dois grupos para políticas, administradores de sistema e projetos.
Tabela dinâmica - administradores e seus direitos| Título da função | Direitos de acesso | |
|---|
| Administrador de Diretiva de Grupo | Edição de usuários em grupo | |
| Administrador de Diretiva de Grupo | Criar diretiva de grupo | Criando Exclusão e Edição de Usuários na Diretiva de Grupo |
| Administrador de gerenciamento de usuários | Removendo um usuário da Diretiva de Grupo | Criar excluir e editar usuários |
| Administrador de backup | Lendo informações sobre usuários e administradores | Lendo entradas de diretiva de grupo |
| Administrador-chefe | Tudo o resto, além de editar e excluir políticas de grupo | Forçar alterações de senha nos servidores clientes |
As próprias políticas de grupo contêm um registro do servidor ao qual essa política é aplicada.
E os usuários têm as seguintes regras, que são prescritas para cada usuário ou grupo separadamente; na verdade, esses são valores booleanos que determinam se um objeto tem acesso via HTTP / HTTPS ao painel de controle de recursos (painel de administração), acesso via SFTP / FTP, SSH.
Agora, algumas palavras sobre o painel de controle e o cliente.
O painel de controle ou tudo está claro, mas você precisa escrever novamente, isso ficaria claro.
Painel de controle Necessário diretamente para gerenciar diretivas de grupo e o servidor como um todo, um super proxy. Distribuído como um aplicativo ou serviço da web independente.
Consequentemente, os administradores têm acesso ao painel de controle.
O cliente é simples na aparência, complexo por dentro.
O cliente precisa de um aplicativo, no caso do HTTP (S), puramente teoricamente, esse aplicativo pode ser um navegador configurado diretamente para funcionar através de um servidor proxy, e nosso servidor proxy terá que se inserir no tráfego. Em geral, provavelmente, será necessário desenvolver um aplicativo separado que funcione via SSH, (S) FTP, HTTP (S), com servidores clientes, por meio de nosso servidor super proxy, ou será ainda mais fácil instalar e se comunicar com eles. o próprio servidor do cliente é um servidor super proxy e, no cliente instalado no computador, todo o processo será simplesmente emulado por especialistas.
Considere o exemplo de HTTP (S).
- O cliente envia uma solicitação de comunicação com o cliente para o servidor proxy.
- O servidor super proxy permite ou não, se permitir, o próprio servidor super proxy aumenta a conexão e efetua login no painel de controle.
- O servidor super proxy recebe diretamente a página principal do painel de administração.
- O servidor super proxy envia esta página para o cliente, substituindo o endereço do recurso do cliente por um marcador especial.
- O especialista segue os links ou preenche os campos do navegador e envia o formulário. Os dados vão para um super servidor proxy.
- O servidor super proxy substitui os tokens de volta ao endereço do recurso do cliente e, portanto, envia-os diretamente para o próprio recurso do cliente.
Com o trabalho no SSH, você pode transferir texto puro. E diretamente do servidor super-proxy para o recurso do cliente, uma conexão SSH normal aumenta.
Algo assim. Aguardo seus comentários nos comentários e links para os repositórios, se alguém decidir criar esse sistema.