Politique d'accès par défaut

Introduction

Les politiques d'accès d' IBM Security Verify fournissent un cadre d'autorisation riche en contexte pour faciliter l'expérience de l'utilisateur tout en protégeant les applications critiques de l'entreprise contre les accès non autorisés.

Lorsqu'une nouvelle application est créée, la case Use default policy est cochée sous Access policies dans l'onglet Sign-on. Par défaut, la politique d'accès Allow access from all devices est sélectionnée et aucune évaluation n'est effectuée lors de l'accès à l'application.

Dans de nombreux cas, une politique d'accès prédéfinie ou personnalisée est nécessaire et doit être sélectionnée et attribuée manuellement.

Après sélection, la politique d'accès choisie sera évaluée une fois que les modifications apportées à l'application auront été sauvegardées.

Ce processus est suffisant pour un petit nombre d'applications et de démonstrations, mais il peut devenir fastidieux à appliquer à plus de quelques applications et peut conduire à des configurations manquées et donc à des accès non autorisés et à des risques d'audit lorsque l'affectation manuelle est nécessaire pour un grand nombre d'applications.

La mise à jour d'une politique d'accès personnalisée à l'aide de l'API Access Policy Vault permet à toutes les applications auxquelles Use default policy a été attribué d'évaluer cette politique d'accès au cours du processus d' Single Sign On fédérée.

❗️

Les stratégies d'accès prédéfinies ne peuvent pas être attribuées par défaut.

L'attribution de la politique d'accès par défaut nécessite une mise à jour ( PUT ) du JSON de la politique, ce qui n'est pas autorisé pour les politiques d'accès prédéfinies.

La solution consiste à créer une politique d'accès personnalisée avec les mêmes règles ou la règle par défaut que la version prédéfinie.
Le JSON des politiques d'accès prédéfinies 1 à 18 peut être récupéré à l'aide de l'API du coffre-fort des politiques d'accès et la charge utile copiée pour créer une nouvelle politique d'accès personnalisée avec le même contenu.

Voir Tableau 2. Politiques d'accès prédéfinies dans la rubrique Politiques d'accès pour les descriptions et les caractéristiques de la logique des politiques d'accès prédéfinies.

Prérequis

Les étapes de ce guide utiliseront une politique d'accès personnalisée pour exiger le 2FA pour tous les utilisateurs une fois par session, en recréant la logique de la politique d'accès prédéfinie ID 18 Require 2FA each session in all devices et en la définissant comme politique par défaut.

L'appel aux API du coffre-fort des politiques d'accès nécessitera un jeton d'accès avec les droits Manage access policies.

Créer un client API

Vous pouvez créer ou réutiliser un client API existant.

Reportez-vous à la section Créer un client API et suivez les étapes de l' option 1 - Client API autonome.

Lors de la sélection des droits, seul le site Manage access policies est requis pour ce scénario.

Obtenir un jeton d'accès

En utilisant les adresses client_id et client_secret des détails de connexion obtenus lors de la création d'un client API, vous pouvez maintenant Acquire an Access Token en suivant les étapes de la section Client Credentials.

Par exemple

curl --location 'https://<tenant.verify.ibm.com>/v1.0/endpoint/default/token' \
--header 'Accept: application/json' \
--header 'Content-Type: application/x-www-form-urlencoded' \
--data-urlencode 'grant_type=client_credentials' \
--data-urlencode 'client_id=yyyyyyyy-yyyy-yyyy-yyyy-yyyyyyyyyyyy' \
--data-urlencode 'client_secret=zzzzzzzzzz'

qui répondra de manière similaire à

{
    "access_token": "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx",
    "grant_id": "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx",
    "token_type": "Bearer",
    "expires_in": 7200
}

Veillez à enregistrer la valeur de l'adresse access_token renvoyée, car elle sera nécessaire pour les API du référentiel de politiques d'accès.

Sélectionnez une politique d'accès qui deviendra la politique par défaut

