Objetivos

• Aprenda sobre restrições baseadas em contexto para proteger seus recursos em nuvem
• Definir zonas de rede para identificar fontes de tráfego para acesso permitido e negado
• Crie regras que definam contexto para acesso aos seus recursos em nuvem
• Saiba como testar e monitorar regras de contexto

O diagrama a seguir mostra a arquitetura da solução como usada no tutorial Aplicar fim para finalizar a segurança em um aplicativo em nuvem. As caixas adicionais com dashed, linhas azuis em torno do cluster Kubernetes Service, Container Registry, Key Protect, e Object Storage denotam restrições baseadas em contexto implementadas como regras de contexto. Observe que Secrets Manager também poderia ter sido protegido, mas é apenas um serviço opcional e não usado neste tutorial.

Antes de Iniciar

Este tutorial requer:

• CLI do IBM Cloud,
• docker cliente para empurrar e puxar imagens de container.

Você encontrará instruções para baixar e instalar essas ferramentas para o seu ambiente operacional no guia Getting started with solution tutorials.

Para evitar a instalação dessas ferramentas, é possível usar o Cloud Shell por meio do console do IBM Cloud.

Instalação

Em uma etapa posterior, Use Terraform para configurar restrições baseadas em contexto, você vai implementar objetos CBR como camada de segurança adicional em cima dos recursos usados no tutorial Aplicar fim para acabar com a segurança em um aplicativo em nuvem.

1. Implementar recursos usando Terraform gerenciado por Schematics conforme descrito no repositório da companheira GitHub.

2. O IBM Cloud Activity Tracker Event Routing deve ser configurado para rotear eventos de auditoria para uma instância de destino IBM Cloud Logs. Encaminhe os eventos de auditoria conforme descrito na configuração de um destino IBM Logs, se não estiver configurado atualmente em sua conta.

Visão geral: restrições baseadas em contexto

restrições baseadas em contexto(CBRs) fornecem a capacidade de definir e impor restrições de acesso para os recursos IBM Cloud com base no local da rede e no tipo de solicitações de acesso. Como tanto as políticas de IAM quanto as restrições baseadas em contexto impõem o acesso, as restrições baseadas em contexto oferecem proteção mesmo diante de credenciais comprometidas ou mal gerenciadas.

Uma regra rege o acesso a um recurso identificado por seu nome de serviço e tipo, bem como por atributos adicionais. Eles podem incluir a região, grupo de recursos e outras propriedades específicas do serviço. Os atributos em uma regra são, em sua maioria, opcionais, de modo que você poderia governar, por exemplo, todas as instâncias Key Protect, ou direm apenas um anel de chave específico em uma instância identificada Key Protect.

O contexto para uma restrição é composto por zonas de rede e terminais de serviço. Você pode desejar definir zonas com base em endereços IP ou intervalos específicos, ou configurando o tráfego originado de um ou mais VPCs ou serviços de cloud. Com isso, o acesso à amostra Key Protect instância pode apenas ser permitida a partir de, por exemplo, uma instância específica Object Storage, uma gama bem conhecida de endereços IP e apenas via terminal privado.

As zonas de rede podem ser usadas para a definição de várias regras. As regras têm um modo de aplicação que é um dos portadores de deficiência, apenas de relatório ou habilitado.

No momento, nem todos os serviços de nuvem suportam o modo somente relatório. Além disso, esses serviços também não geram nenhuma entrada de log relacionada ao CBR quando ativada Verifique a documentação de serviço individual para obter detalhes

Criar zona e regra

Por avaliar o impacto de restrições baseadas em contexto, você vai criar uma regra que rege o acesso a um namespace em Container Registry. Você começa criando esse espaço de nomes, então uma zona de rede para identificar um VPC como fonte de tráfego.

