Práticas recomendadas e soluções para compartilhar senhas [fechado]

Temos várias senhas que precisam ser conhecidas por mais de uma pessoa em nossa empresa. Por exemplo, a senha de administrador dos nossos roteadores da Internet, a senha do nosso host da web e também algumas senhas "não relacionadas à TI", como códigos seguros.

Atualmente, usamos um sistema ad hoc de "senhas padrão" para sistemas de baixo valor e compartilhamento verbal de senhas para sistemas mais importantes / potencialmente prejudiciais. Eu acho que a maioria das pessoas concorda que este não é um bom sistema.

O que gostaríamos é de uma solução de software para armazenar senhas "compartilhadas", com acesso para cada um limitado às pessoas que realmente precisam. Idealmente, isso solicitaria ou aplicaria alterações periódicas de senha. Também deve ser capaz de indicar quem tem acesso a uma senha específica ( por exemplo , quem sabe a senha raiz do servidor XYZ?)

Você pode sugerir alguma solução de software para armazenar e compartilhar senhas? Existe algo em particular para se preocupar?

Qual é a prática comum em pequenas e médias empresas para isso?

Enfrento esse problema toda vez que vou para uma nova inicialização. A primeira coisa que faço é fazer alguns "cofres de senhas" com um programa como este (ou um de seus derivados):

http://passwordsafe.sourceforge.net/

Defina combinações fortes e jogue-as em um compartilhamento de rede. Segmento por área de responsabilidade ... infraestrutura central, servidores de produção, desenvolvimento / controle de qualidade, etc.

Quando houver impulso suficiente, e supondo que eu possua as dependências adequadas do ambiente Windows, gosto de mover todos para isso:

http://www.clickstudios.com.au/passwordstate.html

Possui recursos para credenciais compartilhadas e pessoais.

Não se deve esquecer a necessidade de poder revogar senhas se um funcionário deixar / for demitido. Houve vários casos observados na mídia popular de funcionários sendo demitidos e "voltando" à empresa usando senhas que ainda estavam ativas depois que saíram.

Normalmente, são 2 partes:

1. Conhecer todas as senhas que precisam ser alteradas (caso contrário, você usará como padrão tudo o que for tedioso)
2. Alterando-os manualmente ou automatizando o processo com uma ferramenta ou script.

Outro fator importante é garantir que a diretiva de senha seja seguida quando as alterações forem feitas - por exemplo, como você sabe que a mesma senha não foi usada em várias contas ou que uma senha fraca não foi usada?

Eu trabalho em uma pequena loja de TI e usamos o Secret Server no ano passado para gerenciar nossas senhas para nossos dispositivos de rede e necessidades de clientes.

Eles oferecem uma "edição de instalação" ou uma edição online / hospedada. Usamos a edição hospedada por menos de US $ 100 / ano (5 usuários) e podemos acessar essas informações de senha de forma segura via navegador da web em qualquer lugar. Se você estiver realmente preocupado com a segurança, instale-o em seu próprio servidor e acesse-o apenas via LAN ou VPN.

Além disso, meu gerenciador de senhas "pessoal" favorito na Web agora oferece uma "edição comercial" - PassPack .

Não tenho certeza de como ele se comporta nesse cenário em relação ao Servidor Secreto, mas a solução deve ser muito mais versátil e segura do que pedaços de papel, aplicativos de desktop ou ( suspiro ) lembrando coisas na sua cabeça. No que diz respeito ao "ponto único de falha", um desses produtos permite fácil exportação para CSV.

Estou usando o LastPass há algum tempo e adoro isso. Passei um tempo pesquisando essa questão no ano passado e gostei de como o LastPass a havia feito.

• Todas as informações são armazenadas no site (e uma cópia local) em um pacote criptografado que somente você tem a senha para descriptografar
• Todas as senhas são compartilháveis ​​e revogáveis, você pode até compartilhá-las sem dar acesso à própria senha (para logins na web)
• Plugins para os principais navegadores
• Muitos outros recursos

