← Parte anterior: Volume I — Parte 2 — Sistemas Operacionais, Redes, Internet, APIs e Banco de Dados

Parte 3 — Representação da Informação, Arquitetura de Computadores, Sistemas de Arquivos, Virtualização, Cloud Computing e Introdução à Segurança da Informação

Foco: compreender como dados se tornam estados físicos, instruções, arquivos, workloads virtualizados, serviços de nuvem e ativos protegidos.
Abordagem: fundamentos rigorosos, comparação entre tecnologias, diagnóstico orientado por evidências, arquitetura aplicada, segurança por desenho, notas Zettelkasten e exercícios.

Sumário

• Prefácio — Da informação ao risco
• Como estudar esta parte
• Mapa sistêmico
• Capítulo 10 — Representação da Informação
• Capítulo 11 — Arquitetura de Computadores
• Capítulo 12 — Sistemas de Arquivos
• Capítulo 13 — Virtualização, Containers e Orquestração
• Capítulo 14 — Computação em Nuvem
• Capítulo 15 — Introdução à Segurança da Informação
• Estudo de caso integrado
• Laboratório prático
• Exercícios
• Projeto final
• Glossário
• Referências
• Encerramento

Prefácio — Da informação ao risco

Um usuário envia um PDF para uma plataforma de conhecimento. A interface informa que o upload terminou, mas o documento não aparece na pesquisa. É tentador chamar isso de “erro da IA”. A cadeia real pode conter outra história: o nome foi normalizado de forma diferente; o arquivo excedeu o limite do proxy; o container gravou na camada efêmera; o worker ficou sem memória; o volume foi montado com proprietário incorreto; o texto extraído usou codificação inadequada; o modelo não recebeu os trechos; ou uma política de segurança bloqueou o processamento.

Cada hipótese pertence a uma abstração diferente, mas todas podem produzir o mesmo sintoma.

Esta parte percorre a infraestrutura de baixo para cima. Primeiro, a informação é representada em bits e codificações. Depois, a arquitetura executa instruções e movimenta dados entre registradores, caches, memória e armazenamento. O sistema de arquivos atribui nomes, metadados, permissões e persistência. Virtualização e containers criam fronteiras operacionais. A nuvem transforma recursos em serviços elásticos e medidos. Segurança governa quem pode fazer o quê, sob quais condições e com qual evidência.

O objetivo não é formar um especialista isolado em hardware, storage, Kubernetes ou cibersegurança dentro de um único artigo. É construir o modelo mental que permite ao Analista de Sistemas tomar decisões e investigar problemas sem confundir camadas.

Ao concluir esta parte, você deverá ser capaz de:

• distinguir bit, byte, code point, code unit, caractere percebido e codificação;
• explicar números inteiros, ponto flutuante, endianness e representação multimídia;
• relacionar ISA, microarquitetura, CPU, cache, RAM, NUMA e armazenamento;
• analisar latência, throughput, IOPS e concorrência sem reduzi-los a uma única métrica;
• explicar caminhos, inodes, links, permissões, journaling, copy-on-write e durabilidade;
• comparar bare metal, VM, emulação, container e orquestração;
• separar imagem imutável, container executável e dados persistentes;
• reconhecer as características que diferenciam cloud de simples hospedagem;
• comparar IaaS, PaaS, SaaS, CaaS e FaaS com responsabilidades reais;
• aplicar identidade, mínimo privilégio, criptografia, gestão de vulnerabilidades e resposta a incidentes;
• integrar LGPD, segurança de uploads e riscos de RAG/IA ao desenho técnico;
• produzir uma arquitetura com critérios mensuráveis de disponibilidade, recuperação, custo e segurança.

Como estudar esta parte

Use três ciclos, em vez de uma leitura contínua:

1. Construa o modelo: leia uma seção e desenhe as relações sem copiar o texto.
2. Teste a transferência: aplique o conceito a um sistema real — GLPI, Flask, Docker, banco, servidor de arquivos ou pipeline RAG.
3. Recupere sem consulta: responda às perguntas do capítulo e explique um incidente com suas próprias palavras.

Uma nota Zettelkasten útil registra uma ideia, um exemplo próprio, uma fonte e conexões. A numeração continua a Parte 2, encerrada em ZK-035.

Exemplo:

ZK-036 — Representação não é significado

Ideia:
Os mesmos bytes podem ser interpretados de maneiras diferentes conforme codificação,
tipo, ordem, schema e contexto. Persistir bytes não preserva significado sozinho.

Exemplo próprio:
Um nome em UTF-8 pode parecer igual na tela e ainda possuir sequências normalizadas
diferentes, afetando busca, comparação e assinatura.

Conexões:
- ZK-037 — Precisão numérica
- ZK-042 — Arquivo, nome e objeto
- ZK-054 — Integridade e autenticidade

Mapa sistêmico

flowchart TB
    A["Informação"] --> B["Representação em bytes"]
    B --> C["CPU e memória"]
    C --> D["Arquivo e armazenamento"]
    D --> E["VM ou container"]
    E --> F["Serviço em cloud"]
    F --> G["Controles de segurança"]

Capítulo 10 — Representação da Informação

Objetivos de aprendizagem

Ao final deste capítulo, você deverá conseguir:

• explicar bit como unidade abstrata e não como um componente físico específico;
• converter valores entre binário, decimal e hexadecimal;
• diferenciar inteiro com sinal, ponto flutuante e decimal exato;
• distinguir caractere, code point, code unit, grapheme cluster e byte;
• explicar tamanho e qualidade de imagem, áudio e vídeo;
• separar codificação, compressão, hash, MAC, assinatura e criptografia;
• diagnosticar um arquivo por formato declarado, conteúdo e integridade.

10.1 O computador manipula estados; pessoas atribuem significado

Um bit possui dois valores possíveis. Esses valores podem ser implementados por níveis de tensão, carga elétrica, orientação magnética, estado óptico ou outra distinção física. O bit é uma abstração: não significa, por si só, verdadeiro, letra, cor ou número.

O significado aparece quando um sistema adota uma convenção. A sequência 01000001 pode representar:

• o inteiro decimal 65;
• a letra A em ASCII e UTF-8;
• oito flags booleanas;
• parte de uma instrução;
• uma intensidade em um canal de imagem;
• um fragmento sem sentido se lido fora do formato.

Essa é a primeira tese do capítulo: bytes preservam estados; schemas, codificações e protocolos preservam interpretação. Claude Shannon formalizou a informação em termos de escolhas possíveis e incerteza, separando a medida da informação de seu significado semântico [1].

Com n bits existem 2^n combinações:

Oito bits fornecem 256 padrões. Atribuir 0 a 255, -128 a 127 ou caracteres a esses padrões é uma decisão de representação.

10.2 Bit, byte, palavra e alinhamento

Um byte possui oito bits no uso computacional contemporâneo. Uma palavra de máquina é uma unidade natural da arquitetura, frequentemente relacionada aos registradores e à ISA, mas não deve ser usada como sinônimo de byte. Em arquiteturas de 64 bits, registradores gerais podem ter 64 bits enquanto instruções ainda operam com bytes, 16, 32 ou 64 bits.

Estruturas podem conter padding para respeitar alinhamento:

struct exemplo {
    char ativo;   /* 1 byte */
    int  codigo;  /* 4 bytes, frequentemente alinhado */
};

Somar os campos sugere cinco bytes, mas o compilador pode alocar oito. Serializar a memória bruta dessa estrutura é frágil: padding, endianness, ABI e compilador podem variar. Formatos de intercâmbio devem definir layout explicitamente.

10.3 Sistemas binário, decimal e hexadecimal

O valor binário 101101₂ é:

Hexadecimal agrupa quatro bits por dígito:

binário:      1010 1111
hexadecimal:     A    F
decimal:             175

Ele aparece em endereços, dumps, cores, hashes e permissões porque representa bits de forma compacta. 0xFF não é um “tipo hexadecimal”; é uma notação para o valor 255.

10.4 Inteiros com sinal e complemento de dois

Processadores modernos representam inteiros com sinal, em geral, por complemento de dois. Em oito bits:

 5 = 00000101
-5 = 11111011

O bit mais significativo participa do valor; não é apenas uma etiqueta de sinal isolada. Se x é um inteiro assinado representado com n bits, sua faixa é:

Em notação de leitura direta: mínimo = -(2^(n-1)) e máximo = 2^(n-1) - 1.

Logo, um inteiro assinado de oito bits vai de -128 a 127. Ultrapassar a faixa produz overflow, cujo comportamento depende da linguagem e do tipo. Validar limites é requisito de correção e segurança.

10.5 Ponto flutuante não representa todos os decimais

Ponto flutuante representa números aproximadamente por sinal, expoente e significando. O padrão IEEE 754 define formatos e operações amplamente utilizados [5]. Assim como 1/3 não termina em decimal, 0,1 não possui representação binária finita comum.

Em muitas linguagens:

0.1 + 0.2 == 0.3  # pode resultar False

Isso não é defeito do Python nem da CPU. É consequência da aproximação.

Para R$ 19,90, usar 1990 centavos ou tipo decimal é mais seguro que presumir exatidão binária. Comparações de floats costumam usar tolerância adequada ao domínio.

10.6 Endianness e ordem dos bytes

Um valor de vários bytes pode ser armazenado do menos significativo para o mais significativo (little-endian) ou no sentido oposto (big-endian). O valor 0x12345678 pode aparecer em memória como:

little-endian: 78 56 34 12
big-endian:    12 34 56 78

Protocolos e formatos devem especificar uma ordem. Ler bytes de uma arquitetura como se estivessem na outra altera o valor. Endianness não muda a ordem de bits escrita visualmente dentro de cada byte; trata da ordem das unidades na representação multibyte.

10.7 Unidades: MB não é MiB

Prefixos SI são decimais; prefixos binários são potências de dois [4]:

Fabricantes de discos geralmente usam decimal; sistemas podem exibir binário com rótulo ambíguo. Além disso, capacidade formatada perde espaço para metadados, reserva e estruturas do sistema de arquivos. A diferença não indica defeito.

Bits por segundo (Mb/s) e bytes por segundo (MB/s) também não são equivalentes. Em condições ideais, 100 Mb/s correspondem a 12,5 MB/s antes de overheads.

10.8 ASCII, Unicode e UTF-8

ASCII é um conjunto histórico de 128 códigos de sete bits para letras latinas básicas, números, pontuação e controle. Ele não representa adequadamente português, árabe, japonês ou a diversidade de símbolos modernos.

Unicode separa conceitos:

• caractere abstrato: unidade textual definida pelo padrão;
• code point: posição como U+0041 para A;
• code unit: unidade usada por uma forma de codificação;
• encoding form: mapeamento para unidades de 8, 16 ou 32 bits;
• grapheme cluster: sequência que o usuário percebe como uma unidade.

UTF-8 usa de um a quatro bytes por valor escalar Unicode; UTF-16 usa uma ou duas unidades de 16 bits; UTF-32 usa uma unidade de 32 bits [2]. Portanto, “um caractere = um byte” e “um caractere = um code point” são suposições incorretas.

Um emoji com tom de pele, uma bandeira ou uma letra com acento combinante pode usar vários code points e ainda aparecer como um único grafema. O algoritmo de segmentação do Unicode define limites de grapheme clusters para operações como cursor e quebra de texto [3].

Normalização

é pode ser representado como um code point precomposto ou como e seguido de acento combinante. As sequências podem parecer iguais e comparar como diferentes byte a byte. Formas NFC, NFD, NFKC e NFKD atendem propósitos distintos; normalizar sem entender compatibilidade pode mudar significado.

Exemplo corporativo: dois nomes visualmente iguais podem gerar falha de busca, chave duplicada aparente ou hash diferente. A solução não é remover acentos indiscriminadamente. Defina normalização, collation e comparação conforme o domínio, preservando o original quando necessário.

10.9 Texto, schema e banco de dados

Uma cadeia correta depende de coerência:

entrada → biblioteca → API → driver → coluna → consulta → saída

Se um componente trata bytes UTF-8 como Latin-1, João pode virar texto corrompido. Regravar o resultado danificado não recupera necessariamente os bytes originais.

Banco e aplicação também precisam concordar sobre:

• charset e collation;
• sensibilidade a maiúsculas e acentos;
• normalização;
• limite em bytes, code points ou grafemas;
• ordenação linguística;
• formato de data e fuso.

VARCHAR(50) não garante que a interface aceite cinquenta símbolos percebidos. O limite deve refletir a regra de negócio e o comportamento do SGBD.

10.10 Imagens digitais

Uma imagem raster é uma matriz de pixels. Em bytes, o tamanho bruto aproximado sem compressão é:

Nessa expressão, L é a largura em pixels, A é a altura, C é a quantidade de canais e b é o número de bits por canal.

Uma imagem 1920 × 1080, RGB, com oito bits por canal requer aproximadamente 6,22 MB decimais por quadro antes de metadados e compressão.

Qualidade não depende apenas de resolução:

• bit depth: níveis possíveis por canal;
• espaço de cor: interpretação numérica das cores, como sRGB;
• alpha: transparência;
• compressão: perda ou preservação de informação;
• amostragem e processamento: origem e transformações;
• metadados: orientação, câmera, perfil e localização.

Extensão não prova formato. Validar upload exige assinatura do arquivo, parser seguro, limites e política de conteúdo.

10.11 Áudio digital

Áudio digital amostra uma onda ao longo do tempo. Três dimensões principais:

• taxa de amostragem, como 48 kHz;
• profundidade por amostra, como 16 ou 24 bits;
• número de canais.

Tamanho PCM aproximado, em bytes:

Nessa expressão, f_s é a taxa de amostragem, b é a profundidade em bits, c é a quantidade de canais e d é a duração em segundos.

Um minuto estéreo, 48 kHz, 16 bits, sem compressão ocupa cerca de 11,52 MB. FLAC comprime sem perdas; AAC, Opus e MP3 removem informação segundo modelos perceptuais. Bitrate, codec e container são conceitos separados.

10.12 Vídeo: sequência, compressão e container

Vídeo combina quadros, áudio, temporização e metadados. Armazenar cada quadro bruto seria caro, por isso codecs exploram redundância dentro do quadro e entre quadros. Um grupo de imagens pode conter quadros completos e quadros dependentes.

Um arquivo .mp4 pode usar codecs diferentes. Dizer “o formato é MP4” não informa toda a compatibilidade. Transcodificação altera custo, qualidade e tempo de processamento.

10.13 Codificação, compressão, hash e criptografia

Esses mecanismos resolvem problemas diferentes:

Base64 não protege segredo; apenas representa bytes em caracteres e aumenta o tamanho. A RFC 4648 padroniza Base16, Base32 e Base64 [6].

Um hash permite detectar alteração quando comparado a um valor confiável, mas não prova autoria sozinho. Se invasor modifica arquivo e hash no mesmo local, a verificação passa. HMAC ou assinatura cria autenticidade sob um modelo de chaves.

Senhas não devem usar hash rápido genérico. Algoritmos deliberadamente caros e com salt, como Argon2id, serão tratados no Capítulo 15.

10.14 Estudo de caso: PDF aceito, mas não processado

Sintoma

A API devolve 201, mas o PDF não entra no índice RAG.

Cadeia de hipóteses

Pipeline robusto

1. limitar tamanho antes e durante a leitura;
2. gerar identificador interno, sem usar nome enviado como caminho;
3. armazenar bytes originais fora da raiz executável;
4. calcular hash e registrar tamanho;
5. validar assinatura, estrutura e política de conteúdo;
6. colocar trabalho em fila durável;
7. extrair texto em processo isolado com limites;
8. aplicar OCR apenas quando necessário;
9. normalizar para a finalidade definida, preservando o original;
10. versionar parser, chunker e embedding;
11. publicar estado recebido, validando, processando, indexado ou falhou;
12. permitir reprocessamento idempotente.

