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

Cinco normas de salvaguarda técnica da Regra de Segurança HIPAA em 45 CFR 164.312 aplicam-se ao WiFi da equipa do hospital. São elas: controlo de acesso, controlos de auditoria, integridade, autenticação de pessoa ou entidade e segurança de transmissão. Pode cumpri-las com 802.1X e identidade EAP-TLS baseada em certificados, RADIUS Accounting como registo de auditoria e encriptação WPA3-Enterprise em cada SSID de colaboradores.

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

O WiFi dos colaboradores é a base sem fios de uma rede de cuidados de saúde em conformidade com a HIPAA. Os médicos abrem o registo de saúde eletrónico em estações de trabalho móveis. Digitalizam 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 cruza um SSID de colaboradores. O Staff WiFi da Purple trata esse SSID como uma camada de identidade e não como uma palavra-passe, e a Regra de Segurança empurra-o na mesma direção.

A Regra de Segurança protege a informação de saúde eletrónica protegida (ePHI) que cria, recebe, mantém ou transmite (45 CFR 164.306(a)). Divide os requisitos em salvaguardas administrativas, físicas e técnicas. As salvaguardas técnicas contêm cinco normas. A WLAN dos seus colaboradores transmite ePHI, pelo que todas as cinco alcançam a camada sem fios.

Dois termos importam antes de continuar a ler. Uma especificação de implementação "obrigatória" deve ser implementada exatamente como escrita. Uma "abordável" deve ser implementada se for razoável e apropriada. Se não for, documenta o motivo e adota uma medida equivalente (45 CFR 164.306(d)). Abordável não é opcional, e num link de rádio aberto raramente existe um argumento credível contra a encriptação.

Em janeiro de 2025, o HHS publicou um aviso de proposta de regulamentação que removeria a categoria abordável. Tornaria obrigatória a encriptação de ePHI em trânsito e a autenticação multifator. Verifique o seu estado quando definir o âmbito da sua próxima análise de risco. Projetar agora de acordo com o texto mais rigoroso evita uma segunda migração mais tarde.

Por que razão uma frase-passe de WiFi partilhada falha a Regra de Segurança?

Uma rede WPA2-PSK (chave pré-partilhada) autentica a frase-passe, não a pessoa. Cada enfermeiro, auxiliar, médico substituto de agência e prestador de serviços que a conhece parece idêntico para a rede. A "identificação de utilizador única" em 164.312(a)(2)(i) é uma especificação obrigatória. Pede-lhe que atribua um nome ou número único a cada pessoa, para que possa identificá-la e acompanhar a sua atividade. Uma frase-passe partilhada não consegue fazer isso, e nenhuma documentação altera esse facto.

A falha espalha-se pelas outras normas:

• Controlos de auditoria. O registo grava um endereço MAC e um aluguer de IP, não um membro identificado da equipa. As versões atuais do iOS e do Android aleatorizam os endereços MAC por predefinição, o que enfraquece até isso.
• Autenticação de pessoa ou entidade. Conhecer uma frase-passe não prova nada sobre a identidade. As frases-passe escapam através de notas adesivas, escalas de serviço e mensagens de grupo.
• Segurança da transmissão. Qualquer pessoa na posse da frase de passe que capture o handshake de quatro vias de um dispositivo pode derivar as suas chaves de sessão. Pode, então, desencriptar o tráfego desse dispositivo. Um ex-colaborador com a frase de passe antiga permanece dentro do limite de encriptação.
• Cessação. O 164.308(a)(3)(ii)(C) prevê que o acesso termine quando a relação laboral termina. Com uma chave partilhada, remover uma pessoa significa alterar a chave para todos.

Este último ponto transforma a rotação de PSK num espetáculo. A rotação perturba todos os dispositivos, pelo que acontece raramente. Cada pessoa que sai entre rotações mantém o acesso.

Como se mapeiam as cinco normas nos controlos sem fios?

Controlo de acessos - 164.312(a)(1)

