A conformidade para WiFi sem palavra-passe: HIPAA, PCI, ISO 27001

O WiFi sem palavra-passe, ou seja, 802.1X com EAP-TLS baseado em certificados, não é obrigatório por lei ao abrigo da HIPAA, PCI-DSS 4.0 ou ISO 27001. Todos os três exigem identificação única, encriptação forte, revogação imediata e registos de auditoria. Uma palavra-passe partilhada tem sérias dificuldades em todos os pontos. Os certificados por dispositivo cumprem cada expectativa por design e produzem os registos que um auditor analisa.

O que significa realmente a conformidade do WiFi sem palavra-passe?

O WiFi sem palavra-passe substitui uma palavra-passe de rede partilhada por uma credencial única para cada dispositivo ou pessoa. Em redes empresariais, isto significa habitualmente o IEEE 802.1X, o padrão para controlo de acesso à rede baseado em portas. O 802.1X entrega a decisão a um servidor RADIUS. O RADIUS é o protocolo que os pontos de acesso utilizam para perguntar a um servidor de autenticação se um dispositivo se pode associar.

O método mais forte é o EAP-TLS (Extensible Authentication Protocol com Transport Layer Security). Tanto o dispositivo como o servidor apresentam certificados digitais. Não existe nenhuma palavra-passe para pescar (phishing), partilhar ou escrever num quadro na sala do pessoal. Cada sessão deriva as suas próprias chaves de encriptação sob WPA2 ou WPA3.

Dois métodos relacionados merecem destaque:

• PEAP (Protected EAP) com um nome de conta e palavra-passe é 802.1X, mas não é sem palavra-passe. Herda todas as fraquezas da palavra-passe que lhe serve de base.
• iPSK (identity pre-shared key) atribui a cada dispositivo a sua própria chave num único SSID. É uma ponte prática para equipamentos que não conseguem reter um certificado.

"Conformidade do WiFi sem palavra-passe" é o termo abreviado para uma questão. A forma como os seus colaboradores e dispositivos se ligam à rede satisfaz os controlos de acesso, encriptação e registo pelos quais é auditado? Nenhum dos três enquadramentos neste guia nomeia o EAP-TLS. Todos os três descrevem resultados que uma palavra-passe partilhada torna difíceis de provar.

Porque é que uma palavra-passe WiFi partilhada falha numa auditoria?

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

• Sem atribuição. Cada dispositivo autentica-se com o mesmo segredo. Os registos mostram um endereço MAC, não uma pessoa, e os endereços MAC podem ser falsificados.
• Revogação significa rotação. Remover um colaborador que sai significa alterar a chave em todos os dispositivos. O Requisito 2.3.2 do PCI-DSS torna essa rotação obrigatória em redes ligadas a dados de cartões.
• Grande raio de impacto. Uma chave divulgada expõe toda a rede e, frequentemente, todos os locais que a partilham.
• Provas fracas. Não consegue demonstrar a um auditor quem conhecia a chave, quando a conheceu ou se os antigos colaboradores já não a possuem.

O acesso baseado em certificados inverte cada ponto. Cada ligação transporta uma identidade única. Revogar um certificado ou desativar uma conta remove um dispositivo ou uma pessoa. Ninguém conhece uma chave, pelo que ninguém sai com uma.

Como é que o WiFi baseado em certificados cumpre o PCI-DSS 4.0?

O PCI-DSS v4.0 tornou-se a única versão ativa quando a v3.2.1 expirou em 31 de março de 2024. Os 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, utiliza os mesmos números de requisitos referenciados abaixo.

O WiFi sem palavra-passe está em conformidade com o PCI?

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

