Adicionar segurança a uma solução em uma fase tardia do ciclo de vida de projeto e desenvolvimento geralmente resulta em retrabalho dispendioso e sacrifícios de usabilidade, o que prejudica os recursos da solução e a experiência do usuário. Projetar soluções que sejam seguras desde o início ajuda a garantir um equilíbrio adequado entre usabilidade, interoperabilidade, resiliência e segurança para a solução final.

Segurança desde o design é o princípio de que as práticas de concepção, desenvolvimento e entrega de um projeto devem incluir práticas de segurança e conformidade, executadas por uma equipe qualificada e experiente. Os princípios de projeto de segurança, como os a seguir, orientam as práticas de pensamento arquitetônico.

O processo de design precisa começar com a utilização do design thinking empresarial para focar nos resultados de usuário necessários para os stakeholders em risco, conformidade e segurança, tanto internos quanto externos à organização. Os stakeholders externos incluem cliente, governo e reguladores. Os stakeholders internos incluem aqueles que gerenciam os riscos, a conformidade e a segurança.

O processo de design continua com o pensamento arquitetônico para definir as características da arquitetura, as decisões arquitetônicas, a arquitetura funcional e o modelo de implementação da nuvem. Em seguida, são definidas as características dos serviços de segurança, como resiliência, desempenho e escalabilidade.

Após a definição dos requisitos e da arquitetura, pode-se iniciar a engenharia da funcionalidade e da infraestrutura de segurança, incluindo a observância do princípio de segurança por padrão.

A IBM possui uma abordagem de longa data para a segurança e a privacidade por design, usada no desenvolvimento de produtos. O artigo IBM publicado sobre Segurança no desenvolvimento: o framework de engenharia segura da IBM é útil para avaliações.

Quando os usuários ou o software com um sistema têm privilégios excessivos, há risco de uso indevido, seja acidentalmente ou deliberadamente.Agentes de ameaça podem comprometer as contas privilegiadas de usuários internos e usar os direitos para percorrer a rede e os sistemas.

Privilégio mínimo é o princípio que afirma que o sistema deve fornecer aos usuários ou software os recursos mínimos necessários para realizar a tarefa pretendida. O sistema deve implementar isso desde o nível mais alto em uma aplicação até uma conexão individual entre dois componentes de software.

Para implementar o princípio do privilégio mínimo, você deve entender os ativos em seu ambiente dinâmico de TI. O acesso privilegiado não é apenas um problema de pessoas; é necessário saber quais aplicações têm acesso a quais dados. O processo de descoberta, classificação e avaliação de risco é contínuo. Reúna os dados de risco de seus recursos digitais para descobrir novos insights de risco em nível de negócios e ajudar você a estabelecer as políticas certas.

Um usuário ou software pode ter um contexto seguro no ponto de identificação e autenticação inicial para uma sessão, mas um agente de ameaça pode comprometer a sessão ativa e usá-la para comprometer ainda mais um sistema.

A verificação contínua é o princípio de que um usuário ou software deve ser constantemente verificado para avaliar se eles ainda têm um contexto seguro. A intenção da verificação contínua é encontrar problemas e vulnerabilidades de segurança o mais cedo possível e, idealmente, os agentes de ameaças o fazem.

A verificação contínua confirma que as entidades são quem, ou o que, afirmam ser, utilizando desafios como uma solicitação de autenticação de dois fatores. Uma carga de trabalho pode exigir atualização para suportar a verificação contínua de usuários e software usando soluções com uma arquitetura de rede zero trust (ZTNA). As organizações focadas em oferecer as melhores experiências de usuário hesitam em interromper o usuário com solicitações desnecessárias; no entanto, esse nível de garantia de identidade é crítico para o zero trust.

Um agente da ameaça pode já ter violado uma organização. Se uma organização procurar apenas ameaças na boundary externa e não ameaças que tenham usado um mecanismo válido para contornar o controle de boundary, ela poderá não descobrir uma violação por muito tempo. Assumir uma violação é o princípio de que uma organização assume que uma violação foi realizada por um agente da ameaça.

A abordagem exige que a gestão de ameaças inclua detecção interna proativa, busca por sinais de alerta precoce, caça a ameaças e uso de procedimentos operacionais padrão comprovados. A detecção e a resposta devem estar estreitamente integradas às camadas de insights e imposição, compartilhando contexto e ajustando dinamicamente as políticas de controle de acesso em resposta às ameaças identificadas.