Si vous disposez déjà d'une politique d'accès personnalisée, vous pouvez passer directement à la mise à jour de la politique d'accès personnalisée pour qu'elle devienne la politique par défaut. Vous devez connaître l'ID de la politique d'accès pour pouvoir la mettre à jour à l'aide des API.

📘

Note

Peu importe que votre politique d'accès personnalisée ait été créée à l'aide des API de politique d'accès ou dans l'éditeur de politique d'accès de l'interface utilisateur d'administration de votre instance Verify.

❗️

Vérifiez la politique d'accès attribuée à Portal Access pour l'accès à la console d'administration et à la page d'accueil.

La configuration par défaut de la politique d'accès ne s'applique actuellement qu'aux applications.

Bien qu'une politique d'accès par défaut n'est pas soit actuellement appliquée pour Accès au portail, Accès à la console d'administration ou Accès à la page d'accueil, il est recommandé d'attribuer manuellement des politiques d'accès individuelles à ces éléments afin d'éviter toute confusion quant à la politique d'accès à appliquer.

Au minimum, une politique d'accès exigeant Require MFA once per session in all devices for all users ou Adaptive Access doit être appliquée à l'accès à la console d'administration.

Les étapes suivantes permettront de récupérer la politique d'accès prédéfinie ID 18 Require 2FA each session in all devices et de créer une nouvelle politique d'accès personnalisée avec la même logique, en utilisant les API.

Récupérer la politique d'accès ID 18 Exiger 2FA à chaque session sur tous les appareils

En utilisant le site access_token à partir de Obtenir un jeton d'accès, récupérer ( GET ) l'ID de politique d'accès 18

curl --location 'https://<tenant.verify.ibm.com>/policyvault/v5.0/policyvault/accesspolicy/18' \
--header 'Authorization: Bearer xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx'

La réponse sera

{
    "id": 18,
    "name": "Require 2FA each session in all devices",
    "description": "Prompt users to complete a second factor authentication one-time, on the first access attempt in an authenticated session with IBM Security Verify. Second factor authentication is not required on subsequent logins to other applications when the users access the applications within the same authenticated session.",
    "containsFirstFactor": false,
    "rules": [
        {
            "id": "100",
            "name": "mfa_once_per_session",
            "description": "",
            "alwaysRun": false,
            "firstFactor": false,
            "conditions": [],
            "result": {
                "action": "ACTION_MFA_PER_SESSION",
                "serverSideActions": [],
                "authnMethods": [
                    "urn:ibm:security:authentication:asf:macotp"
                ]
            }
        }
    ],
    "meta": {
        "state": "ACTIVE",
        "schema": "urn:access:policy:5.0:schema",
        "revision": 0,
        "label": "system migration",
        "predefined": true,
        "created": 1524201037854,
        "createdBy": "admin",
        "lastActive": 1524201037854,
        "modified": 1524201037854,
        "modifiedBy": "admin",
        "scope": [
            "administrators"
        ],
        "enforcementType": "fedSSO",
        "tenantDefaultPolicy": false
    },
    "validations": {
        "subscriptionsNeeded": [
            "civ.subscription"
        ]
    }
}

Conservez une copie de la réponse JSON car elle sera utilisée pour créer la politique d'accès personnalisée avec quelques mises à jour mineures.

Créer une politique d'accès personnalisée Exiger l'AMF une fois par session dans tous les appareils pour tous les utilisateurs

Nous utiliserons les API de la chambre forte des politiques d'accès, mais vous pouvez également créer une politique d'accès personnalisée dans l'interface utilisateur d'administration de votre instance Verify.

Bien qu'il soit possible de créer une nouvelle politique d'accès et de l'attribuer par défaut en une seule opération, pour les besoins de cet article, nous allons d'abord créer la politique et la mettre à jour en tant que politique par défaut afin que les mêmes étapes puissent être appliquées lorsqu'une politique d'accès personnalisée existe déjà.

