O caso de conformidade para WiFi sem senha: HIPAA, PCI, ISO 27001

O WiFi sem senha, ou seja, 802.1X com EAP-TLS baseado em certificados, não é exigido pelo HIPAA, PCI DSS 4.0 ou ISO 27001:2022. Todos os três esperam identificação exclusiva, criptografia forte, revogação rápida e logs de auditoria. Uma senha compartilhada apresenta dificuldades em todos os quesitos. Os certificados por dispositivo atendem a cada expectativa por design e geram os logs que um auditor analisa.

O que realmente significa a conformidade de WiFi sem senha?

O WiFi sem senha substitui uma senha de rede compartilhada por uma credencial exclusiva para cada dispositivo ou pessoa. Em redes corporativas, isso geralmente significa IEEE 802.1X, o padrão para controle de acesso à rede baseado em porta. O 802.1X transfere a decisão para um servidor RADIUS. RADIUS é o protocolo que os pontos de acesso usam para perguntar a um servidor de autenticação se um dispositivo pode se conectar.

O método mais forte é o EAP-TLS (Extensible Authentication Protocol com Transport Layer Security). Tanto o dispositivo quanto o servidor apresentam certificados digitais. Não há senha para fazer phishing, compartilhar ou escrever em um quadro branco na sala dos funcionários. Cada sessão deriva suas próprias chaves de criptografia sob WPA2-Enterprise ou WPA3-Enterprise.

Dois métodos relacionados precisam ser destacados:

• PEAP (Protected EAP) com um nome de conta e senha é 802.1X, mas não é sem senha. Ele herda todas as fraquezas da senha por trás dele.
• iPSK (identity pre-shared key) fornece a cada dispositivo sua própria chave em um único nome de rede. É uma ponte prática para equipamentos que não podem armazenar um certificado.

"Conformidade de WiFi sem senha" é um atalho para uma pergunta. A maneira como sua equipe e dispositivos se conectam à rede satisfaz os controles de acesso, criptografia e registro em log contra os quais você é auditado? Nenhum dos três frameworks deste guia cita o EAP-TLS. Todos os três descrevem resultados que uma senha compartilhada torna difíceis de comprovar.

Por que uma senha de WiFi compartilhada falha em uma auditoria?

Uma chave pré-compartilhada (PSK) é um único segredo conhecido por todos na rede. Esse único fato cria quatro problemas de auditoria.

• Sem atribuição. Cada dispositivo se autentica com o mesmo segredo. Os logs mostram um endereço MAC, não uma pessoa, e os endereços MAC podem ser falsificados.
• Revogação significa rotação. Remover um funcionário que saiu significa alterar a chave em cada dispositivo. O requisito 2.3.2 do PCI DSS torna essa rotação obrigatória em redes conectadas a dados de cartões.
• Amplo raio de alcance de danos. Uma única chave vazada expõe toda a rede e, frequentemente, cada site que a compartilha.
• Evidência frágil. Você não pode provar a um auditor quem conhecia a chave, quando a descobriu ou se os ex-funcionários não a possuem mais.

O acesso baseado em certificado reverte cada ponto. Cada conexão carrega uma identidade exclusiva. Revogar um certificado ou desativar uma conta remove um dispositivo ou uma pessoa. Ninguém conhece uma chave, então ninguém sai com uma.

Como o WiFi baseado em certificados atende ao PCI DSS 4.0?

PCI-DSS v4.0 tornou-se a única versão ativa quando a v3.2.1 foi aposentada em 31 de março de 2024. Seus requisitos com data futura tornaram-se obrigatórios em 31 de março de 2025. A revisão limitada v4.0.1, publicada em junho de 2024, usa os mesmos números de requisitos referenciados abaixo.

O WiFi sem senha é compatível com PCI?

Não por si só. A conformidade com PCI pertence ao ambiente avaliado, não a um produto. O WiFi sem senha satisfaz ou simplifica os requisitos que as senhas compartilhadas tornam dolorosos:

