ポリシーにルールを追加する

リソースのスコープと、これらリソースへの特権アクセスの付与方法を定義するルールを追加します。追加できるルールの種類は、セットアップしたポリシーの種類によって異なります。Oktaサービスアカウントポリシーでは、Oktaのルールタイプのみを追加できますが、デフォルトポリシーでは、Okta以外のすべてのポリシータイプのルールを追加することができます。

開始する前に

  • 既存のポリシーがあるか、ポリシーの作成中である必要があります。「セキュリティポリシーを作成または更新する」を参照してください。
  • セキュリティ管理者または代理セキュリティ管理者ロールが割り当てられている必要があります。

デフォルトポリシーのルールを追加する

このルールは、サーバー、シークレット、SaaSアプリサービスアカウント、またはActive Directoryに対して追加できます。

  1. [Security Administration(セキュリティ管理)][Policies(ポリシー)]に移動します。

  2. ルールを追加するポリシーを選択します。
  3. [Add rule(ルール追加)]を選択してから、次のいずれかのルールタイプを選択します:[Server rule(サーバールール)][Secret rule(シークレットルール)][SaaS app service account rule(SaaSアプリサービスアカウントルール)]、または[Active Directory account rule(Active Directoryアカウントルール)]
  4. 前の手順での選択内容に基づいて、次のいずれかを完了させます。
  5. ルールの[Save(保存)]をクリックします。このポリシーを公開できるようになります。

サーバールールを構成する

[Server rule(サーバールール)]を選択した場合は、次の手順を実行します。

設定 アクション

Rule name(ルール名)

ルール名を入力します。

Select the resources that you want to protect with this rule(このルールによって保護するリソースを選択)

ラベルまたは名前によってリソースを選択できます。選択内容に応じて、その他の構成を行う必要があります。