• 1.3.3 exige controlos de segurança de rede entre cada rede sem fios e o ambiente de dados de titulares de cartões (CDE). O CDE é o conjunto de sistemas que armazenam, processam ou transmitem dados de cartões. O tráfego sem fios para o CDE deve ser negado por predefinição. O acesso baseado em identidade coloca dispositivos autorizados numa VLAN (LAN virtual) específica e nega tudo o resto.
• 2.3.1 e 2.3.2 exigem que altere as chaves sem fios predefinidas do fornecedor. Também deve alterar as chaves de encriptação sem fios sempre que alguém que as conhecia saia. Com o EAP-TLS, nenhuma pessoa conhece uma chave, pelo que o gatilho de saída nunca é acionado.
• 4.2.1.2 exige criptografia forte para autenticação e transmissão em redes sem fios que transportam dados de cartões ou que estejam ligadas ao CDE. O PCI-DSS proíbe o WEP desde 2010. A autenticação mútua de certificados com WPA2-Enterprise ou WPA3-Enterprise cumpre este requisito.
• 8.2.2 restringe as contas partilhadas e genéricas a casos excecionais com justificação documentada. Uma palavra-passe de rede partilhada por 200 colaboradores é difícil de justificar.
• 8.2.5 exige que o acesso de colaboradores cessantes seja revogado imediatamente. Desativar uma conta no seu fornecedor de identidade faz exatamente isso.
• 10.2.1 e 10.5.1 exigem registos de auditoria, retidos por 12 meses com os três meses mais recentes imediatamente disponíveis. Os registos RADIUS do 802.1X atribuem cada ligação a um certificado ou conta.

O WiFi sem palavra-passe não cobre o Requisito 11.2.1. Esse requisito solicita que teste pontos de acesso autorizados e não autorizados pelo menos uma vez a cada três meses. Continua a ser o seu trabalho, conforme explica a secção de limites.

O HIPAA exige WiFi baseado em certificados?

Não. A Regra de Segurança do HIPAA (45 CFR Parte 164, Subparte C) é neutra em termos de tecnologia e não nomeia nenhum protocolo sem fios. Estabelece normas e especificações de implementação, algumas "obrigatórias" e outras "endereçáveis". Endereçável significa que implementa a especificação onde for razoável e apropriado. Caso contrário, documenta o motivo e adota uma alternativa equivalente.

O WiFi baseado em certificados enquadra-se perfeitamente nas salvaguardas técnicas do §164.312:

• Identificação única, §164.312(a)(2)(i), obrigatório. Cada dispositivo e pessoa na rede tem uma identidade distinta.
• Encriptação e desencriptação, §164.312(a)(2)(iv), endereçável. As chaves por sessão protegem a ePHI (informação eletrónica de saúde protegida) em trânsito pelo ar.
• Controlos de auditoria, §164.312(b), obrigatório. Os registos RADIUS registam qual a identidade que se ligou, a partir de qual ponto de acesso e quando.
• Autenticação de pessoa ou entidade, §164.312(d), obrigatório. Um certificado prova que o dispositivo é aquele que afirma ser. Vinculá-lo a uma conta de fornecedor de identidade estende essa prova à pessoa.
• Segurança de transmissão, §164.312(e)(1). Controlos de integridade e encriptação são especificações abordáveis sob esta norma.

As salvaguardas administrativas também importam. A análise de risco em §164.308(a)(1)(ii)(A) é onde regista a razão pela qual os seus controlos sem fios são razoáveis. Os procedimentos de rescisão em §164.308(a)(3)(ii)(C) são mais fáceis de comprovar quando a desativação de uma conta remove o acesso à rede.

Preste atenção à evolução da regulamentação. Em janeiro de 2025, o Departamento de Saúde e Serviços Humanos dos EUA (HHS) publicou uma proposta de norma. Esta removeria a maior parte da distinção entre obrigatório e abordável. Também tornaria obrigatória a encriptação e a autenticação multifator, com exceções limitadas. É uma proposta, não uma norma final. O acesso baseado em certificados já se posiciona do lado correto da mesma.

O que diz a ISO 27001 sobre redes sem fios?

A ISO/IEC 27001:2022 não tem nenhum controlo chamado "sem fios". O Anexo A lista 93 controlos em quatro temas, e vários aplicam-se diretamente à forma como os colaboradores se ligam a uma rede. A ISO/IEC 27002:2022, o guia de implementação, aborda as redes sem fios no controlo 8.22. Refere que os perímetros sem fios são mal definidos. Para ambientes sensíveis, sugere tratar o acesso sem fios como uma ligação externa até passar por um gateway.

Os controlos que um auditor irá testar:

• 5.15 Controlo de acesso e 5.18 Direitos de acesso. Regras para quem pode aderir, e como esse acesso é aprovisionado e removido.
• 5.16 Gestão de identidades e 5.17 Informação de autenticação. Identidades e segredos geridos ao longo do seu ciclo de vida. Uma palavra-passe partilhada é uma informação de autenticação que não pode atribuir a uma única pessoa.
• 8.5 Autenticação segura. Tecnologia de autenticação adequada à sensibilidade do acesso.
• 8.15 Registo de logs e 8.16 Monitorização de atividades. Logs que registam eventos e provas de que alguém os revê.
• 8.20 Segurança de redes, 8.21 Segurança de serviços de rede e 8.22 Segregação de redes.
• 8.24 Utilização de criptografia.
• 5.19 e 5.23. Relações com fornecedores e serviços de nuvem, que se aplicam se a sua autenticação for executada como um serviço de nuvem.

As organizações certificadas pela ISO/IEC 27001:2013 tinham até 31 de outubro de 2025 para fazer 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 mapeiam para WiFi sem palavra-passe

Controlo	Estrutura	O que solicita	Palavra-passe partilhada (PSK)	Baseado em certificado (EAP-TLS)
1.3.3	PCI DSS 4.0	Rejeição por omissão entre redes sem fios e o CDE	Cada dispositivo com a chave entra num único segmento	VLAN por identidade, rejeição por omissão
2.3.2	PCI DSS 4.0	Alterar chaves sem fios quando alguém que as conhecia sai	Rodar a cada saída de colaborador, em todos os dispositivos	Nenhuma pessoa possui uma chave; revoga-se um certificado
4.2.1.2	PCI DSS 4.0	Criptografia forte para autenticação e transmissão sem fios	A força depende da qualidade da frase-passe	Certificados mútuos, chaves por sessão
8.2.2	PCI DSS 4.0	Contas partilhadas apenas por exceção documentada	Partilhada por conceção	Uma credencial por dispositivo ou pessoa
10.5.1	PCI DSS 4.0	12 meses de registos, três meses imediatamente disponíveis	Os registos mostram apenas endereços MAC	Os registos identificam o certificado ou a conta
§164.312(a)(2)(i)	HIPAA	Identificação única (obrigatório)	Não cumprido pela credencial de rede	Cumprido por conceção
§164.312(b)	HIPAA	Controlos de auditoria (obrigatório)	Atribuição fraca	Cada sessão é atribuível
§164.312(e)(1)	HIPAA	Segurança na transmissão	Encriptado, mas chave conhecida por toda a equipa	Encriptado com chaves que nenhuma pessoa conhece
5.17	ISO 27001:2022	Informação de autenticação atribuída e gerida	Não pode ser atribuída a uma única pessoa	Emitida, renovada e revogada por identidade
5.18	ISO 27001:2022	Direitos de acesso aprovisionados e removidos	A remoção exige uma alteração de chave em toda a rede	A remoção segue o fornecedor de identidade
8.22	ISO 27001:2022	Segregação de redes	Um segmento por chave	Segmento por função ou tipo de dispositivo

Que provas irá um auditor solicitar?

Os auditores testam a conceção, a configuração e a operação. A conceção baseia-se nos seus diagramas. A configuração nos seus ficheiros de exportação. A operação nos seus registos e amostras. Reúna todo o material antes do trabalho de campo, e não no decorrer do mesmo.

Item de prova	O que demonstra	PCI DSS 4.0	HIPAA	ISO 27001:2022
Diagramas de rede e de fluxo de dados mostrando limites de funcionários, convidados e CDE	Conceção de segmentação	1.2.3, 1.2.4	§164.308(a)(1)	8.20, 8.22
Regras de firewall ou ACL entre VLANs WiFi de funcionários e o CDE	Rejeição por omissão na prática	1.3.3	§164.312(e)(1)	8.22
Exportação da configuração do SSID mostrando modo Enterprise e EAP-TLS	Autenticação e encriptação 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 da informação de autenticação	4.2.1.2	§164.312(d)	5.17
Amostra de saídas de colaboradores: hora de desativação da conta vs última autenticação na rede	Revogação atempada	8.2.5	§164.308(a)(3)(ii)(C)	5.18
Registos RADIUS com definiçõ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 por falsos pontos de acesso	Controlo 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 provar os controlos de WiFi a um auditor?