• 1.3.3 exige controles de segurança de rede entre cada rede sem fio e o ambiente de dados do titular do cartão (CDE). O CDE é o conjunto de sistemas que armazenam, processam ou transmitem dados de cartão. O tráfego sem fio para o CDE deve ser negado por padrão. O acesso baseado em identidade coloca dispositivos autorizados em uma VLAN (LAN virtual) específica e nega todo o resto.
• 2.3.1 e 2.3.2 exigem que você altere as chaves sem fio padrão do fornecedor. Você também deve alterar as chaves de criptografia sem fio sempre que alguém que as conhecia sair. Com EAP-TLS, nenhuma pessoa conhece uma chave, então o gatilho de saída nunca é acionado.
• 4.2.1.2 exige criptografia forte para autenticação e transmissão em redes sem fio que transportam dados de cartão ou conectadas ao CDE. O PCI-DSS proíbe o WEP desde 2010. A autenticação mútua de certificados com WPA2-Enterprise ou WPA3-Enterprise atende a esse requisito.
• 8.2.2 restringe contas compartilhadas e genéricas a casos excepcionais com justificativa documentada. Uma senha de rede compartilhada por 200 funcionários é difícil de justificar.
• 8.2.5 exige que o acesso de funcionários desligados seja revogado imediatamente. Desativar uma conta em seu provedor de identidade faz exatamente isso.
• 10.2.1 e 10.5.1 exigem logs de auditoria, retidos por 12 meses, com os três meses mais recentes imediatamente disponíveis. Os logs RADIUS do 802.1X atribuem cada conexão a um certificado ou conta.

O WiFi sem senha não cobre o Requisito 11.2.1. Esse requisito solicita que você teste pontos de acesso autorizados e não autorizados pelo menos uma vez a cada três meses. Isso continua sendo seu trabalho, conforme explica a seção de limites.

A HIPAA exige WiFi baseado em certificado?

Não. A HIPAA Security Rule (45 CFR Parte 164, Subparte C) é neutra em termos de tecnologia e não nomeia nenhum protocolo sem fio. Ela estabelece padrões e especificações de implementação, alguns "obrigatórios" e outros "endereçáveis". Endereçável significa que você implementa a especificação onde for razoável e apropriado. Caso contrário, você documenta o motivo e adota uma alternativa equivalente.

O WiFi baseado em certificado se alinha perfeitamente com as salvaguardas técnicas em §164.312:

• Identificação exclusiva, §164.312(a)(2)(i), obrigatório. Cada dispositivo e pessoa na rede possui uma identidade distinta.
• Criptografia e descriptografia, §164.312(a)(2)(iv), endereçável. Chaves por sessão protegem as ePHI (informações eletrônicas de saúde protegidas) que se movem pelo ar.
• Controles de auditoria, §164.312(b), obrigatório. Os logs RADIUS registram qual identidade se conectou, a partir de qual ponto de acesso e quando.
• Autenticação de pessoa ou entidade, §164.312(d), obrigatório. Um certificado comprova que o dispositivo é aquele que se afirma ser. Vinculá-lo a uma conta de provedor de identidade estende essa prova à pessoa.
• Segurança de transmissão, §164.312(e)(1). Controles de integridade e criptografia são especificações tratáveis sob esta norma.

As salvaguardas administrativas também importam. A análise de risco no §164.308(a)(1)(ii)(A) é onde você registra por que seus controles de rede sem fio são razoáveis. Os procedimentos de rescisão no §164.308(a)(3)(ii)(C) são mais fáceis de comprovar quando a desativação de uma conta remove o acesso à rede.

Fique atento à direção das mudanças. Em janeiro de 2025, o Departamento de Saúde e Serviços Humanos dos EUA (HHS) publicou uma proposta de norma. Ela removeria a maior parte da distinção entre obrigatório e tratável. Também tornaria a criptografia e a autenticação multifator obrigatórias, com exceções limitadas. É uma proposta, não uma norma final. O acesso baseado em certificados já se posiciona do lado correto dela.

O que a ISO 27001 diz sobre redes sem fio?

A ISO/IEC 27001:2022 não possui um controle chamado "rede sem fio". O Anexo A lista 93 controles em quatro temas, e vários se aplicam diretamente a como os funcionários se conectam a uma rede. A ISO/IEC 27002:2022, o guia de implementação, aborda redes sem fio sob o controle 8.22. Ela observa que os perímetros de redes sem fio são mal definidos. Para ambientes confidenciais, ela sugere tratar o acesso sem fio como uma conexão externa até que ele passe por um gateway.

