mcpField
U
uipath-admin

uipath-admin

github.com/uipathセキュリティ17549 回インストール今日更新
リポジトリ

uipath-admin について

uipath-adminは、UiPathのアイデンティティ、認可、テナント運用、IP制限、監査を扱うエージェントスキルです。対象とスコープを確認してから変更し、結果を検証する手順を重視します。

主な機能

  1. 01ユーザー、グループ、ロボットアカウントの管理
  2. 02カスタムロールと割り当ての設定
  3. 03テナントとサービスのライフサイクル管理
  4. 04IP制限ルールの管理
  5. 05監査イベントの検索とエクスポート
  6. 06アイデンティティとアクセスの障害調査

活用シーン

  1. 01アクセス拒否やロール未反映の調査
  2. 02不審なサインインと監査イベントの確認
  3. 03テナントサービスと操作状態の管理
  4. 04IPロックアウト、PAT、SMTPの問題調査

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/uipath/skills --skill uipath-admin

インストール後、Claude Code で/uipath-adminを入力して読み込まれたか確認します。

同梱ファイル

SKILL.md と一緒にインストールされる参考資料やスクリプト。

references/
audit-commands.md
audit-exclusions-guide.md
audit-workflow-guide.md
external-app-management.md
group-management.md
identity-commands.md
identity-troubleshoot-guide.md
key-concepts.md
organization-management.md
organizations-commands.md
pat-management.md
robot-account-management.md
smtp-management.md
tenant-management.md
tenants-commands.md
user-management.md
references/authorization/
authorization-commands.md
check-access.md
grant-permissions.md
permission-catalog.md
role-assignment-management.md
role-management.md
references/diagnose/
CAPABILITY.md
failure-modes.md
troubleshooting-guide.md
references/ip-restriction/
bypass-rule-management.md
enforcement-management.md
ip-range-management.md
ip-restriction-commands.md

詳細

UiPath Admin

Identity Server、Authorization、OMS、IP Restriction、Audit に対する管理操作を uip admin で実行します。

使用する場面

  • Identity: ユーザー、グループとメンバーシップ、ロボットアカウント、外部アプリと認証情報、PAT、SMTP、OAuth2 スコープの検出、人またはロボットのオンボーディング。
  • Authz: カスタムロール、割り当て、権限カタログ、有効なアクセス権限、アドホックな権限付与。ロールのスコープは Organization、TenantGlobal、Tenant、Project です。割り当てでは Folder または App も使用できます。
  • OMS: 現在の組織、テナントのライフサイクル、サービスのプロビジョニング、操作のポーリング、リージョンの検出。CLI では組織を作成または削除できません。
  • IP Restriction: 許可リストのエントリ、適用、バイパスルール、およびパブリック IP に関する質問や安全性の確認に使う ip-restriction my-ip。
  • Audit: 組織またはテナントの監査イベント、ソース、ターゲット、種類、クエリ、ログイン履歴、メンバーシップ/ライセンスのアクティビティ、テナントのアクティビティ、調査、エクスポートには、uip or audit-logs ではなく uip admin audit を使用します。uip or audit-logs は Orchestrator の運用監査用であり、uipath-platform に属します。
  • 監査の除外: 一致するイベントの記録を停止するルールには、uip admin audit org exclusions を使用します。「これらのイベントの記録を停止/抑制/ミュートしたい」、「監査証跡のノイズが多すぎる」、「記録していないイベントを知りたい」、または除外ルールの一覧表示/取得/作成/更新/削除に関するリクエストが該当します。組織スコープのみです。書き込み操作はすべて証跡を抑制するため、audit-exclusions-guide.md とルール 30b~30e に従ってください。
  • トラブルシューティング: アクセス、認証、ID、テナント操作、プロビジョニング、ロボット認証、SMTP、PAT、外部アプリ、または IP ロックアウトに関する症状には、診断機能のインデックス とID トラブルシューティングガイドを使用します。

監査が利用可能かどうかを確認するには、uip admin audit <scope> sources を実行します。記憶に頼らず、最新のカタログを検出してください。audit-workflow-guide.md → Audit scope disambiguation とルール 23 に従って、org と tenant を使い分けてください。自然言語による調査では、リソースの変更/削除、サインイン、テナントの変更、コンプライアンス期間、複数スコープにまたがるリクエストを扱えます。要求されたスコープごとに 1 回ずつ実行し、結果をまとめてください。