Um sistema de informação terá vulnerabilidades no software, no firmware e no hardware. As configurações e o software mudarão, e novas vulnerabilidades aparecerão. Se uma camada de defesa estiver vulnerável, o sistema precisará permanecer seguro.

A defesa em profundidade é o princípio de que um sistema tem múltiplas camadas de defesa para que, se uma camada falhar, outra camada permanecerá em vigor para proteger os dados sensíveis no sistema. O uso de uma abordagem em camadas para uma estratégia de segurança garante que a organização possa deter um invasor em uma camada subsequente quando uma camada de defesa for violada.

A estratégia e a arquitetura de segurança empresarial devem incluir medidas que ofereçam proteção nas camadas subsequentes do modelo tradicional de computação em rede. Geralmente, uma organização precisa planejar a segurança desde o mais básico (segurança em nível de sistema) até o mais complexo (segurança em nível de transmissão).

A superfície de ataque de uma organização é a soma das vulnerabilidades, caminhos ou métodos – às vezes chamados de vetores de ataque – que os agentes da ameaça podem usar para obter acesso não autorizado à rede ou a dados sensíveis, ou para realizar um ataque cibernético. À medida que as organizações adotam cada vez mais serviços em nuvem e modelos de trabalho híbridos (no local/trabalho em casa), suas redes e as superfícies de ataque associadas a elas tornam-se maiores e mais complexas a cada dia.

Minimizar a superfície de ataque é o princípio de que um sistema deve reduzir o escopo dos vetores de ataque para reduzir as possíveis maneiras pelas quais um agente de ameaça pode obter acesso. Especialistas em segurança dividem a superfície de ataque em três subsuperfícies: a superfície de ataque digital, a superfície de ataque física e a superfície de ataque de engenharia social.

1. A superfície de ataque digital expõe potencialmente a nuvem e a infraestrutura local da organização a qualquer agente de ameaça com uma conexão à internet. Os vetores de ataque comuns incluem acesso à rede, vulnerabilidades de software, ativação de recursos não utilizados, TI invisível e software desatualizado.

2. A superfície de ataque física expõe ativos e informações tipicamente acessíveis apenas a usuários com acesso autorizado ao escritório físico ou aos dispositivos de endpoint da organização. Isso inclui ataques de agentes internos maliciosos, roubo de dispositivos e "baiting" – um ataque em que os agentes da ameaça deixam as unidades USB infectadas com malware em locais públicos com a esperança de enganar os usuários para que conectem os dispositivos a seus computadores e baixem o malware involuntariamente.

3. A superfície de ataque de engenharia social manipula as pessoas para que compartilhem informações que não deveriam compartilhar, baixar um software que não deveriam baixar, visitar sites que não deveriam visitar, enviar dinheiro para criminosos ou cometer outros erros que comprometem seus ativos pessoais ou organizacionais ou sua segurança.

Uma organização deve avaliar o risco para os dados confidenciais que estão sendo processados pelo sistema examinando cada uma dessas superfícies de ataque.

Os usuários podem ter acesso a dados altamente confidenciais que permitem um desvio de controles, como chaves de criptografia, ou ter direitos para realizar ações altamente privilegiadas, como transferir grandes montantes de dinheiro. Mesmo quando um sistema monitora os usuários, eles podem abusar de seus direitos, resultando em consequências comerciais catastróficas.

A separação de funções é o princípio de que os usuários com acesso poderoso a dados ou ações precisam de mais de um usuário para concluir a ação. Isso fornece à organização a capacidade de dividir as funções administrativas entre indivíduos sem sobrepor as responsabilidades, para que um usuário não tenha autoridade ilimitada.

Em atividades como o gerenciamento de chaves de criptografia, a organização exigirá que os administradores de chaves de criptografia gerenciem diferentes partes de uma chave para que nenhum administrador tenha conhecimento da chave inteira. Com as transações comerciais, a aplicação pode exigir que uma pessoa que solicita uma transação tenha um ou mais aprovadores para que ela seja concluída.

Em alguns setores, um órgão regulador pode exigir a separação de funções para cargos de grande responsabilidade como parte das diretrizes regulatórias. A separação de funções ajuda as empresas a cumprirem as normas governamentais e simplifica a gestão das autoridades.

