データベース統合ユーザー権限

統合ユーザーを作成する場所

ユーザーを作成する場所はデータベースのタイプによって異なり、必要な権限もデータベースインスタンスがデプロイされる場所によって異なる場合があります（たとえば、Amazon RDSと自己管理対象インフラストラクチャの場合）。

以下のセクションでは、サポートされるデータベースタイプごとに、必要な権限と、統合ユーザーを作成するためのコマンドの例を示しています。integration_user_nameとsecure_passwordは、自分の値に置き換えてください。

MariaDB

gateways_network_boundaryを、この統合のOkta Privileged Accessゲートウェイの場所を特定するIP式に置き換えます。単一のIPアドレスを入力すると、統合は1つのゲートウェイに制限され、ゲートウェイを変更する場合はこのユーザーの付与を変更する必要があります。%ワイルドカードのみの使用は安全でないため、Oktaは推奨しません。

-- 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

次のコマンドは、自己管理されたデータベースインスタンス、Amazon RDS、Google Cloud Platform Cloud SQL、およびAzure SQL管理対象インスタンスに対して機能します。Azure SQLデータベースのMicrosoft SQLサーバーについては、「Azure SQLデータベース」を参照してください。

これらのコマンドは、masterデータベースに統合ユーザーをログインとして作成します。これは、Okta Privileged Accessがインスタンス全体でログインのパスワードを読み取ったりローテーションしたりできるスコープです。

-- 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データベース

Azure SQLデータベースは含まれているデータベースモデルを使用し、インスタンスレベルのアクセスを提供しないため、サーバーレベルのコマンドは失敗します。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];

重複した統合から保護するには、Azure SQLデータベースのmasterデータベース内で次のコマンドを実行します。

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

MongoDB

adminデータベースにカスタムロールを作成し、それを統合ユーザーに付与します。authentication_dbをこの統合が使用する認証データベースに置き換え、user_authentication_dbを統合ユーザーが定義されているデータベースに置き換えます。

// 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

gateways_network_boundaryをこの統合のOkta Privileged Accessゲートウェイの場所に対応するCIDRブロック、サブネットマスク、またはIPワイルドカード式に置き換えます。単一のIPアドレスを入力すると、統合は1つのゲートウェイに制限され、ゲートウェイを変更する場合はこのユーザーの付与を変更する必要があります。%ワイルドカードのみの使用は安全でないため、Oktaは推奨しません。

-- 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

Oracle Database統合はコンテナレベルで行われ、子PDBにアクセス管理は提供されません。統合を作成しようとしているターゲットコンテナ（CDB$ROOT、アプリコンテナ、またはPDB）に直接接続し、そこで次のコマンドを実行します。

-- 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;

CDB統合の場合、CDB$ROOTコンテナ、またはアプリコンテナの場合はアプリルートコンテナで、次のコマンドを実行します。前述のコマンドとの唯一の違いはCONTAINER=ALLです。Oracleでは、共通ユーザーの権限状態が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では、PostgreSQLのスーパーユーザー権限が必要です。PostgreSQLユーザーはロールを管理するユーザーのパスワードのみを変更できるため、スーパーユーザーがない場合、統合ユーザーの付与ですべての管理対象アカウントをリスト化し、アカウントを追加するたびに更新する必要があります。スーパーユーザーは、インスタンス上の既存または将来のアカウントのパスワードをOkta Privileged Accessでローテーションできます。

次に行うべきこと

統合ユーザーを作成したら、Okta Privileged Accessゲートウェイをインストールして、データベース統合をサポートするように構成できます。