トラブルシューティングのルート:アクセス拒否(403)、「ロールが反映されない」、サービス間でのロールの混同はすべて 1 つのシナリオです → プリンシパルを特定し、有効なアクセス権限を確認し、必要な権限を調べたうえで、権限不足とスコープの誤った付与を切り分けます(Playbook 1、失敗モード → アクセス拒否)。不審なログイン → 組織監査(Playbook 2)。IP ロックアウト → my-ip、範囲、適用(Playbook 3)。PAT/外部アプリの失敗 → 有効期限、スコープ、取り消しの監査(Playbook 4)。SMTP には smtp get と smtp test を使用します。停止したテナント操作はポーリングしてください。プロビジョニングが何も行わない場合は、プラットフォームで固定されたサービスを確認してください。ロボット ID の問題と認証情報モデルの問題を区別してください。

重要なルール

各ルールはエージェントとの契約の一部です。

全般
  1. 適切なコマンドに振り分けます: Orchestrator 固有のロール/権限に関するリクエストには、uip admin authorization ではなく uip or roles(uipath-platform)を使用します。組織/テナントの監査には、監査履歴、エクスポート、ログイン履歴、コンプライアンスダンプ、「誰がどこで何をしたか」を含め、必ず uip admin audit <scope>(sources、events、または export)を使用し、uip or audit-logs は使用しません。
  2. まずログイン状態を確認します: uip login status --output json を実行します。未認証の場合は中止し、ユーザーに uip login の実行を依頼します。このコマンドはブラウザーでの対話型フローを開始するため、自動化セッションや非対話型セッションでは実行してはいけません。環境認証済みのセッションは、すでにログイン済みです。アクティブなセッションから組織を特定します。
  3. すべてのコマンドで --output json を使用します。 プログラムで解析し、会話形式で提示します。
  4. エラーが発生したら中止し、エラーをそのまま表示します。 認証エラーを再試行してはいけません。ユーザーに uip login の実行を依頼します。
  5. リスクの高い操作の前に、名前で指定されたプリンシパルを特定します: ユーザー、グループ、ロボットアカウント、外部アプリが対象です。割り当ての作成/削除、ユーザー/グループの削除、メンバーシップの変更、ロボットの削除、外部アプリの削除、シークレットの生成も含まれます。まず検索し、Principal: <displayName> (<userName>) — <id> の形式で確認結果を表示します。一致する項目がない場合は中止してユーザーに確認します。一致する項目が複数ある場合は、番号付きリストを表示して数字の入力を待ちます。現在ログインしているユーザーで代用してはいけません。プリンシパル ID の解決を参照してください。
アイデンティティ
  1. 作成前に確認します: ユーザー招待を除き、まずロボットアカウント、グループ、外部アプリを一覧表示します。
  2. シークレットを表示するのは一度だけです: 外部アプリの作成時と generate-secret の実行時に限ります。すぐに保存するようユーザーに伝えます。
  3. 外部アプリには作成スコープが必要です: --app-scope または --user-scope を指定します。例:--app-scope "OR.Folders"。
  4. グループメンバーシップにはユーザー ID を使用します: ルール 5 に従ってユーザーを特定してから、groups members add/revoke を使用します。
  5. 対象を特定してから、ユーザー、グループ、ロボットアカウント、外部アプリの削除を確認します。 組み込みグループ(type: "BuiltIn")は削除できません。削除できるのは Custom グループのみです。
