Como posso revogar o acesso de um usuário em diferentes sistemas?

Question

Vamos deixar um de nossos administradores entrar em algumas semanas. Ele tem acesso a toda a nossa infraestrutura, então teremos que redefinir as senhas em tudo. Isso vai ser muito demorado, porém, com o número de servidores e dispositivos lá fora, teríamos que redefinir. Algumas coisas estão ligadas a domínios do Windows, o que é bastante fácil, mas problemático, dependendo de se algum serviço é executado como aquele usuário.

Existe alguma maneira de revogar facilmente o acesso a tudo para esse usuário? Eu acho que estou pedindo cross sign on single ... talvez o RADIUS possa fazer isso? Ou existe uma solução chave na mão, como o RSA SecureID? O que vocês tem usado?

    

Answer 1

Quando deixei meu último emprego, eles tiveram que passar pelo mesmo processo. Eu consegui ter acesso a praticamente todas as senhas semelhantes a root que tínhamos. Havia um mini-projeto para mapear tudo o que eu tinha acesso, e eu lhes dava listas de onde eu sabia que tinha acesso. Na semana passada, reduzi os direitos constantemente, pois várias senhas, ACLs e associações a grupos foram alteradas. Os caras da Telecom estavam me olhando mal, já que não tinham mudado sua senha em FAR, FAR por muito tempo e estavam tendo que fazer isso em cada dispositivo (alguns exigiam uma visita ao site); pelo menos eles aproveitaram essa oportunidade para implantar um sistema de senha central ao mesmo tempo. No meu último dia me pediram para passar o tempo tentando entrar em coisas para ver se conseguiram tudo. Na verdade, eles fizeram.

Isto é o que uma transferência educada de poder deve parecer no mundo SysAdmin.

    

Answer 2

Usamos o SecurID via Radius para controlar todo o acesso externo à rede. Isso significa limitar o número de pontos de acesso remoto ( linhas analógicas qualquer um? ) e garantir que aqueles que permanecem (1) usem a solução SecurID como um fator de autenticação (por SSH, RDP, webmail, etc) ou (2) estão em uma lista de verificação de procedimentos de rescisão (rodar a senha em "no caso de interrupção" caixa conectada em DSL, etc).

Acesso do lado de fora, assim garantido, você lida com a rotação de todas as senhas estáticas, limpeza de contas de usuário, etc. no interior.

Com relação a "dependendo se qualquer serviço é executado como aquele usuário" - a melhor prática seria que nada fosse executado no contexto de uma conta de usuário humano por essa mesma razão. Audite suas tarefas cron , at , etc agora e mova o que você puder para contas de serviço não humanas.

Não é uma tarefa fácil configurar seu ambiente para lidar com esse tipo de coisa de maneira elegante e, provavelmente, não é algo que você possa organizar nas próximas semanas.

    

Answer 3

Faça um registro de todos os seus sistemas com senhas de raiz estática, qual senha eles estão usando (esperamos que eles sejam distintos o suficiente para que você possa identificá-los sem revelá-los) e a data em que foram alterados pela última vez. Se puder, mude para usar várias senhas "raiz" de diferentes níveis - uma senha de baixo nível que não seja usada para dispositivos externos não precisará necessariamente ser alterada se esses dispositivos estiverem usando uma senha exclusiva com usos limitados. / p>

Também há uma lição importante para os gerentes: não agrave sua equipe de TI, pois eles têm as chaves para os negócios . Uma boa política de contratação - contratação de pessoal em que você pode confiar para não abusar de seu conhecimento depois que o emprego terminar - é geralmente mais fácil (e melhor) do que uma solução técnica.

    

Answer 4

Mesmo usando algum tipo de mecanismo de login único, não evita ter que passar pelo exercício que você terá que passar. O logon único é uma camada de abstração que essencialmente abstrai os vários conjuntos individuais de credenciais em uma única credencial (da perspectiva do usuário), mas não "mescla" as diversas entidades em uma única entidade. Se você tiver um login do Windows e um login do Linux e utilizar o login único para permitir que o usuário faça a autenticação uma vez para acessar os dois sistemas, você ainda terá dois logins que precisam ser tratados quando o usuário sair. Para o usuário médio, o logon único seria eficaz, mas para um administrador ou um usuário experiente, eles saberiam como obter acesso a um sistema (roteador, servidor etc., ignorando o mecanismo de logon único. Por que passar pelo mecanismo de logon único quando posso apenas fazer telnet diretamente para o roteador?