Préambule

Dans le paysage en constante évolution de l'informatique dématérialisée, le maintien d'une sécurité solide tout en garantissant la conformité est un défi essentiel pour les organisations de toutes tailles. Alors que les entreprises adoptent de plus en plus l'informatique dématérialisée, la complexité de la gestion et de la sécurisation des données sur différentes plateformes croît de manière exponentielle.

Amazon Bedrock, avec sa puissante base de services d'apprentissage automatique et d'IA, offre aux organisations un environnement évolutif et sécurisé pour développer et déployer des applications intelligentes. Toutefois, pour exploiter pleinement le potentiel de ces innovations, il est essentiel de mettre en œuvre une approche rationalisée de la sécurité et de la conformité.

L'intégration d'Elastic avec Amazon Bedrock peut considérablement améliorer la surveillance de la sécurité et la gestion de la conformité au sein de votre environnement en nuage. Cette intégration exploite les capacités de recherche, d'observabilité et de sécurité d'Elastic pour optimiser la façon dont vous gérez et sécurisez les applications et les données hébergées sur Amazon Bedrock.

Les capacités de gestion des informations et des événements de sécurité (SIEM) d'Elastic peuvent être utilisées pour analyser les journaux et surveiller les événements générés par les applications fonctionnant sur Amazon Bedrock. Cela permet de détecter en temps réel les menaces potentielles pour la sécurité et de prendre des mesures automatisées pour atténuer les risques.

Cet article vous guidera à travers le processus de configuration de l'intégration d'Amazon Bedrock et d'activation de nos règles de détection prédéfinies pour rationaliser vos opérations de sécurité. Nous couvrirons les aspects clés suivants :

1. Conditions préalables à l'intégration d'Elastic Amazon Bedrock : Comprendre les exigences de base pour configurer l'intégration d'Elastic Amazon Bedrock pour la sécurité dans le nuage.
2. Mise en place de l'intégration d'Amazon Bedrock: Instructions étape par étape pour configurer Amazon Bedrock dans votre infrastructure AWS existante.
3. Activation des règles de sécurité prédéfinies: Comment tirer parti des règles prédéfinies pour détecter les violations de politiques et autres menaces de sécurité les plus probables.
4. Exploration de la détection des blocs d'inconduite à haut niveau de confiance : Un examen approfondi d'une règle préconstruite spécifique conçue pour détecter les blocs d'inconduite à forte probabilité dans Amazon Bedrocklogs.
5. Démonstration d'un scénario d'exploitation pour Amazon Bedrock : Utilisation d'un exemple de script python pour simuler des interactions avec un modèle Amazon Bedrock afin de tester des scénarios d'exploitation susceptibles de déclencher les règles de détection préconstruites d'Elastic.

Conditions préalables à l'intégration d'Elastic Amazon Bedrock

Elastic Integration pour Amazon Bedrock

L'intégration Amazon Bedrock collecte les journaux d'invocation du modèle Amazon Bedrock et les métriques d'exécution avec Elastic Agent. Pour plus d'informations sur l'intégration, vous pouvez consulter notre documentation.

Vous trouverez ci-dessous la liste des conditions préalables à une configuration complète et réussie d'Amazon Bedrock Elastic Integration :

• Configuration du compte AWS
• Exigences en matière de nuage élastique
• Terraform (optionnel)

Configuration du compte AWS

• Compte AWS actif: Assurez-vous que vous disposez d'un compte AWS actif avec les autorisations appropriées pour déployer et gérer des ressources sur Amazon Bedrock.
• Configuration d'Amazon Bedrock: Confirmez que Amazon Bedrock est correctement configuré et opérationnel dans votre environnement AWS. Il s'agit notamment de mettre en place des modèles d'IA, des ensembles de données et d'autres ressources nécessaires à vos applications. Reportez-vous à la section Démarrer avec Amazon Bedrock pour plus d'informations sur la configuration.
• Rôles et autorisations IAM: Créez ou configurez des rôles de gestion des identités et des accès (IAM) avec les autorisations nécessaires pour permettre à Elastic d'accéder aux ressources Amazon Bedrock. Ces rôles doivent disposer de privilèges suffisants pour lire les journaux, les mesures et les traces des services AWS. Vous trouverez plus de détails sur les exigences dans notre documentation AWS.

