Effectuez des réécritures sécurisées de bases de données avec Amazon QuickSight

Effectuez des réécritures sécurisées de bases de données avec Amazon QuickSight

Nœud source: 2641420

Amazon QuickSight est une solution de business intelligence (BI) évolutive, sans serveur et basée sur le machine learning (ML) qui facilite la connexion à vos données, la création de tableaux de bord interactifs, l'accès à des informations basées sur le ML et le partage de visuels et de tableaux de bord avec des dizaines de milliers de personnes. des utilisateurs internes et externes, soit dans QuickSight lui-même, soit intégré à n'importe quelle application.

Une réécriture est la possibilité de mettre à jour un datamart, un entrepôt de données ou tout autre back-end de base de données à partir des tableaux de bord BI et d'analyser les données mises à jour en temps quasi réel dans le tableau de bord lui-même. Dans cet article, nous montrons comment effectuer des réécritures sécurisées de base de données avec QuickSight.

Présentation des cas d'utilisation

Pour démontrer comment activer une capacité de réécriture avec QuickSight, considérons une entreprise fictive, AnyCompany Inc. AnyCompany est une société de services professionnels spécialisée dans la fourniture de solutions de main-d'œuvre à ses clients. AnyCompany a déterminé que l'exécution de charges de travail dans le cloud pour répondre aux besoins croissants de son entreprise mondiale constituait un avantage concurrentiel et utilise le cloud pour héberger toutes ses charges de travail. AnyCompany a décidé d'améliorer la manière dont ses succursales fournissent des devis à ses clients. Actuellement, les succursales génèrent manuellement les devis des clients et, comme première étape de ce parcours d'innovation, AnyCompany cherche à développer une solution d'entreprise pour la génération de devis clients avec la capacité d'appliquer dynamiquement les données de tarification locales au moment de la génération des devis.

AnyCompany utilise actuellement Redshift d'Amazon comme plate-forme d'entrepôt de données d'entreprise et QuickSight comme solution BI.

Construire une nouvelle solution s’accompagne des défis suivants :

  • AnyCompany souhaite une solution facile à créer et à maintenir, et ne veut pas investir dans la création d’une interface utilisateur distincte.
  • AnyCompany souhaite étendre les capacités de son tableau de bord QuickSight BI existant pour permettre également la génération et l'acceptation de devis. Cela simplifiera le déploiement de fonctionnalités, car leurs employés utilisent déjà les tableaux de bord QuickSight et profitent de l'interface facile à utiliser fournie par QuickSight.
  • AnyCompany souhaite stocker l'historique des négociations de devis qui comprend les devis générés, révisés et acceptés.
  • AnyCompany souhaite créer un nouveau tableau de bord avec des données d'historique de devis à des fins d'analyse et d'informations commerciales.

Cet article décrit les étapes permettant d'activer la fonctionnalité de réécriture sur Amazon Redshift à partir de QuickSight. Notez que les outils BI traditionnels sont en lecture seule avec peu ou pas d'options pour mettre à jour les données sources.

Vue d'ensemble de la solution

Cette solution utilise les services AWS suivants :

  • Passerelle d'API Amazon – Héberge et sécurise l’API REST de réécriture qui sera invoquée par QuickSight
  • AWS Lambda – Exécute la fonction de calcul requise pour générer le hachage et une deuxième fonction pour effectuer en toute sécurité la réécriture
  • Amazon QuickSight – Offre des tableaux de bord BI et des capacités de génération de devis
  • Redshift d'Amazon – Stocke les devis, les prix et autres ensembles de données pertinents
  • AWS Secrets Manager – Stocke et gère les clés pour signer les hachages (résumé du message)

Bien que cette solution utilise Amazon Redshift comme magasin de données, une approche similaire peut être mise en œuvre avec n'importe quelle base de données prenant en charge la création de fonctions définies par l'utilisateur (UDF) pouvant appeler Lambda.

La figure suivante montre le flux de travail pour effectuer des réécritures à partir de QuickSight.

