Segurança e privacidade B2

Nível: B2

Objetivo

Discutir riscos e controles de segurança e privacidade em inglês técnico B2: articular um threat model, descrever attack surface, justificar least privilege, debater políticas de data retention, descrever obrigações de compliance e interpretar audit logs para reporting a stakeholders.

Explicação

Conversas maduras de segurança e privacidade em times de engenharia não giram em torno de regras isoladas, mas em torno de trade-offs explícitos entre risco, controle e custo. Em B2, espera-se que você nomeie o risco, proponha um controle e justifique o trade-off — em frases com voz passiva, conditional clauses e noun clauses.

1. Threat model: o que, quem e como

Um threat model é uma descrição estruturada de *o que estamos protegendo*, *de quem estamos protegendo* e *como um atacante poderia agir*. Os três blocos mais comuns em threat modeling são:

• Assets: o que tem valor (dados de clientes, chaves, infraestrutura, reputação).
• Threat actors: quem pode atacar (script kiddie, insider malicioso, fornecedor comprometido, adversário estatal).
• Attack vectors: como o atacante chegaria ao asset (API pública, dependência de terceiro, phishing, credential stuffing).

A formulação típica em B2 usa *what if* + noun clause para levantar cenários:

• `What if an attacker compromises a service account with read access to the production database?`
• `What if a developer accidentally commits a secret to a public repository?`
• `What if a third-party vendor stores our customer data outside the approved region?`

A resposta quase nunca é "impedir o ataque". É reduzir a probabilidade, reduzir o impacto e detectar cedo — o tripé clássico de controles de segurança.

2. Attack surface e least privilege

Attack surface é todo ponto de entrada que um atacante pode usar: endpoints expostos, portas abertas, dependências externas, contas de serviço com escopo amplo. Reduzir a attack surface é o controle de menor custo: cada superfície nova exige monitoramento, autenticação e auditoria.

Least privilege é o princípio de que cada identidade (humana ou máquina) deve ter apenas as permissões mínimas necessárias para sua função. Em frases B2, prefira:

• `The service account should run with read-only access to the audit log.`
• `We revoked write access from the analytics role; it no longer needs it.`
• `The CI runner is scoped to a single repository, not the entire organization.`

Voz passiva (`is scoped to`, `has been revoked`) é a forma padrão de descrever controles já aplicados, sem expor quem decidiu.

3. Data retention e privacy by design

Uma data retention policy define *por quanto tempo* cada categoria de dado é mantida e *o que acontece depois* (anonimização, deleção, arquivo frio). Em B2, espera-se que você conecte retenção a bases legais (compliance):

• `We retain transaction logs for 12 months to support fraud investigation; after that, they are deleted automatically.`
• `PII is pseudonymized after 30 days and fully anonymized after 18 months, in line with LGPD guidance.`
• `Backups older than 24 months are encrypted with a key that is rotated annually.`

Expressões como *in line with*, *as required by*, *subject to* mostram que a política não é arbitrária: ela responde a uma obrigação regulatória ou contratual.

4. Compliance e audit log

Compliance é o estado de estar em conformidade com leis, contratos ou padrões (LGPD, GDPR, SOC 2, PCI-DSS, HIPAA). O trabalho de compliance em engenharia se materializa em evidência: logs, screenshots, relatórios automatizados, atas de reunião.

Um audit log registra *quem fez o quê, quando, e de onde*. Ele não impede um ataque, mas permite detectar, investigar e responder. Frases comuns:

• `Every privileged action is written to an append-only audit log.`
• `The audit log is retained for 365 days and reviewed quarterly by the security team.`
• `If a control fails, the audit log is what we use to reconstruct what happened.`

Note a voz passiva (`is written to`, `is retained`, `is reviewed`) e o conditional (`If a control fails`) — combinação típica de um relatório de segurança B2.

5. Discutindo riscos e controles em time

A frase mais importante em uma conversa de segurança não é técnica — é a pergunta de trade-off:

• `What's the worst-case impact if this control fails?`
• `Is the cost of this control proportional to the risk we're mitigating?`
• `Are we treating this as a compliance checkbox or as a real reduction in risk?`

Quando você apresenta um controle, justifique com risk reduction + residual risk + cost. Quando você recusa um controle, explique com mitigating factor + compensating control. Esse é o padrão de discussão que times de segurança reconhecem como maduro.

Exemplos

Erros comuns