Eu recomendo a PasswordSafe de Adam, com os dados em uma pasta de rede. Eu tenho duas considerações nesta área. Uma é ter uma única versão, para que todos os que precisam dos dados estejam obtendo os dados atuais.

1 - O PasswordSafe usa um formato padronizado para o arquivo, portanto existem outras soluções que podem lê-lo, incluindo o KeePass.

2- Coloque o arquivo de senha em um compartilhamento seguro e tenha um script noturno que o copie para alguns locais da rede. Talvez copie-o para um compartilhamento em outro servidor (externo, se possível) e para uma unidade USB restante no servidor. Você deseja que o arquivo seja pelo menos um local em que não esteja protegido por uma senha que esteja armazenando!

3- Armazene o instalador (ou versão executável do programa) nos mesmos locais que o arquivo-chave, para que você possa acessá-lo rapidamente, se necessário.

4- Faça com que as pessoas abram o arquivo somente para leitura, a menos que precisem fazer uma alteração.

5- Se necessário, você pode criar vários arquivos de senha, um para as credenciais de que todos da equipe precisam e outro para as credenciais das coisas realmente sensíveis.

Eu não recomendaria mudar para uma solução baseada na Web. Uma solução hospedada internamente pode ser boa, mas parece um monte de problemas. Também estou preocupado com o fato de ser um único ponto de falha.

Compartilho a responsabilidade de alguns sistemas com funcionários de um de meus clientes. Concordamos em usar um esquema de senha para as contas mais usadas. Outras senhas são armazenadas em uma lista em papel de pares (número, senha) mantidos pelo chefe de TI do cliente. Os nomes de usuário e hosts são armazenados em um banco de dados facilmente acessível. As senhas são entregues com base na necessidade de conhecimento.

Prática comum em pequenas e médias empresas:

Três lugares em que trabalhei usaram documentos separados para detalhar senhas para diferentes sistemas. Um documento para roteadores e firewalls, outro para acesso aos servidores e outro para desenvolvedores (por exemplo, detalhes de login para conexões com o banco de dados). O acesso a aplicativos não costuma ser documentado (presumo que, para a maioria, você se conecta com direitos de administrador).

O administrador da rede vê apenas o documento de senha dos roteadores e as pessoas que têm acesso a este documento estão listadas neste arquivo. Seus termos de emprego determinam que os logins e senhas aos quais têm acesso são privados e não devem ser compartilhados com outras pessoas. Semelhante para administrador de sistemas e desenvolvedores.

Às vezes, a realidade é que a senha é compartilhada, mas você pode identificar quem precisa saber (e por quê) e alterar o que precisa ser alterado. Funcionou bem em uma empresa (de software) de 50 funcionários.

Para senhas raramente usadas, como contas de administrador local em servidores, senhas de roteador e firewall e similares no meu último trabalho, uma loja de cerca de 50 ou mais, apenas o administrador do sistema sabia as senhas. Eles foram anotados em um pedaço de papel em um envelope. Havia três envelopes que foram selados e assinados pelo chefe, pelo SysAdmin e pelo programador principal. Cada indivíduo tinha uma cópia dos documentos. No caso de as senhas serem usadas, as mudamos e fizemos novos envelopes.

No meu trabalho atual, em uma organização muito maior, temos 15 administradores de sistemas sozinhos e, alguns milhares de usuários, temos um método para calcular senhas com base no nome de um servidor. Isso inclui um prefixo conhecido e um método de hash simples o suficiente para ser feito no papel. Quando as senhas precisam ser alteradas porque alguém sai ou não, alteramos o prefixo ou o hash ou ambos. Dessa forma, embora eu não saiba a senha de todas as máquinas ou dispositivos ao meu redor, eu poderia calculá-la se necessário por algum motivo.

Hoje há um post do Lifehacker sobre o Passpack , pode valer a pena dar uma olhada.

Eu já tive o mesmo problema antes. Acabei construindo um sistema para lidar com isso sozinho. Ele armazenava o nome de usuário e a senha em um formulário altamente criptografado dentro de um banco de dados com uma Interface da Web que permitia inserir as informações da conta e definir a segurança para que somente as pessoas ou grupos corretos pudessem acessar os dados.

