OpenCyber Academy
Tecnólogo · Capítulo 21 · Português
Código do curso: OCA-076Capítulo 21: OCA-076-C021

Capítulo 21 — Arquitetura e engenharia de segurança: integração de serviços

Ensino gratuito e aberto para quem deseja proteger pessoas e tecnologias. Não é preciso criar uma conta para estudar ou consultar as respostas.

Mapa da aula

Aula 21 publicada. Mapa, exemplo, EX061.

flowchart TD
  N0["21.1 Um novo parceiro"]
  N1["21.2 Proteger as credenciais"]
  N2["21.3 Limitar o parceiro"]
  N3["Síntese"]
  N0 --> N1 --> N2 --> N3
  N3 --> EX["Exemplo resolvido"]
  EX --> Q["Exercício EX061"]

Desenho lógico

flowchart LR
  N0["21.1 Um novo parceiro"]
  N1["21.2 Proteger as credenciais"]
  N2["21.3 Limitar o parceiro"]
  N3["Síntese"]
  N0 --> N1 --> N2 --> N3 --> Q["EX061"]

[21.1 Um novo parceiro]
    |
    v
[21.2 Proteger as credenciais]
    |
    v
[21.3 Limitar o parceiro]
    |
    v
[Síntese]
    |
    v
[Exemplo resolvido] --> [Exercício EX061]

Objetivos de aprendizagem

Você vai (1) integrar com segurança o serviço de um novo parceiro; (2) proteger as credenciais da API; (3) limitar o que um parceiro pode fazer.

21.1 Um novo parceiro

A Brightwater assina contrato com uma rede de armários de retirada de encomendas (lockers), para que os clientes possam retirar encomendas nos armários. A empresa dos armários precisa dos eventos de entrega e devolve as confirmações de retirada. Tomás revisa o plano de integração com o desenvolvedor. Os dados trafegam por uma interface de programação de aplicações (API) sobre HTTPS. Ele pergunta de que dados a empresa dos armários realmente precisa: o identificador da encomenda, a localização do armário e um código de retirada, mas não o endereço residencial nem o telefone do cliente. Minimizar os dados compartilhados limita o dano se o parceiro for invadido.

21.2 Proteger as credenciais

A API dos armários usa chaves para autenticar cada lado. Tomás insiste em que as chaves fiquem guardadas no gerenciador de segredos do provedor de nuvem, e não no código ou em arquivos de configuração, sejam diferentes para teste e produção e sejam rotacionadas a cada seis meses. As mensagens recebidas da empresa dos armários são assinadas, para que a Brightwater possa verificar sua origem. Ele segue as práticas de desenvolvimento seguro do NIST SP 800-218, que pede a proteção dos segredos e a revisão dos componentes de terceiros. Uma chave vazada permitiria a um atacante marcar encomendas como retiradas.

21.3 Limitar o parceiro

A chave da empresa dos armários só consegue relatar eventos de retirada das encomendas atribuídas aos seus armários; ela não consegue consultar outras encomendas nem alterar rotas. Tomás testa isso tentando buscar uma encomenda não relacionada com a chave de teste do parceiro, o que é corretamente recusado. Ele documenta a integração no diagrama de arquitetura como uma nova fronteira de confiança e acrescenta alertas para volumes incomuns de eventos de retirada. Cada integração amplia a superfície de ataque, então os limites e os testes devem ser incorporados desde o primeiro dia.

Exemplo resolvido

Tomás minimiza os dados compartilhados com um parceiro de armários, protege as chaves da API num gerenciador de segredos e testa que a chave do parceiro não consegue consultar encomendas não relacionadas.

Caso sintético. O parceiro e a API são sintéticos; o SP 800-218 é real.

Erros e limites

Os parceiros podem mudar seus sistemas sem aviso. Os gerenciadores de segredos criam uma dependência.

Exercícios

Síntese

Integrações seguras compartilham o mínimo de dados, protegem as chaves e impõem limites testados ao que os parceiros podem fazer.

Respostas comentadas

EX061. O endereço residencial e o telefone do cliente.

EX062. Marcar encomendas como retiradas.

EX063. Tentando buscar uma encomenda não relacionada com a chave de teste do parceiro, o que foi recusado.