Segurança e Privacidade

Este capítulo fornece uma visão geral sobre perguntas frequentes relacionadas à segurança da informação, privacidade e garantia de qualidade.

Processamento de Dados e Permissões

1. De qual centro de dados o RADIUSaaS está a operar?

O serviço central do RADIUSaaS pode atualmente ser implantado nas seguintes regiões:

• Austrália

• Europa

• Reino Unido

• Estados Unidos da América

Caso sejam necessários proxies RADIUS, eles podem ser implantados nos seguintes países/regiões:

2. Quais dados são processados pelo RADIUSaaS?

Certificados

O RADIUSaaS processa certificados X.509 de utilizador ou dispositivo para validar a autenticidade do pedido de autenticação. Como parte do certificado, cada atributo pode ser processado, potencialmente contendo informações tais como:

• Nome de utilizador

• Email

• UPN

Protocolo RADIUS

O RADIUSaaS baseia-se no protocolo RADIUS, por exemplo, os seguintes dados são visíveis para o RADIUSaaS:

• Endereço MAC do cliente

• Endereço MAC do NAS (por ex. ponto de acesso, switch, ...)

• SSID do WiFi

• Dados específicos do fornecedor (por ex. VLAN, grupo de tunelamento, ...)

• Endereço IP do NAS

• Endereço IP público atribuído pelo ISP

• Segredo partilhado RADIUS (relevante apenas se o RadSec não for suportado nativamente)

• Chave privada do certificado do servidor RADIUS

Diversos

O RADIUSaaS fornece (opcionalmente) funcionalidade para gerar pares nome de utilizador + palavra-passe para acesso à rede. Essas credenciais são armazenadas e processadas pelo serviço também.

3. Quais dados são armazenados de forma persistente pelo/em nome do RADIUSaaS e como?

1. Permissões

   A plataforma RADIUSaaS armazena informações UPN/email dos utilizadores que têm permissão para aceder à plataforma. Nenhuma palavra-passe é armazenada ou processada pelo RADIUSaaS.

2. Registos

   Para fins de resolução de problemas e análise, a plataforma RADIUSaaS regista todos os dados relevantes que processa (ver Pergunta 2 exceto o Segredo Partilhado RADIUS e a chave privada do certificado do servidor).

   Os registos são armazenados diretamente na plataforma RADIUSaaS dentro de um Elasticsearch base de dados e segregados para cada cliente através de um espaço dedicado. Tempo de retenção dos registos: 75 dias.

3. Certificados

   O RADIUSaaS requer vários certificados de servidor bem como certificados raiz para facilitar o funcionamento adequado. Todos esses certificados são seguramente armazenados num Azure KeyVault.

4. As credenciais opcionais de nome de utilizador + palavra-passe mencionadas em Pergunta 2 são armazenados num Azure KeyVault.

5. Outros segredos e dados de configuração

   Outros dados confidenciais, por ex. o Segredo Partilhado RADIUS bem como a configuração do serviço são seguramente armazenados num Azure KeyVault.

4. Existe um mecanismo de arquivamento para registos?

Não existe um mecanismo de arquivamento de registos incorporado. No entanto, o Exportador de Registos recurso pode ser usado para ingerir registos RADIUS nos seus próprios serviços de registo e arquivamento.

5. Que permissões de tenant é que os utilizadores que acedem ao portal web do RADIUSaaS têm de consentir?

1. Perfil Básico de Utilizador:

   Com esta permissão o RADIUSaaS obtém o UPN do utilizador que tenta iniciar sessão no Portal de Administração do RADIUSaaS.

2. Manter acesso aos dados a que lhe deu acesso

   Com esta permissão o RADIUSaaS recebe o direito de solicitar um token de atualização para que o utilizador possa permanecer autenticado.

Por favor veja aqui para detalhes.

6. Que dados ficam disponíveis ao conceder o(s) consentimento(s) do ponto 5.?

1. Perfil Básico de Utilizador:

   Para detalhes sobre que dados podem ser obtidos, por favor consulte este artigo: https://docs.microsoft.com/en-us/azure/active-directory/develop/v2-permissions-and-consent#profile

2. Manter acesso aos dados a que lhe deu acesso

   Nenhum dado específico fica disponível ao conceder consentimento para esta permissão.

7. Que endpoints acessíveis externamente o RADIUSaaS expõe?

