Preâmbulo

No cenário em constante evolução da computação em nuvem, manter uma segurança robusta e, ao mesmo tempo, garantir a conformidade é um desafio crítico para organizações de todos os portes. Com a crescente adoção da nuvem pelas empresas, a complexidade de gerenciar e proteger dados em diversas plataformas aumenta exponencialmente.

O Amazon Bedrock, com sua poderosa base de aprendizado de máquina e serviços de IA, oferece um ambiente escalável e seguro para que as organizações desenvolvam e implementem aplicativos inteligentes. No entanto, para aproveitar plenamente o potencial dessas inovações, é essencial implementar uma abordagem simplificada em relação à segurança e à conformidade.

A integração do Elastic com o Amazon Bedrock pode aprimorar significativamente o monitoramento de segurança e o gerenciamento de conformidade em seu ambiente de nuvem. Essa integração aproveita os recursos de busca, observabilidade e segurança da Elastic para otimizar a forma como você gerencia e protege aplicativos e dados hospedados no Amazon Bedrock.

Os recursos de gerenciamento de informações e eventos de segurança (SIEM) da Elastic podem ser usados para analisar logs e monitorar eventos gerados por aplicativos em execução no Amazon Bedrock. Isso permite a detecção de potenciais ameaças à segurança em tempo real e ações de resposta automatizadas para mitigar os riscos.

Este artigo irá guiá-lo pelo processo de configuração da integração com o Amazon Bedrock e ativação de nossas regras de detecção predefinidas para otimizar suas operações de segurança. Abordaremos os seguintes aspectos principais:

1. Pré-requisitos para a integração do Elastic Amazon Bedrock: Compreender os requisitos essenciais para configurar a integração do Elastic Amazon Bedrock para segurança na nuvem.
2. Configurando a integração do Amazon Bedrock: instruções passo a passo para configurar o Amazon Bedrock em sua infraestrutura AWS existente.
3. Habilitando regras de segurança predefinidas: como aproveitar regras predefinidas para detectar violações de políticas de alta confiabilidade e outras ameaças à segurança.
4. Explorando a detecção de bloqueios de má conduta de alta confiança: uma análise detalhada de uma regra predefinida específica, projetada para detectar bloqueios de má conduta de alta confiança nos logs do Amazon Bedrock.
5. Demonstrar um cenário de exploração para o Amazon Bedrock: Utilizar um script Python de exemplo para simular interações com um modelo do Amazon Bedrock para testar cenários de exploração que possam acionar regras de detecção predefinidas do Elastic.

Pré-requisitos para a integração do Elastic Amazon Bedrock

Integração elástica para Amazon Bedrock

A integração com o Amazon Bedrock coleta logs de invocação de modelos do Amazon Bedrock e métricas de tempo de execução com o Elastic Agent. Para obter informações mais detalhadas sobre a integração, consulte a nossa documentação.

A seguir, a lista de pré-requisitos para uma configuração completa e bem-sucedida da integração do Amazon Bedrock com o Elasticsearch:

• Configuração de conta da AWS
• Requisitos da Nuvem Elástica
• Terraform (Opcional)

Configuração de conta da AWS

• Conta AWS ativa: Certifique-se de ter uma conta AWS ativa com as permissões apropriadas para implantar e gerenciar recursos no Amazon Bedrock.
• Configuração do Amazon Bedrock: Confirme se o Amazon Bedrock está configurado corretamente e operacional em seu ambiente AWS. Isso inclui a configuração de modelos de IA, conjuntos de dados e outros recursos necessários para suas aplicações. Consulte o guia Introdução ao Amazon Bedrock para obter mais informações sobre a configuração.
• Funções e permissões do IAM: Crie ou configure funções do Identity and Access Management (IAM) com as permissões necessárias para permitir que o Elastic acesse os recursos do Amazon Bedrock. Essas funções devem ter privilégios suficientes para ler logs, métricas e rastreamentos de serviços da AWS. Detalhes adicionais sobre os requisitos podem ser encontrados em nossa documentação da AWS.

Requisitos da Nuvem Elástica

Observação: Como a integração está em fase beta, habilite a opção "Exibir integrações beta" na seção "Procurar integrações" do painel de gerenciamento do seu Elastic Stack.

Terraformar

O Terraform é uma ferramenta de infraestrutura como código (IaC) de código aberto criada pela HashiCorp que permite definir, provisionar e gerenciar infraestrutura em nuvem e local de forma consistente e repetível.

