sudoコマンドバンドル

デフォルトでは、*nixオペレーティングシステムはユーザーレベルとスーパーユーザー（ルート）レベルの2レベルのユーザーアクセスをサポートします。sudoコマンドバンドルを使用することで管理者は、ユーザーに完全なルートアクセス権を与えることなく詳細な権限を付与できます。sudoを利用することでOkta Privileged Accessセキュリティ管理者は、ユーザーが別のユーザーとして実行できる、またはスーパーユーザー権限を使って実行できる具体的なコマンドを指定する階層化された権限システムを作成できます。

リソース管理者は、sudoコマンドバンドルを作成、変更、削除できます。セキュリティ管理者は、事前に作成されたsudoコマンドバンドルを使ってポリシールール内の個別アカウントの特定のアクセス方式タイプを指定できます。

sudoコマンドのタイプ

sudoコマンドには3タイプあります。

未加工（Raw）：このタイプのsudoコマンドでは、ユーザーは管理者がsudoコマンドの作成時に定義するコマンドのみを実行できます。管理者は、使用されるコマンドとして任意の入力を提供できます。ユーザーは、いかなる方法でもコマンドを変更できません。
ディレクトリ（Directory）：このタイプのコマンドでは、ユーザーは管理者がsudoコマンドの作成時に定義するディレクトリ内の任意のコマンドを実行できます。これは、/文字で定義されるルートディレクトリを含め、/で始まり、/で終わる文字列によって定義されるすべてのリーガルUNIXディレクトリです。
実行可能（Executable）：このタイプのsudoコマンドでは、ユーザーは管理者がsudoコマンドの作成時に定義する実行可能ファイルを実行できます。管理者は、このコマンドが引数としてAny、None、Specificを受け入れるかどうかを選択できます。このコマンドは、/文字から始まる文字列によって定義されたリーガルUNIXパスである必要があります。

sudoコマンドバンドルのルール

sudoコマンドバンドルは、次のルールに従います。

sudoコマンドバンドルを作成できるのは、Okta Privileged Accessリソース管理者のみです。
ターゲットサーバーに対するsudo権限をユーザーに付与するポリシーにsudoコマンドバンドルを追加できるのは、Okta Privileged Accessセキュリティ管理者のみです。
実行可能タイプのsudoコマンドも引数Any、None、Specificをサポートします。未加工およびディレクトリタイプのsudoコマンドでは、追加の引数を指定できません。
sudoコマンドバンドルは、実行するバイナリの完全ディレクトリパスを指定する必要があります。
sudoコマンドバンドルの名前には、空白文字を除くすべての英数文字を使用できます。
sudoコマンドバンドルの説明には、英数文字の任意の組み合わせを使用できます。

sudoコマンドバンドルの仕組み

Okta Privileged AccessユーザーがLinuxサーバーとのSSH接続の確立を試みると、利用できるアクセス方式のリストが示されます。sudoコマンド機能が構成され、ポリシー設定によってユーザーにsudoアクセス権が付与されていれば、そのユーザーは、求められる条件を満たしている限りsudoレベルのアクセス権でサインインできます。

次の例は、接続リクエストが各種セキュリティポリシーに基づいてどのように評価されるか、およびユーザーに示されるアクセス方式を示しています。

例

オンコールのSREエンジニアが特定のリソースに対するsudoアクセス権を3日間必要とするというシナリオを考えます。ON-CALLとSREは、sudoコマンドバンドルの集合の表示名であり、セキュリティポリシーに定義されます。SREにはsudoコマンドバンドル1、2、3が含まれ、ON-CALLにはsudoコマンドバンドル4、5、6が含まれます。

sudoと条件の両方が異なるセキュリティポリシー

セキュリティポリシー1：SREの下のsudoコマンドバンドルの集合にsudoレベルでアクセスするには、Access Requests条件とMFA条件が必要です。
セキュリティポリシー2：ON-CALLの下のsudoコマンドバンドルの集合にsudoレベルでアクセスするには、Access Requests条件とMFA条件が必要です。

