O escalonamento de privilégios impede o root diretamente

O escalonamento de privilégios impede o root diretamente

Acho que este será meu primeiro post no lado da casa do StackExchange. No entanto, sei que isso precisa ser configurado porque já o vi implementado anteriormente, mas na verdade não sei como é implementado.

O que pretendo fazer é no RedHat 7/8 ou derivado... Como posso fazer com que um usuário conduza os seguintes escalonamentos de privilégios:

<user> -> <user>.adm -> root

  • Os usuários da IdM no grupo ssh_users podem usar SSH para os servidores de qualquer lugar na(s) rede(s).
  • Os Administradores de Domínio na IdM não podem ser usados ​​para SSH para servidores e não estão no grupo.
  • Os usuários que são administradores de domínio devem usar SSH para seu usuário padrão sudo su - <user>.adm. Eles não podem fazer root diretamente.
  • Os usuários que são administradores de domínio e também têm acesso root devem sudo su - <user>.admprimeirosudo su - root
  • Nem todos os administradores de domínio têm permissão para obter escalonamento root.

Em última análise, os Administradores de Domínio são os Administradores do Sistema com permissões relevantes para manter, solucionar problemas e corrigir o sistema. Os engenheiros de sistema têm permissão para obter root, o que lhes dá permissões completas no sistema. Isso também envolve a delegação de responsabilidades, onde apenas contas de auditoria <user>.issotêm permissão para excluir logs fora do usuário root. O que é, em última análise, o que origina esta exigência.

O que realmente estou procurando é documentação que possa (porque estou desenhando espaços em branco) que possa me apontar na direção certa ou funções/manuais do Ansible que façam funcionalmente esse tipo de abordagem de privilégio mínimo. Qualquer ajuda seria muito apreciada!

Responder1

Os usuários que são administradores de domínio e também têm acesso root devem sudo su - <user>.admprimeirosudo su - root

Conceitualmente eupensarque o que você deve querer e precisar alcançar é:

Todos os administradores têm duas contas pessoais:

  1. uma conta de usuário "normal"
  2. uma conta de administrador

Para obter direitos totais de administrador em um servidor Linux:

  1. o administrador primeiro precisa fazer login com sua conta de usuário normal<user>

  2. uma vez logados no servidor, eles aumentam seus privilégios fazendo login em sua conta de administrador pessoal<user>.adm

    • sudo su - <user>.adm solicita a senha da <user>conta e, em seguida, com privilégios de root, substitui o usuário por <user>.adm.
    • ^^^ Essa é a abordagem errada IMHO
      Você deve querer que seus administradores usem su - <user>.adm
      Isso significa que seu administrador será solicitado a inserir a senha da <user>.admconta (em vez da senha da <user>conta) para fazer login como <user>.adm.
      • Então, desde que seus administradores não tenham a mesma senha em suas contas adm e em suas contas normais, uma senha comprometida não será suficiente para se tornar root em todos os seus servidores. GANHAR!
      • Além disso, não há nenhuma sudopolítica necessária para sua conta de usuário normal <user>. GANHAR!
  3. Uma vez conectado com uma conta de administrador pessoal, isso permitirá que eles executem todas as ações que exijam rootprivilégios.

    Isso requer a criação de uma sudopolítica. Há informações mais que suficientes sobre isso.

    Minha preferência é usar o #includedir /etc/sudoers.dmecanismo incluído na maioria /etc/sudoersdas políticas modernas ( #não há comentários!) E descartar um arquivo (que não inclua um .no nome do arquivo) e configurar políticas dessa forma.

    Uma opção é ter uma política para hbruijn.admpessoalmente, ou seja /etc/sudoers.d/hbruijn_adm:

    # /etc/sudoers.d/hbruijn_adm 
    # sudo policy that allow HBruijn's admin account to perform all
    # as any user, without prompting for a password
    hbruijn.adm  ALL = NOPASSWD: ALL
    

    Como alternativa, quando todas as contas de administrador com permissão para obter privilégios de root completos em sistemas Linux pertencem a um grupo específico, configure uma política baseada em grupo.


Está implícito que você também evita que seus administradores possam fazer login diretamente em suas contas de administrador.

Isso pode ser, por exemplo, para que o acesso remoto SSH seja obtido usando uma DenyUsersdiretiva nos servidores /etc/ssh/sshd_configpara impedir que um usuário específico, ou usuários que correspondam a um padrão, efetuem logon:

# /etc/ssh/sshd_config
#here go defaults for all connections/users
PasswordAuthentication no
PubkeyAuthentication no
...
DenyUsers *.adm 

Como alternativa, use algo semelhante DenyGroupspara configurar uma política baseada em grupo.

informação relacionada