Os controles que um auditor irá testar:

• 5.15 Controle de acesso e 5.18 Direitos de acesso. Regras para quem pode se conectar, e como esse acesso é provisionado e removido.
• 5.16 Gestão de identidade e 5.17 Informações de autenticação. Identidades e segredos gerenciados ao longo de seu ciclo de vida. Uma senha compartilhada é uma informação de autenticação que você não pode atribuir a uma única pessoa.
• 8.5 Autenticação segura. Tecnologia de autenticação adequada à sensibilidade do acesso.
• 8.15 Registro (logs) e 8.16 Monitoramento de atividades. Logs que registram eventos, e evidências de que alguém os revisa.
• 8.20 Segurança de redes, 8.21 Segurança dos serviços de rede e 8.22 Segregação de redes.
• 8.24 Uso de criptografia.
• 5.19 e 5.23. Relacionamentos com fornecedores e serviços em nuvem, que se aplicam se a sua autenticação for executada como um serviço em nuvem.

As organizações certificadas pela ISO/IEC 27001:2013 tinham até 31 de outubro de 2025 para realizar a transição. Se a sua Declaração de Aplicabilidade ainda utiliza a numeração de 2013, como A.9 ou A.13, atualize-a.

Como as três estruturas se alinham ao WiFi sem senha

Controle	Estrutura	O que solicita	Senha compartilhada (PSK)	Baseado em certificado (EAP-TLS)
1.3.3	PCI DSS 4.0	Bloqueio por padrão (default-deny) entre redes sem fio e o CDE	Todo dispositivo na chave cai em um segmento	VLAN por identidade, bloqueio por padrão
2.3.2	PCI DSS 4.0	Alterar as chaves de rede sem fio quando qualquer pessoa que as conhecia sair	Rotacionar a cada saída de funcionário, em cada dispositivo	Nenhuma pessoa possui uma chave; revoga-se apenas um certificado
8.2.2	PCI-DSS 4.0	Contas compartilhadas apenas por exceção documentada	Compartilhado por design	Uma credencial por dispositivo ou pessoa
10.5.1	PCI DSS 4.0	12 meses de logs, três meses imediatamente disponíveis	Logs mostram apenas endereços MAC	Logs nomeiam o certificado ou conta
§164.312(a)(2)(i)	HIPAA	Identificação exclusiva (obrigatório)	Não atendido pela credencial de rede	Atendido por design
§164.312(b)	HIPAA	Controles de auditoria (obrigatório)	Atribuição fraca	Cada sessão atribuível
§164.312(e)(1)	HIPAA	Segurança de transmissão	Criptografado, mas a chave é conhecida por toda a equipe	Criptografado com chaves que nenhuma pessoa conhece
5.17	ISO 27001:2022	Informações de autenticação alocadas e gerenciadas	Não é possível alocar para uma pessoa	Emitido, renovado e revogado por identidade
5.18	ISO 27001:2022	Direitos de acesso provisionados e removidos	A remoção exige uma alteração de chave em toda a rede	A remoção segue o provedor de identidade
8.22	ISO 27001:2022	Segregação de redes	Um segmento por chave	Segmento por função ou tipo de dispositivo

Quais evidências um auditor solicitará?

Os auditores testam o design, a configuração e a operação. O design são os seus diagramas. A configuração são as suas exportações. A operação são os seus logs e amostras. Reúna o pacote antes do trabalho de campo, não durante ele.

Item de evidência	O que ele mostra	PCI DSS 4.0	HIPAA	ISO 27001:2022
Diagramas de rede e fluxo de dados mostrando os limites de funcionários, convidados e CDE	Design de segmentação	1.2.3, 1.2.4	§164.308(a)(1)	8.20, 8.22
Regras de firewall ou ACL entre as VLANs sem fio de funcionários e o CDE	Negação padrão na prática	1.3.3	§164.312(e)(1)	8.22
Exportação de configuração de SSID mostrando modo Enterprise e EAP-TLS	Autenticação e criptografia fortes	4.2.1.2	§164.312(a)(2)(iv)	8.5, 8.24
Política de certificados: CA emissora, período de validade, renovação, revogação	Ciclo de vida das informações de autenticação	4.2.1.2	§164.312(d)	5.17
Amostra de desligamento: tempo de desativação da conta em relação à última autenticação de rede	Revogação oportuna	8.2.5	§164.308(a)(3)(ii)(C)	5.18
Logs do RADIUS com configurações de retenção	Atribuição e retenção	10.2.1, 10.5.1	§164.312(b)	8.15
Inventário de pontos de acesso e resultados trimestrais de varredura de rogue	Controle de pontos de acesso autorizados e não autorizados	11.2.1, 11.2.2	§164.308(a)(1)	8.16
Certificados e contratos de fornecedores	Garantia de terceiros	12.8	§164.308(b) onde o fornecedor lida com ePHI	5.19, 5.23