La première étape de la solution consiste à générer un hachage ou un résumé de message de l'ensemble d'attributs dans Amazon Redshift en appelant une fonction Lambda. Cette étape empêche la falsification de la demande. Pour générer un hachage, Amazon Redshift appelle un scalaire Lambda UDF. Le mécanisme de hachage utilisé ici est le plus populaire BLAKE2 fonction (disponible dans la bibliothèque Python hashlib). Pour sécuriser davantage le hachage, le hachage par clé est utilisé, ce qui constitue une alternative plus rapide et plus simple au code d'authentification de message basé sur le hachage (HMAC). Cette clé est générée et stockée par Secrets Manager et ne doit être accessible qu'aux applications autorisées. Une fois le hachage sécurisé généré, il est renvoyé à Amazon Redshift et combiné dans une vue Amazon Redshift.

La réécriture du devis généré sur Amazon Redshift est effectuée par la fonction de réécriture Lambda, et un point de terminaison d'API REST API Gateway est créé pour sécuriser et transmettre les demandes à la fonction de réécriture. La fonction de réécriture effectue les actions suivantes :

  1. Générez le hachage en fonction des paramètres d'entrée de l'API reçus de QuickSight.
  2. Signez le hachage en appliquant la clé de Secrets Manager.
  3. Comparez le hachage généré avec le hachage reçu des paramètres d'entrée à l'aide de la méthode compare_digest disponible dans le HMAC module.
  4. Une fois la validation réussie, écrivez l'enregistrement dans le tableau de soumission de devis dans Amazon Redshift.

La section suivante fournit des étapes détaillées avec des exemples de charges utiles et des extraits de code.

Générer le hachage

Le hachage est généré à l'aide d'un UDF Lambda dans Amazon Redshift. De plus, une clé Secrets Manager est utilisée pour signer le hachage. Pour créer le hachage, procédez comme suit :

  1. Créez la clé Secrets Manager à partir du Interface de ligne de commande AWS (AWS CLI) :
aws secretsmanager create-secret --name “name_of_secret” --description "Secret key to sign hash" --secret-string '{" name_of_key ":"value"}' --region us-east-1

  1. Créez une UDF Lambda pour générer un hachage pour le chiffrement :
import boto3 import base64
import json
from hashlib import blake2b
from botocore.exceptions import ClientError def get_secret(): #This key is used by the Lambda function to further secure the hash. secret_name = "<name_of_secret>" region_name = "<aws_region_name>" # Create a Secrets Manager client session = boto3.session.Session() client = session.client(service_name='secretsmanager', region_name=<aws_region_name> ) # In this sample we only handle the specific exceptions for the 'GetSecretValue' API. # See https://docs.aws.amazon.com/secretsmanager/latest/apireference/API_GetSecretValue.html # We rethrow the exception by default. try: get_secret_value_response = client.get_secret_value(SecretId=secret_name) except Exception as e: raise e if "SecretString" in get_secret_value_response: access_token = get_secret_value_response["SecretString"] else: access_token = get_secret_value_response["SecretBinary"] return json.loads(access_token)[<token key name>] SECRET_KEY = get_secret()
AUTH_SIZE = 16 def sign(payload): h = blake2b(digest_size=AUTH_SIZE, key=SECRET_KEY) h.update(payload) return h.hexdigest().encode('utf-8') def lambda_handler(event, context):
ret = dict() try: res = [] for argument in event['arguments']: try: msg = json.dumps(argument) signed_key = sign(str.encode(msg)) res.append(signed_key.decode('utf-8')) except: res.append(None) ret['success'] = True ret['results'] = res except Exception as e: ret['success'] = False ret['error_msg'] = str(e) return json.dumps(ret)

  1. Définissez une UDF Amazon Redshift pour appeler la fonction Lambda afin de créer un hachage :
CREATE OR REPLACE EXTERNAL FUNCTION udf_get_digest (par1 varchar)
RETURNS varchar STABLE
LAMBDA 'redshift_get_digest'
IAM_ROLE 'arn:aws:iam::<AWSACCOUNTID>role/service-role/<role_name>';

La Gestion des identités et des accès AWS (IAM) à l'étape précédente doit être associé à la stratégie suivante pour pouvoir appeler la fonction Lambda :

{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": "lambda:InvokeFunction", "Resource": "arn:aws:lambda:us-east-1:<AWSACCOUNTID>1:function:redshift_get_digest" }
}

  1. Récupérez la clé depuis Secrets Manager.

Cette clé est utilisée par la fonction Lambda pour sécuriser davantage le hachage. Ceci est indiqué dans le obtenir_secret fonction à l’étape 2.

