Skip to main content

Politiques de sécurité

Niveau des applications et sécurité des fonctionnalités

Il convient de prendre en compte suffisamment tôt la question de la sécurité de l’application ; par exemple au cours de la phase de préparation de votre projet, avant même de commencer à générer et configurer l’application. Pour protéger votre application des hackers et éviter les accès et utilisations non autorisés, vous devez gérer deux types de sécurités : la sécurité de l’application et la sécurité des fonctionnalités.

Sécurité de l’application

La sécurité de l’application se concentre sur la protection de l’application contre les utilisateurs externes et non autorisés. Par exemple, avec la sécurité de l’application, vous :

  • réduisez le risque que des utilisateurs non autorisés accèdent à votre application ou en dérobent des données ;
  • identifiez les utilisateurs autorisés qui ont besoin d’un accès à l’application ;
  • créez des politiques de mot de passe et d’authentification.

La sécurité de l’application tient compte de tous les moyens par lesquels vous pouvez protéger l’application, comme le recours à des outils de sécurité tiers ou l’activation de l’authentification multifactorielle. Son objectif est d’empêcher les utilisateurs non autorisés d’accéder à votre application ou d’en consulter les données.

Sécurité des fonctionnalités

La sécurité des fonctionnalités se concentre sur l’application, en déterminant les types de dossier, les fonctionnalités et les données auxquels les utilisateurs autorisés peuvent accéder ou non. Par exemple, avec la sécurité des fonctionnalités, vous :

  • configurez des rôles de sécurité pour les personas identifiés dans chaque type de dossier de sorte que les utilisateurs autorisés puissent accéder aux fonctionnalités de l’application dont ils ont besoin ;
  • évitez que les utilisateurs voient les fonctionnalités ou accèdent aux données qui ne les concernent pas ;
  • concevez le contrôle d’accès basé sur les rôles (RBAC, role-based access control), le contrôle d’accès basé sur les attributs (ABAC, attribute-based access control) et le contrôle d’accès basé sur les clients (CBAC, client-based access control).
Note: Pour passer en revue la configuration des utilisateurs et des personas, consultez Inviting users to an application

Par exemple, dans une application de traitement des salaires, le responsable métier souhaite que chaque manager puisse consulter l’historique de ses subordonnés directs, mais pas celui de ses homologues ou d’autres membres du personnel. De plus, aucun manager ne doit pouvoir modifier le salaire des employés. Toutefois, le responsable du traitement des salaires et le directeur financier peuvent voir l’historique de paie de tous les employés et mettre à jour les salaires. Lors de la documentation de la story du responsable, déterminez les fonctionnalités de paie auxquelles le responsable peut et ne peut pas accéder.

Note: Nous recommandons aux membres des équipes du SSA et du LSA d’identifier les besoins en sécurité au cours de la phase Découverte (Sales) d’un projet et de les documenter au cours de la phase Conception. Pour en savoir plus sur les phases de la méthodologie Pega Express, consultez la rubrique intitulée Pega Express Delivery

Vérifiez vos connaissances avec l’interaction suivante :

Configurer la sécurité de l’application sur Pega Platform

Pour limiter l’accès non autorisé à vos applications, vous pouvez notamment configurer les paramètres de l’onglet Security Policies de la page d’accueil Authentication dans App Studio. Dans Dev Studio, ouvrez le menu Configure et sélectionnez Org & Security > Authentication > Security Policies pour afficher et mettre à jour les politiques de sécurité pour l’ensemble du serveur Pega Platform™.

Caution: Les paramètres d’un service d’authentification peuvent remplacer ceux de la page d’accueil Authentication.

Après avoir mis à jour un paramètre, cliquez sur Submit au bas de la page pour enregistrer une mise à jour. Les modifications apportées aux politiques de sécurité deviennent actives dès la soumission du formulaire.

Note: L’application de politiques de sécurité appropriées n’est qu’un aspect de la sécurisation d’une application. Pour obtenir la liste complète des bonnes pratiques en termes de sécurité, consultez la Security Checklist pour le déploiement de Pega Platform. 

L’onglet Security Policies est divisé en deux sections : Frequently required policies et Other policies. Les politiques Password, CAPTCHA, Lockout et Audit font partie des politiques fréquemment requises, tandis que Multi-factor authentication et Operator disablement sont classées dans les autres politiques.