Responder 201 pode significar “recurso de processamento criado”, não “indexação concluída”. O contrato deve deixar isso claro.

10.15 Síntese do capítulo

• O bit é uma escolha binária abstrata; contexto atribui significado.
• Word size, alinhamento e endianness afetam layout, não devem vazar para contratos.
• Ponto flutuante aproxima muitos decimais; dinheiro exige representação consciente.
• Unicode separa code point, code unit, bytes e grafemas.
• Codec e container, extensão e conteúdo, hash e autenticidade são pares distintos.
• Upload seguro exige validação, isolamento, limites e estados observáveis.

Notas Zettelkasten — Capítulo 10

ZK-036 — Representação não é significado
Ideia: bytes dependem de tipo, codificação, ordem e schema para serem interpretados.
Conexões: ZK-037 — Precisão numérica; ZK-038 — Texto como sequência.

ZK-037 — Precisão numérica
Ideia: ponto flutuante aproxima; inteiro e decimal também possuem limites e escala.
Conexões: ZK-036 — Representação; ZK-049 — Custo medido.

ZK-038 — Texto como sequência
Ideia: byte, code unit, code point e grafema são unidades diferentes.
Conexões: ZK-036 — Representação; ZK-056 — Proteção de dados.

ZK-039 — Integridade precisa de uma âncora
Ideia: hash detecta diferença apenas quando o valor de comparação é confiável;
autenticidade requer chave, assinatura, MAC ou canal confiável.
Conexões: ZK-054 — Criptografia aplicada; ZK-057 — Cadeia de suprimentos.

Recuperação ativa — Capítulo 10

1. Como os mesmos oito bits podem representar uma letra e um número?
2. Por que 0,1 + 0,2 pode não ser exatamente 0,3?
3. Qual é a diferença entre MB e MiB?
4. Por que um símbolo visível pode ocupar vários code points?
5. O que normalização Unicode resolve e que risco cria quando mal aplicada?
6. Diferencie codec, container, resolução e bitrate.
7. Por que Base64 não é criptografia?
8. O que um SHA-256 confirma e o que não confirma sozinho?

Capítulo 11 — Arquitetura de Computadores

Objetivos de aprendizagem

Ao final deste capítulo, você deverá conseguir:

• separar ISA, microarquitetura e implementação física;
• explicar o ciclo lógico de instrução sem confundi-lo com execução serial real;
• relacionar pipeline, previsão, cache, RAM, NUMA e armazenamento;
• distinguir latência, throughput, IOPS e largura de banda;
• aplicar a Lei de Amdahl a paralelismo e escala;
• diagnosticar gargalos com métricas por recurso e por operação.

11.1 Arquitetura é um contrato entre software e máquina

A Instruction Set Architecture — ISA — define a interface visível ao software: instruções, registradores, tipos, modos de endereçamento, exceções e modelo de memória. x86-64, ARMv8-A e RISC-V são famílias de ISA. A microarquitetura é a forma como um processador implementa esse contrato: pipeline, unidades de execução, caches, buffers e previsão.

Dois processadores podem executar a mesma ISA e possuir desempenho, consumo e organização interna diferentes. Por isso, “programa para 64 bits” descreve compatibilidade arquitetural; não identifica geração, quantidade de cache ou velocidade.

Livros de Patterson e Hennessy tratam essa divisão entre interface e implementação como fundamento da análise quantitativa de computadores [7]. Tanenbaum oferece uma leitura complementar por níveis de organização [8].

11.2 Von Neumann, Harvard e sistemas reais

O modelo de programa armazenado associado a von Neumann coloca instruções e dados em uma memória endereçável e permite que a CPU busque ambos. Em uma arquitetura Harvard, instruções e dados possuem caminhos ou memórias separados.

Processadores modernos combinam ideias. Podem apresentar um espaço de endereçamento unificado ao software e caches separados para instruções e dados. Assim, classificar qualquer máquina real em uma única caixa pode esconder detalhes úteis.

O chamado “gargalo de von Neumann” descreve a limitação de mover instruções e dados entre processamento e memória. Caches, prefetch, pipelines, execução fora de ordem e paralelismo reduzem parte do custo, mas não o eliminam.

11.3 CPU: mais do que clock e núcleos

Uma CPU contém, de forma simplificada:

• unidades que buscam e decodificam instruções;
• registradores;
• unidades aritméticas, lógicas, vetoriais e de ponto flutuante;
• mecanismos de controle e previsão;
• caches e tradução de endereços;
• interconexões com memória e dispositivos.

GHz mede ciclos por segundo, não trabalho útil por ciclo. Desempenho depende de instruções por ciclo, dependências, misses de cache, desvios, largura do pipeline, ISA, compilador, frequência sustentada e limites térmicos.

Uma aproximação:

Nessa expressão, I é a quantidade de instruções executadas, CPI é a média de ciclos por instrução e f é a frequência de operação em ciclos por segundo.

Os fatores não são constantes: o mesmo código pode ter comportamento diferente com dados, cache e concorrência distintos.

11.4 Ciclo de instrução e pipeline

O modelo didático usa:

1. buscar instrução;
2. decodificar;
3. obter operandos;
4. executar;
5. acessar memória quando necessário;
6. escrever resultado.

Isso explica dependências, mas não significa que uma CPU moderna conclua uma instrução inteira antes de iniciar a próxima. Pipelines sobrepõem fases; execução fora de ordem adianta instruções independentes; a aposentadoria preserva o estado arquitetural esperado.

Desvios condicionais criam incerteza. O processador prevê o caminho e pode executar especulativamente. Se erra, descarta trabalho e paga penalidade. Especulação aumenta desempenho e também amplia a superfície de canais laterais, motivo pelo qual microcódigo, compilador e sistema operacional participam da segurança.

11.5 Registradores, contexto e privilégio

Registradores mantêm operandos e estado muito próximos das unidades de execução. Há registradores gerais, contador de programa, flags, registradores vetoriais e estruturas de controle.

Ao alternar uma thread, o sistema preserva o contexto necessário e restaura outro. A troca tem custo: estado direto, efeitos em cache e tradução, e perda de localidade. Mais threads do que núcleos podem melhorar utilização quando há espera de I/O, mas também aumentar contenção.

Níveis de privilégio limitam instruções e memória acessíveis. Aplicações comuns não reconfiguram páginas ou dispositivos diretamente; entram no kernel por chamadas controladas, como visto na Parte 2.

11.6 Hierarquia de memória

Velocidade, capacidade e custo formam uma hierarquia:

Números exatos mudam por plataforma. O princípio é explorar localidade temporal — reutilizar dado recente — e localidade espacial — acessar endereços próximos.

Cache line, miss e coerência

Caches transferem dados em linhas, não em variáveis isoladas. Se duas threads alteram campos distintos que ocupam a mesma linha, a coerência pode movimentá-la entre núcleos e causar false sharing.

Tipos de miss são frequentemente explicados como compulsório, capacidade e conflito. Em multiprocessadores, coerência acrescenta invalidações. Uma taxa de CPU alta pode esconder muito tempo parado aguardando memória.

Cache não é “memória secreta sempre rápida”. Seu benefício depende do padrão de acesso. Percorrer uma matriz na ordem contígua costuma aproveitar melhor linhas e prefetch que saltos aleatórios.

11.7 RAM, controladores e NUMA

RAM mantém dados voláteis em uso. Em servidores com múltiplos sockets, a memória pode ser Non-Uniform Memory Access: um núcleo acessa memória local com custo menor que memória ligada a outro nó. A documentação do kernel expõe diferenças de latência e largura de banda entre iniciadores e alvos NUMA [10].

Isso importa em bancos, VMs e modelos de IA. Alocar CPU em um nó e memória em outro pode elevar latência. Antes de fixar afinidade, meça; políticas manuais ruins podem piorar balanceamento.

Memória “livre” também não é o objetivo isolado. O sistema usa RAM para cache de páginas. Observe memória disponível, conjunto de trabalho, faults, reclaim, swap e limites de cgroup.

11.8 Armazenamento: latência, throughput, IOPS e durabilidade

Quatro métricas devem ser separadas:

• latência: tempo de uma operação;
• IOPS: operações por segundo sob tamanho e padrão definidos;
• throughput: bytes por segundo;
• queue depth: operações simultâneas em voo.

Um SSD pode oferecer alto throughput sequencial e desempenho menor em gravações aleatórias sincronizadas. Um banco depende de latência de fsync, cache, WAL, padrão de acesso e controlador, não apenas do número anunciado na embalagem.

RAID, cache do dispositivo e sistema de arquivos mudam o comportamento. Confirmação de escrita só é durável se toda a cadeia respeita flush/barreiras e energia conforme o contrato.

11.9 Barramentos, PCIe e DMA

CPU, memória, GPU, armazenamento e interfaces comunicam-se por interconexões. PCI Express organiza links por gerações e lanes. Um dispositivo pode usar DMA para transferir dados à memória sem a CPU copiar cada byte, embora a CPU e o sistema ainda configurem e coordenem a operação.

IOMMU traduz e controla acessos de dispositivos, importante para virtualização e isolamento. Passar um dispositivo diretamente a uma VM melhora alguns workloads, mas altera mobilidade, compartilhamento e superfície de risco.

11.10 32 bits e 64 bits

A classificação pode referir-se ao tamanho de registradores, operandos, ponteiros ou espaço de endereçamento da ISA. O limite didático de 4 GiB vem de 2^32 endereços de byte, mas sistemas de 32 bits podem usar extensões como PAE, e nem todo espaço é disponibilizado a um processo.

Migrar para 64 bits permite espaços maiores e registradores/ISA adequados, mas ponteiros maiores aumentam algumas estruturas e cache pressure. Não torna automaticamente o programa duas vezes mais rápido.

11.11 Multicore, SMT e Lei de Amdahl

Núcleos executam fluxos em paralelo. SMT expõe mais de uma thread lógica por núcleo para aproveitar recursos ociosos; duas CPUs lógicas não equivalem necessariamente a dois núcleos físicos.

A Lei de Amdahl limita o ganho quando uma fração permanece serial:

Nessa expressão, P é a fração paralelizável e N é a quantidade de unidades de execução.

Se 80% do trabalho é paralelizável e 20% é serial, infinitos núcleos não ultrapassam ganho teórico de 5 vezes. Locks, comunicação e desbalanceamento reduzem ainda mais.

Em aplicações Web, aumentar workers ajuda até banco, memória, pool, CPU ou dependência se tornarem gargalo. Capacidade é sistêmica.

11.12 CPU e GPU

CPU privilegia baixa latência e controle geral. GPU oferece muitas unidades para operações paralelas sobre grandes conjuntos. Treino e inferência de IA podem aproveitar GPU, mas apenas quando modelo, precisão, memória do acelerador e pipeline justificam.

Uma GPU ociosa não acelera automaticamente Flask, SQL ou parsing serial. Transferir dados entre RAM e VRAM possui custo. Para modelos locais, meça:

• tempo de carregamento;
• tokens por segundo;
• latência até o primeiro token;
• VRAM/RAM;
• tamanho do contexto;
• concorrência;
• quantização e qualidade.

11.13 Diagnóstico quantitativo de uma aplicação

Sintoma: relatório do GLPI e resposta RAG ficam lentos no mesmo host.

Não comece pelo upgrade

Colete por operação:

uptime
mpstat -P ALL 1
vmstat 1
iostat -xz 1
pidstat -dur 1
free -h

Se disponíveis e autorizados, perfis, eBPF e traces ajudam a localizar espera. O objetivo é diferenciar:

Uma média de 40% de CPU não elimina saturação de um núcleo. “Disco 70%” sem definição de utilidade também não é diagnóstico.

11.14 Estudo de caso: o upgrade errado

Uma equipe aumenta a VM de 4 para 16 vCPUs porque a API está lenta. O p95 não muda. O trace mostra 30 ms na aplicação e 4,2 s esperando uma consulta sem índice. O banco está em storage com latência alta e a consulta examina milhões de linhas.

O upgrade falha porque o recurso escasso não era CPU da aplicação. A correção combina query, índice medido, paginação e storage apropriado. Depois, carga real verifica se o novo gargalo migrou para pool ou rede.

Este exemplo não significa que CPU nunca seja a causa; mostra que capacidade deve seguir perfil, não intuição.

11.15 Síntese do capítulo

• ISA define o contrato; microarquitetura define uma implementação.
• O ciclo de instrução é lógico; pipelines sobrepõem trabalho.
• Clock, núcleo e CPU total não medem sozinhos desempenho.
• Cache e NUMA tornam a localização do dado parte do custo.
• Latência, IOPS e throughput atendem workloads diferentes.
• Paralelismo é limitado pela fração serial e por dependências.
• Diagnóstico mede tempo por recurso e por operação.

Notas Zettelkasten — Capítulo 11

ZK-040 — Contrato arquitetural
Ideia: ISA é a interface visível; microarquitetura é uma execução possível.
Conexões: ZK-036 — Representação; ZK-041 — Localidade.

ZK-041 — Localidade governa custo
Ideia: dado próximo e reutilizado custa menos; cache, NUMA e storage tornam
distância lógica parte do desempenho.
Conexões: ZK-040 — Contrato; ZK-047 — Overcommit.

ZK-042 — Capacidade é sistêmica
Ideia: acelerar um componente apenas desloca o gargalo quando outra dependência
limita o throughput fim a fim.
Conexões: ZK-041 — Localidade; ZK-050 — Elasticidade.

Recuperação ativa — Capítulo 11

1. Diferencie ISA e microarquitetura.
2. Por que 4 GHz não permite comparar sozinho duas CPUs?
3. Como pipeline contradiz a leitura literal do ciclo buscar-executar?
4. O que é false sharing?
5. Por que NUMA pode afetar banco e IA?
6. Compare latência, throughput e IOPS.
7. O que limita o ganho de adicionar núcleos?
8. Como provar que lentidão está no banco, não na CPU da aplicação?

Capítulo 12 — Sistemas de Arquivos

Objetivos de aprendizagem

Ao final deste capítulo, você deverá conseguir:

• explicar arquivo, diretório, nome, metadado e objeto persistente;
• diferenciar caminho, descritor, inode, hard link e link simbólico;
• analisar permissões POSIX e ACLs do Windows;
• explicar journaling, copy-on-write, fsync e durabilidade;
• comparar sistemas de arquivos por workload e requisito;
• separar volume, bind mount, camada gravável e snapshot;
• desenhar persistência e backup para containers.

12.1 O que um sistema de arquivos faz

Um sistema de arquivos organiza bytes persistentes em objetos nomeáveis e aplica regras para localização, metadados, alocação, concorrência, proteção e recuperação. Ele conecta a interface de arquivos do sistema operacional ao armazenamento [9].

Abrir /srv/app/uploads/relatorio.pdf envolve:

1. resolver cada componente do caminho;
2. atravessar diretórios;
3. verificar identidade e permissões;
4. localizar metadados e blocos/extents;
5. criar um descritor no processo;
6. atender leituras pelo page cache e dispositivo;
7. atualizar offsets, tempos e estado conforme as opções.

O caminho identifica um nome naquele namespace. Depois de aberto, o processo usa um descritor; renomear o caminho não altera necessariamente o objeto já aberto.

12.2 Arquivos, diretórios e tipos de objeto

Em sistemas Unix-like, a mesma interface abrange arquivos regulares, diretórios, dispositivos, sockets e pipes. Um diretório associa nomes a objetos. Em ext4, o inode contém metadados e referências aos dados, enquanto o nome pertence à entrada de diretório [11].