Select servers by label(サーバーをラベルで選択する)

  1. [Select resources by label(リソースをラベルで選択する)]に切り替えます。
  2. [リソースを追加]フィールドでリソースラベルを検索して選択します。複数のリソースラベルを選択できます。
  3. [Access resources by individual account(個別アカウントでリソースにアクセス)][Access resources by vaulted account(vaultで管理されているアカウントでリソースにアクセス)]のいずれか、または両方のアクセス方式を選択します。
  4. [Access resources by individual account(個別アカウントでリソースにアクセス)]を選択した場合は、[User-level permissions(ユーザーレベルの権限)][Admin-level permissions(管理者レベルの権限)][User-level with sudo commands(ユーザーレベルとsudoコマンド)]のいずれかのオプションを選択します。
  5. [User-level with sudo commands(ユーザーレベルとsudoコマンド)を選択した場合は、次の手順を実行します。
    1. [Sudo commands(sudoコマンド)]フィールドにコマンドを入力し、Enterキーを押して選択します。ルールごとに最大10個のsudoコマンドを追加できます。
    2. [End-user Display Name(エンドユーザー表示名)]フィールドにsudoコマンドバンドルの集合のニックネームを入力します。ニックネームの最大長さは64文字に制限され、使用できる文字は、0~9、A~Z、a~z、-、_、空白文字のみです。
  6. [Access resources by vaulted account(vaultで管理されているアカウントでリソースにアクセス)]を選択した場合は、[Select vaulted accounts(vaultで管理されているアカウントを選択)]フィールドにアカウント名を入力し、キーボードのEnterキーを押してアカウントを選択します。1つまたは複数のアカウントを追加できます。

[Select accounts by label(アカウントをラベルで選択する)]

  1. [Select resources by name(リソースを名前で選択する)]に切り替えます。
  2. 1つ以上のサーバーを個別に選択します。

Enable session recording(セッションの記録を有効にする)

任意。セッションの記録を有効にするには、Oktaリソース管理者が事前にゲートウェイを登録およびインストールする必要があります。

  1. [Enable traffic forwarding through gateways(ゲートウェイ経由のトラフィックフォワーディングを有効にする)]を選択します。
  2. [Record session through gateways(ゲートウェイ経由でセッションを記録)]を選択します。

承認リクエスト

任意。アクセスリクエストワークフローがセキュリティポリシーで表示されるようにするには、まず、アクセスリクエストでリクエストタイプを作成します。「Okta Privileged Accessとアクセスリクエスト」を参照してください。

  1. [Enable approval requests(承認リクエストを有効にする)]に切り替えます。
  2. 承認リクエストタイプを選択します。
  3. 承認を存続させる期間を選択します。

アカウントの権限

任意。ユーザーがvaultで管理されているアカウントの資格情報を復号し、プレーンテキストで表示できるようにするには、[Reveal(表示)]をクリックします。

MFAの有効化

任意。MFAを有効にして、ポリシー内にきめ細かいレベルの認証と制御を追加します。

  1. [Enable MFA(MFAの有効化)]に切り替えます。
  2. 次のいずれかのオプションを選択します。[Any two-factor types(任意の2要素タイプ)]または[Phishing Resistant(フィッシング耐性)]
  3. 次のいずれかの再認証の頻度を選択します。[Every SSH or RDP connection attempt(SSHまたはRDP接続試行のたびに毎回)](リソースへのアクセス試行のたびにMFAを実行)、または[After the specified duration(指定期間後)](5分~12時間の範囲で期間を指定し、デフォルトは30分)。

ポリシーの実装後は、リソースへの接続を試みるユーザーは必要なMFAステップを完了する必要があります。

シークレットルールを構成する

[Secret rule(シークレットルール)]を選択した場合は、次の手順を実行します。

設定 アクション

Rule name(ルール名)

ルール名を入力します。

Select the secret folder or secret you want to protect with this rule(このルールによって保護するシークレットフォルダーまたはシークレットを選択)

  1. [Select secret folder or secret(シークレットフォルダーまたはシークレットを選択)]をクリックします。
  2. シークレットフォルダーまたはシークレットを選択します。
  3. [Save(保存)]をクリックします。

Select Permissions(権限を選択)

権限を選択します。少なくとも1つの権限を選択する必要があります。詳細については、「シークレット権限」を参照してください。

承認リクエスト

アクセスリクエストワークフローがセキュリティポリシーで表示されるようにするには、まず、アクセスリクエストでリクエストタイプを作成します。「Okta Privileged Accessとアクセスリクエスト」を参照してください。

  1. [Enable approval requests(承認リクエストを有効にする)]に切り替えます。
  2. 承認リクエストタイプを選択します。
  3. 承認を存続させる期間を選択します。

Enable MFA(MFAの有効化)

任意。MFAを有効にして、ポリシー内にきめ細かいレベルの認証と制御を追加します。

  1. [Enable MFA(MFAの有効化)]に切り替えます。
  2. 次のいずれかのオプションを選択します。[Any two-factor types(任意の2要素タイプ)]または[Phishing Resistant(フィッシング耐性)]
  3. 次のいずれかの再認証頻度を選択します。
    • [Every SSH or RDP connection attempt(SSHまたはRDP接続試行のたびに毎回)]:リソースへのアクセス試行のたびにMFAを実行します。
    • [After the specified duration(指定期間後)]:5分~12時間の範囲で期間を指定します。デフォルトは30分です。

SaaSアプリサービスアカウントルールを構成する

[SaaS app service account rule(SaaSアプリサービスアカウントルール)]を選択した場合は、次の手順を実行します。

  1. ルール名を入力します。
  2. パスワード更新方法を以下から1つ選択します。
    • [Automated(自動化)]
    • [Manual(手動)]
  3. [Automated(自動化)]を選択した場合は、次の手順を実行します。
    設定アクション

    Accounts to protect(保護アカウント)

    ラベルまたは名前によってリソースを選択できます。選択内容に応じて、その他の構成を行う必要があります。

    1. [Select accounts by label(アカウントをラベルで選択する)]に切り替えます。
    2. [Accounts(アカウント)]ドロップダウンリストをクリックして、1つ以上のラベルを追加します。
    3. [Select resources by name(リソースを名前で選択する)]に切り替えます。
    4. 1つ以上のアカウントを個別に選択します。

    承認リクエスト

    任意。アクセスリクエストワークフローがセキュリティポリシーで表示されるようにするには、まず、Access Requestsでリクエストタイプを作成する必要があります。「Okta Privileged Accessとアクセスリクエスト」を参照してください。

    1. [Enable approval requests(承認リクエストを有効にする)]に切り替えます。
    2. 承認リクエストタイプを選択します。
    3. 承認を存続させる期間を選択します。

    アカウントの権限

    任意。次のいずれかを少なくとも1つ選択します。

    • [Reveal(表示する)]:ユーザーが資格情報を復号し、プレーンテキストで表示できるようにします。
    • [Rotate Password(パスワードをローテーション)]:ユーザーにパスワードをローテーションする権限を付与します。
    • 任意。 [Override Managed Password(管理対象パスワードを上書き)]を選択します。これにより、ユーザーはパスワードを上書きして帯域外のパスワード変更に対応できます。

    MFAの有効化

    任意。MFAを有効にして、ポリシー内にきめ細かいレベルの認証と制御を追加します。

    1. [Enable MFA(MFAの有効化)]に切り替えます。
    2. 次のいずれかのオプションを選択します。[Any two-factor types(任意の2要素タイプ)]または[Phishing Resistant(フィッシング耐性)]
    3. 次のいずれかの再認証頻度を選択します。
      • [Every guarded action a user takes(ユーザーが警戒アクション取るたびに毎回)]:リソースへのアクセス試行のたびにMFAを実行します。
      • [After the specified duration(指定期間後)]:5分~12時間の範囲で期間を指定します。デフォルトは30分です。

    ポリシーの実装後は、リソースへの接続を試みるユーザーは必要なMFAステップを完了する必要があります。

    Maximum checkout time(最大チェックアウト時間)

    任意。この時間制限は、このポリシー内でチェックアウトが有効化されているすべてのリソースに適用されます。

    1. [Override the project-level maximum checkout time(プロジェクトレベルの最大チェックアウト時間をオーバーライド)]に切り替えます。
    2. [Quantity(数量)][Unit(単位)]を設定します。
  4. [Manual(手動)]を選択した場合は、次の手順を実行します。
    設定アクション

    Permission for accounts(アカウントの権限)

    任意。次のいずれかを少なくとも1つ選択します。

    • [Reveal(表示する)]:ユーザーが資格情報を復号し、プレーンテキストで表示できるようにします。
    • [Update(更新)]:資格情報の値を変更する権限をユーザーに付与します。

    Accounts to protect(保護アカウント)

    1. [Select resources by name(リソースを名前で選択する)]に切り替えます。
    2. [Accounts(アカウント)]ドロップダウンリストをクリックして、1つ以上のラベルを追加します。
    3. [Select resources by name(リソースを名前で選択する)]に切り替えます。
    4. 1つ以上のアカウントを個別に選択します。

    承認リクエスト

    任意。アクセスリクエストワークフローがセキュリティポリシーで表示されるようにするには、まず、Access Requestsでリクエストタイプを作成する必要があります。「Okta Privileged Accessとアクセスリクエスト」を参照してください。

    1. [Enable approval requests(承認リクエストを有効にする)]に切り替えます。
    2. 承認リクエストタイプを選択します。
    3. 承認を存続させる期間を選択します。

    Enable MFA(MFAの有効化)

    任意。MFAを有効にして、ポリシー内にきめ細かいレベルの認証と制御を追加します。

    1. [Enable MFA(MFAの有効化)]に切り替えます。
    2. 次のいずれかのオプションを選択します。[Any two-factor types(任意の2要素タイプ)]または[Phishing Resistant(フィッシング耐性)]
    3. 次のいずれかの再認証頻度を選択します。
      • [Every guarded action a user takes(ユーザーが警戒アクション取るたびに毎回)]:リソースへのアクセス試行のたびにMFAを実行します。
      • [After the specified duration(指定期間後)]:5分~12時間の範囲で期間を指定します。デフォルトは30分です。

    ポリシーの実装後は、リソースへの接続を試みるユーザーは必要なMFAステップを完了する必要があります。

Active Directoryアカウントルールを構成する

特定のリソースグループにセキュリティポリシーが構成されている場合、Active Directoryアカウントとサーバーの両方が同じリソースグループに属している必要があります。属していない場合、RDPを介したリモートアクセスが失敗し、接続が成功しません。

Active Directory account rule(Active Directoryアカウントルール)]を選択した場合は、次の手順を実行します。