1. API Backend do Servidor RADIUS

   • Fornece informação de configuração ao proxy RadSec.

2. Portas do Servidor RADIUS e RadSec

   • Para facilitar a autenticação de rede a partir de qualquer lugar na Internet, estas interfaces de autenticação têm de ser expostas publicamente.

3. Portal Admin do RADIUSaaS

   • Um portal web que facilita a administração do serviço.

4. API de Gestão do Cluster Kubernetes

   • Necessária para operar o serviço.

8. Como são protegidos os endpoints da Pergunta 7?

1. API Backend do Servidor RADIUS

   • Protegidos via tokens de acesso JWT que podem ser geridos (emitidos, eliminados, revogados) pelo cliente.

2. Portas do Proxy RADIUS e do Servidor RadSec

   • Portas do servidor RadSec: protegidas por TLS (>= versão 1.2).

   • Portas do servidor proxy RADIUS: protegidas via Segredo Partilhado RADIUS.

3. Portal Admin do RADIUSaaS

   • Protegido via autenticação OAuth 2.0 contra um dos nossos IDPs suportados.

4. API de Gestão do Cluster Kubernetes

   • Protegido por TLS (>= versão 1.2).

9. Que portas e protocolos são usados pelos endpoints da Pergunta 7?

• API Backend do Servidor RADIUS

  • HTTPS (TCP / 443)

• Portas do Proxy RADIUS e do Servidor RadSec

  • Portas do servidor RadSec: RadSec (TCP / 2083)

  • Portas do servidor proxy RADIUS: RADIUS (UDP / 1812, 1813)

• Portal Admin do RADIUSaaS

  • HTTPS (TCP / 443)

• API de Gestão do Cluster Kubernetes

  • HTTPS (TCP / 443)

Identidade

1. Que esquemas de autorização são usados para obter acesso ao RADIUSaaS?

• O acesso administrativo é realizado através de autenticação OAuth 2.0 contra um IDP para identidades ou contas que estão registadas na plataforma.

2. Existem controlos de acesso condicionais / baseados em funções para proteger o RADIUSaaS?

• Sim. O portal de administração do RADIUSaaS fornece funcionalidades para atribuir funções a cada utilizador (funções disponíveis: administrador, visualizador, convidado).

• Para operar e manter corretamente o serviço, existem contas super-admin para um círculo limitado de empregados da glueckkanja AG, que têm acesso total a todas as instâncias cliente do serviço RADIUSaaS.

3. As credenciais de acesso podem ser recuperadas? Se sim, como?

• Credenciais de início de sessão: Depende das políticas Microsoft Entra ID (Azure AD) configuradas no tenant do cliente.

• Credenciais de nome de utilizador + palavra-passe bem como todos os certificados para acesso à rede podem ser recuperados a partir do Azure KeyVault com uma política de retenção de 90 dias após terem sido eliminados.

4. O que fazer para recuperar o acesso perdido à instância RADIUSaaS?

• Se a sua empresa perdeu acesso à instância RADIUSaaS porque o(s) administrador(es) anterior(es) saiu/ram ou o UPN / domínio foi alterado, a forma mais simples de recuperar o acesso é recriar uma conta de utilizador que corresponda ao UPN existente em RADIUSaaS > Permissões > Administradores. Esta é de longe a abordagem mais rápida, uma vez que não requer quaisquer ações da nossa parte.

• Se o acima não for viável, a recuperação de acesso ao portal estará sujeita a um rigoroso processo de verificação de identidade que não só é demorado como exigirá um esforço significativo de ambas as partes. Há uma taxa única de 420,00 EUR (excl. IVA) para este processo. Para iniciar o processo, por favor crie um ticket de suporte técnico.

• Para evitar a perda de acesso ao seu tenant RADIUSaaS, por favor siga as nossas melhores práticas trabalhando cuidadosamente cada passo do nosso Guias de Introdução.

Proteção de Dados

1. Como é que os dados em repouso são protegidos contra acesso não autorizado?

Dados de Configuração e Segredos

• Os dados de configuração são armazenados no Azure KeyVault e protegidos através de credenciais de acesso que por sua vez são armazenadas como Segredos do Kubernetes.

Serviço Kubernetes

• Os volumes e discos usados para hospedar o nosso serviço são encriptados.

Registos