1. Vá para os namespacesContainer Registry e anote o nome do namespace configurado anteriormente.
2. No console IBM Cloud, clique no menu Gerenciar e selecione restrições baseadas em contexto. Na página de visão geral, clique em Criar uma zona de rede.
3. Digite VPCzone como nome. Em Permitidos VPCs, selecione aquele com o seu cluster Kubernetes Service. Clique em Avançar para revisar, em seguida, Criar a zona.
4. Em seguida, crie uma regra usando a zona clicando em Regras na navegação à esquerda, em seguida, Criar.
5. Selecione Container Registry na seção Serviço e clique em Next.
6. Deixe a seção APIs com Todas APIs de serviço clique em Avançar.
7. Em seguida, sob Recursos, escolha Recursos específicos. Escolha Tipo de recurso como atributo e especifique namespace como valor. Adicione outra condição e configure o Nome do recurso como NAMESPACE (o mesmo valor da etapa 1). Clique em Review e, em seguida, em Continue.
8. Selecione o VPCzone que você criou anteriormente a partir da lista. Em seguida, use Add e Continue para chegar à última etapa do diálogo. Marque o Enforcement como Report-only. Depois disso, crie a regra.

Esteja ciente de que as zonas e regras do CBR são implantadas de forma assíncrona. Ele pode levar até poucos minutos para que eles se tornem ativos (eventualmente consistentes).

Teste a regra e seus modos de aplicação

1. Em uma nova guia do navegador, abra o serviçoIBM Cloud Logs, selecione a guia Cloud Logs e clique no nome da instância que está recebendo os eventos de auditoria.

2. Inicie uma nova sessão de IBM Cloud Shell em outra aba do navegador.

3. No shell, execute os seguintes comandos: Configure uma variável de ambiente para a região de nuvem que você vai usar para o Container Registry, e.g., us ou de.

   export REGION=us
   

   Defina outra variável para o espaço de nome Container Registry:

   export NAMESPACE=<YOUR_NAMESPACE>
   

   Agora faça o login no Container Registry.

   ibmcloud cr login
   

   Em seguida, puxe uma imagem de contêiner para o ambiente da concha.

   docker pull docker.io/library/hello-world:latest
   

   Re-tag a imagem para fazer o upload dele para o seu espaço de nomes de registro.

   docker tag docker.io/library/hello-world $REGION.icr.io/$NAMESPACE/hello-world
   

   Por último, envie a imagem do contêiner para o registro.

   docker push $REGION.icr.io/$NAMESPACE/hello-world
   

4. Alterne para a guia do navegador com IBM Cloud Logs mostrando os registros de auditoria. No modo de relatório, as entradas de registro são gravadas em IBM Cloud Activity Tracker Event Routing quando uma regra corresponde, independentemente do resultado da decisão. O registro de log tem detalhes sobre o pedido. Na imagem abaixo, a regra para permitir o acesso a um namespace Container Registry foi correspondida no modo de relatório.

   

   Conforme discutido, no modo de relatório, todos os pedidos correspondentes geram uma entrada de log. Nos detalhes do evento você vê um atributo decisão com um valor de Permit ou Deny. Na captura de tela acima está Negar.

5. De volta na aba do navegador com o shell, liste as imagens do container no espaço de nomes.

   ibmcloud cr images --restrict $NAMESPACE
   

6. Em uma terceira aba do navegador, navegue pelas regras do CBR. Ao lado da regra relacionada ao registro que criou anteriormente, clique no menu de pontos e selecione Editar. Vá em Descreva sua regra (Etapa 3) e alterna a regra de Report-only para Enabled. Ative a mudança pressionando o botão Aplicar.

7. Volte para a guia do navegador com IBM Cloud Shell. Emita o mesmo comando de antes para listar as imagens:

   ibmcloud cr images --restrict $NAMESPACE
   

   Desta vez, ele deve resultar em uma mensagem de erro que você não está autorizado.

8. Na guia do navegador com os logs, você deverá encontrar um novo registro semelhante ao seguinte:

   

   A regra foi aplicada e, com base em como você tentou acessar o registro, o acesso foi negado. A razão é que a regra permite o acesso a partir de um VPC específico apenas. O ambiente Cloud Shell e seu endereço IP, conforme documentado nos registros nos campos requestData->environment, são diferentes. Portanto, o pedido é negado.

Ao trabalhar com os logs IBM Cloud Logs, é possível utilizar cadeias de consulta como as seguintes para localizar facilmente os registros de log relevantes:

