Qual é a diferença entre usuário e conta de serviço?

7

Gostaria de saber a diferença entre conta de usuário e de serviço.

Eu sei que, por exemplo Jenkins instalado no Ubuntu não é um usuário, mas conta de serviço .

  1. Qual é o uso da conta de serviço?
  2. Quando precisamos deles?
  3. Como posso criar uma conta de serviço?
por Rudziankoŭ 06.10.2016 / 14:31

4 respostas

8

Contas de usuário são usadas por usuários reais, contas de serviço são usadas por serviços do sistema, como servidores da Web, agentes de transporte de email, bancos de dados etc. Por convenção, e apenas por convenção, contas de serviço têm IDs de usuário na faixa baixa, por exemplo < 1000 ou mais. A menos que para o UID 0, as contas de serviço não têm privilégios especiais. As contas de serviço podem - e geralmente possuem - recursos específicos, até mesmo arquivos especiais de dispositivos, mas não têm privilégios de superusuário.

Contas de serviço podem ser criadas como contas de usuário comuns (por exemplo, usando useradd ). No entanto, as contas de serviço geralmente são criadas e configuradas pelo gerenciador de pacotes na instalação do software de serviço. Portanto, mesmo como administrador, você raramente deve se preocupar diretamente com a criação de contas de serviço.

Por um bom motivo: Em contraste com as contas de usuário, as contas de serviço geralmente não têm um shell de login "adequado", ou seja, elas têm /usr/sbin/nologin como shell de login (ou, antigamente, /bin/false ). Além disso, as contas de serviço normalmente são bloqueadas, ou seja, não é possível efetuar login (para os tradicionais /etc/passwd e /etc/shadow , isso pode ser feito configurando o hash de senha para valores arbitrários, como * ou x ). Isso é para proteger as contas de serviço contra abusos ( defesa em profundidade ).

Ter contas de serviço individuais para cada serviço tem duas finalidades principais: é uma medida de segurança para reduzir o impacto em caso de incidente com um serviço (compartimentalização ) e simplifica a administração à medida que se torna mais fácil rastrear quais recursos pertencem a qual serviço. Consulte este ou isto responde a perguntas relacionadas para mais detalhes.

    
por 06.10.2016 / 14:59
3

Originalmente, os usuários tinham a intenção de corresponder a um humano usando o sistema, daí o nome. Cada processo é executado como um usuário específico e cada arquivo é de propriedade de um usuário específico. Um usuário especial, chamado root, é usado para coisas que não pertencem a nenhum usuário humano específico, ou seja, o próprio sistema operacional. Como root corresponde ao próprio sistema operacional, ele tem todos os privilégios.

Logo as pessoas descobriram que era conveniente criar vários usuários do sistema, sem privilégios abrangentes. Isso permite isolar os vários serviços que são executados em uma máquina, para que eles não peguem nos dedos uns dos outros. Uma conta de serviço (ou “conta do sistema”, esses dois termos são sinônimos) é aquela que corresponde a um serviço em execução no sistema, e não a alguém que usa o sistema. Você geralmente tem uma conta de serviço para cada tarefa em execução no sistema que tenha seu próprio conjunto de privilégios (por exemplo, seus próprios arquivos, suas próprias portas de rede, etc.).

