Onde a ArboRule roda
A ArboRule roda inteiramente na Amazon Web Services, na região us-east-1 . Não operamos hardware próprio, e nenhuma parte do serviço roda em um escritório.
A AWS tem a certificação ISO/IEC 27001 e um relatório SOC 2 Type II para a infraestrutura embaixo de nós. Isso cobre os data centers, os controles de acesso físico e o hardware. Não cobre a nossa aplicação, e não apresentamos como se cobrisse. Veja na última cláusula o que temos em nome próprio.
O motor de decisão roda como uma função AWS Lambda isolada. A aplicação, o banco de dados e o armazenamento de arquivos são sistemas separados, e o motor alcança a aplicação apenas por um token assinado, de vida curta, restrito a um único workspace.
Criptografia
Tudo é criptografado em trânsito e em repouso. Não existe caminho sem criptografia para entrar ou sair.
- Em trânsito
- HTTPS em tudo, com certificados emitidos e renovados automaticamente. Cada resposta leva HSTS por um ano, incluindo subdomínios. HTTP puro é redirecionado, nunca servido.
- Em repouso
- Os dois discos do servidor de aplicação são volumes criptografados. O bucket de arquivos é criptografado no servidor, bloqueia todo acesso público e guarda versões dos objetos, para que um arquivo apagado possa ser recuperado. O registro de contêineres também é criptografado.
- Segredos
- As suas credenciais de conexão, os seus segredos de assinatura de webhook, as configurações de gatilho e as chaves dos provedores de IA são criptografadas uma segunda vez dentro do banco de dados, com chaves da aplicação. Uma cópia do banco de dados sozinha não revela nada disso.
- Senhas
- Guardadas como hash com bcrypt. Nunca armazenamos uma senha, e não conseguimos ler nenhuma.
- Cartões de pagamento
- Tratados pela Stripe e nunca enviados para nós. Não guardamos nenhum número de cartão.
Os navegadores também recebem políticas de tipo de conteúdo, de enquadramento, de referenciador e de permissões em cada página, para que um erro em uma camada não vire uma exploração no navegador em outra.
Quem alcança os seus dados
O acesso é decidido por workspace e é verificado no servidor a cada requisição. Um papel no navegador decide o que é desenhado; não decide o que é permitido.
- Papéis
- Quatro papéis de workspace — admin, editor, leitor e revisor — mais dois papéis de organização. Um revisor consegue esvaziar uma fila sem conseguir editar o fluxo que a encheu.
- Login único
- SAML e OIDC, com descoberta por domínio verificado. O seu provedor de identidade continua sendo a autoridade, então as suas próprias regras de múltiplos fatores e de acesso condicional valem também na ArboRule.
- Sincronização de diretório
- SCIM. Uma pessoa removida no seu diretório perde o acesso aqui, sem ninguém precisar lembrar de fazer isso.
- Chaves de API
- Restritas por workspace e por ambiente, listadas nas configurações e revogáveis a qualquer momento.
- A nossa própria equipe
- Ninguém na ArboRule navega por um workspace de cliente por acaso. O acesso de suporte exige um motivo escrito, expira automaticamente depois de 30 minutos e fica registrado com o nome de quem o abriu.
O log de auditoria
Cada organização tem um log de auditoria que registra quem fez o quê e quando. Ele cobre entradas no sistema, mudanças de permissão, publicação de fluxos, mudanças de conexão, criação de chaves e acesso de suporte.
Ele não pode ser editado nem apagado — nem por você, nem por nós. O próprio banco de dados recusa a mudança, por uma regra que fica abaixo da aplicação. Um operador com acesso total ao banco ainda assim não consegue reescrever uma entrada. Isso é uma decisão de projeto: um log de auditoria que um administrador pode alterar em silêncio não é prova de nada.
Você pode lê-lo nas configurações e exportá-lo como CSV, para que ele vá para o seu próprio arquivo em vez de viver só aqui.
Como construímos e publicamos
Toda mudança chega à produção por um pull request, e esse pull request roda automaticamente as verificações abaixo.
- Análise estática das classes comuns de vulnerabilidade web, sobre a aplicação inteira.
- Uma checagem de cada dependência contra a base pública de vulnerabilidades. Uma biblioteca com falha conhecida quebra o build.
- A suíte de testes completa, com um piso mínimo de cobertura de linhas que quebra o build quando um subsistema novo chega sem testes.
- Verificações de estilo e de tipos no código do servidor e no do navegador.
- Uma varredura de vulnerabilidades na imagem de contêiner, executada quando a imagem é enviada.
Atualizações de dependências são propostas automaticamente toda semana para o servidor, para o pacote do navegador e para a própria esteira de build. Credenciais de produção nunca ficam no repositório: elas vivem no AWS Parameter Store como valores criptografados, e a aplicação as lê por um papel de instância em vez de uma chave guardada.
Rede e plataforma
- Uma nuvem privada virtual dedicada. Só as portas web ficam abertas para a internet.
- O acesso administrativo por SSH é restrito a endereços nomeados, com bloqueio por falhas repetidas por cima.
- Instance metadata requires a session token, so a request-forgery bug cannot read the server's cloud credentials.
- Limites de taxa na entrada, no cadastro, na API de decisão e em cada receptor público, com chaves que impedem uma integração barulhenta de sufocar outra.
- Os webhooks de saída são protegidos contra falsificação de requisição e assinados com um segredo rotacionável, para que quem recebe possa verificar que a mensagem veio de nós.
- Proteção contra robôs nos formulários públicos de cadastro e de demonstração.
- Os erros são reportados a um serviço de monitoramento configurado para excluir dados pessoais.
Backups e recuperação
O banco de dados é copiado toda noite no servidor, e uma cópia criptografada é gravada no mesmo dia em um armazenamento de objetos separado. O arquivo externo guarda 7 cópias diárias, 4 semanais e 6 mensais, e verifica a própria integridade a cada execução. Os arquivos enviados ficam em armazenamento versionado, então uma exclusão pode ser desfeita por 30 dias.
Os logs de plataforma são guardados por 12 meses, tempo suficiente para investigar um problema relatado meses depois de acontecer. As regras completas de retenção estão na política de privacidade.
Dito com todas as letras: o serviço roda em uma região e uma zona de disponibilidade, e a restauração é feita por um operador, não automaticamente. Não vamos chamar isso de alta disponibilidade. Está na lista abaixo.
Os seus dados e os seus direitos sobre eles
Para o conteúdo que você coloca em um workspace, você é o controlador e nós somos o operador. Não usamos o conteúdo do seu workspace para treinar modelos, e não vendemos dados pessoais.
Você não precisa nos pedir para exercer um direito sobre os dados. Um admin da organização pode exportar a conta, apagar um usuário específico ou encerrar a conta inteira de dentro do produto. O encerramento é armado com 14 dias de antecedência para que um admin possa cancelar um engano, e então remove cada workspace, fluxo, registro de decisão, caso e arquivo.
A política de privacidade nomeia cada suboperador que recebe dados pessoais, o que cada um faz com eles e onde faz.
O que ainda não temos
Esta cláusula é o motivo para ler a página. Todo fornecedor lista o que tem. A pergunta útil é o que ele não tem, e preferimos que você descubra aqui do que três semanas dentro de uma análise de compras.
- A ArboRule não tem certificado ISO 27001 próprio, nem relatório SOC 2 próprio. O nosso provedor de infraestrutura tem os dois. Um programa para certificar a aplicação está em andamento; pergunte em que etapa ele está.
- Nenhum teste de intrusão por terceiros foi feito ainda. Um está planejado.
- Nenhum acordo de tratamento de dados foi publicado ainda. Pergunte e diremos com honestidade em que ponto está a minuta.
- Apenas uma região. Não há escolha de residência de dados, nem troca automática para uma segunda região.
- A autenticação de múltiplos fatores não está embutida na entrada por senha. Organizations that connect single sign-on already get their identity provider's factors today, and that is the route we recommend.
- Nenhum compromisso de disponibilidade publicado. Não vamos imprimir um número que não medimos contra um contrato.
Se um destes bloqueia uma compra, diga. Saber qual lacuna custa um negócio real é o que faz ela virar prioridade.
Relatar uma vulnerabilidade
Write to hello@arborule.com with the words "security report" in the subject. Machine-readable details are published at /.well-known/security.txt.
Conte o que você encontrou, como reproduzir e o que um atacante conseguiria fazer com isso. Buscamos confirmar o recebimento em até três dias úteis, e avisaremos quando a correção for publicada.
We will not pursue legal action against research carried out in good faith under the terms below. Test only accounts you own, do not run denial-of-service or automated scanning against production, do not access another customer's data, and give us a reasonable period to fix the problem before you publish.
Não mantemos um programa pago de recompensas. Damos crédito a quem relata e quer ser creditado.