• Quando no modo de relatório, "context restriction" permit OR deny retorna as linhas de log com acesso o qual teria renderizado um Permit ou Deny.
• No modo de relatório, é possível usar "context restriction" permit para mostrar apenas o acesso que seria permitido. Da mesma forma, use "context restriction" deny para acesso negado.
• Por último, quando em modo forçado, use uma string de consulta como context restriction rendered para linhas de log relacionadas a acesso negado.

O monitoramento de uma nova regra é recomendado para 30 dias antes de aplicá-lo. Saiba mais sobre Monitoramento de restrições baseadas em contexto tanto no modo report-only e ativado na documentação do CBR.

Para se preparar para a implantação de objetos CBR com Terraform em uma seção mais abaixo, vá até a guia do navegador com as regras CBR. Lá, exclua a regra criada anteriormente clicando em seu menu de ponto e selecionando Remover e depois confirmando com Excluir. Depois disso, clique em Zonas de rede e exclua a zona criada anteriormente.

Defina a estratégia de acesso aos seus recursos em nuvem

Para configurar o conjunto certo de regras para restrições baseadas em contexto (CBRs), você deve ter definido a estratégia de acesso para os seus recursos em nuvem. Todos os recursos devem ser protegidos pela gestão de identidade e acesso (IAM). Significa, que as verificações de autenticação e autorização devem ser realizadas antes que um usuário ou ID de serviço acesse um recurso. As CBRs se somam à proteção cortando o acesso à rede com base em critérios de origem e outras regras, mas não substituem a configuração adequada do IAM. Adicionalmente, muitos serviços suportam limitar o tráfego de rede a terminais privados, com isso já reduzindo as opções de acesso.

Você pode achar que algumas regras impactam o conforto dos recursos administrados, por exemplo, através do console do navegador. Além disso, você precisa ter certeza de que você não se nega acesso a recursos, painéis de gerenciamento e APIs. Assim, é preciso contabilizá-los para hospedeiros de bastidores, redes corporativas, gateways e talvez até Cloud Shell. Além disso, alguns serviços suportam uma distinção refinada de plano de dados e acesso ao local de controle para configuração do CBR, e.g., Kubernetes Service APIs de cluster e gerenciamento.

Em síntese, essas perguntas devem ser feitas:

• Todos os recursos são protegidos pelo IAM e similares?
• Como os recursos acessados, eles já estão limitados a terminais privados onde possível?
• É possível separar avião de dados e controlar o acesso de avião?
• O que é o tráfego relacionado ao uso, que para o trabalho administrativo? Como as emergências são tratadas?
• De onde se origam o tráfego acima?

Use o modo de relatório para estar ciente das atividades que correspondem às restrições baseadas em contexto. As decisões baseadas em regras tornam uma permissão ou negam? Isso combina com a sua expectativa? Para aprender sobre as atividades e manejá-las corretamente com as regras do CBR, recomenda-se uma fase de teste no modo de relatório de pelo menos um mês. Isso permite uma abordagem iterativa em direção ao conjunto desejado de zonas de rede e regras de contexto.

Para este tutorial, vamos definir as seguintes zonas de rede:

• uma zona para o cluster do Kubernetes Service
• uma zona para Object Storage
• para uma faixa IP com os endereços de uma rede doméstica (corporativo ou bastion) para servir como homezone

Depois disso, vamos definir regras de contexto da seguinte forma:

• para o acesso ao Instância Key Protect a partir das zonas:
  • Cluster do Kubernetes Service
  • Object Storage
• para o acesso à instância do Object Storage e seu depósito de zonas:
  • Cluster do Kubernetes Service
  • zona inicial
• para o acesso ao Container Registry e ao namespace com a imagem de contêiner de zonas:
  • Cluster do Kubernetes Service
• para obter o acesso ao cluster do Kubernetes Service e sua API de gerenciamento de zonas:
  • zona inicial

Todas as zonas e regras acima podem ser implantadas em modo de relatório-apenas ou forçado com um único comando Terraform. Observe que as regras não são destinadas ao uso de produção, mas como uma amostra para investigar o uso e o tráfego no modo somente de relatório

A documentação tem uma lista de recursos que são suportados como referências de serviço. Você também pode recuperar a lista usando o comando CLI service-ref-targets ou a função API relacionada Lista de destinos de referência de serviço disponíveis.