Execute primeiro o teste de saídas de colaboradores. É o teste que uma palavra-passe partilhada não consegue passar de forma limpa.

1. Exporte a sua lista de saídas de recursos humanos referente ao período de auditoria.
2. Selecione uma amostra, por exemplo, de 10 a 25 saídas em diferentes instalações.
3. Para cada uma, extraia a hora de desativação da conta do seu fornecedor de identidade.4. Extraia a última autenticação de rede bem-sucedida para essa identidade a partir dos registos RADIUS.
4. Qualquer autenticação após a hora de desativação constitui uma não conformidade. Corrija a causa antes que o auditor a detete.

Numa rede PSK, o passo quatro não devolve qualquer informação útil. Nenhum registo associa uma ligação à pessoa que saiu, pelo que não pode provar que esta deixou de se ligar.

Onde se enquadra o WiFi sem palavra-passe em relação ao que já executa?

Não necessita de novos pontos de acesso. O 802.1X é uma funcionalidade padrão dos pontos de acesso empresariais. A Purple é agnóstica em termos de hardware e funciona como uma sobreposição na nuvem em Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme e Fortinet.

O Purple Staff WiFi utiliza Redes Baseadas em Identidade. O acesso à rede segue o seu fornecedor de identidade: Microsoft Entra ID, Okta ou Google Workspace. Os novos colaboradores obtêm acesso assim que a sua conta é criada. Os colaboradores que mudam de funções alteram o segmento de rede quando a sua função muda. Os colaboradores que saem perdem o acesso quando a conta é desativada. Esse fluxo de admissões, transferências e saídas (JML) é o que produz provas claras para o PCI DSS 8.2.5, HIPAA §164.308(a)(3)(ii)(C) e o controlo 5.18 da ISO 27001.

A sua rede de convidados permanece separada. O PCI DSS 1.3.3 aplica-se tanto a esta como às redes de colaboradores: o tráfego de convidados para o CDE deve ser recusado. Os planos de Guest WiFi da Purple cumprem o GDPR e a CCPA para dados de visitantes, conforme estabelecido em Connect vs Capture.

Para o seu ficheiro de fornecedores, a Purple possui a certificação ISO 27001 e Cyber Essentials, e está em conformidade com o GDPR e a CCPA. Os dados da própria plataforma da Purple mostram um tempo de atividade de 99.999% em mais de 80.000 locais ativos. O seu auditor tratará estes dados como uma garantia do fornecedor, e não como prova dos seus próprios controlos.

Como se caracteriza a conformidade do WiFi sem palavra-passe na prática?

Os três cenários abaixo são exemplos práticos. Cada um define os seus pressupostos, para que possa refazer os cálculos para a sua própria infraestrutura.

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

Situação. Um hotel de 200 quartos mantém 140 colaboradores numa única rede PSK. Os computadores da receção e os tablets do restaurante nessa rede acedem ao sistema de pagamentos, o que a coloca no âmbito do PCI. Assuma uma rotação anual de pessoal de 30%, ou seja, 42 saídas por ano.

O que foi feito. A rede de colaboradores passou para 802.1X com EAP-TLS, associada ao fornecedor de identidade do grupo hoteleiro. Os dispositivos de pagamento foram integrados numa VLAN dedicada com regras de rejeição predefinidas (default-deny) a partir de qualquer outra rede. A rede de convidados foi isolada de ambas.

Resultado. As rotações de chaves do requisito 2.3.2 passam de 42 por ano, afetando cada dispositivo de colaborador, para zero. Cada colaborador que sai é removido ao desativar uma única conta. A amostra de saídas tem agora um registo para comparação. Os operadores em Hotéis com pessoal sazonal observam a maior redução, pois a rotação de pessoal impulsiona a rotação de chaves.

Uma cadeia de retalho de 40 lojas: reduzir o raio de impacto

Situação. Uma cadeia de 40 lojas utiliza uma única PSK em todas as lojas para scanners de inventário portáteis e portáteis de back-office. Os gerentes das lojas conhecem a chave. Um antigo gerente publica-a online.

