CompTIA SY0-701: Gerenciamento de Identidade e Acesso — Guia de estudos

By Laurynas Brazys · 20 July 2026 · #comptia #sy0-701 #certification #exam-prep #study-guide

Faz parte do CompTIA Security+ SY0-701 — Guia de estudos. Pratique com respostas verificadas no centro de exames da CompTIA, ou faça testes cronometrados no ExamRoll.io.

Gerenciamento de Identidade e Acesso (IAM) é a disciplina de garantir que as entidades certas — usuários, serviços e dispositivos — obtenham o acesso correto aos recursos certos, no momento certo, e apenas pelo tempo necessário. Ele se baseia em dois pilares conceitualmente distintos que são frequentemente, e perigosamente, confundidos: autenticação, que prova quem uma entidade é, e autorização, que determina o que essa entidade autenticada pode fazer. Um usuário que faz login em uma estação de trabalho com uma impressão digital se autenticou; se esse usuário pode ou não abrir o banco de dados da folha de pagamento é uma questão de autorização. Qualquer projeto de controle que confunda os dois abre brechas para comprometimentos.

Fatores de Autenticação e Autenticação Multifator

Os fatores de autenticação são tradicionalmente agrupados em cinco categorias: algo que você sabe (senhas, PINs), algo que você tem (smart cards, tokens de hardware, celulares com aplicativos TOTP), algo que você é (impressão digital, retina, geometria facial), um lugar onde você está (geolocalização ou contexto baseado na rede) e algo que você faz (biometria comportamental, como cadência de digitação). A autenticação multifator (MFA) exige evidências de pelo menos duas categorias diferentes. Uma senha combinada com uma pergunta de segurança não é MFA — ambos são “algo que você sabe”. Uma senha combinada com um código TOTP do Google Authenticator é MFA.

Tokens de hardware vêm em várias formas. Chaves de segurança FIDO2/WebAuthn, como YubiKeys, usam criptografia assimétrica: a chave privada nunca sai do dispositivo, e o servidor detém apenas uma chave pública, o que impede phishing e ataques de repetição (replay). Tokens HOTP geram senhas de uso único a partir de um contador; tokens TOTP as geram a partir da hora atual usando uma construção HMAC-SHA1:

TOTP = HMAC-SHA1(shared_secret, floor(current_unix_time / 30))

Smart cards, comumente cartões PIV ou CAC em ambientes governamentais, armazenam um certificado X.509 e uma chave privada em um chip resistente a violações. A apresentação do cartão, combinada com um PIN, satisfaz dois fatores e permite a autenticação baseada em certificado em sistemas como o Active Directory via Kerberos PKINIT.

MFA é o controle isolado mais eficaz contra o roubo de credenciais. Quando usuários relatam logins de endereços IP que não originaram, redefinir as senhas trata o sintoma; impor o MFA trata a causa raiz, porque uma senha roubada por si só se torna insuficiente.

Single Sign-On e Federação

O single sign-on (SSO) permite que um usuário se autentique uma vez e acesse múltiplos aplicativos sem reinserir as credenciais. A Federação estende isso através de fronteiras organizacionais ou de confiança — o provedor de identidade (IdP) de um usuário em um domínio atesta a identidade do usuário para um provedor de serviço (SP) em outro. O equívoco mais comum aqui é tratar SAML e OAuth como intercambiáveis; eles resolvem problemas diferentes.

SAML 2.0 é um protocolo baseado em XML projetado para SSO empresarial e asserções de autenticação. Quando um usuário solicita um aplicativo SaaS, o SP redireciona o navegador para o IdP, que autentica o usuário e retorna uma asserção SAML assinada contendo atributos de identidade. Este é o mecanismo padrão para permitir que funcionários acessem aplicativos na nuvem como Salesforce ou Workday usando credenciais corporativas do Active Directory.

OAuth 2.0 é um framework de autorização, não um protocolo de autenticação. Ele concede a um aplicativo de terceiros acesso delegado a um recurso em nome do usuário por meio de tokens de acesso. Permitir que um aplicativo poste no seu feed do Twitter é um fluxo OAuth. O OpenID Connect (OIDC) é uma camada de identidade construída sobre o OAuth 2.0 que adiciona um id_token (um JWT) fornecendo asserções de autenticação — é isso que torna o “Fazer login com o Google” possível.

Um ponto de atenção crítico: SSO e federação reduzem a proliferação de credenciais, mas não eliminam a necessidade de MFA. Na verdade, eles concentram o risco — uma credencial de SSO comprometida agora desbloqueia todos os aplicativos federados. O MFA deve ser imposto no IdP, e contas privilegiadas devem exigir autenticação step-up mesmo após o SSO.

Modelos de Controle de Acesso

Uma vez que a identidade é estabelecida, um modelo de controle de acesso rege as decisões de autorização. O Controle de Acesso Discricionário (DAC) permite que os proprietários dos recursos definam permissões, geralmente por meio de listas de controle de acesso (ACLs). O Controle de Acesso Obrigatório (MAC) impõe políticas centralmente com base em rótulos e níveis de autorização (clearances), comum em sistemas militares e aplicado por frameworks como o SELinux. O Controle de Acesso Baseado em Função (RBAC) atribui permissões a funções e usuários a funções — uma função de “Analista de Faturamento” carrega um conjunto de permissões definido, e os usuários herdam permissões pela associação à função. O Controle de Acesso Baseado em Atributos (ABAC) avalia políticas com base em atributos da entidade, do recurso, da ação e do ambiente, permitindo regras como “permitir acesso de leitura a arquivos de RH apenas durante o horário comercial a partir de dispositivos gerenciados pela empresa”.