Consequência: um arquivo pode ter vários nomes por hard links. Remover um nome reduz a contagem; o objeto só pode liberar armazenamento quando não restam links nem descritores abertos.

Arquivo apagado, espaço ainda ocupado

Um log de 20 GB é removido, mas o processo continua com o descritor aberto. df não libera o espaço; du já não encontra o nome. Em Linux, lsof +L1 pode revelar objetos abertos sem link. A correção normal é pedir ao serviço que reabra o log ou reiniciá-lo de forma controlada, depois de preservar evidências.

12.3 Caminhos absolutos, relativos e normalização

Um caminho absoluto parte de uma raiz; um relativo depende do diretório ou contexto atual. Em containers, /app/data pertence ao namespace do container e pode apontar para camada efêmera, volume ou bind mount.

Riscos comuns:

• ../ escapar do diretório esperado;
• links simbólicos redirecionarem uma validação;
• diferença entre maiúsculas/minúsculas;
• caracteres Unicode equivalentes visualmente;
• nome reservado no Windows;
• caminho absoluto do host usado dentro do container;
• montagem encobrir arquivos presentes na imagem.

Não monte caminho concatenando entrada do usuário. Gere nomes internos, preserve nome original apenas como metadado e confirme que o destino resolvido permanece na raiz autorizada.

12.4 Inodes, extents e esgotamento

Em famílias ext, inodes representam objetos. É possível haver espaço em bytes e falhar ao criar arquivo porque os inodes acabaram — típico de milhões de pequenos arquivos.

df -h
df -i
find /caminho -xdev -type f | wc -l

Não execute find indiscriminadamente em storage crítico durante pico; a varredura também consome I/O. Métricas e inventário antecipado são preferíveis.

Sistemas modernos usam extents para representar intervalos contíguos de blocos com menos metadados. O layout real depende do filesystem.

12.5 Hard links e links simbólicos

Links criam riscos em rotinas privilegiadas. Uma verificação do caminho seguida de abertura pode sofrer troca entre as etapas. APIs com descritores de diretório e flags adequadas reduzem condições TOCTOU — time of check to time of use.

12.6 Permissões POSIX e identidade do processo

No modelo clássico:

r = ler
w = gravar
x = executar ou atravessar diretório

Permissões são avaliadas para proprietário, grupo e outros:

-rw-r-----  1 app reports  2048 Aug 31 relatorio.pdf

O arquivo permite leitura/gravação ao proprietário, leitura ao grupo e nada aos demais. Em diretório, x permite atravessar; r, listar nomes; w, alterar entradas, dependendo também de outras regras.

Valores octais:

7 = rwx
6 = rw-
5 = r-x
4 = r--

chmod 777 remove barreiras e raramente corrige a causa. O serviço deve executar com usuário/grupo próprios, diretórios mínimos e umask planejada.

Bits especiais incluem setuid, setgid e sticky. Em diretório compartilhado, sticky restringe remoções; setgid pode herdar o grupo. Seu uso exige contexto, não memorização isolada.

12.7 ACLs e Windows

ACLs expressam permissões para identidades adicionais. NTFS suporta controle granular e herança por usuários e grupos [12]. Em compartilhamento SMB, a permissão efetiva resulta da combinação entre acesso ao compartilhamento, ACL do filesystem, grupo, negações e contexto.

Boas práticas:

• conceder a grupos, não pessoa por pessoa;
• separar leitura, modificação e administração;
• evitar Deny sem necessidade, pois herança torna o efeito difícil de prever;
• validar com a identidade real do serviço/usuário;
• registrar proprietário e ruptura de herança;
• revisar grupos privilegiados.

No domínio corporativo, “o administrador abre” não prova que DOMINIO\conta-servico abre.

12.8 Page cache, buffers e durabilidade

Uma chamada de escrita pode copiar dados para memória e retornar antes de a mídia persistente confirmá-los. fsync solicita sincronização do arquivo segundo a semântica do sistema; operações de criação/renomeação também podem exigir sincronizar o diretório para determinadas garantias [14].

O aplicativo, filesystem, driver, controlador e dispositivo precisam respeitar a cadeia. Um cache que declara flush concluído sem proteção de energia compromete a promessa.

“Salvei o arquivo” pode significar:

1. o processo colocou bytes em buffer;
2. o kernel os recebeu;
3. o filesystem registrou metadados;
4. o dispositivo confirmou mídia não volátil;
5. uma cópia independente existe.

São estados diferentes.

12.9 Journaling não é backup nem transação de negócio

Journaling registra operações para recuperar consistência estrutural após falha. Dependendo do modo, metadados e dados recebem garantias diferentes. A documentação do kernel descreve o journal usado pelo ext4 e suas transações internas [11].

Ele não impede:

• exclusão autorizada por engano;
• corrupção produzida pela aplicação;
• ransomware;
• perda do dispositivo;
• arquivo logicamente incompleto;
• alteração replicada para todas as cópias.

Uma aplicação deve usar protocolo de escrita adequado: arquivo temporário no mesmo filesystem, sincronização quando necessária, rename atômico conforme as garantias e registro no banco. Mesmo assim, arquivo e banco não formam automaticamente uma única transação.

12.10 Copy-on-write e checksums

Copy-on-write grava novos blocos antes de atualizar referências, possibilitando snapshots eficientes e reduzindo sobrescrita no local. Também pode aumentar fragmentação e write amplification.

OpenZFS combina copy-on-write e checksums ponta a ponta para detectar corrupção; com redundância apropriada pode reparar blocos [13]. Isso não transforma qualquer pool em backup. Erro de operador, chave perdida ou falha do domínio inteiro continuam possíveis.

12.11 Comparação de sistemas de arquivos

Não escolha por lista de recursos. Considere suporte do sistema, recuperação, equipe, workload, ferramentas, backup, expansão e compatibilidade. A documentação do kernel descreve ext4 [11]; Microsoft documenta ACLs e capacidades NTFS [12]; OpenZFS registra custos e propriedades de seu modelo [13].

12.12 Bloco, arquivo e objeto

Montar object storage como filesystem pode ser conveniente, mas não cria todas as garantias POSIX. A aplicação deve conhecer consistência, multipart upload, versionamento e custo de operações.

12.13 Containers: camada gravável, volume e bind mount

Uma imagem fornece camadas somente leitura. O container adiciona uma camada gravável efêmera. Em drivers baseados em OverlayFS, alterar arquivo existente pode exigir copy_up [15]. Para dados persistentes e escrita intensa, Docker recomenda volumes em vez da camada gravável [16].

Um bind mount pode encobrir arquivos existentes na imagem. Além disso, UID/GID dentro do container precisam corresponder à permissão no host ou a mecanismo de remapeamento.

Regra operacional

docker compose down normalmente preserva volumes nomeados; down -v solicita removê-los. Antes de qualquer ação destrutiva, identifique volumes, backup e restore. Recriar container não deve apagar dado de negócio.

12.14 Snapshot, backup e réplica

• snapshot captura estado em um ponto e frequentemente compartilha o mesmo domínio de armazenamento;
• réplica acompanha alterações, inclusive exclusões e corrupção lógica;
• backup mantém cópia recuperável conforme retenção e isolamento;
• arquivamento preserva informação por política de longo prazo.

Snapshot crash-consistent pode equivaler a uma queda de energia. Para banco, use mecanismos nativos ou coordene quiescência e logs. Teste restauração no nível da aplicação.

12.15 Estudo de caso: upload desaparece ao recriar o container

Sintoma

Uploads funcionam até a implantação; após docker compose up -d --build, arquivos somem.

Evidências

Aplicação grava em: /app/app/static/uploads
Compose monta:      /app/uploads
Camada do container cresce durante o uso
Novo container:     diretório volta ao estado da imagem

Causa

O caminho gravado não correspondia ao mount. Dados ficaram na camada gravável do container.

Correção

1. interromper novas gravações de forma controlada;
2. copiar dados do container antigo para destino persistente, preservando metadados necessários;
3. corrigir o caminho único de configuração;
4. ajustar proprietário e grupo;
5. validar upload, leitura, recriação e restore;
6. monitorar capacidade e inodes;
7. incluir o volume na política de backup.

O incidente não é “culpa do Docker”; é divergência entre modelo de persistência e configuração.

12.16 Diagnóstico seguro

df -h
df -i
findmnt
lsblk -f
stat /caminho/arquivo
namei -l /caminho/arquivo
getfacl /caminho/arquivo
ls -l /proc/<PID>/fd
docker inspect nome-do-container
docker volume inspect nome-do-volume

du mede arquivos alcançáveis; df mede blocos alocados no filesystem. Divergência pode envolver arquivos apagados abertos, snapshots, reserva ou mount diferente. Não execute chmod -R 777, chown -R ou remoções recursivas como diagnóstico.

12.17 Síntese do capítulo

• Caminho é nome; descritor referencia o objeto aberto.
• Inode e espaço em bytes podem se esgotar separadamente.
• Permissão efetiva depende da identidade real, herança, ACL e contexto.
• Escrita aceita pelo kernel não equivale sempre a dado durável.
• Journaling recupera estrutura; não substitui transação nem backup.
• Camada gravável de container não é local de persistência de negócio.
• Snapshot, réplica e backup protegem contra falhas diferentes.

Notas Zettelkasten — Capítulo 12

ZK-043 — Nome não é objeto
Ideia: caminho resolve um nome; após abrir, o processo opera por descritor.
Conexões: ZK-038 — Texto; ZK-044 — Durabilidade.

ZK-044 — Durabilidade é uma cadeia
Ideia: buffer, page cache, journal, controlador, mídia e cópia independente
representam promessas diferentes.
Conexões: ZK-039 — Integridade; ZK-045 — Persistência de container.

ZK-045 — Persistência de container
Ideia: imagem e camada gravável pertencem ao ciclo do workload; dado de negócio
precisa de volume e estratégia de recuperação explícitos.
Conexões: ZK-044 — Durabilidade; ZK-048 — Imagem como artefato.

Recuperação ativa — Capítulo 12

1. Por que remover o nome de um arquivo pode não liberar espaço?
2. Como hard link difere de link simbólico?
3. Por que df e du podem divergir?
4. O que journaling garante e o que não garante?
5. Quando fsync entra na durabilidade?
6. Compare block, file e object storage.
7. Por que banco não deve gravar na camada do container?
8. O que um snapshot crash-consistent preserva?

Capítulo 13 — Virtualização, Containers e Orquestração

Objetivos de aprendizagem

Ao final deste capítulo, você deverá conseguir:

• diferenciar particionamento, virtualização, emulação e containers;
• explicar CPU, memória, I/O e rede virtuais;
• reconhecer overcommit, ballooning, noisy neighbor e failure domain;
• descrever namespaces, cgroups, capabilities e seccomp;
• distinguir imagem, container, runtime, registry e volume;
• compreender o papel de Docker Compose e Kubernetes;
• projetar isolamento, probes, secrets e persistência sem promessas irreais.

13.1 Por que virtualizar

Servidores físicos historicamente eram dimensionados para picos e dedicados a uma aplicação. Isso elevava ociosidade, custo e tempo de provisionamento. Virtualização permite apresentar recursos físicos como recursos lógicos, consolidar workloads, padronizar ambientes e criar fronteiras operacionais.

O ganho não é gratuito. Surge uma nova camada que precisa ser atualizada, monitorada, dimensionada e recuperada. Consolidar dez servidores em um host também concentra impacto se esse host falha.

13.2 Virtualização, emulação e container

Emulação pode ser combinada com virtualização: instruções nativas usam aceleração e dispositivos são emulados. Container não é “uma VM pequena”; a fronteira passa pelo mesmo kernel.

13.3 Hipervisor e máquinas virtuais

O hipervisor medeia CPU, memória, rede e storage para máquinas virtuais. A taxonomia tradicional usa:

• tipo 1: executa diretamente sobre o hardware ou como plataforma de virtualização;
• tipo 2: executa como aplicação sobre um sistema operacional hospedeiro.

Arquiteturas modernas misturam componentes no kernel, partição raiz e processos de usuário, então a classificação ajuda didaticamente, mas não mede isolamento ou desempenho sozinha. NIST define o hipervisor como plataforma que virtualiza recursos e fornece isolamento de execução entre VMs [24].

Cada VM possui firmware virtual, dispositivos, kernel, serviços e aplicações. Isso aumenta independência, mas também consumo, superfície de atualização e tempo de inicialização.

13.4 Como CPU e memória são virtualizadas

Extensões de hardware permitem executar grande parte do código convidado diretamente, transferindo eventos sensíveis ao hipervisor. Técnicas de paginação aninhada combinam tabelas do convidado e do host. O hypervisor agenda vCPUs sobre CPUs físicas.

Uma vCPU é uma unidade escalonável, não um núcleo físico reservado, salvo configuração explícita. Quatro VMs com quatro vCPUs em um host de oito núcleos representam overcommit de 2:1; isso pode ser aceitável para workloads ociosos e ruim para CPU sustentada.

Memória pode usar:

• reserva e limite;
• overcommit;
• ballooning para devolver páginas;
• compartilhamento de páginas em alguns ambientes;
• swap do host ou convidado;
• huge pages para workloads específicos.

Se host e convidado entram em swap simultaneamente, latência pode explodir. “A VM tem 16 GB” não prova que 16 GB físicos estão sempre disponíveis.

13.5 I/O virtual, passthrough e rede

Dispositivos podem ser emulados, paravirtualizados ou atribuídos diretamente. Drivers paravirtuais reduzem custo. Passthrough/SR-IOV pode oferecer desempenho e isolamento de filas, mas afeta migração, observabilidade e compartilhamento. IOMMU ajuda a restringir DMA.

Rede virtual inclui interfaces, switches, bridges, overlays, firewall e NAT. Duas VMs no mesmo host podem comunicar-se sem sair por uma porta física, logo monitoramento apenas no switch externo perde visibilidade.

13.6 Snapshots de VM e clones

Snapshot de VM captura discos e, opcionalmente, memória/estado. Cadeias longas aumentam dependência e custo. Snapshot não é estratégia de backup independente: permanece frequentemente no mesmo storage e pode conter estado apenas crash-consistent.

Clones aceleram provisionamento, mas duplicam identidade se hostname, chaves e IDs não forem regenerados. Templates devem ser generalizados e atualizados.

13.7 Overcommit e noisy neighbor

Consolidação funciona porque picos nem sempre coincidem. Falha quando suposições não são medidas.

Um vizinho pode consumir storage compartilhado e tornar outra VM lenta mesmo com CPU livre. Limites, reservas, classes de serviço e capacidade por failure domain reduzem o risco.

13.8 Containers no Linux

Containers combinam mecanismos do kernel e ferramentas de empacotamento:

• namespaces: criam visões isoladas de processos, mounts, rede, usuários, IPC, hostname e cgroups;
• cgroups: contabilizam e limitam CPU, memória, I/O e processos;
• capabilities: dividem parte do poder de root;
• seccomp: filtra chamadas de sistema;
• LSM: SELinux/AppArmor aplicam políticas adicionais;
• filesystem em camadas: compõe imagem e camada gravável.

A documentação do kernel cobre namespaces e cgroup v2 [17][18]. O isolamento é configurável: --privileged, host network, mounts sensíveis e socket do Docker podem aproximar o container do controle do host.

13.9 Imagem, container, runtime e registry

A OCI mantém especificações de imagem, runtime e distribuição [19]. Fixar apenas latest não garante repetibilidade; um digest aponta ao conteúdo exato, embora dependências e ambiente externo ainda possam mudar.

Construção de imagem

FROM python:3.13-slim@sha256:<digest-validado>

