Enterprise

Introdução

Esta página documenta o plano Enterprise para quem precisa aprová-lo: arquitetura de segurança, GRC e o time que assina o runbook de crise. Trata do que muda com contrato de disponibilidade, segregação de funções e auditoria externa trimestral.

A diferença entre standard e enterprise não é volume, é garantia. No standard o failover zonal é best-effort e o RPO depende de quando o último WAL segment foi arquivado. No enterprise o failover é medido, o RPO é contratado em segundos e cada indisponibilidade gera artefato assinado.

O crédito é apurado pela própria observabilidade, sem chamado: roda no dia 3 sobre o mês anterior e publica em /v2/org/sla/statements.

Visão geral

Um ambiente Enterprise tem uma organização (faturamento e identidade), um ou mais tenants (isolamento) e, em cada tenant, ambientes — prod, staging, dr. Políticas, chaves e destinos de log vivem no tenant; cotas e limites de taxa, no ambiente.

O limite duro é 64 tenants por organização e 12 ambientes por tenant. Acima disso a propagação deixa de ser transacional: lotes de 16, com até 40 s de inconsistência entre o primeiro e o último tenant. Para mais fronteiras, use outra organização ligada por org-link, que compartilha identidade e não cota.

A camada de evidência não é opcional nem desligável. Toda mutação gera registro imutável antes de ser confirmada: com o gravador fora, a operação falha com 503 audit_sink_unavailable — disponibilidade trocada por não-repúdio.

Primeiros passos

A ativação não é auto-serviço: envolve federação de identidade e emissão de material criptográfico. Leva de 3 a 5 dias úteis, a maior parte validando metadata do IdP e esperando o peering. Nada exige downtime.

Execute o roteiro antes num tenant staging descartável. A promoção de standard para enterprise é reversível em 7 dias; depois a trilha WORM já acumulou registros irremovíveis e o downgrade exige tenant novo.

1. Registrar o contato de segurança

   Recebe os SEV1 e é a única identidade que aprova rotação de chave-mestra. Deve ser um grupo.

2. Federar identidade

   Metadata SAML ou discovery OIDC. Certificado com menos de 30 dias de validade é rejeitado.

3. Ligar SCIM

   Sem ele, desativar um funcionário depende do TTL da sessão (até 12 h).

4. Estabelecer a rede privada

   Peering VPC ou túnel WireGuard. Ver VPN e peering.

5. Declarar a janela

   Faixa semanal de no mínimo 4 h para upgrades que reiniciam o primário.

6. Configurar o dreno para o SIEM

   Destino, formato e chave. Sem dreno, os logs ficam retidos internamente.

7. Executar o game day

   Failover zonal e regional forçados, cronometrados. Primeira evidência do dossiê.

a44 auth login --org acme --device-code
a44 org upgrade --tier enterprise --security-contact sec-ops@acme.example

# valida pré-requisitos antes de qualquer mutação
a44 org preflight --tier enterprise
# [ok]   idp: saml metadata válido (exp 2028-02-11)
# [fail] network: sem peering — RTO regional não garantido

a44 env create prod --tenant core --region sa-east-1 --replicas 3
a44 env create dr   --tenant core --region us-east-2 --role standby

Arquitetura

O plano de controle é global, replicado em três regiões com Raft de cinco membros, e nunca entra no caminho de requisição. Distribuída a política, o plano de dados opera mesmo com o controle fora do ar: o cache tem TTL de 900 s e um modo fail-static que o estende enquanto o controle estiver inalcançável.

A consequência precisa estar clara: revogação não é instantânea. Um token revogado durante uma partição segue aceito pelos nós em fail-static até ela se resolver. Quando isso é inaceitável, policy.strict_revocation: true troca fail-static por fail-closed e os nós recusam tráfego após o TTL.

Mudar qualquer um deles gera registro de auditoria com valor anterior e novo. strict_revocation e cache_ttl_s são alto impacto: exigem dois operadores distintos.

VPN e peering

Três formas de conectar a rede do cliente, não intercambiáveis. Peering VPC, quando ambos estão no mesmo provedor e região: 0,3 a 0,8 ms adicionais, sem egress entre pares, exige CIDRs sem sobreposição e não é transitivo. Overlay WireGuard, para on-premises e multicloud: MTU efetiva de 1380 bytes e teto prático de 2,4 Gbps por túnel. Endpoint privado, que expõe um serviço por DNS interno sem juntar redes.