Exigences en matière de nuage élastique

Note : Puisque l'intégration est en phase de version bêta, veuillez activer l'affichage des intégrations bêta dans la section d'exploration des intégrations du panneau de gestion de votre pile Elastic.

Terraform

Terraform est un outil d'infrastructure en tant que code (IaC) open source créé par HashiCorp qui vous permet de définir, de fournir et de gérer l'infrastructure en nuage et sur site d'une manière cohérente et reproductible.

Il s'agit d'une étape facultative, mais qu'il est bon de réaliser car dans les prochaines sections de l'article, nous utiliserons cet outil pour mettre en place l'infrastructure AWS requise. Pour en savoir plus sur l'installation et la documentation, cliquez ici.

Configuration de l'intégration d'Amazon Bedrock

Dans cette section de l'article, nous allons parcourir les étapes pour mettre en place l'intégration d'Amazon Bedrock avec Elastic en deux parties :

1. Mise en place d'une infrastructure AWS avec Terraform: Dans cette section, nous allons suivre les étapes de la mise en place d'une infrastructure AWS à l'aide de Terraform. Nous allons créer un seau S3, une instance EC2 avec les rôles et politiques IAM nécessaires pour accéder au seau S3, et configurer les groupes de sécurité pour autoriser l'accès SSH. Cette configuration est idéale pour les scénarios dans lesquels vous avez besoin d'une instance EC2 pour interagir avec S3, par exemple pour le traitement ou le stockage de données.
2. Configuration de l'agent élastique et de l'intégration: Dans cette section, nous allons suivre les étapes de l'installation de l'agent élastique sur l'instance AWS EC2 et de la configuration de l'intégration Amazon Bedrock.

Mise en place d'une infrastructure AWS avec Terraform

Le processus de configuration de haut niveau comprend les étapes suivantes :

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

Le fichier providers.tf contient généralement la configuration des fournisseurs Terraform que vous utilisez dans votre projet. Dans notre exemple, elle comprend la configuration du fournisseur AWS. Voici un exemple de contenu de notre fichier providers.tf. L'adresse profile mentionnée dans l'adresse providers.tf doit être configurée dans l'espace utilisateur du fichier d'informations d'identification AWS (~/.aws/credentials). Reportez-vous à Configuration and credential file settings - AWS Command Line Interface, qui est également mis en évidence dans la section credential de la documentation AWS d'Elastic.

Le fichier variables.tf contient les définitions des variables utilisées dans votre configuration Terraform. Pour notre scénario, il inclut la définition de aws_region et resource_labels. Voici un exemple de contenu de notre fichier variables.tf.

Le fichier outputs.tf contient généralement les définitions de sortie de votre configuration Terraform. Ces sorties peuvent être utilisées pour afficher des informations utiles après l'installation de votre infrastructure. Voici un exemple de contenu de notre fichier outputs.tf

Le fichier main.tf contient généralement la collection de toutes ces ressources, telles que les sources de données, le seau S3 et la politique de seau, la configuration du journal d'invocation du modèle Amazon Bedrock, la configuration de la file d'attente SQS, le rôle IAM et les politiques requises par l'instance EC2 qui installerait l'agent élastique et les journaux de flux, ainsi que la configuration du Guardrail d'Amazon Bedrock. Voici un exemple de contenu de notre fichier main.tf.

Une fois que le site main.tf est configuré conformément aux exigences, nous pouvons initialiser, planifier et appliquer la configuration de la terraforme.

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

Pour démanteler l'infrastructure que terraform a précédemment créée, vous pouvez utiliser la commande terraform destroy.

Une fois la configuration de l'infrastructure terminée, les identifiants de ressources nécessaires sont fournis via outputs.tf.. Nous pouvons procéder à une vérification de base de l'infrastructure créée en suivant les étapes suivantes :

