Limiter l’accès réseau et SQL à une base RDS

Introduction

La base de commandes accepte les connexions de tout le VPC de l’application, qui utilise une identité administratrice. Vous limiterez l’accès réseau et créerez un utilisateur dédié pouvant lire et ajouter des commandes, sans les supprimer.

Terminez d’abord les laboratoires de connexion et de SQL. Cet environnement indépendant fournit un PostgreSQL primaire, trois commandes d’exemple et une application. Vous testerez les deux limites d’accès et supprimerez la base d’exercice à la fin.

Lien avec les certifications

Ce laboratoire propose une pratique introductive des sujets d’examen suivants.

Cloud Practitioner (CLF-C02) · Tâche 3.5 : Comprendre les groupes de sécurité comme limite d’accès réseau.
Solutions Architect – Associate (SAA-C03) · Tâche 1.3 : Appliquer le moindre privilège et limiter l’accès aux données applicatives.

Limiter la source réseau de PostgreSQL

Dans cette étape, vous remplacerez l’accès étendu du VPC par un accès depuis le groupe de sécurité préparé pour l’application.

Un groupe de sécurité contrôle les connexions réseau pouvant atteindre la base. Il ne décide pas des opérations SQL qu’un utilisateur authentifié peut effectuer. Vous traiterez cette autre limite à l’étape suivante.

Chargez les paramètres préparés :

cd /home/labex/project
source database.env

Inspectez le groupe de la base et ses deux documents de règles :

aws ec2 \
  describe-security-groups \
  --group-ids "$DB_SECURITY_GROUP_ID" \
  --query 'SecurityGroups[].{Group:GroupName,Ingress:IpPermissions}'

cat broad-rule.json
cat application-rule.json

La règle existante autorise le port TCP 5432 depuis 10.70.0.0/16, permettant à d’autres clients du VPC de tenter une connexion. La nouvelle utilise UserIdGroupPairs pour référencer le groupe applicatif. Une référence de groupe autorise le trafic des ressources associées au groupe source ; elle ne copie pas ses règles.

Supprimez la règle étendue et ajoutez celle de l’application :

aws ec2 \
  revoke-security-group-ingress \
  --group-id "$DB_SECURITY_GROUP_ID" \
  --ip-permissions file://broad-rule.json

aws ec2 \
  authorize-security-group-ingress \
  --group-id "$DB_SECURITY_GROUP_ID" \
  --ip-permissions file://application-rule.json

Testez une nouvelle connexion depuis la source applicative :

psql \
  "service=orders-db" \
  --command 'SELECT count(*) FROM orders;'

Vous devez obtenir 3. Testez ensuite le client fourni qui n’appartient pas au groupe applicatif :

psql \
  "service=orders-db-external" \
  --command 'SELECT count(*) FROM orders;'

La connexion du client externe doit échouer. Son mot de passe est valide, mais sa source réseau n’est pas autorisée. Les noms de connexion préparés sélectionnent ces deux sources. Les règles de l’exercice ne changent pas votre connexion de gestion à Terminal ou AWS View.

AWS View doit afficher le groupe applicatif comme source PostgreSQL de la base, au lieu du CIDR étendu du VPC.

Créer un utilisateur de base pour l’application

Dans cette étape, vous autoriserez la lecture et l’insertion de commandes sans privilèges administratifs ni de suppression.

Un rôle PostgreSQL peut détenir des privilèges. Un rôle avec LOGIN peut s’authentifier comme utilisateur de base. Les rôles de base sont distincts des identités AWS IAM : IAM gère la ressource RDS, tandis que ces autorisations SQL gouvernent les opérations dans PostgreSQL.

Accès réseau, connexion et droits SQL sont des limites distinctes

Schéma conceptuel: Accès réseau, connexion et droits SQL sont des limites distinctes.

Créez orders_app avec le fichier privé de mot de passe fourni. --set définit une variable psql ; :'app_password' cite sa valeur de façon sûre comme chaîne SQL :

psql \
  "service=orders-db" \
  --set=ON_ERROR_STOP=1 \
  --set=app_password="$(cat app-password.txt)" <<'SQL'
