# Segurança do PDF Blocks

Como a API do PDF Blocks trata os documentos que você envia e os controles por trás do serviço, da criptografia à resposta a incidentes.

<TranslationNotice />

Esta página descreve a segurança da **API de processamento de documentos do PDF
Blocks**: o serviço que recebe, transforma e devolve seus documentos PDF. É ali
que seus dados são tratados, então é esse o foco aqui. É um serviço
**stateless** que não armazena nada, e ele roda separado dos nossos sistemas de
conta e faturamento, que nunca recebem seus documentos. Esta página foi escrita
para as equipes de segurança e de compras que nos avaliam; se você precisar de
um controle que não esteja coberto aqui, escreva para
[security@pdfblocks.com](mailto:security@pdfblocks.com).

**Prefere um documento?** Baixe o [PDF Blocks Security Whitepaper
(PDF)](/pdf-blocks-security-whitepaper.pdf), um resumo compartilhável de tudo o
que está nesta página.

## Dois compromissos que definem a API

A maior parte do que torna o PDF Blocks seguro de adotar se resume a dois fatos
estruturais sobre como a API funciona:

- **Nunca armazenamos seus documentos.** A API processa cada arquivo na memória
  e devolve o resultado na mesma resposta. Os documentos nunca são gravados em
  um banco de dados nem em armazenamento durável. Um upload grande pode ficar
  brevemente em buffer em um arquivo temporário pela duração de uma única
  requisição, e ele é excluído assim que a requisição termina.
- **Nosso pipeline é determinístico, sem LLMs.** Toda ação é manipulação de
  documento implementada em código: o mesmo documento e os mesmos parâmetros
  sempre produzem a mesma saída. Nenhum grande modelo de linguagem lê seus
  documentos, o pipeline não chama nenhum serviço de IA de terceiros e nada do
  que você nos envia é usado para treinar ou fazer o ajuste fino de um modelo.

## Como seus documentos são tratados

Quando você envia um documento para a API, ele é recebido por TLS, processado na
memória e devolvido em streaming na resposta. Nada do conteúdo do documento é
retido. Para cada requisição registramos apenas metadados (um hash da chave de
API, a ação solicitada, a contagem de bytes de entrada e de saída, o status da
resposta e uma marca de tempo), que usamos para faturamento, segurança e
prevenção de abusos. O processamento que realizamos em seu nome é regido pelo
nosso [Adendo de processamento de dados](/docs/trust/dpa), disponível para
clientes corporativos.

Como os documentos nunca são persistidos, não há dados de documento para
exportar, excluir ou para os quais emitir um certificado de destruição; a
garantia é estrutural, e não uma política que precisamos fazer cumprir.

## IA e aprendizado de máquina

O PDF Blocks não é um produto de IA. Ações como mesclar, dividir, girar, aplicar
marca-d’água, carimbar e proteger com senha são transformações determinísticas
escritas em código, e elas são tudo o que a API faz com o seu arquivo. Nenhum
grande modelo de linguagem lê seus documentos, e nenhum conteúdo de documento é
enviado a um serviço de IA de terceiros.

Algumas operações precisam trabalhar sobre a aparência de uma página, e não
sobre a sua estrutura. Ler um código de barras é o exemplo mais claro: localizar
o símbolo na página e decodificá-lo pode usar computação visual. Isso é análise
de imagem, não um modelo de linguagem, e roda dentro do mesmo ambiente isolado
sem acesso de saída à internet que todo o resto. De um jeito ou de outro, a
regra é a mesma: **não treinamos modelos de aprendizado de máquina com seus
documentos**, e nunca usamos o conteúdo deles para nada além da operação que
você solicitou.

## Criptografia

- **Em trânsito.** Todas as conexões são criptografadas com TLS. Aplicamos uma
  política moderna de TLS 1.3 / 1.2, e requisições em HTTP simples são
  redirecionadas permanentemente para HTTPS. O tráfego entre os componentes
  internos da API também é criptografado com TLS.
- **Em repouso.** A API não mantém armazenamento durável, então não há nada a
  criptografar em repouso, por design. Um upload grande pode ficar brevemente em
  buffer em um arquivo temporário pela duração de uma única requisição; esse
  arquivo é excluído assim que a requisição termina e nunca é retido.

## Autenticação na API