設定 アクション

Rule name(ルール名)

ルール名を入力します。

Accounts to protect(保護アカウント)

  1. [Select individual accounts(個別アカウントを選択する)]チェックボックスをクリックします。
  2. 任意。[Operator(演算子)]を選択して、[Value(値)]を入力します。
  3. 任意。[Domain(ドメイン)] フィールドに1つ以上のドメイン名を入力します。
  4. [Select shared accounts by matching names(共有アカウントを一致する名前で選択する)]チェックボックスをクリックします。
  5. [Account name(アカウント名)] フィールドに1つ以上のアカウントを入力します。
  6. 任意。[Domain(ドメイン)] フィールドに1つ以上のドメイン名を入力します。
  7. Select specific shared accounts(特定の共有アカウントを選択する)の下で、検索バーを使用してアカウントを検索し、1つ以上のアカウントを選択します。

Shared Accounts by Name(共有アカウントを名前で)]は、アカウントを名前で一致します。アカウントが存在していなくても構いません。現在または将来その名前を持つすべてのアカウントが一致します。

特定のアカウントを選択すると、実際のアカウントとSIDを選択することになります。アカウントが削除された後、そのドメイン内に同じ名前で異なるSIDのアカウントが再作成された場合は、このポリシーと一致しなくなるため、そのアカウントを再度選択する必要があります。

