Segurança e implantação

CoRoid realiza trabalhos de engenharia autônomos no seu código. Esta página aborda onde esse trabalho é executado, até onde ele pode chegar, como as credenciais e os dados são protegidos e qual registro ele deixa. Descreve os controles atualmente em vigor. Os controles planejados são rotulados como planejados.

Onde o trabalho dos agentes é executado#

Cada tarefa é executada em sua própria área de trabalho em nuvem isolada. A área de trabalho é criada para aquela tarefa e desmontada após sua conclusão. Os agentes leem e gravam apenas o repositório que foi extraído para ela.

Existem três zonas:

O trabalho sai do espaço de trabalho em uma única forma: um pull request. Sua equipe decide se ele será incorporado, e o seu próprio caminho de implantação o leva a partir daí. O CoRoid não precisa de extensão IDE, de agente local ou de acesso à sua rede privada.

Até onde uma área de trabalho pode acessar na internet#

Uma área de trabalho que compila e testa seu código acessa endereços públicos da internet diretamente, de modo que instalações e downloads funcionam como em uma máquina de desenvolvedor. Ela nunca acessa endereços privados: a rede interna do cluster, o serviço de metadados em nuvem e faixas privadas são bloqueados para ela.

Rede de sandbox, sob Segurança → Configurações, encaminha os espaços de trabalho de um escopo pelo proxy de saída do CoRoid. Ele fica desativado até que você o ative, seja para a configuração padrão da organização ou para um projeto específico, em todos os planos:

• Ativado (observar). Toda conexão passa pelo proxy, que registra o host e a porta da tarefa, nunca o caminho ou qualquer conteúdo. Nada é recusado.
• Recusar o que não é permitido (impor), selecionado no painel de proteção. O proxy permite o acesso a registros públicos de pacotes (npm, PyPI, módulos Go, crates.io, RubyGems, Maven Central e Gradle, NuGet, Packagist, Hex, pub.dev, conda), ao repositório Git do seu projeto e aos hosts presentes na lista de permissões configurada. Tudo o mais é bloqueado. Quando um comando falha após essa rejeição, o agente recebe informações sobre qual host foi recusado e o motivo.

O painel exibe onde as sandboxs se conectaram nos últimos 30 dias: cada host e porta, quantas tarefas e conexões, a tarefa que os acessou por último e se foram permitidos, recusados ou seriam recusados sob a opção 'impor' com a lista atual. Permitir adiciona um host à lista. Comece em modo observar: a lista mostra o que a opção 'impor' recusaria antes de você ativá-la.

A Rede Na seção, na sua visualização de Factory, são listados os destinos alcançados pelos seus espaços de trabalho, com as recusas primeiro. Uma varredura executada pelo próprio CoRoid (uma varredura de segurança, por exemplo) mantém o seu espaço de trabalho em uma tarefa própria; essa tarefa indica qual foi a varredura e lista os seus destinos da mesma forma.

Em ambos os modos, uma conexão que ignora o proxy, como uma conexão TCP bruta, falha, e o proxy nunca se conecta a um endereço privado. As ferramentas encontram o proxy por meio das variáveis de proxy padrão, que o CoRoid define; o Maven lê o seu proxy apenas de settings.xml, portanto uma compilação Maven não consegue acessar a internet enquanto a Rede de sandbox estiver ativada. As consultas de nome ainda passam pelo resolvedor do cluster. A alteração se aplica às áreas de trabalho criadas após ela.

Cada entrada na lista de permissões é um host (api.example.com), seus subdomínios (*.example.com), ou ambos com uma porta (example.com:8443; sem porta, 80 e 443). Um projeto com sua própria configuração tem seu próprio modo e lista; Usar o padrão retorna à configuração da organização. A definição acompanha portabilidade de configurações, assim como o restante das configurações de Segurança.

Identidade e acesso#

A autenticação é centralizada no gateway. Ele suporta:

• Sessões de usuário baseadas em JWT para acesso ao portal
• Tokens de serviço a serviço com rotação gerenciada
• Chaves API para integrações externas
• Proteções para endpoints de usuário, serviço e acesso misto

O acesso ao repositório é limitado ao projeto. As credenciais de um projeto não podem ser usadas por outro projeto, e o CoRoid não precisa de credenciais de toda a organização para trabalhar em um único repositório. Veja Conecte seu código.

Os proprietários e administradores da organização gerenciam membros, sessões e o feed de eventos de segurança em Configurações → Identidade e acesso. SSO/SAML com provisionamento SCIM faz parte do plano Enterprise, que está em pré-visualização privada.

Proteção de dados#

• Os dados são criptografados em trânsito e em repouso.
• As credenciais da sua organização, como chaves de provedor, tokens de repositório e outros segredos de integração, são criptografadas com uma chave de dados própria da sua organização. Um serviço de gerenciamento de chaves criptografa essa chave de dados em seguida. Apenas o corretor de credenciais do CoRoid pode descriptografá-las, e ele registra cada uso. Veja Chaves de provedor.
• Os próprios segredos de configuração do CoRoid são armazenados criptografados.
• O serviço de nuvem pública oferece um perfil de hospedagem na UE para equipes com requisitos de GDPR ou de residência de dados. O Apenas na UE perfil do AI mantém a inferência de modelo com provedores hospedados na UE. Veja Perfis do AI.
• Você controla por quanto tempo o histórico de execução, transcrições e artefatos são mantidos. Veja Retenção de dados.

O histórico de decisões#

Cada alteração autônoma é explicada nos termos que revisores e equipes de segurança já utilizam:

• a especificação, a atividade do agente, a Revisão e a decisão de aprovação permanecem vinculadas à tarefa
• O histórico de execução registra cada execução do agente, incluindo tentativas falhas e o motivo de suas falhas
• O histórico de pull request mostra a evidência final antes que o código seja Mesclar
• Evidências de segurança, dependências, cobertura, testes visuais, end-to-end e de navegador podem ser anexadas a uma Revisão. Veja Evidência de Revisão.

As portas de Mesclar mantêm as alterações de produção sob políticas explícitas. Nada é Mesclar sem a aprovação do seu portões de qualidade são necessários.

Operações de produção#

• Geração de SBOM e varredura de imagens de contêiner em CI
• Endpoints públicos exclusivamente HTTPS com terminação TLS
• Snapshots automatizados de banco de dados e runbooks de restauração
• Monitoramento e alertas de métricas, logs e erros

Opções de implantação#

CoRoid opera em três modelos operacionais. O fluxo de trabalho é o mesmo em todos; o que muda é onde residem o tempo de execução, o armazenamento, o acesso ao repositório e as credenciais.

Local#

As implantações locais permitem que equipes regulamentadas mantenham o acesso ao repositório, o armazenamento, as credenciais e a política de rede dentro da infraestrutura que elas gerenciam.

• Docker Compose é adequado para instalações em servidor único e pilotos. Volumes persistentes armazenam o banco de dados, os repositórios e os logs.
• Kubernetes é adequado para instalações em múltiplos servidores e com escalonamento automático. O Helm gerencia os serviços de aplicativo, trabalhador, sincronização e executor, e funciona com PostgreSQL gerenciado ou auto-hospedado e armazenamento de objetos.
• Redes restritas pode usar estratégias de modelo e dependências offline, gerenciamento de segredos auto-hospedado e TLS interno.

O acesso ao Git utiliza tokens de acesso pessoal em vez de instalação de aplicativo de terceiros e pode apontar para hosts de repositório internos.

Certificações#

Atualmente, o CoRoid não possui relatório SOC 2 nem outra certificação de segurança de terceiros. O SOC 2 é uma meta de preparação. Não descreveremos um controle como certificado até que ele o seja.

Relacionados#

• Segurança: encontrar e corrigir vulnerabilidades no seu próprio código e nas dependências
• Retenção de dados
• Chaves de provedor
• Planos e preços
• Evidência de Revisão