Connectez-vous en toute sécurité avec le connecteur d'authentification AWS | Mendix

Passer au contenu principal

Connectez-vous en toute sécurité avec le connecteur d'authentification AWS

Mendix a publié le connecteur d'authentification AWS, permettant aux développeurs de s'authentifier facilement sur AWS et de commencer à utiliser leur gamme de services.

La sécurité est bien sûr essentielle, en particulier lorsque vous utilisez des services à la carte comme AWS. Il est donc essentiel de suivre les meilleures pratiques lors de l'intégration avec les services AWS. À cette fin, le connecteur d'authentification AWS dispose de différents moyens d'authentification, dont le plus sûr est l'utilisation des informations d'identification de session. Cela permet essentiellement à votre application d'adopter un rôle d'utilisateur IAM pendant une période définie (généralement environ une heure). Tirer parti de la fonctionnalité IAM Roles Anywhere récemment publiée.

Image présentant le contenu : Bonnes pratiques pour une intégration sécurisée aux services AWS. Informations d'identification basées sur la session. Le connecteur Amazon DynamoDB demande l'objet Credentials au connecteur d'authentification AWS via l'action GetSessionCredentials. Le connecteur d'authentification AWS demande un jeton de session temporaire via AWS STS via Roles Anywhere. Le jeton temporaire renvoyé sert à signer la requête à DynamoDB via le connecteur DynamoDB. Si la session possède le rôle et la configuration appropriés, l'opération est autorisée ; sinon, une exception AccessDenied est levée.

certifié

Cette méthode d'authentification utilise des certificats pour authentifier votre application auprès d'AWS. Pour pouvoir l'utiliser, vous devrez obtenir des certificats clients. Ce n'est pas une mince affaire si vous n'avez pas accès à votre propre autorité de certification (CA).

Pour créer un certificat auto-signé, nous allons utiliser openSSL qui est un outil de ligne de commande open source à des fins cryptographiques. Vous pouvez installer openssl ici, ou tu peux utilisez l'openssl fourni avec votre installation Git.

Il existe d'autres moyens de générer des certificats. Vous pouvez utiliser le Service d'autorité de certification privée AWS ou un service de certificat public. Nous utilisons openssl pour deux raisons :

  1. Coût – il s’agit d’un outil de ligne de commande gratuit sans implications financières, parfait pour le développement et les tests.
  2. Sécurité – l’utilisation d’une autorité de certification publique comme ancre de confiance signifie que tous les certificats générés par cette autorité de certification seront approuvés, tandis que vous pouvez limiter avec des contraintes de politique, ce n'est pas recommandé.

Mème avec un homme en trench-coat disant « Ohh encore une chose »