Não foi solicitado quando era hora de alterar as senhas, pois os serviços em dezenas de servidores usavam o mesmo login e as alterações nas senhas tinham que ser configuradas com bastante antecedência.

Criei-o com um recurso de auditoria completo para que, toda vez que um funcionário visse um logon, ele fosse registrado para que pudéssemos despejar o log de auditoria no Excel para os auditores SOX.

Use GPG com a opção Symmetric para criptografar um arquivo de texto com todas as senhas nele. Então, tudo o que você precisa fazer é fornecer a frase secreta para outros administradores. Quando um administrador sai da empresa, basta criptografar novamente o arquivo de texto com uma nova senha.

Centrify tem trabalhado para mim.

Uau, boa discussão! Ninguém mencionou minha solução preferida (exceto de passagem), então darei uma mensagem para o KeePass. Bem extensível, com autenticação por senha, chave ou AD. Faz o trabalho muito bem para nós.

Para acessar servidores:

Forneça acesso a um servidor e use-o como uma caixa de salto e gerencie as contas na caixa de salto. Qualquer um que se supõe ser confiável na caixa de salto é confiável no recurso remoto. Dessa forma, todos têm sua própria senha e a senha no servidor para uma conta específica pode ser mantida em segredo.

Para acessar outros recursos:

Limite o acesso apenas a pessoal essencial. Certifique-se de gerenciar uma lista de usuários confiáveis. Altere a senha a cada 90 dias e atualize a lista de usuários confiáveis. Informe as pessoas da alteração pendente com 15, 7 e 1 dia de antecedência. Distribua apenas a senha aos gerentes e permita que eles determinem quem precisa de acesso. Use utilitários para registrar o acesso e informar regularmente aos usuários que eles são sistemas monitorados de perto. Qualquer negócio engraçado nos servidores deve ser uma ofensa terminável conhecida.

Sei que essa não é exatamente a resposta que você deseja, mas, no meu local de trabalho, é exatamente a mesma, os funcionários confiáveis ​​recebem as senhas relevantes, as senhas não são compartilhadas entre os dispositivos e não são anotadas. O sistema tende a funcionar muito bem, pois a administração de dispositivos geralmente é de responsabilidade de apenas alguns membros da equipe. Também temos uma retenção muito boa de funcionários, para que a confiança possa ser construída por um longo período de tempo.

Você pode usar algum tipo de software de cofre de senhas - dessa forma, você pode conceder aos usuários autorizados o próprio acesso a eles e garantir que as informações não vazem para as pessoas deixando anotações. Uma boa provavelmente nem exibe a senha, apenas a coloca na área de transferência para colar e colar.

Temos um sistema como o presidente e a bomba - duas pessoas sabem metade da senha. Dessa forma, você nunca terá uma situação em que um único administrador não autorizado saia e faça alterações não aprovadas por conta própria.

Eu trabalho em uma empresa de TI, temos muitos clientes, normalmente resolvemos o problema remotamente. Usamos ssh para fazer login para solucionar problemas. Adicionamos uma chave ssh de máquina a todas as máquinas de nossos clientes, para que seja útil para outros fazer login e solucionar problemas, se eu não estiver lá. Mas a máquina que estamos usando para fazer login nos clientes é altamente recomendável protegido. Se você quiser ter boas senhas, use números e caracteres extras.

Para adicionar chaves ssh, o seguinte:

1.ssh-keygen -t dsa (Para obter as chaves ssh em .ssh / id_dsa.pub

2. scp .ssh / id_dsa.pub root @ remote: ~ / tmp

3. Na máquina remota

cat >> /tmp/id_dsa.pub .ssh / allowed_keys2

Tente fazer login para remover macine, de outro console ... :) happy sshhhhhh

Recuse-se a usar sistemas que exijam uma senha. Qualquer servidor deve se autenticar com chaves SSH, qualquer site com OpenID. Execute um provedor OpenID dentro do firewall.

Obviamente, esse cenário implica que todos os seus sistemas estão acessíveis via SSH ou HTTP, mas funciona para nós.