O que foi feito. Os computadores portáteis geridos passaram para EAP-TLS com certificados emitidos através da gestão de dispositivos. Os leitores de código de barras que não suportavam certificados passaram para iPSK, com uma chave por dispositivo, numa VLAN restrita. O inventário de pontos de acesso de cada loja foi documentado ao abrigo do Requisito 11.2.2.

Resultado. A exposição resultante de uma credencial exposta diminui de 40 lojas para um único dispositivo. Revogar esse dispositivo exige apenas uma ação e mantém os restantes leitores ligados. A cadeia de lojas pode agora apresentar a um avaliador um inventário por dispositivo em vez de um único segredo partilhado. O mesmo padrão adequa-se a qualquer património de Retalho com uma mistura de dispositivos geridos e sem interface de utilizador.

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

Situação. Um departamento de saúde distrital nos EUA gere 12 clínicas. Os médicos utilizam tablets partilhados para aceder ao registo de saúde eletrónico. Cada clínica tem a sua própria palavra-passe de rede, resultando em 12 credenciais partilhadas e nenhuma atribuição nos registos de rede.

O que foi feito. Os tablets receberam certificados de dispositivo. Os médicos iniciam sessão com a sua conta do fornecedor de identidade, associando cada sessão de um dispositivo a uma pessoa. Os registos RADIUS alimentam a gestão de registos do departamento. A retenção foi definida de acordo com o período de documentação de seis anos definido na secção §164.316(b)(2), onde o departamento classifica os registos como documentação.

Resultado. As credenciais de rede partilhadas passaram de 12 para zero. A análise de risco pode registar a especificação de encriptação como implementada em vez de documentar uma alternativa. Os controlos de auditoria ao abrigo da secção §164.312(b) mostram agora qual a pessoa que, em que dispositivo, se ligou a que rede de clínica e quando. As equipas de Saúde do setor público que respondem tanto à HIPAA como à auditoria estatal podem reutilizar o mesmo pacote de provas. Os dispositivos das tripulações nos Comboios seguem o mesmo modelo, com uma identidade por tablet em todas as carruagens e estações.

Quais são os limites que deve conhecer?

• Não se trata de um certificado de conformidade. O WiFi sem palavra-passe satisfaz controlos específicos. O âmbito, a análise de risco e o resto de cada estrutura continuam a ser da sua responsabilidade.
• Os pontos de acesso não autorizados continuam a necessitar de testes. O PCI DSS 11.2.1 exige testes trimestrais para pontos de acesso autorizados e não autorizados. O acesso baseado em certificados não deteta um dispositivo não autorizado ligado a um comutador de loja.
• Os certificados expiram. Necessita de uma autoridade de certificação, de um método de inscrição e de um processo de renovação. Uma renovação falhada desliga todos os dispositivos cujo certificado partilhe essa data de expiração.
• Nem todos os dispositivos conseguem alojar um certificado. Impressoras, leitores de código de barras e alguns equipamentos clínicos não o conseguem fazer. Utilize iPSK ou uma rede segmentada, e documente a exceção.
• O PEAP não é um atalho. O PEAP com palavras-passe mantém o risco associado às palavras-passe. Se os dispositivos não validarem o certificado do servidor, um ponto de acesso falso pode capturar credenciais.
• Os registos só ajudam se forem mantidos e revistos. Defina a retenção para 12 meses para o PCI DSS. Comprove uma cadência de revisão para o controlo 8.16 da ISO 27001.

O que deve fazer a seguir?

1. Classifique cada nome de rede. Identifique quais tocam o CDE, ePHI ou nenhum. Isso decide qual framework se aplica a cada uma.
2. Execute o teste de saída de colaboradores agora. Se não o conseguir concluir, encontrou o seu primeiro risco de auditoria.
3. Escolha uma credencial por classe de dispositivo. EAP-TLS para portáteis, telemóveis e tablets geridos. iPSK para dispositivos sem interface gráfica (headless).
4. Atualize a sua documentação de controlo. Mapeie a alteração na sua Declaração de Aplicabilidade, análise de risco HIPAA ou documento de âmbito PCI DSS.
5. Faça um piloto num site. Comprove a inscrição de certificados, atribuição de VLAN e revogação de acessos de ex-colaboradores antes de implementar em toda a infraestrutura.
6. Construa o pacote de evidências. Utilize a tabela de evidências acima como a sua lista de verificação, três meses antes do trabalho de campo.