アカウントの権限

次のいずれかのオプションを少なくとも1つ選択します。

  • [Reveal(表示する)]:ユーザーが資格情報を復号し、プレーンテキストで表示できるようにします。
  • [Rotate Password(パスワードをローテーション)]:ユーザーにパスワードをローテーションする権限を付与します。
  • [RDP session(RDPセッション)]:Windowsサーバー上でRDPセッションを開始する権限をユーザーに付与します。
  • 次のオプションは、[RDP session(RDPセッション)]を選択すると使用可能になります。Active Directory(AD)ポリシールールでサーバーを指定することで、ユーザーが対象のADアカウントを使用してそれらのサーバー上でRDPセッションを開始できるようにします。
    1. [By label(ラベルで)]を選択します。
    2. [Add resources(リソースを追加)]フィールドでサーバーラベルを検索して選択します。複数のサーバーラベルを選択することができます。
    3. [By name(名前で)]を選択し、1つ以上のサーバーを個別に選択します。
    4. Okta Privileged Accessによるローカルグループメンバーシップの管理を決定するには、次のいずれかのオプションを選択します。最初の2つのオプションでは、アカウントが[Administrators(管理者)]グループまたは[Remote Desktop Users(リモートデスクトップユーザー)]グループに追加されます。ローカルグループの管理に別の方法を使用する場合は、[Not to be added to any local groups(ローカルグループに追加されない)]を選択します。
      • Be added to "Remote Desktop Users" group(「リモートデスクトップユーザー」グループに追加される)
      • Be added to "Administrators" group(「管理者」グループに追加される)
      • [Not be added to any local group(ローカルグループに追加されない)]

      これは、ドメインコントローラーのsftd.yamlファイルがグループ管理を許可するように構成されていない限り、ドメインコントローラーには適用されません。「Windowsドメインコントローラー」を参照してください。

  • [SSH Session(SSHセッション)]:認証済みのActive DirectoryドメインアカウントがSSHを介してADドメイン内のLinuxサーバーに接続できるようにします。

    既存のローカルユーザーが存在しない状態で非完全修飾ユーザー名を使用すると、 Active Directoryアカウントの作成ができず、サインインに失敗します。

    1. [By label(ラベルで)]を選択します。
    2. [Add resources(リソースを追加)]フィールドでサーバーラベルを検索して選択します。複数のサーバーラベルを選択することができます。
    3. [By name(名前で)]を選択し、1つ以上のサーバーを個別に選択します。

セッションの記録

任意。セッションの記録を有効にするには、Oktaリソース管理者が事前にゲートウェイを登録およびインストールする必要があります。

  1. [Enable traffic forwarding through gateways(ゲートウェイ経由のトラフィックフォワーディングを有効にする)]を選択します。
  2. [Record session through gateways(ゲートウェイ経由でセッションを記録)]を選択します。

トラフィック転送とセッションの記録を有効にすると、この条件はRDPセッションとSSHセッションの両方に適用されます。

承認リクエスト

