Gerenciamento de credenciais do servidor para Linux e Windows


12

Somos uma loja relativamente pequena (até o número de administradores de sistemas) com uma mistura de servidores RHEL, Solaris, Windows 2003 e Windows 2008; cerca de 200 servidores ao todo.

Para nossas contas de administrador ( rootno Linux e admnistratorno Windows), temos um esquema de senha que depende da localização do datacenter e de algumas outras propriedades documentadas do servidor.

No Linux, nossa prática atual é criar uma conta compartilhada não privilegiado onde podíamos supara root. Nos sistemas baseados no Windows, criamos uma conta adicional com privilégios de administrador. Ambas as contas compartilham a mesma senha.

Isto provou ser muito ineficiente. Quando alguém sai de nossa loja, temos que:

  1. Alterar o esquema de senha para as contas de administrador
  2. Gere uma nova senha de administrador para cada servidor
  3. Crie uma nova senha de conta de não administrador
  4. Toque em todos os servidores e altere as senhas

Eu queria saber se alguém em um ambiente semelhante pode sugerir uma maneira mais sensata de gerenciar essas credenciais. Algumas informações relevantes:

  • Embora a maioria dos nossos servidores faça parte do nosso domínio do AD, nem todos são.
  • Gerenciamos todos os nossos servidores Linux com o Puppet (a autenticação de chave era uma opção que eu pensava, mas ela abordaria apenas a principal preocupação acima).
  • Fornecemos servidores de Linux com o Cobbler.
  • Cerca de 10% do nosso hardware é dedicado ao VMWare. Nesses casos, usamos modelos VMWare para compilações de servidores.

Todas as idéias ou sugestões serão muito apreciadas. Esse é um problema que já existe há algum tempo e finalmente quero resolvê-lo.

Respostas:


10

Algumas sugestões que eu teria são:

  • Os servidores conectados ao Windows AD podem ter suas senhas de administrador local definidas por meio da diretiva de grupo usando as Preferências de Diretiva de Grupo (GPP) ou um script de inicialização do computador. Consulte http://social.technet.microsoft.com/Forums/en-US/winserverGP/thread/b1e94909-bb0b-4e10-83a0-cd7812dfe073/

  • Limite a criação de contas locais nos servidores Windows, a menos que seja necessário. Use contas do AD quando possível.

  • Use o computador LDAP para Linux para autenticar contas de administrador no AD. Isso simplifica um pouco o gerenciamento de contas. E quando um administrador deixar apenas desativar em um local e sem acesso, você poderá limpar o lado do Linux à sua vontade.

  • Use o arquivo / etc / sudoers para uma conta de administrador específica no Linux, para que os administradores não precisem da senha de root. Isso pode ser bom em sua instância, pois raramente precisarão da senha root, para que possa ser bloqueada. Atualizada

  • Mantenha as senhas de administrador raiz e local em uma senha segura, não no conhecimento geral. Alguns cofres de senhas têm delegação e registro, portanto, talvez você nem precise redefinir uma senha se a pessoa nunca teve acesso a ela.

  • Automatize o processo de redefinição de senha para contas raiz e de administrador. Tanto o Linux quanto o Windows podem ser scripts para fazer isso, para que você economize algum tempo e não seja um fardo.

Espero que ajude.


Meu problema com o LDAP é o único ponto de falha. Prefiro gerenciar contas via Puppet. E aprecie suas sugestões. Obrigado @Bernie!
Belmin Fernandez

1
@Beaming Se você usa o Active Directory, pode ter mais de um controlador de domínio (nenhum ponto único de falha) e apontar para o nome de domínio DNS, por exemplo, domain.com, para obter todos os controladores de domínio para uma consulta LDAP. Ou você pode configurar um registro A DNS para apontar para controladores de domínio específicos, se desejar que apenas dois ou três respondam ao LDAP como ldap.domain.com. Não usei o Puppet, mas a chave para facilitar a administração do usuário não é uma única fonte, sempre que possível. Seria provável que o Puppet pudesse se conectar a um servidor LDAP de backend de qualquer maneira, se você preferisse dessa maneira.
Bernie White

Concordou que o AD é o caminho a seguir aqui. Com mais de 2 controladores de domínio, a probabilidade de o AD cair completamente é pequena, mas também, se houver, você provavelmente terá problemas muito maiores. Mantenha contas raiz locais em seus servidores Linux para serem usadas como último recurso, se tudo mais falhar.
EEAA

2
@ Bernie - em relação ao seu terceiro ponto. Ao usar o sudo, ninguém precisa saber a senha do root. Ao especificar "NOPASSWD" em uma entrada sudo, o usuário não precisa digitar sua própria senha. Isso não tem nada a ver com a senha root.
EEAA

@ErikA +1 Muito verdadeiro. Removida a referência ao NOPASSWD, pois não ajuda a responder à pergunta /
Bernie White

2

Você pode tentar e ver se o FreeIPA funciona para você.

Você pode gerenciar o acesso do usuário aos hosts a partir de um local central. Conforme sugerido por outras pessoas, você pode ver se o sudo funciona para você no acesso no nível raiz. O Freeipa suporta sudoers no LDAP, para que você não precise mantê-lo em cada servidor ou via fantoche etc.

O Freeipa suporta clientes Linux, Solaris e Windows. Você pode perder certos recursos do AD e não tenho certeza de quais outras limitações um cliente Windows terá.

Possui recursos de replicação, para que você possa evitar um SPOF. O back-end é LDAP, portanto, é possível reutilizar muitas ferramentas que as pessoas usam para LDAP, como scripts de backup.

Ele suporta controle de acesso baseado em host, para que você possa dizer "o usuário X pode efetuar login apenas nos servidores Y".

Também oferece sincronização com o AD . Como eu não sou do Windows, não faço ideia do que isso significa.


1

Não use a conta de administrador padrão. No lado do Windows, crie uma conta de usuário e uma conta de administrador para cada usuário que precisar de acesso de administrador. Você pode usar qualquer ferramenta para sincronizar com o UNIX.

Se alguém sair, basta excluir as contas de usuário e administrador.

Para proteger a conta de administrador padrão, forneça uma senha muito longa e complexa e verifique se qualquer pessoa tem apenas metade. Se eles precisam usar a conta inteira, precisam procurar alguém que tenha a outra metade.

Isso é o mais seguro possível.

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.