Authz
  1. 組み込みロールは読み取り専用です。 作成/更新/削除できるのは Custom ロールのみです。CLI はサービス管理またはプラットフォームレベルのロール作成を拒否します。詳しくは、独自のロールを管理するサービスを参照してください。
  2. roles create/update は PUT スタイルのアップサートです。 フラグと --file ./actions.json から本文を作成します。省略したフラグはフィールドを上書きするため、更新前に必ず roles get を実行してください。
  3. --service はスコープを推定します(例:studio → Tenant、apps → Organization)。上書きが必要な場合にのみ --scope を使用してください。serviceName を推測してはいけません。有効な値と再導出コマンドについては、permission-catalog.md → serviceNamesを参照してください。
  4. 一覧表示はすべてのサービスに対応しますが、ロール作成は対応していません。 roles list --service <svc> と roles assignments list --service <svc> はすべてのサービスを受け付けます。実効アクセス権の確認には check-access を使用してください。
  5. スコープの語彙はコマンドによって異なります。 roles create --scope は Organization|TenantGlobal|Tenant|Project、assignment create はこれに Folder|App を追加し、assignment list は TenantGlobal を除外します。check-access --scope がサポートするのは Tenant|Folder のみです。
  6. Assignment の作成/削除には、ルール 5 に基づくプリンシパルの解決が必要です。 --identity-id は検証されない生の UUID です。
  7. Assignment の所有者はスコープパスと一致している必要があります。 パスのサービスセグメントは lowercase(ownerServiceName) で、ロール自身の roles get の値をそのまま使用します。たとえば DocumentUnderstanding は /tenant/<tid>/documentunderstanding です。CentralizedAccess にはサービスセグメントがありません(/ または /tenant/<tid>)。別のサービスのセグメントで代用したり、別のロールの付与情報からコピーしたりしてはいけません。Reinfer(表示名は IXP)は Document Understanding ではありません。表示名の対応関係を適用するのはユーザー向けの文章のみであり、パスには適用しません。不一致を修正するには、--service <slug> または --scope-path "/tenant/<tid>/<slug>" を指定して Assignment を再作成してください。Tenant スコープのロールにはプロジェクトセグメントは不要です。詳しくは、ロールの所有サービスを検証するを参照してください。 17b. スコープが誤って設定された付与情報はデフォルトの一覧には表示されません。--scope-path で取得してください。 roles assignments list は、指定したフラグからスコープパスと serviceName の両方を固定します。そのため、<svc> 所有のロールが /tenant/<tid> に付与されている場合、デフォルトのどの形式にも一致せず、スコープパスを指定しない一覧、--identity-id、--scope Tenant(--include-inherited の有無を問わず)、--service <svc> のいずれにも表示されません。roles assignments list --scope-path "/tenant/<TENANT_ID>" --output json を --service なしで実行して取得してください。一覧が空でも付与情報が存在しない証拠とはみなさず、それを根拠に Assignment を再作成してはいけません。再作成すると、元の不一致が繰り返されます。詳しくは、アクセス拒否 → 原因 Bを参照してください。
OMS
  1. 非同期ライフサイクル:自動ポーリング後に引き継ぎます。 テナントの作成/更新/削除/有効化/無効化では operationId が返されます。organizations operation get <OP_ID> を5秒間隔で3回ポーリングし、終端ステータスになったら停止します。その後も処理中の場合は、番号付きメニューを提示します。無期限にループしてはいけません。組織の作成/削除はCLIでは利用できず、Portal/サポートが必要です。ポーリング手順を参照してください。
  2. tenants delete はソフト削除のみです。 復元にはサポートが必要です。ハード削除フラグはありません。
  3. テナントコマンドは、ログイン中のテナントをデフォルトで対象にします。 テナントの削除/無効化と tenants services remove では、必ず明示的に <TENANT_ID> を指定してください。
  4. テナント作成前にリージョンを確認してください: organizations regions list を先に実行してください。--region は必須で、リージョンに応じた設定が必要です。
  5. サービスの無効化/削除では、誤って Success と報告されることがあります。 必ずその後に一覧を再取得してください。テナントの概念を参照してください。