En utilisant le même site access_token que ci-dessus, créez ( POST ) une nouvelle politique d'accès avec une version légèrement réduite et modifiée de la réponse JSON provenant de l'extraction de la politique d'accès ID 18 Require 2FA each session in all devices.
La charge utile JSON est un sous-ensemble de l'identifiant 18 de la politique d'accès récupérée, fournissant les paramètres minimums requis pour la syntaxe V5.

curl --location 'https://<tenant.verify.ibm.com>/policyvault/v5.0/policyvault/accesspolicy' \
--header 'Accept: application/json; charset=utf-8' \
--header 'Content-Type: application/json' \
--header 'Authorization: Bearer xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx' \
--data '{
    "name": "Require MFA once per session in all devices for all users",
    "description": "Clone of Access policy ID 18",
    "rules": [
        {
            "id": "100",
            "name": "Default rule",
            "description": "MFA once per session with any factor",
            "conditions": [],
            "result": {
                "action": "ACTION_MFA_PER_SESSION",
                "authnMethods": [
                    "anyFactor"
                ]
            }
        }
    ],
    "meta": {
        "state": "ACTIVE",
        "schema": "urn:access:policy:5.0:schema",
        "label": "Initial version",
        "scope": [
            "administrators"
        ],
        "enforcementType": "fedSSO"
    }
}'

Un statut HTTP de 201 doit être renvoyé et le JSON de la politique d'accès créée doit être renvoyé en écho avec une notation similaire à celle de la récupération de l'identifiant de politique 18.

{
    "id": 1108755,
    "name": "Require MFA once per session in all devices for all users",
    "description": "Clone of Access policy ID 18",
    "containsFirstFactor": false,
    "rules": [
        {
            "id": "100",
            "name": "Default rule",
            "description": "MFA once per session with any factor",
            "alwaysRun": false,
            "firstFactor": false,
            "conditions": [],
            "result": {
                "action": "ACTION_MFA_PER_SESSION",
                "serverSideActions": [],
                "authnMethods": [
                    "anyFactor"
                ]
            }
        }
    ],
    "meta": {
        "state": "ACTIVE",
        "schema": "urn:access:policy:5.0:schema",
        "revision": 0,
        "label": "Initial version",
        "predefined": false,
        "created": 1700632889971,
        "createdBy": "4f2becf9-f203-4a31-b77e-2cebc9b42385",
        "lastActive": 1700632889971,
        "modified": 1700632889971,
        "modifiedBy": "4f2becf9-f203-4a31-b77e-2cebc9b42385",
        "scope": [
            "administrators"
        ],
        "enforcementType": "fedSSO",
        "tenantDefaultPolicy": false
    },
    "validations": {
        "subscriptionsNeeded": [
            "civ.subscription"
        ]
    }
}

La réponse JSON a été complétée par les éléments suivants

• une adresse id a été générée pour la politique. Ceci est nécessaire lors de la mise à jour ( PUT ) pour l'attribuer par défaut
• meta a été enrichi de données d'audit supplémentaires
• validations ont été ajoutés pour indiquer les conditions d'abonnement qui doivent être maintenues pour que cette politique d'accès soit évaluée
• des champs d'aide tels que containsFirstFactor, alwaysRun, firstFactor, serverSideActions ont été ajoutés

Mettre à jour la politique d'accès personnalisée pour qu'elle devienne la politique par défaut

Dans le JSON de la politique d'accès renvoyée dans Créer une politique d'accès personnalisée Require MFA once per session in all devices for all users, le champ meta contenait un paramètre "tenantDefaultPolicy": false.

Nous mettrons à jour ( PUT ) cette valeur en l'incluant dans l' ensemble du JSON de la politique d'accès.

Par souci de commodité, nous extrairons le contenu intégral de la politique d'accès à l'aide de notre identifiant 1108755.
Si vous avez enregistré la réponse de Créer une politique d'accès personnalisée Require MFA once per session in all devices for all users, vous pouvez ignorer la récupération de la politique d'accès.

