Privilèges des utilisateur pour l'intégration de base de données

Où créer l'utilisateur d'intégration

L'endroit où vous créez l'utilisateur dépend du type de base de données, et les privilèges requis varient parfois également en fonction de l'emplacement de déploiement de l'instance de base de données, par exemple Amazon RDS par rapport à une infrastructure gérée en interne.

Les sections suivantes répertorient les privilèges requis ainsi que des exemples de commandes permettant de créer l'utilisateur d'intégration, pour chaque type de base de données pris en charge. Remplacez integration_user_name et secure_password par vos valeurs.

MariaDB

Remplacez gateways_network_boundary par une expression IP qui identifie l'emplacement où se trouvent les passerelles Okta Privileged Access pour cette intégration. La saisie d'une seule adresse IP limite l'intégration à une seule passerelle et vous oblige à modifier les autorisations de cet utilisateur si vous changez de passerelle. L'utilisation exclusive du caractère générique % n'est pas sécurisée ; c'est pourquoi Okta vous déconseille de l'utiliser.

-- Create the integration user:
CREATE USER 'integration_user_name'@'gateways_network_boundary' IDENTIFIED BY 'secure_password';

-- Required for user discovery:
GRANT SELECT ON mysql.user TO 'integration_user_name'@'gateways_network_boundary';

-- Required for password rotation:
GRANT CREATE USER ON *.* TO 'integration_user_name'@'gateways_network_boundary';
     
GRANT SELECT ON mysql.global_priv TO 'integration_user_name'@'gateways_network_boundary';     
         

Microsoft SQL Server

Les commandes suivantes fonctionnent avec les instances de base de données autogérées, Amazon RDS, Cloud SQL de Google Cloud Platform et les instances gérées d'Azure SQL. Pour Microsoft SQL Server sur Azure SQL Database, voir Azure SQL Database.

Ces commandes créent l'utilisateur d'intégration en tant que compte de connexion dans la base de données master ; c'est à ce niveau que Okta Privileged Access peut consulter et renouveler les mots de passe des connexions sur l'ensemble de l'instance.

-- Create the integration user in the "master" context:
CREATE LOGIN [integration_user_name]
    WITH PASSWORD = 'secure_password', DEFAULT_DATABASE = master;
GO

-- Required for discovery and password rotation:
GRANT ALTER ANY LOGIN TO [integration_user_name];
GO

-- Required to reject read-only instances:
GRANT VIEW SERVER STATE TO [integration_user_name];

-- Required to read the server fingerprint, which identifies the instance
-- and prevents duplicate integrations to it:
GRANT VIEW ANY DATABASE TO [integration_user_name];

Azure SQL Database

Azure SQL Database utilise un modèle de base de données contenue et ne permet pas d'accès au niveau de l'instance ; par conséquent, les commandes au niveau du serveur échouent. Exécutez les commandes suivantes dans la base de données de l'application plutôt que dans master.

-- Create a contained integration user directly in the database:
CREATE USER [integration_user_name] WITH PASSWORD = 'secure_password';
GO

-- Required for rotating passwords:
GRANT ALTER ANY USER TO [integration_user_name];
GO

-- Required to protect against integration with read-only instances:
GRANT VIEW DATABASE STATE TO [integration_user_name];

Exécutez la commande suivante dans la base de données master d'Azure SQL Database afin d'éviter les intégrations en double :