WORKDIR /app
COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt

COPY app ./app
USER 10001:10001
CMD ["gunicorn", "--bind", "0.0.0.0:8000", "app:create_app()"]

O exemplo ilustra base fixada, dependências em camada própria, usuário não root e comando explícito. Ainda são necessários scan, SBOM, atualização, verificação de pacote e secrets externos.

Multi-stage builds reduzem ferramentas de compilação na imagem final. Menor imagem ajuda distribuição e superfície, mas “distroless” ou scratch exigem estratégia de diagnóstico e certificados.

13.10 Limites de recursos e OOM

Sem limites, um container pode competir por todo o host. Com limite incorreto, falha apesar de o host ter memória livre.

Exemplo Compose:

services:
  app:
    image: registry.exemplo.com/knowledgebase@sha256:<digest>
    mem_limit: 1g
    cpus: 1.5
    pids_limit: 256
    read_only: true
    tmpfs:
      - /tmp:size=128m,noexec,nosuid

Compatibilidade das opções depende do modo e da implementação do Compose. Meça working set, picos de inicialização e comportamento sob limite. Modelos de IA, workers e aplicação Web não devem dividir memória sem orçamento.

13.11 Docker Compose: aplicação de um host

Compose descreve serviços, redes, volumes, dependências e configuração de um conjunto de containers. É excelente para desenvolvimento, laboratório e produção controlada em um host, mas não oferece automaticamente scheduler multi-host, failover de nó ou controladores de estado como Kubernetes.

Exemplo conceitual:

services:
  web:
    image: registry.exemplo.com/kb/web@sha256:<digest>
    depends_on:
      redis:
        condition: service_healthy
    volumes:
      - uploads:/app/app/static/uploads
    secrets:
      - db_password

  worker:
    image: registry.exemplo.com/kb/web@sha256:<digest>
    command: ["rq", "worker", "knowledgebase"]
    volumes:
      - uploads:/app/app/static/uploads

  redis:
    image: redis:8-alpine
    healthcheck:
      test: ["CMD", "redis-cli", "ping"]

volumes:
  uploads:

secrets:
  db_password:
    file: ./secrets/db_password.txt

depends_on ordena criação/saúde conforme o modo, mas não torna a aplicação resiliente a falhas posteriores. O cliente precisa de timeouts e reconexão. O arquivo de segredo local ainda precisa de proteção e rotação.

13.12 Kubernetes: estado desejado e controladores

Kubernetes oferece uma API declarativa e controladores que reconciliam estado desejado e observado.

• Pod: menor unidade de agendamento, um ou mais containers com rede e volumes compartilhados;
• Deployment: gerencia ReplicaSets e atualização de workloads geralmente sem estado [21];
• StatefulSet: oferece identidade e ordenação para estados específicos;
• Service: endereço estável e seleção de Pods;
• Ingress/Gateway: roteamento de entrada, conforme controlador;
• ConfigMap/Secret: configuração e material sensível, com proteção adicional necessária;
• PV/PVC/StorageClass: abstração de armazenamento persistente [23].

Pod não é VM. Seus containers compartilham namespace de rede e ciclo do Pod. O scheduler coloca Pods; controllers os recriam. Recriação não recupera estado que estava apenas no filesystem efêmero.

13.13 Liveness, readiness e startup probes

Kubernetes diferencia [22]:

• startup: concede tempo de inicialização antes das demais;
• readiness: decide se o Pod deve receber tráfego;
• liveness: decide se o container precisa ser reiniciado.

Uma liveness que consulta banco pode reiniciar todas as instâncias durante falha do banco e piorar o incidente. Liveness deve indicar travamento local recuperável por restart; readiness pode refletir incapacidade temporária de atender. Probes precisam de timeout, custo baixo e thresholds compatíveis.

13.14 Secrets não são seguros apenas pelo nome

Variável de ambiente pode aparecer em dumps, interfaces ou processos. Secret do Kubernetes pode estar apenas codificado em Base64 se criptografia em repouso e RBAC não forem configurados. Repositório Git, imagem, log e pipeline são locais inadequados para segredo.

Uma solução de gestão de secrets deve tratar:

• armazenamento cifrado e acesso por identidade;
• entrega mínima ao workload;
• rotação e revogação;
• auditoria;
• separação entre ambientes;
• resposta a exposição.

13.15 Segurança de containers

A documentação do Docker destaca namespaces, cgroups, daemon, capabilities e hardening como áreas centrais [20]. Controles:

• usuário não root e user namespaces quando aplicável;
• filesystem somente leitura;
• remover capabilities e adicionar apenas as necessárias;
• seccomp/AppArmor/SELinux;
• não montar /var/run/docker.sock em workload comum;
• não usar --privileged por conveniência;
• imagens mínimas, assinadas, escaneadas e atualizadas;
• limites de CPU, memória e PIDs;
• rede e egress restritos;
• secrets fora da imagem;
• logs e auditoria do plano de controle.

Container comprometido continua sendo incidente. A meta é limitar impacto e movimento lateral, não declarar isolamento absoluto.

13.16 Quando usar cada modelo

Kubernetes não é requisito de maturidade. Um Compose bem operado pode ser superior a um cluster mal administrado para uma aplicação pequena.

13.17 Estudo de caso: Flask, RQ, Redis e Ollama no mesmo host

Sintoma

Quando um documento grande é indexado, o portal fica lento e o worker reinicia.

Evidências

Host: 16 GiB RAM
Ollama: 10–12 GiB durante inferência
Web: sem limite
Worker: limite de 2 GiB; pico de 2,4 GiB no parsing
Redis: política de memória não definida
Resultado: worker OOM; fila repete job; web sofre reclaim

Redesenho

• separar orçamento de web, worker, Redis e Ollama;
• limitar tamanho, páginas e paralelismo de documentos;
• fazer streaming quando possível;
• tornar job idempotente;
• medir pico por etapa;
• impedir que health check reinicie web por lentidão do modelo;
• considerar host separado/GPU ou modelo menor;
• preservar upload em volume compartilhado e indexação no banco apropriado;
• estabelecer backpressure pela fila.

Adicionar mais workers aumentaria o pico e pioraria o OOM. Concorrência precisa respeitar o recurso mais caro.

13.18 Síntese do capítulo

• VM virtualiza hardware e executa kernel convidado; container isola processos no kernel do host.
• vCPU e memória virtual não equivalem sempre a recurso físico dedicado.
• Overcommit exige telemetria e limites.
• Imagem é artefato; container é instância; tag é referência mutável.
• Compose coordena serviços; Kubernetes reconcilia estado em cluster.
• Probes respondem a perguntas diferentes.
• Isolamento é uma propriedade configurada e testada.

Notas Zettelkasten — Capítulo 13

ZK-046 — Virtualização é mediação
Ideia: recursos lógicos dependem de um mediador que agenda, traduz e isola.
Conexões: ZK-040 — Contrato arquitetural; ZK-047 — Overcommit.

ZK-047 — Overcommit transforma média em risco
Ideia: consolidar usa ociosidade estatística; picos correlacionados quebram a premissa.
Conexões: ZK-042 — Capacidade; ZK-050 — Elasticidade.

ZK-048 — Imagem não é instância
Ideia: imagem é conteúdo distribuível; container acrescenta execução e estado efêmero.
Conexões: ZK-045 — Persistência; ZK-057 — Cadeia de suprimentos.

Recuperação ativa — Capítulo 13

1. Como emulação difere de virtualização?
2. Por que quatro vCPUs não significam quatro núcleos reservados?
3. O que é noisy neighbor?
4. Quais mecanismos formam um container Linux?
5. Por que digest e tag não são equivalentes?
6. O que Compose não oferece automaticamente?
7. Compare startup, readiness e liveness.
8. Por que Kubernetes pode ser uma escolha ruim para sistema pequeno?

Capítulo 14 — Computação em Nuvem

Objetivos de aprendizagem

Ao final deste capítulo, você deverá conseguir:

• reconhecer cloud pelas características essenciais, não pelo local do servidor;
• comparar modelos de serviço e responsabilidade;
• projetar rede, compute, storage e banco em failure domains;
• diferenciar escalabilidade, elasticidade, disponibilidade e recuperação;
• explicar responsabilidade compartilhada;
• analisar custo por unidade, egress, compromisso e ociosidade;
• planejar migração e portabilidade sem slogans.

14.1 Cloud não é apenas “servidor fora da empresa”

NIST define cloud como acesso de rede conveniente e sob demanda a um conjunto compartilhado de recursos configuráveis, rapidamente provisionados e liberados com pouco esforço de gestão [25]. Cinco características ajudam a distinguir cloud de hospedagem tradicional:

1. autosserviço sob demanda;
2. amplo acesso por rede;
3. pool de recursos;
4. elasticidade rápida;
5. serviço medido.

Uma VPS criada por chamado manual e cobrada por contrato fixo pode ser hospedagem, ainda que esteja em um grande provedor. Um cloud privado local pode cumprir as características mesmo dentro da organização.

14.2 Escalabilidade, elasticidade e disponibilidade

• scale up: aumentar recursos de uma instância;
• scale out: aumentar instâncias;
• elasticidade: ajustar capacidade à demanda em tempo apropriado;
• disponibilidade: manter a função acessível conforme a meta;
• resiliência: absorver falhas e recuperar comportamento;
• durabilidade: preservar dados ao longo do tempo.

Autoscaling não corrige aplicação stateful que guarda sessão em memória local, banco saturado nem implantação defeituosa. Ele precisa de métrica, limites, cooldown, capacidade de dependências e estratégia de scale-in.

14.3 IaaS, PaaS e SaaS

Os modelos canônicos do NIST são IaaS, PaaS e SaaS [25]. A arquitetura de referência do NIST complementa a taxonomia com atores e responsabilidades [42]. CaaS e FaaS são categorias de mercado úteis, mas não fazem parte da taxonomia original.

Quanto mais gerenciado, menor o controle operacional direto e maior a dependência do contrato do serviço. Isso pode ser excelente: transferir trabalho indiferenciado permite focar no produto. O trade-off deve ser explícito.

14.4 Modelos de implantação

• pública: infraestrutura oferecida a amplo mercado;
• privada: exclusiva de uma organização;
• comunitária: compartilhada por organizações com requisitos comuns;
• híbrida: combina ambientes distintos ligados por portabilidade e integração.

Multicloud descreve uso de múltiplos provedores, mas não implica que cada aplicação seja portátil ou faça failover entre eles. Duplicar toda arquitetura em duas clouds aumenta custo e complexidade. Use quando requisitos de negócio justificarem.

14.5 Regiões, zonas e failure domains

Região é uma área geográfica; zona de disponibilidade é um agrupamento isolado dentro de uma região conforme o provedor. Serviços e regiões não oferecem o mesmo suporte. A documentação da Azure, por exemplo, enfatiza que habilitar redundância e escolher tier adequado continuam sendo responsabilidades do cliente [26].

Distribuir duas VMs em zonas diferentes não garante alta disponibilidade se banco, disco, NAT ou deploy continuam únicos.

flowchart TB
    U["Usuário"] --> D["DNS / roteamento global"]
    D --> L["Balanceador regional"]
    L --> A["Aplicação — Zona A"]
    L --> B["Aplicação — Zona B"]
    A --> DB["Banco com redundância"]
    B --> DB

Mapeie cada dependência e seu failure domain. Alta disponibilidade na região não é disaster recovery regional.

14.6 Rede virtual

Uma VPC/VNet define isolamento lógico de rede. Dentro dela existem sub-redes, rotas, gateways e controles. Um desenho típico separa:

• entrada pública apenas no balanceador/proxy;
• aplicação em subnet privada;
• banco sem endereço público;
• saída controlada por NAT/proxy quando necessária;
• administração por identidade, bastion ou acesso privado;
• endpoints privados para serviços gerenciados;
• DNS dividido e logs de fluxo.

Security group/firewall controla tráfego, mas não substitui autorização da aplicação. Subnet pública não significa que toda instância possui IP público; descreve frequentemente a rota disponível.

14.7 Balanceadores e saúde

Balanceador L4 decide por endereço/porta e transporte; L7 interpreta HTTP e pode rotear por host/caminho/header. Ele precisa de health checks representativos e capacidade de remover instâncias.

Riscos:

• health check sempre 200 mesmo sem dependência essencial;
• sessão presa a instância sem necessidade;
• drain insuficiente durante deploy;
• timeout incompatível entre camadas;
• confiança irrestrita em headers;
• certificado e política TLS divergentes.

14.8 Compute: VM, container gerenciado e função

Serverless não significa ausência de servidor; significa que o provedor gerencia a infraestrutura de execução. Cold start, duração máxima, concorrência, egress e observabilidade continuam relevantes.

14.9 Armazenamento em nuvem

Objeto

Ideal para uploads, mídia, backup e artefatos. Use versionamento, lifecycle, criptografia, política por identidade e bloqueio público. Namespace e consistência obedecem ao serviço, não a POSIX.

Bloco

Apresentado a VM/serviço como volume. Performance pode depender de tamanho, tier, IOPS provisionadas e limite da instância.

Arquivo

Compartilhado por protocolo, adequado a workloads que precisam de hierarquia e semântica compatível. Latência e locking precisam ser testados.

Durabilidade anunciada do serviço não substitui proteção contra exclusão lógica. Versionamento, retenção, backup e conta separada reduzem o domínio de ataque.

14.10 Bancos gerenciados

O provedor pode administrar patch, backups, réplica e failover, mas o cliente ainda responde por:

• schema, query e índice;
• usuários e privilégios;
• retenção e restauração;
• escolha de tier e redundância;
• criptografia e chaves conforme modelo;
• conectividade e exposição;
• atualização de versão e compatibilidade;
• teste de RPO/RTO.

“Multi-AZ” precisa ser lido no contrato: é síncrono? failover é automático? qual tempo? backups são regionais? Restore foi testado?

14.11 Infraestrutura como código

IaC descreve recursos de forma versionável e repetível. Benefícios:

• revisão antes da mudança;
• criação consistente entre ambientes;
• inventário declarativo;
• detecção de drift;
• automação de teste e política.

O estado da ferramenta pode conter IDs e segredos; proteja-o. Uma alteração revisada ainda pode apagar recurso; plano, guardrails, backup e aprovação contextual são necessários. Não armazene credencial no repositório.

14.12 Observabilidade e confiabilidade

Cloud oferece muitas métricas, mas o sistema precisa de objetivos. Um SLI mede comportamento; um SLO define meta; SLA é compromisso contratual.

Exemplo:

SLI: proporção de solicitações válidas atendidas abaixo de 2 s
SLO: 99,5% em janela móvel de 30 dias

Média de disponibilidade de componentes não se soma. Dependências em série reduzem disponibilidade fim a fim. Redundância correlacionada na mesma zona não remove o failure domain.

Teste failover, restore e degradação. Um runbook nunca executado é documentação, não evidência.

14.13 FinOps e custo por valor

FinOps é uma prática operacional e cultural para maximizar valor, decisão orientada a dados e responsabilidade financeira entre engenharia, finanças e negócio [27]. Não é apenas “cortar a conta”.

Custos invisíveis frequentes:

• recurso ocioso;
• volume e snapshot órfãos;
• egress entre regiões/Internet;
• logs sem retenção;
• IP e balanceador parados;
• banco superdimensionado;
• NAT gateway e tráfego processado;
• GPU ligada sem utilização;
• chamadas/tokens de IA sem limite;
• descontos comprometidos para capacidade errada.

Meça custo por unidade de valor. Uma forma mais legível é separar o custo total do custo unitário:

em que:

Tags/labels precisam representar produto, ambiente, proprietário e centro de custo. Rate optimization sem corrigir desperdício apenas compra desperdício mais barato.

14.14 Responsabilidade compartilhada

O provedor protege datacenter, hardware e partes variáveis da plataforma; o consumidor protege identidade, configuração, aplicação e dados segundo o serviço. Em IaaS, o cliente patcha o guest; em SaaS, ainda configura usuários, compartilhamento, retenção e uso.

Responsabilidade não transferida por contrato continua com a organização. Serviço gerenciado reduz tarefas, não elimina accountability.

14.15 Migração: rehost não é transformação

Estratégias comuns:

• rehost: mover quase sem alterar;
• replatform: aproveitar alguns serviços gerenciados;
• refactor: redesenhar para novos requisitos;
• repurchase: trocar por SaaS;
• retain: manter por ora;
• retire: desligar;
• relocate: mover plataforma virtualizada compatível.

Antes de migrar:

1. inventarie aplicação, dados, integrações e donos;
2. defina SLO, RPO, RTO e requisitos legais;
3. meça baseline de custo e performance;
4. classifique dados e residência;
5. escolha estratégia por componente;
6. projete identidade, rede, logs e chaves;
7. teste migração, rollback e restore;
8. valide operação e custo após a mudança;
9. desative origem somente após critérios.

14.16 Lock-in e portabilidade

Lock-in não é binário. Pode existir em API, dados, formato, identidade, operação, conhecimento e contrato. Um banco gerenciado proprietário pode gerar alto valor e ainda exigir estratégia de saída.

Perguntas:

• os dados podem ser exportados em tempo e custo aceitáveis?
• qual funcionalidade precisaria ser reconstruída?
• quem possui chaves e logs?
• há limite de egress?
• a equipe conhece alternativa?
• o ganho atual compensa o custo futuro?

Usar apenas recursos genéricos para evitar qualquer dependência pode perder benefícios e criar plataforma interna cara. A decisão é econômica e arquitetural.

14.17 Estudo de caso: portal corporativo em cloud

Requisitos

• portal Flask público;
• documentos privados;
• worker assíncrono;
• Redis/fila;
• PostgreSQL;
• inferência com Ollama ou serviço de IA;
• RPO de 15 minutos e RTO de 2 horas;
• usuários no Brasil;
• custo previsível.

Arquitetura inicial

• CDN/WAF e balanceador público;
• duas instâncias de aplicação em zonas distintas;
• workers com escala baseada na idade da fila;
• object storage privado com versionamento para originais;
• banco gerenciado Multi-AZ com PITR;
• Redis gerenciado ou cluster com persistência conforme uso;
• inferência em pool separado, com limite de concorrência;
• secrets por identidade de workload;
• logs centralizados com retenção e mascaramento;
• backups copiados para conta/domínio de proteção separado.

Decisões

1. aplicação não grava uploads em disco local;
2. worker recebe ID, não bytes inteiros pela fila;
3. object storage emite URL de curta duração quando necessário;
4. banco guarda metadados e estado, não arquivo grande sem motivo;
5. autoscaling respeita capacidade do banco e da IA;
6. falha da IA deixa documento em estado reprocessável;
7. deploy usa migração compatível e rollback;
8. custo por documento e por consulta é monitorado.

14.18 Síntese do capítulo

• Cloud é um modelo operacional com autosserviço, pool, elasticidade e medição.
• Managed service redistribui responsabilidades; não as elimina.
• Zona, região, multi-AZ e multi-região representam failure domains diferentes.
• Autoscaling precisa de dependências escaláveis e backpressure.
• FinOps conecta custo a valor e responsabilidade.
• Migração exige inventário, critérios e plano de saída.

Notas Zettelkasten — Capítulo 14

ZK-049 — Serviço medido muda comportamento
Ideia: custo variável precisa de unidade de valor, proprietário e feedback rápido.
Conexões: ZK-037 — Precisão; ZK-050 — Elasticidade.

ZK-050 — Elasticidade não é capacidade infinita
Ideia: escala possui limites, atraso, custo e dependências; backpressure evita colapso.
Conexões: ZK-042 — Capacidade; ZK-047 — Overcommit.

ZK-051 — Failure domain deve ser desenhado
Ideia: duplicar instâncias só melhora disponibilidade quando remove causas comuns.
Conexões: ZK-044 — Durabilidade; ZK-052 — Responsabilidade compartilhada.

ZK-052 — Responsabilidade compartilhada
Ideia: serviço gerenciado muda quem executa controles, não quem responde pelo risco.
Conexões: ZK-051 — Failure domain; ZK-055 — Mínimo privilégio.

Recuperação ativa — Capítulo 14

1. O que diferencia cloud de uma VPS solicitada manualmente?
2. Compare escala vertical, horizontal e elasticidade.
3. Como responsabilidade muda entre IaaS e SaaS?
4. Por que duas VMs em zonas diferentes podem continuar dependentes de ponto único?
5. O que serverless não elimina?
6. Por que object storage não deve ser tratado como filesystem POSIX?
7. Como medir custo por valor?
8. Quando lock-in pode ser uma escolha racional?

Capítulo 15 — Introdução à Segurança da Informação

Objetivos de aprendizagem

Ao final deste capítulo, você deverá conseguir:

• distinguir ativo, ameaça, vulnerabilidade, exposição, risco e controle;
• aplicar confidencialidade, integridade, disponibilidade e autenticidade;
• separar identificação, autenticação, autorização, sessão e auditoria;
• comparar criptografia, hash, MAC e assinatura;
• proteger senhas, secrets, APIs, bancos, cloud, containers e uploads;
• organizar vulnerabilidades por risco real, não apenas por score;
• relacionar segurança, LGPD e ciclo de vida dos dados;
• estruturar resposta a incidentes e segurança de uma aplicação RAG.

15.1 Segurança é gestão contínua de risco

Segurança da informação preserva propriedades necessárias para que informação e sistemas apoiem o negócio mesmo diante de erro, abuso, falha e ataque. Ela não é um produto instalado no final do projeto.

O NIST Cybersecurity Framework 2.0 organiza resultados em seis funções: Govern, Identify, Protect, Detect, Respond e Recover [28]. A inclusão de Govern reforça que estratégia, papéis, política, fornecedores e risco pertencem à gestão, não apenas à equipe técnica.

Segurança absoluta não existe. O objetivo é reduzir probabilidade e impacto a um nível aceito, preservar capacidade de detecção e recuperar-se com evidência.

15.2 Propriedades: CIA e além

Confidencialidade

Informação é acessível apenas a identidades e processos autorizados. Exemplo: descrição de chamado jurídico não pode aparecer para outro setor.

Integridade

Informação e sistemas não são alterados ou destruídos sem autorização ou detecção apropriada. Exemplo: prioridade e histórico do ticket precisam permanecer coerentes.

Disponibilidade

Informação e serviço permanecem acessíveis dentro dos requisitos. Um sistema disponível apenas para login, mas incapaz de abrir chamados, não entrega sua função.

Autenticidade e rastreabilidade

Autenticidade sustenta que uma identidade, mensagem ou artefato é o que afirma ser. Rastreabilidade permite reconstruir ações. Não repúdio é uma propriedade jurídica/técnica mais específica e não nasce simplesmente de manter logs.

Controles podem conflitar: bloquear tudo aumenta confidencialidade e destrói disponibilidade. Segurança é composição orientada por contexto.

15.3 Vocabulário de risco

Risco = probabilidade × impacto é uma aproximação útil, não uma verdade numérica. Probabilidade raramente é conhecida com precisão. Registre premissas, exposição, explorabilidade, ativo, controles existentes e risco residual.

Tratamentos possíveis: mitigar, evitar, transferir ou aceitar formalmente. Ignorar não é aceitar de forma governada.

15.4 Identidade: cinco perguntas diferentes

1. Identificação: quem a entidade afirma ser?
2. Autenticação: qual evidência sustenta a identidade?
3. Autorização: qual ação pode executar sobre qual objeto?
4. Sessão: como o estado autenticado é mantido e encerrado?
5. Auditoria: como reconstruir a decisão e a ação?

LDAP/Active Directory pode autenticar e fornecer grupos, mas a aplicação ainda mapeia grupos a papéis e entidades. Sincronizar usuário não concede automaticamente a permissão correta.

MFA e autenticação resistente a phishing

MFA combina fatores independentes: conhecimento, posse e inerência. Dois segredos memorizados continuam sendo o mesmo tipo de fator. SMS melhora alguns cenários, mas pode sofrer phishing e troca de SIM.

NIST SP 800-63B-4 afirma que senha não é resistente a phishing e orienta opções criptográficas resistentes quando o nível requer [31]. Passkeys/WebAuthn vinculam credenciais de chave pública ao site e reduzem reutilização de segredo. Ainda são necessários recuperação de conta, ciclo de dispositivo e revogação seguros.

15.5 Autorização: papel, atributo e objeto

RBAC

Permissões são associadas a papéis: solicitante, técnico, gestor, administrador.

ABAC

A decisão usa atributos: entidade, departamento, classificação, horário, dispositivo e estado do recurso.

Autorização por objeto

Mesmo um técnico autenticado não deve acessar qualquer ticket_id. APIs precisam verificar relação com entidade, grupo, papel e estado em toda operação. IDs aleatórios reduzem enumeração, mas não substituem o controle.

Princípios:

• negar por padrão;
• mínimo privilégio;
• separação de funções;
• privilégio temporário para administração;
• revisão periódica;
• remoção rápida no desligamento;
• conta técnica por integração, sem compartilhamento.

15.6 Sessões, tokens e secrets

Uma sessão roubada pode contornar a senha. Cookies Web devem usar Secure, HttpOnly, SameSite adequado, expiração, rotação após autenticação e proteção contra CSRF conforme a arquitetura.

Tokens precisam validar assinatura, emissor, audiência, expiração e escopo. Decodificar JWT não equivale a validá-lo.

Secrets incluem senha de banco, API token do GLPI, chave Slack, chave SSH e certificado privado. Não devem aparecer em:

• código ou Git;
• imagem Docker;
• docker inspect sem necessidade;
• log ou captura de erro;
• prompt de IA;
• planilha ou chat;
• backup sem proteção.

Gestão inclui inventário, armazenamento, entrega por identidade, rotação, revogação, auditoria e resposta a vazamento. A OWASP mantém orientações específicas de secret management [44].

15.7 Criptografia aplicada

Simétrica

Uma chave cifra e decifra. É eficiente para grandes volumes. Modos autenticados como AES-GCM protegem confidencialidade e integridade quando nonce, chave e parâmetros são corretos.

Assimétrica

Par de chave pública e privada permite assinatura, troca/encapsulamento de chaves e outros protocolos. Dados grandes normalmente usam criptografia híbrida: uma chave simétrica protege o conteúdo; criptografia assimétrica protege a chave ou autentica a troca.

Hash, MAC e assinatura

Não crie algoritmo criptográfico próprio. Use bibliotecas mantidas, protocolos padronizados e gestão de chaves. Criptografar dado e armazenar a chave ao lado com o mesmo acesso reduz drasticamente o benefício.

15.8 Gestão de chaves

Chave possui ciclo de vida:

1. geração com entropia adequada;
2. distribuição controlada;
3. armazenamento em KMS/HSM ou cofre apropriado;
4. uso autorizado e auditado;
5. rotação/versionamento;
6. revogação;
7. destruição e retenção compatível.

Envelope encryption cifra dados com uma data key e protege essa chave com uma chave mestra. Rotacionar a mestra pode reempacotar chaves sem recifrar todo o conteúdo, conforme o serviço.

Backup cifrado exige testar recuperação das chaves. A melhor criptografia torna o dado irrecuperável quando a chave é perdida.

15.9 Senhas

Senhas não devem ser armazenadas em texto claro nem com SHA-256 rápido. OWASP recomenda funções específicas, deliberadamente custosas, priorizando Argon2id quando disponível e configurado segundo o ambiente [32]. Cada senha recebe salt único; pepper opcional exige armazenamento separado.

Boas práticas atuais:

• permitir senhas longas e caracteres Unicode sem truncamento silencioso;
• comparar com lista de valores comprometidos/comuns;
• não impor trocas periódicas arbitrárias sem evidência de comprometimento;
• não criar regras de composição que induzem padrões previsíveis;
• limitar tentativas com proteção contra abuso e negação de serviço;
• oferecer gerenciadores e MFA;
• proteger recuperação de conta no mesmo nível da autenticação.

Parâmetros de hash precisam ser versionados para rehash gradual após login.

15.10 Segurança em APIs

O OWASP API Security Top 10 de 2023 inclui autorização quebrada por objeto, autenticação quebrada, consumo irrestrito, SSRF, inventário inadequado e consumo inseguro de APIs [33]. O ASVS fornece requisitos verificáveis para controles de aplicações Web [34], enquanto as orientações REST detalham proteção de endpoints e credenciais em trânsito [43].

Controles:

• TLS e validação do servidor;
• autenticação e autorização por objeto/propriedade;
• schema e tamanho máximo;
• queries parametrizadas;
• rate limit por identidade, operação e custo;
• timeout, circuit breaker e egress permitido;
• paginação e limite de complexidade;
• idempotência;
• inventário de versões e endpoints;
• erros sem stack/segredo;
• logging e correlação.

SSRF

Uma função “importar documento pela URL” pode fazer o servidor acessar metadata cloud, painel interno ou loopback. Bloqueie esquemas, resolva/valide destino com cuidado, controle redirecionamentos, limite egress e use serviço isolado. Lista de bloqueio de IPs isolada é insuficiente diante de DNS e formatos alternativos.

15.11 Upload de arquivos

Upload combina risco de conteúdo, parser, armazenamento e execução. A OWASP recomenda allowlist de extensões, validação do tipo real, nome gerado, limites, armazenamento separado e análise apropriada [37].

Pipeline:

1. autenticar e autorizar;
2. limitar tamanho e quantidade;
3. gerar ID e remover controle do caminho;
4. verificar extensão, assinatura e parser;
5. armazenar fora da raiz executável;
6. bloquear execução e servir com tipo seguro;
7. analisar malware/CDR quando aplicável;
8. isolar parsing com CPU, memória e tempo limitados;
9. impedir zip bombs e path traversal;
10. registrar hash, dono, retenção e estado;
11. autorizar cada download.

MIME enviado pelo navegador é uma alegação, não prova.

15.12 Banco de dados

• conta por aplicação e ambiente;
• mínimo privilégio; relatório somente leitura;
• rede privada e autenticação forte;
• TLS quando a fronteira exige;
• parâmetros, nunca concatenação;
• patch e versão suportada;
• criptografia e chaves conforme classificação;
• auditoria de operações privilegiadas;
• backup isolado e restore testado;
• mascaramento em homologação;
• retenção e exclusão governadas.

Criptografia de disco protege mídia perdida, mas não impede aplicação comprometida de ler dados autorizados. Segurança de coluna/campo pode reduzir exposição, com custo de busca, chave e aplicação.

15.13 Containers e cloud

Container

Use as medidas do Capítulo 13: não root, capabilities mínimas, filesystem read-only, seccomp/LSM, limites, imagem assinada e atualizada, rede restrita, nenhum socket administrativo.

Cloud

Erros frequentes:

• bucket público;
• chave permanente em código;
• IAM *;
• banco com IP público;
• logs desativados;
• snapshot compartilhado;
• metadata acessível por SSRF;
• backup no mesmo domínio comprometível;
• conta root usada diariamente.

Prefira identidade de workload e credenciais curtas. Políticas devem definir ações e recursos, não apenas “acesso ao serviço”.

15.14 Zero Trust