Esta etapa é opcional, mas é útil, pois nas próximas seções do artigo usaremos essa ferramenta para configurar a infraestrutura AWS necessária. Informações detalhadas sobre instalação e documentação podem ser encontradas aqui.

Configurando a integração do Amazon Bedrock

Nesta seção do artigo, vamos percorrer os passos para configurar a integração do Amazon Bedrock com o Elastic em duas partes:

1. Configurando a infraestrutura da AWS com Terraform: Nesta seção, vamos percorrer os passos para configurar uma infraestrutura da AWS usando o Terraform. Criaremos um bucket S3, uma instância EC2 com as funções e políticas IAM necessárias para acessar o bucket S3 e configuraremos grupos de segurança para permitir o acesso SSH. Essa configuração é ideal para cenários em que você precisa de uma instância EC2 para interagir com o S3, como para processamento ou armazenamento de dados.
2. Configuração do Elastic Agent e da integração: Nesta seção, vamos abordar os passos para instalar o Elastic Agent na instância EC2 da AWS e configurar a integração com o Amazon Bedrock.

Configurando a infraestrutura da AWS com Terraform

O processo de configuração de alto nível envolverá as seguintes etapas:

1. Configurando providers.tf
2. Configurando variables.tf
3. Configurando outputs.tf
4. Configurando main.tf

O arquivo providers.tf normalmente contém a configuração de quaisquer provedores Terraform que você esteja usando em seu projeto. Em nosso exemplo, isso inclui a configuração do provedor AWS. Aqui está o conteúdo de exemplo do nosso arquivo providers.tf . O profile mencionado no providers.tf deve ser configurado no espaço do usuário do arquivo de credenciais da AWS (~/.aws/credentials). Consulte Configurações de arquivo de configuração e credenciais - Interface de linha de comando da AWS, que também é destacada na seção de credenciais da documentação da AWS da Elastic.

O arquivo variables.tf contém as definições de variáveis usadas em toda a sua configuração do Terraform. Para o nosso cenário, isso inclui a definição de aws_region e resource_labels. Aqui está o conteúdo de exemplo do nosso arquivo variables.tf .

O arquivo outputs.tf normalmente contém as definições de saída para sua configuração do Terraform. Esses resultados podem ser usados para exibir informações úteis após o provisionamento da sua infraestrutura. Aqui está um exemplo do conteúdo do nosso arquivo outputs.tf

O arquivo main.tf normalmente contém a coleção de todos esses recursos, como fontes de dados, bucket S3 e política de bucket, configuração do Amazon Bedrock Model Invocation Log, configuração da fila SQS, função e políticas do IAM necessárias para a instância EC2 que instalará o Elastic Agent e os logs de fluxo, além da configuração do Amazon Bedrock Guardrail. Aqui está o conteúdo de exemplo do nosso arquivo main.tf .

Uma vez que o main.tf esteja configurado de acordo com os requisitos, podemos então inicializar, planejar e aplicar a configuração do Terraform.

terraform init // initializes the directory and sets up state files in backend
terraform plan // command creates an execution plan
terraform apply // command applies the configuration aka execution step

Para remover a infraestrutura que o Terraform criou anteriormente, pode-se usar o comando terraform destroy .

Após a configuração da infraestrutura, os identificadores de recursos necessários são fornecidos via outputs.tf. Podemos realizar uma verificação básica da infraestrutura criada seguindo os passos abaixo:

1. Para verificar o bucket S3 criado pelo Terraform, você pode usar o comando `aws cli list-buckets` (consulte a Referência de Comandos da AWS CLI 1.34.10) ou navegar pelo console da AWS. 2. Verifique a fila SQS criada pelo Terraform. Você pode usar o comando `list-queues` da AWS CLI (consulte a Referência de Comandos da AWS CLI 1.34.10) ou navegar pelo console da AWS para verificar.
2. Verifique a instância EC2 criada no console da AWS e conecte-se à instância EC2 usando o Connect usando o EC2 Instance Connect - Amazon Elastic Compute Cloud e execute aws s3 ls example-bucket-name para verificar se a instância tem acesso ao bucket S3 criado.
3. Verifique o Guardrail do Amazon Bedrock criado pelo Terraform. Você pode usar a API ListGuardrails do Amazon Bedrock ou navegar pelo console da AWS para fazer a verificação.

Configuração do Elastic Agent e da integração

