Concepts liés aux politiques de sécurité

Lorsque vous créez une politique de sécurité, vous pouvez configurer les fonctionnalités de contrôle d'accès suivantes :

Fonctionnalité	Description
Principal	Les utilisateurs et les groupes qui sont associés à la politique et qui se voient accorder l'accès aux ressources correspondantes. Voir Okta Privileged Access pour en savoir plus.
Politique	Une politique fait référence à un ensemble de règles ou de directives qui dictent la manière dont l'accès privilégié est géré au sein d'une organisation. Ces actions peuvent inclure l'accès à des données sensibles, des modifications de configuration critiques ou l'installation de logiciels.
Règles	Les règles d'une politique définissent des conditions, des actions ou des restrictions spécifiques liées à la gestion et à l'utilisation de comptes ayant des privilèges. Ces règles sont conçues pour appliquer les bonnes pratiques de sécurité, se conformer aux exigences de conformité et atténuer les risques associés à un accès privilégié. Une règle est utilisée pour définir la permission des ressources et la manière dont un accès privilégié est accordé aux ressources. Chaque politique de sécurité contient une règle qui définit les ressources et les privilèges disponibles pour chaque principal. Les administrateurs de sécurité et les administrateurs de sécurité délégués peuvent créer les règles suivantes : Règle de serveur Règle secrète
Type de session	Il s'agit de la façon dont les utilisateurs ont accès aux ressources. Le type de session peut être SSH ou RDP.
Ressources	Les accès privilégiés aux ressources sont basés sur la politique créée par l'administrateur de sécurité ou l'administrateur de sécurité délégué. Vous pouvez configurer la permission des accès aux ressources à l'aide des méthodes suivantes. Ressources utilisant des libellés Sélectionnez les libellés à utiliser et incluez les serveurs qui correspondent à le libellé lors de la création d'une règle. Après avoir défini la permission des serveurs à l'aide de libellés, vous pouvez configurer la manière dont les principaux accèdent aux ressources. Les principaux peuvent accéder aux ressources en se connectant aux serveurs avec un compte individuel à la demande, un compte local en coffre-fort, ou les deux. Ressources par nom Appliquer la politique à une ressource spécifique ; par exemple, apiserver-prod / pamadmin. La connexion SSH racine est désactivée par défaut sur la plupart des installations Linux.
Libellés	Vous pouvez appliquer des libellés à des serveurs individuels. Ces libellés permettent aux équipes Okta Privileged Access de catégoriser et de trier les accès au serveur. Il existe deux types de libellé : Libellés générées par le système : lorsque vous ajoutez un serveur à Okta Privileged Access, plusieurs libellés générées par le système sont automatiquement créées en fonction de caractéristiques telles que le nom d'hôte, le type de serveur, le système d'exploitation, AWS, Azure ou Google ID du compte Cloud Platform. Libellés personnalisées : vous pouvez configurer les libellés directement dans le fichier de configuration de l'agent du serveur (sftd.yaml), qui apparaît ensuite dans la console Okta Privileged Access pour sélection. Pour ajouter des libellés personnalisées dans le fichier de configuration de l'agent du serveur, consultez Libellés personnalisées. Les libellés personnalisées peuvent avoir une incidence sur l'accessibilité au serveur. Okta recommande d'utiliser les libellés personnalisées avec précaution. Les libellés sont stockées au format de paire clé:valeur. Ce format offre une plus grande flexibilité aux équipes. Les libellés peuvent provenir du système ou du fichier de configuration sftd. Okta Privileged Access ajoute automatiquement un préfixe pour identifier la source de le libellé. Par exemple, un serveur peut porter deux libellés, env:prod et env:test. Si le libellé env:prod provient de Okta Privileged Access, le préfixe système ressemblera à ce qui suit : system.env:prod. De même, si le libellé env:test provient du fichier de configuration sftd, les préfixes sftd ressembleront à ce qui suit : sftd.env:test. Cette méthode permet d'éviter les conflits dans le cas où la même libellé a été ajoutée à partir de plusieurs sources (par exemple, si un libellé a été spécifiée à la fois par le système et par un fichier de configuration d'agent du serveur).
Enregistrement de session	Voir Enregistrement de session.
Demande d'approbation	Voir Okta Privileged Access avec demandes d'accès
Authentification multifacteur (MFA)	Voir Authentification multifacteur (MFA).

Rubriques liées

Politique de sécurité