Os produtos ou serviços contêm muitos pontos de configuração diferentes e existe o desejo de torná-los o mais fáceis de usar possível. Como resultado, o produto apresenta uma configuração de segurança fraca, como portas de rede abertas ou permissão para o uso de senhas fáceis de memorizar.

Segurança por padrão é o princípio de que uma organização recebe produtos ou serviços configurados em um estado seguro imediatamente após a instalação. Os produtos são configurados para proteger contra as ameaças e vulnerabilidades mais comuns, sem que os usuários finais precisem tomar medidas adicionais para garantir sua segurança.

Um sistema pode ser configurado de forma segura inicialmente, mas um desenvolvedor pode posteriormente fazer uma alteração que modifique a configuração, ou um agente de ameaça pode explorar uma vulnerabilidade e fazer uma alteração que comprometa o sistema.

A conformidade contínua é o princípio segundo o qual a configuração de segurança do sistema é constantemente verificada, desde o desenvolvimento do sistema até sua operação contínua. O objetivo da conformidade contínua é encontrar problemas e vulnerabilidades de segurança antes que os agentes da ameaça o façam.

Idealmente, as verificações de conformidade são totalmente automatizadas e abrangem todas as configurações de segurança, incluindo a plataforma de nuvem, a plataforma de contêiner, o middleware e as imagens de computação, como servidores virtuais e contêineres. Com imagens computacionais, uma abordagem melhor pode ser usar Infraestrutura como Código (IaC) para substituir a imagem inteira regularmente.

As responsabilidades compartilhadas pela entrega de segurança e conformidade em um ambiente de nuvem híbrida dependem dos modelos de serviço, plataformas de computação e provedores de serviços de nuvem usados pela carga de trabalho ou aplicação. Um arquiteto de segurança deve documentar e comunicar as responsabilidades que abrangem o projeto, a construção e a operação dos serviços de segurança. Sem clareza, podem existir lacunas na segurança da solução.

Cada dimensão tem um impacto diferente nas responsabilidades compartilhadas:

• Modelo de serviço de nuvem – A definição do NIST de computação em nuvem tem os diferentes escopos de responsabilidades dependendo do modelo de serviço de nuvem, como IaaS, PaaS, SaaS ou nuvem distribuída. Os serviços de segurança fazem parte das responsabilidades compartilhadas. Por exemplo, as responsabilidades compartilhadas da IBM Cloud incluem gerenciamento de acesso e identidade e conformidade com segurança e regulamentação. As responsabilidades compartilhadas para estas categorias variam dependendo do modelo de serviço de nuvem.
   

• Plataforma de computação – A hospedagem de uma carga de trabalho pode ser feita em uma ou mais plataformas de computação, como Bare Metal Servers, Virtual Servers, plataformas de contêiner e sem servidor. Cada plataforma de computação tem um conjunto diferente de responsabilidades compartilhadas. Por exemplo, Bare Metal Servers exigem que o proprietário da carga de trabalho seja responsável por todos os controles de segurança da plataforma, exceto pelo hardware físico e pela integração de rede.
   

• Provedor de serviço de nuvem – As responsabilidades também mudam dependendo do provedor de serviço de nuvem. Por exemplo, a plataforma Kubernetes de cada provedor de serviço em nuvem é diferente (a menos que você esteja usando o Red Hat OpenShift), pois cada uma consiste em um conjunto diferente de pacotes de código aberto selecionados.

Então, por que um arquiteto de segurança deveria se preocupar com as diferenças na propriedade dos serviços? A equipe responsável pelas operações de segurança pode ter serviços de segurança predefinidos para dar suporte ao funcionamento do serviço. Os serviços de segurança podem fazer parte da plataforma em nuvem ou podem ser locais, exigindo uma ampla integração.

Por exemplo, uma equipe interna de operações de segurança pode usar uma tecnologia diferente da de um integrador de sistemas global (GSI), como o IBM® Consulting. Para a equipe de segurança interna, o painel de controle de segurança que hospeda os serviços de segurança pode ser local, enquanto o GSI pode estar usando serviços de segurança em nuvem fornecidos por outro provedor de serviços em nuvem.

