Six conditions doivent être réunies avant qu’une action s’exécute. Pas l’une ou l’autre – toutes.
Ici, l’accès n’est pas un nom de rôle. Ce qui décide si une personne peut faire quelque chose, c’est la licence de l’organisation et le groupe d’autorisations lié à la fonction qu’elle occupe, déterminés au moment où elle se connecte. Cette page suit une action ordinaire à travers toutes les conditions qui la rendent possible.
L’action Ouvrir l’écran de paie et modifier un taux de salaire
Chacune de ces conditions, avant que l’action s’exécute.
Le compte existe-t-il seulement ?
Personne ne s’inscrit soi-même. L’auto-inscription est désactivée : un compte existe parce que quelqu’un dans l’organisation l’a créé – ce qui fait de la liste des comptes une décision plutôt qu’une conséquence.
La connexion elle-même a-t-elle réussi ?
Un seul serveur d’autorisation, dont chaque application de la suite est cliente – une seule connexion couvre donc toute la suite, au lieu que chaque application gère la sienne. Les mots de passe sont soumis à une règle de longueur minimale et de complexité, et ne peuvent pas reprendre les cinq derniers. Un second facteur par application d’authentification peut être activé, avec des codes de récupération ; il est activé utilisateur par utilisateur et non imposé à l’ensemble de l’organisation.
À quelle organisation ce compte appartient-il ?
Le compte renvoie à un enregistrement de collaborateur, et cet enregistrement porte l’organisation. Chaque requête exécutée par les applications est limitée à celle-ci ; c’est pourquoi un même déploiement peut accueillir plusieurs organisations sans que leurs enregistrements se croisent.
L’organisation dispose-t-elle d’une licence pour cette application ?
Un fichier de licence chiffré, vérifié lors de l’import par rapport au nom de l’organisation et à une date d’expiration, désigne les modules qui existent pour cette organisation. S’il a expiré, les privilèges passent en lecture seule au lieu que les applications continuent simplement de fonctionner.
Quel groupe d’autorisations le poste détient-il ?
Les groupes sont liés aux fonctions de l’organigramme, pas aux comptes. Le collaborateur occupe un poste ; le poste détient le groupe ; le groupe porte les applications et les privilèges. Un changement de titulaire n’est donc pas un changement d’autorisations – et il n’y a pas de liste d’exceptions par personne à tenir à jour.
Le groupe accorde-t-il exactement cette action, sur exactement ce formulaire ?
Pas un nom de rôle. Le groupe liste chaque formulaire individuellement et, pour chacun, chaque action individuellement – lire, créer, modifier, supprimer, télécharger. La lecture de la paie et la modification de la paie sont des autorisations distinctes, et l’une n’implique pas l’autre.
Alors seulement Le taux de salaire peut être modifié. Si l’une des six conditions n’est pas remplie, l’écran ne s’ouvre pas, ou s’ouvre sans cette action.
Quand l’appelant est une application et non une personne.
Il n’y a alors aucun poste à déterminer : l’autorisation est donc accordée à l’application elle-même et listée là où on peut la voir – les scopes d’identité et d’API qui lui ont été attribués, la date à laquelle elle a été accordée, sa date d’expiration et la commande qui la retire. Un accès qu’on ne peut pas voir ne peut pas être contrôlé, et c’est ici qu’il est visible.
Ce qui est réellement conservé, et ce que cela couvre.
- Une demande en cours conserve sa propre trace
- Une instance de processus enregistre les transitions effectuées et la version de la définition sous laquelle elle s’est exécutée : on peut ainsi établir après coup selon quelles règles une demande donnée a été tranchée. Process Builder
- Les affectations sont historisées
- L’affectation en cours est signalée par un indicateur, et les précédentes restent enregistrées avec leurs dates – savoir qui occupait un poste au moment où quelque chose s’est produit est donc une question qui a une réponse. Emploi & contrats
- L’acceptation de la clause de non-responsabilité est consignée
- L’avis que les utilisateurs doivent accepter est publié une seule fois pour l’organisation, et chaque acceptation est journalisée au nom de l’utilisateur qui l’a donnée. Configuration de l’entreprise
Ce que cette page n’affirme pas.
- Aucune certification n’est revendiquée. continON n’est pas présenté ici comme certifié, audité ou évalué selon ISO 27001, SOC 2, HIPAA, PCI DSS ou tout autre référentiel, et aucun badge de conformité ne figure sur ce site.
- L’authentification à deux facteurs existe sous la forme d’une application d’authentification activée par utilisateur. Elle n’est pas présentée comme imposée à l’échelle de l’organisation, et il n’existe pas de second facteur par SMS ou par e-mail.
- La fédération avec un fournisseur d’identité externe n’est pas proposée. Le câblage correspondant existe dans le code mais est actuellement désactivé ; elle n’est donc pas présentée comme une fonctionnalité que vous pouvez acheter aujourd’hui.
- Tout n’est pas audité. Les traces mentionnées ci-dessus sont des traces précises qui existent réellement ; cette page ne revendique pas de journal d’audit exhaustif couvrant chaque écran et chaque champ.
- Aucune propriété de chiffrement n’est affirmée au-delà de ce qui est visible : les noms d’hôte publics sont servis via TLS, et les clés d’API externes stockées sont chiffrées au repos. Rien de plus n’est affirmé concernant les données au repos ou en transit.
Apportez votre revue de sécurité.
Une séance de travail sur un mandant anonymisé, avec vos propres questions : comment un groupe est constitué, ce qu’un poste ouvre réellement, et à quoi ressemble l’autorisation d’une application une fois révoquée.