Cette application auto-hébergée peut-elle prendre en charge votre processus d’approbation ? Un cadre d’évaluation pratique

Pourquoi une fonctionnalité d’approbation n’est pas la même chose qu’un processus d’approbation maîtrisé

De nombreuses applications peuvent marquer un élément comme approuvé, restreindre un changement de statut ou notifier un collègue pour relecture. Cela peut être utile, mais ne fournit pas automatiquement un processus maîtrisé pour une décision d’achat, une dépense, une demande d’accès, une modification de données client ou une décision de publication.

Un processus d’approbation maîtrisé nécessite davantage qu’une action à l’écran. Il exige une décision définie, des décideurs habilités, des règles précisant quand leur autorité s’applique, une trace de leur décision et des mesures de protection empêchant les personnes de modifier ou de contourner le processus après coup. La bonne question n’est pas : « Cette application propose-t-elle des approbations ? » Elle est : « Pouvons-nous configurer et exploiter cette application de façon à ce que les décisions requises soient prises, appliquées et étayées ? »

La publication NIST SP 800-53 considère les mesures de sécurité comme flexibles et personnalisables dans le cadre d’un processus de gestion des risques à l’échelle de l’organisation. Appliquez le même principe ici : traduisez vos propres exigences métier, réglementaires et de risque en tests observables. L’intitulé générique d’une fonctionnalité ne remplace pas ce travail.

• Considérez une fonctionnalité comme un point de départ, et non comme la preuve d’une mesure de contrôle.
• Distinguez les revues de convenance des décisions qui créent des engagements financiers, juridiques, de sécurité ou ayant une incidence sur les clients.
• Documentez les exigences obligatoires, celles qui sont souhaitables et celles qui doivent être gérées en dehors de l’application.

Commencez par la décision réelle

Partez de l’événement métier, et non de la configuration du logiciel. Décrivez un type d’approbation à la fois. Les « achats » constituent généralement une catégorie trop large : l’approbation d’un renouvellement récurrent de fournisseur de faible montant peut nécessiter des preuves, une habilitation et une évaluation du risque différentes de celles requises pour un nouvel engagement important auprès d’un fournisseur.

Pour chaque décision, identifiez le demandeur, l’enregistrement faisant l’objet de la décision, les preuves requises, les résultats possibles et l’action qui ne peut intervenir qu’après approbation. Identifiez également la conséquence d’une approbation erronée. Cela détermine le niveau de contrôle, de visibilité et de revue dont le flux a besoin.

• Qu’est-ce qui est approuvé : une demande, un document, une modification d’enregistrement, un paiement, une publication, une habilitation d’accès ou une action sur des données client ?
• Qui peut soumettre la demande, et quels champs ou pièces jointes doivent être renseignés avant sa soumission ?
• Qui peut l’approuver, la rejeter, la renvoyer pour modification ou l’annuler ?
• Quels seuils, catégories de risque, services, sites ou classifications de données modifient le circuit ?
• Quelle action devient autorisée après approbation, et qui l’exécute ?
• Pendant combien de temps le dossier de décision et les preuves justificatives doivent-ils être conservés ?

Cartographiez le flux minimal avant d’évaluer le logiciel

Rédigez le plus petit flux complet en langage clair, puis rendez chaque étape testable dans l’application. Une base utile comprend la demande, la revue, la décision, la notification, l’exécution et la conservation de l’enregistrement. Si un outil envisagé ne peut pas représenter une étape requise ou préserver les informations nécessaires, identifiez explicitement la mesure de contrôle compensatoire plutôt que de supposer que les utilisateurs s’en souviendront.

Distinguez la décision d’approbation de l’exécution ultérieure. Un approbateur peut, par exemple, autoriser un achat, tandis qu’une autre personne crée la commande. Cette distinction est importante pour la responsabilisation et la séparation des tâches.

• Demande : créer un élément identifié de manière unique et saisir les données et preuves requises.
• Revue : mettre l’élément à la disposition du ou des relecteurs appropriés.
• Décision : consigner l’approbation, le rejet ou le renvoi pour reprise, avec l’identité responsable.
• Notification : informer le demandeur et la prochaine personne responsable de ce qui s’est passé.
• Exécution : autoriser ou déclencher l’action de suivi approuvée uniquement lorsque les conditions sont remplies.
• Conservation : préserver le dossier de décision, les pièces jointes et l’historique pendant la période requise.

