N’accorder au portail que l’accès nécessaire

CybersécuritéBeginner
Pratiquer maintenant

Introduction

La fuite anonyme est corrigée dans ce nouvel environnement, mais le portail utilise encore les identifiants de l’administrateur du stockage. Il peut faire bien plus que lire son relevé attribué. Vous créerez une identité dédiée, n’autoriserez que les lectures nécessaires et basculerez l’application vers elle.

Utilisez Storage Admin pour les comptes et politiques, Portal App pour le fichier privé d’identifiants et Document Portal pour les requêtes applicatives réelles. Les données synthétiques s’exécutent sur VersityGW 1.10.0 local avec des utilisateurs internes comme principaux, pas sur un AWS IAM complet. L’environnement démarre indépendamment du laboratoire précédent.

Créer une identité dédiée au portail

Dans cette étape, remplacez la dépendance à un administrateur par une identité applicative distincte.

Sélectionnez l’onglet Document Portal dans l’interface du laboratoire pour commencer cette étape.

Passez à l’onglet Document Portal, cliquez sur Open assigned document et observez Identity: storage-admin. Le relevé fonctionne, mais les droits administrateur sont inutiles. Une identité nomme l’appelant ; sa clé secrète permet au client de signer des requêtes prouvant cette identité. L’authentification prouve qui appelle ; l’autorisation décide ce que cet appelant peut faire.

Passez à l’onglet Storage Admin. Chargez les identifiants administrateur de cette VM :

Passez à l’onglet Storage Admin avant d’exécuter la commande suivante.

source admin.env

VersityGW inclut un client d’administration. -a sélectionne le nom de clé d’accès, -s son secret et -er l’endpoint. Avant create-user, ces options identifient l’administrateur ; après, elles définissent le nouveau compte. Le rôle user n’a pas de contournement administratif. Créez le compte synthétique :

/opt/c14/versitygw admin -a storage-admin -s storage-admin-secret -er http://127.0.0.1:7070 create-user -a portal-reader -s portal-reader-secret -r user

Un succès ne produit pas d’erreur. Si le compte existe déjà après répétition, continuez avec lui. Ne lui accordez jamais admin et ne le rendez pas propriétaire du bucket : ces droits contournent la politique restreinte prévue.

Testez son authentification sur l’aide publique. Les affectations en préfixe ne sélectionnent les identifiants que pour cette commande :

AWS_ACCESS_KEY_ID=portal-reader AWS_SECRET_ACCESS_KEY=portal-reader-secret aws --endpoint-url http://127.0.0.1:7070 s3api get-object --bucket documents --key public/help.txt help.txt

Les métadonnées confirment une requête authentifiée. L’aide est autorisée pour tous ; cela n’autorise pas encore la lecture des relevés internes. InvalidAccessKeyId indique un utilisateur absent, et SignatureDoesNotMatch un secret incorrect ; aucun ne constitue un résultat d’autorisation.

Autoriser uniquement les lectures du préfixe requis

Dans cette étape, autorisez l’identité dédiée sans accorder d’écriture ni de lectures sans rapport.

Sélectionnez l’onglet Storage Admin dans l’interface du laboratoire pour commencer cette étape.

