Preparatório Caixa TI: Sistemas Operacionais — administração, serviços e virtualização

Administração de usuários e grupos

Em ambientes corporativos, a administração de usuários e grupos organiza quem pode acessar recursos (arquivos, serviços e sistemas) e com quais privilégios. A prática recomendada é conceder o menor privilégio possível (least privilege), usando grupos para facilitar a gestão em escala.

Conceitos essenciais

• Usuário: identidade que executa ações no sistema (login, execução de processos, acesso a arquivos).
• Grupo: conjunto de usuários para aplicar permissões de forma coletiva (ex.: grupo suporte, dev, auditoria).
• Privilégios administrativos: contas com permissão de administrar o sistema (ex.: root/Administrador). Em Linux, é comum delegar via sudo; em Windows, via grupos locais/de domínio.
• Conta de serviço: usuário “técnico” usado por um serviço/daemon para rodar com permissões restritas (boa prática: não rodar serviços como administrador/root).

Passo a passo prático (Linux – conceitual com comandos típicos)

1) Criar um grupo e um usuário

# cria grupo de equipe (ex.: appteam) e usuário (ex.: joao) e associa ao grupo principal
sudo groupadd appteam
sudo useradd -m -s /bin/bash -g appteam joao
sudo passwd joao

2) Adicionar usuário a grupos secundários

# adiciona joao ao grupo de logs/auditoria (exemplo)
sudo usermod -aG adm joao

3) Delegar tarefas administrativas com sudo (boa prática)

# editar com segurança (visudo) e permitir apenas comandos necessários
sudo visudo
# exemplo de regra (conceitual): permitir reiniciar um serviço específico
# joao ALL=(root) NOPASSWD: /bin/systemctl restart nginx

Boas práticas: evitar compartilhamento de contas; usar grupos para permissões; registrar ações administrativas; revisar periodicamente usuários inativos e privilégios excessivos.

Continue em nosso aplicativo

Você poderá ouvir o audiobook com a tela desligada, ganhar gratuitamente o certificado deste curso e ainda ter acesso a outros 5.000 cursos online gratuitos.

ou continue lendo abaixo...

Baixar o aplicativo

Permissões e controle de acesso

Permissões definem quem pode ler, escrever ou executar recursos. Em provas e no dia a dia, é comum cair a lógica de “quem tem acesso a quê” e como ajustar de forma segura.

Modelo clássico (Linux): dono, grupo e outros

• r (read): ler conteúdo/listar
• w (write): alterar/criar/remover
• x (execute): executar arquivo / atravessar diretório

Em diretórios, o bit x significa “entrar/atravessar” o diretório; sem ele, mesmo com leitura, pode não ser possível acessar arquivos dentro.

Passo a passo prático (Linux)

1) Inspecionar permissões

ls -l /caminho
# exemplo de saída: -rw-r----- 1 joao appteam 1234 arquivo.txt

2) Alterar dono e grupo

sudo chown joao:appteam arquivo.txt

3) Ajustar permissões com chmod

# modo simbólico
chmod g+r arquivo.txt
# modo octal (ex.: 640 = rw- r-- ---)
chmod 640 arquivo.txt

4) Permissões padrão com umask (conceito)

# umask define o que será removido das permissões padrão ao criar arquivos
umask

ACL (Access Control List) – quando o modelo simples não basta

ACL permite conceder permissões específicas para usuários/grupos adicionais sem “forçar” mudança de grupo/dono. Útil quando múltiplas equipes precisam de acessos diferentes ao mesmo diretório.

# exemplo conceitual
setfacl -m u:maria:rwX /dados/projeto
getfacl /dados/projeto

Boa prática: preferir grupos e estrutura de diretórios bem planejada; usar ACL quando houver necessidade real de exceções controladas.

Serviços/daemons: gerenciamento e dependências

Serviços (daemons) são processos em segundo plano que oferecem funcionalidades como servidor web, banco, fila, monitoramento, autenticação etc. Administrar serviços envolve iniciar/parar, habilitar no boot, verificar status, dependências e logs.

Passo a passo prático (Linux com systemd – abordagem comum)

1) Verificar status

systemctl status nginx

2) Iniciar, parar e reiniciar

sudo systemctl start nginx
sudo systemctl stop nginx
sudo systemctl restart nginx

3) Habilitar/desabilitar no boot

sudo systemctl enable nginx
sudo systemctl disable nginx

