Como uma equipe de administradores de sistemas compartilha senhas com segurança?

Quais são as práticas recomendadas para compartilhar centenas de senhas entre algumas pessoas? Essas senhas protegem os dados críticos da missão e nunca podem ser visíveis além de uma pequena equipe.

Eu provavelmente escreveria uma solução personalizada baseada na Web hospedada em uma intranet corporativa. (consulte http://lastpass.com para obter inspiração ou para usá-lo. Compartilhar senhas é um dos recursos, embora possa não funcionar no seu volume.)

EDIT : Claro, melhor solução, não compartilhá-los. Armazenar senhas de texto não criptografado em qualquer meio é perigoso, principalmente quando o objetivo de armazená-las é compartilhá-las. Há um número quase infinito de soluções, cada uma trazendo um risco associado. Por que não colocá-los em uma imagem de disco criptografada, gravar essa imagem em um único CD, colocar o CD em um cofre que apenas um guarda armado possa abrir e autorizar as pessoas a apresentar o documento com foto para desbloqueá-lo?

O ponto é que realmente não conhecemos seu cenário. Por que você está compartilhando centenas de senhas de missão crítica? Eles são para a intranet do backoffice, VPN ou são senhas de clientes que você mantém em texto simples por algum motivo? Todas as pessoas com quem você precisa compartilhá-lo estão na mesma instalação? Uma transferência física como um CD criptografado ou uma tabela impressa armazenada em um cofre realmente funcionaria? Ou seus administradores de sistemas estão espalhados pelo mundo, tornando os meios eletrônicos de compartilhá-los a única solução?

A melhor prática é não compartilhar as senhas. Use ferramentas como o sudo para permitir que os usuários obtenham o acesso necessário em suas próprias contas. Se você tiver alguns usuários, cada um deverá ter suas próprias contas, quando necessário. O LDAP (Unix / Linux) e o Active Directory são uma boa solução para conceder acesso a vários servidores a partir de um banco de dados comum.

Quando for necessário ter uma cópia escrita de uma senha, sele-a em um envelope assinado e datado no selo. Mude a senha quando for usada. Quando a senha for alterada, sele-a em um novo envelope.

Para senhas que realmente precisam ser compartilhadas, use uma das ferramentas de senha como Keepass, que pode ter seu banco de dados em uma rede. Ferramentas com clientes para várias plataformas são melhores. Considere se você precisa de mais de um banco de dados. Lembre-se de que você precisa realmente confiar em todos que têm acesso a esses dados.

Fomos com o KeePass para esse fim exato. É um ótimo pequeno programa que armazena todas as suas senhas em um arquivo de banco de dados criptografado. Existem recursos de segurança adicionais, como a necessidade de um arquivo de chave junto com a senha principal para acessar as senhas. Isso permite várias camadas de segurança (separar o arquivo-chave e o banco de dados), mantendo o tempo conveniente para que todos trabalhem com todas as senhas diferentes. Por exemplo, você pode executar o aplicativo e o arquivo de chave em uma unidade USB, mas armazenar o banco de dados na sua rede em algum lugar. Isso exigiria credenciais para o compartilhamento de rede, a senha principal e a unidade USB física com o arquivo de chave.

Quais são as práticas recomendadas para compartilhar centenas de senhas entre algumas pessoas?

Fácil, isso vem em dois sabores:

1. Você não, pura e simplesmente. Se você optar por fazer isso, adiará a autenticação de senha para uma autoridade confiável externa e controlará a autenticação a partir daí.

2. Você possui, mas ao fazê-lo, possui controles de acesso externos que possuem senhas ou tokens de segurança que não são gravados dentro do sistema que você usa (ou seja, o registro de senhas é protegido por outra senha com disponibilidade limitada). Existem inúmeros problemas com isso.

Essas senhas protegem os dados críticos da missão e nunca podem ser visíveis além de uma pequena equipe.

Você deve considerar seriamente um serviço de autenticação segura que se integre a um serviço de diretório para solucionar o problema. A combinação DS / AS cria uma "autoridade" confiável que pode atuar como um árbitro para todos os seus usuários e dispositivos. As contas de usuário podem ter seu acesso abstraído da senha real usada na autenticação, facilitando a "desconexão" de senhas da política de acesso. O controle de senhas é desativado na conta do usuário; portanto, se um administrador sair, você simplesmente desligará a conta e o acesso será desativado (porque a senha dessa pessoa só concede acesso com base na validade do DS / AS que confirma a conta válida).

Isso funcionará apenas quando você estiver em um ambiente que permita que seus dispositivos / programas desviem suas solicitações de autenticação para fontes externas; portanto, pode não ser uma solução para você . Se você tem uma porcentagem significativa de dispositivos / programas que podem acomodar autenticação externa, eu faria isso, apenas para consolidar várias centenas de senhas em uma lista gerenciável de, digamos, uma dúzia. Se você decidir seguir esse caminho, existem várias soluções prontas para uso, conhecidas e testadas.

• Active Directory. Provavelmente o mais conhecido do grupo, oferece o Kerberos como uma opção de autenticação e fornece LDAP para o DS básico.
• Samba / Winbind. Pense nisso como "Active Directory Light", você não obtém todos os recursos do AD, mas um modelo mais antigo baseado no NT4 (pense no hash LANMAN). Isso será suplantado com a integração do AD do Samba 4 e provavelmente "desaparecerá".
• Serviços de Diretório da Novell. Não sei o suficiente para recomendá-lo, mas sei que ele ainda existe. Muitas entidades governamentais ainda administram o NDS; portanto, se você estiver trabalhando nesse "setor", será do seu interesse. A Novell recentemente transportou o NDS para ser executado como um serviço Linux, mas não sei se esse ainda é um produto ativo (por volta de 2005).
• LDAP + Kerberos. Este é basicamente o Active Directory "doméstico", menos todos os "recursos legais". No entanto, eles também são componentes conhecidos com uma base de código estável e amadurecida; portanto, a integração desses serviços é geralmente a extensão da "personalização" necessária para fazer as coisas funcionarem.
• Chaves SSH + (insira o programa de administração do sistema aqui, provavelmente fantoche). Útil apenas onde você tem SSH em todos os aspectos e todos os dispositivos são acessados ​​dessa maneira. As chaves podem ser distribuídas e revogadas conforme necessário, e as senhas tornam-se "irrelevantes" à medida que a chave SSH concede acesso. Usar um sistema como fantoche permite atualizar centenas de máquinas emitindo comandos em massa para adicionar / revogar chaves SSH.
• Alguma combinação dos itens acima.

Há também uma questão de quanta segurança você precisa. Você não especificou se por "missão crítica" você quer dizer que ogivas nucleares podem chover nas cidades, ou se "missão crítica" significa que o último carregamento de Furbies não chegará à cidade. Seria realmente útil se houvesse algo que descrevesse uma avaliação de risco / ameaça.

Algumas coisas:

• Como outros já disseram, esta é uma má ideia. Use um LDAP, etc
• Se você se comprometer a fazer isso por qualquer motivo, consolide pelo menos as senhas. 100 senhas não gerenciadas significa que você não está atualizando senhas.
• Mantenha-os no papel. Exija que a equipe assine o papel com uma tinta de cor diferente para facilitar a determinação de se uma folha foi copiada.
• Se você estiver no Unix, use S / KEY para gerar senhas únicas. Guarde isso em algum lugar seguro.

Você também precisa ir além das medidas de segurança mecânica de colocar senhas em papel em um cofre ou criptografar as senhas. Leia como organizações com modelos de segurança maduros protegem chaves e combinações seguras. Não recomendo fazer o que você quer fazer, mas se você fizer:

• As pessoas que usarão as senhas não podem controlar o acesso às senhas. Um grupo distinto de pessoas em uma cadeia de gerenciamento diferente precisa controlar o acesso ao cofre, gaveta etc. Se você possui um grupo financeiro, ele pode ser um candidato. Talvez o vice-presidente de marketing etc.
• É necessário haver um registro escrito quando o cofre for aberto e alguém se apossar de uma senha.
• A senha deve ser alterada dentro de 24 horas após o check-out.

Procedimentos como esse são uma dor no pescoço, mas servirão como incentivo para as pessoas adotarem práticas mais saudáveis. Se você não fizer algo como o que eu descrevi, não se preocupe em bloquear as senhas, porque você será violado algum dia de qualquer maneira.

Sei que essa é uma pergunta antiga, mas recentemente me deparei com uma solução baseada na web de código aberto chamada Corporate Vault que pode ser interessante para alguns. Ainda não tive a chance de experimentar.

usamos um programa chamado Password Safe . é agradável e muito seguro, você pode configurar o banco de dados em uma unidade de rede e dar a todos que precisam dele acesso e senha ao próprio cofre, que armazena todos os nomes de usuário e senhas criptografados com segurança.

https://pypi.python.org/pypi/django-pstore/ usa criptografia GPG por usuário para senhas compartilhadas (e quaisquer outros dados que você queira compartilhar). O servidor nunca sabe sobre senhas, apenas retém os dados criptografados. Todo mundo usa sua própria chave privada para descriptografar os segredos compartilhados.

O sistema inclui gerenciamento de direitos: nem todo mundo obtém acesso total.

Usamos https://passwork.me como solução auto-hospedada. Mas você também pode armazenar senhas na nuvem deles.

A SPB Wallet é uma boa que costumávamos usar o PW com segurança por fantasma, mas a carteira SPB permite sincronizar com um compartilhamento de rede e também com o seu iphone, se você obtiver o aplicativo. Ele também possui um gerador de senhas embutido e você pode gerá-los de senhas simples a senhas extremamente complexas. Você também pode copiar a senha enquanto a senha ainda estiver com asterisco. Se alguém estiver procurando, você poderá copiá-la e colá-la sem que ninguém veja a senha. O aplicativo para PC é bloqueado automaticamente quando não há atividade por um período definido.

Outra opção é o Azure Key Vault, que armazena seus segredos com segurança e permite que você permita o acesso a eles de forma programática, gire facilmente suas senhas, etc.

Nossa prática recomendada é compartilhar o mínimo possível de senhas.

Portanto, por exemplo: - use my.cnf no diretório raiz do sistema para obter senhas no banco de dados - use chaves ssh para acessar servidores e ter uma senha raiz que é permitida apenas pelo console (portanto, você deve ter acesso físico / bmc ao servidor ) - use ldap sempre que possível (ssh, bmc, switches, redmine, ....)

No entanto, existem poucas situações em que não podemos usar essa abordagem (como senha root). Em seguida, usamos keepass em nosso armazenamento compartilhado, mas mantemos apenas 10 senhas necessárias.

Muito boa pergunta. Eu estaria interessado em outras respostas.

Aqui está o que eu faço, mas primeiro recomendo o uso de chaves pré-compartilhadas sempre que possível. Não sei se isso é possível com os sistemas Windows.

Como a quantidade de senhas deve ser pequena (você está usando chaves sempre que possível), eu uso um arquivo de texto sem formatação criptografado com gpg em um sistema que não possui NIC. Então (1) você precisa de acesso físico e (2) uma senha.

editado para maior clareza