Aplicável a todos os modelos está o princípio do menor privilégio: as entidades recebem apenas o acesso mínimo necessário para executar sua função, e nada mais. Complementar a isso está a separação de funções, que impede que um único indivíduo controle todo um processo sensível — a pessoa que solicita um pagamento não deve ser a mesma que o aprova.

Controles de acesso práticos incluem ACLs de sistema de arquivos, ACLs de rede em roteadores e firewalls, e restrições de horário que permitem o login apenas durante as horas autorizadas. Uma entrada de ACL do Windows concedendo acesso somente leitura a um compartilhamento de finanças pode ser lida como:

icacls C:\Finance /grant "Domain\Finance-RO:(OI)(CI)R"

Gerenciamento de Acesso Privilegiado

Contas privilegiadas — administradores de domínio, root, administradores de banco de dados (sysadmins), contas root da nuvem, contas de serviço — são as joias da coroa de qualquer ambiente. Sistemas de Gerenciamento de Acesso Privilegiado (PAM), como CyberArk, BeyondTrust ou HashiCorp Vault, impõem controles em torno dessas contas: as credenciais são armazenadas em cofre (vaulted) e rotacionadas automaticamente, as sessões são gravadas, o checkout requer justificativa e, muitas vezes, aprovação, e as senhas são frequentemente de uso único ou efêmeras.

O acesso Just-in-Time (JIT) eleva os privilégios apenas pela duração de uma tarefa específica, eliminando direitos de administrador permanentes. Um desenvolvedor que precisa executar uma migração de banco de dados recebe uma credencial com tempo limitado que expira automaticamente após 30 minutos — não há uma conta privilegiada persistente para ser roubada. O Privileged Identity Management (PIM) no Azure AD implementa esse padrão nativamente, exigindo fluxos de trabalho de aprovação e reautenticação com MFA antes da elevação.

Contas de serviço apresentam um desafio distinto. Elas geralmente têm privilégios excessivos, suas senhas raramente são rotacionadas e seu uso raramente é auditado. As Managed Service Accounts (MSAs) e Group Managed Service Accounts (gMSAs) no Active Directory automatizam a rotação de senhas e eliminam a necessidade de humanos saberem as credenciais de contas de serviço.

Serviços de Diretório e Provisionamento

O Active Directory (AD) continua sendo o repositório de identidades on-premises dominante. Usuários, computadores e grupos são organizados em Unidades Organizacionais (OUs), e os Objetos de Política de Grupo (GPOs) aplicam configurações e definições de segurança hierarquicamente. As relações de confiança (trusts) do AD estendem a autenticação entre domínios e florestas. O Azure Active Directory (Entra ID) estende esses conceitos para a nuvem, adicionando políticas de acesso condicional, pontuação de risco de proteção de identidade e integração transparente com milhares de aplicativos SaaS.

O LDAP (Lightweight Directory Access Protocol) é o protocolo subjacente para consultar serviços de diretório. O RADIUS centraliza a autenticação para acesso à rede — VPN, Wi-Fi e autenticação com fio 802.1X comumente se autenticam em um servidor RADIUS respaldado pelo AD. O TACACS+ desempenha um papel semelhante para a administração de dispositivos de rede, com o benefício adicional de separar a autenticação, a autorização e a auditoria (accounting) em fases distintas.

O provisionamento e o desprovisionamento de usuários devem estar fortemente acoplados aos processos de RH. A falha mais persistente de IAM é a conta órfã — a conta do Active Directory de um ex-funcionário que permanece ativa semanas ou meses após sua saída. O provisionamento automatizado via SCIM (System for Cross-domain Identity Management) ou conectores do RH para o AD, combinado com checklists obrigatórios de desprovisionamento, fecha essa lacuna.

Cenário Prático: Comprometimento de Credenciais por Meio de uma Conta Órfã

A equipe de TI de uma empresa de manufatura descobriu um acesso incomum fora do horário de expediente ao seu sistema de ERP a partir de uma conta de serviço que havia sido criada para um projeto de integração já descontinuado. A conta tinha direitos de usuário de domínio e nunca havia sido revisada durante as revisões de acesso trimestrais porque não estava associada a um funcionário nomeado. Um invasor que comprou as credenciais de um despejo (dump) da dark web usou a conta para enumerar compartilhamentos de arquivos, exfiltrar dados de precificação e estabelecer uma base persistente (foothold) por meio de uma tarefa agendada. A violação foi descoberta apenas quando o fornecedor do ERP sinalizou padrões anômalos de chamadas de API. A causa raiz foi uma falha no processo de desprovisionamento — a integração foi descomissionada, mas a conta nunca foi desativada. A implementação de um sistema PAM com descoberta automatizada de contas órfãs e ciclos de revisão obrigatórios teria revelado a conta muito antes de ser explorada.

← Governança · Todos os domínios · Ameaças →

Pratique estas questões → · Prática cronometrada no ExamRoll.io →