Garantias Técnicas de HIPAA para WiFi de Funcionários Hospitalares: O Que a Regra de Segurança Realmente Exige

Cinco padrões de salvaguardas técnicas da HIPAA Security Rule contidos na 45 CFR 164.312 se aplicam ao WiFi da equipe hospitalar. Eles são controle de acesso, controles de auditoria, integridade, autenticação de pessoa ou entidade e segurança de transmissão. Você atende a esses requisitos com 802.1X e identidade EAP-TLS baseada em certificados, RADIUS Accounting como log de auditoria e criptografia WPA3-Enterprise em todos os SSIDs da equipe.

O que as salvaguardas técnicas da HIPAA exigem do WiFi da equipe?

O WiFi da equipe é a base sem fio de uma rede de saúde em conformidade com a HIPAA. Médicos e enfermeiros acessam o prontuário eletrônico em estações móveis, escaneiam códigos de barras de medicamentos em dispositivos portáteis e atendem chamadas em crachás de comunicação clínica. A maior parte desse tráfego passa por um SSID da equipe. O Staff WiFi da Purple trata esse SSID como uma camada de identidade em vez de uma senha, e a Security Rule impulsiona sua organização na mesma direção.

A Security Rule protege as informações eletrônicas de saúde protegidas (ePHI) que você cria, recebe, mantém ou transmite (45 CFR 164.306(a)). Ela divide os requisitos em salvaguardas administrativas, físicas e técnicas. As salvaguardas técnicas contêm cinco padrões. Como a WLAN da sua equipe transmite ePHI, todos os cinco alcançam a camada sem fio.

Dois termos são essenciais antes de continuar a leitura. Uma especificação de implementação "obrigatória" deve ser aplicada exatamente como descrita. Uma especificação "endereçável" deve ser implementada se for razoável e apropriada. Caso não seja, você deve documentar o motivo e adotar uma medida equivalente (45 CFR 164.306(d)). Endereçável não é opcional e, em um link de rádio aberto, raramente existe um argumento plausível contra a criptografia.

Em janeiro de 2025, o HHS publicou um aviso de proposta de regulamentação que removeria a categoria endereçável. Isso tornaria obrigatórias a criptografia de ePHI em trânsito e a autenticação multifator. Verifique o status dessa proposta ao planejar sua próxima análise de risco. Projetar com base no texto mais rigoroso agora evita uma segunda migração no futuro.

Por que uma frase de acesso compartilhada de WiFi falha na Security Rule?

Uma rede WPA2-PSK (chave pré-compartilhada) autentica a frase de acesso, não a pessoa. Cada enfermeiro, maqueiro, médico substituto temporário e prestador de serviços que a conhece parece idêntico para a rede. A "identificação única de usuário" em 164.312(a)(2)(i) é uma especificação obrigatória. Ela exige a atribuição de um nome ou número exclusivo a cada pessoa, permitindo identificá-la e acompanhar suas atividades. Uma frase de acesso compartilhada não pode fazer isso, e nenhuma documentação altera esse fato.

A falha se espalha pelos outros padrões:

• Controles de auditoria. O log registra um endereço MAC e uma concessão de IP, não um membro nomeado da equipe. As versões atuais do iOS e do Android randomizam endereços MAC por padrão, o que enfraquece até mesmo esse registro.
• Autenticação de pessoa ou entidade. Conhecer uma frase de acesso não prova nada sobre a identidade. Frases de acesso vazam por meio de lembretes em papel, escalas de plantão e mensagens em grupo.
• Segurança da transmissão. Qualquer pessoa em posse da frase de secreta que capturar o aperto de mão de quatro vias de um dispositivo pode derivar suas chaves de sessão. Ela pode então descriptografar o tráfego desse dispositivo. Um ex-funcionário com a frase secreta antiga permanece dentro do limite de criptografia.
• Rescisão. O item 164.308(a)(3)(ii)(C) prevê que o acesso termine quando o vínculo empregatício for encerrado. Com uma chave compartilhada, remover uma pessoa significa alterar a chave para todos.

Esse último ponto transforma a rotação de PSK em mero teatro. A rotação interrompe a conexão de todos os dispositivos, por isso acontece raramente. Cada pessoa que sai da empresa entre as rotações mantém o acesso.

Como os cinco padrões se mapeiam nos controles sem fio?

Controle de acesso - 164.312(a)(1)