Le portail a besoin de portal/statement.txt ; sa zone autorisée est portal/. Un préfixe correspond au début d’une clé d’objet. portal/* n’inclut pas finance/budget.txt. La lecture utilise s3:GetObject ; l’envoi et la suppression utilisent s3:PutObject et s3:DeleteObject. Évitez s3:*, qui comprend toutes les opérations.

Lisez la politique effective dans Storage Admin :

Passez à l’onglet Storage Admin avant d’exécuter la commande suivante.

aws --endpoint-url http://127.0.0.1:7070 s3api get-bucket-policy --bucket documents --query Policy --output text

Seule l’autorisation d’aide publique existe. Ouvrez la copie locale :

nano policy.json

Remplacez-la par ce JSON complet. Conservez la déclaration publique et ajoutez une autorisation distincte pour le lecteur nommé. Les principaux internes de VersityGW sont des noms d’utilisateurs ; les formats AWS diffèrent.

{
  "Version": "2012-10-17",
  "Statement": [
    {"Effect": "Allow", "Principal": "*", "Action": "s3:GetObject", "Resource": "arn:aws:s3:::documents/public/*"},
    {"Effect": "Allow", "Principal": "portal-reader", "Action": "s3:GetObject", "Resource": "arn:aws:s3:::documents/portal/*"}
  ]
}

Dans nano, enregistrez avec Ctrl+O, Enter, puis quittez avec Ctrl+X. Appliquez le fichier avec file:// :

aws --endpoint-url http://127.0.0.1:7070 s3api put-bucket-policy --bucket documents --policy file://policy.json

Aucune sortie signifie un succès ; une erreur de syntaxe laisse l’ancienne politique effective. Corrigez et réappliquez si nécessaire. Testez la lecture autorisée :

AWS_ACCESS_KEY_ID=portal-reader AWS_SECRET_ACCESS_KEY=portal-reader-secret aws --endpoint-url http://127.0.0.1:7070 s3api get-object --bucket documents --key portal/statement.txt statement.txt

Testez maintenant une lecture sans rapport. Le AccessDenied attendu est intentionnel ; continuez après ce refus :

AWS_ACCESS_KEY_ID=portal-reader AWS_SECRET_ACCESS_KEY=portal-reader-secret aws --endpoint-url http://127.0.0.1:7070 s3api get-object --bucket documents --key finance/budget.txt budget.txt

Le contrôle teste aussi de vraies écritures et suppressions dans un stockage équivalent jetable, en préservant les documents actifs. Une identité invalide échouerait au contrôle positif de lecture ; une connexion cassée ne peut donc pas passer pour un moindre privilège.

Changer les identifiants de l’application

Dans cette étape, faites utiliser l’identité dédiée au véritable portail.

Sélectionnez l’onglet Portal App dans l’interface du laboratoire pour commencer cette étape.

Passez à l’onglet Portal App. Ce compte local distinct possède la configuration privée de l’application, sans les identifiants du shell Storage Admin. Lisez son fichier actuel :

Passez à l’onglet Portal App avant d’exécuter la commande suivante.

cat credentials.json

Les champs access_key et secret_key identifient actuellement storage-admin. Éditez le fichier :

nano credentials.json

Utilisez les identifiants synthétiques dédiés :

{
  "access_key": "portal-reader",
  "secret_key": "portal-reader-secret"
}

Enregistrez avec Ctrl+O, Enter, puis quittez avec Ctrl+X. Le portail lit ce fichier à chaque requête ; aucun redémarrage n’est nécessaire. Revenez à l’onglet Document Portal, cliquez sur Open assigned document ou rechargez la page. Attendez Identity: portal-reader et le relevé original. Si le portail ne peut pas lire, corrigez JSON ou identifiants, puis passez à l’onglet Storage Admin pour vérifier la politique.

Document Portal utilise l’identité dédiée portal-reader

Enfin, passez à l’onglet Storage Admin et testez une requête interne anonyme et l’aide publique. -sS affiche les erreurs sans progression ; -w ajoute le code de réponse :

Passez à l’onglet Storage Admin avant d’exécuter la commande suivante.

curl -sS -w '\nHTTP %{http_code}\n' http://127.0.0.1:7070/documents/portal/statement.txt

Attendez AccessDenied et HTTP 403.

curl -sS http://127.0.0.1:7070/documents/public/help.txt

Attendez le texte d’aide original. L’identité applicative et l’accès anonyme sont deux frontières distinctes ; protéger l’une ne protège pas automatiquement l’autre.

Résumé

Vous avez créé une identité applicative ordinaire, n’avez autorisé que les lectures du préfixe requis et avez retiré les identifiants administrateur du portail fonctionnel. Vous avez vérifié séparément authentification, autorisation, accès public et disponibilité de l’application.