1. Vérifiez le S3 Bucket créé à partir de Terraform, vous pouvez utiliser la commande aws cli reference list-buckets - AWS CLI 1.34.10 Command Reference ou naviguer via la console AWS pour vérifier la même chose. 2. Vérifiez la file d'attente SQS créée à partir de la terraform, vous pouvez utiliser la commande aws cli reference list-queues - AWS CLI 1.34.10 Command Reference ou naviguer via la console AWS pour vérifier la même chose.
2. Vérifiez l'instance EC2 créée à partir de la console AWS et connectez-vous à l'instance EC2 via Connect en utilisant EC2 Instance Connect - Amazon Elastic Compute Cloud et exécutez aws s3 ls example-bucket-name pour vérifier si l'instance a accès au seau S3 créé.
3. Vérifiez le Guardrail Amazon Bedrock créé à partir de Terraform, vous pouvez utiliser l'API Amazon Bedrock ListGuardrails - Amazon Bedrock ou naviguer via la console AWS pour vérifier la même chose.

Configuration de l'agent Elastic et de l'intégration

Pour installer Elastic Agent sur l'instance AWS EC2 et configurer l'intégration Amazon Bedrock, créez une politique d'agent à l'aide des étapes guidées dans les politiques d'Elastic Agent | Fleet et Elastic Agent Guide [8.15]. Ensuite, connectez-vous à l'instance ec2 créée lors des étapes de configuration de l'infrastructure via Connect en utilisant EC2 Instance Connect - Amazon Elastic Compute Cloud, et installez l'agent élastique en suivant les étapes guidées dans Install Elastic Agents | Fleet et Elastic Agent Guide [8.15]. Lors de l'installation de l'agent, n'oubliez pas de sélectionner la politique d'agent créée au début de ce processus d'installation et d'utiliser la méthode d'installation de l'agent appropriée en fonction de l'instance créée. Enfin, assurez-vous que l'agent est correctement configuré et qu'il reçoit des données.

Pour configurer l'intégration Amazon Bedrock dans la politique nouvellement créée, ajoutez l'intégration Amazon Bedrock en suivant les étapes guidées : Ajoutez une intégration Elastic Agent à une politique. Activez Beta Integrations pour utiliser l'intégration Amazon Bedrock comme indiqué dans l'image ci-dessous.

Configurez les clés d'accès à l'intégration avec AWS pour accéder au compte AWS où Amazon Bedrock est configuré. Utilisez l'option Collect Logs from S3 bucket et indiquez le Bucket ARN créé à l'étape de configuration. Veuillez noter qu'il faut utiliser soit l'URL du Bucket S3, soit celle de la Queue SQS lors de la configuration, et non les deux à la fois. Ajoutez cette intégration à la politique existante où l'ec2-instance est configurée.

Vérifier les ingérences du journal d'invocation du modèle Amazon Bedrock

Une fois l'agent Elastic et la configuration de l'intégration terminés, nous pouvons effectuer une vérification de base de l'intégration pour déterminer si les journaux sont ingérés comme prévu en utilisant l'exemple d'appel API suivant :

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

L'exemple d'appel à l'API suppose une configuration fonctionnelle avec aws cli et un accès au modèle fondamental Anthropic Claude Messages API - Amazon Bedrock. Si l'utilisateur n'a pas accès au modèle, il peut simplement demander l'accès aux modèles à partir de la page d'accès au modèle comme suggéré dans Accès aux modèles de fondation Amazon Bedrock, ou nous pouvons éventuellement changer l'appel API à tout modèle existant auquel l'utilisateur peut accéder.

Lorsque l'appel API ci-dessus est exécuté avec succès, les journaux d'invocation du modèle Amazon Bedrock sont remplis et, dans Kibana, logs-aws_bedrock.invocation-default doit être rempli avec ces journaux d'invocation. Nous pouvons utiliser la simple requête ES|QL suivante pour retourner les événements récemment ingérés.

from logs-aws_bedrock.invocation-* | LIMIT 10