Configurer des ensembles de données Amazon Redshift dans QuickSight

Le tableau de bord de génération de devis utilise la vue Amazon Redshift suivante.

Créez une vue Amazon Redshift qui utilise toutes les colonnes précédentes ainsi que la colonne de hachage :

create view quote_gen_vw as select *, udf_get_digest ( customername || BGCheckRequired || Skill|| Shift ||State ||Cost ) from billing_input_tbl

Les enregistrements ressembleront à la capture d'écran suivante.

La vue précédente sera utilisée comme ensemble de données QuickSight pour générer des devis. Une analyse QuickSight sera créée à l’aide de l’ensemble de données. Pour une analyse en temps quasi réel, vous pouvez utiliser le mode de requête directe QuickSight.

Créer des ressources API Gateway

L'opération de réécriture est initiée par QuickSight appelant une ressource API Gateway, qui appelle la fonction de réécriture Lambda. Comme condition préalable à la création du champ calculé dans QuickSight pour appeler l’API de réécriture, vous devez d’abord créer ces ressources.

API Gateway sécurise et appelle la fonction Lambda de réécriture avec les paramètres créés en tant que paramètres de chaîne de requête URL avec des modèles de mappage. Les paramètres de mappage peuvent être évités en utilisant l'intégration du proxy Lambda.