Para o modelo de serviço de nuvem Software como Serviço (SaaS), apenas a administração de segurança da aplicação está disponível ao consumidor do serviço de nuvem. A segurança normalmente é integrada à aplicação como parte do serviço, com escopo limitado para controlar a configuração de segurança. Nesse caso, o provedor de SaaS detém a maior parte das responsabilidades pelas operações de segurança.

Sem responsabilidades documentadas, pode não haver responsáveis designados para projetar, construir e executar componentes de segurança que sejam essenciais para o funcionamento da carga de trabalho. Compreender as responsabilidades compartilhadas pelos serviços de segurança permite que a arquitetura da solução atenda às necessidades operacionais e evita a necessidade de retrabalho da solução em um estágio posterior do projeto.

Os serviços de segurança em uma arquitetura de nuvem híbrida utilizam diferentes modelos de serviços de nuvem, plataformas computacionais e provedores de serviços de nuvem. Esses serviços precisam de uma arquitetura de painel de controle acordada para garantir o gerenciamento e a supervisão consistentes da segurança e da conformidade.

Com uma empresa que possui cargas de trabalho de data center local, o painel de controle pode residir em um data center local para ser resiliente a uma falha de um provedor de serviço de nuvem. No entanto, um serviço de segurança local não terá necessariamente a capacidade de gerenciar totalmente a plataforma em nuvem. Portanto, projete uma arquitetura de painel de controle para relatar o status de segurança e identificar os riscos entre os diferentes provedores de serviços em nuvem.

Com organizações nascidas na nuvem, a hospedagem do painel de controle pode ser outra nuvem, hospedada em um ponto de presença (POP) ou hospedada em um data center de colocação. O painel de controle de segurança pode precisar estar disponível, mesmo que tenha ocorrido uma falha em um serviço de nuvem.

Como arquiteto de segurança, é importante documentar e acordar uma decisão arquitetônica para garantir o alinhamento da arquitetura do painel de controle de segurança em toda a organização. Tome essa decisão logo no início do projeto para garantir que a solução esteja alinhada com a estratégia da organização.

A segurança não se resume apenas à implementação de recursos de segurança, mas sim à proteção dos dados e processos empresariais contra ameaças. Utilize uma abordagem sistemática para rastrear os fluxos de dados pelo sistema, a fim de identificar os controles de segurança para proteger os dados em trânsito, em repouso e em uso.

Os arquitetos devem identificar os dados confidenciais a serem protegidos, começando com um diagrama de contexto do sistema para identificar os limites do sistema e as interações externas que iniciam os fluxos de dados pelo sistema. Em seguida, os fluxos de dados internos da aplicação são examinados usando um diagrama para descrever os componentes funcionais, como um diagrama de componentes.

À medida que os arquitetos migram para a implementação, eles examinam os fluxos de dados entre os componentes implementados e a infraestrutura da nuvem usando um diagrama de arquitetura da nuvem. A IBM criou uma linguagem de design de diagrama técnica que permite um design independente de um provedor de serviço de nuvem.

Para identificar as ameaças a esses fluxos de dados, utilize a modelagem de ameaças tanto para os componentes funcionais da carga de trabalho quanto para a infraestrutura da carga de trabalho.

Em conjunto, essas técnicas e artefatos oferecem uma abordagem repetível e consistente para o pensamento arquitetônico voltado à segurança e conformidade.

Ao processar os dados mais confidenciais, considere uma camada adicional de proteção utilizando computação confidencial e criptografia homomórfica.

Um sistema precisa atender a muitos requisitos de controle diferentes, e a lista pode ficar longa e difícil de gerenciar. Em vez de trabalhar com muitos requisitos individuais, trabalhe com processos, serviços ou recursos que agrupam os requisitos em recursos de entrega. Por exemplo, o gerenciamento do ciclo de vida da identidade ou a detecção de componentes não autorizados são potenciais recursos de entrega.

Siga estas etapas para gerenciar a conformidade de maneira mais eficaz:

1. Crie um framework de conformidade única com rastreabilidade até as fontes originais.
2. Mapeie os requisitos no framework de conformidade para um conjunto de recursos de entrega.
3. Garanta recursos de conformidade em todos os estágios do projeto, criação, teste e operação.
4. Continue atendendo aos requisitos de produção.

O arquiteto de segurança deve garantir que os recursos de segurança tenham Objetivos de Nível de Serviço (SLOs) associados, acordos de responsabilidade e assim por diante.