O padrão limita o acesso a ePHI a pessoas e softwares com direitos de acesso concedidos. Na camada sem fio, o IEEE 802.1X é a implementação. Trata-se de um padrão de controle de acesso baseado em porta que mantém cada dispositivo fora da rede até que ele comprove sua identidade. Um servidor RADIUS verifica essa identidade.

Com o EAP-TLS, a identidade é um certificado X.509 emitido para uma pessoa nomeada ou dispositivo gerenciado. O RADIUS então retorna uma política: VLAN, função e lista de acesso. Um enfermeiro da ala médica entra na VLAN clínica. Um prestador de serviços de instalações entra em um segmento que alcança apenas a gestão do edifício.

Duas outras especificações afetam o WiFi. A desconexão automática (endereçável) mapeia-se para tempos limites de sessão e intervalos de reautenticação. O acesso de emergência (obrigatório) significa um plano documentado para o que acontece se o serviço RADIUS ficar inacessível.

O que o auditor procura: sua política de controle de acesso, uma lista de todos os SSIDs com seus respectivos métodos de autenticação e como uma pessoa obtém e perde acesso. Espere ter que provar que nenhum SSID que trafega ePHI utiliza uma chave compartilhada.

Controles de auditoria - 164.312(b)

O padrão exige mecanismos que registrem e examinem a atividade em sistemas que contêm ou usam ePHI. Ele não possui especificações de implementação, portanto o método é seu. Para redes sem fio, o RADIUS Accounting (RFC 2866) é o log de auditoria.

Cada sessão produz registros de Start, Interim-Update e Stop. Os atributos respondem diretamente às perguntas do auditor:

• Quem: User-Name, o certificado ou a identidade do diretório.
• Qual dispositivo: Calling-Station-Id, o endereço MAC do cliente.
• Onde: Called-Station-Id, o ponto de acesso e o SSID.
• Quando e por quanto tempo: Event-Timestamp e Acct-Session-Time.
• Por que foi encerrado: Acct-Terminate-Cause.

Registrar é metade do padrão. Examinar é a outra metade, e o item 164.308(a)(1)(ii)(D) exige a revisão regular da atividade do sistema de informação. Transmita os registros de contabilidade para a sua plataforma SIEM. Em seguida, agende e documente a revisão.

O que o auditor procura: uma exportação para um intervalo de datas de amostra e evidências de que alguém a revisa. O item 164.316(b)(2)(i) exige retenção de seis anos da documentação obrigatória. Muitas organizações aplicam o mesmo prazo para evidências de log.

Integridade - 164.312(c)(1)

O padrão protege as ePHI contra alteração ou destruição inadequadas. No link de rádio, o AES-CCMP adiciona uma verificação de integridade de mensagem a cada quadro. O WPA3-Enterprise também torna os Protected Management Frames (IEEE 802.11w) obrigatórios. Eles bloqueiam quadros de desautenticação forjados, uma forma comum de desconectar dispositivos clínicos da rede. O modo WPA3-Enterprise 192-bit migra para o AES-GCMP-256.

O TKIP, a cifra legado do WPA, depende de uma verificação de integridade fraca. O IEEE descontinuou o TKIP no 802.11-2012.

O que o auditor procura: configurações de cifra do controlador mostrando apenas AES, TKIP desativado e proteção de quadros de gerenciamento ativa.

Autenticação de pessoa ou entidade - 164.312(d)

O padrão exige que você verifique se a pessoa ou entidade que solicita acesso é quem declara ser. Este é o argumento principal para usar EAP-TLS em vez de PEAP-MSCHAPv2.

O PEAP (Protected EAP) envolve uma troca de nome de usuário e senha dentro de um túnel TLS. Se um cliente ignorar a validação do certificado do servidor, um access point não autorizado poderá se passar pela sua rede. Ele captura a troca MS-CHAPv2, que pode ser quebrada offline. O Aviso de Segurança da Microsoft 2743314 documenta isso. Ele recomenda a validação do certificado do servidor ou a migração para a autenticação baseada em certificados. A Microsoft também documenta que o Windows Defender Credential Guard bloqueia o single sign-on para MS-CHAPv2 com credenciais salvas.

O EAP-TLS realiza a autenticação mútua por certificados. O dispositivo prova que possui uma chave privada e o servidor prova sua própria identidade. Não há senha para sofrer phishing. A chave privada pode residir, não exportável, no TPM (Trusted Platform Module) ou enclave seguro do dispositivo. Dispositivos médicos também contam como entidades, e dispositivos compatíveis podem carregar seus próprios certificados.