curl --location 'https://<tenant.verify.ibm.com>/policyvault/v5.0/policyvault/accesspolicy/1108755' \
--header 'Authorization: Bearer xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx'

qui renverra un résultat similaire à

{
    "id": 1108755,
    "name": "Require MFA once per session in all devices for all users",
    "description": "Clone of Access policy ID 18",
    "containsFirstFactor": false,
    "rules": [
        {
            "id": "100",
            "name": "Default rule",
            "description": "MFA once per session with any factor",
            "alwaysRun": false,
            "firstFactor": false,
            "conditions": [],
            "result": {
                "action": "ACTION_MFA_PER_SESSION",
                "serverSideActions": [],
                "authnMethods": [
                    "anyFactor"
                ]
            }
        }
    ],
    "meta": {
        "state": "ACTIVE",
        "schema": "urn:access:policy:5.0:schema",
        "revision": 0,
        "label": "Initial version",
        "predefined": false,
        "created": 1700632889971,
        "createdBy": "4f2becf9-f203-4a31-b77e-2cebc9b42385",
        "lastActive": 1700632889971,
        "modified": 1700632889971,
        "modifiedBy": "4f2becf9-f203-4a31-b77e-2cebc9b42385",
        "scope": [
            "administrators"
        ],
        "enforcementType": "fedSSO",
        "tenantDefaultPolicy": true
    },
    "validations": {
        "subscriptionsNeeded": [
            "civ.subscription"
        ]
    }
}

Ensuite, nous mettrons à jour la politique en utilisant l'ensemble des données utiles renvoyées par GET. La seule modification apportée pour les cosmétiques est la mise à jour de "label": "Tenant default", mais elle est facultative et ne sert qu'à cette démonstration.

curl --location --request PUT 'https://<tenant.verify.ibm.com>/policyvault/v5.0/policyvault/accesspolicy/1108755' \
--header 'Accept: application/json; charset=utf-8' \
--header 'Content-Type: application/json' \
--header 'Authorization: Bearer xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx' \
--data '{
    "id": 1108755,
    "name": "Require MFA once per session in all devices for all users",
    "description": "Clone of Access policy ID 18",
    "containsFirstFactor": false,
    "rules": [
        {
            "id": "100",
            "name": "Default rule",
            "description": "MFA once per session with any factor",
            "alwaysRun": false,
            "firstFactor": false,
            "conditions": [],
            "result": {
                "action": "ACTION_MFA_PER_SESSION",
                "serverSideActions": [],
                "authnMethods": [
                    "anyFactor"
                ]
            }
        }
    ],
    "meta": {
        "state": "ACTIVE",
        "schema": "urn:access:policy:5.0:schema",
        "revision": 0,
        "label": "Tenant default",
        "predefined": false,
        "created": 1700632889971,
        "createdBy": "4f2becf9-f203-4a31-b77e-2cebc9b42385",
        "lastActive": 1700632889971,
        "modified": 1700632889971,
        "modifiedBy": "4f2becf9-f203-4a31-b77e-2cebc9b42385",
        "scope": [
            "administrators"
        ],
        "enforcementType": "fedSSO",
        "tenantDefaultPolicy": true
    },
    "validations": {
        "subscriptionsNeeded": [
            "civ.subscription"
        ]
    }
}'

Un statut HTTP de 201 devrait être renvoyé, le corps de la réponse reprenant la charge utile d'entrée avec les paramètres "tenantDefaultPolicy": true et meta mis à jour, y compris "modified": 1700638825445,, tandis que la valeur d'origine de created est restée inchangée.