Ces commandes ont été testées sur Windows et Linux (désolé pour les utilisateurs Mac, même si je pense qu'elles sont identiques). Si vous utilisez Windows et que vous souhaitez exécuter sur le Mendix cloud, assurez-vous que vous avez installé openSSL version 3.X.

Avis de non-responsabilité : la création de vos propres certificats auto-signés nécessite une attention particulière aux détails et peut ne pas convenir à votre cas d'utilisation. Assurez-vous de bien comprendre les risques encourus et que votre CA et votre clé sont conservées en toute sécurité et en toute confidentialité à tout moment.

Certificats auto-signés

Créer une racine

La première chose à faire est de créer un certificat racine qui agira comme votre autorité de certification et votre ancre de confiance. Il sera utilisé pour signer tous vos certificats supplémentaires et répond aux exigences suivantes :

  • Doit être au format PEM
  • Doit être la version 3
  • Les contraintes de base doivent inclure CA : TRUE

Pour ce faire, vous devrez mettre à jour votre fichier openssl.cnf. Il s'agit d'un fichier de configuration pour openssl et il se trouve à l'endroit où vous avez installé votre openssl dans le dossier bin. Localisez la section v3_ca et mettez-la à jour comme suit :

[ v3_ca ]
    basicConstraints        =critical, CA:TRUE
    subjectKeyIdentifier    =hash
    authorityKeyIdentifier  =keyid:always, issuer:always
    keyUsage                =critical, cRLSign, digitalSignature, keyCertSign

Après cela, nous devons générer notre clé privée et créer notre fichier PEM CA. Nous devrons utiliser le Algorithme RSA ou EC pour générer notre clé.

openssl genrsa -out PrivateCA.key 4096
    openssl req -new -x509 -days 3650 -key PrivateCA.key -out PrivateCA.pem -extensions v3_ca

Vous pouvez ici fournir certaines informations d'identification pour le certificat :

openssl x509 -in PrivateCA.pem -text -noout

C'est également une bonne idée de valider que nous avons bien créé un certificat v3.

Image montrant le chemin C pour la validation du certificat V3

Certificats clients

Maintenant que nous avons notre autorité de certification, nous pouvons générer des certificats clients que nous utiliserons pour obtenir nos informations d'identification dans AWS. AWS a les exigences suivantes pour le certificat client que vous utilisez :

  • Doit être la version 3 (X.509v3)
  • Les contraintes de base doivent inclure CA : FAUX
  • L'utilisation de la clé doit inclure la signature numérique
  • L'algorithme de signature doit inclure SHA256 ou supérieur.

Pour répondre à ces exigences, nous devons d'abord créer un fichier d'extension, que nous appellerons lors de la génération de notre certificat. Placez un fichier nommé v3.ext dans le même répertoire que votre certificat racine, avec le contenu suivant :

authorityKeyIdentifier=keyid,issuer
    basicConstraints=CA:FALSE
    keyUsage = digitalSignature, nonRepudiation, keyEncipherment, dataEncipherment

Maintenant, pour notre certificat, nous créons d’abord une clé :

openssl genrsa -out client.key 4096

Ensuite, nous créons un nouveau certificat :

openssl req -new -key client.key -out client.csr

Enfin, nous le signons avec notre autorité de certification racine :

openssl x509 -req -in client.csr -CA PrivateCA.pem -CAkey PrivateCA.key -set_serial 01 -out client.pem -days 3650 -sha256 -extfile v3.ext

Une fois cette opération terminée, vous devriez avoir les fichiers suivants dans votre dossier Certificats :

Image montrant v3.ext dans le dossier des certificats

Il reste une étape pour pouvoir utiliser nos certificats dans notre Mendix application : Nous devons exporter notre certificat client vers le format pfx qui peut être téléchargé sur notre application.

openssl pkcs12 -export -in client.pem -inkey client.key -certpbe PBE-SHA1-3DES -keypbe PBE-SHA1-3DES -macalg sha1 -out client.pfx

Vous devrez spécifier un mot de passe que vous devrez utiliser ultérieurement.

Vous pouvez désormais utiliser ces certificats pour connecter votre Mendix application aux services AWS.

AWS

L’étape suivante consiste à transmettre votre certificat racine à IAM Roles Anywhere et à le connecter au rôle IAM que vous souhaitez utiliser.

Ouvrez votre console AWS et recherchez IAM Roles Anywhere.

Image de la console AWS avec IAM Roles Anywhere

Nous allons commencer par créer une ancre de confiance connectée à notre autorité de certification racine. Donnez un nom à l'ancre de confiance et sélectionnez le groupe de certificats externes dans le groupe de certificats externes avant de coller le contenu de PrivateCA.pem :

Image montrant la fenêtre Modifier l'ancre de confiance

Assurez-vous que l’ancre de confiance se trouve dans la même région que les services que vous souhaitez utiliser.

Une fois que vous avez votre Trust Anchor, vous aurez besoin d'un rôle IAM à assumer. Créez un nouveau rôle IAM et ajoutez une politique de confiance personnalisée :

  {
      "Version":"2012-10-17",
      "Statement":[
        {
          "Effect":"Allow",
          "Principal":{
          "Service":"rolesanywhere.amazonaws.com"
        },
        "Action":[
            "sts:AssumeRole",
            "sts:SetSourceIdentity",
            "sts:TagSession"
          ]
        }
      ]
    }

Vous devrez ensuite ajouter une politique IAM. Notez qu'il est recommandé d'accorder les autorisations minimales requises par le rôle. Ici, nous accordons des droits pour interagir avec le bucket S3 mendixdemo.com.


     {
        "Version": "2012-10-17",
        "Statement": [
            {
                "Effect": "Allow",
                "Action": [
                    "s3:PutObject"
                ],
                "Resource": "arn:aws:s3:::mendixdemo.com/*"
            }
        ]
    }

Ensuite, vous aurez besoin d'un profil pour assumer ce rôle, alors recherchez à nouveau IAM Roles Anywhere et créez un profil, en attribuant le rôle que nous venons de créer

Image montrant la création d'un profil pour assumer le rôle IAM Roles Anywhere

Mendix Local

À ce stade, nous pouvons utiliser nos certificats et nos rôles AWS pour intégrer notre Mendix application. Nous commencerons par le développement local. Pour faire la démonstration, j'ai mis en place un projet de démonstration simple et j'ai téléchargé le connecteur d'authentification AWS et le connecteur S3 depuis la place de marché.

Commençons par configurer notre connecteur AWS. Il a juste besoin des ARN des éléments que nous avons créés.

Image montrant la configuration du connecteur AWS

Ensuite, nous ajouterons le connecteur S3 pour nous permettre de télécharger vers le bucket S3 que nous avons défini dans notre politique.

Image montrant l'ajout du connecteur S3

Attendez… n’oublions-nous pas quelque chose ? Quel était l’intérêt de toute cette génération de certificats si nous n’allons pas les utiliser ? Nous devons indiquer à notre application où trouver nos certificats ! Nous avons commencé par définir l’ID de certificat client sur « 1 ». Nous devons maintenant mettre à jour nos paramètres d’exécution App->Paramètres->Configurations et ajouter deux configurations d'exécution personnalisées:

  • ClientCertificatePasswords – le mot de passe que vous avez ajouté lorsque vous avez généré votre pfx.
  • ClientCertificates – l’emplacement de votre certificat sur votre machine locale.

Image montrant l'ajout de configurations d'exécution client

Si nous testons cela maintenant, nous pouvons voir que nous pouvons télécharger vers notre bucket S3 !

Mendix Cloud

Nous pouvons le faire localement, ce qui est formidable, mais nous devons maintenant pouvoir déployer sur le cloud, ce qui nécessitera un environnement sous licence. Pour ces instructions, nous utilisons «Mendix Cloud” mais les principes sont les mêmes pour “Mendix Pour le Cloud Privé”.

Notre première modification consiste en une mise à jour de configuration visant à définir la constante d'application AWSAuthentication.ClientCertificateID sur la valeur de l'identifiant du certificat, configurable dans l'environnement. Vous avez l'habitude d'utiliser une valeur unique en cas de plusieurs certificats ; pensez donc à une valeur pertinente. Par exemple, « AWS_Auth » :

Nous devons ensuite définir notre certificat client dans notre Mendix environnement. Ouvrez votre environnement et accédez à Réseau et ajoutez un certificat client. Téléchargez votre fichier client.pfx et indiquez le mot de passe que vous avez utilisé pour le créer.

Sélectionnez ensuite le certificat et cliquez sur Modifier à partir des trois points sous Actions :

Dans l'écran Modifier, créez un nouvel identifiant « Pin » avec la valeur que vous avez configurée pour la constante AWSAuthentication.ClientCertificateID, donc dans notre exemple « AWS_Auth ».

Redémarrez ensuite l'application pour la faire fonctionner.

 

Conclusion

Nous avons vu comment l'authentification AWS peut être utilisée pour tirer parti des solutions IAM de pointe d'AWS, pour nous permettre de nous connecter Mendix applications aux ressources AWS de la manière la plus sécurisée possible.

Pour simplifier ce processus, nous avons créé deux fichiers batch pour créer les certificats auto-signés – téléchargez pour Windows et Linux/Mac.

Pour en savoir plus sur le connecteur d'authentification, consultez la documentation : https://docs.mendix.com/appstore/connectors/aws/aws-authentication/

Pour en savoir plus sur Mendix et AWS :

https://www.mendix.com/aws/

Choisissez votre langue