Como você comprova os controles de WiFi para um auditor?

Execute você mesmo o teste de desligamento primeiro. É o teste que uma senha compartilhada não consegue passar de forma limpa.

1. Exporte sua lista de desligamentos de RH para o período de auditoria.
2. Selecione uma amostra, por exemplo 10 a 25 desligamentos em várias unidades.
3. Para cada um, obtenha o horário de desativação da conta no seu provedor de identidade.
4. Extraia a última autenticação de rede bem-sucedida para essa identidade a partir dos logs do RADIUS.
5. Qualquer autenticação após o horário de desativação é uma descoberta. Corrija a causa antes que o auditor a encontre.

Em uma rede PSK, a etapa quatro não retorna nada útil. Nenhum log vincula uma conexão ao colaborador desligado, portanto você não pode provar que ele parou de se conectar.

Onde o WiFi sem senha se posiciona em relação ao que você já executa?

Você não precisa de novos pontos de acesso. O 802.1X é um recurso padrão de pontos de acesso empresariais. A Purple é agnóstica em relação a hardware e funciona como uma sobreposição em nuvem no Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme e Fortinet.

O Purple Staff WiFi usa Redes Baseadas em Identidade. O acesso à rede segue o seu provedor de identidade: Microsoft Entra ID, Okta ou Google Workspace. Os novos colaboradores ganham acesso quando a conta deles é criada. Colaboradores que mudam de função alteram o segmento de rede quando o seu cargo muda. Colaboradores desligados perdem o acesso quando a conta é desativada. Esse fluxo de admissão, mobilidade e desligamento (JML) é o que produz evidências limpas para PCI DSS 8.2.5, HIPAA §164.308(a)(3)(ii)(C) e controle ISO 27001 5.18.

A sua rede de convidados permanece separada. O PCI DSS 1.3.3 aplica-se tanto a ela quanto às redes de funcionários: o tráfego de convidados para o CDE deve ser negado. Os planos do Guest WiFi da Purple trazem conformidade com GDPR e CCPA para dados de visitantes, conforme estabelecido em Connect vs Capture.

Para o seu arquivo de fornecedores, a Purple possui certificação ISO 27001 e Cyber Essentials e está em conformidade com GDPR e CCPA. Os dados da própria plataforma da Purple mostram 99,999% de tempo de atividade em mais de 80.000 locais ativos. Seu auditor tratará isso como garantia do fornecedor, não como prova de seus próprios controles.

Como é a conformidade do WiFi sem senha na prática?

Os três cenários abaixo são exemplos práticos. Cada um declara suas premissas, para que você possa refazer os cálculos para a sua própria empresa.

Um hotel de 200 quartos: eliminando a rotação de chaves PCI

Situação. Um hotel de 200 quartos mantém 140 funcionários em uma rede PSK. Computadores da recepção e tablets do restaurante nessa rede acessam o sistema de pagamento, o que a coloca no escopo do PCI. Assuma 30% de rotatividade anual de funcionários, ou seja, 42 desligamentos por ano.

O que foi feito. A rede de funcionários mudou para 802.1X com EAP-TLS, vinculada ao provedor de identidade do grupo hoteleiro. Os dispositivos de pagamento foram movidos para uma VLAN dedicada com regras de negação padrão (default-deny) para qualquer outra rede. A rede de convidados foi isolada de ambas.

Resultado. As rotações de chaves do Requisito 2.3.2 caem de 42 por ano, cada uma afetando todos os dispositivos de funcionários, para zero. Cada desligamento é resolvido desativando-se uma única conta. A amostra de desligamentos agora possui um log para comparação. Operadores em Hotels com funcionários sazonais veem a maior redução, pois a rotatividade impulsiona a rotação.