Évaluez les états et les transitions, y compris les modifications après approbation

Un flux est défini par ses états et les transitions autorisées entre eux. Testez au minimum les brouillons, les éléments soumis, les éléments approuvés et les éléments rejetés. Dans de nombreux processus, vous aurez aussi besoin des états renvoyé pour modification, annulé, expiré, remplacé ou exécuté.

Le test le plus révélateur concerne une modification significative après approbation. Si le montant, le fournisseur, le périmètre, la pièce jointe, le niveau d’accès ou la finalité des données client change, l’application verrouille-t-elle l’enregistrement, invalide-t-elle l’approbation, crée-t-elle une nouvelle révision, ou conserve-t-elle simplement une ancienne approbation à côté d’un contenu modifié ? Votre processus doit préciser quelles modifications exigent une nouvelle approbation, et l’application doit rendre ce résultat clair.

Testez également qui peut effectuer chaque transition d’état. Un demandeur peut pouvoir modifier un brouillon, mais ne devrait pas nécessairement pouvoir le marquer comme soumis, approuvé ou exécuté sans que les conditions requises soient réunies.

• Les utilisateurs peuvent-ils voir l’état actuel et l’historique complet des états antérieurs ?
• Les transitions sont-elles limitées par rôle, affectation ou conditions du flux ?
• Les éléments rejetés sont-ils clos, modifiables pour une nouvelle soumission ou renvoyés pour correction ?
• Une modification après approbation déclenche-t-elle une nouvelle approbation lorsque votre politique l’exige ?
• Un élément approuvé peut-il être annulé, et le motif d’annulation ainsi que l’identité de la personne sont-ils conservés ?
• Les utilisateurs peuvent-ils distinguer un enregistrement approuvé d’un enregistrement en attente, révisé ou remplacé ?

Testez les règles d’habilitation, pas seulement l’affectation des approbateurs

Un approbateur nommé est facile à comprendre, mais peut être fragile. Une évaluation robuste vérifie si l’application peut refléter le modèle d’habilitation réellement utilisé : relecteurs fondés sur les rôles, seuils, circuits conditionnels et plusieurs étapes d’approbation. Ne supposez pas qu’un responsable désigné est toujours la personne habilitée pour chaque décision.

Utilisez des cas représentatifs. Testez une demande courante, une demande juste en dessous puis juste au-dessus d’un seuil monétaire, une demande à risque élevé, une demande couvrant deux services et une demande nécessitant une revue juridique, de sécurité ou financière. Notez si l’orientation est automatique, si elle peut être modifiée et ce que les utilisateurs peuvent voir lorsqu’ils ne sont pas les relecteurs en charge.

• Habilitation nominative : une personne responsable donnée peut-elle approuver ?
• Habilitation fondée sur le rôle : le titulaire actuel d’un rôle métier approuvé peut-il approuver ?
• Habilitation par seuil : le circuit change-t-il au montant ou niveau de risque requis ?
• Habilitation à plusieurs étapes : les relecteurs requis peuvent-ils intervenir dans le bon ordre ?
• Habilitation parallèle : lorsque plusieurs revues sont requises, toutes doivent-elles approuver ou une seule suffit-elle ?
• Habilitation conditionnelle : les relecteurs requis peuvent-ils varier selon le service, le type de données, le pays, le projet ou la catégorie de demande ?

Vérifiez la séparation des tâches et les accès privilégiés

La séparation des tâches ne consiste pas simplement à attribuer des intitulés différents aux personnes. La mesure AC-5 du NIST exige une séparation définie et documentée des tâches, ainsi que des autorisations d’accès qui la soutiennent. Traduisez ce principe en tests directs : un demandeur peut-il approuver sa propre demande, modifier un enregistrement approuvé, choisir un approbateur non habilité ou contourner un relecteur obligatoire ?

Évaluez séparément les rôles ordinaires de l’application et les accès opérationnels. Dans un déploiement auto-hébergé, les personnes disposant d’un accès étendu au déploiement ou à l’hôte peuvent être en mesure de modifier le fonctionnement, les données ou la configuration de l’application en dehors du flux métier. Docker indique que son modèle d’autorisation standard fonctionne selon un principe de tout ou rien pour les utilisateurs autorisés à accéder au démon Docker : ces utilisateurs peuvent exécuter des commandes client Docker. Intégrez cet accès dans votre modèle de menace et dans la conception de votre gouvernance.