Em qualquer modo não há rota default para a internet. Saídas — webhooks, integrações, metadata de IdP — passam por NAT de egress com IPs fixos por região, publicados em /v2/network/egress-ranges e trocados com 30 dias de aviso. Prenda o firewall ao endpoint, não a IPs copiados à mão.

apiVersion: net.a44/v2
kind: Tunnel
metadata:
  name: acme-onprem-sp
spec:
  mode: wireguard
  region: sa-east-1
  peer:
    publicKey: "Yk2p9c...=="
    endpoints:                 # dois, ativo/passivo
      - 200.19.44.10:51820
      - 200.19.44.11:51820
    allowedIps: ["10.40.0.0/16"]
  local:
    cidr: "10.244.0.0/20"      # não pode sobrepor allowedIps
    mtu: 1380
  keepaliveSeconds: 25
  rekeyMinutes: 120
  failover:
    detectionSeconds: 6        # 3 keepalives perdidos
    mode: active-passive

a44 net peering create \
  --tenant core --region sa-east-1 \
  --peer-account 4471-0092-1183 \
  --peer-vpc vpc-0af31c \
  --peer-cidr 10.40.0.0/16 \
  --routes-import 10.244.0.0/20 \
  --dns-resolution both

# o par aceita em até 72 h, senão o convite expira
a44 net peering status --tenant core
# state=pending-acceptance  expires_in=61h12m  overlap_check=ok

Sobreposição de CIDR é a recusa mais comum: overlap_check roda antes do convite e falha com 409 cidr_overlap. Não há NAT de contorno — se colidem, um lado renumera ou migra para endpoint privado.

Clusters e quórum

Cada cluster ha tem um primário e duas réplicas em zonas distintas, mais um consenso externo de cinco membros. O quórum de escrita é 3 de 5; o de promoção exige 3 de 5 e confirmação de que o candidato aplicou ao menos o LSN do último líder. Sem essa segunda condição, uma réplica atrasada seria promovida e perderia transações já confirmadas.

Split-brain é evitado por fencing por lease: o primário só escreve enquanto detém uma lease de 12 s renovada a cada 4 s. Perdido o contato, ele para na expiração — antes de qualquer promoção, já que o promotor espera lease_ttl + 3 s. São até 15 s sem primário numa partição, deliberadamente: melhor isso que duas cabeças gravando.

a44 db cluster inspect --env prod --tenant core
# leader        = node-a1  lease_expires_in=8.7s   fence_state=armed
# quorum        = 4/5 healthy   (node-e5 unreachable 3m12s)
# sync_standby  = node-b2  lag_bytes=0        lag_ms=1.8
# async_standby = node-c3  lag_bytes=1441792  lag_ms=612
# promote_ready = node-b2 (lsn 0/8F3A21C0 >= last_leader_lsn)

Com 4 de 5 membros o cluster opera normal. Com 3 de 5 ainda escreve, mas emite a44.consensus.thin_quorum e a próxima falha corta a escrita. Com 2 de 5 vira somente leitura em até 12 s, sem promoção manual possível.

Alta disponibilidade e failover multi-região

O failover zonal dispensa humano: detecção em até 12 s pela expiração da lease, eleição em 3 a 8 s, repontamento de DNS e pool em mais 20 a 60 s. O p95 dos game days de 2026 é 71 s, contra 90 s contratados. Conexões caem e o driver reabre — não há migração de sessão, e transações em voo são revertidas.

O failover regional é sempre manual: automatizá-lo exigiria confiar num detector remoto de falha, e um falso positivo custa mais que 15 min parado. Exige dois operadores com dr.promote, confirmação de 120 s e motivo registrado na trilha. O RPO aqui não é zero — a replicação inter-regional é assíncrona, com lag de 2 a 5 s e pico de 40 s durante rebuild de índice.

# game day: derruba o primário de propósito e cronometra
a44 chaos inject --env prod --fault primary-kill --dry-run=false \
  --window "2026-08-14T02:00:00-03:00/PT30M" --ticket CHG-88421

# promoção regional (exige segundo aprovador)
a44 dr promote --env dr --reason "regiao sa-east-1 indisponivel desde 03:12" \
  --confirm-window 120s
# aprovado por m.okada@acme.example em 41s
# novo primario us-east-2b  lsn_gap=3.2s (1.1 MB)

