Capítulo 26 — Segurança da informação: alternativas de arquitetura

Capítulo 26 — Segurança da informação: alternativas de arquitetura

Mapa da aula

Aula 26 publicada. Mapa, exemplo, EX076.

flowchart TD
  N0["26.1 Modelos de perímetro"]
  N1["26.2 Modelos centrados na identidade"]
  N2["26.3 Nuvem e local"]
  N3["26.4 Escolhendo"]
  N0 --> N1 --> N2 --> N3
  N3 --> EX["Exemplo resolvido"]
  EX --> Q["Exercício EX076"]

Desenho lógico

flowchart LR
  N0["26.1 Modelos de perímetro"]
  N1["26.2 Modelos centrados na identidade"]
  N2["26.3 Nuvem e local"]
  N3["26.4 Escolhendo"]
  N0 --> N1 --> N2 --> N3 --> Q["EX076"]

[26.1 Modelos de perímetro]
    |
    v
[26.2 Modelos centrados na identidade]
    |
    v
[26.3 Nuvem e local]
    |
    v
[26.4 Escolhendo]
    |
    v
[Exemplo resolvido] --> [Exercício EX076]

Objetivos de aprendizagem

Você vai (1) comparar arquiteturas de perímetro e centradas na identidade; (2) avaliar opções em nuvem e locais; (3) escolher uma arquitetura com os motivos registrados.

26.1 Modelos de perímetro

A arquitetura tradicional da Saltmarsh confia nos dispositivos dentro da rede e defende a borda com firewalls. Lindiwe observa que esse modelo se enfraquece quando os funcionários trabalham remotamente, as aplicações vão para serviços em nuvem e os atacantes entram por phishing. Uma vez dentro, um atacante herda a confiança. O Prof. Hale explica que o perímetro continua útil, mas já não é suficiente, porque a linha entre dentro e fora se tornou difusa para a maioria das organizações. Lindiwe ilustra isso com um incidente sintético em que um notebook vítima de phishing na rede interna alcançou um compartilhamento de arquivos com exportações da folha de pagamento, porque nada dentro do firewall conferia quem estava pedindo.

26.2 Modelos centrados na identidade

Uma alternativa confere a identidade, a saúde do dispositivo e o contexto de cada pedido, independentemente da localização na rede. Lindiwe esboça como a aplicação de despacho da Saltmarsh funcionaria: cada pedido é autenticado, o dispositivo é conferido quanto às correções em dia e o acesso é limitado à função do usuário. Essa abordagem segue o princípio da mediação completa de Saltzer e Schroeder. Ela observa que isso exige um gerenciamento de identidades maduro, um inventário de dispositivos e registro de logs, que a Saltmarsh tem apenas em parte. Ela lista as capacidades que faltam: um inventário completo de dispositivos, um relato consistente da saúde dos dispositivos e o registro de cada decisão de acesso às aplicações.

26.3 Nuvem e local

A Saltmarsh está considerando levar a folha de pagamento para um serviço em nuvem. Lindiwe compara as responsabilidades de segurança: o provedor protege sua infraestrutura, enquanto a Saltmarsh continua responsável pelas contas de usuário, pela configuração e pelos dados. Ela lista perguntas ao provedor sobre cifração, registro de logs, certificações e notificação de incidentes. O Prof. Hale adverte que os serviços em nuvem deslocam as responsabilidades, mas não as eliminam, e que armazenamentos em nuvem mal configurados causaram muitas exposições. Ela redige o questionário para o provedor com doze perguntas, e a equipe de compras concorda em enviá-lo com os documentos da licitação.

26.4 Escolhendo

Lindiwe recomenda uma abordagem em etapas: manter a segmentação e os firewalls, colocar primeiro as aplicações de alto valor atrás de um acesso ciente da identidade e avaliar a folha de pagamento em nuvem com uma revisão contratual. Ela registra a decisão com os motivos: a redução do risco no acesso remoto, a viabilidade diante da maturidade atual da identidade e o custo. O Prof. Hale observa que as escolhas de arquitetura raramente são de tudo ou nada, e que um caminho em etapas permite que a organização construa as capacidades que cada etapa exige. O diretor-geral aprova a primeira etapa, começando pelo despacho e pela folha de pagamento. Lindiwe marca uma revisão depois de seis meses para decidir se a próxima etapa deve prosseguir.

Exemplo resolvido

Lindiwe compara os modelos de perímetro e centrados na identidade, lista as responsabilidades compartilhadas da folha de pagamento em nuvem e recomenda uma transição em etapas com os motivos registrados.

Caso sintético. As arquiteturas são sintéticas.

Erros e limites

Ir para um serviço em nuvem não transfere a responsabilidade pelas contas e pela configuração.

Exercícios

• EX076 — Fraqueza do perímetro. Por que o modelo de perímetro é insuficiente? Rubrica: 3 = os atacantes dentro herdam a confiança;; 2 = parcialmente correto;; 1 = vago;; 0 = nenhuma.

• EX077 — Ligação com a mediação. Que princípio a verificação centrada na identidade segue? Rubrica: 3 = mediação completa;; 2 = parcialmente correto;; 1 = outro;; 0 = nenhuma.

• EX078 — Responsabilidade na nuvem. O que continua sendo responsabilidade da Saltmarsh na nuvem? Rubrica: 3 = contas, configuração e dados;; 2 = parcialmente correto;; 1 = vago;; 0 = nenhuma.

Continue estudando — aula 26 (capítulo 26 de 50)

← Capítulo 25 · Índice das aulas · Capítulo 27 →

Continue para a próxima aula já escrita.