Usar Terraform para configurar restrições baseadas em contexto

Em vez de criar manualmente as zonas de rede e as regras de contexto para um projeto, recomenda-se automatizar a implantação. Restrições baseadas em contexto podem ser implantadas utilizando-se Infrastructure as Code (IaC)-a saber, Terraform code. Você pode primeiro implementar as zonas e regras com regras no modo report-only para teste. Em seguida, após testes minucioso, mude para o modo forçado, atualizando a configuração implementada.

resource "ibm_cbr_zone" "cbr_zone_k8s" {
  account_id = data.ibm_iam_account_settings.team_iam_account_settings.account_id
  addresses {
    type = "serviceRef"
    ref {
      account_id       = data.ibm_iam_account_settings.team_iam_account_settings.account_id
      service_instance = data.ibm_container_vpc_cluster.cluster.id
      service_name     = "containers-kubernetes"
    }
  }
  description = "Zone with the Kubernetes cluster"
  name        = "cbr_zone_k8s"
}

resource "ibm_cbr_rule" "cbr_rule_cos_k8s" {
  contexts {
    attributes {
      name  = "networkZoneId"
      value = ibm_cbr_zone.cbr_zone_k8s.id
    }
  }
  contexts {
    attributes {
      name  = "networkZoneId"
      value = ibm_cbr_zone.cbr_zone_homezone.id
    }
  }

  description      = "restrict COS access, limit to cluster"
  enforcement_mode = var.cbr_enforcement_mode
  resources {
    attributes {
      name  = "accountId"
      value = data.ibm_iam_account_settings.team_iam_account_settings.account_id
    }
    attributes {
      name     = "serviceInstance"
      operator = "stringEquals"
      value    = var.cos.guid
    }
    attributes {
      name     = "serviceName"
      operator = "stringEquals"
      value    = "cloud-object-storage"
    }
  }
}

Teste as regras de contexto

Com o conjunto de restrições baseadas em contexto implantadas, é hora novamente de verificá-las e testá-las. Para verificar os objetos CBR, vá para a visão geral de restrições baseadas em contexto. Em seguida, inspeciona as novas zonas e regras.

Os testes devem ser realizados em Container Registry, Object Storage e Key Protect e validados através do monitoramento dos logs como realizado anteriormente. Como as zonas e regras incluem uma restrição de acesso no Container Registry, você pode repetir os testes realizados na seção Teste a regra e seus modos de aplicação.

Para testar a nova regra para acesso a Object Storage, siga estas etapas:

1. Em uma aba do navegador, vá para o lista de Object Storage instâncias. Clique no nome do serviço para o tutorial, ex.: secure-file-storage-cos.
2. Em uma segunda guia do navegador, visite o painel IBM Cloud Logs já usado com os registros de auditoria.
3. De volta na aba com a visão geral Object Storage, na lista de Buckets, clique no balde de armazenamento.
4. Use Upload para importar um arquivo para dentro do balde. Deixe a configuração como transferência padrão e use a área Upload de arquivos (objetos) para selecionar um arquivo. Conclua clicando em Upload.
5. De volta à guia do navegador com os logs de auditoria, deve haver registros de log relacionados ao CBR com o título Context restriction matched while in report mode. Isso se deve ao fato de que as regras foram implantadas no modo report. Expanda alguns registros para verificar os dados relatados decisão e isEnforced. Dependendo da faixa IP configurada para a homezone, a decisão pode ser Permit ou Deny. O valor para isEnforced deve ser false por causa do modo de reportagem.

Para testes adicionais, você pode desejar alterar a faixa de IP da homezone. Ele é a variável homezone_iprange nas configurações Schematics.

Remover recursos

Para remover o recurso, use o navegador e navegue até o IBM Cloud Schematics visão geral dos ambientes de. Selecione a área de trabalho, em seguida, no menu Ações, primeiro selecione Destroy resources, posteriormente use Excluir área de trabalho.

Conteúdo relacionado

• Blog post Rumo a Zero Confiança com Restrições baseadas em Contexto
• Post do Blog Introduzindo Restrições Baseadas em Contexto
• O que é Zero Trust?
• Melhores práticas para organizar usuários, equipes, aplicativos