ポリシーにルールを追加する
リソースのスコープと、これらリソースへの特権アクセスの付与方法を定義するルールを追加します。追加できるルールの種類は、セットアップしたポリシーの種類によって異なります。Oktaサービスアカウントポリシーでは、Oktaのルールタイプのみを追加できますが、デフォルトポリシーでは、Okta以外のすべてのポリシータイプのルールを追加することができます。
開始する前の確認事項
- 既存のポリシーがあるか、ポリシーの作成中である必要があります。セキュリティポリシーを作成または更新するを参照してください。
- セキュリティ管理者または代理セキュリティ管理者ロールが割り当てられている必要があります。
デフォルトポリシーのルールを追加する
このルールは、サーバー、シークレット、SaaSアプリサービスアカウント、またはActive Directoryに対して追加できます。
-
に移動します。
- ルールを追加するポリシーを選択します。
- ルール追加（Add rule）を選択してから、次のいずれかのルールタイプを選択します：サーバールール（Server rule）、シークレットルール（Secret rule）、SaaSアプリサービスアカウントルール（SaaS app service account rule）または Active Directoryアカウントルール（ account rule）。
- 前の手順での選択内容に基づいて、次のいずれかを完了させます。
- ルールの保存（Save）をクリックします。このポリシーを公開できるようになります。
サーバールールを構成する
サーバールール（Server rule）を選択した場合は、次の手順を実行します。
| 設定 | アクション |
|---|---|
|
ルール名（Rule name） |
ルール名を入力します。 |
|
このルールによって保護するリソースを選択（Select the resources that you want to protect with this rule） |
ラベルまたは名前によってリソースを選択できます。選択内容に応じて、その他の構成を行う必要があります。 Select servers by label（サーバーをラベルで選択する）
［Select accounts by label（アカウントをラベルで選択する）］
|
|
Enable session recording（セッションの記録を有効にする） |
任意。セッションの記録を有効にするには、Oktaリソース管理者が事前にゲートウェイを登録およびインストールする必要があります。
|
|
承認リクエスト |
任意。アクセスリクエストワークフローがセキュリティポリシーで表示されるようにするには、まず、Access Requestsでリクエストタイプを作成します。Okta Privileged Accessとアクセスリクエストを参照してください。
|
|
アカウントの権限 |
任意。次のいずれかを少なくとも1つ選択します。
|
|
Enable MFA（MFAの有効化） |
任意。MFAを有効にして、ポリシー内にきめ細かいレベルの認証と制御を追加します。
ポリシーの実装後は、リソースへの接続を試みるユーザーは必要なMFAステップを完了する必要があります。 注:
MFAを使用したユーザーの認証後に、10秒間の猶予期間が適用されます。この猶予期間中は、サインオンのたび（Every sign-on）が選択されている場合でも、Oktaはユーザーにパスワードの再入力を求めません。 この機能は、SAMLで構成されたすべてのアプリで利用できます。 SWAアプリでは再認証がサポートされないため、再認証が選択されている場合、サインオン方式をSAMLからSWAに変更することはできません。 |
シークレットルールを構成する
シークレットルール（Secret rule）を選択した場合は、次の手順を実行します。
| 設定 | アクション |
|---|---|
|
ルール名（Rule name） |
ルール名を入力します。 |
|
このルールによって保護するシークレットフォルダーまたはシークレットを選択（Select the secret folder or secret you want to protect with this rule） |
|
|
権限を選択（Select Permissions） |
権限を選択します。少なくとも1つの権限を選択する必要があります。詳細については、シークレット権限を参照してください。 |
|
承認リクエスト |
アクセスリクエストワークフローがセキュリティポリシーで表示されるようにするには、まず、Access Requestsでリクエストタイプを作成します。「 Okta Privileged Access を使ったAccess Requests 」を参照してください。
|
|
MFAの有効化（Enable MFA） |
任意。MFAを有効にして、ポリシー内にきめ細かいレベルの認証と制御を追加します。
注:
MFAを使用したユーザーの認証後に、10秒間の猶予期間が適用されます。この猶予期間中は、サインオンのたび（Every sign-on）が選択されている場合でも、Oktaはユーザーにパスワードの再入力を求めません。 この機能は、SAMLで構成されたすべてのアプリで利用できます。 SWAアプリでは再認証がサポートされないため、再認証が選択されている場合、サインオン方式をSAMLからSWAに変更することはできません。 |
SaaSアプリサービスアカウントルールを構成する
SaaSアプリサービスアカウントルール（SaaS app service account rule）を選択した場合は、次の手順を実行します。
- ルール名を入力します。
- パスワード更新方法を以下から1つ選択します。
- 自動化（Automated）
- 手動（Manual）
- 自動化（Automated）を選択した場合は、次の手順を実行します。
設定 アクション 保護アカウント（Accounts to protect）
1つ以上のアカウントを選択します。
アカウントの権限
任意。次のいずれかを少なくとも1つ選択します。
- 表示する（Reveal）：ユーザーが資格情報を復号し、プレーンテキストで表示できるようにします。
- パスワードをローテーション（Rotate Password）：ユーザーにパスワードをローテーションする権限を付与します。
- 任意。管理対象パスワードを上書き（Override Managed Password）を選択します。これにより、ユーザーはパスワードを上書きして帯域外のパスワード変更に対応できます。
承認リクエスト
任意。アクセスリクエストワークフローがセキュリティポリシーで表示されるようにするには、まず、Access Requestsでリクエストタイプを作成する必要があります。Okta Privileged Accessとアクセスリクエストを参照してください。
- 承認リクエストを有効にする（Enable approval requests）に切り替えます。
- 承認リクエストタイプを選択します。
- 承認を存続させる期間を選択します。
MFAの有効化（Enable MFA）
任意。MFAを有効にして、ポリシー内にきめ細かいレベルの認証と制御を追加します。
- MFAの有効化（Enable MFA）に切り替えます。
- 次のいずれかのオプションを選択します。任意の2要素タイプ（Any two-factor types）またはフィッシング耐性（Phishing Resistant）（Phishing resistant）。
- 次のいずれかの再認証頻度を選択します。
- ユーザーが警戒アクション取るたびに毎回（Every guarded action a user takes）：リソースへのアクセス試行のたびにMFAを実行します。
- 指定期間後（After the specified duration）：5分～12時間の範囲で期間を指定します。デフォルトは30分です。
ポリシーの実装後は、リソースへの接続を試みるユーザーは必要なMFAステップを完了する必要があります。
最大チェックアウト時間（Maximum checkout time）
任意。この時間制限は、このポリシー内でチェックアウトが有効化されているすべてのリソースに適用されます。
- プロジェクトレベルの最大チェックアウト時間をオーバーライド（Override the project-level maximum checkout time）に切り替えます。
- 量（Amount）と期間（Duration）を設定します。
- 手動（Manual）を選択した場合は、次の手順を実行します。
設定 アクション サービスアカウント権限
任意。次のいずれかを少なくとも1つ選択します。
- 表示する（Reveal）：ユーザーが資格情報を復号し、プレーンテキストで表示できるようにします。
- 更新（Update）：資格情報の値を変更する権限をユーザーに付与します。
保護アカウント（Accounts to protect）
1つ以上のアカウントを選択します。
承認リクエスト
任意。アクセスリクエストワークフローがセキュリティポリシーで表示されるようにするには、まず、Access Requestsでリクエストタイプを作成する必要があります。Okta Privileged Accessとアクセスリクエストを参照してください。
- 承認リクエストを有効にする（Enable approval requests）に切り替えます。
- 承認リクエストタイプを選択します。
- 承認を存続させる期間を選択します。
MFAの有効化（Enable MFA）
任意。MFAを有効にして、ポリシー内にきめ細かいレベルの認証と制御を追加します。
- MFAの有効化（Enable MFA）に切り替えます。
- 次のいずれかのオプションを選択します。任意の2要素タイプ（Any two-factor types）またはフィッシング耐性（Phishing Resistant）（Phishing resistant）。
- 次のいずれかの再認証頻度を選択します。
- ユーザーが警戒アクション取るたびに毎回（Every guarded action a user takes）：リソースへのアクセス試行のたびにMFAを実行します。
- 指定期間後（After the specified duration）：5分～12時間の範囲で期間を指定します。デフォルトは30分です。
ポリシーの実装後は、リソースへの接続を試みるユーザーは必要なMFAステップを完了する必要があります。
Active Directoryアカウントルールを構成する
特定のリソースグループにセキュリティポリシーが構成されている場合、Active Directoryアカウントとサーバーの両方が同じリソースグループに属している必要があります。属していない場合、RDPを介したリモートアクセスが失敗し、接続が成功しません。
Active Directoryアカウントルール（Active Directory account rule）を選択した場合は、次の手順を実行します。
| 設定 | アクション |
|---|---|
|
ルール名（Rule name） |
ルール名を入力します。 |
|
Accounts to protect（保護アカウント） |
注:
共有アカウントを名前で（Shared Accounts by Name）］は、アカウントを名前で一致します。アカウントが存在していなくても構いません。現在または将来その名前を持つすべてのアカウントが一致します。 特定のアカウントを選択すると、実際のアカウントとSIDを選択することになります。アカウントが削除された後、そのドメイン内に同じ名前で異なるSIDのアカウントが再作成された場合は、このポリシーと一致しなくなるため、そのアカウントを再度選択する必要があります。 |
|
アカウントの権限 |
次のいずれかのオプションを少なくとも1つ選択します。
|
|
セッションの記録 |
任意。セッションの記録を有効にするには、Oktaリソース管理者が事前にゲートウェイを登録およびインストールする必要があります。
トラフィック転送とセッションの記録を有効にすると、この条件はRDPセッションとSSHセッションの両方に適用されます。 |
|
承認リクエスト |
任意。アクセスリクエストワークフローがセキュリティポリシーで表示されるようにするには、まず、アクセスリクエストでリクエストタイプを作成する必要があります。Okta Privileged Accessとアクセスリクエストを参照してください。
|
|
MFAの有効化（Enable MFA） |
任意。MFAを有効にして、ポリシー内にきめ細かいレベルの認証と制御を追加します。
ポリシーの実装後は、リソースへの接続を試みるユーザーは必要なMFAステップを完了する必要があります。 注:
MFAを使用したユーザーの認証後に、10秒間の猶予期間が適用されます。この猶予期間中は、サインオンのたび（Every sign-on）が選択されている場合でも、Oktaはユーザーにパスワードの再入力を求めません。 この機能は、SAMLで構成されたすべてのアプリで利用できます。 SWAアプリでは再認証がサポートされないため、再認証が選択されている場合、サインオン方式をSAMLからSWAに変更することはできません。 |
|
最大チェックアウト時間（Maximum checkout time） |
任意。この時間制限は、このポリシー内でチェックアウトが有効化されているすべてのリソースに適用されます。
|
Oktaサービスアカウントポリシーのルールを追加する
このルールをOktaサービスアカウントポリシーに追加します。
-
に移動します。
- ルールを追加するポリシーを選択します。
- ルールを追加（Add rule）を選択して、次の手順を実行します。
設定 アクション ルール名（Rule name）
ルール名を入力します。
保護アカウント（Accounts to protect）
ラベルまたは名前によってリソースを選択できます。選択内容に応じて、その他の構成を行う必要があります。
アカウントを名前で選択する（Select accounts by name）
- アカウントを名前で選択する（Select accounts by name）に切り替えます。
- 1つ以上のアカウントを個別に選択します。
承認リクエスト
任意。アクセスリクエストワークフローがセキュリティポリシーで表示されるようにするには、まず、アクセスリクエストでリクエストタイプを作成する必要があります。Okta Privileged Accessとアクセスリクエストを参照してください。
- 承認リクエストを有効にする（Enable approval requests）に切り替えます。
- 承認リクエストタイプを選択します。
- 承認を存続させる期間を選択します。
MFAの有効化（Enable MFA）
任意。MFAを有効にして、ポリシー内にきめ細かいレベルの認証と制御を追加します。
- MFAの有効化（Enable MFA）に切り替えます。
- 次のいずれかのオプションを選択します。任意の2要素タイプ（Any two-factor types）またはフィッシング耐性（Phishing Resistant）（Phishing resistant）。
- 次のいずれかの再認証頻度を選択します。
- ユーザーが警戒アクション取るたびに毎回（Every guarded action a user takes）：リソースへのアクセス試行のたびにMFAを実行します。
- 指定期間後（After the specified duration）：5分～12時間の範囲で期間を指定します。デフォルトは30分です。
ポリシーの実装後は、リソースへの接続を試みるユーザーは必要なMFAステップを完了する必要があります。
注:MFAを使用したユーザーの認証後に、10秒間の猶予期間が適用されます。この猶予期間中は、サインオンのたび（Every sign-on）が選択されている場合でも、Oktaはユーザーにパスワードの再入力を求めません。
この機能は、SAMLで構成されたすべてのアプリで利用できます。
SWAアプリでは再認証がサポートされないため、再認証が選択されている場合、サインオン方式をSAMLからSWAに変更することはできません。
最大チェックアウト時間（Maximum checkout time）
任意。この時間制限は、このポリシー内でチェックアウトが有効化されているすべてのリソースに適用されます。
- プロジェクトレベルの最大チェックアウト時間をオーバーライド（Override the project-level maximum checkout time）に切り替えます。
- 量（Amount）と期間（Duration）を設定します。
- ルールを保存（Save rule）をクリックします。
- ポリシーを保存（Save policy）をクリックします。このポリシーを公開できるようになります。
関連項目
アクセスリクエストを持つ Okta Privileged Access