É recomendável ter login separado para um domínio para administradores de domínio?


33

Normalmente, gosto de configurar logins separados para mim, um com permissões de usuário regulares e outro para tarefas administrativas. Por exemplo, se o domínio fosse XXXX, eu configuraria uma conta XXXX \ bpeikes e uma conta XXXX \ adminbp. Eu sempre fiz isso porque, francamente, não confio em mim para fazer login como administrador, mas em todos os lugares em que trabalhei, os administradores de sistema parecem adicionar apenas suas contas habituais ao grupo Administradores de Domínio.

Existem práticas recomendadas? Eu vi um artigo da MS que parece dizer que você deve usar o Run As e não fazer login como administrador, mas eles não dão um exemplo de implementação e nunca vi alguém fazer isso.


1
Como quem lida principalmente com Linux / Unix e não é especialista em Windows, não é exatamente isso que o UAC deve corrigir? Com o que quero dizer, para que se possa usar uma conta, mas ainda assim, apenas processos autorizados recebam privilégios administrativos.
precisa saber é o seguinte

@ Dolda2000 O UAC era mais para usuários finais com o hábito de executar como administrador em sua máquina local. Existem preocupações adicionais quando você está executando como administrador de domínio em sua máquina local - suas credenciais e acesso podem ser usados ​​muito pior do que instalar um vírus em sua máquina, visto que você tem direitos elevados para a maioria das coisas. o domínio inteiro.
HopelessN00b

1
@ HopelessN00b: E você está dizendo que o UAC não se aplica a essas coisas? Por que não? Existem razões técnicas ou a implementação está simplesmente faltando?
Dolda2000

2
@ Dolda2000 Bem, o UAC deveria corrigir o problema, com o malware sendo capaz de usar o contexto do usuário administrativo conectado para se instalar nos PCs dos usuários finais e dos consumidores. E faz. Também impediria que esse vetor específico usasse o contexto de usuário de um administrador de domínio para instalar malware localmente, no entanto, essa não é a extensão das preocupações de segurança envolvidas na execução como administrador de domínio, e não como usuário limitado.
HopelessN00b

1
@ Dolda2000 O UAC impede que os processos executem funções privilegiadas na máquina local. Se você estiver conectado como administrador de domínio, poderá executar comandos privilegiados remotamente em outras máquinas e eles serão executados elevados nas máquinas remotas sem um prompt do UAC. Assim, o malware projetado especificamente para explorar isso pode infectar todo o domínio (e infectar a máquina local usando outra máquina remota) sem que você veja o prompt do UAC.
Monstieur

Respostas:


25

"Práticas recomendadas" geralmente ditam LPU (usuário menos privilegiado) ... mas você está certo (como ETL e Joe são +1) que as pessoas raramente seguem esse modelo.

A maioria das recomendações é feita como você diz ... crie duas contas e não as compartilhe com outras pessoas. Uma conta não deve ter direitos de administrador nem mesmo na estação de trabalho local que você está usando, mas novamente quem segue essa regra, especialmente com o UAC atualmente (que, em teoria, deveria estar ativado).

Existem vários fatores nos quais você deseja seguir esse caminho. Você deve levar em consideração segurança, conveniência, política corporativa, restrições regulatórias (se houver), risco, etc.

Mantendo o Domain Adminse Administratorsnível de domínio grupos agradável e limpo com contas mínimas é sempre uma boa idéia. Mas não compartilhe simplesmente contas de administrador de domínio comuns, se puder evitá-lo. Caso contrário, há o risco de alguém fazer alguma coisa e, em seguida, apontar o dedo entre administradores de sistemas de "não fui eu quem usou essa conta". Melhor ter contas individuais ou usar algo como o CyberArk EPA para auditá-lo corretamente.

Também nessas linhas, seu Schema Adminsgrupo sempre deve estar VAZIO, a menos que você esteja fazendo uma alteração no esquema e depois coloque a conta, faça a alteração e remova a conta. O mesmo poderia ser dito, Enterprise Adminsespecialmente em um modelo de domínio único.

Você também NÃO deve permitir contas privilegiadas na VPN na rede. Use uma conta normal e eleve conforme necessário uma vez dentro.

Por fim, você deve usar o SCOM ou o Netwrix ou algum outro método para auditar qualquer grupo privilegiado e notificar o grupo apropriado na TI sempre que algum dos membros desse grupo for alterado. Isso permitirá que você diga "espere um minuto, por que é tão e tão repentinamente um administrador de domínio?" etc.

No final do dia, há uma razão para a chamada "Melhor prática" e não "Somente prática" ... existem escolhas aceitáveis ​​feitas por grupos de TI com base em suas próprias necessidades e filosofias. Alguns (como Joe disse) são simplesmente preguiçosos ... enquanto outros simplesmente não se importam porque não estão interessados ​​em tapar uma falha de segurança quando já existem centenas e incêndios diários para combater. No entanto, agora que você leu tudo isso, considere-se um dos que combaterá a boa luta e fará o possível para manter as coisas em segurança. :)

