PacketFence é uma plataforma NAC para controlar a entrada de usuários e dispositivos em redes cabeadas e Wi-Fi. Reúne autenticação, políticas de acesso, visitantes e integração com a infraestrutura. A Add Solution apoia avaliação, arquitetura, piloto e implantação segura.
A Add Solution parte do ambiente real: identidades, endpoints, modelos e firmwares, VLANs, RADIUS, portal Guest, contingência e operação.
Associar o acesso à identidade do equipamento ou do usuário. Em um parque gerenciado, a avaliação deve considerar autenticação por certificado, distribuição centralizada do perfil de rede e retirada de acesso no desligamento ou na perda do dispositivo.
Oferecer um caminho de entrada com prazo, responsável e permissões definidos. Para um prestador que precisa de um sistema interno, a pergunta é quais destinos serão liberados, por quanto tempo e quem aprova essa exceção.
Organizar o uso de dispositivos pessoais sem misturar esse acesso com o dos equipamentos corporativos. O desenho precisa considerar sistemas operacionais, privacidade, suporte ao usuário e o que acontece quando o dispositivo deixa de ser utilizado.
Reduzir liberações permanentes e indiscriminadas. Equipamentos sem autenticação forte precisam de cadastro, responsável, acesso restrito aos serviços necessários e critérios para revisão. Em ambientes sensíveis, o risco de interrupção exige avaliação conjunta com a operação.
Definir uma política comum, preservando as diferenças de aplicação em cada equipamento. A implantação pode começar por uma rede, SSID ou grupo de portas, com expansão condicionada aos resultados do piloto.
O projeto deve converter regras de segurança em acessos administráveis: permissões coerentes, entrada e saída organizadas, diagnóstico objetivo, implantação gradual e continuidade documentada. Inventário, riscos e capacidade operacional definem o escopo e os critérios de aceite.
No 802.1X, o endpoint apresenta sua identidade, o equipamento de rede transporta a autenticação via RADIUS e aplica a autorização recebida. O resultado deve ser confirmado no equipamento, no endereçamento e no tráfego permitido.
O endpoint apresenta a identidade prevista para usuário, dispositivo ou certificado.
No fluxo 802.1X, o autenticador transporta a conversa EAP por RADIUS e recebe a decisão de autenticação e autorização.
Contexto, grupo, dispositivo e local determinam o resultado esperado para aquela conexão.
O NAS aplica VLAN, papel, ACL ou outro mecanismo nativo documentado e suportado.
Estado no equipamento, endereçamento e tráfego permitido confirmam o acesso efetivo.
É uma opção prioritária a avaliar para dispositivos gerenciados. A autenticação utiliza certificados, reduzindo a dependência de senhas digitadas no acesso à rede. Exige uma PKI bem operada e perfis distribuídos corretamente. A negociação de TLS também precisa ser compatível entre os clientes e o servidor. EAP-TLS com TLS 1.3.
Podem atender a requisitos de compatibilidade, mas precisam ser escolhidos considerando o diretório e os sistemas operacionais utilizados. Em Windows, o Credential Guard pode afetar o uso das credenciais da sessão em métodos baseados em MS-CHAPv2. A revisão deve buscar um método adequado ao parque, preservando as proteções do endpoint. EAP no Windows.
Pode viabilizar o acesso de equipamentos sem supplicant. O endereço MAC funciona como identificador e pode ser imitado; não oferece a mesma garantia de identidade de um certificado. Por isso, recomendamos exceções delimitadas, inventário e segmentação restritiva. O comportamento de prioridade e fallback entre 802.1X e MAC deve ser validado no modelo utilizado. Limitações e desenho de MAB.
O PacketFence oferece opções como autorregistro, aprovação por patrocinador e confirmação por e-mail ou SMS. A escolha depende da experiência desejada e dos serviços disponíveis. Guest e BYOD. A entrada pelo portal deve ser avaliada junto com o isolamento da rede, a duração do acesso e a autenticação usada no enlace Wi-Fi. O formulário, sozinho, não define esses controles.
EAP-TLS exige gestão do ciclo de vida dos certificados: emissão, distribuição, validade, renovação e revogação. A homologação deve confirmar identidade, cadeia de confiança, finalidade do certificado e comportamento diante de expiração ou indisponibilidade da PKI.
No controle out-of-band, o endpoint se comunica com os serviços permitidos por meio do equipamento de rede, ou NAS, e da infraestrutura de produção. Em um ramo separado, o NAS troca mensagens RADIUS de autenticação e autorização com PacketFence. PacketFence utiliza identidade e confiança, como diretório e certificados, conforme o método. O NAS aplica a autorização. O tráfego de produção não atravessa PacketFence. Esquema conceitual sem dados de uma instalação real.
No modelo out-of-band, o PacketFence decide a autorização e o equipamento de rede a aplica. O tráfego de produção permanece na infraestrutura. O desenho deve validar RADIUS, VLANs, ACLs, accounting, mudança de autorização e contingência em cada equipamento.
No modo inline, PacketFence fica no caminho do tráfego da rede controlada. Pode atender a equipamentos sem mecanismos adequados de enforcement, mas traz requisitos adicionais de capacidade e continuidade. Arquitetura inline. A avaliação precisa incluir throughput real, picos de tráfego, interfaces, latência e impacto de manutenção. A escolha deve ser consciente, especialmente quando o mesmo ambiente depende desse caminho para acessar sistemas essenciais.
É possível trabalhar com RADIUS only, sem os fluxos de registro, isolamento e portal desse modo de implantação, ou combinar mecanismos conforme o segmento atendido. Modos suportados. Em projetos distribuídos, convém decidir onde ficam autenticação, portal e dependências de identidade. A conectividade entre unidades, o comportamento durante falhas e o acesso de contingência precisam ser definidos antes da expansão.
Usuário, dispositivo, certificado ou combinação conforme a política.
Autenticação e autorização transportadas até o equipamento de rede.
Switch, ponto de acesso ou controlador aplica VLAN, papel ou ACL suportados.
DHCP, DNS, roteamento e segmentação completam o acesso efetivo.
Accounting, estado da sessão e teste do tráfego demonstram o resultado.
Compatibilidade precisa ser validada por modelo, firmware e mecanismo. O levantamento registra autenticação, atributos de autorização, VLAN ou ACL, accounting, CoA e o comportamento em reautenticação e falha.
A compatibilidade com Huawei varia por modelo, firmware e mecanismo. O levantamento confirma 802.1X, MAB, RADIUS, VLAN ou ACL dinâmica, accounting e CoA necessários ao caso. A homologação deve usar o equipamento e a versão reais do ambiente.
Em ambientes multivendor, a política pode ser comum, mas a aplicação muda por fabricante. O projeto documenta atributos, limites e comportamento de cada integração, preservando recursos nativos e uma operação sustentável.
A jornada de visitantes precisa definir cadastro, responsável, aprovação, prazo e recursos permitidos. O portal deve funcionar nos dispositivos previstos, preservar acessibilidade e direcionar o usuário mesmo antes de existir acesso pleno à internet.
A autorização deve ser comprovada no equipamento e no tráfego. Accounting identifica a sessão; CoA, Disconnect ou mecanismo equivalente precisa alterar ou encerrar o acesso correto. O piloto valida expiração, renovação, roaming e falhas de comunicação.
O visitante entra pela rede e experiência de portal previstas para o dispositivo real.
Autorregistro, recepção ou patrocinador seguem dados mínimos, prazo e responsabilidade definidos.
A política concede somente internet ou os recursos específicos aprovados.
Accounting e identificadores disponíveis correlacionam usuário, equipamento e NAS.
CoA, Disconnect ou o mecanismo nativo acordado altera ou encerra a sessão correta.
PacketFence pode combinar perfil de dispositivo e sinais de ferramentas de segurança. Cada sinal deve ter origem, validade e confiança conhecidas; ações automáticas precisam de escopo, remediação e reversão para evitar bloqueios indevidos.
Alta disponibilidade precisa ser validada por serviço. O projeto mede novas autenticações, portal, sessões existentes, banco e dependências em condições de falha. Capacidade e retenção são dimensionadas com dados observados, margem e testes representativos.
Atualizações devem seguir versões suportadas, notas oficiais, backup, teste e retorno planejado. Integrações devem usar mecanismos documentados para evitar dependência de alterações locais que dificultem suporte e evolução.
A arquitetura documentada parte de pelo menos três nós e quantidade ímpar de servidores.
Galera, HAProxy e Keepalived distribuem funções conforme o desenho e a conectividade entre locais.
Na perda de quorum do cluster, o banco entra em modo somente leitura; portal e autenticações RADIUS podem ter impactos diferentes conforme os dados e as fontes ainda acessíveis.
Portal, novas autenticações e sessões existentes são verificados separadamente.
Backup, restauração, atualização e regressão entre fabricantes têm procedimentos e evidências próprios.
O custo total inclui infraestrutura, implantação, operação, suporte, atualização e crescimento. A edição self-hosted é distribuída sob GPL v2 ou posterior; suporte do fabricante e serviços da Add Solution possuem escopos próprios, que devem ficar explícitos na proposta.
A comparação deve partir dos requisitos do ambiente. PacketFence favorece controle da infraestrutura e flexibilidade aberta; Cisco ISE, ClearPass e FortiNAC podem ser adequados quando suas integrações de ecossistema são decisivas; NPS atende cenários RADIUS mais restritos. Licenças, compatibilidade, operação e migração precisam ser comparadas no mesmo escopo.
O escopo deve registrar compatibilidade por modelo e firmware, integrações nativas, critérios de aceite, responsabilidades e metas de continuidade. Limitações encontradas no piloto precisam ser tratadas antes da expansão.
O escopo pode incluir as seguintes frentes, conforme a necessidade do ambiente:
Inventário dos pontos de controle, fontes de identidade, tipos de endpoint e dependências. Definição das políticas, exceções, método de implantação e critérios de continuidade.
Validação em um conjunto representativo de equipamentos e clientes. Testes de entrada, recusa, segmentação, expiração, revogação e falha. Registro dos resultados e das limitações antes da expansão.
Sequenciamento por unidade, SSID ou grupo de portas, com comunicação ao suporte e procedimento de retorno. Cada etapa deve ter critérios de avanço e responsáveis definidos.
A entrega registra políticas, integrações, certificados, testes, exceções e procedimentos de suporte e recuperação. Responsabilidades e modelo de atendimento são definidos na proposta.
A resposta depende dos modelos, firmwares e controles pretendidos. O levantamento deve separar os equipamentos que atendem ao desenho, os que exigem restrições e os que precisam ser substituídos. A compatibilidade deve ser conferida por função na matriz oficial.
Sim, esse pode ser o escopo inicial do projeto. Mesmo nessa etapa, é importante validar isolamento, portal, duração, rastreabilidade e encerramento do acesso. A expansão para 802.1X corporativo é uma decisão posterior de arquitetura.
Deve ser tratado como identificação com limitações. O desenho recomendado associa cadastro controlado, permissões mínimas e acompanhamento de exceções. Equipamentos capazes de autenticação mais forte devem ser avaliados para utilizá-la.
Não. O projeto coordena esses controles. A política de entrada e segmentação precisa conviver com inspeção de tráfego, proteção dos endpoints e resposta a incidentes. Cada camada deve ter função, responsável e evidência próprios.
A aceitação deve incluir testes entre convidados, redes internas e serviços de infraestrutura. O resultado depende das regras e dos caminhos de comunicação efetivamente configurados, inclusive IPv6 quando presente.
O projeto deve separar validação do certificado e permissão de acesso. Identidade, vínculo com o dispositivo ou usuário, validade da autorização e eventuais restrições precisam compor a decisão.
Os mecanismos de autenticação de rede podem usar o supplicant do sistema ou identificação por MAC. Verificações de postura e provisionamento têm dependências próprias, que devem ser confirmadas para cada integração e sistema operacional.
Isso precisa ser demonstrado para a arquitetura escolhida. Sessões existentes, novas autenticações e portal podem ter comportamentos diferentes. O piloto deve incluir falha de nó e de dependências, com política de contingência explícita.
Sim, o portal dispõe de mecanismos de personalização documentados. O projeto deve preservar acessibilidade, clareza dos estados, compatibilidade móvel e o caminho de atualização da plataforma.
O projeto pode contribuir com controles de acesso e registros. A definição de finalidade, dados coletados, retenção e responsabilidades deve ser validada pela organização com sua área de privacidade. Um portal ou ferramenta isolada não comprova conformidade. Orientações da ANPD sobre segurança da informação.
Depende da compatibilidade do parque, maturidade da identidade e da PKI, quantidade de fluxos, necessidade de redundância e escopo de operação. A avaliação inicial deve transformar essas variáveis em etapas, critérios de aceite e proposta.
Compartilhe classes de dispositivos, redes, equipamentos, métodos de autenticação, necessidades de visitantes e requisitos de continuidade. Não envie credenciais, segredos RADIUS ou dados operacionais sensíveis.