O lsn_gap final é o RPO real do evento e entra no relatório. Gap acima do contratado é violação de SLA mesmo com recuperação rápida: perder dado pesa mais que demorar a voltar.

Banco de dados

O Postgres roda com synchronous_commit = remote_apply contra uma réplica da mesma região — é o que sustenta o RPO de 5 s. Na prática o RPO zonal é zero; os 5 s são margem para quando a réplica síncrona é rebaixada em manutenção. O custo é 0,8 a 2,1 ms a mais por transação de escrita que local, o que só pesa em escritas muito granulares.

Se a réplica síncrona sumir por mais de sync_timeout_ms (padrão 8000), o cluster degrada para commit assíncrono em vez de travar e emite a44.repl.sync_lost — o único momento em que o RPO real deixa de ser zero. Quem prefere parar a perder usa sync_degrade: block: escritas falham com 57P03 até haver réplica síncrona; leituras seguem.

-- isolamento por linha, obrigatório em prod
alter table faturas enable row level security;
alter table faturas force row level security;

create policy tenant_read on faturas
  for select using (tenant_id = current_setting('a44.tenant', true)::uuid);

create policy tenant_write on faturas
  for insert with check (tenant_id = current_setting('a44.tenant', true)::uuid);

-- lag antes de servir leitura de réplica
select client_addr,
       sent_lsn, write_lsn, flush_lsn, replay_lsn,
       pg_wal_lsn_diff(sent_lsn, replay_lsn) as lag_bytes,
       extract(epoch from replay_lag)        as lag_s
from pg_stat_replication
order by lag_bytes desc;

import { connect } from '@anthares44/postgres';

const db = await connect({
  env: 'prod',
  tenant: 'core',
  poolSize: 40,                 // 200 por cluster
  statementTimeoutMs: 15_000,
  readPreference: 'primary',    // 'replica' aceita lag
  maxLagMs: 250,                // acima disso, cai para o primário
  retry: { attempts: 3, backoff: 'exponential', baseMs: 120, jitter: true },
});

// failover derruba conexões: 57P01/57P03 são retryable
await db.tx(async (t) => {
  await t.exec('set local a44.tenant = $1', [tenantId]);
  await t.exec('insert into faturas (tenant_id, valor) values ($1, $2)', [tenantId, 19990]);
});

O teto é de 200 conexões por cluster, réplicas incluídas; acima disso o pooler recusa com 53300 too_many_connections. O número pesa menos em regime do que no instante seguinte a um failover: todos os clientes reconectam ao mesmo tempo, e sem folga reservada o cluster novo passa a recusar conexões justamente durante os 71 s que o SLA cronometra — o RTO é cumprido pela plataforma e violado pela aplicação. Dimensione a soma dos pools de prod e dr em no máximo 70% do teto e confira a sobra em a44 db cluster inspect antes de cada game day.

Storage

O storage replica sincronamente entre três zonas e, no Enterprise, assincronamente para dr com lag alvo de 60 s no p99. Cada tenant tem bucket e chave KMS próprios; revogar a chave de um torna seus objetos ilegíveis sem afetar os demais.

Objetos podem ser WORM com retenção em modo governance ou compliance. Em governance, quem tem storage.bypass_retention remove antes do prazo e gera evento de severidade alta. Em compliance, ninguém remove — nem o suporte, nem o dono da organização. Auditores tratam retenção contornável como controle preventivo fraco.

{
  "bucket": "core-evidencias",
  "encryption": { "kms_key": "a44-kms://acme/core/objects-2026", "rotate_days": 365 },
  "object_lock": { "mode": "compliance", "retain_days": 2555 },
  "versioning": true,
  "replication": [
    { "region": "us-east-2", "role": "dr", "target_lag_s": 60 }
  ],
  "lifecycle": [
    { "prefix": "raw/", "to": "infrequent", "after_days": 30 },
    { "prefix": "raw/", "to": "archive",    "after_days": 180 },
    { "prefix": "tmp/", "action": "delete", "after_days": 7 }
  ],
  "public_access_block": true,
  "presign_max_ttl_s": 900
}

Sair de uma classe antes do mínimo cobra o período restante. A surpresa comum em fatura é um job mensal que reescreve objetos já em archive: cada reescrita reinicia o relógio e cobra a saída. Rode a44 storage lifecycle simulate antes.