As requisições são autenticadas com uma chave de API, que identifica sua conta
para que possamos autenticar a requisição e medir o uso para o faturamento.
Armazenamos cada chave apenas como um hash SHA-256 com um prefixo curto de
exibição; a chave completa é exibida uma única vez, na criação, e depois disso
nunca mais pode ser recuperada conosco. As chaves podem ser revogadas a qualquer
momento, e as revogações são mantidas como trilha de auditoria. As chaves são
vinculadas a um plano, que rege as regiões, os tamanhos de documento e os
volumes que elas podem usar.

Uma chave de API é uma credencial de uso, não uma porta para seus dados. Ela nos
diz a qual conta uma requisição pertence, para que possamos autorizá-la e
contabilizá-la no seu plano, e é só isso que ela faz. Não existe endpoint que
liste, baixe ou reproduza documentos que você já processou, porque nunca os
armazenamos. Quem rouba uma chave pode gastar sua cota, e é por isso que as
chaves podem ser revogadas instantaneamente, mas **não consegue alcançar nem um
dos seus documentos**. A resposta de cada requisição é a única cópia, e ela é
sua.

## Infraestrutura

A API roda na Amazon Web Services e na Microsoft Azure, definida como
infrastructure-as-code e implantada por um pipeline automatizado e revisado.
Propriedades principais:

- **Isolamento de rede.** O processamento de documentos roda em redes privadas
  isoladas *sem acesso de saída à internet*, de modo que não pode exfiltrar
  dados nem em princípio.
- **Proteção na borda.** A API é protegida por um firewall de aplicações web com
  rate limiting.
- **Hosts endurecidos e efêmeros.** A computação roda sobre imagens base atuais
  e com patches aplicados; os discos das instâncias são criptografados e são
  destruídos quando uma instância é desativada.
- **A segurança física** dos data centers subjacentes é herdada da AWS e da
  Microsoft Azure, que mantêm atestações SOC 2, ISO 27001 e PCI DSS para suas
  instalações.

## Regiões e residência de dados

Você escolhe onde seus documentos são processados endereçando um endpoint
regional; a requisição é processada inteiramente dentro daquela jurisdição e em
nenhum outro lugar. A API está disponível nas seguintes regiões, cada uma
*stateless* e executando o catálogo completo de ações:

| Região                        | Endpoint                |
| ----------------------------- | ----------------------- |
| Global (roteado por latência) | api.pdfblocks.com       |
| Estados Unidos                | us.api.pdfblocks.com    |
| HIPAA Estados Unidos          | hipaa.api.pdfblocks.com |
| União Europeia                | eu.api.pdfblocks.com    |
| Reino Unido                   | uk.api.pdfblocks.com    |
| Canadá                        | ca.api.pdfblocks.com    |
| Austrália                     | au.api.pdfblocks.com    |
| Japão                         | jp.api.pdfblocks.com    |
| Índia                         | in.api.pdfblocks.com    |
| Brasil                        | br.api.pdfblocks.com    |

Como o processamento é *stateless*, a residência de dados se resume a uma única
decisão: para qual host você envia a requisição. Os detalhes estão na nossa
documentação de [Regiões e residência de
dados](/docs/api/regions-and-data-residency).

O endpoint alinhado à HIPAA é para fluxos de trabalho que envolvem informações
de saúde protegidas, sob um Business Associate Agreement assinado. Consulte
[HIPAA](/docs/trust/hipaa).

## Segurança da aplicação e do desenvolvimento

- Toda alteração é versionada, revisada por pares e integrada por meio de
  integração contínua, que executa testes automatizados de unidade, de
  integração e de contrato antes que o código possa ser publicado.
- Cada commit é examinado por ferramentas de segurança automatizadas (análise
  estática do código da aplicação e auditoria de vulnerabilidades de
  dependências), e as atualizações de dependências são propostas automaticamente
  e revisadas.
- As implantações se autenticam com credenciais federadas de curta duração (sem
  chaves de nuvem de longa duração) e exigem uma etapa explícita de aprovação
  humana para chegar à produção.
- Os lançamentos passam por verificações de integridade e são revertidos
  automaticamente se uma nova versão falhar no seu autoteste de prontidão.

## Gestão de vulnerabilidades e resposta a incidentes

