EAP-TLS vs PEAP: Segurança, certificados e adequação
Published
O conselho mais comum sobre eap tls vs peap é simples e errado. Escolha o EAP-TLS porque é "mais seguro," e deixe o PEAP para as equipas que ainda não se atualizaram. Isso ignora a questão que decide se uma WLAN de múltiplos locais continua a funcionar numa segunda-feira. Consegue emitir, renovar e revogar um certificado para cada dispositivo que o deveria utilizar?
Eu não aplicaria apenas um método a toda a propriedade. O EAP-TLS pertence a dispositivos que pode inscrever e renovar. O PEAP, quase sempre com EAP-MSCHAPv2 interno, pertence aos casos em que já existe uma palavra-passe de diretório e a inscrição de certificados não é viável. O método mais complexo nem sempre é aquele que consegue executar. Um certificado expirado no back office de um hotel bloqueia o acesso dos funcionários enquanto as suas contas permanecem válidas. Um perfil PEAP que ignora a verificação do servidor pode entregar uma palavra-passe de diretório a um access point malicioso. Ambas as falhas são operacionais. Atribua o método ao grupo de utilizadores em vez de procurar uma solução única para toda a rede.
Índice
- EAP-TLS e PEAP Lado a Lado
- Como Cada Método Autentica e Onde as Palavras-passe Surtim Fuga
- Requisitos de Certificados Antes da Implantação
- Ciclo de Vida dos Certificados e Esforço de Implantação
- Revogação, Velocidade de Roaming e Suporte do Cliente
- Atribua Cada População e Comprove a Divisão
EAP-TLS e PEAP Lado a Lado
A diferença prática entre EAP-TLS e PEAP reside nas credenciais que cada ponto final pode suportar e no trabalho necessário para as manter utilizáveis. Utilize EAP-TLS para dispositivos que possa inscrever e renovar. Utilize PEAP onde os utilizadores já tenham palavras-passe de diretório e a inscrição de certificados não seja prática. Nenhum dos métodos é a resposta certa para todas as populações.
| Critério | EAP-TLS | PEAP |
|---|---|---|
| ID do tipo EAP | 13 | 26 |
| Credencial do cliente | Certificado de cliente X.509 | Nome de utilizador e palavra-passe, geralmente EAP-MSCHAPv2 ou EAP-GTC |
| Credencial do servidor | Certificado do servidor RADIUS | Certificado do servidor RADIUS no túnel TLS externo |
| Autenticação mútua | Certificados de cliente e servidor | Certificado do servidor e autenticação interna de utilizador ou dispositivo |
| Palavra-passe em trânsito | Nenhuma | Sim, dentro do túnel TLS |
| O que um AP falso pode roubar se o cliente ignorar as verificações do servidor | Nada semelhante a uma palavra-passe; a autenticação falha em modo seguro | Palavra-passe do diretório |
| Revogação de um dispositivo | Revogar ou expirar esse certificado | Desativar a conta ou redefinir uma palavra-passe que possa ser reutilizada |
| Trabalho de PKI | Certificados de servidor e cliente, renovação e recuperação | Apenas certificado do servidor |
| Melhor aplicação inicial | Funcionários geridos por MDM e dispositivos privilegiados | Dispositivos não geridos que não conseguem registar certificados |
Um artigo técnico da Authentik de 2025 identifica o EAP-TLS como EAP do tipo ID 13 e o PEAP como tipo ID 26. Estes IDs identificam os métodos para o RADIUS e para o suplicante. Eles não determinam quais as pessoas ou dispositivos que os devem utilizar.
O que as linhas realmente alteram
As credenciais do cliente definem o limite operacional. O EAP-TLS apresenta um certificado de cliente X.509. O PEAP utiliza um nome de utilizador e palavra-passe, comummente através de EAP-MSCHAPv2 ou EAP-GTC. Isso torna a inscrição e a renovação de certificados o volume de trabalho determinante, em vez de uma classificação teórica dos métodos.
As verificações de confiança também diferem. O EAP-TLS autentica os certificados do cliente e do servidor. O PEAP valida o certificado do servidor RADIUS no túnel TLS externo e, em seguida, autentica o utilizador ou dispositivo com um método interno.
A exposição da palavra-passe depende da configuração do suplicante. O EAP-TLS não tem palavra-passe na rede. O PEAP transporta uma palavra-passe dentro do seu túnel, pelo que um cliente que ingnore as verificações do servidor pode revelar uma palavra-passe de diretório a um ponto de acesso malicioso. Com o EAP-TLS, um certificado de cliente em falta ou não fiável faz com que a autenticação falhe.
O offboarding também depende do que está a ser gerido. Um certificado de dispositivo pode ser revogado ou deixado expirar sem redefinir a palavra-passe de diretório do utilizador. Desativar uma conta ou alterar uma palavra-passe reutilizada pode afetar outros inícios de sessão associados a essa credencial.
O compromisso operacional é claro: o EAP-TLS exige certificados de cliente, renovação e um caminho de recuperação, enquanto o PEAP exige o certificado do servidor e uma configuração cuidadosa do suplicante. Atribua o EAP-TLS a funcionários inscritos e dispositivos com privilégios; mantenha o PEAP para dispositivos não geridos que não podem integrar a gestão de certificados. As equipas que executam infraestrutura serverless para plataformas de membros podem ter grupos distintos de membros, funcionários e dispositivos, mas o modelo de alojamento não escolhe o método de autenticação. A credencial tem de corresponder a quem consegue gerir.
Como Cada Método Autentica e Onde Ocorrem Fugas de Palavras-passe
O EAP-TLS não é automaticamente a resposta certa para todos os utilizadores. A decisão fundamental é se a sua equipa consegue emitir, renovar e revogar certificados de forma fiável para cada população. O PEAP mantém o onboarding mais simples para utilizadores não geridos, mas a sua palavra-passe depende da configuração correta do suplicante.
Ambos os métodos utilizam o 802.1X. O suplicante é o dispositivo que solicita o acesso, o autenticador é o ponto de acesso ou switch que retransmite esse pedido, e o servidor RADIUS aceita-o ou rejeita-o. Eles partilham a estrutura EAP, não uma credencial.
O índice de especificações IETF EAP descreve o EAP-TLS, definido no IETF RFC 5216, como uma autenticação de cliente e servidor baseada em certificados, com autenticação mútua, negociação de conjunto de cifras com integridade protegida e derivação de chaves. A especificação foi publicada em março de 2008. Na prática, o EAP-TLS exige um certificado de cliente emitido através de PKI, juntamente com o certificado do servidor RADIUS.
Duas sequências, uma estrutura
O EAP-TLS autentica ambos os pontos de extremidade numa única troca TLS:
- O suplicante inicia o EAP com o autenticador, que retransmite o pedido para o RADIUS.
- Os certificados do servidor e do cliente são verificados durante a troca TLS.
- A troca protege a negociação do conjunto de cifras e deriva chaves, sem enviar uma palavra-passe que possa ser alvo de phishing, retransmissão ou força bruta.
- Um certificado de cliente em falta ou não confiável significa que o dispositivo é rejeitado. Não é possível recorrer à introdução de uma palavra-passe.
O PEAP cria um túnel TLS externo que autentica o servidor e, em seguida, executa um método interno, normalmente EAP-MSCHAPv2 ou EAP-GTC. Como o método interno pode utilizar um nome de utilizador e uma palavra-passe, os pontos finais geralmente não precisam de certificados de cliente. O índice de especificações EAP do IETF também descreve a estrutura de normas que estes métodos utilizam.
Os utilizadores não veem o túnel externo do PEAP. A identidade interna, normalmente um nome de utilizador e palavra-passe ou um token, só é enviada após o TLS estar estabelecido. Isto torna o PEAP familiar para suplicantes baseados em diretório, embora deixe a palavra-passe exposta se o cliente não verificar o túnel corretamente.
O PEAP com EAP-TLS interno é um caso especial mais complexo, combinando um método de certificado com um túnel TLS externo. Uma implementação identificada como “PEAP” significa normalmente PEAP-MSCHAPv2.
Onde o suplicante decide o resultado
Um artigo detalhado sobre métodos EAP de segurança empresarial sem fios explica a distinção: o EAP-TLS utiliza autenticação mútua X.509. O RADIUS valida o certificado do cliente, e o cliente valida o certificado do servidor. Não existe qualquer palavra-passe para ser alvo de phishing, retransmissão ou força bruta. O artigo refere também que o NIST exige que tanto a estação sem fios como o servidor de autenticação possuam certificados válidos.
Com o PEAP, o cliente tem de validar a cadeia de certificados do RADIUS e o nome do servidor esperado. Se faltar qualquer uma das verificações, um access point falso pode solicitar uma palavra-passe de diretório. Um perfil de suplicante configurado para "não validar" não protege a palavra-passe.
Regra prática: Fixe o nome do servidor RADIUS e a CA emissora no perfil de WiFi. Sem essas verificações, o PEAP pode oferecer uma palavra-passe a um servidor não autorizado.
As respostas MS-CHAPv2 capturadas podem ser descodificadas offline após um atacante as obter através de um túnel malicioso. Validar o túnel é o controlo adequado; o método interno não salva um perfil que aceite um servidor não confiável. O mesmo risco de palavra-passe estende-se para além do WiFi. Os relatórios de credenciais comprometidas em pequenas empresas australianas reforçam a razão pela qual uma palavra-passe de diretório reutilizada continua a ser valiosa para um atacante.
Atribua o EAP-TLS a dispositivos geridos e a utilizadores cujo ciclo de vida dos certificados consiga gerir. Utilize o PEAP quando os utilizadores ou dispositivos não conseguirem receber e renovar certificados de forma fiável, mas imponha a validação da CA e do nome do servidor através do perfil do suplicante. O compromisso operacional é direto: os certificados exigem trabalho de Inscrição e recuperação, enquanto as palavras-passe o obrigam a gerir a reutilização e as alterações de contas. O melhor método depende de quem consegue gerir, e não de declarar um vencedor para todos os SSIDs.
Requisitos de Certificados Antes da Implementação
Confirme estes seis itens num laboratório antes de efetuar a primeira associação em produção. Uma cadeia em falta ou um nome incorreto parecerá "WiFi indisponível", e não um erro de certificado.
- Certificado do servidor RADIUS. Emita-o a partir da sua CA privada. Coloque o nome que o perfil do suplicante fixa no assunto ou SAN. Defina a utilização de autenticação do servidor e forneça a cadeia intermédia completa com o certificado. Uma CA pública que assine qualquer nome correspondente é o modelo de confiança errado para um nome RADIUS interno.
- Certificado do cliente. Um por dispositivo ou utilizador, com utilização de autenticação de cliente. Coloque uma identidade única no SAN, como um nome principal de utilizador ou um número de série do dispositivo. Armazene a chave privada no TPM ou no enclave seguro quando a plataforma o suportar.
- Âncora de confiança. Instale a CA de raiz interna ou emissora através do perfil MDM. Não aponte dispositivos para uma raiz pública na esperança de que a verificação do nome seja suficiente.
- Validade e renovação. Defina um período de validade para o certificado do servidor e para os certificados dos clientes. Crie uma janela de sobreposição para que o certificado de substituição seja instalado antes que o antigo expire.
- Revogação. Forneça ao servidor RADIUS um ponto de extremidade CRL ou OCSP ao qual ele consiga aceder. Decida, por escrito, se a autenticação falha ou prossegue quando esse ponto de extremidade estiver offline. Teste o cenário offline. Não o descubra durante uma falha pontual da WAN.
- Canal de inscrição. Entregue os certificados com SCEP ou PKCS#12 através do MDM. Comprove o funcionamento num único dispositivo, incluindo a renovação, antes de os disponibilizar a um grupo.
Suponha que uma clínica utiliza o Okta para a identidade dos funcionários e o Intune para portáteis. O nome RADIUS no perfil deve coincidir com o certificado, e o grupo Okta que deve aceder à VLAN clínica deve ser o mesmo grupo que o MDM utiliza para a inscrição. As nossas notas sobre autenticação WiFi com Okta explicam essa transferência de identidade sem transformar o laboratório num SSID com palavra-passe.
Associe um portátil de teste, revogue o respetivo certificado e confirme que a associação seguinte falha antes de alterar um ambiente em produção.
Ciclo de Vida dos Certificados e Esforço de Implementação
A segurança do EAP-TLS transforma-se numa interrupção de serviço quando um certificado expira, ou quando um cliente não consegue aceder às informações de revogação, e a conta de utilizador continua perfeitamente válida. Essa é a questão que vale a pena colocar. "Os certificados são mais difíceis" não é uma arquitetura.
NIST Special Publication 800-120 enquadra essa mesma responsabilidade. O EAP-TLS necessita de emissão, distribuição, renovação, gestão da cadeia de confiança e verificação de revogação fiáveis. Um dispositivo com um certificado expirado, ou com um serviço de revogação inacessível, pode perder o acesso à rede mesmo quando a identidade do utilizador permanece válida. O PEAP autentica tipicamente o servidor na fase TLS externa e um nome de utilizador e palavra-passe através de um método interno como o MS-CHAPv2, contornando esse ciclo de vida do cliente. A facilidade do primeiro dia transfere a carga de trabalho para reposições de palavras-passe e perfis incorretos.
Evite que os certificados se tornem a causa de interrupções
A resposta ao nível de design é a automação, não um manual de procedimentos mais longo.
- Inscreva através do MDM. Envie o perfil, a âncora de confiança e o certificado em conjunto. A configuração manual de WiFi é a razão pela qual as verificações do nome do servidor são desmarcadas.
- Faça sobreposição na renovação. Instale o novo certificado antes que o antigo expire. Um fim de semana em que todos os portáteis deixam de funcionar ao mesmo tempo é sinal de uma sobreposição demasiado curta.
- Testar a revogação offline. Saiba se o RADIUS falha em modo fechado (fail closed) ou aberto (fail open) quando o CRL ou OCSP não podem ser obtidos.
- Mantenha um caminho de recuperação. Um ponto final com falha precisa de uma forma de regressar que não seja "pedir emprestada a palavra-passe PEAP de alguém." Uma porta de helpdesk cablada ou um SSID de recuperação com âmbito estrito é preferível a um segredo partilhado escrito num quadro branco.
O Purple Access obtém certificados EAP-TLS do Microsoft Intune, Jamf Pro, JumpCloud, Kandji, Hexnode, Iru e Addigy, entregues via SCEP, com a configuração a demorar cinco a dez minutos uma única vez para a organização, em vez de ser efetuada por dispositivo. A rede segura não utiliza palavras-passe e é baseada em certificados, sendo que um dispositivo que falhe a verificação de conformidade é recusado na autenticação através do Conditional Access. Trata-se de uma ligação sujeita a conformidade, e não de um segundo pedido de palavra-passe.
O PEAP continua a ser a escolha mais simples quando a PKI não está suficientemente desenvolvida, quando os prestadores de serviços não podem ser incluídos no MDM ou quando ambientes mistos de BYOD não aceitam um certificado. Os setores da saúde, educação, hotelaria e outras redes com múltiplos locais enfrentam frequentemente estes três desafios em simultâneo. Utilize o EAP-TLS para dispositivos corporativos geridos, de funcionários e de alto risco. Mantenha uma alternativa estritamente controlada para pontos finais não geridos ou temporários. A gestão de identidades à escala de cada local é a decisão fundamental, e não um slogan a dizer que o TLS superou as palavras-passe.
Se o próprio RADIUS for o ponto frágil, um backend alojado elimina a falha de "um servidor no armário da sede". O nosso artigo sobre RADIUS-as-a-Service é o local ideal para verificar a acessibilidade e a redundância antes de culpar o método EAP.
A breve demonstração abaixo mostra a inscrição do certificado juntamente com um método interno de palavra-passe, que é o contraste que as equipas de suporte veem quando a renovação se atrasa.
Revogação, Velocidade de Roaming e Suporte do Cliente
O suporte e a velocidade são problemas de consulta. Os suplicantes atuais do Windows, macOS, iOS, Android e ChromeOS suportam ambos os métodos. O modo de falha é o que difere.
O EAP-TLS falha quando o perfil, a CA emissora ou as datas de validade estão incorretos. O PEAP falha quando o método interno, o formato de identidade ou a verificação do nome do servidor não correspondem à política do RADIUS. Nenhuma destas falhas significa que o access point "não suporta enterprise".
A revogação tem a mesma divisão. Desativar o certificado de um dispositivo corta o acesso desse portátil sem afetar os outros inícios de sessão da pessoa. Redefinir uma palavra-passe de diretório afeta todos os clientes não geridos que ainda a utilizem. O corte imediato e específico do dispositivo é a vantagem do EAP-TLS. As falhas graves decorrentes de certificados expirados são o custo.
Handshakes, não nomes de marcas
Um artigo da ACM sobre latência de autenticação sem fios conclui que o desempenho depende mais da contagem de handshakes, roaming, validação de certificados e latência do backend do que do nome do método. O EAP-TLS padrão conclui a autenticação de certificados de cliente e servidor na sua troca TLS. O PEAP estabelece um túnel TLS e, em seguida, executa a autenticação interna, adicionando uma fase distinta. O material técnico da Cisco mencionado nesse artigo refere que o PEAP com EAP-TLS interno envolve dois handshakes TLS e pode ser lento quando ocorre uma reautenticação completa durante o roaming.
Meça estes parâmetros separadamente. Não defina um vencedor com base num único tempo médio de início de sessão.
- Tempo de associação a IP no percentil 95
- Autenticação completa versus latência de retoma de roaming
- Tempo de ida e volta (RTT) do RADIUS
- Taxa de falhas de autenticação
- Falhas na renovação de certificados
A retoma de sessão, o caching de PMK ou 802.11r, a acessibilidade local ao RADIUS e uma cadeia de certificados curta afetam mais esses números do que a troca de um conjunto de cifras. O PEAP pode parecer simples no primeiro dia e, ainda assim, gerar atrasos devido a trocas repetidas de palavras-passe e intervenções dos utilizadores. O EAP-TLS pode parecer instantâneo após a inscrição e depois falhar gravemente devido a um certificado expirado.
| Sintoma | Método mais provável | Causa habitual | Correção prática |
|---|---|---|---|
| Repete o pedido de palavra-passe perto de um AP desconhecido | PEAP | O suplicante não valida o nome do servidor ou a cadeia | Envie um perfil que fixe o nome RADIUS e a CA |
| O acesso deixa de funcionar num portátil após alteração de função | EAP-TLS | Certificado revogado ou dispositivo removido do MDM | Confirme a revogação e volte a inscrever apenas esse dispositivo |
| Equipa inteira bloqueada numa segunda-feira | EAP-TLS | Certificados expiraram em simultâneo ou a sobreposição de renovação foi demasiado curta | Prepare a renovação antes da expiração e mantenha um caminho de recuperação |
| O roaming parece lento apenas na reautenticação completa | PEAP com EAP-TLS interno | Dois handshakes TLS | Prefira a retoma, caching PMK ou 802.11r; evite o EAP-TLS interno, a menos que seja necessário |
| Rejeições aleatórias apenas num local | Qualquer um deles | Round-trip RADIUS ou procura de cadeia, não o nome EAP | Meça o RTT e o percentil 95 de associação a IP antes de alterar o método |
O roaming lento num determinado local deve-se normalmente à distância do RADIUS ou à procura da cadeia de certificados, e não é uma prova de que escolheu o tipo de EAP errado.
Atribua Cada Grupo e Comprove a Divisão
Um único edifício pode ter portáteis de funcionários, um convidado de conferência, um Mac de um prestador de serviços e uma caixa registadora. Não devem partilhar o mesmo tipo de credencial. Mapeie cada população, faça um piloto num local em paralelo com a rede que já opera e avalie os pedidos de suporte e o registo de autenticação antes de replicar o projeto.
| População | Utilizar | Não utilizar | Motivo |
|---|---|---|---|
| Funcionários geridos por MDM e utilizadores privilegiados | EAP-TLS num SSID WPA-Enterprise | PSK partilhado ou PEAP | Identidade por certificado, VLAN por grupo, o acesso termina quando a conta é desativada |
| Visitantes de curta duração | Captive Portal ou Passpoint numa VLAN de convidados | Registo PEAP ou EAP-TLS na receção | Sem ciclo de vida de certificados e sem palavra-passe de diretório para sofrer phishing |
| Portáteis não geridos e prestadores de serviços | Apenas PEAP-MSCHAPv2 com validação forçada do servidor | EAP-TLS se não for possível registá-los ou renová-los | As palavras-passe já existem, mas o perfil deve verificar o certificado RADIUS |
| Impressoras, TVs, caixas registadoras, CCTV e sensores | PSK por dispositivo com a sua própria VLAN | EAP-TLS ou uma palavra-passe PEAP partilhada | Estes dispositivos geralmente não conseguem armazenar certificados, e uma chave partilhada é difícil de rodar |
| Espaço misto num único edifício | Divisão por identidade através de VLANs separadas | Um SSID e um método para todos | Funcionários, convidados e dispositivos falham de formas diferentes e não devem partilhar o mesmo tipo de credencial |
Quem continua com palavras-passe e quem não deve continuar
Pessoal gerido e utilizadores com privilégios obtêm EAP-TLS num SSID WPA-Enterprise. O pessoal de limpeza, receção e operações pode autenticar-se com certificados de um MDM através de SCEP, aterrar numa VLAN por grupo de diretório e perder o acesso quando a conta for desativada. Uma PSK partilhada ou uma palavra-passe PEAP recria a própria coisa que estava a tentar retirar.
Convidados e visitantes permanecem num Captive Portal ou Passpoint, numa VLAN de convidados. Não inscreva certificados na receção e não os coloque em PEAP. Não há um ciclo de vida que vá gerir e há uma palavra-passe de diretório que não quer ver vítima de phishing. Um perfil Passpoint pode voltar a ligar-se na visita seguinte sem um novo pedido de suporte.
Laptops não geridos e prestadores de serviços podem permanecer em PEAP-MSCHAPv2, e apenas se o perfil forçar a validação do servidor. Se não conseguir inscrevê-los ou renová-los, o EAP-TLS vai deixá-los sem acesso. Se não conseguir forçar a verificação do servidor, o risco da palavra-passe supera a conveniência, e estes não devem estar, de todo, no SSID do pessoal.
Impressoras, TVs, caixas registadoras, EPOS, CCTV, sensores e controladores de portas recebem uma PSK por dispositivo e a sua própria VLAN. Regra geral, não conseguem armazenar certificados. Uma palavra-passe PEAP partilhada reintroduz o problema das chaves partilhadas. O requisito PCI DSS v4.0.1 Req 2.3.2 exige que as chaves sem fios sejam alteradas quando qualquer pessoa que as conheça sai da empresa, o que torna impraticável a utilização de uma chave partilhada. O xPSK é a solução ideal para esses equipamentos. As TVs dos quartos, termóstatos e caixas registadoras devem pertencer a VLANs associadas a chaves que os convidados nunca veem.
Prove-o num local
Aplique o novo design nos pontos de acesso que a localização já possui, ao lado da rede atual. Avalie o resultado com base nos pedidos de suporte e nas evidências de auditoria, e não numa demonstração de início de sessão.
Exija um registo de autenticação que grave cada aceitação e rejeição com identidade, dispositivo, estado de inscrição no MDM, método, ponto de acesso, SSID, local, VLAN, função, motivo e hora. Esse mesmo registo é o conjunto de evidências para os controlos de acesso e registo da ISO 27001 e para os requisitos 8 e 10 do PCI-DSS. Sem MDM, bloqueie primeiro os perfis PEAP e agende certificados apenas para a população gerida.
Podemos implementar esta divisão como três redes por propriedade. Os hóspedes utilizam o Captive Portal, incluindo uma verificação de quarto no PMS onde a propriedade disponha de um. Os funcionários utilizam EAP-TLS ou Passpoint. Os dispositivos IoT utilizam chaves por dispositivo. O Cloud RADIUS encaminha cada dispositivo para a rede e VLAN corretas com base na identidade, e rejeita um ex-colaborador cuja conta esteja desativada. O caminho de migração para deixar de usar uma palavra-passe partilhada de funcionários é o mesmo descrito no nosso guia para migrar o WiFi de funcionários em múltiplos locais para 802.1X.
Eu iniciaria o piloto com o SSID de funcionários geridos e as chaves por dispositivo para caixas registadoras, mantendo os prestadores de serviços num perfil PEAP validado até que a inscrição seja efetiva. Um único método para todos parece mais simples num diagrama, mas falha de três formas diferentes no terreno.
O Purple Access executa WiFi para funcionários baseado em certificados e chaves por dispositivo para equipamentos nos pontos de acesso que já possui, pelo que eap tls vs peap se torna uma escolha de população em vez de uma aposta em toda a infraestrutura. Pode testar redes abertas, seguras e xPSK num único local e, em seguida, avaliar os pedidos de suporte e o registo de autenticação antes de uma implementação mais ampla. Visite o Purple Access para mapear as suas redes de funcionários, convidados e dispositivos.