Segurança

A identidade humana vem do IdP corporativo; não há senha para membros e o login local cai assim que a federação sobe. Sessões duram no máximo 12 h e são reavaliadas a cada 15 min contra o SCIM, então um usuário desativado perde acesso em até 15 min. Contas de serviço não são federadas e usam tokens de a44 auth mint com TTL máximo de 3600 s.

A segregação de funções são papéis mutuamente exclusivos mais dois operadores em ações de alto impacto. Ninguém acumula policy.write e audit.read: quem define a regra não verifica sozinho o cumprimento. Atribuir ambos falha com 422 sod_conflict e o nome do par.

apiVersion: iam.a44/v2
kind: DirectorySync
spec:
  protocol: scim2
  deprovisionAction: suspend      # suspend | delete — delete é irreversível
  reevaluateSeconds: 900
  groupMapping:
    - external: "SEC-Platform-Admins"
      roles: ["policy.write", "dr.promote"]
    - external: "SEC-Audit"
      roles: ["audit.read"]
    - external: "APP-DBA"
      roles: ["db.admin"]
      environments: ["prod", "staging"]
  requireMfa: true
  sessionMaxHours: 12
  breakGlass:
    accounts: 2
    ttlMinutes: 60
    notify: ["sec-ops@acme.example"]
    requiresTicket: true

Compliance

A plataforma mantém relatórios anexáveis ao dossiê do cliente: SOC 2 Tipo II com observação de 12 meses, ISO/IEC 27001 e 27017 e pentest anual por terceiro. Eles cobrem os controles da plataforma; os do cliente são dele — a plataforma dá evidência, não julgamento.

Para LGPD importam dois mecanismos. Residência: com data_residency: strict nenhum byte sai da região declarada, o que desabilita a replicação para dr e remove a garantia de RTO regional — o preflight avisa. Apagamento: /v2/privacy/erasure remove o titular em até 30 dias e registra o que ficou retido por conflito legal, com a base citada.

# pacote de conformidade, sob NDA aceito no portal
a44 compliance fetch --docs soc2-typeii,iso27001,pentest-2026 --out ./grc/

# apagamento de titular, com relatório do que ficou retido
a44 privacy erasure --subject-id 9f21-c0 --tenant core --dry-run
# faturas   : 412 -> RETIDAS (retencao fiscal, 5 anos)
# eventos   : 88301 -> APAGADAS
# audit_log : 1204 -> PSEUDONIMIZADAS (WORM nao aceita delete)

A trilha não é apagada nem em erasure: identificadores diretos viram pseudônimo estável e o mapeamento reverso é destruído, o que preserva a cadeia e atende ao pedido. Se o auditor não aceitar, resta reduzir audit.retention_years — antes de o dado entrar.

Auditoria e evidência

Toda ação de configuração ou acesso a dado sensível gera um registro de esquema fixo: at, actor, action, target, tenant, env, source_ip, request_id, before, after, approval, prev_hash. Os registros formam cadeia por hash e a raiz de cada bloco é assinada a cada 10 min com chave inacessível ao plano de controle, o que prova a terceiros que nada foi removido ou reordenado.

A verificação é auto-serviço: a44 audit verify recomputa a cadeia localmente e confere as assinaturas contra a chave pública, apontando o índice exato de qualquer divergência. Auditores rodam o comando na máquina deles, com o export que eles mesmos baixaram.

{
  "at": "2026-07-14T18:22:07.914Z",
  "actor": "m.okada@acme.example",
  "actor_type": "human",
  "action": "policy.update",
  "target": "policy/prod/network-egress",
  "tenant": "core",
  "env": "prod",
  "source_ip": "10.40.7.19",
  "request_id": "req_01J9K7XQ2M",
  "before": { "allow_egress": ["0.0.0.0/0"] },
  "after":  { "allow_egress": ["203.0.113.0/24"] },
  "approval": {
    "required": true,
    "approver": "r.lins@acme.example",
    "ticket": "CHG-88104",
    "elapsed_s": 137
  },
  "prev_hash": "sha256:6b1f9ac2",
  "hash": "sha256:0d8471fe"
}

a44 audit export --from 2026-04-01 --to 2026-06-30 \
  --tenant core --format jsonl --sign --out q2-2026.jsonl