Créez une ressource API REST de type de méthode GET qui utilise les fonctions Lambda (créées à l'étape suivante) comme type d'intégration. Pour obtenir des instructions, reportez-vous à Création d'une API REST dans Amazon API Gateway ainsi que Configurer les intégrations Lambda dans API Gateway.

La capture d'écran suivante montre les détails de la création d'un paramètre de chaîne de requête pour chaque paramètre transmis à API Gateway.

La capture d'écran suivante montre les détails de la création d'un paramètre de modèle de mappage pour chaque paramètre transmis à API Gateway.

Créer la fonction Lambda

Créez une nouvelle fonction Lambda que API Gateway devra appeler. La fonction Lambda effectue les étapes suivantes :

  1. Recevez les paramètres de QuickSight via API Gateway et hachez les paramètres concaténés.

L'exemple de code suivant récupère les paramètres de l'appel API Gateway à l'aide de l'objet événement de la fonction Lambda :

 customer= event['customer’]) bgc = event['bgc']

La fonction exécute la logique de hachage comme indiqué dans le créer du hachage étape plus tôt en utilisant les paramètres concaténés transmis par QuickSight.

  1. Comparez la sortie hachée avec le paramètre de hachage.

Si ceux-ci ne correspondent pas, la réécriture n’aura pas lieu.

  1. Si les hachages correspondent, effectuez une réécriture. Vérifiez la présence d'un enregistrement dans la table de génération de devis en générant une requête à partir de la table à l'aide des paramètres transmis depuis QuickSight :
query_str = "select * From tbquote where cust = '" + cust + "' and bgc = '" + bgc +"'" +" and skilledtrades = '" + skilledtrades + "' and shift = '" +shift + "' and jobdutydescription ='" + jobdutydescription + "'"

  1. Effectuez l'action suivante en fonction des résultats de la requête :
    1. Si aucun enregistrement n'existe pour la combinaison précédente, générez et exécutez une requête d'insertion en utilisant tous les paramètres avec le statut généré.
    2. Si un enregistrement existe pour la combinaison précédente, générez et exécutez une requête d'insertion avec le statut en cours de révision. Le quote_Id de la combinaison existante sera réutilisé.

Créer un visuel QuickSight

Cette étape implique la création d'un visuel de table qui utilise un champ calculé pour transmettre des paramètres à API Gateway et appeler la fonction Lambda précédente.

  1. Ajoutez un champ calculé QuickSight nommé Generate Quote pour contenir l'URL hébergée par API Gateway qui sera déclenchée pour réécrire l'historique du devis dans Amazon Redshift :
concat("https://xxxxx.execute-api.us-east-1.amazonaws.com/stage_name/apiresourcename/?cust=",customername,"&bgc=",bgcheckrequired,"&billrate=",toString(billrate),"&skilledtrades=",skilledtrades,"&shift=",shift,"&jobdutydescription=",jobdutydescription,"&hash=",hashvalue)

  1. Créez un visuel de tableau QuickSight.
  2. Ajoutez des champs obligatoires tels que Client, Compétence et Coût.
  3. Ajoutez le champ calculé Générer un devis et stylisez-le sous forme de lien hypertexte.

Le choix de ce lien écrira l'enregistrement dans Amazon Redshift. Cela incombe à la même valeur de hachage renvoyée lorsque la fonction Lambda effectue le hachage sur les paramètres.

La capture d'écran suivante montre un exemple de visuel de tableau.

Écrire dans la base de données Amazon Redshift

La clé Secrets Manager est récupérée et utilisée par la fonction Lambda pour générer le hachage à des fins de comparaison. La réécriture ne sera effectuée que si le hachage correspond au hachage passé en paramètre.

Le tableau Amazon Redshift suivant capturera l'historique des devis tel que renseigné par la fonction Lambda. Les enregistrements en vert représentent les enregistrements les plus récents du devis.

Considérations et prochaines étapes

L'utilisation de hachages sécurisés empêche la falsification des paramètres de charge utile visibles dans la fenêtre du navigateur lorsque l'URL de réécriture est invoquée. Pour sécuriser davantage l'URL de réécriture, vous pouvez utiliser les techniques suivantes :

  • Déployez l'API REST dans un VPC privé accessible uniquement aux utilisateurs QuickSight.
  • Pour empêcher les attaques par relecture, un horodatage peut être généré parallèlement à la fonction de hachage et transmis comme paramètre supplémentaire dans l'URL de réécriture. La fonction Lambda backend peut ensuite être modifiée pour autoriser les réécritures uniquement dans un certain seuil temporel.
  • Suivez la passerelle API contrôle d'accès ainsi que sécurité les meilleures pratiques.
  • Réduire les Déni de service potentiel pour les API destinées au public.

Vous pouvez encore améliorer cette solution pour afficher un formulaire Web lorsque l'URL de réécriture est ouverte. Cela pourrait être implémenté en générant dynamiquement un formulaire HTML dans la fonction backend Lambda pour prendre en charge la saisie d'informations supplémentaires. Si votre charge de travail nécessite un nombre élevé de réécritures qui nécessitent un débit ou une simultanéité plus élevé, un magasin de données spécialement conçu comme Édition compatible Amazon Aurora PostgreSQL pourrait être un meilleur choix. Pour plus d'informations, reportez-vous à Appel d'une fonction AWS Lambda à partir d'un cluster de base de données Aurora PostgreSQL. Ces mises à jour peuvent ensuite être synchronisées dans les tables Amazon Redshift à l'aide de requêtes fédérées.

Conclusion

Cet article montre comment utiliser QuickSight avec Lambda, API Gateway, Secrets Manager et Amazon Redshift pour capturer les données saisies par l'utilisateur et mettre à jour en toute sécurité votre entrepôt de données Amazon Redshift sans quitter votre environnement QuickSight BI. Cette solution élimine le besoin de créer une application externe ou une interface utilisateur pour les opérations de mise à jour ou d'insertion de base de données, et réduit les frais de développement et de maintenance associés. L'appel API Gateway peut également être sécurisé à l'aide d'une clé ou d'un jeton pour garantir que seuls les appels provenant de QuickSight sont acceptés par API Gateway. Cela sera abordé dans les articles suivants.


À propos des auteurs

Srikanth Baheti est un architecte de solutions principal mondial spécialisé pour Amazon QuickSight. Il a commencé sa carrière en tant que consultant et a travaillé pour plusieurs organisations privées et gouvernementales. Plus tard, il a travaillé pour PerkinElmer Health and Sciences & eResearch Technology Inc, où il était responsable de la conception et du développement d'applications Web à fort trafic, de pipelines de données hautement évolutifs et maintenables pour les plateformes de reporting utilisant les services AWS et l'informatique sans serveur.

Raji Sivasubramaniam est un architecte de solutions senior chez AWS, spécialisé dans l'analyse. Raji est spécialisé dans l'architecture de solutions de gestion des données d'entreprise, de Business Intelligence et d'analyse de bout en bout pour les entreprises Fortune 500 et Fortune 100 à travers le monde. Elle possède une expérience approfondie des données et des analyses de santé intégrées avec une grande variété d'ensembles de données de santé, y compris le marché géré, le ciblage des médecins et l'analyse des patients.

Horodatage:

Plus de Big Data AWS