A norma limita o acesso a ePHI a pessoas e software com direitos de acesso concedidos. Na camada sem fios, o IEEE 802.1X é a implementação. É uma norma de controlo de acessos baseada em portas que mantém cada dispositivo fora da rede até que este prove a sua identidade. Um servidor RADIUS (Remote Authentication Dial-In User Service) verifica essa identidade.

Com o EAP-TLS (Extensible Authentication Protocol - Transport Layer Security), a identidade é um certificado X.509 emitido a uma pessoa identificada ou a um dispositivo gerido. O RADIUS devolve depois uma política: VLAN, função e lista de acessos. Um enfermeiro de enfermaria fica alocado à VLAN clínica. Um prestador de serviços de instalações fica num segmento que alcança apenas a gestão do edifício.

Duas especificações adicionais dizem respeito ao WiFi. O encerramento automático de sessão (endereçável) mapeia para tempos limite 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: a sua política de controlo de acessos, uma lista de todos os SSID com o respetivo método de autenticação e como uma pessoa obtém e perde o acesso. Conte ter de demonstrar que nenhum SSID que transporte ePHI utiliza uma chave partilhada.

Controled de auditoria - 164.312(b)

A norma exige mecanismos que registem e examinem a atividade em sistemas que contenham ou utilizem ePHI. Não possui especificações de implementação, pelo que o método é seu. Para redes sem fios, o RADIUS Accounting (RFC 2866) é o registo de auditoria.

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

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

O registo é metade da norma. O exame é a outra metade, e o 164.308(a)(1)(ii)(D) exige a revisão regular da atividade do sistema de informação. Transmita os registos de contabilidade para a sua plataforma SIEM (security information and event management). Em seguida, agende e documente a revisão.

O que o auditor procura: uma exportação para um intervalo de datas de amostra e provas de que alguém a revê. O 164.316(b)(2)(i) exige a retenção de documentação obrigatória por seis anos. Muitas organizações aplicam o mesmo horizonte temporal às evidências de registos.

Integridade - 164.312(c)(1)

A norma protege as ePHI contra alteração ou destruição indevidas. Na ligação de rádio, o AES-CCMP adiciona uma verificação de integridade de mensagem a cada trama. O WPA3-Enterprise também torna obrigatórias as Protected Management Frames (IEEE 802.11w). Estas bloqueiam tramas de desautenticação forjadas, uma forma comum de desligar dispositivos clínicos da rede. O modo WPA3-Enterprise de 192 bits passa para AES-GCMP-256.

O TKIP, a cifra WPA legada, baseia-se numa verificação de integridade fraca. O IEEE descontinuou o TKIP na norma 802.11-2012.

O que o auditor procura: definições de cifra do controlador que mostrem apenas AES, TKIP desativado e proteção de tramas de gestão ativa.

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

A norma exige que verifique se a pessoa ou entidade que procura acesso é quem alega ser. Este é o argumento central para a utilização de EAP-TLS em vez de PEAP-MSCHAPv2.

O PEAP (Protected EAP) envolve uma troca de nome de utilizador e palavra-passe num túnel TLS. Se um cliente ignorar a validação do certificado do servidor, um access point falso pode personificar a sua rede. Este captura a troca MS-CHAPv2, que pode ser quebrada offline. O Microsoft Security Advisory 2743314 documenta este problema, recomendando a validação do certificado do servidor ou a migração para 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 guardadas.

O EAP-TLS realiza a autenticação mútua por certificado. O dispositivo prova que possui uma chave privada e o servidor prova a sua própria identidade. Não existe palavra-passe para ser alvo de phishing. A chave privada pode permanecer, de forma não exportável, no TPM (Trusted Platform Module) ou enclave seguro do dispositivo. Os dispositivos médicos também contam como entidades, e os dispositivos com essa capacidade podem carregar os seus próprios certificados.

O que o auditor procura: como verifica a identidade em cada rota de acesso. "A equipa sabe a palavra-passe do WiFi" não é uma resposta. Mostre o procedimento de emissão de certificados, associado ao registo de entrada no RH, e a etapa de revogação para saídas de funcionários.

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