O que o auditor procura: como você verifica a identidade em cada rota de acesso. "A equipe sabe a senha do WiFi" não é uma resposta. Mostre o procedimento de emissão de certificados, vinculado ao registro de contratação do RH, e a etapa de revogação para ex-funcionários.

Segurança de transmissão - 164.312(e)(1)

O padrão protege contra o acesso não autorizado a ePHI em trânsito. Suas duas especificações, controles de integridade e criptografia, são ambas abordáveis. O WPA2-Enterprise com TKIP falha, porque a cifra foi descontinuada. O IEEE 802.11n também exclui o TKIP de taxas de alto rendimento (high-throughput). O WPA2-Enterprise com AES-CCMP é defensável hoje. O WPA3-Enterprise é a configuração a ser implantada agora.

As diretrizes de violação do HHS tratam as ePHI em trânsito como seguras quando a criptografia segue as normas NIST SP 800-52, 800-77 ou 800-113. Essas publicações cobrem TLS, IPsec e VPNs SSL. O WPA3 no rádio não coloca, por si só, o tráfego nesse porto seguro. O TLS na camada de aplicação ainda importa.

O que o auditor procura: configurações de criptografia em cada SSID da equipe e um registro de desativação de SSIDs legados.

Quais configurações sem fio se mantêm seguras?

O iPSK (identity pre-shared key) fornece a cada dispositivo ou grupo de dispositivos sua própria senha em um único SSID.

Configuração	Identificação única	Trilha de auditoria	Autenticação	Criptografia em trânsito	Posição de auditoria
WPA2-PSK compartilhado, TKIP	Nenhuma - um segredo compartilhado	Apenas MAC e IP	Conhecimento da frase de secreta	Cifra descontinuada	Falha
WPA2-PSK compartilhado, AES	Nenhuma - um segredo compartilhado	Apenas MAC e IP	Conhecimento da frase secreta	AES; qualquer detentor da chave pode descriptografar sessões capturadas	Falha para acesso de funcionários a ePHI
iPSK por dispositivo	Por dispositivo, não por pessoa	Chave de dispositivo nomeado	Posse da chave do dispositivo	AES-CCMP	Aceitável para dispositivos clínicos sem interface com controles compensatórios documentados
WPA2-Enterprise, PEAP-MSCHAPv2	Por pessoa	Nome de usuário por sessão	Senha; exposta se a validação de certificado estiver desativada	AES-CCMP	Defensável com validação imposta e um plano de migração
WPA2-Enterprise, EAP-TLS	Por pessoa ou dispositivo	Identidade do certificado por sessão	Certificado mútuo	AES-CCMP	Forte
WPA3-Enterprise, EAP-TLS	Por pessoa ou dispositivo	Identidade do certificado por sessão	Certificado mútuo	AES-CCMP mais PMF obrigatório	Configuração de destino
WPA3-Enterprise 192-bit, EAP-TLS	Por pessoa ou dispositivo	Identidade do certificado por sessão	Certificado mútuo, ECC de 384 bits	AES-GCMP-256 mais PMF	Maior garantia; confirme o suporte do dispositivo primeiro

O que um auditor do OCR analisa em uma rede sem fio hospitalar?

O HHS Office for Civil Rights (OCR) aplica a HIPAA. Suas revisões são baseadas principalmente em documentos. Os auditores não percorrem as enfermarias com um analisador de espectro. Eles solicitam políticas, configurações e registros e, em seguida, testam se os registros correspondem à política.

Comece com a análise de risco. O Relatório do Setor de Auditorias da HIPAA de 2016-2017 do OCR, publicado em dezembro de 2020, descobriu que a maioria das entidades cobertas auditadas não implementou a análise de risco e o gerenciamento de risco de forma eficaz. Uma análise de risco que omite a WLAN é uma constatação fácil.