Referências:

http://www.microsoft.com/en-us/download/details.aspx?id=4868

http://technet.microsoft.com/en-us/library/cc700846.aspx

http://technet.microsoft.com/en-us/library/bb456992.aspx


O privilégio mínimo se aplica principalmente a contas não administrativas. A separação de credenciais não ajuda da perspectiva menos privada se a cred é usada em um sistema sujo comprometido pela cred privleged mais baixa.
Jim B

É verdade, mas considero que "LPU" também significa apenas dar acesso a grupos privilegiados, conforme necessário. Muitos depósitos de TI. forneça acesso ao DA simplesmente porque é mais fácil do que lidar com uma infinidade de solicitações de acesso.
TheCleaner

28

AFAIK, é considerado uma prática recomendada que os administradores de domínio / rede tenham uma conta de usuário padrão para fazer logon em sua estação de trabalho para executar tarefas rotineiras de "usuário" (email, documentação etc.) e uma conta administrativa nomeada que possua a conta apropriada. associação ao grupo para permitir que eles executem tarefas administrativas.

Este é o modelo que tento seguir, embora seja difícil de implementar se a equipe de TI existente não estiver acostumada a fazê-lo dessa maneira.

Pessoalmente, se eu encontrar uma equipe de TI reticente a seguir nessa direção, sou da opinião de que eles são preguiçosos, inexperientes ou que não entendem a prática da administração do sistema.


12

Essa é uma prática recomendada por motivos de segurança. Como outros já mencionaram, impede que você faça algo acidentalmente ou que você seja comprometido por navegar na rede. Ele também limita o dano que sua navegação pessoal pode causar - idealmente, seu trabalho diário nem deve ter privilégios de administrador local, muito menos administrador de domínio.

Também é incrivelmente útil combater os seqüestros de token de autenticação Pass the Hash ou Windows. ( Exemplo ) Um teste de penetração adequado provará isso facilmente. Ou seja, uma vez que um invasor obtenha acesso a uma conta de administrador local, ele usará esse poder para migrar para um processo com um token de administrador de domínio. Então eles efetivamente têm esses poderes.

Como exemplo de pessoas que usam isso, minha empresa usa! (200 pessoas, equipe de 6 funcionários) De fato, nossos administradores de domínio têm TRÊS contas. Um para uso diário, outro para administração / instalação de software localmente. A terceira são as contas de administrador de domínio e usadas exclusivamente para administrar servidores e o domínio. Se quiséssemos ser mais paranóicos / seguros, um quarto provavelmente estaria em ordem.


Três contas ... interessantes ... eu tenho que considerar que, para a iminente mudança de domínio na minha empresa ...
pepoluan

1
O mesmo na minha empresa. Conta de desktop normal, conta de administrador para acesso de administrador local em computadores clientes E uma conta de administrador de servidor separada. As duas contas de administrador não recebem e-mail nem acesso à Internet. O único problema é que a conta de administrador do servidor precisa de direitos de administrador local na estação de trabalho ou o UAC interfere na execução do MMC localmente com RunAs como a conta de administrador do servidor. (Pode usar RDP a um tudo servidor e executar de lá, mas que é realmente prejudicando, por vezes, se você precisa copiar / colar ou comparar com os dados que é executado no-conta do computador.)
Tonny

Conseguimos nos sair muito bem em ter nosso RDP de administradores de domínio em um servidor para o trabalho de gerenciamento. O Copy & Paste realmente se move incrivelmente bem no RDP. E esse servidor único possui todos os nossos utilitários de gerenciamento já instalados. Mas o que foi dito ... Acredito que o grupo Administradores de Domínio tenha direitos de administrador local por padrão. Eu apenas prefiro que essas credenciais nunca toquem nos desktops, para impedir o roubo de tokens e similares.
Christopher Karel

8

Na minha empresa anterior, insisti que todos os administradores de sistema tivessem 2 contas, ou seja:

  • DOMAIN \ st19085
  • DOMÍNIO \ st19085a ("a" para administrador)

Os colegas ficaram relutantes no começo, mas isso se tornou uma regra geral, depois que a pergunta típica sobre a ameaça de vírus "recebemos um antivírus" foi desmascarada por um banco de dados de vírus desatualizado ...

  • Como você mencionou, o comando RUNAS pode ser usado (eu costumava ter um script em lote, apresentando um menu personalizado, iniciando tarefas específicas com o comando RUNAS).

  • Outra coisa é o uso do Microsoft Management Console , você pode salvar as ferramentas necessárias e iniciá-las com o botão direito do mouse , Executar como ... e sua conta de administrador de domínio.

  • Por último, mas não menos importante, eu costumava iniciar um shell do PowerShell como administrador de domínio e iniciar as coisas necessárias a partir daí.