4) Entender falhas rapidamente

# últimos logs do serviço
journalctl -u nginx --since "10 min ago"

Boas práticas operacionais com serviços

• Rodar com usuário de serviço dedicado e permissões mínimas.
• Configurar restart policy (reinício automático) quando apropriado, evitando loops infinitos sem diagnóstico.
• Separar configuração (arquivos) de dados (state) e de logs.
• Documentar portas, dependências (ex.: serviço A depende de B) e checks de saúde.

Logs: coleta, leitura e correlação

Logs são a principal fonte para diagnóstico de incidentes: falhas de serviço, erros de autenticação, problemas de rede, falta de espaço, permissões, timeouts. O objetivo operacional é responder: “o que aconteceu, quando, com qual impacto e qual componente?”.

Tipos comuns de logs

• Logs do sistema: kernel, inicialização, hardware, autenticação.
• Logs de aplicação: erros e eventos específicos do software.
• Logs de auditoria: ações administrativas, acessos sensíveis.

Passo a passo prático (Linux)

1) Consultar logs do sistema (journal)

# últimas linhas
journalctl -n 200
# filtrar por unidade/serviço
journalctl -u ssh --since "today"

2) Buscar padrões rapidamente

# procurar por erro em arquivo de log tradicional
sudo grep -i "error" /var/log/syslog

3) Correlacionar por tempo

# filtrar por janela temporal
journalctl --since "2026-01-15 10:00" --until "2026-01-15 10:30"

Boa prática: padronizar timestamps, manter retenção adequada, centralizar logs quando há múltiplos servidores e proteger logs contra alteração indevida (integridade).

Agendamento de tarefas: rotinas e automação

Agendamento é usado para rotinas como limpeza de temporários, rotação de logs, backups, relatórios e verificações de saúde. O cuidado principal é evitar tarefas concorrentes, garantir idempotência e registrar saída/erros.

Passo a passo prático (cron – Linux)

1) Editar crontab do usuário

crontab -e

2) Exemplo de agendamento

# Executa todo dia às 02:30
30 2 * * * /usr/local/bin/rotina_backup.sh >> /var/log/backup.log 2>&1

3) Verificar tarefas agendadas

crontab -l

Boas práticas em agendamentos

• Redirecionar saída e erros para log.
• Usar lock (arquivo de trava) para impedir execução simultânea.
• Evitar depender de variáveis de ambiente implícitas; definir PATH no script.
• Testar manualmente o comando antes de agendar.

Gerenciamento de pacotes e atualizações (nível conceitual)

Gerenciamento de pacotes controla instalação, atualização e remoção de software. Em ambiente corporativo, o foco é previsibilidade: saber o que mudou, quando e por quê, reduzindo indisponibilidades.

Conceitos

• Repositório: fonte confiável de pacotes assinados.
• Dependências: bibliotecas e componentes necessários para um pacote funcionar.
• Atualização de segurança: corrige vulnerabilidades; costuma ter prioridade.
• Atualização funcional: muda versões e pode alterar comportamento; exige validação.

Boas práticas de atualização

• Manter inventário de versões e pacotes críticos.
• Separar ambientes (ex.: homologação/produção) e aplicar janela de mudança.
• Preferir atualizações automatizadas apenas para patches de segurança quando houver política e monitoramento.
• Ter plano de rollback (reversão) e backups antes de mudanças relevantes.
• Após atualizar, validar: serviço sobe, portas respondem, logs sem erros, consumo normal de CPU/memória.

Virtualização: máquinas virtuais vs containers

Virtualização permite isolar cargas de trabalho, padronizar ambientes e melhorar o uso de recursos. Para a prova, é essencial diferenciar máquinas virtuais (VMs) e containers e escolher o caso de uso adequado.

Máquinas virtuais (VMs)

• O que são: cada VM roda um sistema operacional completo (kernel próprio), sobre um hipervisor.
• Vantagens: isolamento forte; suporta diferentes sistemas operacionais no mesmo host; adequado para workloads legados.
• Desvantagens: maior consumo de recursos; boot mais lento; imagens maiores.
• Casos de uso: aplicações que exigem kernel específico; ambientes com requisitos rígidos de isolamento; consolidação de servidores.

Containers