Não existe uma definição formal de conta humana vs. sistema / serviço. O kernel não se importa (além de conceder muitos privilégios ao usuário com o UID 0). A maioria dos comandos de administração também não se importa. Algumas diferenças típicas são:

  • Um usuário humano tem um nome real como "John Doe", enquanto um usuário do sistema tem um nome descritivo como "Nasal daemon" ou nenhum.
  • Um usuário humano tem um shell de login real (por exemplo, /bin/sh ou /bin/bash ou /bin/csh . Alguns usuários do sistema têm um shell (quase sempre /bin/sh ), outros não, dependendo de como eles são a ser usado (por exemplo, su foo requer que foo tenha uma casca).
  • Um usuário humano geralmente tem uma senha - mas nem sempre é esse o caso, por exemplo, um usuário somente remoto pode ter apenas uma chave SSH. Observe que nos unices modernos, a senha não está em /etc/passwd , mas em algum outro arquivo, como /etc/shadow .
  • O diretório pessoal de um usuário humano geralmente está em /home (ou algum local específico do site), enquanto o diretório inicial de um usuário do sistema geralmente não está em /home e pode não existir (mas há exceções).
  • A maioria dos sites designa um intervalo de IDs de usuário para usuários do sistema e um intervalo disjunto para usuários humanos. Reservar 100–65533 ou 500–65533 ou 1000–65533 é típico, e a maioria das distribuições é configurada para começar a alocar IDs de usuários reais de 500 ou 1.000.

Nos sites em que as contas são compartilhadas em várias máquinas, geralmente há um servidor central que contém listas de usuários, acessíveis por NIS ou LDAP . A entrada passwd em /etc/nsswitch.conf especifica onde encontrar informações do usuário. É comum ter usuários do sistema no local /etc/passwd e usuários reais do banco de dados em toda a rede, mas às vezes há usuários do sistema no banco de dados em toda a rede (para impor UIDs consistentes, o que facilita a replicação de dados e servidores) e às vezes, há usuários humanos no arquivo local (para permitir que eles efetuem login mesmo quando a rede é operada).

Uma conta acessível a humanos disfarçada como um usuário do sistema normalmente não teria um nome real, mas teria um shell de login e um conjunto de senhas ou uma chave SSH, ao mesmo tempo em que teria um ID de usuário no intervalo do sistema. Na verdade, seria um disfarce melhor usar uma conta do sistema real cuja remoção faria com que algum serviço parasse de funcionar. Mas você não pode ter regras rígidas para detectar possíveis ataques: por definição, os invasores não seguem as regras.

Contas de serviço e contas humanas são gerenciadas pelos mesmos comandos e registradas nos mesmos arquivos. Os comandos de criação de conta podem ter opções para definir padrões razoáveis para usuários humanos e de serviço, por exemplo, para escolher um ID de usuário no intervalo adequado e solicitar uma senha para um humano e desativar a autenticação de senha para um serviço. Por exemplo, adduser vs adduser --system ou useradd vs useradd -r no Linux.

    
por 10.10.2016 / 02:13
1

Uma conta de serviço pode não ter a capacidade de usar um shell, por exemplo. É usado para executar serviços (daemon) com escopo e privilégios restritos. Minha opinião é que você pode criá-lo como um usuário regular, apenas tomando cuidado com os direitos e membros do grupo. No entanto, na maioria das vezes, você não faz isso porque os programas os criam automaticamente durante a instalação. Dê uma olhada em /etc/passwd root:x:0:0:root:/root:/bin/bash

0 é o UID, ele caracteriza a hierarquia da conta no espaço do usuário, o root está acima de todo mundo, então você tem o grupo membership :root do diretório home /root finalmente o shell usado pela conta /bin/bash para 'logar' no sistema.

Você pode usar /usr/sbin/nologin para uma conta que não deseja privilégio de login.

    
por 06.10.2016 / 14:55
1
    1. uma conta de serviço, a.k.a. conta técnica é uma conta projetada para ser usada apenas por um serviço / aplicativo, não por um usuário comum.
    1. Os desenvolvedores de aplicativos e serviços querem que essas contas restrinjam os direitos e privilégios de processos associados, em vez de executar seus processos como raiz. Os serviços iniciados por init , systemd ou similar, que são executados como raiz, são rapidamente reduzidos à conta de serviço para limitar os riscos. Dependendo do sistema operacional usado, as contas do aplicativo podem receber mais privilégios do que contas regulares, por exemplo, o direito de ligar-se a uma porta TCP privilegiada ou, ao contrário, ter seus privilégios reduzidos em comparação a um usuário comum, por exemplo, negando que os processos de serviço chamem fork / exec . Nesse caso, não há necessidade de fazer o downgrade dos serviços para a conta de serviço, eles podem ser iniciados com ele.
    1. Você não deve precisar, mas apenas criar uma conta sem uma senha utilizável e com um shell que não funcione (por exemplo, /bin/false ) e não será utilizável por um usuário comum, ou seja, não haverá como registrar em local ou remotamente (por exemplo, através de ssh ) usando o nome da conta. Como a maioria das limitações, usar a conta root ou sudo permite superá-la.
por 06.10.2016 / 14:51