Activer les règles de détection préconstruites

Pour activer les règles de détection préconstruites, connectez-vous d'abord à l'instance élastique et, dans le volet de navigation de gauche, naviguez vers Sécurité → Règles → Règles de détection (SIEM). Filtre pour "Data Source : Amazon Bedrock" dans la section tags.

Activez les règles préconstruites disponibles. Pour les règles préconstruites, les informations de configuration contiennent un guide d'aide pour configurer les Guardrails AWS pour Amazon Bedrock, ce qui est réalisé dans l'étape Configuration de l'infrastructure AWS avec Terraform si l'exemple est suivi correctement et que la terraform a la configuration Guardrail Amazon Bedrock. Veuillez noter que cette configuration est essentielle pour que certaines règles génèrent des alertes - nous devons nous assurer que le garde-corps est configuré en conséquence s'il a été omis lors de la phase de configuration de l'infrastructure.

L'exploration des fautes professionnelles à forte probabilité bloque la détection

Simulons un scénario réel dans lequel un utilisateur interroge un sujet refusé au modèle Amazon Bedrock. Accédez à la section Amazon Bedrock dans la console Amazon UI, et utilisez le volet de navigation de gauche pour accéder à la sous-section Guardrails sous Safeguards. Utilisez l'exemple de garde-corps créé pendant nos instructions de configuration pour cet exercice, et utilisez l'option test pour exécuter une invocation de modèle avec les garde-corps et interroger le sujet refusé configuré.

Répétez la requête au moins 6 fois, car la règle préconstruite est conçue pour alerter sur plus de 5 blocs de confiance. Lorsque le programme d'alerte est exécuté, nous pouvons voir une alerte s'afficher pour les éléments suivants Unusual High Confidence Misconduct Blocks Detected.

Démonstration d'un scénario d'exploitation pour Amazon Bedrock

Pour simuler un contournement de la sécurité d'Amazon Bedrock, nous avons besoin d'un script de simulation d'exploit pour interagir avec les modèles d'Amazon Bedrock. L'exemple de script d'exploitation que nous fournissons simule le schéma d'attaque suivant :

• Tentative de plusieurs demandes successives d'utilisation de ressources de modèle refusées dans AWS Bedrock
• Génère plusieurs erreurs successives d'exception de validation dans Amazon Bedrock
• L'utilisateur génère régulièrement un nombre élevé de jetons d'entrée, soumet de nombreuses demandes et reçoit des réponses volumineuses qui imitent des schémas d'épuisement des ressources.
• Combinaison d'actions "BLOCKED" répétées et très fiables et de codes de violation spécifiques tels que "MISCONDUCT", indiquant une mauvaise utilisation persistante ou des tentatives de sonder les limites éthiques du modèle.

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()

Note : L'identifiant GUARDRAIL_ID et la version GUARDRAIL_VERSION se trouvent dans la rubrique outputs.tf

Lorsqu'il est exécuté dans un environnement contrôlé, le script fourni simule un scénario d'exploitation qui générerait des alertes de détection dans Elastic Security. Lors de l'analyse de ces alertes à l'aide de la fonction Elastic Attack Discovery, le script crée des chaînes d'attaque qui montrent les relations entre les différentes alertes, ce qui permet aux analystes de comprendre clairement comment plusieurs alertes peuvent faire partie d'une attaque plus importante.

Conclusion

L'intégration d'Elastic avec Amazon Bedrock permet aux organisations de maintenir un environnement cloud sécurisé et conforme tout en maximisant les avantages de l'IA et de l'apprentissage automatique. En exploitant les outils avancés de sécurité et d'observabilité d'Elastic, les entreprises peuvent détecter les menaces de manière proactive, automatiser les rapports de conformité et obtenir des informations plus approfondies sur leurs opérations dans le nuage. De plus en plus, les entreprises s'appuient sur des sources de données et des technologies opaques pour révéler les menaces les plus sérieuses - notre engagement en faveur d'une sécurité transparente est évident dans nos artefacts, nos intégrations et notre code source ouverts.