uipath-admin について
uipath-adminは、UiPathのアイデンティティ、認可、テナント運用、IP制限、監査を扱うエージェントスキルです。対象とスコープを確認してから変更し、結果を検証する手順を重視します。
主な機能
- 01ユーザー、グループ、ロボットアカウントの管理
- 02カスタムロールと割り当ての設定
- 03テナントとサービスのライフサイクル管理
- 04IP制限ルールの管理
- 05監査イベントの検索とエクスポート
- 06アイデンティティとアクセスの障害調査
活用シーン
- 01アクセス拒否やロール未反映の調査
- 02不審なサインインと監査イベントの確認
- 03テナントサービスと操作状態の管理
- 04IPロックアウト、PAT、SMTPの問題調査
インストール
コマンドをコピーしてターミナルで実行します。
npx skills add https:/ / github.com/ uipath/ skills --skill uipath-adminインストール後、Claude Code で/uipath-adminを入力して読み込まれたか確認します。
同梱ファイル
SKILL.md と一緒にインストールされる参考資料やスクリプト。
references/audit-commands.mdaudit-exclusions-guide.mdaudit-workflow-guide.mdexternal-app-management.mdgroup-management.mdidentity-commands.mdidentity-troubleshoot-guide.mdkey-concepts.mdorganization-management.mdorganizations-commands.mdpat-management.mdrobot-account-management.mdsmtp-management.mdtenant-management.mdtenants-commands.mduser-management.mdreferences/authorization/authorization-commands.mdcheck-access.mdgrant-permissions.mdpermission-catalog.mdrole-assignment-management.mdrole-management.mdreferences/diagnose/CAPABILITY.mdfailure-modes.mdtroubleshooting-guide.mdreferences/ip-restriction/bypass-rule-management.mdenforcement-management.mdip-range-management.mdip-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 の問題と認証情報モデルの問題を区別してください。
重要なルール
各ルールはエージェントとの契約の一部です。
全般
- 適切なコマンドに振り分けます: Orchestrator 固有のロール/権限に関するリクエストには、
uip admin authorizationではなくuip or roles(uipath-platform)を使用します。組織/テナントの監査には、監査履歴、エクスポート、ログイン履歴、コンプライアンスダンプ、「誰がどこで何をしたか」を含め、必ずuip admin audit <scope>(sources、events、またはexport)を使用し、uip or audit-logsは使用しません。 - まずログイン状態を確認します:
uip login status --output jsonを実行します。未認証の場合は中止し、ユーザーにuip loginの実行を依頼します。このコマンドはブラウザーでの対話型フローを開始するため、自動化セッションや非対話型セッションでは実行してはいけません。環境認証済みのセッションは、すでにログイン済みです。アクティブなセッションから組織を特定します。 - すべてのコマンドで
--output jsonを使用します。 プログラムで解析し、会話形式で提示します。 - エラーが発生したら中止し、エラーをそのまま表示します。 認証エラーを再試行してはいけません。ユーザーに
uip loginの実行を依頼します。 - リスクの高い操作の前に、名前で指定されたプリンシパルを特定します: ユーザー、グループ、ロボットアカウント、外部アプリが対象です。割り当ての作成/削除、ユーザー/グループの削除、メンバーシップの変更、ロボットの削除、外部アプリの削除、シークレットの生成も含まれます。まず検索し、
Principal: <displayName> (<userName>) — <id>の形式で確認結果を表示します。一致する項目がない場合は中止してユーザーに確認します。一致する項目が複数ある場合は、番号付きリストを表示して数字の入力を待ちます。現在ログインしているユーザーで代用してはいけません。プリンシパル ID の解決を参照してください。
アイデンティティ
- 作成前に確認します: ユーザー招待を除き、まずロボットアカウント、グループ、外部アプリを一覧表示します。
- シークレットを表示するのは一度だけです: 外部アプリの作成時と
generate-secretの実行時に限ります。すぐに保存するようユーザーに伝えます。 - 外部アプリには作成スコープが必要です:
--app-scopeまたは--user-scopeを指定します。例:--app-scope "OR.Folders"。 - グループメンバーシップにはユーザー ID を使用します: ルール 5 に従ってユーザーを特定してから、
groups members add/revokeを使用します。 - 対象を特定してから、ユーザー、グループ、ロボットアカウント、外部アプリの削除を確認します。 組み込みグループ(
type: "BuiltIn")は削除できません。削除できるのはCustomグループのみです。
Authz
- 組み込みロールは読み取り専用です。 作成/更新/削除できるのは
Customロールのみです。CLI はサービス管理またはプラットフォームレベルのロール作成を拒否します。詳しくは、独自のロールを管理するサービスを参照してください。 roles create/updateは PUT スタイルのアップサートです。 フラグと--file ./actions.jsonから本文を作成します。省略したフラグはフィールドを上書きするため、更新前に必ずroles getを実行してください。--serviceはスコープを推定します(例:studio→Tenant、apps→Organization)。上書きが必要な場合にのみ--scopeを使用してください。serviceNameを推測してはいけません。有効な値と再導出コマンドについては、permission-catalog.md → serviceNamesを参照してください。- 一覧表示はすべてのサービスに対応しますが、ロール作成は対応していません。
roles list --service <svc>とroles assignments list --service <svc>はすべてのサービスを受け付けます。実効アクセス権の確認にはcheck-accessを使用してください。 - スコープの語彙はコマンドによって異なります。
roles create --scopeはOrganization|TenantGlobal|Tenant|Project、assignment create はこれにFolder|Appを追加し、assignment list はTenantGlobalを除外します。check-access --scopeがサポートするのはTenant|Folderのみです。 - Assignment の作成/削除には、ルール 5 に基づくプリンシパルの解決が必要です。
--identity-idは検証されない生の UUID です。 - 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
- 非同期ライフサイクル:自動ポーリング後に引き継ぎます。 テナントの作成/更新/削除/有効化/無効化では
operationIdが返されます。organizations operation get <OP_ID>を5秒間隔で3回ポーリングし、終端ステータスになったら停止します。その後も処理中の場合は、番号付きメニューを提示します。無期限にループしてはいけません。組織の作成/削除はCLIでは利用できず、Portal/サポートが必要です。ポーリング手順を参照してください。 tenants deleteはソフト削除のみです。 復元にはサポートが必要です。ハード削除フラグはありません。- テナントコマンドは、ログイン中のテナントをデフォルトで対象にします。 テナントの削除/無効化と
tenants services removeでは、必ず明示的に<TENANT_ID>を指定してください。 - テナント作成前にリージョンを確認してください:
organizations regions listを先に実行してください。--regionは必須で、リージョンに応じた設定が必要です。 - サービスの無効化/削除では、誤って Success と報告されることがあります。 必ずその後に一覧を再取得してください。テナントの概念を参照してください。
Audit
- クエリの前に、
orgとtenantのどちらかを明確にしてください。 曖昧で、直前のやり取りでもスコープが確定していない場合は、AskUserQuestion が利用可能であれば、それを使って確認の質問を1つしてください。暗黙のうちに既定のスコープを選ばないでください。対話形式で確認できない場合は、両方をクエリして結果を統合してください。スコープは位置で指定します。例:uip admin audit org sourcesまたはuip admin audit tenant events。--scopeは無効です。監査スコープの曖昧さの解消を参照してください。 - イベントの戻り値は
{auditEvents, next, previous}であり、配列そのものではありません。Data.auditEvents[]を読み取ってください。nextは新しいイベント、previousは古いイベントを示し、最新から過去へたどる場合はpreviousを使います。 --limitは内部でページネーションを行います。 ページネーションのために日付を繰り返し指定しないでください。サーバーへの各リクエストの上限・下限は[10, 200]で、CLI の上限は 10000 です。--limitは[1, 10000]の範囲で指定してください。10000 を超えるとResult: "ValidationError"が返されます。「すべて」を取得する場合は、省略するか範囲内に収めてください。- 最初に
audit <scope> sourcesを実行してください。 ソース、ターゲット、タイプの GUID を捏造せず、ライブカタログにある GUID を使ってください。このレスポンスで利用可能かどうかも確認できます。 - イベントの期間は 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を参照してください。 - org 監査では
--tenant-idは無視されます。 代わりにaudit tenantを使ってください。 - 監査で 401 が発生した場合は、再試行しないでください。 トークンに
Audit.Readがありません。uip logout && uip loginを実行するようユーザーに伝えてください。 29b. 一時的な監査の 5xx エラー(ErrorCode: server_error/Retry: RetryLater、例:503/504)は、同一のクエリを使い、数秒の間隔を置いて最大2回まで再試行してください。limit や期間を変更しないでください。エラーのエンベロープをデータとして表示または保存してはなりません。取得に失敗したことを報告してください。 - エクスポートでは、ベースディレクトリと 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 制限
- 強制適用を有効にする前に安全確認と確認応答が必要です。
ip-restriction my-ipを実行し、呼び出し元の IP がip-ranges listに含まれていることを確認してから、次のように伝えてください。「IP 制限を有効にすると、送信元 IP がip-ranges listに含まれていない呼び出し元(Portal、CLI、ロボット、外部アプリ)は、この組織へのアクセスをブロックされます。設定を誤るとアクセスできなくなり、プラットフォーム側での復旧が必要になります。続行しますか?」--confirmを必須にしてください。強制適用が有効な状態で範囲を削除する場合も、--confirmが必要です。強制適用の管理を参照してください。 - IP 制限によるロックアウトからの復旧はプラットフォーム側で行います。 許可リストに登録された IP から強制適用を無効にするか、Portal の復旧手順を使用してください。CLI での回避手段はありません。
- 「APMS」は決して表示しないでください。 ユーザー向けの出力では「IP 制限」と表記してください。
- 認可エラーを回避するために権限を変更してはいけません。 403(または「認可されていない」という結果)が返った場合は、原因を診断して報告してください。不足しているスコープ、グループ、トークンの種類を示したうえで、停止してユーザーの判断を待ってください。コマンドを成功させるために、ユーザーをグループに追加したり、グループから削除したり、ロールを割り当てたり編集したり、権限を拡大したりしてはいけません。一時的な変更や、直前に行った変更を「元に戻す」ためであっても同様です。権限の取り消しは、ユーザーがすでに持っていたアクセス権の削除と区別できません。グループ、ロール、権限への書き込みが認められるのは、ユーザーが依頼したタスクそのものが、そのメンバーシップまたは権限の変更である場合に限られます。
避けるべきこと
- リソース ID をフラグとして渡さないでください。 ID と名前は位置引数です。たとえば、
groups members add <GROUP_ID> --user-ids ...のように指定します。このルールは get/update/delete/create コマンドにも適用されます。 - 出所を示さずに認可結果を提示しないでください。 ロール名、
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 とは決して言いません。 |