• O que são: empacotam aplicação e dependências, compartilhando o kernel do host; isolamento via namespaces/cgroups (conceito).
• Vantagens: leveza; inicialização rápida; alta densidade; facilita padronização de deploy.
• Desvantagens: isolamento geralmente menor que VM; dependência do kernel do host; exige disciplina de imagens e segurança.
• Casos de uso: microsserviços; jobs efêmeros; escalabilidade rápida; pipelines de CI/CD; ambientes consistentes de execução.

Como decidir (regra prática)

• Precisa de SO diferente ou isolamento máximo? Tende a VM.
• Precisa de agilidade, escala e padronização para aplicações? Tende a container.
• Ambientes modernos frequentemente usam VMs como base e containers dentro delas (defesa em camadas).

Alta disponibilidade: cluster e failover

Alta disponibilidade (HA) busca reduzir indisponibilidade por falhas. Em termos operacionais, envolve redundância, detecção de falha e comutação (failover) para manter o serviço ativo.

Conceitos objetivos

• Single Point of Failure (SPOF): componente único cuja falha derruba o serviço (ex.: um único servidor de aplicação).
• Cluster: conjunto de nós que cooperam para entregar um serviço (ativo-ativo ou ativo-passivo).
• Failover: troca automática (ou manual) do nó primário para um secundário quando há falha.
• Health check: verificação de saúde (porta, endpoint, processo, latência) usada para decidir se um nó está apto.
• Stateful vs stateless: serviços sem estado (stateless) são mais fáceis de escalar e fazer failover; serviços com estado exigem replicação/consistência.

Ativo-ativo vs ativo-passivo (quando usar)

• Ativo-ativo: múltiplos nós atendem ao mesmo tempo. Melhor uso de recursos; exige cuidado com sessão/estado e consistência.
• Ativo-passivo: um nó atende e outro fica em espera. Mais simples; pode ter custo de recursos ociosos; failover precisa ser bem testado.

Pontos de atenção em HA

• DNS vs balanceador: DNS pode ter cache/TTL; balanceador com health check tende a reagir mais rápido.
• Dados: replicação, backups e testes de restauração são parte do desenho de HA.
• Split-brain (conceito): dois nós acreditam ser primários; pode causar corrupção de dados. Mitigação envolve quorum/coordenação.

Questões de prática (diagnóstico e escolha de ferramentas/abordagens)

1) Serviço não inicia após atualização

Você atualizou um pacote e o serviço passou a falhar ao iniciar. Qual sequência de diagnóstico é mais adequada?

• A) Reiniciar o servidor repetidamente até funcionar.
• B) Verificar status do serviço, consultar logs do serviço e do sistema, validar arquivo de configuração e dependências, e só então decidir rollback/ajuste.
• C) Desinstalar todos os pacotes relacionados e reinstalar sem checar logs.
• D) Alterar permissões de diretórios aleatórios para 777.

2) Usuário acessa diretório, mas não consegue listar arquivos

Qual permissão provavelmente está faltando no diretório?

• A) Permissão de escrita (w).
• B) Permissão de execução (x) no diretório.
• C) Permissão de execução (x) no arquivo.
• D) Permissão de leitura (r) no arquivo.

3) Aplicação precisa escalar rapidamente em picos

Você precisa subir instâncias rapidamente para atender aumento de demanda. Qual abordagem tende a ser mais adequada?

• A) Máquinas virtuais completas, sempre, independentemente do caso.
• B) Containers, por serem mais leves e rápidos para replicar, desde que o desenho da aplicação permita.
• C) Executar tudo como root para simplificar.
• D) Desabilitar logs para ganhar desempenho.

4) Falha intermitente em produção: por onde começar?

O sistema apresenta lentidão e timeouts em horários específicos. Qual combinação de ferramentas/abordagens é mais apropriada?

• A) Verificar logs por janela de tempo, correlacionar com agendamentos (cron), checar consumo de recursos e status de serviços.
• B) Alterar a senha de todos os usuários e reiniciar.
• C) Remover o agendamento sem investigar e torcer para resolver.
• D) Aumentar permissões de todos os diretórios para acelerar acesso.

5) Failover não ocorre quando o nó primário cai

Qual hipótese é mais plausível para investigar primeiro?

• A) Health check mal configurado, dependência de DNS/TTL alto, ou ausência de mecanismo de detecção/coordenação no cluster.
• B) Falta de permissões de leitura em um arquivo de usuário comum.
• C) Umask incorreta em um diretório temporário.
• D) O sistema não possui logs, então não há como investigar.