YPCad
Português
Peça uma demonstração

Segurança

Esta página diz tanto o que protegemos como o que não conseguimos proteger. Uma história de segurança a que falte a segunda parte leva o leitor a confundir uma lista com uma garantia.

Ponto de partida

Publicar um pacote é executar código no computador de cada engenheiro que o instala. Cada decisão de segurança deste produto foi primeiro pesada contra uma pergunta: esta alteração torna mais fácil publicar sem direito?

  • Os pacotes são assinados (ECDSA P-256)

    O ficheiro da assinatura viaja dentro do pacote. Assina um manifesto com as impressões dos ficheiros, o identificador do pacote e a versão — e não uma simples impressão do arquivo.

    Se só a impressão fosse assinada, um arquivo antigo corretamente assinado poderia ser apresentado sob um número de versão novo: a assinatura passaria a verificação, e o utilizador instalaria como «atualização» uma ferramenta com uma vulnerabilidade conhecida.

  • A chave privada NÃO fica no servidor

    O servidor apenas verifica. A assinatura acontece no computador de quem publica, com uma ferramenta própria.

    Se a chave ficasse no servidor, quem o tomasse poderia alterar um pacote e voltar a assiná-lo — o que tornaria a assinatura inútil.

  • O cliente também verifica

    A extensão no computador do engenheiro verifica a assinatura por si, e a lista de chaves de confiança que usa não vem do servidor.

    A assinatura existe precisamente porque não se pode acreditar no servidor pela palavra. Ir buscar a lista de confiança a esse mesmo servidor anularia em silêncio o pressuposto de partida.

  • Um registo de auditoria que não se apaga

    Cada publicação, cada mudança de direito e cada decisão de canal ficam escritas para sempre. Não existe, de propósito, nenhum caminho de alteração ou de eliminação, e a limpeza depois do prazo de guarda não lhe toca.

    «Como é que esta ferramenta veio aqui parar» pergunta-se normalmente meses depois. Nesse dia, um apontamento que pudesse ter sido apagado é um apontamento que nunca existiu.

  • Regra dos quatro olhos, opcional

    Subir uma versão para um canal mais largo pode exigir a aprovação de um segundo administrador, e quem pediu não pode aprovar o seu próprio pedido. Voltar atrás nunca exige aprovação.

    Por predefinição está desligada. Numa equipa de três pessoas, o obstáculo transforma-se em poucas semanas numa mensagem que se aprova sem ler; um controlo em que se acredita que protege sem proteger é pior do que controlo nenhum.

  • Desempacotar um arquivo é por si só uma superfície de ataque

    Os arquivos carregados são verificados quanto à saída da pasta (zip-slip) e quanto a bombas de desempacotamento, e o tamanho depois de desempacotar é limitado.

    Desempacotar um arquivo parece inofensivo. Um arquivo preparado de propósito pode escrever ficheiros fora da pasta de destino ou encher o disco do servidor.

  • Entrada sem palavra-passe

    Os utilizadores entram com um código de uso único enviado para o seu endereço. A sessão anda com um testemunho de vida curta; o testemunho de renovação nunca é visível para o código no navegador.

    Se não há cofre de palavras-passe para gerir, também não há base de palavras-passe que possa fugir. E reutilizar um testemunho de renovação já revogado é tratado como sinal de roubo: a sessão fecha-se.

  • Vê aquilo que instala

    A pasta de instalação contém uma lista de componentes legível por máquina (SBOM CycloneDX) e scripts de migração para as duas bases de dados.

    A sua equipa de informática tem de poder verificar o que chega ao servidor antes de chegar. Quando se anuncia uma vulnerabilidade numa dependência, «temo-la?» passa a ser uma pesquisa por ficheiros.

O que não conseguimos proteger

Isto não são falhas, são limites. Decorrem da estrutura, e afirmar o contrário seria falso.

  • Dois administradores a agir em conjunto. A regra dos quatro olhos trava um, não dois.
  • O administrador de sistema do servidor. Para quem tem acesso à base de dados e ao sistema de ficheiros, nenhum controlo ao nível da aplicação é obstáculo.
  • O posto onde está a chave de assinatura. A chave não está no servidor, mas está algures; se essa máquina cair, cai também a assinatura.
  • Comportamento malicioso escondido de propósito. A nossa inspeção dos pacotes é heurística e não afirmamos que apanhe código que procure esconder-se.
  • A fuga de dados. Uma ferramenta instalada trabalha com os direitos do próprio engenheiro e consegue ler tudo aquilo que eles alcançam. Isso é limitado pelos controlos do sistema operativo e da rede, não por este produto.
  • A segurança das suas cópias de segurança. A cópia da base de dados está nas suas mãos, e tudo o que está lá dentro vale exatamente o mesmo que o sistema vivo.

Comunicar uma vulnerabilidade

Se encontrou alguma, escreva-nos. Levamos as comunicações a sério, não afastamos do processo quem comunica, e dizemos-lhe quando sai a correção.

security@ypcad.com