A norma previne o acesso não autorizado a ePHI em trânsito. As suas duas especificações, controlos de integridade e encriptação, são ambas endereçáveis. O WPA2-Enterprise com TKIP falha, porque a cifra foi descontinuada. O IEEE 802.11n também exclui o TKIP de taxas de elevado débito. O WPA2-Enterprise com AES-CCMP é defensável atualmente. O WPA3-Enterprise é a configuração a implementar agora.

As orientações sobre violações do HHS consideram as ePHI em movimento protegidas quando a encriptação segue as normas NIST SP 800-52, 800-77 ou 800-113. Essas publicações cobrem TLS, IPsec e VPNs SSL. O WPA3 no sinal de rádio não coloca, por si só, o tráfego nesse porto de abrigo. O TLS na camada de aplicação continua a ser essencial.

O que o auditor procura: definições de encriptação em cada SSID da equipa e um registo da desativação de SSIDs legados.

Quais as configurações sem fios que resistem a uma auditoria?

O iPSK (identity pre-shared key) atribui a cada dispositivo ou grupo de dispositivos a sua própria frase de segurança num único SSID.

Configuração	Identificação única	Pista de auditoria	Autenticação	Encriptação em trânsito	Posição de auditoria
WPA2-PSK partilhado, TKIP	Nenhuma - um segredo partilhado	Apenas MAC e IP	Conhecimento da frase de passe	Cifra descontinuada	Falha
WPA2-PSK partilhado, AES	Nenhuma - um segredo partilhado	Apenas MAC e IP	Conhecimento da frase de passe	AES; qualquer detentor da chave pode desencriptar sessões capturadas	Falha para acesso da equipa a ePHI
iPSK por dispositivo	Por dispositivo, não por pessoa	Chave de dispositivo nomeada	Posse da chave do dispositivo	AES-CCMP	Aceitável para dispositivos clínicos sem interface de utilizador com controlos de compensação documentados
WPA2-Enterprise, PEAP-MSCHAPv2	Por pessoa	Nome de utilizador por sessão	Palavra-passe; exposta se a validação do 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-alvo
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 primeiro o suporte do dispositivo

O que analisa um auditor da OCR numa rede sem fios hospitalar?

O HHS Office for Civil Rights (OCR) aplica a HIPAA. As suas revisões baseiam-se maioritariamente em documentação. Os auditores não percorrem as enfermarias com um analisador de espetro. Solicitam políticas, configurações e registos, e depois testam se os registos correspondem à política.

Comece pela análise de risco. O Relatório do Setor de Auditorias HIPAA 2016-2017 do OCR, publicado em dezembro de 2020, revelou que a maioria das entidades cobertas auditadas não implementou a análise e a gestão de risco de forma eficaz. Uma análise de risco que omita a WLAN é um achado fácil.

Requisito	O que o OCR pede para ver	Evidência sem fios que responde ao requisito
Análise de risco, 164.308(a)(1)(ii)(A)	Inventário de sistemas que gerem ePHI e ameaças a cada um	Cada SSID, o seu método de autenticação, VLAN e classes de dispositivos
Controlo de acesso, 164.312(a)(1)	Prova de que cada pessoa tem um identificador único	Configuração de 802.1X e EAP-TLS; zero SSIDs de chave partilhada a transmitir ePHI
Controlos de auditoria, 164.312(b)	Registos e evidências de revisão	Exportação do RADIUS Accounting para um intervalo de datas de amostra; registos de revisão do SIEM
Integridade, 164.312(c)(1)	Como a ePHI é protegida contra alteração	Definiçõ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 certificados associado aos registos de RH
Segurança na transmissão, 164.312(e)(1)	Decisão de encriptação, com justificação se não for implementada	Configuração de WPA3-Enterprise e registo de desativação de SSID legado
Cessação, 164.308(a)(3)(ii)(C)	Prova de que os colaboradores que saem perdem o acesso	Marcas temporais de revogação definidas em conformidade com as datas de saída dos RH