{
    "id": 1108755,
    "name": "Require MFA once per session in all devices for all users",
    "description": "Clone of Access policy ID 18",
    "containsFirstFactor": false,
    "rules": [
        {
            "id": "100",
            "name": "Default rule",
            "description": "MFA once per session with any factor",
            "alwaysRun": false,
            "firstFactor": false,
            "conditions": [],
            "result": {
                "action": "ACTION_MFA_PER_SESSION",
                "serverSideActions": [],
                "authnMethods": [
                    "anyFactor"
                ]
            }
        }
    ],
    "meta": {
        "state": "ACTIVE",
        "schema": "urn:access:policy:5.0:schema",
        "revision": 0,
        "label": "Tenant default",
        "predefined": false,
        "created": 1700632889971,
        "createdBy": "4f2becf9-f203-4a31-b77e-2cebc9b42385",
        "lastActive": 0,
        "modified": 1700638825445,
        "modifiedBy": "4f2becf9-f203-4a31-b77e-2cebc9b42385",
        "scope": [
            "administrators"
        ],
        "enforcementType": "fedSSO",
        "tenantDefaultPolicy": true
    },
    "validations": {
        "subscriptionsNeeded": [
            "civ.subscription"
        ]
    }
}

❗️

N'utilisez pas l'API sur les révisions de la politique d'accès https://<tenant.verify.ibm.com>/policyvault/v5.0/policyvault/accesspolicy/<access_policy_id>/revision/<revision> pour mettre à jour une révision et un paramètre "tenantDefaultPolicy": true et "state": "ACTIVE".

L'adresse tenantDefaultPolicy ne peut être définie que sur la révision principale /policyvault/v5.0/policyvault/accesspolicy/<access_policy_id>.
Si des modifications supplémentaires sont apportées à la politique d'accès (en plus de la mise à jour de label ci-dessus), une nouvelle révision peut être créée et la valeur de revision de la politique principale incrémentée.

Tester la politique d'accès par défaut

Le paramètre "tenantDefaultPolicy": true prendra effet immédiatement et remplacera toute politique d'accès par défaut attribuée précédemment.

Vous pouvez valider la mise à jour en créant une nouvelle application ou en modifiant une application où la case Use default policy est cochée, ce qui permet d'afficher le nom de la politique d'accès de la politique mise à jour.

Lors de l'accès à cette application, la politique d'accès attribuée sera évaluée.

Pour rétablir l'utilisation de la valeur par défaut dans les applications, au lieu d'attribuer manuellement une politique d'accès, il suffit de modifier l'application, de cocher Use default policy et d'enregistrer les modifications.

❗️

La politique d'accès par défaut attribuée n'est pas actuellement appliquée pour l'accès au portail de la console d'administration ou l'accès à la page d'accueil.

Dans le portail d'accès, lorsque Use default policy est coché, l'étiquette Allow access from all devices s'affiche, indiquant qu'une mise à jour de la politique par défaut de l' application n'est pas appliquée ici.
Sélectionnez manuellement la politique d'accès et enregistrez les modifications pour remplacer les politiques d'accès du portail.

Supprimer ou modifier la politique d'accès par défaut

Si vous devez modifier le comportement de la politique d'accès par défaut, vous pouvez

• Mettre à jour la politique d'accès actuellement attribuée à l'aide des API ou de l'éditeur de politique d'accès ; si vous ne fournissez pas le site tenantDefaultPolicy, la valeur actuellement attribuée restera inchangée
• Attribuez une nouvelle politique d'accès en suivant les étapes de la section Mettre à jour la politique d'accès personnalisée pour qu'elle devienne la politique par défaut avec un ID de politique d'accès différent
• Mettre à jour la politique d'accès actuellement attribuée à l'aide des API pour définir "tenantDefaultPolicy": false qui reviendra à Allow access from all devices

Conclusion

La mise à jour de la politique d'accès par défaut peut être aussi simple qu'un simple appel à l'API pour créer ou mettre à jour tenantDefaultPolicy dans une politique d'accès personnalisée.

L'application est immédiate et élimine le risque d'incohérences lorsqu'une politique d'accès incorrecte est sélectionnée ou que le propriétaire de l'application oublie de mettre à jour la politique d'accès souhaitée, ce qui réduit les accès non autorisés et les risques d'audit.