ALTER SERVER ROLE [##MS_DefinitionReader##]
    ADD MEMBER [integration_user_name];

MongoDB

Créez un rôle personnalisé sur la base de données admin, puis accordez-le à l'utilisateur d'intégration. Remplacez authentication_db par la base de données d'authentification que cette intégration utilise, et user_authentication_db par la base de données dans laquelle l'utilisateur d'intégration est défini.

// 1. Create the role on the 'admin' database (required for cluster and cross-database access):
db.getSiblingDB("admin").createRole({
  role: "opaIntegrationRole",
  privileges: [
    // Required to discover users and rotate passwords on the target database:
    { resource: { db: "authentication_db", collection: "" }, actions: [ "viewUser", "changePassword" ] },
    // Required for preventing integration with a read-only replica:
    { resource: { cluster: true }, actions: [ "replSetGetConfig" ] },
    // Required to reliably identify the instance and prevent duplicate integrations:
    { resource: { db: "config", collection: "version" }, actions: [ "find" ] }
  ],
  roles: []
});

// 2. Grant the role to the user on the user's authentication database:
db.getSiblingDB("user_authentication_db").grantRolesToUser("integration_user_name", [
  { role: "opaIntegrationRole", db: "admin" }
]);

MySQL

Remplacez gateways_network_boundary par un bloc CIDR, un masque de sous-réseau ou une expression IP avec caractères génériques correspondant à l'emplacement où se trouvent, ou se trouveront, les passerelles Okta Privileged Access pour cette intégration. La saisie d'une adresse IP unique limite l'intégration à une seule passerelle et vous oblige à modifier les autorisations de cet utilisateur si vous modifiez la passerelle. L'utilisation exclusive du caractère générique % n'est pas sécurisée ; c'est pourquoi Okta vous déconseille de l'utiliser.

-- Create the integration user:
CREATE USER 'integration_user_name'@'gateways_network_boundary' IDENTIFIED BY 'secure_password';

-- Required for user discovery:
GRANT SELECT ON mysql.user TO 'integration_user_name'@'gateways_network_boundary';
GRANT SELECT ON mysql.role_edges TO 'integration_user_name'@'gateways_network_boundary';
GRANT RELOAD ON *.* TO 'integration_user_name'@'gateways_network_boundary';

-- Required for password rotation:
GRANT CREATE USER ON *.* TO 'integration_user_name'@'gateways_network_boundary';
GRANT CREATE ROLE ON *.* TO 'integration_user_name'@'gateways_network_boundary';
GRANT CONNECTION_ADMIN ON *.* TO 'integration_user_name'@'gateways_network_boundary';
GRANT ALL PRIVILEGES ON `target_db`.* TO 'integration_user_name'@'gateways_network_boundary' WITH GRANT OPTION;
FLUSH PRIVILEGES;

Oracle Database

Les intégrations Oracle Database sont effectuées au niveau du conteneur et ne permettent pas de gérer les accès aux PDB enfants. Connectez-vous directement au conteneur cible, à savoir CDB$ROOT, un conteneur d'application ou une PDB, pour lequel vous souhaitez créer une intégration, puis exécutez-y les commandes suivantes.

-- Create the integration user:
CREATE USER integration_user_name IDENTIFIED BY "secure_password";

-- Allow connection using this user:
GRANT CREATE SESSION TO integration_user_name CONTAINER=CURRENT;

-- Required for user discovery, for preventing duplicate integrations,
-- and for preventing integration with read-only instances:
GRANT SELECT_CATALOG_ROLE TO integration_user_name CONTAINER=CURRENT;

-- Required for password rotation:
GRANT ALTER USER TO integration_user_name CONTAINER=CURRENT;

Pour les intégrations CDB, exécutez les commandes suivantes dans le conteneur CDB$ROOT ou dans le conteneur racine de l'application s'il s'agit d'un conteneur d'application. La seule différence par rapport aux commandes précédentes est CONTAINER=ALL, élément requis par Oracle car le niveau de privilèges d'un utilisateur standard doit être cohérent dans tous les conteneurs de la CDB :

CREATE USER c##integration_user_name IDENTIFIED BY "secure_password" CONTAINER=ALL;
GRANT CREATE SESSION,
      SELECT_CATALOG_ROLE,
      ALTER USER,
      SET CONTAINER
   TO c##integration_user_name CONTAINER=ALL;

-- Required to open visibility into every PDB's rows in CDB-wide dynamic views
-- (V$PDBS, V$SESSION, V$INSTANCE)
ALTER USER c##integration_user_name SET CONTAINER_DATA = ALL CONTAINER = CURRENT;

PostgreSQL

-- Create the integration user:
CREATE USER integration_user_name WITH PASSWORD 'secure_password';

-- Superuser is required in order to change password for any user
-- Use this for self-hosted:
ALTER USER integration_user_name WITH CREATEROLE;
ALTER USER integration_user_name WITH SUPERUSER;
-- Use this if DB is on Amazon RDS:
-- GRANT rds_superuser TO integration_user_name;

Okta Privileged Access nécessite des privilèges de superutilisateur sur PostgreSQL. Un utilisateur PostgreSQL ne peut modifier le mot de passe que d'un utilisateur dont il gère le rôle ; ainsi, sans les droits de superutilisateur, vous devriez répertorier tous les comptes gérés dans les autorisations de l'utilisateur d'intégration et les mettre à jour à chaque fois qu'un compte est ajouté. Le superutilisateur permet à Okta Privileged Access d'effectuer la rotation du mot de passe pour tout compte existant ou futur sur l'instance.

Étapes suivantes

Une fois que vous avez créé l'utilisateur d'intégration, vous pouvez installer la passerelle Okta Privileged Access et la configurer pour prendre en charge les intégrations de base de données.