Zero Trust não significa negar toda confiança nem autenticar incessantemente sem contexto. NIST SP 800-207 remove confiança implícita baseada apenas em localização ou propriedade e orienta decisões focadas em usuário, ativo e recurso [29].

Princípios aplicados:

• cada acesso tem sujeito, recurso, ação e contexto;
• rede interna não concede privilégio automático;
• dispositivo e identidade possuem estado;
• políticas são explícitas e de mínimo privilégio;
• telemetria retroalimenta decisão;
• segmentação limita movimento;
• sessões são reavaliadas conforme risco.

VPN coloca o cliente na rede; não resolve autorização por recurso.

15.15 Defesa em profundidade

Um único controle falha. Defesa em profundidade combina:

identidade → endpoint → rede → workload → aplicação → dados → backup → detecção

Exemplo de upload malicioso:

• proxy limita tamanho;
• API valida identidade e schema;
• storage não executa conteúdo;
• parser roda isolado;
• scanner analisa;
• saída é tratada como não confiável;
• egress do worker é restrito;
• logs detectam padrão;
• restore existe se conteúdo corromper índice.

As camadas precisam ser independentes o suficiente para que a mesma falha de configuração não desative todas.

15.16 LGPD e ciclo de vida

A Lei nº 13.709/2018 regula tratamento de dados pessoais no Brasil [36]. Segurança deve começar antes do banco:

1. qual finalidade legítima exige o dado?
2. qual base legal e papel do agente?
3. qual mínimo de campos?
4. quem acessa e por quanto tempo?
5. onde existem cópias, logs, embeddings e backups?
6. como titular exerce direitos?
7. quando e como eliminar ou anonimizar?
8. quais operadores/fornecedores participam?

Princípios como finalidade, adequação, necessidade, transparência, segurança, prevenção e responsabilização mudam arquitetura. “Aceitar termos” não corrige coleta excessiva.

Incidente com dados pessoais

Pela regulamentação vigente da ANPD, o controlador comunica incidentes capazes de acarretar risco ou dano relevante. A Resolução CD/ANPD nº 15/2024 estabelece prazo de três dias úteis para comunicação à ANPD, ressalvada legislação específica, e admite complementação fundamentada conforme as regras [37]. Avaliação jurídica e do encarregado deve integrar o plano; não espere terminar toda a perícia para iniciar governança.

Este material é técnico e não substitui orientação jurídica.

15.17 Gestão de vulnerabilidades

Um programa contínuo inclui:

1. inventário de ativos, versões e responsáveis;
2. descoberta por scanner, fornecedor, teste e pesquisa;
3. validação de exposição e aplicabilidade;
4. priorização por exploração conhecida, criticidade e controles;
5. correção, mitigação ou aceitação formal;
6. teste e implantação segura;
7. verificação da remediação;
8. métricas de cobertura e tempo.

CVSS mede severidade técnica, não o risco completo. Uma vulnerabilidade média explorada ativamente em serviço público pode vir antes de uma crítica não alcançável. O catálogo KEV da CISA registra vulnerabilidades conhecidamente exploradas e ajuda a priorizar [40].

Inventário precisa incluir plugins do GLPI, imagens base, pacotes Python, Nginx, banco, sistema operacional e firmware.

15.18 Cadeia de suprimentos e desenvolvimento seguro

Dependências, pipeline, registry, pacote e atualização formam uma cadeia. NIST SSDF 1.1 organiza práticas para preparar, proteger, produzir e responder a vulnerabilidades no desenvolvimento [35].

Controles:

• revisão e proteção de branch;
• dependências fixadas com mecanismo de verificação;
• build reproduzível quando viável;
• SBOM e transparência de componentes [41];
• assinatura e attestations;
• runner isolado e secrets mínimos;
• scan de código, dependência e imagem;
• promoção do mesmo artefato entre ambientes;
• rollback e provenance;
• processo de vulnerabilidade e atualização.

SBOM não corrige falha; informa onde o componente existe. Assinatura prova origem conforme a chave, não ausência de vulnerabilidades.

15.19 Hardening

Hardening reduz superfície:

• desabilitar serviço e porta não usados;
• remover contas e credenciais padrão;
• aplicar baseline por função;
• restringir administração;
• configurar log e relógio;
• patch e reboot planejados;
• proteger boot, firmware e console conforme risco;
• separar ambientes;
• validar drift;
• testar antes de produção.

Uma checklist copiada pode quebrar aplicação ou dar falsa confiança. Cada exceção deve ter justificativa, prazo e controle compensatório.

15.20 Logs, detecção e privacidade

Logs de segurança devem permitir reconstruir:

• quem apresentou qual identidade;
• qual decisão de autorização ocorreu;
• qual recurso e ação;
• origem e dispositivo relevantes;
• resultado e motivo;
• request_id, sessão e evento;
• mudança administrativa;
• acesso a dado sensível.

Não registre senha, token, chave, cookie, documento inteiro ou prompt confidencial. Proteja logs contra alteração, limite acesso, sincronize tempo e defina retenção. Alerta precisa de responsável e ação; volume sem resposta é apenas armazenamento caro.

15.21 Resposta a incidentes

NIST SP 800-61 Rev. 3 integra resposta ao ciclo de gestão do CSF 2.0, enfatizando preparação contínua, detecção, resposta, recuperação e melhoria [30].

Fluxo operacional:

1. preparar: papéis, contatos, ferramentas, backups, playbooks e autoridade;
2. detectar e analisar: validar sinal, escopo, impacto e linha do tempo;
3. conter: limitar dano preservando evidência;
4. erradicar: remover causa e acesso do invasor;
5. recuperar: restaurar, monitorar e validar função;
6. aprender: corrigir fatores sistêmicos e medir ações.

Não desligue ou formate automaticamente. Em alguns incidentes isso destrói memória e logs; em outros, isolar imediatamente é essencial. Playbooks definem decisão por cenário.

Evidência

Registre quem coletou, quando, origem, hash, ferramenta, armazenamento e transferências. Cadeia de custódia importa quando evidência pode sustentar medida disciplinar, contratual ou legal.

15.22 Segurança de IA e RAG

Um documento recuperado não é instrução confiável. Prompt injection indireta ocorre quando conteúdo externo tenta alterar o comportamento do modelo. NIST documenta riscos específicos de IA generativa [38][45], e o OWASP LLM Top 10 2026 atualiza riscos de aplicações com modelos [39].

Riscos de RAG:

• documento malicioso com instruções ocultas;
• vazamento entre tenants na busca vetorial;
• embedding de dados que deveriam ser eliminados;
• recuperação sem autorização por documento;
• saída do modelo usada como SQL, shell ou ação;
• prompt/log com dado pessoal;
• dependência/modelo adulterado;
• consumo de tokens/GPU como negação de serviço;
• resposta falsa tratada como fato.

Controles:

• autorizar antes e depois da recuperação;
• separar coleções/tenants e filtrar por ACL;
• tratar contexto como dados não confiáveis;
• limitar ferramentas, egress e privilégios do agente;
• validar saída antes de qualquer ação;
• exigir confirmação humana para alto impacto;
• registrar fontes e versão de modelo/prompt;
• avaliar ataques e vazamento com conjunto de testes;
• aplicar retenção/exclusão também ao índice;
• nunca colocar segredo no system prompt como mecanismo de proteção.

Um modelo que sugere prioridade no GLPI não deve possuir token administrativo nem executar atualização sem política determinística.

15.23 Estudo de caso: GLPI com LDAP, API, Slack e anexos

Ativos

• identidades sincronizadas do AD;
• tickets de TI, Jurídico, RH e Fiscal;
• anexos;
• tokens de API;
• regras de entidade/grupo;
• histórico e logs;
• backup e banco.

Ameaças e controles

Matriz de acesso resumida

15.24 Síntese do capítulo

• Segurança governa risco ao longo do ciclo, não apenas bloqueia ataques.
• Autenticação não concede autorização sobre qualquer objeto.
• MFA varia em resistência; senhas não resistem a phishing.
• Criptografia depende de chaves, algoritmos e ciclo de vida.
• Upload, API, banco, container e cloud exigem controles próprios.
• Zero Trust remove confiança implícita de localização.
• LGPD afeta coleta, acesso, retenção, incidente e descarte.
• Vulnerabilidade deve ser priorizada por exposição e impacto.
• RAG introduz fronteira entre dados não confiáveis e instruções.

Notas Zettelkasten — Capítulo 15

ZK-053 — Segurança como ciclo
Ideia: governar, identificar, proteger, detectar, responder e recuperar formam
um sistema contínuo de redução de risco.
Conexões: ZK-052 — Responsabilidade; ZK-058 — Resposta a incidentes.

ZK-054 — Integridade e autenticidade
Ideia: hash detecta mudança com referência; MAC/assinatura ligam integridade
a uma chave e modelo de identidade.
Conexões: ZK-039 — Âncora de integridade; ZK-057 — Cadeia de suprimentos.

ZK-055 — Mínimo privilégio por objeto
Ideia: identidade autenticada recebe somente ações necessárias sobre recursos
autorizados no contexto atual.
Conexões: ZK-052 — Responsabilidade; ZK-059 — Segurança de RAG.

ZK-056 — Privacidade é ciclo de dados
Ideia: finalidade, minimização, acesso, retenção, cópias e eliminação precisam
ser desenhados do upload ao backup e embedding.
Conexões: ZK-038 — Texto; ZK-059 — Segurança de RAG.

ZK-057 — Cadeia de suprimentos
Ideia: SBOM dá visibilidade e assinatura dá provenance; nenhuma substitui teste,
atualização e resposta.
Conexões: ZK-048 — Imagem; ZK-054 — Autenticidade.

ZK-058 — Incidente exige preparação
Ideia: conter, preservar evidência e recuperar dependem de autoridade, contatos,
telemetria e backup definidos antes da crise.
Conexões: ZK-035 — Recuperação verificável; ZK-053 — Segurança como ciclo.

ZK-059 — Contexto de RAG é não confiável
Ideia: documento recuperado pode conter instruções hostis; autorização e validação
envolvem retrieval, modelo, ferramentas e saída.
Conexões: ZK-055 — Mínimo privilégio; ZK-056 — Privacidade.

Recuperação ativa — Capítulo 15

1. Diferencie ameaça, vulnerabilidade, exposição e risco.
2. Por que autenticação bem-sucedida não autoriza qualquer ticket?
3. O que torna um autenticador resistente a phishing?
4. Compare hash, HMAC, assinatura e criptografia.
5. Por que SHA-256 é inadequado para armazenar senha?
6. Como SSRF pode alcançar metadata cloud?
7. Por que MIME enviado pelo navegador não prova o tipo do arquivo?
8. O que Zero Trust remove do modelo tradicional?
9. Como a LGPD altera embeddings e backups?
10. Por que CVSS não define sozinho prioridade?
11. O que SBOM prova e o que não prova?
12. Como um documento pode atacar uma aplicação RAG?

Estudo de caso integrado — Plataforma de conhecimento com RAG

1. Contexto

A organização mantém a plataforma KnowledgeBasePro para artigos técnicos, documentos e respostas assistidas por IA. A aplicação Flask é publicada pelo Nginx em um prefixo Web, usa Redis e RQ para trabalhos assíncronos, armazena documentos em volume persistente, mantém metadados e índices em banco e solicita inferência ao Ollama. Parte do conteúdo pode ser importada da API do GLPI.

Requisitos:

• o upload deve sobreviver à recriação de containers;
• cada tenant vê apenas seu conteúdo;
• arquivos suspeitos não são processados no contexto da aplicação Web;
• falha da IA não derruba leitura de artigos;
• tarefas duplicadas não geram duplicidade lógica;
• documentos e embeddings seguem retenção e exclusão;
• o ambiente suporta restore testado;
• custo e capacidade são medidos por documento e consulta.

2. Arquitetura conceitual

flowchart TB
    U["Usuário"] --> N["Nginx / TLS"]
    N --> W["Flask Web"]
    W --> S["Storage de documentos"]
    W --> R["Redis / RQ"]
    R --> K["Worker isolado"]
    K --> O["Ollama"]
    K --> D["PostgreSQL / índice"]
    W --> D
    K --> G["API GLPI"]

Fronteiras

3. Do bit ao resultado

Recepção

1. O navegador codifica o nome e os bytes no corpo HTTP.
2. Nginx valida tamanho máximo do request e transmite por TLS.
3. Flask autentica, autoriza a coleção e cria document_id.
4. O arquivo é gravado em storage persistente com nome interno.
5. Tamanho, SHA-256, MIME detectado, dono e retenção são registrados.

Processamento

6. A aplicação publica job com document_id e chave idempotente.
7. RQ entrega o trabalho; o worker verifica se aquela versão já foi processada.
8. Um parser isolado extrai texto com CPU, memória e tempo limitados.
9. Unicode é normalizado para busca segundo política, preservando bytes originais.
10. O chunker gera trechos com versão e origem.
11. O serviço produz embeddings e os grava com tenant_id, document_id e ACL.
12. O estado muda para indexed; falhas permanecem reprocessáveis.

Consulta

13. O usuário envia pergunta.
14. A aplicação autoriza a coleção antes da busca.
15. O retrieval filtra tenant e ACL no próprio acesso, não apenas depois.
16. Trechos são tratados como dados não confiáveis e passados ao modelo.
17. A resposta inclui referências e não executa ações.
18. Logs registram IDs, duração e resultado sem conteúdo sensível desnecessário.

4. Modelo de estado

stateDiagram-v2
    [*] --> Received
    Received --> Validating
    Validating --> Rejected
    Validating --> Queued
    Queued --> Processing
    Processing --> Indexed
    Processing --> Failed
    Failed --> Queued: retry autorizado
    Rejected --> [*]
    Indexed --> [*]

Estado explícito evita que 201 Created seja interpretado como indexação concluída. Cada transição registra versão, tentativa, erro classificável e horário.

5. Persistência

Embeddings podem ser reconstruíveis, mas o tempo e custo precisam caber no RTO. Se o índice leva dois dias para refazer, chamá-lo de descartável não atende recuperação de duas horas.

6. Capacidade e backpressure

Suponha:

Host:               16 GiB RAM
Sistema/overhead:    2 GiB
Web (2 workers):     2 GiB
PostgreSQL/Redis:    3 GiB
Ollama:              7 GiB
Reserva operacional: 2 GiB

Não sobra memória para dois parsers com pico de 1,5 GiB. A fila deve limitar concorrência a um ou o Ollama precisa de host separado/modelo menor. O cálculo é ponto de partida; RSS, page cache, VRAM e picos reais precisam ser medidos.

Backpressure:

• limite de uploads ativos por tenant;
• fila com prioridade e tamanho máximo;
• worker com concorrência calculada;
• rejeição ou espera explícita quando saturado;
• timeout por etapa;
• alerta pela idade do job mais antigo;
• autoscaling apenas até capacidade do banco/modelo.

7. Falha encadeada

Linha do tempo

09:00 deploy altera /app/uploads para /app/app/staging_uploads
09:05 primeiro PDF é gravado na camada do container
09:06 worker lê arquivo e consome 2,8 GiB
09:07 cgroup encerra worker por OOM
09:08 RQ repete job sem deduplicação
09:09 três workers processam o mesmo PDF
09:10 host entra em pressão; Nginx devolve 504
09:15 container é recriado; arquivo desaparece

Causa e fatores

• causa de perda: mount e caminho da aplicação divergiam;
• causa de repetição: job sem estado idempotente;
• fator amplificador: concorrência sem orçamento de memória;
• falha de detecção: não havia métrica de OOM, idade de fila nem smoke test de persistência;
• falha de processo: deploy validou endpoint, não ciclo completo.

Correção sistêmica