Requisito	O que o OCR pede para ver	Evidência de rede sem fio que responde
Análise de risco, 164.308(a)(1)(ii)(A)	Inventário de sistemas que manipulam ePHI e ameaças a cada um	Todos os SSIDs, seus métodos de autenticação, VLAN e classes de dispositivos
Controle de acesso, 164.312(a)(1)	Comprovante de que cada pessoa possui um identificador único	Configuração de 802.1X e EAP-TLS; zero SSIDs de chave compartilhada trafegando ePHI
Controles de auditoria, 164.312(b)	Logs e evidências de revisão	Exportação de RADIUS Accounting para um intervalo de datas de amostra; registros de revisão de SIEM
Integridade, 164.312(c)(1)	Como a ePHI é protegida contra alteração	Configurações de cifra do controlador: apenas AES, PMF obrigatório
Autenticação, 164.312(d)	Como a identidade é verificada em cada rota	Procedimento de emissão e revogação de certificado vinculado aos registros do RH
Segurança de transmissão, 164.312(e)(1)	Decisão de criptografia, com justificativa se não for implementada	Configuração do WPA3-Enterprise e registro de desativação de SSIDs legados
Rescisão, 164.308(a)(3)(ii)(C)	Comprovante de que os desligados perdem o acesso	Carimbos de data/hora de revogação definidos em relação às datas de saída do RH

Espere perguntas sobre a rede de pacientes e visitantes também. Os auditores querem ver se ela não consegue acessar ePHI.

Onde os dispositivos médicos e o WiFi de pacientes se posicionam em relação ao WiFi da equipe?

As bombas de infusão e os equipamentos de imagem estão no escopo?

Esta é a pergunta de definição de escopo que confunde muitas equipes de TI de saúde. O teste é se o dispositivo cria, recebe, mantém ou transmite ePHI. Bombas de infusão inteligentes que trocam ordens vinculadas a pacientes com o EHR estão no escopo. O mesmo se aplica a modalidades de imagem que enviam estudos DICOM para o PACS e monitores de telemetria transmitindo para uma estação central. Um registrador de temperatura de geladeira de vacinas não carrega dados de pacientes e fica fora do escopo de ePHI.

A dificuldade é que muitos dispositivos no escopo não conseguem executar 802.1X, EAP-TLS ou WPA3. A orientação pré-comercialização de segurança cibernética de 2023 da FDA se aplica a novas submissões de dispositivos. Sua base instalada permanece como está.

Como a segmentação de VLAN limita o risco

Uma VLAN (LAN virtual) é um segmento de rede logicamente separado em hardware compartilhado. Coloque a IoT clínica em SSIDs dedicados ou grupos iPSK, mapeados para uma VLAN por classe de dispositivo. As regras de firewall permitem que cada classe alcance apenas seus servidores designados, como o servidor da bomba ou o PACS. Os dispositivos da equipe não podem acessar as bombas diretamente, e as bombas não podem acessar a VLAN da equipe.

A publicação de Práticas de Segurança Cibernética na Indústria da Saúde do HHS 405(d) recomenda a segmentação de dispositivos médicos de redes gerais. Registre a segmentação em sua análise de risco como o controle compensatório para dispositivos que não podem se autenticar por certificado. Mantenha registros RADIUS para dispositivos iPSK e autenticados por MAC também, para que cada classe de dispositivo apareça no log de auditoria.

A rede de pacientes e visitantes

Sua rede de pacientes e visitantes não carrega ePHI, mas coleta dados pessoais no Captive Portal. Um Captive Portal é a página da web que um visitante vê antes de ficar online. Os auditores perguntarão como essa rede é isolada dos segmentos clínicos. O SecurePass, o adendo de segurança do Purple Guest WiFi, traz a mesma abordagem baseada em identidade para pacientes e visitantes.

Dois cenários práticos

Um hospital do condado descontinua sua senha compartilhada de funcionários

Situação. Considere um hospital administrado pelo condado com 350 leitos. Seu SSID de funcionários executava WPA2-PSK, e a senha era compartilhada com enfermeiros terceirizados há anos. As bombas de infusão estavam na mesma rede. A análise de risco anual sinalizou que a identificação exclusiva não era atendida.

O que foi feito. Estações de trabalho gerenciadas e dispositivos portáteis migraram para o EAP-TLS, com certificados emitidos pela plataforma MDM para identidades do Microsoft Entra ID. A política de RADIUS atribuiu VLANs por grupo do Entra ID. Os registros de contabilização foram transmitidos para o SIEM, com uma revisão semanal documentada. As bombas migraram para iPSK em uma VLAN isolada, com permissão para acessar apenas o servidor de bombas. Os telefones pessoais dos funcionários migraram para um SSID exclusivo para internet.

Resultado. Os segredos compartilhados em redes que trafegam ePHI caíram de dois para zero. "Quem estava no ponto de acesso da sala de medicamentos às 02:00?" tornou-se uma única consulta no SIEM. Anteriormente, isso significava correlacionar manualmente atribuições DHCP com registros de crachás. Funcionários desligados agora perdem o acesso no momento em que seu certificado é revogado e sua associação ao grupo do Microsoft Entra ID é removida. Nenhum outro dispositivo é afetado.