Espere também perguntas sobre a rede de pacientes e visitantes. Os auditores querem verificar se esta não consegue aceder a ePHI.

Onde se posicionam os dispositivos médicos e a WiFi de pacientes em relação à WiFi da equipa?

As bombas de infusão e os equipamentos de imagiologia estão no âmbito?

Esta é a pergunta de definição de âmbito que faz tropeçar muitas equipas de TI de saúde. O teste consiste em saber se o dispositivo cria, recebe, mantém ou transmite ePHI. As bombas de infusão inteligentes que trocam ordens associadas a pacientes com o EHR estão no âmbito. O mesmo acontece com as modalidades de imagiologia que enviam estudos DICOM para o PACS e com os monitores de telemetria que transmitem para uma estação central. Um registador de temperatura de um frigorífico de vacinas não transporta dados de pacientes e fica fora do âmbito da ePHI.

A dificuldade é que muitos dispositivos no âmbito não conseguem executar 802.1X, EAP-TLS ou WPA3. As orientações prévias ao mercado de cibersegurança de 2023 da FDA aplicam-se a novas submissões de dispositivos. A sua base instalada permanece tal como está.

Como a segmentação por VLAN contém o risco

Uma VLAN (LAN virtual) é um segmento de rede logicamente separado em hardware partilhado. Coloque a IoT clínica em SSIDs dedicados ou grupos iPSK, mapeados para uma VLAN por classe de dispositivo. As regras de firewall permitem depois que cada classe aceda apenas aos seus servidores designados, como o servidor de bombas ou o PACS. Os dispositivos da equipa não conseguem aceder diretamente às bombas, e as bombas não conseguem aceder à VLAN da equipa.

A publicação Health Industry Cybersecurity Practices da HHS 405(d) recomenda a segmentação de dispositivos médicos em relação às redes gerais. Registe a segmentação na sua análise de risco como o controlo compensatório para dispositivos que não conseguem autenticar-se por certificado. Mantenha também registos RADIUS para dispositivos iPSK e autenticados por MAC, para que todas as classes de dispositivos apareçam no registo de auditoria.

A rede de pacientes e visitantes

A sua rede de pacientes e visitantes não transporta ePHI, mas recolhe dados pessoais no Captive Portal. Um Captive Portal é a página web que um visitante vê antes de aceder à internet. Os auditores irão perguntar como essa rede é isolada dos segmentos clínicos. O SecurePass, o suplemento 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 distrital descontinua a sua frase de acesso partilhada da equipa

Situação. Considere um hospital gerido pelo município com 350 camas. O SSID da sua equipa utilizava WPA2-PSK e a frase de acesso tinha sido partilhada com enfermeiros contratados durante anos. As bombas de infusão estavam na mesma rede. A análise de risco anual identificou a identificação única como não cumprida.

O que foi feito. As estações de trabalho geridas e os dispositivos portáteis mudaram para EAP-TLS, com certificados emitidos através da plataforma MDM para identidades do Microsoft Entra ID. A política RADIUS atribuiu VLANs por grupo do Entra ID. Os registos de contabilidade foram transmitidos para o SIEM, com uma revisão semanal documentada. As bombas mudaram para iPSK numa VLAN isolada, com permissão apenas para aceder ao servidor de bombas. Os telemóveis pessoais da equipa mudaram para um SSID exclusivo para internet.

Resultado. Os segredos partilhados em redes que transportam ePHI caíram de dois para zero. "Quem estava no ponto de acesso da sala de medicação às 02:00?" passou a ser uma simples consulta no SIEM. Anteriormente, implicava correlacionar manualmente as concessões DHCP com os registos de cartões de acesso. Os colaboradores que saem da empresa perdem agora o acesso quando o seu certificado é revogado e a pertença ao grupo do Microsoft Entra ID é removida. Nenhum outro dispositivo é afetado.

Uma cadeia de farmácias unifica o acesso da equipa em 60 lojas