Frequentemente, há necessidade de garantir que os dados de um cliente, linha de negócios ou ambiente não vazem para outro. É necessário haver separação entre a execução da carga de trabalho e o armazenamento dos dados. Pode ser algo tão simples quanto uma tabela diferente em um banco de dados ou servidores físicos separados.

A nuvem híbrida oferece muitas opções para impor a separação do processamento de dados. A separação deve ocorrer entre:

1. Cargas de trabalho ou aplicações – por exemplo, contabilidade versus recursos humanos
2. Ambientes – por exemplo, desenvolvimento, teste e produção
3. Clientes – por exemplo, cliente A versus Cliente B
4. Localização – por exemplo, Reino Unido versus Estados Unidos

Existem muitas opções diferentes para segregação em um ambiente de nuvem híbrida, que oferecem diferentes recursos e níveis de garantia:

1. Conta corporativa
2. Conta na nuvem
3. Grupo de recursos
4. Nuvem privada virtual
5. Domínio de execução – por exemplo, uma imagem de contêiner ou servidor
6. Projeto
7. Domínio de gerenciamento de chaves
8. Dispositivos físicos

As políticas organizacionais devem definir qual tipo de separação é apropriado para a carga de trabalho que processa os dados. Por exemplo, a política pode exigir que a hospedagem dos dados de produção do cliente não deve estar em um ambiente de não produção. O nível mínimo de separação necessário é uma conta de nuvem diferente, pois é lá que ocorre o gerenciamento de identidade e acesso.

Relacionado ao tema da separação de dados está o da soberania de dados. Alguns países estão impondo restrições sobre onde o processamento e o acesso de dados podem ocorrer. O post de blog "Addressing Regulations and Driving Innovation with Sovereign" apresenta uma discussão sobre a hierarquia das necessidades de soberania de dados.

A modelagem de ameaças é frequentemente vista como uma técnica para identificar e validar os controles de segurança dos dados que trafegam por um sistema.

No entanto, a modelagem de ameaças tem um segundo propósito: identificar ameaças para monitoramento em um sistema de monitoramento de ameaças. O arquiteto de segurança deve trabalhar para identificar uma lista priorizada de ameaças. Em seguida, defina o caso de uso de detecção de ameaças necessário para os recursos de detecção de ameaças. Implemente e teste a detecção de casos de uso com manuais de resposta a incidentes para permitir uma resposta eficaz a ameaças.

Garanta a rastreabilidade documentada entre as ameaças, os casos de uso de detecção de ameaças e os manuais de resposta a incidentes para assegurar o planejamento e a entrega completos do projeto.

Com os data centers locais do passado, as equipes de operações de segurança concluíam as atividades em questão de dias ou horas e não exigiam níveis de serviço rigorosos. Com a automação de Infraestrutura como Código (IaC), a perda de um serviço de segurança centralizado, como o gerenciamento de segredos ou certificados, tem um impacto imediato na disponibilidade de uma aplicação. Portanto, os serviços de segurança exigem níveis de serviço e uma arquitetura para atender aos requisitos de disponibilidade.

Defina para cada recurso ou serviço de segurança:

1. Horas de serviço
2. Tempos de resposta a incidentes, problemas e alterações
3. Habilidades e experiência da equipe de operações
4. Procedimentos testados detalhados para atender aos requisitos de serviço
5. Automação para atender aos requisitos do serviço

Se a equipe de operações de segurança interna não puder atender às demandas de uma carga de trabalho nativa da nuvem, considere se um provedor de serviços de segurança gerenciados é apropriado.

Se você parar para pensar, muitos serviços de segurança hoje em dia precisam de resiliência e níveis de serviço que sejam pelo menos tão bons quanto a carga de trabalho que eles suportam.

Os métodos de trabalho antigos faziam com que a segurança fosse uma reflexão tardia, dificultando a configuração e a aplicação de correções de segurança, uma vez que não ocorriam no início do ciclo de desenvolvimento. Com as práticas de trabalho em DevOps, os padrões de construção de segurança precisam ser:

1. Incluídos nos ambientes de desenvolvimento e teste.
2. Consistentes desde o desenvolvimento inicial até a produção total.
3. Testados continuamente para garantir a conformidade contínua.

Os processos de criação devem evitar a implementação insegura de uma carga de trabalho em todos os estágios de desenvolvimento e operações para garantir que a segurança não seja uma reflexão tardia.