# Segurança e Criptografia

BackupAlly implementa criptografia de nível enterprise para proteção de dados.

# Modelo de Criptografia

# Envelope Encryption

BackupAlly usa envelope encryption (criptografia em envelope):

┌──────────────────────────────────────────────┐
│              Backup File (.ally)             │
├──────────────────────────────────────────────┤
│  ┌────────────────────────────────────────┐  │
│  │  RSA-4096 encrypted AES-256 key        │  │
│  └────────────────────────────────────────┘  │
│  ┌────────────────────────────────────────┐  │
│  │  AES-256-GCM encrypted data            │  │
│  └────────────────────────────────────────┘  │
└──────────────────────────────────────────────┘

# Por que Envelope Encryption?

1. Performance: AES é muito mais rápido que RSA para dados grandes
2. Segurança: Chave AES diferente a cada backup
3. Flexibilidade: Pode rotacionar chave RSA sem re-criptografar dados

# Algoritmos

# Criptografia Assimétrica

# Criptografia Simétrica

# Integridade

# Modos de Chave

# Default

Usa a mesma chave RSA para todos os backups:

[crypto]
key_mode = "default"
default_key_ref = "/etc/backupally/keys/default.key"

Vantagens:

• Simples de gerenciar
• Uma chave para todos os restores

Desvantagens:

• Comprometimento afeta todos os backups

# Ephemeral

Gera nova chave para cada backup:

[crypto]
key_mode = "ephemeral"

Vantagens:

• Isolamento total entre backups
• Comprometimento afeta apenas um backup

Desvantagens:

• Requer gerenciamento de múltiplas chaves
• Necessita servidor central para recovery

# None

Sem criptografia (não recomendado):

[crypto]
key_mode = "none"

Uso válido:

• Dados públicos
• Ambientes de desenvolvimento
• Storage já criptografado

# Key Fingerprint

Cada backup contém o fingerprint da chave que o criptografou:

Fingerprint = SHA256(public_key)[0:8]

8 bytes que identificam unicamente a chave.

# Verificar Fingerprint

backupally keys fingerprint /etc/backupally/keys/default.key
# Key fingerprint: a1b2c3d4e5f6a7b8

# Uso no Header

O fingerprint está no header do arquivo .ally, permitindo:

• Identificar qual chave usar para restore
• Detectar chave errada antes de tentar descriptografar

# Gerenciamento de Secrets

# Armazenamento

Secrets são armazenados em /etc/backupally/secrets.db:

• SQLite criptografado
• Chave derivada da chave mestra
• Permissões 0600

# Uso em Configuração

password = "${secret:mysql_password}"
api_key = "${secret:aws_key}"

# Proteção

• Secrets nunca aparecem em logs
• Valores descriptografados apenas em memória
• Memória zerada após uso (zeroize)

# Servidor Central

Para disaster recovery, registre chaves no servidor central:

[central]
enabled = true
server_url = "https://central.backupally.io"
api_key = "seu-api-key"
auto_sync = true

# Recuperação

backupally keys recover \
  --fingerprint a1b2c3d4e5f6a7b8 \
  --server https://central.backupally.io \
  --api-key your-key

# Boas Práticas

# Chaves

1. Backup offline: Mantenha cópia em local seguro
2. Anote fingerprints: Para recovery
3. Rotação periódica: A cada 6-12 meses
4. Permissões: 0600 em arquivos de chave

# Secrets

1. Nunca em código: Use ${secret:name}
2. Rotação: Atualize periodicamente
3. Mínimo privilégio: Usuários de backup com acesso limitado

# Storage

1. Criptografia em trânsito: HTTPS sempre
2. Criptografia em repouso: S3 SSE, B2 SSE
3. Acesso restrito: IAM policies específicas

# Verificação de Integridade

# Pós-Backup

[global]
backup_verification = true

Após upload, BackupAlly:

1. Download parcial do arquivo
2. Verifica header e checksum
3. Confirma integridade

# Pré-Restore

backupally restore --verify --target mysql-prod --snapshot snap_xxx

Verifica:

1. Checksum do arquivo
2. GCM tag (autenticação)
3. Fingerprint da chave