Situação. Considere uma cadeia regional de farmácias com 60 lojas, cada uma com um dispensário e uma sala de consultas. As farmácias são entidades abrangidas pela HIPAA. Os pagamentos por cartão também colocam o PCI-DSS no âmbito de aplicação. Cada loja utilizava uma frase de acesso partilhada para terminais do dispensário, tablets e telefones dos funcionários. As lojas mais recentes utilizavam Cisco Meraki e as lojas mais antigas utilizavam Ubiquiti UniFi.

O que foi feito. Cada loja ganhou um SSID de funcionários 802.1X com EAP-TLS, autenticado num único serviço RADIUS na nuvem. Nenhum ponto de acesso foi substituído. Os registos de contabilidade foram encaminhados para um registo centralizado. Os clientes do Retalho permaneceram numa rede de convidados separada.

Resultado. As frases de acesso partilhadas ao nível da loja caíram de 60 para zero, tal como as deslocações para rotação de frases de acesso. Um único conjunto de controlos responde agora à identificação exclusiva da HIPAA e ao Requisito 8.2.1 do PCI-DSS v4.0, que exige uma identificação exclusiva para cada pessoa.

Quais são os limites dos controlos sem fios numa análise de risco HIPAA?

Os controlos de WiFi protegem apenas um salto. Os controlos de acesso a EHR, o TLS na camada de aplicação e a encriptação de pontos de extremidade suportam o resto da carga. A HIPAA é neutra do ponto de vista tecnológico e não especifica nenhum protocolo sem fios, pelo que a sua análise de risco deve explicar cada escolha.

Os dispositivos legados definem o limite mínimo. O modo de transição WPA3-Enterprise mantém os clientes WPA2 ligados, mas também mantém as vulnerabilidades do WPA2 nesse SSID. Execute um SSID exclusivo para WPA3 para dispositivos compatíveis e desative o SSID de transição com base num plano agendado.

Os certificados precisam de um ciclo de vida. Um certificado de servidor RADIUS expirado coloca todos os clientes offline em simultâneo. Automatize a renovação e monitorize as datas de expiração.

O roaming precisa de otimização. Uma troca completa 802.1X em cada ponto de acesso adiciona latência, algo que os crachás de voz detetam imediatamente. A transição rápida BSS (802.11r) reduz esse tempo. Consulte 802.11r e 802.11k no Android: implementação de roaming rápido em Cisco Meraki, HPE Aruba e Ubiquiti UniFi. Em infraestruturas Meraki, consulte Cisco Meraki 802.11r adaptativo vs ativado: corrigir o roaming em pontos de acesso MR.

Por fim, a Lei Pública 116-321 orienta o HHS a considerar as práticas de segurança reconhecidas que manteve em vigor nos 12 meses anteriores ao determinar penalizações. O mapeamento dos seus controlos sem fios para as práticas 405(d) ajuda neste processo.

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

1. Faça o inventário de cada SSID, do seu método de autenticação, cifra e VLAN.
2. Classifique os dispositivos como geridos pela equipa, pessoais da equipa, IoT clínico ou convidados.
3. Migre os dispositivos geridos para EAP-TLS, com políticas baseadas em grupos de diretório.
4. Desative o TKIP, exija PMF e agende a transição para WPA3-Enterprise.
5. Envie a contabilidade RADIUS via streaming 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 controlos de compensação.
7. Revalide a cobertura após alterações de cifragem e SSID. O guia WiFi Site Surveys: A Practical Planning Guide define o método.
8. Registe cada decisão na análise de risco, com provas anexadas.

O Staff WiFi da Purple oferece 802.1X com EAP-TLS, política de VLAN por pessoa e contabilidade RADIUS centralizada na nuvem. Integra-se em hardware Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme Networks e Fortinet. O Microsoft Entra ID, Okta e Google Workspace gerem as entradas, transferências e saídas de funcionários. A Purple possui certificação ISO 27001 e opera em mais de 80 000 locais ativos, com 440 milhões de inícios de sessão em 2024 (dados da Purple). Saiba mais na nossa página de Cuidados de Saúde e no artigo 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 os nossos guias de conformidade do staff WiFi ISO 27001 e SOC 2 se aplicar várias estruturas em simultâneo.