Perguntas frequentes

O WiFi sem palavra-passe está em conformidade com o PCI?

O WiFi sem palavra-passe não está em conformidade com o PCI por si só, porque o PCI DSS avalia o seu ambiente e não um produto. No entanto, cumpre os Requisitos 2.3.2, 4.2.1.2, 8.2.2 e 8.2.5 de forma mais limpa do que uma palavra-passe partilhada, e os seus registos RADIUS suportam o Requisito 10. Continua a necessitar de controlos de negação por predefinição entre as redes sem fios e o ambiente de dados de titulares de cartões sob o 1.3.3, além de testes trimestrais de pontos de acesso não autorizados sob o 11.2.1.

O HIPAA exige WiFi baseado em certificados?

Não, o HIPAA não nomeia nenhuma tecnologia sem fios. A Security Rule exige identificação única, controlos de auditoria e autenticação de pessoas ou entidades, e trata a encriptação como endereçável. O WiFi baseado em certificados cumpre todos estes requisitos por conceção, o que torna a sua análise de risco mais fácil de defender. Uma proposta de regulamento do HHS de janeiro de 2025 tornaria a encriptação e a autenticação multifator obrigatórias com exceções limitadas. Trata-se de uma proposta, não de uma regra final.

O que diz a ISO 27001 sobre redes sem fios?

A ISO/IEC 27001:2022 não possui um controlo específico para redes sem fios. Os auditores testam a rede sem fios face aos controlos do Anexo A 5.15 a 5.18 para acesso e identidade, 8.5 para autenticação segura, 8.15 para registo de dados (logging) e 8.20 a 8.22 para segurança e segregação de rede. A orientação da ISO/IEC 27002:2022 sob o 8.22 sugere tratar o acesso sem fios em ambientes sensíveis como uma ligação externa até que este passe por um gateway.

Como posso provar os controlos de WiFi a um auditor?

Pode provar os controlos de WiFi com configurações, registos (logs) e um teste de saída de colaboradores. Apresente diagramas de rede que mostrem os limites da rede sem fios e do CDE, exportações de SSID que mostrem a autenticação Enterprise, a sua política de certificados, 12 meses de registos RADIUS e resultados de varrimentos trimestrais de dispositivos não autorizados. Em seguida, execute uma amostra de saídas de colaboradores, comparando a hora de desativação da conta de cada ex-colaborador com a sua última autenticação de rede bem-sucedida. Qualquer autenticação após a desativação constitui uma não conformidade.

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

Sim, a Purple é agnóstica em termos de hardware e funciona como uma sobreposição na nuvem em Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme e Fortinet. Mantém os seus pontos de acesso e switching. A Purple liga o acesso à rede ao Microsoft Entra ID, Okta ou Google Workspace, pelo que abandonar uma palavra-passe partilhada não exige um projeto de substituição integral de hardware.

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

Utilize iPSK ou uma rede segmentada separada para os mesmos. O iPSK atribui a cada dispositivo a sua própria chave no mesmo SSID, pelo que a revogação de um dispositivo mantém os restantes ligados. Coloque os equipamentos sem ecrã, tais como impressoras e scanners, numa VLAN restrita. Documente a justificação comercial na sua análise de risco ou Declaração de Aplicabilidade e reveja cada exceção em cada ciclo de auditoria.

A certificação ISO 27001 da Purple torna-nos conformes?

Não, a certificação de um fornecedor não se transfere para si. As credenciais ISO 27001, Cyber Essentials, GDPR e CCPA da Purple servem de prova para a sua avaliação de fornecedores ao abrigo dos controlos 5.19 e 5.23 da ISO 27001 e do Requisito 12.8 do PCI-DSS. O seu próprio âmbito, análise de risco, configuração e registos ainda precisam de cumprir cada estrutura de trabalho, e o seu auditor irá testá-los diretamente.