As vulnerabilidades são identificadas continuamente (varredura de dependências,
análise estática, comunicados de fornecedores e relatos externos), triadas por
severidade e corrigidas em prazos definidos, com os problemas críticos tratados
em questão de dias. Tratamos os incidentes de segurança segundo um plano
documentado, com severidades e etapas de resposta definidas, e notificamos os
clientes afetados sobre incidentes confirmados ou suspeitos que os impactem, sem
atraso indevido, em conformidade com o nosso [Adendo de processamento de
dados](/docs/trust/dpa) e com a legislação aplicável.

## Disponibilidade e resiliência

- Em todas as regiões, a API roda com capacidade redundante em várias zonas de
  disponibilidade, atrás de balanceadores de carga com verificação de
  integridade, com substituição automática da capacidade não íntegra.
- As implantações usam atualizações graduais com reversão automática, de modo
  que um lançamento com falha não derruba o serviço.
- Como a API é *stateless*, a recuperação é uma questão de capacidade íntegra
  (não há dados de documento a restaurar), e uma interrupção em uma região não
  afeta as outras.

## Registros e monitoramento

Registramos apenas metadados da requisição (a ação, a contagem de bytes, um hash
da chave de API, o status e a marca de tempo) e **nunca** o conteúdo dos seus
documentos. Os logs ocultam credenciais e tokens. Métricas e alarmes de
infraestrutura acompanham as taxas de erro, a latência e a integridade dos hosts
para que possamos detectar e tratar problemas rapidamente.

## Como nossos controles se mapeiam para frameworks comuns

A API do PDF Blocks é construída para se alinhar aos critérios que frameworks
formais como SOC 2 e ISO 27001 avaliam. A tabela abaixo resume como nossos
controles se mapeiam para os Trust Services Criteria do SOC 2; teremos prazer em
apresentar a um avaliador as evidências por trás de qualquer um deles.

| Trust Services Criterion | Como a API do PDF Blocks atende a ele |
| --- | --- |
| **Security** (critérios comuns) | TLS 1.3 em trânsito; firewall de aplicações web e rate limiting; redes privadas isoladas sem acesso de saída; chaves de API armazenadas como hash; acesso de menor privilégio; varredura automatizada de vulnerabilidades. |
| **Availability** | Capacidade redundante em várias zonas de disponibilidade, verificações de integridade, uma API multirregião e implantações graduais com reversão automática. |
| **Confidentiality** | Documentos processados na memória e nunca armazenados; criptografia em trânsito; segmentação de rede rigorosa; obrigações de confidencialidade para a equipe e para os subprocessadores. |
| **Processing Integrity** | Operações determinísticas sobre documentos; revisão por pares, integração contínua e testes de contrato que condicionam cada lançamento; gestão de mudanças com implantação automática submetida a verificações de integridade. |
| **Privacy** | Sem retenção de documentos; documentos nunca compartilhados com nenhum subprocessador; nenhum uso de dados de clientes para treinar IA; residência de dados selecionável por região. |

## Subprocessadores

O processamento de documentos roda na Amazon Web Services e na Microsoft Azure.
O conteúdo dos seus documentos **não é compartilhado com nenhum subprocessador**;
ele é processado dentro da nossa própria infraestrutura, na região que você
endereça. A lista completa de subprocessadores, com a finalidade e a localização
de cada provedor, é mantida na nossa página
[Subprocessadores](/docs/trust/subprocessors).

## Documentação disponível mediante solicitação

Clientes e potenciais clientes do **plano Business** podem solicitar, sob acordo
de confidencialidade mútuo, nossas políticas internas de segurança (Segurança da
Informação, Controle de Acesso, Criptografia, Proteção e Retenção de Dados,
Gestão de Vulnerabilidades, Desenvolvimento Seguro, Resposta a Incidentes e
Continuidade de Negócios) e um questionário de segurança preenchido. Escreva
para [security@pdfblocks.com](mailto:security@pdfblocks.com) para começar.

## Relatar uma vulnerabilidade

Se você acredita ter encontrado uma vulnerabilidade de segurança no PDF Blocks,
relate-a para [security@pdfblocks.com](mailto:security@pdfblocks.com). Recebemos
bem a divulgação coordenada, confirmaremos o recebimento do seu relato e pedimos
que você nos dê uma oportunidade razoável de corrigir antes de qualquer
divulgação pública. Nossos dados de contato legíveis por máquina estão
publicados em [/.well-known/security.txt](/.well-known/security.txt).