Uma rede de farmácias unifica o acesso de funcionários em 60 lojas

Situação. Considere uma rede de farmácias regional com 60 lojas, cada uma com um dispensário e uma sala de atendimento. As farmácias são entidades cobertas pela HIPAA. Pagamentos com cartão também trazem o PCI-DSS para o escopo. Cada loja utilizava uma senha compartilhada para terminais do dispensário, tablets e telefones de funcionários. As lojas mais novas usavam Cisco Meraki e as mais antigas usavam Ubiquiti UniFi.

O que foi feito. Cada loja ganhou um SSID de funcionários 802.1X com EAP-TLS, autenticado em um único serviço RADIUS na nuvem. Nenhum ponto de acesso foi substituído. Os registros de contabilidade foram direcionados para um log centralizado. Os clientes do varejo permaneceram em uma rede de visitantes separada.

Resultado. As senhas compartilhadas em nível de loja caíram de 60 para zero, assim como as visitas para rotação de senhas. Um único conjunto de controles agora atende à identificação exclusiva da HIPAA e ao Requisito 8.2.1 do PCI-DSS v4.0, que exige uma ID exclusiva para cada pessoa.

Quais são os limites dos controles sem fio em uma análise de risco da HIPAA?

Os controles de WiFi protegem um salto. Controles de acesso a EHR, TLS na camada de aplicação e criptografia de endpoint carregam o restante da carga. A HIPAA é neutra em relação à tecnologia e não nomeia nenhum protocolo sem fio, portanto, sua análise de risco deve explicar cada escolha.

Dispositivos legados definem o nível mínimo. O modo de transição WPA3-Enterprise mantém clientes WPA2 conectados, mas também mantém as fragilidades do WPA2 nesse SSID. Execute um SSID exclusivo para WPA3 para dispositivos compatíveis e desative o SSID de transição de acordo com um cronograma planejado.

Os certificados precisam de um ciclo de vida. Um certificado de servidor RADIUS expirado deixa todos os clientes offline de uma só vez. Automatize a renovação e monitore as datas de expiração.

O roaming precisa de ajuste. Uma troca 802.1X completa em cada ponto de acesso adiciona atraso, o que é percebido primeiro por crachás de voz. A transição BSS rápida (802.11r) encurta esse tempo. Veja 802.11r e 802.11k no Android: implantação de roaming rápido no Cisco Meraki, HPE Aruba e Ubiquiti UniFi. Em infraestruturas Meraki, veja Cisco Meraki 802.11r adaptável vs ativado: corrigindo o roaming em pontos de acesso MR.

Por fim, a Public Law 116-321 orienta o HHS a considerar as práticas de segurança reconhecidas que você manteve nos 12 meses anteriores ao definir penalidades. Mapear seus controles sem fio para as práticas 405(d) ajuda nesse processo.

O que você deve fazer antes da sua próxima análise de risco?

1. Faça um inventário de cada SSID, seu método de autenticação, cifra e VLAN.
2. Classifique os dispositivos como funcionários gerenciados, funcionários pessoais, IoT clínico ou visitante.
3. Mova dispositivos gerenciados para EAP-TLS, com políticas baseadas em grupos de diretório.
4. Desative o TKIP, exija PMF e programe o WPA3-Enterprise.
5. Transmita o RADIUS Accounting para o seu SIEM, documente a revisão e defina a retenção.
6. Segmente a IoT clínica por classe de dispositivo e documente os controles compensatórios.
7. Revalide a cobertura após alterações de cifra e SSID. O guia WiFi Site Surveys: A Practical Planning Guide apresenta o método.
8. Registre cada decisão na análise de risco, com as evidências anexadas.

O Staff WiFi da Purple oferece 802.1X com EAP-TLS, política de VLAN por pessoa e RADIUS accounting centralizado na nuvem. Ele se integra sobre o hardware de Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme Networks e Fortinet. Microsoft Entra ID, Okta e Google Workspace gerenciam admissões, movimentações e desligamentos. A Purple possui certificação ISO 27001 e opera em mais de 80.000 locais ativos, com 440 milhões de logins em 2024 (dados da Purple). Leia mais em nossa página de Healthcare e em Why your next WiFi upgrade doesn't need new hardware.

