Criptografar o disco dos modelos

#O que a criptografia de disco protege e o que ela não protege

A criptografia em repouso torna o conteúdo de um disco ilegível sem a chave: alguém que rouba o notebook, retira o SSD ou apreende um computador desligado só consegue recuperar dados inutilizáveis. Esse é o cenário que ela cobre, e não abrange outros: um computador ligado e desbloqueado, um software malicioso rodando na sua sessão ou uma senha fraca continuam sendo vias de acesso. No plano regulatório, o artigo 32 do RGPD menciona a pseudonimização e a criptografia de dados pessoais entre as medidas técnicas que o responsável pelo tratamento deve considerar conforme o risco; ele não prescreve uma ferramenta específica, e a exigência depende do contexto (saúde, finanças).

#O que deve ser criptografado: os pesos não são o segredo

Os modelos baixados do Ollama ou do Hugging Face são públicos: os pesos de um modelo open-weight não têm nada de confidencial, a menos que você tenha feito fine-tuning de um modelo com dados privados. O que é confidencial é tudo o que o uso produz. Criptografar apenas a pasta dos modelos deixa, portanto, o essencial exposto.

Histórico de conversas

O terminal do Ollama registra o histórico das entradas no diretório .ollama do seu perfil (o código do Ollama compõe o caminho .ollama/history); as interfaces web como Open WebUI mantêm suas conversas em suas próprias bases de dados.

Índice de documentos

Uma base ChromaDB, Qdrant ou Weaviate contém seus trechos de documentos, legíveis exatamente como estão: é uma cópia dos seus arquivos.

Documentos de origem e exportações

Os PDFs depositados na pasta do RAG, as transcrições, as saídas gravadas.

Arquivo de troca e hibernação

Quando a memória está cheia, o sistema grava páginas no disco: elas podem conter trechos das suas conversas. A documentação do Arch Linux destaca que um swap criptografado, redefinido a cada inicialização, oferece melhor proteção, pois evita fragmentos sensíveis que nunca são sobrescritos.

Logs e cópias temporárias

Logs do servidor, arquivos de cache, editores que criam cópias.

Disso decorrem duas estratégias. A mais simples e segura é criptografar todo o disco do sistema, o que cobre tudo em uma única operação. A segunda, quando não é possível modificar o sistema, é criptografar um volume dedicado que contém os dados (índices, documentos, modelos com ajuste fino) e mover para ele as pastas que armazenam esses dados.

#macOS: FileVault

Em um Mac com chip Apple ou com chip de segurança T2, a documentação da Apple esclarece que os dados são criptografados automaticamente: a ativação do FileVault adiciona uma camada de proteção, condicionando o acesso aos dados à digitação da senha de login. Em um Mac Intel sem chip T2, é necessário ativar o FileVault para criptografar os dados. A documentação técnica descreve o FileVault como um sistema que utiliza o algoritmo AES-XTS para proteger volumes inteiros, com o apoio do mecanismo AES em hardware e do Secure Enclave dos Macs recentes.

1. 01
   Abrir as configurações

   Menu Apple, Ajustes do Sistema, Privacidade e Segurança, depois FileVault.
2. 02
   Ativar o FileVault

   Clique em Ativar; o macOS oferece duas formas de recuperação.
3. 03
   Escolher o método de recuperação

   A conta iCloud é prática, sem chave separada para guardar; a chave de recuperação é uma sequência de caracteres para anotar e guardar em outro local, diferente do Mac. Para dados sensíveis, prefira a chave de recuperação.
4. 04
   Deixar o Mac trabalhando

   A criptografia continua em segundo plano; você pode continuar usando a máquina.

fdesetup status
# doit répondre : FileVault is On.

#Windows: BitLocker e criptografia do dispositivo

BitLocker é a função de criptografia de volume do Windows. De acordo com a documentação da Microsoft, sua ativação é possível no Windows Pro, Enterprise, Pro Education/SE e Education. O Windows Home não oferece acesso a essa função, mas conta com a criptografia do dispositivo (device encryption), que ativa o BitLocker automaticamente em máquinas elegíveis; desde o Windows 11 24H2, os pré-requisitos de hardware foram reduzidos, o que torna mais máquinas elegíveis.

Um detalhe importante: a criptografia automática do dispositivo só é ativada após o login com uma conta Microsoft ou uma conta profissional, e a chave de recuperação é então salva nessa conta (ela fica disponível em aka.ms/myrecoverykey). Com uma conta local, a criptografia não é ativada automaticamente, mas é possível ativar o BitLocker manualmente em uma edição que permita isso. Para dados muito sensíveis, decida conscientemente onde a chave fica armazenada: uma conta online é prática em caso de perda, mas a chave deixa de ficar exclusivamente com você.

1. 01
   Abrir o BitLocker

   Procure 'Gerenciar BitLocker' no menu Iniciar (edições Pro e superiores).
2. 02
   Ativar na unidade do sistema

   Escolha o desbloqueio por TPM; adicione um código PIN na inicialização para se proteger contra a inicialização direta da máquina roubada.