• A Base de Dados Elasticsearch está alojada nos discos do Serviço Kubernetes encriptados.

• Os registos são armazenados numa Base de Dados Elasticsearch e segregados via espaços dedicados.

• O acesso a esses espaços é concedido através de credenciais de nome de utilizador + palavra-passe que por sua vez são armazenadas como Segredos do Kubernetes.

• A própria Base de Dados Elasticsearch não está encriptada.

2. Como é que os dados em trânsito são protegidos contra acesso não autorizado?

• Os fluxos de autenticação do dispositivo que tenta aceder à rede são encapsulados num túnel TLS (>= TLS 1.2).

• A associação entre o NAS e o servidor RADIUS é ofuscada através do Segredo Partilhado RADIUS (algoritmo de hash MD5).

3. Como são separados os tenants dos clientes entre si?

Backend

Os serviços backend do RADIUSaaS correm em múltiplos clusters Kubernetes distribuídos mundialmente. Cada instância RADIUSaaS de um cliente tem o seu próprio namespace K8s, espaço de registos e IP público dedicado. Existe uma instância Elasticsearch com contas de cliente dedicadas para registo e leitura por cluster.

Proxies RADIUS

Cada proxy RADIUSaaS corre na sua própria VM com IP público dedicado.

Segurança por Design

1. O RADIUSaaS emprega uma estratégia de defesa em profundidade?

O RADIUSaaS baseia-se em protocolos bem estabelecidos para gerir fluxos de autenticação de rede (RADIUS, RadSec, EAP-TLS, EAP-TTLS-X). Devido ao forte enfoque na autenticação baseada em certificados, captar o tráfego é inútil desde que o espião não tenha acesso a um certificado confiável.

2. O protocolo RADIUS baseado em UDP é seguro?

Recomendamos usar o moderno RadSec protocolo para autenticação contra o RADIUSaaS. No entanto, existem muitos componentes da infraestrutura de rede ainda em uso que não suportam RadSec.

O diagrama seguinte mostra o fluxo de autenticação RADIUS:

Na primeira parte da sequência de autenticação, a comunicação é protegida por um algoritmo de hashing baseado em MD5 (parcialmente encriptado com o segredo partilhado). Nenhum segredo é transportado nesta fase.

Na segunda parte da sequência de autenticação, um EAP baseado em TLS (por ex. EAP-TLS) encripta o tráfego. O tráfego EAP-TLS é então transportado via UDP para o proxy RADIUS. Esta é a fase em que credenciais tais como o certificado ou a palavra-passe são trocadas com o RADIUSaaS. Se utilizar autenticação baseada em certificados, nenhum segredo é transportado nesta fase visto que apenas a chave pública é trocada. A chave privada permanece no dispositivo cliente em todos os momentos.

Uma comparação abrangente entre RADIUS e RadSec em termos de segurança de transporte é fornecida aqui.

Conclusão: A autenticação RADIUS baseada em UDP com o RADIUSaaS é segura, uma vez que

• o tráfego relevante está encriptado e

• adicionalmente não são transportados segredos, se for utilizada autenticação baseada em certificados.

3. Que tecnologias, stacks, plataformas foram usadas para desenhar o RADIUSaaS?

• Kubernetes

• EFK Stack (Elasticsearch, Filebeats, Kibana)

• Python

• Azure (KeyVault)

• TerraForm

• Git CI

RGPD e Residência de Dados

1. Os dados saem da Europa?

• Serviços Centrais: Depende da configuração

  • Os serviços centrais do RADIUSaaS podem ser alojados nos centros de dados descritos na Pergunta 1.

  • Se o serviço estiver alojado num centro de dados europeu, então nenhum dado sai da União Europeia.

• Proxy RadSec: Depende da configuração

  • Se necessitar de um proxy RadSec devido a limitações do equipamento de rede relativamente ao suporte nativo a RadSec, pode selecionar um proxy de várias regiões, incluindo a Europa. Nesse caso, os seus dados permanecem dentro das fronteiras da União Europeia.

2. Em que fornecedores de cloud de terceiros o RADIUSaaS confia e porquê?

