Segurança

O appliance roda em um hardware e em uma rede que você opera. A IronFlock fornece o software e seus padrões; o quão bem o appliance está protegido também depende do modo que você escolhe, da rede ao redor dele e do host em que ele roda. Esta página é o checklist para essa parte.

O que cada modo protege

O appliance opera em um de três modos, descritos em HTTPS e certificados. Eles diferem no que é criptografado e verificado:

Use HTTPS com o seu certificado corporativo sempre que o appliance compartilhar uma rede com outros sistemas. É o único modo em que os dispositivos conectados verificam com quem estão falando. Os outros dois modos são adequados a um segmento de rede que apenas o appliance, seus dispositivos e seus operadores conseguem alcançar.

O que permanece sem criptografia

Mesmo com HTTPS, parte do tráfego não é criptografada. Planeje a sua rede levando isso em conta:

• A conexão do dispositivo na porta 18080 é publicada em todas as interfaces de rede, em todos os modos. O próprio agente de dispositivo do appliance e os apps que rodam no appliance se conectam a ela e, no modo simples e com uma CA autoassinada, também todos os dispositivos conectados.
• Os túneis de acesso remoto para o appliance (porta 7000) são criptografados no modo simples e com uma CA autoassinada, mas os dispositivos não conseguem verificar o certificado do appliance. Alguém com acesso ao caminho de rede poderia se passar pelo servidor de túneis do appliance. Os agentes de dispositivo registram um aviso quando se conectam dessa forma.
• As conexões entre os serviços dentro do appliance, como as conexões com os seus bancos de dados, não são criptografadas. Elas não saem do host.
• Os dados em repouso não são criptografados pelo appliance. Use a criptografia do sistema operacional ou do disco do host se o appliance armazenar dados sensíveis ou puder sair das suas instalações.

Checklist de hardening

• Escolha o modo adequado à sua rede (veja O que cada modo protege).
• Restrinja quem pode alcançar as portas do appliance. O instalador não abre nada no seu firewall, e o Docker publica as portas do appliance contornando as regras de entrada habituais do firewall do host (ufw, firewalld). Filtre na chain DOCKER-USER ou no firewall da sua rede: o instalador deixa um modelo em /opt/ironflock/docker-user-firewall.sh.example. Libere as portas dos dispositivos (18080, 15001, 15002, 7000, 30000–30049) somente a partir das redes dos seus dispositivos — veja Dispositivos conectando-se ao appliance.
• Mantenha o sistema operacional do host atualizado e limite quem tem uma conta nele. Qualquer pessoa com acesso root ao host pode ler todos os segredos do appliance.
• Use chaves SSH em vez de senhas para o acesso administrativo ao host.
• Configure a sincronização de horário — veja Sincronização de horário (NTP).
• Altere a senha de administrador após o primeiro login e configure um segundo fator para a conta de administrador.
• Exija um segundo fator de todos assim que todas as contas tiverem um (veja Contas e acesso).
• Proteja com um segundo fator a conta do ironflock.com que é dona da instância: ela tem acesso de administrador ao appliance a partir da nuvem.
• Instale apenas apps em que você confia. Os apps rodam no appliance e nos seus dispositivos com amplo acesso ao host, incluindo os arquivos de configuração do appliance.
• Mantenha o appliance atualizado (veja Atualizações).

Contas e acesso

• Conta de administrador: cada appliance recebe a sua própria senha de administrador na instalação; o instalador a exibe uma única vez. Se ela for perdida, defina uma nova conforme descrito em Operação local — isso também encerra todas as sessões de administrador.
• Novos usuários só podem se cadastrar com um convite de um projeto no appliance. Sem convite, o cadastro é recusado, também via login social.
• Segundo fator: os usuários podem configurar um app autenticador (TOTP), passkeys ou chaves de segurança, e códigos de recuperação. Passkeys e chaves de segurança exigem HTTPS. A opção do instalador --2fa define a política, e ela se mantém entre atualizações:
  • available — os usuários podem configurar um segundo fator, mas ele nunca é solicitado.
  • effective (padrão) — os usuários que têm um segundo fator precisam usá-lo.
  • required — todos os usuários precisam usar um segundo fator. Antes, certifique-se de que todas as contas tenham um: um usuário sem segundo fator não consegue mais fazer login.