6
Esta é essencialmente a implementação que eu usei (e forcei a todos os outros) em todos os lugares em que tive a palavra. Você faz logon no seu computador e executa suas tarefas diárias como um usuário normal, assim como todos os outros. Quando você precisa de direitos de administrador, você Run As/ Run as Administratore usa a conta de usuário administrativo. Usar apenas uma conta para tudo é uma má prática de segurança e, na minha experiência, as pessoas que se opõem são as pessoas que mais precisam estar isoladas de executar tudo como administrador de qualquer maneira.
007 HopelessN00b

Uma ótima observação de @ HopelessN00b: "as pessoas que se opõem são as que mais precisam estar isoladas de executar tudo como administrador de qualquer maneira"
mr.b 31/03/14

Na verdade, você deve estar usando uma estação de trabalho separada que foi bloqueado para executar único administrador
Jim B

4

Já trabalhei em locais que fazem as duas coisas e geralmente preferem ter uma conta separada. Na verdade, é muito mais fácil assim, ao contrário do que os usuários / clientes relutantes de joeqwerty parecem pensar:

Prós em usar sua conta normal todos os dias para atividades de administração de domínio: Sim, todas as ferramentas administrativas funcionam na minha estação de trabalho sem runas! W00t!

Contras de usar sua conta normal todos os dias para atividades de administração de domínio: Medo. ;) A tecnologia de desktop pede que você olhe para uma máquina porque ele não consegue descobrir o que há de errado com ela; você faz o login, ela possui um vírus. Desconecte o cabo de rede, altere a senha (em outro lugar). Quando os gerentes perguntam por que você não recebe seu e-mail comercial no seu blackberry pessoal através da operadora de telefonia celular, você explica que eles armazenam sua senha de DOMÍNIO ADMIN em seus servidores quando você faz isso. Etc., etc. Sua senha altamente privilegiada é usada para coisas como ... webmail, vpn, faça login nesta página da web. (Eca.) (Para ser justo, minha conta foi bloqueada na página "alterar sua senha", então pelo menos havia isso. Se eu quisesse alterar minha senha LDAP antiga, sincronizada pela página, teria que ir na mesa de um colega de trabalho.)

Prós do uso de uma conta diferente para atividades de administração de domínio: Intenção. Essa conta é destinada às ferramentas administrativas, etc., e não a emails, webmail, vpn, logins de páginas da Web etc. Por isso, menos medo de que minhas atividades normais de "usuário" exponham riscos a todo o domínio.

Contras de usar uma conta diferente para atividades de administração de domínio: eu tenho que usar runas para ferramentas administrativas. Isso não é tão doloroso.

A versão TL; DR: Ter uma conta separada é simplesmente mais fácil. Também é uma prática recomendada, pois é o privilégio menos necessário .


2

Menos Priv deve ser motivo suficiente, mas, caso contrário, considere também que, se você usa uma conta com as mesmas permissões que seus usuários, é mais provável que sofra com os problemas que eles apresentam - e pode depurá-los em sua própria conta também - muitas vezes antes mesmo de vê-los!

Nada pior do que um administrador que diz "funciona para mim" e fecha o ticket :)


+1 por reconhecer que o uso diário de uma conta no nível do usuário melhora a eficácia da solução de problemas.
Eu digo Reinstate Monica

1

Em toda a teoria, é melhor que você não use um logon de administrador principal para suas atividades diárias. Existem vários motivos, como vírus - se você pegar um vírus e executar o logon de administrador do domínio, o vírus terá uma maneira fácil de acessar sua rede, com acesso total! Os erros possíveis são mais fáceis de se ter certeza, mas não vejo isso como o maior desafio. Se você for ao redor do campus e fizer logon com o administrador principal, alguém poderá estar procurando por sua senha por cima do ombro. Todo tipo de coisas assim.

Mas é prático? Acho difícil seguir essa regra, mas gostaria de segui-la.


0

adicionando meus 2 centavos com base na experiência real ..

saber e manter-se ciente de que você está usando uma conta de administrador para o seu trabalho diário o torna muito cauteloso no que faz. para que você não apenas clique em um email / link ou execute qualquer aplicativo sem verificar três vezes. Eu acho que isso te mantém alerta.

usar uma conta de privilégios mínimos para o seu trabalho diário torna uma pessoa descuidada.


Essa é uma teoria legal, mas, na minha experiência, ela não funciona (pelo menos não para todos). Vi colegas excluindo grandes quantidades de dados dos sistemas de produção por erros (basta um espaço em branco no lugar errado em uma linha de comando).
Gerald Schneider

não é uma teoria, praticamos aqui ;-) Na minha experiência, você examina as pessoas a quem você concederá esses privilégios e não apenas as entrega para as perguntas.
badbanana
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.