Nom de la police Description Options de configuration de la politique
Mot de passe Régit les niveaux de sécurité des mots de passe d’utilisateur. Utilisez la section Password policies pour personnaliser les exigences relatives à la longueur, à la complexité et à la prévisibilité des mots de passe.
CAPTCHA Détermine si une personne a bien entré le mot de passe.

 

Utilisez la section CAPTCHA policies pour configurer un CAPTCHA afin de vérifier les tentatives de connexion. Lorsque cette option est activée, vous pouvez :
  • Choisir entre l’implémentation par défaut ou une implémentation personnalisée.
  • Activer l’utilisation d’un CAPTCHA lors de la connexion initiale.
  • Définir la probabilité que les utilisateurs reçoivent un CAPTCHA après un échec de connexion.
Lockout Définit le comportement du système lorsque des utilisateurs saisissent un mot de passe incorrect.

 

Utilisez la section Lockout policies pour personnaliser la durée pendant laquelle les utilisateurs devront attendre après l’échec d’une tentative de connexion. Les options indiquées dépendent de l’activation ou de la désactivation de la politique de verrouillage. Lorsqu’une pénalité de verrouillage est activée, vous pouvez :
  • Définir une valeur de seuil pour les tentatives de connexion échouées.
  • Définir la période initiale de pénalité de verrouillage, en secondes. Les échecs de connexion répétés augmentent automatiquement la période de pénalité.
  • Tenir un journal des échecs de connexion pendant un nombre de minutes déterminé.

Lorsqu’une politique de verrouillage est désactivée, vous pouvez :

  • Définir le nombre de tentatives de connexion rejetées avant qu’un compte soit verrouillé.
  • Définir la durée en minutes pendant laquelle le compte de l’utilisateur est verrouillé.
Audit Détermine la quantité de détails inscrits dans le journal du système pour un problème de sécurité. Utilisez la section Audit policies pour personnaliser le niveau de détail capturé pour les tentatives de connexion.
Multi-factor authentication Définit plusieurs facteurs, ou éléments de preuve, que les utilisateurs doivent fournir pour confirmer leur identité. Utilisez la section Multi-factor authentication policies (using one-time password) pour configurer les paramètres d’un mot de passe à usage unique envoyé aux utilisateurs par e-mail ou SMS. Pour achever le processus de connexion, les utilisateurs doivent saisir le mot de passe à usage unique dans le délai imparti. 
Operator disablement Définit la durée d’inactivité avant que l’accès d’un utilisateur soit désactivé. Utilisez la section Operator disablement policy pour désactiver automatiquement l’accès pour les utilisateurs inactifs pendant le nombre de jours spécifié. Pour empêcher le système de désactiver l’accès des utilisateurs qui en ont besoin, ajoutez l’ID opérateur de l’utilisateur à la liste Exclusion list of operator IDs.
Note: Pour une explication détaillée des paramètres de chaque type de politique, y compris les valeurs minimales et maximales autorisées, consultez Security policies settings.

Politiques d’authentification à facteurs multiples

Les mots de passe sont un moyen d’authentifier les utilisateurs. Pour accroître la sécurité, activez l’authentification à facteurs multiples (multi-factor authentication) pour authentifier les utilisateurs. Avec l’authentification à facteurs multiples, les utilisateurs n’obtiennent l’accès qu’après avoir fourni plusieurs facteurs, ou éléments de preuve, pour confirmer leur identité.

Note: Avec l’authentification à deux facteurs, qui est un sous-ensemble de l’authentification multifactorielle, les utilisateurs fournissent deux éléments de preuve à la connexion.

Dans l’image suivante, cliquez sur les icônes + pour en savoir plus sur les différents facteurs d’authentification.

Vérifiez vos connaissances avec l’interaction suivante :


This Topic is available in the following Module:

If you are having problems with your training, please review the Pega Academy Support FAQs.

Did you find this content helpful?

100% found this content useful

Want to help us improve this content?

We'd prefer it if you saw us at our best.

Pega Academy has detected you are using a browser which may prevent you from experiencing the site as intended. To improve your experience, please update your browser.

Close Deprecation Notice