CREATE ROLE orders_app LOGIN PASSWORD :'app_password';
GRANT CONNECT ON DATABASE orders TO orders_app;
GRANT USAGE ON SCHEMA public TO orders_app;
GRANT SELECT, INSERT ON orders TO orders_app;
SQL

CONNECT autorise les connexions à la base. USAGE permet l’accès par le schéma, un espace de noms contenant les tables. SELECT et INSERT n’autorisent que les opérations nécessaires. Vous n’avez accordé ni DELETE, ni UPDATE, ni CREATEDB, ni CREATEROLE, ni privilèges de superutilisateur.

Testez le rôle en passant la valeur privée du mot de passe à psql :

PGPASSWORD="$(cat app-password.txt)" psql \
  "service=orders-db-app" \
  --command 'SELECT current_user, count(*) FROM orders;'

Vous devez obtenir l’utilisateur orders_app et 3 commandes.

Essayez de supprimer un ID de commande inexistant. La requête ne peut retirer aucune commande réelle, même si les privilèges étaient trop étendus par erreur :

PGPASSWORD="$(cat app-password.txt)" psql \
  "service=orders-db-app" \
  --command 'DELETE FROM orders WHERE order_id = -1;'

Vous devez obtenir permission denied for table orders. Cet échec survient après la réussite de la connexion réseau et de l’authentification. Il démontre donc une autre limite que l’échec de connexion du client externe.

Utiliser l’identité limitée dans l’application

Dans cette étape, vous configurerez le rôle dans l’application et prouverez que les opérations courantes fonctionnent toujours.

Changez l’identité de base et la référence du fichier de mot de passe, en conservant les deux champs d’endpoint :

jq \
  '.user = "orders_app" | .password_file = "app-password.txt"' \
  app-config.json > app-config.new
mv app-config.new app-config.json

Lisez la liste actuelle des commandes :

curl \
  --silent \
  --show-error \
  --fail \
  http://127.0.0.1:8080/application/orders | jq

Vous devez obtenir les trois commandes initiales et user: orders_app.

Ajoutez une commande par l’endpoint HTTP de l’application. Content-Type indique que le corps de la requête est en JSON :

curl \
  --silent \
  --show-error \
  --fail \
  --request POST \
  --header 'Content-Type: application/json' \
  --data '{"order_id":104,"customer":"Kai","total":"5.00"}' \
  http://127.0.0.1:8080/application/orders

Vous devez obtenir saved: true et l’ID 104. Relisez la liste :

curl \
  --silent \
  --show-error \
  --fail \
  http://127.0.0.1:8080/application/orders | jq

Vous devez obtenir quatre commandes, dont celle de Kai à 5.00. AWS View doit afficher les mêmes données stockées et l’identité limitée de l’application. Les droits réduits préservent son fonctionnement nécessaire. L’application lit les commandes initiales et sa nouvelle commande avec l’utilisateur limité orders_app.

Supprimer la base d’exercice

Dans cette étape, vous supprimerez la base du laboratoire, ses commandes d’exemple et ses utilisateurs SQL.

aws rds \
  delete-db-instance \
  --db-instance-identifier orders-db \
  --skip-final-snapshot \
  --query 'DBInstance.DBInstanceIdentifier'

aws rds \
  wait db-instance-deleted \
  --db-instance-identifier orders-db

aws rds \
  describe-db-instances \
  --query 'DBInstances[].DBInstanceIdentifier'

Vous devez obtenir []. Le moteur et ses rôles ont disparu ; l’ancien endpoint de l’application ne se connecte plus. Conservez le réseau fourni et son groupe de base restreint. Il n’y a aucune raison de rouvrir l’accès pour le nettoyage.

Résumé

Vous avez limité les connexions PostgreSQL à la source applicative et donné à l’application son propre rôle limité. Le client externe ne pouvait pas se connecter et le rôle ne pouvait pas supprimer de commandes, tandis que lectures et insertions fonctionnaient toujours. Vous avez ensuite supprimé la base d’exercice en conservant les règles réseau restreintes.

Le prochain laboratoire récupère des commandes perdues en restaurant un instantané manuel RDS dans une nouvelle base.

Limiter l’accès à la base de données à l’application