• As sessões duram 24 horas.
• Acesso a partir do ironflock.com: a conta do ironflock.com que criou a Instance Key está vinculada à conta de administrador do appliance. Os usuários que você convida vinculam as suas próprias contas do ironflock.com — veja Vinculando contas. Um usuário pode remover esse vínculo a qualquer momento.

Segredos no host

O instalador gera os segredos do appliance uma única vez, na instalação, e os mantém entre atualizações. Eles ficam em /opt/ironflock/:

O instalador também faz o login do Docker no registro da IronFlock com a sua chave de licença, então a configuração do Docker do root também a contém.

Inclua esses arquivos nos seus backups e proteja os backups como o próprio appliance.

O que você mesmo pode substituir:

• Senha de administrador: no perfil, ou com o comando de redefinição em Operação local.
• Certificado HTTPS: substitua os arquivos em certs/; o appliance carrega o novo certificado automaticamente.
• Chave de licença: na seção de licença do perfil de administrador.
• Credenciais de SMTP e de proxy: em .env e, em seguida, reinicie com sudo systemctl restart ironflock.service.

Para os segredos internos dos serviços, entre em contato com a equipe da IronFlock.

Conexões de saída e telemetria

Os destinos aos quais o appliance se conecta estão listados em Configuração de firewall; todas essas conexões são criptografadas.

• A validação da licença envia a chave de licença, uma impressão digital do hardware e os tokens de acesso das conexões do appliance com a App Store online.
• O assistente de IA envia os prompts pelo gateway de LLM da IronFlock, a menos que você configure um gateway próprio.
• Sem telemetria. O appliance não envia análises de uso: nem a UI do appliance nem os seus serviços relatam o uso à IronFlock ou a terceiros.
• A partir do navegador do usuário: os blocos de mapa são carregados do Mapbox, e a entrada por voz usa o serviço de reconhecimento de fala Deepgram. Essas conexões são feitas pelo navegador, não pelo appliance.

Atualizações

• As atualizações do appliance são iniciadas pelo administrador (veja Manutenção). O appliance as baixa via HTTPS e reverte automaticamente se uma atualização falhar.
• As atualizações do agente de dispositivo são assinadas. Cada agente verifica a assinatura antes de aplicar uma atualização e reverte se a nova versão não iniciar — veja Atualizações do agente de dispositivo.
• O sistema operacional do host é sua responsabilidade, incluindo o Docker.

Backup e restauração

O appliance não tem backup integrado. Para fazer o backup, pare-o com sudo systemctl stop ironflock.service e copie:

• a pasta /opt/ironflock/, incluindo .env, license.env, certs/ e registry-token-certs/;
• os volumes Docker do appliance (docker volume ls), que contêm os bancos de dados, os arquivos, a App Store local e os arquivos dos usuários.

Mantenha o .env junto com os volumes do mesmo momento: os dados criptografados nos volumes só podem ser lidos com as chaves desse .env.

Desativação

1. Transfira ou libere a licença enquanto o appliance ainda estiver online — veja Mover sua licença para um novo hardware.

2. Remova o software:

   sudo systemctl disable --now ironflock.service
   sudo docker compose -f /opt/ironflock/docker-compose.yml \
       --env-file /opt/ironflock/.env down -v
   sudo rm -rf /opt/ironflock

   O instalador fez o login do Docker no registro da IronFlock com a chave de licença; remova também esse login:

   sudo docker logout instance-registry.ironflock.com

3. Se o hardware sair das suas instalações, apague o disco — os comandos acima excluem os arquivos, mas não os sobrescrevem.

Configurações que enfraquecem a segurança

Algumas configurações existem apenas para solução de problemas. Não as defina em produção:

• TUNNEL_TLS_INSECURE_SKIP_VERIFY e CLOUD_TUNNEL_TLS_INSECURE_SKIP_VERIFY — desativam a verificação de certificado dos túneis de acesso remoto.
• AGENT_UPDATE_ALLOW_UNSIGNED — permite que um agente de dispositivo aplique atualizações não assinadas.
• TUNNEL_AUTHZ_ENFORCE=false — permite que os dispositivos abram túneis sem comprovar a sua identidade.
• ?tls.rejectUnauthorized=false em SMTP_CONNECTION_URI — aceita qualquer certificado do seu servidor de e-mail.
• --2fa available — segundos fatores nunca são solicitados.