Uma rede de varejo com 40 lojas: reduzindo o raio de impacto

Situação. Uma rede com 40 lojas usa uma única PSK em todas as lojas para coletores de dados portáteis de estoque e notebooks do back-office. Os gerentes de loja sabem a chave. Um ex-gerente a publica online.

O que foi feito. Laptops gerenciados migraram para EAP-TLS com certificados emitidos por meio do gerenciamento de dispositivos. Leitores de código de barras que não podiam conter certificados migraram para iPSK, uma chave por dispositivo, em uma VLAN restrita. O inventário de pontos de acesso de cada loja foi documentado sob o Requisito 11.2.2.

Resultado. A exposição gerada por uma credencial vazada cai de 40 lojas para um único dispositivo. Revogar esse dispositivo exige apenas uma ação e mantém os outros leitores conectados. A rede de lojas agora pode apresentar a um avaliador um inventário por dispositivo em vez de um único segredo compartilhado. O mesmo padrão se aplica a qualquer propriedade de Varejo com uma mistura de dispositivos gerenciados e dispositivos sem interface de usuário.

Um departamento de saúde do condado: atribuição HIPAA em 12 clínicas

Situação. Um departamento de saúde de um condado nos EUA administra 12 clínicas. Os médicos usam tablets compartilhados para acessar o prontuário eletrônico de saúde. Cada clínica possui sua própria senha de rede, resultando em 12 credenciais compartilhadas e nenhuma atribuição nos logs de rede.

O que foi feito. Os tablets receberam certificados de dispositivo. Os médicos fazem login com sua conta do provedor de identidade, de modo que cada sessão vincula um dispositivo a uma pessoa. Os logs de RADIUS alimentam o gerenciamento de logs do departamento. A retenção foi configurada de acordo com o período de documentação de seis anos definido em §164.316(b)(2), onde o departamento classifica os logs como documentação.

Resultado. As credenciais de rede compartilhadas caíram de 12 para zero. A análise de risco pode registrar a especificação de criptografia como implementada, em vez de documentar uma alternativa. Os controles de auditoria sob §164.312(b) agora mostram qual pessoa, em qual dispositivo, conectou-se a qual rede de clínica e quando. Equipes do setor público de Saúde que respondem tanto à HIPAA quanto à auditoria estadual podem reutilizar o mesmo pacote de evidências. Os dispositivos da equipe em Trens seguem o mesmo modelo, com uma identidade por tablet em cada vagão e depósito.

Quais são os limites que você deve conhecer?

• Não é um certificado de conformidade. O WiFi sem senha atende a controles específicos. O escopo, a análise de risco e o restante de cada framework continuam sendo sua responsabilidade.
• Pontos de acesso não autorizados ainda precisam de testes. O PCI DSS 11.2.1 exige testes trimestrais para pontos de acesso autorizados e não autorizados. O acesso baseado em certificado não detecta um dispositivo invasor conectado a um switch da loja.
• Os certificados expiram. Você precisa de uma autoridade de certificação, um método de inscrição e um processo de renovação. Uma renovação perdida desconecta todos os dispositivos cujo certificado compartilha essa data de expiração.
• Nem todo dispositivo pode conter um certificado. Impressoras, leitores e alguns equipamentos clínicos não podem. Use iPSK ou uma rede segmentada e documente a exceção.
• O PEAP não é um atalho. O PEAP com senhas mantém o risco associado a senhas. Se os dispositivos não validarem o certificado do servidor, um ponto de acesso falso poderá capturar credenciais.
• Os logs só ajudam se forem retidos e revisados. Defina a retenção em 12 meses para o PCI DSS. Comprove uma frequência de revisão para o controle 8.16 da ISO 27001.

O que você deve fazer a seguir?