任意。アクセスリクエストワークフローがセキュリティポリシーで表示されるようにするには、まず、アクセスリクエストでリクエストタイプを作成する必要があります。「Okta Privileged Accessとアクセスリクエスト」を参照してください。

  1. [Enable approval requests(承認リクエストを有効にする)]に切り替えます。
  2. 承認リクエストタイプを選択します。
  3. 承認を存続させる期間を選択します。

Enable MFA(MFAの有効化)

任意。MFAを有効にして、ポリシー内にきめ細かいレベルの認証と制御を追加します。

  1. [Enable MFA(MFAの有効化)]に切り替えます。
  2. 次のいずれかのオプションを選択します。[Any two-factor types(任意の2要素タイプ)]または[Phishing Resistant(フィッシング耐性)]
  3. 次のいずれかの再認証頻度を選択します。
    • [Every SSH or RDP connection attempt(SSHまたはRDP接続試行のたびに毎回)]:リソースへのアクセス試行のたびにMFAを実行します。
    • [After the specified duration(指定期間後)]:5分~12時間の範囲で期間を指定します。デフォルトは30分です。

ポリシーの実装後は、リソースへの接続を試みるユーザーは必要なMFAステップを完了する必要があります。

Maximum checkout time(最大チェックアウト時間)

任意。この時間制限は、このポリシー内でチェックアウトが有効化されているすべてのリソースに適用されます。

  1. [Override the project-level maximum checkout time(プロジェクトレベルの最大チェックアウト時間をオーバーライド)]に切り替えます。
  2. [Amount(量)][Duration(期間)]を設定します。

Oktaサービスアカウントポリシーのルールを追加する

このルールをOktaサービスアカウントポリシーに追加します。

  1. [Security Administration(セキュリティ管理)][Policies(ポリシー)]に移動します。

  2. ルールを追加するポリシーを選択します。
  3. [Add rule(ルールを追加)]を選択して、次の手順を実行します。
    設定アクション

    Rule name(ルール名)

    ルール名を入力します。

    Accounts to protect(保護アカウント)

    ラベルまたは名前によってリソースを選択できます。選択内容に応じて、その他の構成を行う必要があります。

    Select accounts by name(アカウントを名前で選択する)

    1. [Select accounts by name(アカウントを名前で選択する)]に切り替えます。
    2. 1つ以上のアカウントを個別に選択します。

    承認リクエスト

    任意。アクセスリクエストワークフローがセキュリティポリシーで表示されるようにするには、まず、アクセスリクエストでリクエストタイプを作成する必要があります。「Okta Privileged Accessとアクセスリクエスト」を参照してください。

    1. [Enable approval requests(承認リクエストを有効にする)]に切り替えます。
    2. 承認リクエストタイプを選択します。
    3. 承認を存続させる期間を選択します。

    Enable MFA(MFAの有効化)

    任意。MFAを有効にして、ポリシー内にきめ細かいレベルの認証と制御を追加します。

    1. [Enable MFA(MFAの有効化)]に切り替えます。
    2. 次のいずれかのオプションを選択します。[Any two-factor types(任意の2要素タイプ)]または[Phishing Resistant(フィッシング耐性)]
    3. 次のいずれかの再認証頻度を選択します。
      • [Every guarded action a user takes(ユーザーが警戒アクション取るたびに毎回)]:リソースへのアクセス試行のたびにMFAを実行します。
      • [After the specified duration(指定期間後)]:5分~12時間の範囲で期間を指定します。デフォルトは30分です。

    ポリシーの実装後は、リソースへの接続を試みるユーザーは必要なMFAステップを完了する必要があります。

    Maximum checkout time(最大チェックアウト時間)

    任意。この時間制限は、このポリシー内でチェックアウトが有効化されているすべてのリソースに適用されます。

    1. [Override the project-level maximum checkout time(プロジェクトレベルの最大チェックアウト時間をオーバーライド)]に切り替えます。
    2. [Amount(量)][Duration(期間)]を設定します。
  4. [Save rule(ルールを保存)]をクリックします。
  5. [Save policy(ポリシーを保存)]をクリックします。このポリシーを公開できるようになります。

関連項目

セキュリティポリシー

Okta Privileged Accessとアクセスリクエスト