Audit
  1. クエリの前に、org と tenant のどちらかを明確にしてください。 曖昧で、直前のやり取りでもスコープが確定していない場合は、AskUserQuestion が利用可能であれば、それを使って確認の質問を1つしてください。暗黙のうちに既定のスコープを選ばないでください。対話形式で確認できない場合は、両方をクエリして結果を統合してください。スコープは位置で指定します。例:uip admin audit org sources または uip admin audit tenant events。--scope は無効です。監査スコープの曖昧さの解消を参照してください。
  2. イベントの戻り値は {auditEvents, next, previous} であり、配列そのものではありません。 Data.auditEvents[] を読み取ってください。next は新しいイベント、previous は古いイベントを示し、最新から過去へたどる場合は previous を使います。
  3. --limit は内部でページネーションを行います。 ページネーションのために日付を繰り返し指定しないでください。サーバーへの各リクエストの上限・下限は [10, 200] で、CLI の上限は 10000 です。--limit は [1, 10000] の範囲で指定してください。10000 を超えると Result: "ValidationError" が返されます。「すべて」を取得する場合は、省略するか範囲内に収めてください。
  4. 最初に audit <scope> sources を実行してください。 ソース、ターゲット、タイプの GUID を捏造せず、ライブカタログにある GUID を使ってください。このレスポンスで利用可能かどうかも確認できます。
  5. イベントの期間は UTC の ISO 8601 形式で指定してください。 ノイズの多いテナントには、--from-date と --to-date を指定せずにクエリしないでください。2026-04-01T14:30:00Z のような日付のみ、またはタイムスタンプ形式を受け付けます。--to-date は指定した時刻ちょうどまでを含みます。最終日を丸一日含めるには、翌日の開始時刻か T23:59:59.999Z を使ってください。相対日付は推測せず、実際の UTC 時刻(date -u)を使って確定し、期間を明示してください。 27b. 対象を絞ったクエリの結果が空なら、それをもって完了です。 スコープ、フィルター、期間を示し、一致するイベントが見つからなかったことを伝えてください。対象を広げる、もう一方のスコープを調べる、またはリソースの存在を確認する方法を提示してください。隣接するリソース、イベントタイプ、広範な検索結果から実行者を推測してはならず、原因となった対象を見つけるためだけにフィルターを緩めてはなりません。一致するイベントが、要求されたリソースと動詞の両方を裏付ける場合に限り、実行者を示してください。createdOn と、識別に必要な eventDetails を引用してください。ステップ5を参照してください。
  6. org 監査では --tenant-id は無視されます。 代わりに audit tenant を使ってください。
  7. 監査で 401 が発生した場合は、再試行しないでください。 トークンに Audit.Read がありません。uip logout && uip login を実行するようユーザーに伝えてください。 29b. 一時的な監査の 5xx エラー(ErrorCode: server_error/Retry: RetryLater、例:503/504)は、同一のクエリを使い、数秒の間隔を置いて最大2回まで再試行してください。limit や期間を変更しないでください。エラーのエンベロープをデータとして表示または保存してはなりません。取得に失敗したことを報告してください。
  8. エクスポートでは、ベースディレクトリと UTC の暦日全体を指定します。 --from-date、--to-date、--output-path を必須とします。日付は暦日単位で両端を含み、イベント取得時の「翌日」方式は使わないでください。--output-path はディレクトリであり、ファイル名や拡張子ではありません。CLI はその中に audit_<from>_<to>_<generated-at> を作成します。デフォルトの JSON では日ごとに <YYYY-MM-DD>.json が作成され、--file-format csv では結合された CSV が1つ作成されます。表計算ソフトで扱うフラットなデータには CSV、日ごとのファイルには JSON を使ってください。ユーザーが名前を指定した保存先は確認せず、そのまま渡してください。./audit-exports など、選択されたデフォルトの保存先の場合に限り、確認してください。Path と GeneratedAt を報告してください。 30b. 除外ルールは組織スコープであり、ルールには何らかの制約が必要です。 uip admin audit org exclusions <list|get|create|update|delete> を使用します。audit tenant exclusions はありません。--exclude-tenant セレクターを使って、ルールをテナントに限定してください。各ディメンションで指定できるセレクターは1つです。--exclude-tenant、--source、--target、--type はそれぞれ複数回指定でき、--status は単一値(Success または Failure)です。テナントセレクターは --exclude-tenant であり、--tenant-id ではありません — このフラグは読み取り系の動詞で「このテナントに対して実行する」という意味であり、ここでは使用できません。セレクター内の値は OR で結合され、セレクター同士は AND で結合されます。少なくとも1つのセレクターが必要です。何も制約しないルールは組織内のすべてのイベントを除外するため、曖昧な「監査ノイズを抑えて」という依頼に応じて、そのようなルールを作成してはいけません。セレクターの GUID は audit org sources で確認し、決して推測してはいけません(ルール26)。enforcement はフラグではありません — 使用できる値は Exclude のみです。ルール名に GUID だけを指定することはできません。audit-exclusions-guide.md を参照してください。