Empresa	Serviços	Contacto	Finalidade
Microsoft Corporation	Serviços em Nuvem (Azure)	Building 3, Carmanhall Road Sandyford, Industrial Estate 18, Dublin, Irlanda	Serviço Kubernetes, rede, armazenamento
Digital Ocean, Inc.	Serviços em Nuvem	Y101 6th Ave, New York City, NY 10013, Estados Unidos	Serviço Kubernetes, rede, armazenamento, VMs para proxies RADIUS
Vultr (marca registada da The Constant Company, LLC)	Serviços em Nuvem	319 Clematis Street - Suite 900 West Palm Beach, FL 33401, Estados Unidos	VMs para proxies RADIUS
GitLab, Inc.	repositório de código git, integração, testes e automação de lançamento	268 Bush Street #350, San Francisco, CA 94104-3503, Estados Unidos	Repositório de código, pipeline CI/CD.

Diversos

1. O RADIUSaaS faz parte de um programa de bug-bounty?

Não

2. Que medidas de QA estão implementadas?

• Existem laboratórios RADIUSaaS dedicados para fins de desenvolvimento

• A implantação e instalação do serviço é realizada através do TerraForm, garantindo consistência e idempotência de cada implantação de instância

• Kibana APM é usado para medição da saúde do serviço e gestão de alertas

• Monitorização Digital Ocean a supervisionar os proxies RadSec

• Cada lançamento de produção deve passar primeiro pelo canal interno, ultrapassando os obstáculos de QA relevantes como parte do nosso processo CI

  • Testes unitários

  • Revisão por pares (princípio das seis-olhos)

  • Testes de integração

  • Testes de stress

  • Testes baseados em experiência

3. Realizam regularmente testes de penetração?

Não.

Como parte das nossas Práticas de Desenvolvimento Seguro, empregamos ferramentas (por ex. análise estática de código) que analisam a base de código em busca de CVEs e outras explorações comuns (incluindo dependências como bibliotecas de terceiros) que possam impactar a segurança dos endpoints que o RADIUSaaS expõe. Antes de qualquer lançamento, quaisquer achados relevantes são avaliados e remediados, para garantir que o RADIUSaaS permaneça livre de quaisquer vulnerabilidades conhecidas. Nem realizamos testes de penetração internamente, nem usamos ferramentas de terceiros "Penetration Test-as-a-Service". Para o primeiro, vemos um conflito inerente de interesses. Para o último, dado que os serviços típicos de teste de penetração frequentemente verificam apenas os endpoints expostos contra CVEs e outras explorações conhecidas, não vemos valor acrescentado às verificações que já realizamos usando análise estática de código. Se desejar realizar os seus próprios testes de penetração, por favor entre em contato conosco e conte-nos sobre os seus requisitos.

4. Existe um processo de aplicação de patchs?

Sim.

Patchs, hot-fixes, correções de bugs e atualizações de funcionalidades são introduzidos usando o nosso processo CI/CD que aproveita diferentes pipelines de testes para garantir que apenas código que satisfaça os nossos requisitos de QA seja lançado. O código recém-lançado é automaticamente disponibilizado a todos os nossos clientes. Usar Infrastructure as Code (Terraform) permite-nos entregar atualizações consistentes, reproduzíveis e de alta qualidade aos nossos clientes.

A arquitetura baseada em Kubernetes do nosso serviço garante que as atualizações de código sejam transparentes para os nossos clientes e não provoquem quaisquer interrupções do serviço.

5. Quais são os SLAs para patchs?

• Patchs para CVEs / vulnerabilidades de segurança: Assim que a vulnerabilidade se tornar de conhecimento público ou assim que identifiquemos uma vulnerabilidade no nosso próprio código, será fornecido um hot-fix no máximo 24 horas após termos tomado conhecimento da vulnerabilidade.

• Outros patchs: Sem SLA.

6. O RADIUSaaS realiza backups?

Segredos e dados de configuração

Aproveitamos o Azure KeyVault para armazenar de forma segura segredos (por ex. certificados) e todos os outros dados de configuração do serviço. O Azure KeyVault é um serviço altamente disponível geo-redundante que replica todo o seu conteúdo num segundo centro de dados, proporcionando assim serviços de backup implícitos.

Servidores RADIUS e RadSec

Sem estado. Não é necessário backup.

Registos

Atualmente não é feito backup.

7. Existem testes de restauração de backups?

Sim.

A restauração a partir de backups é testada com cada atualização/lançamento do serviço. Existem aproximadamente 4 - 8 lançamentos por ano.