Atualmente, estou executando uma auditoria Unix e gostaria algumas orientações sobre as melhores práticas para a gestão do usuário root acesso.

A organização é pequena, com uma equipe de TI approx 25.

Dê o passe apenas para quem você confia. Registrando a raiz acções que é lido por todos os utilizadores é bom também.

Eu nunca vi melhores práticas implementadas. Mas em um mundo ideal ... A conta root não pode ser usado para acessar a caixa. Você assina sobre como Bob, ou George, ou o que seja. Então você para a sua raiz, deixando uma pista de auditoria. A excepção é o sistema portuário consola ... você pode fazer logon como root lá, reinicie a máquina, etc A consola porto só pode ser acessado a partir do computador quarto. Ou, se é que isso é muito restritiva, o console é acessado a partir do porto um servidor remoto consola. Você precisa signin para o console como a ti mesmo e este servidor deixa uma pista de auditoria.

A raiz é uma senha forte senha. Ele está disponível apenas para alguns especialistas. Você pode recuperar a partir de qualquer desastre? Se não, não raiz senha para você. (Possivelmente um gerente tem, mas não usar pessoalmente, a senha). Quando um destes peritos folhas, você desativar a sua conta. E você mudar a password de root.

Outras pessoas usam sudo se precisarem de algo raiz ... este também deixa uma pista de auditoria. Isto não significa contudo ALL no sudoers. Apenas um pequeno número limitado comandos.

Algo como este é a nossa política oficial. Mas várias vezes bigshots arranjar excepções.

Eu só tinha que manter meus 2 centavos-nos aqui. Um problema que eu tenho visto é uma falta de "servidores de terminal 'com SSH (2) apenas o acesso. Muita coisa ainda usar o telnet. Telnet e do BSD "R'-comandos deve ser proibida. Outra é que ninguém se senta com o CEO (presidente, proprietário, etc) e tem uma discussão sobre qual é o verdadeiro valor do "coisas" armazenados em seu computador. Ou o custo para ele, quando esses sistemas não são mais acessíveis. A meta é a força dele / dela em uma política de segurança. Que realmente deve limitar a "bigshot" acesso.
A última coisa é uma coisa "velha" sysadmin uma vez me contou. Fomos configuração raiz senhas. Agarrou um UNIX livros nas prateleiras, encontrou um capítulo ou sub-capítulo título com seis ou sete palavras nela, tomou a primeira letra de cada palavra, "munged 'esses caracteres (a \u003d @; l \u003d | E \u003d 3, etc) e reteve o primeiro caractere do nome em frente a esta cadeia, bem como o último caractere do nome no final. Ele havia criado "o mesmo" root senha para todas as máquinas (fácil de recordar, especialmente se você anotou o capítulo título), e, ao mesmo tempo uma raiz diferente senha para cada máquina. Eu tenho usado essa (ou uma variação) desde então.

raiz só pode acessar qualquer caixa através da sua consola, e apenas a SA equipe tem raiz.
Cada uma das nossas casas têm existência própria PWD, kinda tranquiliza-lo sobre o que em nossa casa
Todas as senhas expirar, à excepção de raiz ... o que eu sinto que não mudam com freqüência suficiente.

Nossa loja é um grande defensor do sudo.
Temos capturados menus (que utilizam sudo) no lugar em todos os sistemas de Datactr pessoal para as seguintes ações:
Criar unix contas (IS e Usuário)
Alterar senhas (todos à excepção de raiz)
IS Desactivar e remover contas de usuário.

Como mencionado anteriormente, todas estas actividades irão deixar uma pista de auditoria e ... No nosso caso, também terão um associado HelpDesk pedido #.
Lembra quando você tinha que fazer todas estas tarefas ... sudo é seu amigo

Nós também utilizam e-mail (fim-de-dia) para nos ajudar a gerir outras Auditoria políticas, como a seguinte:
inválido tentativas de sudo (sudo usuário não é válido)
tentativas de su inválido (que não fazem parte da equipe SA)
login inválido tentativas 3 ou> ... estes são horária.
(Este é apenas um exemplo do que pode implementada, esta lista pode ir sobre e-on)

tenho SOX?
Em todays SOX clima, acho que todas estas políticas associadas e pistas de auditoria são necessárias.

Se você não tem algo semelhante no lugar, você pode querer pensar sobre a forma como alguns deles poderiam oferecer algum benefício para o seu env ..

Perderabo,

O meu atual emprego antes de uma era de segurança ideal. Tudo o que residiam na zona DMZ ou próximo baixo foi Trusted Solaris. A conta de root era uma "função", e não um usuário - por isso não login directo a partir de qualquer lugar. RBAC governou o dia e que tinha sido prorrogado para fornecer sudo aquilo que poderia e muito mais. Sem acesso, que foi não criptografada foi permitido. Todas as outras camadas - app, transporte, o cliente eo banco de dados, não pensei TS foram configuração de forma semelhante. Extensa auditoria existiam registos de auditoria e mantido locais e aa localização remota de modo que você poderia checksum para garantir que a pista de auditoria foi inalterado.

Segurança foi apertada, mas bem organizado o suficiente para nunca ser um obstáculo para as empresas.

Felicidades,

Keith