30c. 除外に関する書き込みはすべて証拠を抑制します — 影響を説明し、事前に明示的な確認を得てください。 create、update、または delete の前に、audit org sources から取得した名前にセレクターを置き換えてルールを表示し(GUID だけを表示してはいけません)、次のように説明してください。ルールが有効になると除外が開始され、遡及適用はされません。すでに記録されたイベントには影響しません。その後に抑制されたイベントは復元できません。ルールを削除すると記録は再開されますが、記録されなかった期間の欠落は復元されないためです。ユーザーの確認を待ってください。ユーザーが求めた範囲を超えてルールを広げてはいけません。また、RuleLimitExceeded や OverlappingRuleExists を回避するために、自分が作成していないルールを削除してはいけません。書き込みを連続して実行してはいけません。ルールを1つ作成し、exclusions get で確認して、PolicyId と ActivatedOn を報告したら終了してください。

30d. exclusions update はパッチではなく全置換であり、再有効化も行われます。 get、update、delete は、ルールの名前またはポリシー ID を指定できる位置引数 <rule> を1つ受け取ります。ユーザーが指定した名前を優先し、セレクターフラグより前に <rule> を渡してください。セレクターフラグは可変長引数であり、先に渡すと別の値として解釈されるためです。まず exclusions get "<RULE>" --output json を実行してから、ルールに残すすべてのセレクターを再指定してください。省略したフィールドは削除されるため、--name だけで名前を変更すると、ルールのセレクターがすべて削除されます。有効化状態も置換の対象です。 --inactive を指定しないと、ルールは再び有効になります。そのため、意図的にステージングしていたルールを置き換えると、イベントの抑制が開始されます。get で IsActive を確認し、値が false だった場合は、再度 --inactive を指定してください。--file を指定すると本文全体を渡すことになり、インラインフラグとは併用できません。本文に含められるのはキャメルケースの name、enforcement、isActive、selectors のみです(isActive を省略した場合は true がデフォルトになります)。そのため、PascalCase でサーバー管理の policyId とタイムスタンプを含む get の応答は、項目を削除しても受け付けられません。記録の空白期間を作らずにルールを入れ替えるには、置き換えるルールを --inactive でステージングし、古いルールを削除してから、新しいルールを有効化してください。 30e. 除外ルールの失敗には原因が明示されます。推測せず、Instructions に従ってください。 拒否された場合、Message にサービス側の理由が、Context.errorCode に機械可読コード(OverlappingRuleExists、UnknownSelectorValue、SelectorValueNotPermitted、DuplicateRuleName、…)が含まれます。ローカルの Result: ValidationError(終了コード 3)はネットワークに到達していないため、再試行するのではなく、コマンドを修正してください。<rule> の名前が有効なルールと無効なルールの両方に一致する場合、CLI は推測しません。 両方のポリシー ID を示す ValidationError を返します。どちらかをユーザーに確認するか、ID を指定してください。有効なルールを既定で選んではいけません。もう一方のルールが、まさにステージング中の置き換え対象である可能性があるためです。SelectorValueNotPermitted は仕様です。UiPath の監視イベントや監査構成の変更(ルール自体の変更を含む)は、除外できません。対象の表記を変えて再試行せず、拒否されたことを報告してください。unknown command 'exclusions' は、インストール済み CLI がこの機能に対応するより前のバージョンであることを意味します(@uipath/cli のアップグレードをユーザーに伝えてください)。list での HTTP 404 は、この組織の監査サービスがまだルール API を公開していないことを意味します。どちらも再試行しても解決せず、uip or audit-logs にフォールバックする理由にもなりません。有効なルールは events と export から該当イベントを隠しますが、その欠落は示されません。 対象を絞った調査で結果が空の場合、アクションが行われなかったと結論付ける前に exclusions list を実行してください(これは結果が空である理由を説明するものであり、実行者の名前を特定する根拠にはなりません。ルール 27b)。

