Settings > Administration > Administrators & Rolesページ > Administratorsタブでは、組織用に設定されているすべての管理者の一覧を確認できます。
各管理者について、以下の情報が表示されます。
- Name: ユーザー/招待者の電子メールまたはユーザー名。
- Statusユーザーが招待を承諾したかどうかに基づいて、「アクティブ」または「保留中」のオプションを表示します。
- Type: 管理者の役割の種類（ユーザーまたはサービスアカウント）を表示します。
- Provisioned By: 管理者ユーザーを作成したユーザー/ロールの種類（ローカル、SCIM、またはSAML）。
- Role: 管理者の機能領域へのアクセスレベル、ページ権限、およびファイルアクセス権限。これは選択された役割であり、事前に定義された役割、またはカスタム役割のいずれかを選択できます。
- API CredentialREST APIトークンのステータス、トークンの有効期限、トークンの生成/変更/取り消しオプションを表示します。
- MFA: 無効/有効の状態を表示します。
- Last Login: ユーザーの最終ログイン日時。
- Auth: 管理者が認証された方法、例:APIキーなど
- Ellipses: クリックすると、管理者の編集/無効化、トークンの生成/変更/取り消し、または管理者リストからのユーザーの削除ができます。
管理者リストをfilterするには、次の方法があります。
- 名前
- Role
- プロビジョニング元（ローカル、SCIM、またはSAML）
- 種類（ユーザーアカウントまたはサービスアカウント）
Clear all filtersをクリックするとフィルターの選択が解除され、 Clear and remove all filtersをクリックすると選択が解除され、フィルターバービューからフィルターが削除されます。
Tenant Admins
ロールベースアクセス制御（RBAC）V3では、 Tenant Adminはテナント/アカウント内で最高レベルの管理権限を持ち、他の管理者やロールを管理する機能も含まれます。しかし、ユーザーがロールを作成または複製しようとすると、コアロールTenant Admin以外のすべてのロールに対して、権限“Administration > Admins > Manage”は意図的に無効になります。
これは、権限昇格を防止するために設計された重要なセキュリティ機能です。
The Purpose of the Security Control
この動作の主な理由は、安全で堅牢なRBACフレームワークを維持するためです。他の管理者や役割を管理する機能は、事前に定義されたTenant Admin役割にのみ与えられる特別な特権です。この制限はRBAC V3設計の基本原則であり、テナント管理者ロールから派生したロールだけでなく、ユーザーが作成または複製したすべてのロールに適用されます。
このセキュリティ対策が実施されている理由は以下のとおりです。
- Preventing Privilege Escalation: ユーザーが新しい役割を作成し、他の管理者や役割を管理する権限を付与できる場合、潜在的な抜け穴が生じる可能性がある。悪意のある攻撃者は、この権限を持つ新しいロールを作成し、それを使用してさらに高い権限を持つ新しいユーザーまたはロールを作成し、セキュリティ制御を事実上バイパスする可能性があります。 これにより、権限のないユーザーに完全な管理者アクセス権限を付与することが可能になる。
- Maintaining a Secure Hierarchy: RBAC V3モデルは、明確かつ安全な階層構造で設計されています。テナント管理者ロールは、テナント/アカウントのルート管理者として機能します。他の、管理権限が比較的弱い役割の人に管理者の管理を任せると、この構造が損なわれ、管理権限の追跡と管理が困難になるだろう。
- Ensuring the Integrity of the RBAC System: 「管理」権限を元のテナント管理者ロールに限定することで、システムはユーザーとロールの作成に関する基本的な制御が信頼できる、侵害されていない状態に維持されることを保証します。これにより、非標準ロールまたはクローンロールを持つユーザーがRBAC制御を無効にすることを防ぎます。
Expected Behavior
- “Administration > Admins > Manage”権限を持つ唯一の事前定義されたロールはTenant Adminです。
- 他のロールが作成または複製されると、 “Administration > Admins > Manage”権限はgrayed out and disabledになります。これは、権限昇格を防ぐための意図的な設計上の選択です。
この設計により、指定されたテナント管理者のみが新しい役割の作成やユーザーアカウントの管理といった重要な機能を実行できるようになり、システム全体の整合性が保護されます。
ローカルユーザーアカウント
ローカルユーザーアカウントページにアクセスするには、 Settingsをクリックしてください。
- Max Failed Login Attempt管理者ユーザーがUIからロックアウトされるまでに許可されるログイン試行の最小回数を指定します。最低3回のログイン試行が必要です
- Idle Timeoutセッションがタイムアウトする頻度を設定します。最小値は5分、最大値は60分です。
- Password Expirationパスワードの有効期限を設定します。
- Allow concurrent logins by the same admin同じ管理者による同時ログインを禁止するには、チェックボックスを選択してください。つまり、管理者が別のブラウザインスタンスからログインした場合、最初のブラウザセッションからはログアウトされます。
- Verification Link Validity: 認証リンクの有効期間（時間または分）を設定します。
ローカルユーザーとSSOユーザーの移行
ケースによっては、同じ電子メール アドレスを持つローカル ユーザーと SSO ユーザーが存在する場合があります。 ローカルログインとSSOログインの両方を持つユーザーがいる場合、RBAC V3への移行後、「プロビジョニング者」はLocalになります。UIの「役割」列に表示される役割は、ローカルユーザーに割り当てられた役割です。
REST API認証設定
Settingsをクリックして、REST API認証設定ページにアクセスしてください。
選択肢にはAPI Key経由が含まれます。
または OAuth 2.0
新しい管理者を招待する
Settings > Administration > Administrators & Rolesページ > Administratorsタブに移動 > Inviteをクリックします
招待ページが表示されます。
- 新しい管理者の電子メールを入力します。 新しい管理者の電子メール ドメインが管理者アカウント ドメインの一部であることを確認します。
- ドロップダウンリストから役割Select 。 ヒント：管理者を招待する前に、その役割が存在することを確認してください。
- 必要に応じて、管理者に対して多要素認証（MFA）を有効にします。
- 「完了」をクリックしてください。
Netskope 、アカウント アクティベーション URL を含む確認電子メールを送信します。
新しい管理者ユーザーは、アカウント認証プロセス中にパスワードを変更できます。
ユーザーは、パスワードを変更することに加えて、ワンタイムパスワード（OTP）が記載された2つ目のメールを受け取ります。
管理者アカウントは、アカウント認証が完了次第有効化されます。
設定画面に移動して、認証期間を設定してください。管理者がローカルアカウントのパスワードを作成またはリセットすると、ユーザーは確認リンクを受け取ります。 認証リンクの有効期間を設定できます。最短は15分、最長は72時間です。
新しいサービスアカウントを作成する
サービスアカウントを使用すると、管理者は非対話型の管理者アカウントを作成できます。 REST API と連携します。
Settings > Administration > Administrators & Rolesページ > Administratorsタブに移動 > Service Accountをクリックします
[新しいサービス アカウント] ページが表示されます。
- サービスアカウントの名前を入力してください。
- ドロップダウンリストから役割Select 。 ヒント：サービスアカウントを作成する前に、その役割が存在することを確認してください。
- 必要に応じて、REST APIトークンを生成し、有効期限を日数で設定できます。
- 必要に応じて、後でトークンを生成するためのチェックボックスを選択してください。
- Createをクリックしてください。
後で上記の手順4からトークンを生成するには、管理者リストページに移動し、行末にある省略記号をクリックします。
Understanding Authentication サービスアカウントの場合
Service Accountロールを持つアカウントでは、「多要素認証を有効にする」（MFA）オプションは表示されません。これは意図的なものです。
- Admin Accounts は 人間がユーザーにログインします 。 彼らは とパスワードで認証を行い、その対話型ログインに追加のセキュリティ層としてMFAを適用できます。
- Service Accounts 対話型ではない。これらはdo not Netskope APIへのプログラムによるアクセスと、UIへのログインのために設計されています。パスワードとMFAの代わりに、彼らは認証します 安全で取り消し可能なAPI token 。
サービスアカウントにはパスワードがなく、UIにログインできないため、従来の多要素認証は適用できません。セキュリティは、APIトークンの適切な管理と保護によって維持されます。