• Confundir threat com risk: *threat* é o cenário adverso (comprometimento de uma service account); *risk* é a combinação de probabilidade e impacto. Use threat para o 'o que pode dar errado' e risk para 'quanto isso nos custa'.
• Tratar least privilege como 'sem acesso nenhum': least privilege é *o mínimo necessário*, não zero. Frases como 'deny everything' descrevem deny-by-default, que é um mecanismo, não o objetivo.
• Escrever 'we don't have data retention' em vez de 'we don't have a data retention policy': ter dados sem política é o problema; a frase B2 correta é a segunda.
• Confundir compliance com security: um sistema pode estar em compliance e ainda ser inseguro, e vice-versa. Em B2, mantenha os dois termos separados.
• Dizer 'the logs are deleted' sem sujeito: use a passiva com agente claro (deleted automatically, deleted by the retention job) ou a ativa (we delete them).
• Usar 'audit' como verbo transitivo genérico: prefira 'we audited the access logs' (verbo) e 'an audit of the access logs' (substantivo).
• Misturar 'attack surface' e 'risk surface': o attack surface é técnico (endpoints, portas, contas); risk surface é mais amplo e inclui coisas como reputação.
• Escrever 'the system is secure' em uma review: segurança é contextual e probabilística. Prefira 'the system is within our risk appetite for this workload'.
• Tratar LGPD/GDPR como 'lei europeia' ou 'lei brasileira': o ponto B2 é o nome próprio da norma e a categoria (privacy regulation, data protection law).
• Recomendar um controle sem falar de residual risk: a pergunta esperada é 'qual risco sobra se o controle falhar?' — não proponha um controle sem essa resposta.

Prática guiada

Reescreva cada frase em tom de review de segurança B2.

1. Mensagem informal

`o dev tem acesso a tudo, vou tirar` → `We are scoping the engineer's role to the minimum required for the on-call rotation; write access to production will be revoked by the end of the week.` (voz passiva planejada + will be revoked + escopo)

1. Pedido genérico

`precisamos guardar os logs por mais tempo por causa da auditoria` → `We are extending log retention from 30 to 365 days, as required by our SOC 2 controls; after that period, logs are deleted automatically.` (extending retention + as required by + automatic deletion)

1. Risco sem trade-off

`esse endpoint público é arriscado` → `The public endpoint expands our attack surface; we are mitigating the risk by enforcing authentication, rate limiting, and quarterly access reviews.` (expands + mitigating + lista de controles)

1. Compliance sem evidência

`estamos em compliance com a LGPD` → `We are in line with LGPD requirements; PII is pseudonymized after 30 days, and the access log is reviewed quarterly by the privacy team.` (in line with + evidência concreta + responsible team)

Observe como cada reescrita passa de opinião para risco nomeado + controle + responsável + trade-off implícito.

Resumo

Discussão B2 de segurança e privacidade combina cinco blocos: threat model (assets, threat actors, attack vectors), attack surface e least privilege (reduzir entrada, minimizar escopo), data retention (quanto tempo, por quê, o que acontece depois), compliance (base legal e evidência) e audit log (quem/quando/de onde, retido e revisado). O padrão de frase é risco + controle + trade-off + responsável, com voz passiva para descrever controles já aplicados e conditional clauses para discutir falhas.

História: Segurança e privacidade B2

Nível: B2

História em inglês

The Monday security review

On Monday morning, Renata, who leads the platform security guild at a mid-size fintech, opened the threat model for the new payment orchestration service. The document listed the assets (customer PII, signing keys, transaction ledger), the threat actors (external attackers, compromised vendors, malicious insiders), and the attack vectors (public APIs, service accounts, third-party SDKs). Renata scheduled a 45-minute review with the payments team lead, the SRE on call, and the privacy officer, since several decisions had to be aligned before the launch. The first question on the agenda was the obvious one: "What is the worst-case impact if the orchestration service is compromised?"

Attack surface and least privilege

The payments lead walked through the proposed architecture, which exposed three public endpoints, two internal gRPC services, and a single signing service with custody of the merchant key. Renata pushed back: "Three public endpoints is a wide attack surface for a service that has not yet earned customer trust." She proposed collapsing two of the endpoints behind a single gateway and removing the third entirely, arguing that the underlying use case could be served by a server-side cron job instead. Then she turned to permissions: "The signing service account currently has read-write access to the entire payments database, which is a textbook least-privilege violation." By the end of the discussion, the team had agreed to scope the signing service to read-only access on a single signing table and to require manual approval for any privilege escalation.

