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

Question

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

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

O que gostaríamos é de uma solução de software para armazenar senhas "compartilhadas", com acesso limitado para cada uma das pessoas que realmente precisam dela. Idealmente, isso exigiria ou aplicaria alterações periódicas de senha. Ele 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 qualquer solução de software para armazenar e compartilhar senhas? Há algo de especial para ser cauteloso?

Qual é a prática comum em empresas de pequeno e médio porte para isso?

    

Answer 1

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

link

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

Uma vez que há impulso suficiente, e supondo que eu tenha as dependências adequadas do ambiente Windows, gosto de levar todo mundo para isso:

link

Tem recursos para credenciais compartilhadas e pessoais.

    

Answer 2

Não esquecer é a necessidade de poder revogar senhas se um funcionário sair / for demitido. Houve vários casos notados na mídia popular de que os funcionários foram demitidos e "voltaram" à empresa usando senhas que ainda estavam ativas depois de saírem.

Isso normalmente é de 2 partes:

1. Conhecendo todas as senhas que precisam ser alteradas (caso contrário, o padrão é tudo o que é tedioso)
2. Altere-as manualmente ou automatize o processo com uma ferramenta ou script.

Outro fator importante é garantir que a política de senha seja seguida quando as alterações forem feitas. Como você sabe que a mesma senha não foi usada em várias contas ou que uma senha fraca não foi usada?

    

Answer 3

Eu trabalho em uma pequena loja de TI e estamos usando o Servidor Secreto no ano passado para gerenciar nossa senhas para nossos dispositivos de rede e necessidades do cliente.

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

Além disso, meu gerenciador de senhas "pessoal" baseado na web agora oferece uma "edição empresarial" - 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 recados de papel, aplicativos de área de trabalho ou ( suspiro ) lembrando coisas em seu cabeça. Para a preocupação do "ponto único de falha", qualquer um desses produtos permite fácil exportação para CSV.

    

Answer 4

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

• Todas as informações são armazenadas em seu 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 da web)
• Plugins para os principais navegadores
• Muitos outros recursos

Answer 5

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

1- O PasswordSafe usa um formato padronizado para o arquivo, então 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 na rede. Talvez copiá-lo para um compartilhamento em outro servidor (off-site, se possível) e para uma unidade USB deixada no servidor. Você quer que o arquivo tenha pelo menos um lugar onde 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 de chave, para que você possa acessá-lo rapidamente, se necessário.

4- As pessoas abrem o arquivo somente para leitura, a menos que tenham que fazer uma alteração.

5- Se necessário, você pode criar vários arquivos de senha, um para as credenciais de que todos na equipe precisam e um para as credenciais para as coisas realmente delicadas.

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

    

Answer 6

Compartilho a responsabilidade por vários 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 baseada em papel de pares (número, senha) mantidos pelo Chefe de TI do cliente. Os nomes de usuários e hosts são armazenados em um banco de dados facilmente acessível. As senhas são entregues com base na necessidade de conhecimento.

    

Answer 7

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 os roteadores e firewalls, outro para acesso aos servidores e um para desenvolvedores (por exemplo, detalhes de login para conexões de banco de dados). O acesso a aplicativos tende a não ser documentado (suponho que, para a maioria, você faça login como você mesmo com direitos de administrador).

O administrador da rede só vê o documento de senha do roteador e os indivíduos que têm acesso a este documento estão listados nesse arquivo. Seus termos de emprego determinam que logins e senhas aos quais eles têm acesso são privados e não devem ser compartilhados com outros. Semelhante para administradores de sistemas e desenvolvedores.

A realidade às vezes é 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.

    

Answer 8

Para senhas usadas raramente, como contas de administrador local em servidores, senhas de firewall e roteador e similares no meu último trabalho, uma loja de cerca de 50 ou mais, apenas o administrador de sistema realmente conhecia as senhas. Eles foram escritos em um pedaço de papel em um envelope. Acredito que três envelopes foram selados e assinados pelo Chefe, pelo SysAdmin e pelo Head Programmer. Cada indivíduo teve uma cópia dos documentos. No caso de as senhas serem usadas, nós as mudamos e fizemos novos envelopes.

No meu trabalho atual, em uma organização muito maior, temos 15 sysadmins sozinhos, e alguns milhares de usuários, temos um método para calcular senhas com base em um nome de servidores. Isso inclui um prefixo conhecido e um método de hash que é simples o suficiente para fazer no papel. Quando as senhas precisam ser alteradas porque alguém parte ou não, alteramos o prefixo, o hash ou ambos. Dessa forma, enquanto eu não sei a senha para cada máquina ou dispositivo em torno de mim, eu poderia calcular se eu precisava por algum motivo.

    

Answer 9

Há um post Lifehacker de hoje sobre Passpack , pode valer a pena dar uma olhada.

    

Answer 10

Eu 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 formato altamente criptografado em um banco de dados com uma Interface Web que permitia inserir as informações da conta e definir a segurança para que apenas as pessoas ou grupos corretos pudessem acessar os dados.

Ele não solicitou 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 precisavam ser configuradas com antecedência.

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

    

Answer 11

Use o 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 uma frase-senha para outros administradores. Quando um administrador deixa a empresa, basta criptografar novamente o arquivo de texto com uma nova frase-senha.

    

Answer 12

A Centrify tem trabalhado para mim.

    

Answer 13

Uau, bom fio! Ninguém mencionou a minha solução preferida (exceto de passagem), por isso vou dar uma mensagem ao KeePass. Muito extensível, com autenticação baseada em senha, chave ou AD. Faz o trabalho muito bem para nós.

    

Answer 14

Para acessar servidores:

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

Para acessar outros recursos:

Limite o acesso apenas ao 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 sobre a mudança pendente 15, 7 e 1 dia de antecedência. Distribua a senha apenas para os 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.

    

Answer 15

Eu sei que esta não é exatamente a resposta que você quer, mas no meu local de trabalho é exatamente o mesmo, os membros confiáveis da equipe recebem as senhas relevantes, as senhas não são compartilhadas entre dispositivos e não são gravadas. O sistema tende a funcionar muito bem, já que a administração de dispositivos é geralmente responsabilidade de apenas alguns membros da equipe. Também temos uma retenção de pessoal muito boa para que a confiança possa ser construída por um longo período de tempo.

    

Answer 16

Você pode querer usar algum tipo de software do cofre de senhas - assim, você pode conceder aos usuários autorizados seu próprio acesso a ele e certificar-se de que as informações não vazem por pessoas que estejam deixando anotações. Uma boa, provavelmente, nem exibe a senha, apenas a coloca na área de transferência para a pasta cut'n.

    

Answer 17

Temos um sistema como o Presidente e a Bomba - duas pessoas conhecem metade da senha. Dessa forma, você nunca terá uma situação em que um único administrador desonesto seja excluído e faça alterações não aprovadas por conta própria.

    

Answer 18

Eu trabalho em uma empresa de TI, nós temos muitos clientes, normalmente nós trotamos o problema remotamente. Usamos o ssh para fazer login para solucionar problemas. Nós adicionamos uma máquina ssh-key para todas as máquinas de nossos clientes, para que seja útil para outro login & solucionar os problemas, se eu não estou lá.Mas a máquina que estamos usando para acessar clientes macine sua altamente segura. Se você quer ter boas senhas, use melhor números e caracteres extras.

Para adicionar chaves ssh, o seguinte:

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

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

3. Na máquina remota

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

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

    

Answer 19

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

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