Para instalar o Elastic Agent na instância EC2 da AWS e configurar a integração com o Amazon Bedrock, crie uma política de agente usando as etapas guiadas em Políticas do Elastic Agent | Guia do Fleet e do Elastic Agent [8.15]. Em seguida, faça login na instância EC2 criada nas etapas de configuração da infraestrutura por meio do Connect usando o EC2 Instance Connect - Amazon Elastic Compute Cloud e instale o agente elástico usando as etapas guiadas em Instalar agentes elásticos | Guia do Fleet e do agente elástico [8.15]. Durante a instalação do agente, lembre-se de selecionar a política de agente criada no início deste processo de configuração e usar o método de instalação de agente relevante, dependendo da instância criada. Por fim, certifique-se de que o agente esteja configurado corretamente e que esteja recebendo dados do agente.

Para configurar a integração do Amazon Bedrock na política recém-criada, adicione a integração do Amazon Bedrock seguindo os passos guiados: Adicionar uma integração do Elastic Agent a uma política. Ative as integrações beta para usar a integração com o Amazon Bedrock, conforme mostrado na imagem abaixo.

Configure a integração com as chaves de acesso da AWS para acessar a conta da AWS onde o Amazon Bedrock está configurado. Utilize a opção "Coletar logs do bucket S3" e especifique o ARN do bucket criado na etapa de configuração. Observe que, durante a configuração, você deve usar o URL do bucket S3 ou o URL da fila SQS, e não ambos. Adicione essa integração à política existente onde a instância EC2 está configurada.

Verificar ingestão de logs de invocação do modelo Amazon Bedrock

Após a configuração do Elastic Agent e da integração, podemos realizar uma verificação básica da integração para determinar se os logs estão sendo ingeridos conforme o esperado, utilizando o seguinte exemplo de chamada de API:

aws bedrock-runtime converse \
--model-id "anthropic.claude-3-5-sonnet-20240620-v1:0" \
--messages '[{"role":"user","content":[{"text":"Hello "}]}]' \
--inference-config '{"maxTokens":2000,"stopSequences":[],"temperature":1,"topP":0.999}' \
--additional-model-request-fields '{"top_k":250}' \
--region us-east-1

A chamada de API de exemplo pressupõe uma configuração funcional com a AWS CLI e acesso ao modelo fundamental Anthropic Claude Messages API - Amazon Bedrock. Se o usuário não tiver acesso ao modelo, basta solicitar acesso a modelos na página de acesso a modelos, conforme sugerido em Acessar modelos do Amazon Bedrock Foundation, ou podemos, opcionalmente, alterar a chamada da API para qualquer modelo existente ao qual o usuário tenha acesso.

Após a execução bem-sucedida da chamada de API acima, os logs de invocação do modelo Amazon Bedrock são preenchidos e no Kibana logs-aws_bedrock.invocation-default deve ser preenchido com esses logs de invocação. Podemos usar a seguinte consulta ES|QL simples para retornar eventos ingeridos recentemente.

from logs-aws_bedrock.invocation-* | LIMIT 10

Ativar regras de detecção predefinidas

Para ativar as regras de detecção predefinidas, primeiro faça login na instância elástica e, no painel de navegação à esquerda, navegue até Segurança → Regras → Regras de detecção (SIEM). Filtre por “Fonte de dados: Amazon Bedrock” na seção de tags.

Ative as regras predefinidas disponíveis. Para regras pré-configuradas, as informações de configuração contêm um guia auxiliar para configurar o AWS Guardrails para o Amazon Bedrock, o que é feito na etapa " Configurando a infraestrutura da AWS com o Terraform" se o exemplo for seguido corretamente e o arquivo Terraform tiver a configuração do Amazon Bedrock Guardrails. Observe que esta configuração é vital para que algumas regras gerem alertas – precisamos garantir que a proteção esteja configurada adequadamente caso seja ignorada na fase de configuração da infraestrutura.

Explorando a detecção de blocos de má conduta de alta confiança

Vamos simular um cenário do mundo real em que um usuário consulta um tópico negado ao modelo Amazon Bedrock. Acesse a seção Amazon Bedrock no Console da interface do usuário da Amazon e use o painel de navegação à esquerda para acessar a subseção Guardrails em Safeguards. Utilize o modelo de proteção criado durante as instruções de configuração para este exercício e use a opção de teste para executar uma invocação de modelo com as proteções configuradas e consultar o tópico negado.

Repita a consulta pelo menos 6 vezes, pois a regra pré-construída foi projetada para alertar sobre mais de 5 blocos de alta confiança. Quando o agendamento de alertas for executado, poderemos ver um alerta aparecer para Unusual High Confidence Misconduct Blocks Detected.