a44 audit verify q2-2026.jsonl --pubkey ./a44-audit-2026.pem
# registros: 1482907   cadeia: integra   lacunas: nenhuma
# blocos   : 13104 assinados, 0 divergentes

Monitoramento e exportação para SIEM

São três fluxos distintos, e confundi-los custa dinheiro ou abre lacuna de detecção. Métricas: 15 meses, resolução caindo de 15 s para 5 min após 30 dias. Logs de aplicação: 30 a 90 dias. Trilha de auditoria: 7 anos, integridade verificável. Para o SIEM importa o terceiro mais uma seleção do segundo.

O dreno entrega em lotes de até 5 MB ou 10 s, at-least-once, com idempotência por request_id. Destino que recusa gera retry em backoff de 2 s a 5 min, com buffer de 72 h. Depois disso os eventos não se perdem — seguem na trilha e voltam com a44 siem replay — mas param de ser tentados sozinhos.

apiVersion: obs.a44/v2
kind: LogDrain
metadata:
  name: siem-corp
spec:
  streams: ["audit", "auth", "network.deny", "db.ddl"]
  format: ocsf-1.3            # ocsf-1.3 | cef | jsonl
  destination:
    type: https
    url: https://siem.acme.example/ingest/a44
    auth: { type: mtls, clientCertRef: "a44-kms://acme/core/siem-mtls" }
  batch: { maxBytes: 5242880, maxSeconds: 10 }
  retry: { baseSeconds: 2, maxSeconds: 300, bufferHours: 72 }
  signing: { enabled: true, alg: ed25519 }
  onBufferFull: block-writes  # block-writes | drop-oldest

onBufferFull: block-writes é o padrão: buffer cheio faz mutações falharem em vez de ocorrerem sem chegar ao SIEM. drop-oldest mantém a plataforma de pé e descarta o item mais antigo do buffer — a trilha guarda tudo, mas a detecção atrasa.

Backups, restauração e janelas de manutenção

O backup é contínuo: snapshot base a cada 24 h mais arquivamento de WAL a cada 60 s ou 16 MB. Dá restauração para qualquer instante da janela de retenção (padrão 35 dias, máximo 400 no Enterprise), com granularidade de segundo, sempre para um cluster novo — restaurar por cima destruiria a evidência do que motivou a restauração.

PITR observado: 12 min para 100 GB, 48 min para 1 TB, 3 h 20 min para 5 TB. Acima disso o gargalo vira a aplicação de WAL, single-threaded, e o tempo cresce mais rápido que o volume — nesse porte mantenha um dr quente. Semanalmente uma restauração de verificação roda isolada.

1. Identificar o instante

   a44 db timeline mostra DDLs, deploys e picos de erro. O alvo fica 1 a 2 min antes do primeiro sintoma.

2. Restaurar para cluster novo

   O cluster nasce isolado, sem tráfego apontado para ele.

3. Validar

   Contagens, checksums das tabelas críticas, amostragem. Não reponte antes.

4. Repontar

   Trocar o alias prod. Conexões caem; o driver reconecta.

5. Preservar o original

   O cluster antigo fica 14 dias em somente leitura como evidência do incidente.

a44 db restore --env prod --to '2026-07-14T18:20:00Z' --into prod-r1 --verify-only
# base 2026-07-14T02:00Z + 4812 segmentos WAL
# estimativa: 51 min   tamanho: 1.1 TB   integridade: ok

a44 maint window set --tenant core \
  --weekly "SUN 02:00-06:00" --tz America/Sao_Paulo --min-notice-days 14
# 2026-08-09 02:00  pg 17.4 -> 17.6  restart ~40s

Integrações

Quatro integrações interessam à segurança corporativa: IdP (SAML/OIDC), diretório (SCIM), SIEM e ITSM. As três primeiras já foram tratadas; aqui ficam o ITSM e o webhook genérico.

Aqui o webhook é saída de evidência, não notificação. Cada entrega parte de um IP da faixa de egress da região, é assinada com chave residente no KMS do tenant e deixa registro na trilha com request_id, destino e resultado — é isso que permite provar ao auditor que o alerta saiu, mesmo quando o receptor afirma não tê-lo recebido. Prenda o firewall do endpoint a /v2/network/egress-ranges e exija mTLS: um destino que aceita qualquer origem transforma a trilha em algo que o próprio auditor questiona. A receita de verificação da assinatura do lado do receptor está em Developers. Entrega at-least-once, até 8 tentativas em backoff ao teto de 15 min, e depois dead-letter de 30 dias — a mesma janela em que a44 audit export ainda reconcilia o que foi gerado com o que foi entregue.