1. uma configuração canônica para o caminho;
2. teste que recria container e confirma o mesmo documento;
3. job único por documento, versão e pipeline;
4. lock/estado transacional com retomada por etapa;
5. limite de concorrência e tamanho;
6. alerta de OOM e fila;
7. implantação canário com documento sintético;
8. restore exercitado fora do host.

8. Segurança da recuperação

O atacante que compromete a conta da aplicação não deve apagar todos os backups. Use identidade separada, retenção/imutabilidade quando disponível, logs e cópia fora do domínio. O exercício de restore valida:

• banco em ponto escolhido;
• vínculo entre metadado e arquivo;
• permissões de tenant;
• versão do parser/modelo;
• reprocessamento de índice;
• chaves e secrets;
• RPO/RTO medidos.

9. Critérios de aceite

• 99% dos uploads até 25 MiB são aceitos ou rejeitados explicitamente em até 5 s;
• 95% dos documentos válidos até 100 páginas são indexados em até 3 min sob carga nominal;
• recriar Web e worker não remove originais;
• repetir o mesmo evento não cria segunda versão lógica;
• consulta de tenant A nunca retorna chunk de tenant B em testes positivos e negativos;
• falha do Ollama preserva leitura e reprocessamento;
• nenhum workload possui credencial administrativa do GLPI;
• restore mensal comprova RPO e RTO;
• custo por documento e por 1.000 consultas possui orçamento e alerta;
• toda resposta de IA de alto impacto exige validação humana.

Laboratório prático orientado

Objetivo e segurança

Produzir um diagnóstico de representação, capacidade, persistência, isolamento e exposição sem alterar produção. Execute somente em ambiente autorizado. Não imprima conteúdo de secrets, tokens ou arquivos pessoais.

Etapa 1 — Representação de um arquivo

Escolha um arquivo de laboratório:

file exemplo.pdf
file --mime exemplo.pdf
stat exemplo.pdf
sha256sum exemplo.pdf
xxd -l 32 exemplo.pdf
```Registre:
- tamanho em bytes;
- MIME alegado e detectado;
- assinatura inicial;
- hash;
- datas e permissões.

Renomear `exemplo.txt` para `.pdf` altera apenas o nome. O conteúdo detectado deve continuar texto.

Para UTF-8, use um arquivo não sensível:
```bash
file --mime texto.txt
iconv -f UTF-8 -t UTF-8 texto.txt >/dev/null

O segundo comando valida a sequência sob a premissa informada, sem corrigir semântica ou normalização.

Etapa 2 — Arquitetura e memória

lscpu
free -h
vmstat 1
cat /proc/meminfo

Se numactl estiver instalado:

numactl --hardware
```Perguntas:
1. quantos sockets, núcleos e threads lógicas?
2. virtualização é indicada?
3. existem nós NUMA?
4. memória disponível difere de memória livre?
5. há swap ativa durante a observação?

## Etapa 3 — Storage e filesystem
```bash
lsblk -f
findmnt
df -h
df -i
stat /caminho/autorizado
namei -l /caminho/autorizado

Se a política permitir:

iostat -xz 1

Documente filesystem, mount, capacidade, inodes, opções e identidade necessária. Não rode reparo, benchmark ou varredura intensa em produção.

Etapa 4 — Persistência Docker

Sem revelar variáveis:

docker ps --format 'table {{.Names}}\t{{.Image}}\t{{.Status}}'
docker inspect nome-do-container \
  --format '{{range .Mounts}}{{println .Type .Source "->" .Destination}}{{end}}'
docker volume ls
docker stats --no-stream

Compare caminho configurado pela aplicação com Destination. Identifique:

• volume de uploads;
• dados do banco;
• usuário efetivo;
• limites de CPU/memória;
• política de restart;
• health check.

Não use docker compose down -v, docker volume prune ou remoções durante diagnóstico.

Etapa 5 — Isolamento

docker inspect nome-do-container \
  --format 'user={{.Config.User}} privileged={{.HostConfig.Privileged}} readonly={{.HostConfig.ReadonlyRootfs}}'
docker inspect nome-do-container \
  --format 'cap_add={{json .HostConfig.CapAdd}} cap_drop={{json .HostConfig.CapDrop}}'

Avalie, sem alterar:

• roda como root?
• está privilegiado?
• filesystem pode ser read-only?
• quais capabilities são necessárias?
• monta socket do Docker ou raiz do host?
• rede permite egress irrestrito?

Etapa 6 — Fluxo completo

Envie um documento sintético sem dados reais e registre:

Recrie apenas containers de laboratório e verifique se o documento permanece. Depois, repita o mesmo job e confirme idempotência.

Etapa 7 — Exercício de restore em ambiente isolado

Não restaure sobre produção. Em staging descartável:

1. registre ponto de recuperação escolhido;
2. crie infraestrutura vazia;
3. restaure banco e documentos;
4. aplique configuração e chaves autorizadas;
5. valide contagem, hashes e ACLs;
6. execute consulta representativa;
7. meça perda e tempo;
8. destrua o ambiente conforme política, preservando relatório.

Resultado:

RPO observado:
RTO observado:
Itens ausentes:
Inconsistências:
Dependências manuais:
Ações corretivas:

Etapa 8 — Threat model reduzido

Preencha:

Etapa 9 — Relatório

```text
Escopo e autorização:
Arquitetura observada:
Inventário e versões:

Hipóteses:
Evidências:
Riscos:
Lacunas de observabilidade:

Recomendação imediata:
Correção estrutural:
Validação proposta:
Responsável e prazo:
```—

Exercícios gerais da Parte 3

Bloco A — Representação e arquitetura

1. Mostre duas interpretações possíveis para 01000001.
2. Por que uma estrutura C pode ocupar mais bytes que a soma dos campos?
3. Explique por que dinheiro não deve depender de float binário sem decisão explícita.
4. Diferencie code point, code unit, byte e grapheme cluster.
5. Um nome parece idêntico e possui hash diferente. Proponha três hipóteses.
6. Calcule o tamanho bruto de uma imagem 3840 × 2160 RGB de 8 bits por canal.
7. Diferencie codec e container em um vídeo.
8. O que Base64 faz e por que aumenta tamanho?
9. Compare ISA e microarquitetura.
10. Por que oito threads lógicas não garantem desempenho de oito núcleos?
11. Aplique a Lei de Amdahl a um trabalho 90% paralelizável com quatro núcleos.
12. Compare latência, throughput e IOPS para banco e streaming.

Bloco B — Filesystem e virtualização

13. Como um arquivo apagado continua ocupando espaço?
14. Por que chmod 777 é diagnóstico ruim?
15. O que fsync tenta garantir e por que a cadeia ainda importa?
16. Compare journaling, snapshot, réplica e backup.
17. Quando object storage não substitui um filesystem?
18. Diferencie volume e bind mount Docker.
19. Por que a camada gravável não deve armazenar uploads?
20. Compare VM, emulação e container.
21. O que significa CPU overcommit de 2:1?
22. Como noisy neighbor de storage afeta VM com CPU livre?
23. Por que uma tag de imagem não garante conteúdo imutável?
24. Dê um exemplo correto de liveness e outro de readiness.

Bloco C — Cloud e segurança

25. Liste as cinco características essenciais de cloud segundo o NIST.
26. Diferencie elasticidade de disponibilidade.
27. Como a responsabilidade muda de IaaS para SaaS?
28. Por que Multi-AZ não é automaticamente multi-região?
29. Defina uma métrica de custo por valor para RAG.
30. Dê um exemplo de lock-in vantajoso e um de lock-in não governado.
31. Diferencie ameaça, vulnerabilidade e exposição em uma API pública.
32. Por que MFA por SMS e passkey não possuem a mesma resistência?
33. Como autorização por objeto evita leitura de outro ticket?
34. Compare criptografia, hash, HMAC e assinatura.
35. Por que criptografar banco não corrige SQL injection?
36. Proponha controles para upload de PDF.
37. Como Zero Trust muda o acesso vindo da rede interna?
38. Por que vulnerabilidade crítica pode receber prioridade inferior a uma média?
39. O que uma SBOM permite fazer?
40. Como prompt injection indireta entra por documento RAG?

Bloco D — Casos

41. O worker sofre OOM apenas durante OCR. Monte plano de evidências e contenção.
42. Uploads somem depois de deploy. Que comandos não destrutivos separam volume e camada?
43. Banco gerenciado está disponível, mas aplicação falha. Liste cinco responsabilidades do cliente.
44. Um token do GLPI apareceu em log. Defina resposta imediata e estrutural.
45. Um usuário do Jurídico recebeu trecho de RH na resposta RAG. Trate como incidente: contenção, escopo, evidência e correção.
46. Backup restaura o banco, mas não os documentos. Qual erro de desenho ocorreu?
47. Autoscaling de workers derruba PostgreSQL. Explique e redesenhe o limite.
48. Um arquivo possui SHA-256 correto, mas veio de fonte maliciosa. Por que a verificação passou?

Direções de resposta

1. Pode ser 65 decimal, A ou flags; o contexto define.
2. Alinhamento e padding da ABI.
3. Muitos decimais não têm representação binária finita; use decimal/unidade mínima.
4. Retome a seção 10.8 e dê um emoji como exemplo de múltiplas unidades.
5. Codificação, normalização, byte invisível ou metadado diferente.
6. 3840 × 2160 × 3 = 24.883.200 bytes, antes de compressão.
7. Codec comprime streams; container os reúne.
8. Codifica bytes em alfabeto textual; grupos e padding geram overhead.
9. ISA é contrato; microarquitetura, implementação.
10. SMT compartilha recursos do núcleo.
11. 1 / (0,1 + 0,9/4) ≈ 3,08.
12. Banco pequeno e síncrono valoriza latência/IOPS; streaming, throughput sustentado.
13. Descritor aberto ou outro hard link mantém o objeto.
14. Amplia privilégio e não explica identidade, ACL ou caminho.
15. Solicita sincronização conforme contrato; controlador e mídia ainda precisam cumprir.
16. Cada mecanismo protege uma falha diferente; snapshot/replica não são cópias isoladas por definição.
17. Quando a aplicação depende de rename, locks, paths e semântica POSIX.
18. Volume é gerenciado pelo engine; bind referencia caminho do host.
19. Ela pertence ao ciclo do container.
20. VM possui kernel convidado; emulação pode traduzir ISA; container compartilha kernel.
21. Duas vCPUs configuradas para cada CPU física, assumindo uso não simultâneo.
22. Todas as VMs dependem da mesma fila/dispositivo.
23. Tag é ponteiro mutável; digest identifica conteúdo.
24. Liveness detecta deadlock local; readiness retira instância sem banco essencial.
25. Autosserviço, acesso amplo, pool, elasticidade rápida e serviço medido.
26. Elasticidade ajusta capacidade; disponibilidade mantém função.
27. O provedor assume mais camadas; identidade, configuração e dados continuam com o cliente.
28. Zona isola datacenter dentro da região; falha regional exige outra estratégia.
29. Custo total dividido por documentos indexados ou consultas úteis, com qualidade/SLO.
30. Serviço gerenciado pode acelerar produto; ausência de exportação/plano é lock-in não governado.
31. Atacante é ameaça; BOLA é vulnerabilidade; endpoint público é exposição.
32. Passkey vincula chave ao origin; SMS pode ser phished/interceptado.
33. Política verifica identidade, entidade, papel e o ticket específico.
34. Use a tabela da seção 15.7.
35. A aplicação autorizada continua capaz de enviar query maliciosa.
36. Limite, nome interno, assinatura, parser seguro, sandbox, storage isolado e autorização no download.
37. Localização deixa de conceder confiança implícita.
38. Exploração ativa, exposição e impacto contextual podem dominar o score.
39. Localizar componentes/versões e responder a vulnerabilidade; não prova segurança.
40. O retrieval insere conteúdo controlado por terceiro no contexto do modelo.
    41–48. A resposta deve separar causa, fator amplificador, contenção, evidência e prevenção mensurável.

Projeto prático final — Arquitetando uma Plataforma Corporativa Segura

Objetivo

Projetar uma plataforma de conhecimento que importa artigos e anexos do GLPI, aceita documentos de usuários, processa RAG e publica respostas com fontes. O projeto deve justificar decisões, não apenas desenhar ícones.

Requisitos mínimos

• 1.000 usuários cadastrados e 100 simultâneos;
• 50 mil documentos, crescimento de 2 mil/mês;
• documentos até 100 MiB, com limite diferente por perfil;
• isolamento entre áreas/tenants;
• integração assíncrona com GLPI;
• aplicação Flask, Redis/RQ, PostgreSQL e Ollama;
• implantação em Docker, VM ou cloud justificada;
• SLO de leitura de 99,5%;
• RPO máximo de 15 minutos e RTO de 2 horas;
• custo mensal acompanhado por unidade;
• conformidade com política de dados pessoais;
• resposta a upload malicioso e vazamento de token.

Entregável 1 — Diagrama de arquitetura

O diagrama deve mostrar:

• usuários e identidades;
• entrada pública e TLS;
• Web/API, fila e workers;
• storage de documentos;
• banco e índice;
• modelo de IA;
• GLPI;
• logs/métricas/traces;
• backup e domínio de recuperação;
• zonas de confiança e protocolos.

Entregável 2 — Tabela de componentes

Preencha todos os componentes. “Alta disponibilidade” sem mecanismo e teste não é resposta.

Entregável 3 — Modelo de dados e ciclo do documento

Defina:

• IDs, versão e hash;
• estados e transições;
• tenant/ACL;
• metadados do arquivo;
• versão de parser, chunker, embedding e modelo;
• retenção/exclusão do original, texto, chunks, embeddings, logs e backups;
• idempotência e reconciliação.

Entregável 4 — Capacidade

Estime:

• CPU/RAM por Web, parser e modelo;
• capacidade e inodes/objetos;
• IOPS/throughput de banco e storage;
• concorrência máxima;
• tamanho/idade da fila;
• custo por documento e consulta;
• limites e alertas.

Registre premissas e proponha teste de carga.

Entregável 5 — Segurança

Produza:

• inventário de ativos e classificação;
• threat model com pelo menos dez cenários;
• matriz de acesso;
• proteção de secrets e chaves;
• controles de upload;
• autorização do retrieval;
• segurança de container/cloud;
• supply chain e SBOM;
• logging sem dados indevidos;
• plano de vulnerabilidades;
• tratamento de prompt injection.

Entregável 6 — Recuperação

Defina:

• RPO/RTO por dado;
• backup, retenção e imutabilidade;
• restauração de banco, documentos e índice;
• dependências de chave;
• frequência de teste;
• critérios de sucesso;
• failover e fallback quando Ollama falhar.

Entregável 7 — Runbooks

Escreva procedimentos para:

1. upload desaparecido;
2. worker em OOM loop;
3. token do GLPI exposto;
4. vazamento entre tenants;
5. banco indisponível;
6. restore completo;
7. custo de IA acima do orçamento.

Cada runbook deve incluir gatilho, autoridade, evidência, contenção, rollback, validação e comunicação.

Critérios de avaliação

Glossário técnico

ABAC: autorização baseada em atributos de sujeito, recurso, ação e contexto.

ACL: lista que associa identidades a permissões sobre um objeto.

Argon2id: função de derivação indicada para armazenamento de senhas conforme parâmetros adequados.

Artefato: saída versionada de build, como imagem, pacote ou binário.

Availability Zone: domínio de datacenter isolado dentro de uma região conforme o provedor.

Backpressure: mecanismo que reduz ou rejeita entrada quando a capacidade a jusante está saturada.

Bare metal: execução diretamente em servidor físico, sem VM como fronteira principal.

Base64: codificação de bytes em alfabeto textual; não oferece confidencialidade.

