Integracoes

O Implant e autossuficiente: um binario estatico que verifica, corrige e opera o servidor localmente. Nao precisa de servidor central, conta, banco de dados nem agente. Tudo o que esta nesta pagina e opcional.

Sem dependencias externas

Aspecto Como funciona
Execucao Local, como root, a partir do binario
Estado Arquivos locais (/var/lib/implant/, /etc/protocolo-implant/)
Saida stdout (human, json, yaml); nada e enviado para fora
Rede Somente para baixar pacotes da distro, o proprio update e componentes que voce pedir

Componentes opcionais (`implant install`)

O comando `install` instala aplicacoes complementares. Nenhuma e necessaria para o Implant funcionar.

Opcao O que instala
node Node.js via NVM
claude-code Claude Code CLI (requer Node.js)
sysinfo Monitoramento de sistema
backupally Sistema de backup
container Runtime de containers
deployally Gerenciamento de deploys
runner Execucao de CI/CD

Os binarios sao baixados com as mesmas protecoes do proprio Implant (TLS pinning nos dominios oficiais e assinatura minisign obrigatoria em host sem pin). O destino de cada app pode ser trocado em [endpoints.apps] no config.toml.

Com implant check, o modulo de apps apenas compara a versao instalada com a publicada; o download so acontece com --auto-fix ou install.

Gerenciamento remoto (opcional)

O Implant pode ser operado por um agente de gerenciamento remoto que roda no servidor e conversa com um console. Nesse arranjo:

  • O agente chama o Implant localmente e coleta a saida estruturada (-o json); o Implant nao fala com o console diretamente.
  • Comandos com recuperacao automatica (ssh-service, lockdown, emergency-mode, firewall-restore --confirm-timeout) foram desenhados para esse cenario: o console aplica a restricao, o agente envia heartbeats ou a confirmacao, e se o canal cair o servidor volta sozinho ao estado seguro. Veja Lockdown / Deadman.
  • implant agent --install | --configure | --status instala e verifica um agent de controle remoto (veja agent).

Sem agente, os mesmos comandos funcionam manualmente pela linha de comando.

Claude Code (opcional)

Para servidores operados com o Claude Code:

Passo Comando
Node.js + Claude Code implant install node, implant install claude-code (ou check --install-node --install-claude-code)
Usuario dedicado com ACL e sudoers restrito `implant setup-claude-code`
Guard-rail (CLAUDE.md com regras de operacao) `implant update-guardrail`

O guard-rail so e baixado por HTTPS, do host configurado em [endpoints], com verificacao de pin.

Fluxo Tipico

Provisionar novo servidor

1. curl -sL https://implant.ccs.systems/init.sh | sudo bash
2. implant check                      (diagnostico, somente leitura)
3. implant check --auto-fix --dry-run (preview)
4. implant check --auto-fix
5. implant ssh-port 2222              (opcional, com watchdog)
6. implant install <app>              (opcional)

Manter conformidade

1. implant self-update
2. implant check
3. implant check --auto-fix           (quando houver Fail)

Gerenciamento de SSH

1. implant ssh-key --add-public-key "ssh-ed25519 AAAA... usuario"
2. implant ssh-port 2222              (alterar porta com watchdog)
3. implant ssh-port --confirm-change  (confirmar)
4. implant ssh-rollback               (reverter se necessario)

Infraestrutura propria

Os endpoints padrao apontam para a distribuicao oficial. Para usar outra infraestrutura, sem recompilar, configure em /etc/protocolo-implant/config.toml:

[endpoints]
cdn_base       = "https://cdn.exemplo.com"
guardrail_base = "https://cdn.exemplo.com/claudecode/"

[endpoints.apps.runner]
url  = "https://cdn.exemplo.com/{arch}/runner"
path = "/opt/runner/runner"

# Opcional: pin SPKI do seu host
[[tls_pins]]
host = "cdn.exemplo.com"
pin  = "sha256/SEU_HASH_BASE64="

O config.toml precisa ser completo (as demais secoes sao obrigatorias); veja o MANUAL do Implant. O placeholder {arch} vira x86_64 ou aarch64 em runtime. Hosts sem pin usam validacao WebPKI padrao e exigem .minisig valida para binarios.

Seguranca dos Downloads

TLS Pinning

Os pins SPKI dos dominios oficiais de distribuicao sao extraidos em tempo de compilacao e embutidos no binario. O cliente HTTP do Implant usa rustls com esses pins (e com os de [[tls_pins]]) para validar o certificado antes de qualquer download. Isso protege contra MITM mesmo que uma autoridade certificadora seja comprometida.

Assinatura minisign

Cada release publica implant.minisig (Ed25519) ao lado do binario.

Origem do download .minisig ausente .minisig invalida
Dominio com pin embutido (distribuicao oficial) segue, com warn aborta
Qualquer outro host (--url, CDN proprio) aborta aborta
init.sh aborta aborta
┌─────────────────────────────────────────────────────────┐
│                 FLUXO DE DOWNLOAD SEGURO                 │
│                                                          │
│   1. Exigir HTTPS                                        │
│   2. Estabelecer conexao TLS                             │
│   3. Verificar pin SPKI (embutido ou [[tls_pins]])       │
│      - sem pin conhecido: validacao WebPKI               │
│   4. Pin divergente: BLOQUEAR conexao                    │
│   5. Baixar binario e .minisig                           │
│   6. Verificar assinatura Ed25519                        │
│   7. Troca atomica do binario, com backup                │
│                                                          │
└─────────────────────────────────────────────────────────┘

Verificacao manual:

minisign -Vm implant -P "$(curl -s https://implant.ccs.systems/pubkey.pub | tail -1)"

Compatibilidade de Arquiteturas

O instalador (init.sh) detecta a arquitetura automaticamente:

ARCH=$(uname -m)
# x86_64 / amd64  → /x86_64/implant
# aarch64 / arm64 → /aarch64/implant
# outras          → instalacao recusada

Clientes antigos que acessam a URL sem prefixo de arquitetura (https://implant.ccs.systems/implant) continuam funcionando: o arquivo na raiz e uma copia do x86_64.