IP 制限
  1. 強制適用を有効にする前に安全確認と確認応答が必要です。 ip-restriction my-ip を実行し、呼び出し元の IP が ip-ranges list に含まれていることを確認してから、次のように伝えてください。「IP 制限を有効にすると、送信元 IP が ip-ranges list に含まれていない呼び出し元(Portal、CLI、ロボット、外部アプリ)は、この組織へのアクセスをブロックされます。設定を誤るとアクセスできなくなり、プラットフォーム側での復旧が必要になります。続行しますか?」--confirm を必須にしてください。強制適用が有効な状態で範囲を削除する場合も、--confirm が必要です。強制適用の管理を参照してください。
  2. IP 制限によるロックアウトからの復旧はプラットフォーム側で行います。 許可リストに登録された IP から強制適用を無効にするか、Portal の復旧手順を使用してください。CLI での回避手段はありません。
  3. 「APMS」は決して表示しないでください。 ユーザー向けの出力では「IP 制限」と表記してください。
  4. 認可エラーを回避するために権限を変更してはいけません。 403(または「認可されていない」という結果)が返った場合は、原因を診断して報告してください。不足しているスコープ、グループ、トークンの種類を示したうえで、停止してユーザーの判断を待ってください。コマンドを成功させるために、ユーザーをグループに追加したり、グループから削除したり、ロールを割り当てたり編集したり、権限を拡大したりしてはいけません。一時的な変更や、直前に行った変更を「元に戻す」ためであっても同様です。権限の取り消しは、ユーザーがすでに持っていたアクセス権の削除と区別できません。グループ、ロール、権限への書き込みが認められるのは、ユーザーが依頼したタスクそのものが、そのメンバーシップまたは権限の変更である場合に限られます。

避けるべきこと

  1. リソース ID をフラグとして渡さないでください。 ID と名前は位置引数です。たとえば、groups members add <GROUP_ID> --user-ids ... のように指定します。このルールは get/update/delete/create コマンドにも適用されます。
  2. 出所を示さずに認可結果を提示しないでください。 ロール名、scopeType、ownerServiceName、および UUID ではなく名前を使ったテナントの紐付けを示してください。出所の契約を参照してください。

その他は重要ルールの逆です。以下は決して行わないでください。

  • 403 を回避するために、グループへの追加、グループからの取り消し、ロールや権限の編集を行うこと(R34)。
  • 組織/テナントの監査に uip or audit-logs を使うこと(R1)、または曖昧な場合に監査スコープをデフォルト設定すること(R23)。
  • audit events を単なる配列として扱うこと(R24)、日付を手動でループしてページネーションすること(R25)、ソース/ターゲット/タイプの GUID をでっち上げること(R26)、またはイベントの多いテナントで範囲を限定せずにクエリすること(R27)。
  • クエリ結果に含まれていないアクターを名前で示すこと(R27b)、org 監査に --tenant-id を渡すこと(R28)、401 を再試行すること(R29)、またはエラーエンベロープをデータとして保存/報告すること(R29b)。
  • export で翌日を --to-date に指定する手法を使うこと(R30)、または変更したフラグだけで roles update を実行すること(R12)。
  • audit tenant exclusions を使うこと、セレクターのない除外ルールを作成すること、またはセレクター GUID をでっち上げること(R30b)。
  • 影響を明示して確認を得ずに除外ルールを作成すること、または遡及的に適用されるものとして提示すること(R30c)。
  • 除外コマンドに --tenant-id を渡すこと、または --status を 2 回指定すること(R30b)。
  • 変更したフラグだけで exclusions update を実行すること、ステージング済みのルールを置き換えるときに --inactive を省略すること、--file とインラインフラグを併用すること、または get のレスポンスを --file に渡すこと(R30d)。
  • SelectorValueNotPermitted による拒否や、exclusions の unknown command/404 を再試行すること、または <rule> の名前が曖昧な場合に自分でルールを選ぶこと(R30e)。
  • プロビジョニング済みの services list と list-available カタログを混同すること(R22)、または解決されたターゲットを表示せずに OMS の変更を実行すること(出力の作法)。

クイックスタート

目的開始点
ユーザーを招待してグループに割り当てるuser-management.md、group-management.md
カスタムロールを作成するuip admin authorization roles create --scope <Organization|TenantGlobal|Tenant|Project> --name "<NAME>" --file ./actions.json --output json
権限を付与するgrant-permissions.md
ロールを割り当てるプリンシパルを解決する;roles get を実行する;所有者サービス/パスを検証する;割り当てを作成する
有効なアクセス権を確認するuip admin authorization check-access <USER_GUID_OR_EMAIL> --scope <Tenant|Folder> --output json
テナントを作成するtenant-management.md
テナントサービスを追加するtenants services list-available --region <R> を実行する;追加する;事後状態を確認する
パブリック IP を確認するip-restriction my-ip --output json を実行する;Data.ipAddress を返す
IP 強制を有効にするmy-ip → 範囲を確認する → enforcement enable --confirm
監査をクエリ/エクスポートするaudit-workflow-guide.md
ノイズの多い監査イベントの記録を停止するaudit org sources → 提案して確認を得る → uip admin audit org exclusions create --name "<RULE_NAME>" --type <EVENT_TYPE_ID> --status Success --output json → exclusions get "<RULE_NAME>" で確認する(ルール 30b~30e、audit-exclusions-guide.md)
抑制されている監査イベントを確認するuip admin audit org exclusions list --output json