Data retention and compliance

After the architecture review, the privacy officer raised the data retention question, since the orchestrator would log every transaction attempt, including failed ones. Renata summarized the trade-off: "We need the logs long enough to investigate fraud and to satisfy SOC 2 evidence, but we cannot keep PII forever, and we cannot pretend that 'forever' is a retention policy." The team agreed on a 90-day hot-retention window for raw transaction logs, followed by pseudonymization and a 12-month cold-retention window, after which the data is deleted automatically. PII fields would be pseudonymized after 30 days and fully anonymized after 18 months, in line with the company's LGPD compliance program. The privacy officer added the new pipeline to the risk register, flagging the right-to-audit clause with the third-party SDK vendor as a residual risk that still needed negotiation.

The audit log and the launch

The last item on the agenda was the audit log, which Renata considered the most important detective control in the whole design. Every privileged action, every manual approval, and every key rotation would be written to an append-only audit log retained for 365 days, with a quarterly review by the security team. Renata was clear about what the audit log was not: "It will not stop an attacker, but it is what we use to reconstruct what happened if any control fails." By the end of the meeting, the team had a written agreement on the threat model, the reduced attack surface, the retention policy, the LGPD-aligned pseudonymization schedule, and the audit log contract. The service launched three weeks later, and the first quarterly access review caught two stale service accounts that had not been revoked, which were removed the same day.

Tradução linha por linha

Notas de vocabulário

• threat model for the new payment orchestration service = Threat model + for + escopo: nomeia o artefato de segurança do serviço.
• threat actors ... attack vectors = Os três blocos clássicos: assets, threat actors, attack vectors.
• Three public endpoints is a wide attack surface = Wide + attack surface: adjetivo típico para descrever superfície de ataque ampla.
• a textbook least-privilege violation = Textbook + noun: crítica forte, mas técnica, de uma violação canônica.
• is scoped to read-only access on a single signing table = Voz passiva (is scoped) + to + escopo mínimo: a forma B2 de descrever least privilege aplicado.
• we cannot pretend that 'forever' is a retention policy = We cannot pretend + that-clause: crítica a um argumento fraco em uma review.
• 90-day hot-retention window ... 12-month cold-retention window = Hot vs. cold retention: dois estágios com políticas e custos diferentes.
• pseudonymized after 30 days and fully anonymized after 18 months = Pseudonymize precede anonymize: pseudonimização é reversível, anonimização não.
• in line with the company's LGPD compliance program = In line with: liga a política interna a uma base regulatória.
• added the new pipeline to the risk register = Risk register: lista viva de riscos; adicionar é o ato de registrar para acompanhamento.
• right-to-audit clause ... as a residual risk = Right-to-audit: cláusula contratual que permite auditar o fornecedor; um residual risk comum.
• append-only audit log retained for 365 days = Append-only + retained: dois atributos esperados de um audit log confiável.
• It will not stop an attacker, but it is what we use to reconstruct what happened = Detectivo (reconstruct) vs. preventivo (stop): distinção central de controles de segurança.
• the first quarterly access review caught two stale service accounts = Catch + stale + service accounts: verbo típico de access review que descobre contas obsoletas.

Perguntas de compreensão

1. What is Renata's role at the company?
2. Name the three building blocks of the threat model Renata opened.
3. Who attended the 45-minute review meeting?
4. What two changes did Renata propose to reduce the attack surface of the orchestrator?
5. Why was the signing service account described as a least-privilege violation?
6. What was Renata's argument about keeping PII 'forever'?
7. Describe the retention policy the team agreed on for transaction logs.
8. What is the difference between pseudonymization and anonymization in the LGPD-aligned schedule?
9. What residual risk did the privacy officer add to the risk register?
10. Why did Renata consider the audit log the most important detective control?
11. What attributes did the team agree on for the audit log?
12. What did the first quarterly access review catch?

Prática com a história

1. Reescreva em tom de security review: o endpoint público é perigoso, vamos fechar
2. Reescreva em voz passiva: restringimos o signing service a leitura em uma única tabela
3. Traduza: Precisamos dos logs por tempo suficiente para investigar fraude, mas não podemos manter PII para sempre.
4. Reescreva com in line with: a política atende ao programa de compliance com a LGPD
5. Reescreva como security review: se o controle falhar, a gente se vira