Bind mount: montagem de um caminho específico do host dentro do container.

Bit: unidade abstrata com dois valores possíveis.

Byte: unidade de oito bits.

CaaS: serviço gerenciado de plataforma/execução de containers em graus variados.

Cache line: unidade transferida e coerente na hierarquia de cache.

Capability: subdivisão de privilégios tradicionalmente associados a root no Linux.

cgroup: mecanismo do kernel para contabilizar, limitar e priorizar recursos de processos.

Codec: algoritmo/formato que codifica e decodifica áudio, vídeo ou outro sinal.

Code point: posição numérica de um caractere abstrato no Unicode.

Code unit: unidade de armazenamento usada por uma codificação Unicode.

Container: conjunto de processos isolados que compartilha o kernel do host.

Copy-on-write: estratégia que grava nova versão antes de trocar referências existentes.

Digest: resumo criptográfico usado para identificar conteúdo, como uma imagem OCI.

DMA: transferência entre dispositivo e memória com intervenção reduzida da CPU por byte.

Elasticidade: ajuste de capacidade à demanda dentro de tempo e limites definidos.

Embedding: representação vetorial usada para proximidade semântica; pode carregar informação sensível.

Emulação: reprodução de hardware ou ISA, inclusive diferente da máquina hospedeira.

Endianness: ordem dos bytes em um valor multibyte.

FaaS: execução gerenciada de funções acionadas por eventos ou requisições.

Failure domain: conjunto de componentes sujeitos à mesma causa de falha.

FinOps: prática de maximização de valor e responsabilidade financeira sobre tecnologia.

Grapheme cluster: sequência percebida pelo usuário como uma unidade textual.

Hard link: outro nome para o mesmo objeto de filesystem.

Hash: resumo unidirecional; não prova autenticidade sozinho.

HMAC: código de autenticação baseado em hash e segredo compartilhado.

Hipervisor: plataforma que virtualiza recursos e isola máquinas virtuais.

IaaS: serviço de infraestrutura virtual no qual o consumidor administra o guest e a aplicação.

IaC: definição versionável de infraestrutura por código/configuração declarativa.

Idempotência: repetição produz o mesmo efeito lógico pretendido.

Imagem OCI: artefato de container composto por manifest, configuração e camadas.

Inode: estrutura de metadados de objetos em filesystems Unix específicos; o nome fica no diretório.

IOMMU: tradução e controle de acessos de dispositivos à memória.

IOPS: operações de entrada/saída por segundo sob parâmetros definidos.

ISA: contrato de instruções e estado visível ao software.

Journaling: registro de atualizações para recuperação de consistência do filesystem.

KMS: serviço/sistema de gestão do ciclo de chaves criptográficas.

Liveness: sinal de que reiniciar o container pode recuperar falha local.

MAC: código de autenticação de mensagem com chave compartilhada.

Microarquitetura: implementação concreta de uma ISA.

MIME type: rótulo de tipo de mídia; valor declarado pelo cliente precisa ser validado.

Namespace: mecanismo que fornece a processos uma visão isolada de recursos do kernel.

Noisy neighbor: workload que degrada outros ao competir por recurso compartilhado.

Normalização Unicode: transformação para uma forma canônica ou de compatibilidade definida.

NUMA: arquitetura em que custo de acesso à memória varia conforme o nó.

Object storage: armazenamento acessado por chave/objeto e API, sem promessa POSIX automática.

Overcommit: alocação lógica superior ao recurso físico, baseada em uso não simultâneo.

PaaS: plataforma gerenciada na qual o consumidor entrega aplicação e dados.

Passkey: credencial baseada em chave pública e autenticador, normalmente vinculada ao origin.

Pipeline: sequência de etapas sobrepostas ou encadeadas de processamento.

Prompt injection: entrada que tenta alterar indevidamente o comportamento de um modelo.

Provenance: informação verificável sobre origem e processo de produção de um artefato.

Readiness: sinal de que uma instância pode receber tráfego.

RAG: geração aumentada por recuperação de conteúdo externo.

RBAC: autorização baseada em papéis.

Região: área geográfica de serviços de um provedor de cloud.

RPO: perda máxima de dados tolerável medida no tempo.

RTO: tempo alvo para restabelecer a função.

SaaS: aplicação completa oferecida como serviço.

Sandbox: ambiente restrito para executar conteúdo ou código não confiável.

SBOM: inventário dos componentes que formam software.

Seccomp: mecanismo Linux para filtrar chamadas de sistema.

Secret: credencial ou material sensível usado por sistemas.

SLI: indicador medido de comportamento do serviço.

SLO: objetivo interno para um SLI em janela definida.

Snapshot: visão de estado em um ponto, frequentemente no mesmo domínio do armazenamento.

Startup probe: verificação que protege inicialização lenta antes de liveness/readiness.

Tag: referência nominal mutável a imagem ou artefato.

Tenant: domínio lógico de cliente/organização isolado dos demais.

Throughput: volume de trabalho ou bytes concluídos por tempo.

TOCTOU: condição em que o objeto muda entre verificação e uso.

Unicode: padrão de caracteres, propriedades e algoritmos; não é uma única codificação.

UTF-8: codificação Unicode com unidades de oito bits e sequências de um a quatro bytes.

Volume: armazenamento persistente gerenciado e montado no container.

WebAuthn: API Web para autenticação com credenciais de chave pública.

Zero Trust: arquitetura sem confiança implícita baseada apenas em localização ou propriedade.

Referências técnicas e bibliográficas

As especificações e documentações Web foram verificadas em 31 de agosto de 2026. Em implantação, confirme a versão do sistema realmente utilizado.

[1] SHANNON, Claude E. A Mathematical Theory of Communication. Bell System Technical Journal, 1948.

[2] THE UNICODE CONSORTIUM. The Unicode Standard, Version 17.0 — Chapter 3. Disponível em: https://www.unicode.org/versions/Unicode17.0.0/core-spec/chapter-3/.

[3] THE UNICODE CONSORTIUM. Unicode Standard Annex #29 — Unicode Text Segmentation. Disponível em: https://www.unicode.org/reports/tr29/.

[4] NIST. Definitions of the SI units: the binary prefixes. Disponível em: https://physics.nist.gov/cuu/Units/binary.html.

[5] IEEE. IEEE/ISO/IEC 60559-2020 — Floating-Point Arithmetic. Disponível em: https://standards.ieee.org/.

[6] IETF. RFC 4648 — The Base16, Base32, and Base64 Data Encodings. Disponível em: https://www.rfc-editor.org/info/rfc4648.

[7] PATTERSON, David A.; HENNESSY, John L. Computer Organization and Design. Morgan Kaufmann.

[8] TANENBAUM, Andrew S.; AUSTIN, Todd. Structured Computer Organization. Pearson.

[9] SILBERSCHATZ, Abraham; GALVIN, Peter B.; GAGNE, Greg. Operating System Concepts. Wiley.

[10] LINUX KERNEL. NUMA Memory Performance e Physical Memory. Disponíveis em: https://docs.kernel.org/admin-guide/mm/numaperf.html e https://docs.kernel.org/mm/physical_memory.html.

[11] LINUX KERNEL. ext4 Data Structures and Algorithms e Journalling API. Disponíveis em: https://docs.kernel.org/filesystems/ext4/ e https://docs.kernel.org/filesystems/journalling.html.

[12] MICROSOFT. NTFS overview e Access Control Overview. Disponíveis em: https://learn.microsoft.com/en-us/windows-server/storage/file-server/ntfs-overview e https://learn.microsoft.com/en-us/windows/security/identity-protection/access-control/access-control.

[13] OPENZFS. Basic Concepts e Checksums and Their Use in ZFS. Disponíveis em: https://openzfs.github.io/openzfs-docs/Basic%20Concepts/index.html e https://openzfs.github.io/openzfs-docs/Basic%20Concepts/Data%20Storage/Checksums.html.

[14] KERRISK, Michael. Linux man-pages — open(2), fsync(2), rename(2) e unlink(2). Disponível em: https://man7.org/linux/man-pages/.

[15] DOCKER. OverlayFS storage driver. Disponível em: https://docs.docker.com/engine/storage/drivers/overlayfs-driver/.

[16] DOCKER. Volumes e Storage. Disponíveis em: https://docs.docker.com/engine/storage/volumes/ e https://docs.docker.com/engine/storage/.

[17] LINUX KERNEL. Namespaces. Disponível em: https://docs.kernel.org/admin-guide/namespaces/index.html.

[18] LINUX KERNEL. Control Group v2. Disponível em: https://docs.kernel.org/admin-guide/cgroup-v2.html.

[19] OPEN CONTAINER INITIATIVE. Runtime, Image and Distribution Specifications. Disponível em: https://opencontainers.org/about/overview/.

[20] DOCKER. Docker Engine Security. Disponível em: https://docs.docker.com/engine/security/.

[21] KUBERNETES. Deployments. Disponível em: https://kubernetes.io/docs/concepts/workloads/controllers/deployment/.

[22] KUBERNETES. Liveness, Readiness, and Startup Probes. Disponível em: https://kubernetes.io/docs/concepts/workloads/pods/probes/.

[23] KUBERNETES. Persistent Volumes. Disponível em: https://kubernetes.io/docs/concepts/storage/persistent-volumes/.

[24] NIST. SP 800-125A Rev. 1 — Security Recommendations for Server-based Hypervisor Platforms. Disponível em: https://csrc.nist.gov/pubs/sp/800/125/a/r1/final.

[25] NIST. SP 800-145 — The NIST Definition of Cloud Computing. Disponível em: https://csrc.nist.gov/pubs/sp/800/145/final.

[26] MICROSOFT. Reliability in Azure e Availability Zones. Disponíveis em: https://learn.microsoft.com/en-us/azure/reliability/overview e https://learn.microsoft.com/en-us/azure/reliability/availability-zones-overview.

[27] FINOPS FOUNDATION. FinOps Framework. Disponível em: https://www.finops.org/framework/.

[28] NIST. Cybersecurity Framework 2.0. Disponível em: https://csrc.nist.gov/pubs/cswp/29/the-nist-cybersecurity-framework-csf-20/final.

[29] NIST. SP 800-207 — Zero Trust Architecture. Disponível em: https://csrc.nist.gov/pubs/sp/800/207/final.

[30] NIST. SP 800-61 Rev. 3 — Incident Response Recommendations and Considerations for Cybersecurity Risk Management. Disponível em: https://csrc.nist.gov/pubs/sp/800/61/r3/final.

[31] NIST. SP 800-63B-4 — Digital Identity Guidelines: Authentication and Authenticator Management. Disponível em: https://pages.nist.gov/800-63-4/sp800-63b.html.

[32] OWASP. Password Storage Cheat Sheet. Disponível em: https://cheatsheetseries.owasp.org/cheatsheets/Password_Storage_Cheat_Sheet.html.

[33] OWASP. API Security Top 10 — 2023. Disponível em: https://owasp.org/www-project-api-security/.

[34] OWASP. Application Security Verification Standard. Disponível em: https://owasp.org/www-project-application-security-verification-standard/.

[35] NIST. SP 800-218 — Secure Software Development Framework Version 1.1. Disponível em: https://csrc.nist.gov/pubs/sp/800/218/final.

[36] BRASIL. Lei nº 13.709, de 14 de agosto de 2018 — Lei Geral de Proteção de Dados Pessoais. Disponível em: https://www.planalto.gov.br/ccivil_03/_ato2015-2018/2018/lei/l13709.htm.

[37] ANPD. Comunicação de Incidentes de Segurança e Resolução CD/ANPD nº 15/2024. Disponíveis em: https://www.gov.br/anpd/pt-br/assuntos/comunicacao-de-incidentes-de-seguranca-cis e https://www.gov.br/anpd/pt-br/acesso-a-informacao/institucional/atos-normativos/regulamentacoes_anpd.

[38] NIST. AI 600-1 — Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile. Disponível em: https://nvlpubs.nist.gov/nistpubs/ai/NIST.AI.600-1.pdf.

[39] OWASP GEN AI SECURITY PROJECT. Top 10 for LLM Applications 2026. Disponível em: https://genai.owasp.org/resource/owasp-genai-llm-top-10-2026/.

[40] CISA. Known Exploited Vulnerabilities Catalog. Disponível em: https://www.cisa.gov/known-exploited-vulnerabilities-catalog.

[41] CISA. Software Bill of Materials Resources. Disponível em: https://www.cisa.gov/topics/information-communications-technology-supply-chain-security/sbom/resources-library.

[42] NIST. SP 500-292 — Cloud Computing Reference Architecture. Disponível em: https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication500-292.pdf.

[43] OWASP. REST Security Cheat Sheet. Disponível em: https://cheatsheetseries.owasp.org/cheatsheets/REST_Security_Cheat_Sheet.html.

[44] OWASP. Secrets Management Cheat Sheet. Disponível em: https://cheatsheetseries.owasp.org/cheatsheets/Secrets_Management_Cheat_Sheet.html.

[45] NIST. AI 100-2 E2025 — Adversarial Machine Learning: A Taxonomy and Terminology of Attacks and Mitigations. Disponível em: https://csrc.nist.gov/pubs/ai/100/2/e2025/final.

Leituras complementares

• HENNESSY, John L.; PATTERSON, David A. Computer Architecture: A Quantitative Approach.
• TANENBAUM, Andrew S.; BOS, Herbert. Modern Operating Systems.
• KLEPPMANN, Martin. Designing Data-Intensive Applications.
• NIST. SP 800-218A — Secure Software Development Practices for Generative AI and Dual-Use Foundation Models.
• W3C. Web Authentication: An API for Accessing Public Key Credentials. https://www.w3.org/TR/webauthn-3/.

Encerramento da Parte 3

Esta parte começou com um bit e terminou com governança de risco. O percurso não é acidental.

Uma informação só permanece útil quando sua representação é interpretada corretamente. A CPU só entrega desempenho quando memória, cache, paralelismo e I/O cooperam. Um arquivo só é persistente quando caminho, permissão, flush, mídia e backup cumprem suas promessas. Uma VM ou container só isola conforme a configuração real. Cloud só entrega elasticidade e disponibilidade quando dependências, failure domains, responsabilidade e custo foram desenhados. Segurança só reduz risco quando identidade, aplicação, dados, operação, resposta e recuperação funcionam como sistema.

O Analista de Sistemas maduro não pergunta apenas “qual ferramenta usar?”. Ele pergunta:

• qual abstração sustenta esta função?
• qual promessa cada camada oferece?
• que falhas o desenho contém e quais apenas desloca?
• onde o estado vive e como será recuperado?
• qual identidade pode agir e sobre qual objeto?
• qual evidência provará que o controle funciona?
• qual custo, risco e dependência a decisão cria?

Essas perguntas conectam hardware, software, infraestrutura e negócio. Elas também preparam os próximos volumes: engenharia de software, modelagem, arquitetura de aplicações, dados, DevOps, segurança e operação deixam de ser assuntos separados e passam a ser decisões sobre o mesmo sistema.

Ficha editorial da Parte 3

Tema central: como informação é representada, executada, persistida, virtualizada, disponibilizada e protegida.
Tese: abstrações só são confiáveis quando suas promessas, limites, estados e evidências são compreendidos.
Público: estudantes e profissionais em formação em Análise e Desenvolvimento de Sistemas, infraestrutura e sustentação.
Palavras-chave: bits, Unicode, CPU, cache, NUMA, filesystem, journaling, containers, Docker, Kubernetes, cloud, FinOps, segurança, LGPD, RAG.
Continuidade: próximos volumes sobre engenharia de software, modelagem, desenvolvimento, arquitetura e operação.