1. Classifique cada nome de rede. Marque quais tocam o CDE, ePHI ou nenhum dos dois. Isso decide qual framework se aplica a cada um.
2. Execute o teste de demissão agora. Se você não puder concluí-lo, encontrou seu primeiro risco de auditoria.
3. Escolha uma credencial por classe de dispositivo. EAP-TLS para laptops, celulares e tablets gerenciados. iPSK para dispositivos sem interface gráfica.
4. Atualize sua documentação de controle. Mapeie a mudança em sua Declaração de Aplicabilidade, análise de risco HIPAA ou documento de escopo PCI DSS.
5. Pilote em um site. Prove o registro de certificado, atribuição de VLAN e revogação de demitidos antes de implantar em toda a propriedade.
6. Construa o pacote de evidências. Use a tabela de evidências acima como seu checklist, três meses antes do trabalho de campo.

Perguntas frequentes

O WiFi sem senha está em conformidade com o PCI?

O WiFi sem senha não está em conformidade com o PCI por si só, porque o PCI DSS avalia o seu ambiente e não um produto. Ele atende aos Requisitos 2.3.2, 4.2.1.2, 8.2.2 e 8.2.5 de forma mais limpa do que uma senha compartilhada, e seus logs de RADIUS oferecem suporte ao Requisito 10. Você ainda precisa de controles de negação padrão entre as redes sem fio e o ambiente de dados do portador do cartão sob o item 1.3.3, além de testes trimestrais de pontos de acesso não autorizados sob o item 11.2.1.

O HIPAA exige WiFi baseado em certificado?

Não, o HIPAA não nomeia nenhuma tecnologia sem fio. A Regra de Segurança exige identificação exclusiva, controles de auditoria e autenticação de pessoa ou entidade, e trata a criptografia como tratável. O WiFi baseado em certificado atende a tudo isso por design, o que torna sua análise de risco mais fácil de defender. Uma proposta de regra do HHS de janeiro de 2025 tornaria a criptografia e a autenticação multifator obrigatórias com exceções limitadas. É uma proposta, não uma regra final.

O que o ISO 27001 diz sobre redes sem fio?

A ISO/IEC 27001:2022 não possui controle específico para redes sem fio. Os auditores testam as redes sem fio em relação aos controles do Anexo A de 5.15 a 5.18 para acesso e identidade, 8.5 para autenticação segura, 8.15 para registro em log e de 8.20 a 8.22 para segurança e segregação de rede. As orientações da ISO/IEC 27002:2022 sob o item 8.22 sugerem tratar o acesso sem fio em ambientes sensíveis como uma conexão externa até que passe por um gateway.

Como provo os controles de WiFi para um auditor?

Você prova os controles de WiFi com configurações, logs e um teste de demissão. Traga diagramas de rede mostrando os limites de rede sem fio e CDE, exportações de SSID mostrando autenticação Enterprise, sua política de certificados, 12 meses de logs RADIUS e resultados trimestrais de varreduras não autorizadas. Em seguida, execute uma amostragem de demitidos, comparando o horário de desativação da conta de cada demitido com sua última autenticação de rede bem-sucedida. Qualquer autenticação após a desativação é uma descoberta.

O Purple Staff WiFi funciona com nossos pontos de acesso existentes?

Sim, a Purple é agnóstica em relação ao hardware e funciona como uma sobreposição em nuvem no Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme e Fortinet. Você mantém seus pontos de acesso e switches. A Purple conecta o acesso à rede ao Microsoft Entra ID, Okta ou Google Workspace, de modo que abandonar uma senha compartilhada não exige um projeto de substituição completa de hardware.

E quanto aos dispositivos que não suportam um certificado?

Use iPSK ou uma rede separada e segmentada para eles. O iPSK fornece a cada dispositivo sua própria chave no mesmo nome de rede, de modo que revogar um dispositivo mantém os demais conectados. Coloque equipamentos sem interface de usuário, como impressoras e scanners, em uma VLAN restrita. Documente a justificativa comercial em sua análise de risco ou Declaração de Aplicabilidade e revise cada exceção a cada ciclo de auditoria.

A certificação ISO 27001 da Purple nos torna em conformidade?

Não, a certificação de um fornecedor não é transferida para você. As credenciais de ISO 27001, Cyber Essentials, GDPR e CCPA da Purple servem como evidências para a sua avaliação de fornecedores sob os controles 5.19 e 5.23 da ISO 27001 e o Requisito 12.8 do PCI-DSS. Seu próprio escopo, análise de risco, configuração e logs ainda precisam atender a cada estrutura, e seu auditor os testará diretamente.