Perguntas frequentes

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

Não, a HIPAA não especifica o WPA3-Enterprise nem qualquer outro protocolo. O WPA2-Enterprise com AES-CCMP e EAP-TLS continua a ser defensável numa análise de risco atualmente. O WPA2 com TKIP não o é, porque o IEEE descontinuou essa cifragem no 802.11-2012. Implante o WPA3-Enterprise em novos SSIDs de funcionários onde os dispositivos o suportem e documente um plano com data para os restantes. A atualização proposta para a Regra de Segurança do HHS tornaria a encriptação em trânsito obrigatória, pelo que deve conceber a sua arquitetura segundo esse padrão desde já.

Podemos manter uma palavra-passe partilhada para os funcionários se a documentarmos na análise de risco?

Não, não para o acesso dos funcionários a ePHI. A identificação única de utilizador no ponto 164.312(a)(2)(i) é uma especificação obrigatória, pelo que a documentação não a pode substituir. Uma palavra-passe partilhada não identifica ninguém e cada funcionário que sai mantém o acesso até à rotação seguinte. Chaves partilhadas ou por dispositivo continuam a ser aceitáveis apenas para dispositivos clínicos sem interface de utilizador. Esses dispositivos também necessitam de segmentação por VLAN e dos controlos de compensação registados na sua análise de risco.

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

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

Durante quanto tempo devemos guardar os registos de acesso sem fios para a HIPAA?

Mantenha-os durante seis anos se pretender um padrão defensável. A regra de documentação da HIPAA no ponto 164.316(b)(2)(i) exige a retenção por seis anos da documentação obrigatória. Muitas organizações aplicam o mesmo período aos registos de auditoria associados. Confirme o período com o seu responsável de conformidade, uma vez que a legislação estatal pode exigir um período mais longo. Armazene os registos de RADIUS Accounting num sistema que possa consultar por pessoa, dispositivo e intervalo de datas.

Os dispositivos médicos em WiFi estão no âmbito das salvaguardas técnicas?

Sim, se o dispositivo criar, receber, mantiver ou transmitir ePHI. Bombas de infusão inteligentes ligadas ao EHR, modalidades de imagiologia que enviam exames para o PACS e monitores de telemetria cumprem todos os requisitos. Dispositivos que não consigam executar EAP-TLS devem ser alocados a VLANs dedicadas, utilizando iPSK sempre que possível. As regras de firewall devem limitar cada classe de dispositivos aos seus servidores designados. Registe a segmentação como o controlo de compensação na sua análise de risco.

Um auditor do OCR fará perguntas sobre o nosso WiFi de doentes e visitantes?

Sim, preveja perguntas sobre a rede de doentes e visitantes a par do WiFi de colaboradores. Os auditores pretendem provas de que esta não consegue aceder a segmentos clínicos que transportem ePHI. Podem também perguntar como o Captive Portal trata os dados pessoais. Apresente a arquitetura da rede, as regras de firewall e os dados recolhidos no início de sessão. O SecurePass, o suplemento de segurança do Purple Guest WiFi, alarga o acesso baseado em identidade a doentes e visitantes.

O Purple integra-se com o Microsoft Entra ID, Okta e Google Workspace?

Sim, o Staff WiFi do Purple integra-se com o Microsoft Entra ID, Okta e Google Workspace. Os grupos de diretório orientam a política de RADIUS, pelo que a função de uma pessoa determina a VLAN a que acede. Novas admissões obtêm acesso quando adicionadas ao grupo correto. Mudanças de função alteram a VLAN quando o seu grupo muda. As saídas perdem o acesso assim que revogar o respetivo certificado e remover a sua pertença ao grupo, ficando cada passo registado para a pista de auditoria.