apiVersion: obs.a44/v2
kind: WebhookDestination
metadata:
  name: itsm-corp
spec:
  events: ["a44.incident.opened", "a44.dr.promoted", "a44.audit.sink_down"]
  url: https://itsm.acme.example/api/incidents
  auth: { type: mtls, clientCertRef: "a44-kms://acme/core/itsm-mtls" }
  signing:
    keyRef: "a44-kms://acme/core/webhook-2026"
    rotateDays: 180
    overlapHours: 48          # aceita a chave antiga durante a troca
  egress: pinned              # sai apenas pelas faixas publicadas
  deadLetterDays: 30
  recordDeliveries: true      # entrega e resposta entram na trilha WORM

import { onEvent } from '@anthares44/events';

// abre chamado no ITSM e devolve o id para a trilha de auditoria
onEvent(['a44.incident.opened', 'a44.dr.promoted'], async (e) => {
  const res = await fetch('https://itsm.acme.example/api/incidents', {
    method: 'POST',
    headers: { 'content-type': 'application/json' },
    body: JSON.stringify({
      severity: e.severity,
      summary: e.action + ' em ' + e.tenant + '/' + e.env,
      externalId: e.request_id,       // idempotencia do lado do ITSM
    }),
  });
  if (!res.ok) throw new Error('itsm ' + res.status); // forca retry com backoff
  return { ticket: (await res.json()).id };
});

API

A API administrativa vive em https://api.anthares44.com/v2 com tokens Bearer de vida curta. A44-Org é sempre obrigatório; A44-Tenant, em toda rota de recurso de tenant. Ações de alto impacto retornam 202 Accepted com approval_id e só rodam depois do segundo operador, acompanhadas por polling ou webhook.

Limites por organização: 600 req/min em leitura, 60 em mutação, com Retry-After no 429. Paginação por cursor opaco (page[after]), nunca offset: a trilha cresce durante a leitura e offset duplicaria ou pularia registros. O teto de page[size] é 1000.

TOKEN=$(a44 auth mint --scope admin --ttl 900)

# alto impacto: entra na fila de aprovacao
curl -X POST https://api.anthares44.com/v2/policy/prod/network-egress \
  -H "authorization: Bearer $TOKEN" \
  -H "a44-org: acme" -H "a44-tenant: core" \
  -H "a44-change-ticket: CHG-88104" \
  -H "idempotency-key: 6f0c1a72-2b44-4d1f-9a55-0e2c9b7ad311" \
  -d '{"allow_egress":["203.0.113.0/24"]}'
# HTTP/2 202
# {"approval_id":"apr_01J9KA","expires_in":3600,"approvers_required":1}

# export paginado por cursor
curl -s "https://api.anthares44.com/v2/audit/events?page[size]=1000&page[after]=ev_01J9K7" \
  -H "authorization: Bearer $TOKEN" -H "a44-org: acme" | jq '.meta'

Boas práticas

Duas escolhas definem a maior parte do resultado operacional. A primeira é decidir os pontos conservadores antes do incidente: strict_revocation, sync_degrade, onBufferFull e object_lock.mode são trade-offs entre disponibilidade e controle cujo valor parece óbvio com o sistema calmo e errado às 3 da manhã.

A segunda é tratar evidência como saída de processo, não tarefa trimestral. O dossiê se monta sozinho se os game days rodam com --ticket, se toda mutação passa por a44-change-ticket e se a revisão de acesso é agendada.

# postura: roda em CI e falha o pipeline em desvio
a44 posture check --tenant core --profile enterprise-baseline
# [ok]   rls habilitado em 41/41 tabelas com tenant_id
# [fail] 2 contas de servico com ttl > 3600s (svc-etl, svc-report)
# [fail] janela adiada 2x — proxima nao e adiavel
# exit 1

FAQ

As perguntas que mais aparecem em revisão de arquitetura de segurança antes da assinatura. Onde a resposta é "depende", a variável está explicitada.

Fora desta lista, o canal é o contato técnico do contrato: resposta em 4 h úteis para SEV3 e 15 min para SEV1.

Ver também: custo por ambiente em Startups; SDKs e ambientes efêmeros em Developers.