Demonstre um cenário de exploração de vulnerabilidade no Amazon Bedrock.

Para simular uma violação de segurança do Amazon Bedrock, precisamos de um script de simulação de exploração para interagir com os modelos do Amazon Bedrock. O exemplo de script de exploração que fornecemos simula o seguinte padrão de ataque:

• Tentativas sucessivas de uso de recursos de modelo negados no AWS Bedrock
• Gera vários erros de exceção de validação sucessivos no Amazon Bedrock.
• O usuário gera consistentemente um grande número de tokens de entrada, envia inúmeras solicitações e recebe respostas extensas que simulam padrões de esgotamento de recursos.
• Combina ações repetidas de "BLOQUEADO" com alta confiança, juntamente com códigos de violação específicos, como "CONDUTA INADEQUADA", indicando uso indevido persistente ou tentativas de testar os limites éticos do modelo.

class BedrockModelSimulator:
   def __init__(self, profile_name, region_name):
       // Create a Boto3 Session Client for Ineration 
   def generate_args_invoke_model(self, model_id, user_message, tokens): 	// Generate Model Invocation parameters
       guardrail_id = <<GUARDRAIL_ID>>
       guardrail_version = <<GUARDRAIL_VERSION>>

       guardrail_config = {
           "guardrailIdentifier": guardrail_id,
           "guardrailVersion": guardrail_version,
           "trace": "enabled"
       }
       conversation = [
           {
               "role": "user",
               "content": [{"text": user_message}],
           }
       ]
       inference_config = {"maxTokens": tokens, "temperature": 0.7, "topP": 1}
       additional_model_request_fields = {}

       kwargs = {
           "modelId": model_id,
           "messages": conversation,
           "inferenceConfig": inference_config,
           "additionalModelRequestFields": additional_model_request_fields
	    "guardrailConfig" : guardrail_config
       }
       return kwargs
  
   def invoke_model(self, invocation_arguments):
       for _ in range(count):
           try:
               // Invoke Model With right invocation_arguments
           except ClientError as e:
               // Error meesage

def main():
   profile_name = <<AWS Profile>>
   region_name = 'us-east-1'
   denied_model_id = // Use a denied model   
   denied_model_user_message = // Sample Message 
   available_model_id = // Use an available model  
   validation_exception_user_message = // Sample Message 
   resource_exploit_user_message = // A very big message for resource exhuastion
   denied_topic_user_message = // Sample Message that can query denied topic configured
   simulator = BedrockModelSimulator(profile_name, region_name)
   denied_model_invocation_arguments = simulator.generate_args_invoke_model(denied_model_id, denied_model_user_message, 200)
   simulator.invoke_model(denied_model_invocation_arguments)
   validation_exception_invocation_arguments = simulator.generate_args_invoke_model(available_model_id, validation_exception_user_message, 6000)
   simulator.invoke_model(validation_exception_invocation_arguments)
   resource_exhaustion_invocation_arguments = simulator.generate_args_invoke_available_model(available_model_id, resource_exploit_user_message, 4096)
   simulator.invoke_model(resource_exhaustion_invocation_arguments)
   denied_topic_invocation_arguments = simulator.generate_args_invoke_available_model_guardrail(available_model_id, denied_topic_user_message, 4096)
   simulator.invoke_model(denied_topic_invocation_arguments)

if __name__ == "__main__":
   main()

Nota: O GUARDRAIL_ID e o GUARDRAIL_VERSION podem ser encontrados em outputs.tf

Quando executado em um ambiente controlado, o script fornecido simula um cenário de exploração que geraria alertas de detecção no Elastic Security. Ao analisar esses alertas usando o recurso Elastic Attack Discovery, o script cria cadeias de ataque que mostram as relações entre vários alertas, proporcionando aos analistas uma compreensão clara de como vários alertas podem fazer parte de um ataque maior.

Conclusão

A integração do Elastic com o Amazon Bedrock permite que as organizações mantenham um ambiente de nuvem seguro e em conformidade, ao mesmo tempo que maximizam os benefícios da IA e do aprendizado de máquina. Ao aproveitar as ferramentas avançadas de segurança e observabilidade da Elastic, as empresas podem detectar ameaças proativamente, automatizar a geração de relatórios de conformidade e obter insights mais profundos sobre suas operações na nuvem. Cada vez mais, as empresas dependem de fontes de dados e tecnologias opacas para revelar as ameaças mais graves — nosso compromisso com a segurança transparente é evidente em nossos artefatos abertos, integrações e código-fonte.