Consulte também a visão geral do Staff WiFi da Purple, o SecurePass para a rede de pacientes e visitantes e nossos guias de conformidade de staff WiFi ISO 27001 e SOC 2 se você gerencia vários frameworks ao mesmo tempo.

Perguntas frequentes

A HIPAA exige WPA3-Enterprise ou o WPA2-Enterprise é aceitável?

Não, a HIPAA não nomeia o WPA3-Enterprise ou qualquer outro protocolo. O WPA2-Enterprise com AES-CCMP e EAP-TLS continua justificável em uma análise de risco atualmente. O WPA2 com TKIP não é, pois o IEEE descontinuou essa cifra no 802.11-2012. Implante o WPA3-Enterprise em novos SSIDs de equipe onde os dispositivos suportem e documente um plano datado para o restante. A atualização proposta para a Regra de Segurança do HHS tornaria a criptografia em trânsito obrigatória, portanto, projete para esse padrão agora.

Podemos manter uma senha compartilhada para a equipe se a documentarmos na análise de risco?

Não, não para o acesso da equipe a ePHI. A identificação exclusiva de usuário em 164.312(a)(2)(i) é uma especificação obrigatória, portanto a documentação não pode substituí-la. Uma senha compartilhada não identifica ninguém, e cada funcionário desligado mantém o acesso até a próxima rotação. Chaves compartilhadas ou por dispositivo permanecem aceitáveis apenas para dispositivos clínicos headless. Esses dispositivos também precisam de segmentação de VLAN e dos controles compensatórios registrados em sua análise de risco.

Precisamos de novos pontos de acesso para migrar para 802.1X e EAP-TLS?

Não, o 802.1X e o EAP-TLS funcionam nos pontos de acesso corporativos que a maioria dos hospitais já possui. O RADIUS em nuvem da Purple funciona com Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme Networks e Fortinet. O trabalho está na emissão de certificados, integração de diretório e política RADIUS, não no hardware. Planeje uma verificação de rádio apenas se você também estiver migrando para o WPA3, pois pontos de acesso mais antigos podem precisar de atualizações de firmware.

Por quanto tempo devemos manter os logs de acesso sem fio para a HIPAA?

Mantenha-os por seis anos se quiser um padrão defensável. A regra de documentação da HIPAA no item 164.316(b)(2)(i) exige a retenção de seis anos da documentação obrigatória. Muitas organizações aplicam o mesmo período para as evidências de log de auditoria por trás dela. Confirme o período com o seu líder de conformidade, pois as leis estaduais podem exigir prazos maiores. Armazene registros de RADIUS Accounting em um sistema que você possa consultar por pessoa, dispositivo e intervalo de datas.

Dispositivos médicos na WiFi estão no escopo das salvaguardas técnicas?

Sim, se o dispositivo criar, receber, mantiver ou transmitir ePHI. Bombas de infusão inteligentes vinculadas ao EHR, modalidades de imagem que enviam exames ao PACS e monitores de telemetria se qualificam. Dispositivos que não podem executar EAP-TLS devem ficar em VLANs dedicadas, usando iPSK sempre que possível. As regras de firewall devem limitar cada classe de dispositivo aos seus servidores designados. Registre a segmentação como o controle compensatório em sua análise de risco.

Um auditor do OCR perguntará sobre a nossa WiFi de pacientes e visitantes?

Sim, espere perguntas sobre a rede de pacientes e visitantes juntamente com a WiFi da equipe. Os auditores querem provas de que ela não consegue alcançar segmentos clínicos que trafegam ePHI. Eles também podem perguntar como o Captive Portal trata os dados pessoais. Mostre o design da rede, as regras de firewall e os dados coletados no cadastro. O SecurePass, o complemento de segurança do Purple Guest WiFi, estende o acesso baseado em identidade para pacientes e visitantes.

O Purple se integra ao Microsoft Entra ID, Okta e Google Workspace?

Sim, a Staff WiFi do Purple se integra ao Microsoft Entra ID, Okta e Google Workspace. Os grupos de diretório direcionam a política RADIUS, para que a função de uma pessoa decida qual VLAN ela alcançará. Novos colaboradores ganham acesso quando adicionados ao grupo correto. Pessoas que mudam de cargo alteram de VLAN quando seu grupo muda. Pessoas desligadas perdem o acesso quando você revoga seu certificado e remove sua associação ao grupo, com cada etapa registrada para a trilha de auditoria.