sudoレベルのアクセス権を獲得するための次のアクセス方式が、ポリシーに基づいてユーザーに示されます。

The following access methods are available to access "S":

1: john.doe via SSH (sudo level individual account - SRE)
Conditions:
	Condition   Met?
	Approval    -
	MFA         -
2: john.doe via SSH (sudo level individual account - ON-CALL)
Conditions:
	Condition   Met?
	Approval    -
	MFA         -

sudoが同じで条件が異なるセキュリティポリシー（Security policies with same sudo and different conditions）

セキュリティポリシー1：SREの下のsudoコマンドバンドルの集合にsudoレベルでアクセスするには、Access Requests条件が必要です。
セキュリティポリシー2：SREの下のsudoコマンドバンドルの集合にsudoレベルでアクセスするには、MFA条件が必要です。

sudoレベルのアクセス権を獲得するための次のアクセス方式が、ポリシーに基づいてユーザーに示されます。

The following access methods are available to access "S":
1: john.doe via SSH (sudo level individual account - SRE)
Conditions:
	Condition   Met?
	Approval    -
2: john.doe via SSH (sudo level individual account - SRE)
Conditions:
	Condition   Met?
	MFA         -

sudoが同じで条件がないセキュリティポリシー（Security policies with same sudo and no condition）

セキュリティポリシー1：SREの下のsudoコマンドバンドルの集合にsudoレベルでアクセスするには、Access Requests条件が必要です。
セキュリティポリシー2：条件はなく、SREの下のsudoコマンドバンドルの集合へのsudoレベルのアクセス権を付与します。

sudoレベルのアクセス権を獲得するための次のアクセス方式が、ポリシーに基づいてユーザーに示されます。

The following access methods are available to access "S":
1: john.doe via SSH (sudo level individual account - SRE)

sudoコマンドバンドルの並べ替え順序

/etc/sudoers.d/ディレクトリ内のsudoコマンドバンドルを一覧表示すると、出力はsudoコマンドバンドル名に基づく辞書順配列で並べ替えられます。ファイル名は、<sudo_commands_bundle_name>-okta-<user_name>-<random_hash_value>という構造に従います。

辞書順配列の値の分析によって確立される並べ替え順序は、Linuxシステムの/etc/sudoers.d/ディレクトリ内のファイルの解析方法に類似しています。優先度は、まず0-9、次にA-Z、最後にa-zのシーケンスに基づきます。

たとえば、*nixシステムのsudoers.dディレクトリに定義されている次のファイルリストについて考えます。


01_abc_nginx-okta-user_name-d6e13ad78522b789a7f510eae4dbdc73
ABB_nginx-okta-user_name-de67ee27c291c25adb659937b1407368
01_ABc_nginx-okta-user_name-de67ee27c291c25adb659937b1407368
xyz_nginx-okta-user_name-de67ee27c291c25adb659937b1407368
01_FULL_NGINX-okta-user_name-d8cb7fddad549121afcf00d25fb75a36
01_full_nginx-okta-user_name-348c6f1a9070b4e1c4a65234ce223dbe
012_nginx-okta-user_name-de67ee27c291c25adb659937b1407368

ファイルは次の順序でリスト表示されます。


user@12345:/etc/sudoers.d$ sudo visudo -c
012_nginx-okta-user_name-de67ee27c291c25adb659937b1407368: parsed OK
01_ABc_nginx-okta-user_name-de67ee27c291c25adb659937b1407368: parsed OK
01_FULL_NGINX-okta-user_name-d8cb7fddad549121afcf00d25fb75a36: parsed OK
01_abc_nginx-okta-user_name-d6e13ad78522b789a7f510eae4dbdc73: parsed OK
01_full_nginx-okta-user_name-348c6f1a9070b4e1c4a65234ce223dbe: parsed OK
ABB_nginx-okta-user_name-de67ee27c291c25adb659937b1407368: parsed OK
xyz_nginx-okta-user_name-de67ee27c291c25adb659937b1407368: parsed OK