3. 03
   Salvar a chave de recuperação

   Salve-a em um cofre ou imprima-a; evite deixá-la apenas na máquina.
4. 04
   Escolher a abrangência do criptografamento

   Em um PC novo, basta criptografar o espaço utilizado; em um PC que já foi usado, prefira a criptografia completa, que também cobre o espaço livre onde ainda restam dados antigos.

#Linux: LUKS para o disco inteiro

LUKS é o padrão de criptografia de disco no Linux, gerenciado pelo utilitário cryptsetup. De acordo com sua página de manual, o formato padrão é o LUKS2. A forma mais simples é escolher essa opção durante a instalação: o Ubuntu, o Fedora e as outras distribuições oferecem uma caixa de seleção “criptografar a nova instalação” que solicita uma senha. O disco inteiro do sistema, incluindo o arquivo de troca, fica então protegido. Depois, é possível verificar com cryptsetup status usando o nome do volume aberto ou com lsblk -f, que indica o tipo crypto_LUKS.

#Linux: criptografar apenas um disco de dados e colocar o Ollama nele

Um caso comum é o de um sistema não criptografado e um segundo SSD reservado para os dados da IA. Esse segundo disco é criptografado com LUKS; depois, as pastas dos modelos e do índice são movidas para ele. A documentação do Ollama indica que o local dos modelos é definido pela variável OLLAMA_MODELS e que, com o instalador padrão no Linux, o usuário ollama deve ter acesso de leitura e escrita à pasta escolhida.

lsblk                                 # identifiez le bon disque ; ici /dev/sdb
sudo cryptsetup luksFormat /dev/sdb   # crée le volume LUKS et demande un mot de passe
sudo cryptsetup open /dev/sdb models   # ouvre : /dev/mapper/models
sudo mkfs.ext4 /dev/mapper/models
sudo mkdir -p /mnt/models
sudo mount /dev/mapper/models /mnt/models
sudo mkdir /mnt/models/ollama
sudo chown -R ollama:ollama /mnt/models/ollama

[Unit]
RequiresMountsFor=/mnt/models

[Service]
Environment="OLLAMA_MODELS=/mnt/models/ollama"

A linha RequiresMountsFor indica ao systemd que o serviço deve iniciar apenas após o volume ser montado: sem ela, Ollama pode iniciar antes do desbloqueio, criar um diretório vazio no disco não criptografado e baixar novamente os modelos nesse local. Após a modificação, execute sudo systemctl restart ollama.

#Senha ou arquivo de chave: a armadilha do arquivo no disco do sistema

Para abrir o volume na inicialização, existem duas abordagens. Com uma senha, o sistema a solicita a cada inicialização (entrada no crypttab com a chave "none"). Com um arquivo de chave, a abertura é automática, mas tudo depende de onde o arquivo está armazenado. Colocar a chave em /root/ em um sistema não criptografado anula quase totalmente a proteção: qualquer pessoa que roube a máquina pode ler o arquivo de chave no disco do sistema e depois abrir o volume. O arquivo de chave só faz sentido se o próprio disco que o contém estiver criptografado. Em um servidor sem tela, a solução de compromisso habitual é um sistema criptografado desbloqueado remotamente ou um desbloqueio manual após cada reinicialização.

models  /dev/sdb  none  luks

# /etc/fstab
/dev/mapper/models  /mnt/models  ext4  defaults  0  2

A criptografia adiciona um custo computacional a cada leitura e escrita. Para um LLM, a leitura dos pesos ocorre principalmente durante o carregamento do modelo: o efeito é mais visível no tempo de carregamento, não nos tokens gerados. Meça a taxa de processamento da criptografia do seu processador com cryptsetup benchmark e compare o tempo de carregamento de um modelo antes e depois; não se baseie em um número genérico.

#NAS e backups: não desfazer a criptografia

NAS

Verifique se as pastas compartilhadas que contêm modelos ou backups estão criptografadas e onde fica a chave. Um NAS que desbloqueia seu volume automaticamente ao iniciar protege contra o roubo apenas do disco, mas não contra o roubo do dispositivo inteiro.

Disco de backup

Um disco USB de backup sem criptografia anula a criptografia do computador: criptografe-o com a mesma ferramenta ou use um software de backup que criptografe os dados antes da gravação.

Backup na nuvem

Certifique-se de que a criptografia seja feita no seu ambiente, com uma chave que só você possui: caso contrário, o fornecedor pode tecnicamente ler seus arquivos.

Chave de recuperação

Sempre separe a chave do backup que ela protege: dois locais distintos.

#Perguntas frequentes sobre criptografia do disco dos modelos

• Checklist de privacidade
• Isolar a máquina com air gap
• IA local em empresas: RGPD, soberania e implantação
• Jurista: analisar um contrato sem vazamento
• Compartilhar Ollama em sua rede local

• Fonte: Apple, FileVault
• Fonte: Microsoft, BitLocker
• Fonte: página do manual de cryptsetup
• Fonte: FAQ do Ollama, localização dos modelos