重要な概念

組織階層と、ユーザー、グループ、ロボットアカウント、ロボット資格情報、外部アプリの違いについては、key-concepts.md を参照してください。

出力の作法とレポートの契約

領域必須の出力
ID の変更結果と新しいリソース ID を示します。外部アプリ用の一度しか表示されないシークレットを強調し、保存するよう警告したうえで、関連する次のステップを提示します。
Authz の読み取り/変更応答からロール名、scopeType、ownerServiceName を示し、該当する場合は表示名を翻訳し、テナントのバインド先は名前に解決して示します。check-access では、ネストされた roleAssignments[].securityPrincipalType を使って、各行に direct または inherited from <Group name> のラベルを付けます。Provenance contract を参照してください。
OMS の読み取り先頭に Organization: <ORG_NAME> を示します。プロビジョニング済みサービスはステータス付きで、利用可能なカタログとは分けて示します。テナントの読み取りでは、名前、UUID、ライフサイクルステータスも表示します。
OMS の変更解決済みの対象を明示します。非同期操作は 5 秒間隔で 3 回自動ポーリングし、その後、番号付きメニューを提示します。同期サービスは状態を確認するため、再度一覧表示します。
監査クエリ/エクスポートスコープ、件数、解決済みの UTC 時間範囲、フィルター、カーソルの状態を示し、ルール 23、26、27 に従います。報告後はユーザーの次のステップの選択を待ち、変更操作を連続して実行しません。エクスポートでは Path と GeneratedAt を報告します。監査出力の作法 を参照してください。
監査除外の読み取りルールの件数と、そのうち有効なルールの件数を示します。各ルールのセレクターは、GUID だけを示すのではなく、audit org sources から名前に変換します。各ルールについて IsActive と ActivatedOn も示します。
監査除外の書き込み書き込み前に影響を説明し、明示的な確認を得ます(ルール 30c)。書き込み後は、PolicyId、IsActive、ActivatedOn、記録されなくなるイベントとその開始時点を示します。削除の場合は、記録がただちに再開されることと、既存の空白期間は残ることも伝えます。次のステップを 1 つ提示して応答を待ち、別の書き込みを連続して実行しません。audit-exclusions-guide.md を参照してください。
IP 制限の変更有効化する前に影響を説明し、明示的な確認を得ます。その後、適用範囲を確認するため my-ip と ip-ranges list を再実行します。APMS とは決して言いません。

Task Navigation

NeedReference
Identity CLIidentity-commands.md
Usersuser-management.md
Groups and membershipgroup-management.md
Robot accountsrobot-account-management.md
External appsexternal-app-management.md
PATspat-management.md
SMTPsmtp-management.md
Authorization CLIauthorization-commands.md
Custom rolesrole-management.md
Grant permissionsgrant-permissions.md
Role assignmentsrole-assignment-management.md
Permission catalogpermission-catalog.md
Effective accesscheck-access.md
Organizationsorganizations-commands.md, organization-management.md
Tenants and servicestenants-commands.md, tenant-management.md
IP Restriction CLIip-restriction-commands.md
IP rangesip-range-management.md
Enforcementenforcement-management.md
Bypass rulesbypass-rule-management.md
Audit CLIaudit-commands.md
Audit investigationsaudit-workflow-guide.md
Audit exclusion rules (stop recording events)audit-exclusions-guide.md, surface in audit-commands.md
Audit paginationaudit-commands.md plus Rule 25
Troubleshootingidentity-troubleshoot-guide.md
Diagnostic capability indexdiagnose/CAPABILITY.md
Failure modesfailure-modes.md
Diagnostic priority laddertroubleshooting-guide.md

コメント