Les plugins d’autorisation Docker peuvent prendre des décisions d’autorisation ou de refus selon le contexte d’authentification et de commande, mais Docker documente également les limites de leur périmètre d’application. Si vous envisagez de vous appuyer sur de tels contrôles, testez leur périmètre par rapport aux actions d’administration importantes pour votre processus. Ne déduisez pas que les restrictions du flux au niveau de l’application limitent à elles seules les administrateurs de l’infrastructure.

• Utilisez des comptes de test distincts pour le demandeur, l’approbateur, l’exécutant, l’administrateur de l’application et l’administrateur de l’infrastructure.
• Tentez l’auto-approbation, l’approbation par un rôle non autorisé et l’approbation après réaffectation.
• Tentez de modifier les champs clés et les pièces jointes après approbation.
• Identifiez qui peut modifier les règles de flux, les rôles, les paramètres d’audit, les magasins de données, les conteneurs et les sauvegardes.
• Définissez qui examine les accès privilégiés et à quelle fréquence.
• Veillez à ce que le processus reconnaisse le risque résiduel lorsqu’une petite équipe technique détient nécessairement un accès opérationnel étendu.

Évaluez la délégation, les absences et les tâches en retard sans perdre la responsabilisation

Les flux d’approbation échouent souvent dans des circonstances ordinaires : un approbateur est en congé, a changé de rôle ou n’agit tout simplement pas. Un processus praticable nécessite un circuit délibéré pour la délégation, la réaffectation et l’escalade. L’objectif est d’assurer la continuité sans masquer qui détenait l’habilitation et qui a pris la décision finale.

Testez si l’application enregistre l’affectataire initial, la personne ou la règle qui a réaffecté la tâche, la décision du délégataire et la date et l’heure de chaque événement. Si la délégation est gérée en dehors de l’application, décidez comment cette instruction sera documentée et comment l’habilitation du nouvel approbateur sera vérifiée.

• Un approbateur peut-il déléguer uniquement à une personne disposant du rôle ou du niveau d’habilitation autorisé ?
• Le système préserve-t-il l’affectataire initial et l’historique de délégation ?
• Un propriétaire de processus peut-il réaffecter un élément en retard, et le motif est-il consigné ?
• Les rappels et les escalades sont-ils suffisamment configurables pour le délai de réponse requis ?
• Que se passe-t-il si le compte d’un approbateur est désactivé ou supprimé alors qu’une tâche est en attente ?
• Existe-t-il un circuit d’urgence documenté, avec une revue ultérieure, pour les décisions qui ne peuvent pas attendre ?

Évaluez les preuves d’approbation et les enregistrements d’audit

Le dossier de décision doit répondre aux questions fondamentales sans dépendre de la mémoire de quelqu’un : que s’est-il passé, quand et où cela s’est-il produit, quoi ou qui en était la cause, quel en a été le résultat et quelles identités y étaient associées ? Ces éléments s’alignent sur les composants des enregistrements d’audit de la mesure AU-3 du NIST.

Pour chaque décision, examinez la sortie réellement conservée plutôt que de vous fier à un tableau de bord. Déterminez si elle inclut la version de la demande, la décision, la date et l’heure, l’identité de l’approbateur, les commentaires, les preuves jointes, les affectations et toutes les modifications significatives. Testez ensuite si un utilisateur peut exporter ou récupérer les preuves dans une forme qui reste compréhensible en dehors de l’application.

Les preuves ne sont utiles que si elles restent fiables. La mesure AU-9 du NIST traite de la protection des informations d’audit et de la restriction de la gestion des fonctions de journalisation à un sous-ensemble approprié d’utilisateurs privilégiés. Demandez qui peut modifier, supprimer, désactiver ou remplacer les enregistrements d’approbation et les journaux, et comment ces actions elles-mêmes sont détectées ou examinées.

• Identifiant de la demande et version ou révision approuvée.
• Type d’événement, heure, source ou emplacement pertinent, résultat et identités associées.
• Commentaires de décision, motifs de rejet et pièces jointes liées lorsque cela est requis.
• Historique complet des affectations, délégations et changements d’état.
• Procédures de conservation, d’exportation et de récupération qui ont été testées.
• Contrôles d’accès sur les enregistrements d’approbation et la journalisation d’audit, y compris la gouvernance des utilisateurs privilégiés.