Resource Access Management:アクセス拒否エラーをトラブルシューティングするにはどうすればよいですか?

オペレーターを特定します。

Auth Subjectパラメーターは、演算子の詳細を提供します。

• IDタイプ: RAMユーザー、RAMロール、およびシングルサインオン (SSO) IDを含む、演算子のIDタイプ。 SSOはIDフェデレーションとも呼ばれます。

• ID情報: ID。 オペレータがRAMユーザの場合、ユーザのIDが表示される。 演算子がRAMロールの場合、ロールの名前とセッション名 (RoleName:RoleSessionNameなど) が表示されます。 演算子がSSO IDの場合、IdPのタイプと名前 (saml-provider/AzureADなど) が表示されます。

• アカウントID: 現在のIDが属するAlibaba CloudアカウントのID。

オペレータの必要な権限を特定します。

Auth Actionパラメーターは、オペレーターが実行する権限を持たない操作を提供します。 操作に基づいて権限を確認または付与できます。

アクセス拒否エラーの原因となるポリシーの種類を特定します。

[ポリシータイプ] パラメーターは、アクセス拒否エラーの原因となるポリシーのタイプを提供します。 ポリシーは、制御ポリシー、セッションポリシー、ロール固有の信頼ポリシー (ロールポリシーを想定) 、またはアカウントまたはリソースグループレベルのIDベースのポリシーです。 詳細については、「ポリシー評価プロセス」をご参照ください。

ポリシーを調整する方法は、ポリシータイプによって異なります。

• コントロールポリシーに基づいて操作が拒否された場合は、リソースディレクトリの管理アカウントに連絡して、必要な権限を付与する必要があります。 コントロールポリシーは、リソースディレクトリ内のメンバーに付与される権限を指定します。 制御ポリシーの決定は、単一のアカウント内で行われる決定よりも高い優先度を有する。

• セッションポリシーに基づいて操作が拒否された場合は、アカウント管理者に連絡して、AssumeRole操作を呼び出して、オペレータにアタッチされているセッションポリシーを確認する必要があります。

• ロール固有の信頼ポリシーに基づいて操作が拒否された場合は、アカウント管理者に連絡して、オペレーターが想定するRAMロールの信頼ポリシーを確認する必要があります。

• IDベースのポリシーに基づいて操作が拒否された場合は、アカウント管理者に連絡して、オペレーターのIDにアタッチされているポリシーを確認する必要があります。

アクセス拒否エラーの原因が暗黙的拒否か明示的拒否かを確認してください。

• 暗黙的な拒否: エラーメッセージは、現在の操作を実行する権限がないことを示し、Auth Determinationパラメーターに [不十分な権限] が表示されます。 この場合、アカウント管理者に連絡して必要な権限を付与する必要があります。 アカウント管理者は、Auth Actionパラメーターで示される操作をAllowステートメントに追加できます。

• Explicit deny: エラーメッセージは、現在の操作が明示的に拒否され、Auth DeterminationパラメーターにExplicit Denyが表示されます。 この場合、アカウント管理者に連絡して、付与された権限を確認し、Auth Actionパラメーターで示される操作がDenyステートメントに含まれているかどうかを確認する必要があります。

  説明

  ポリシーがコントロールポリシーの場合、Auth Actionパラメーターで示される操作がAllowステートメントに含まれていない場合でも、Explicit Denyが返されます。

オペレーターを特定します。

• AuthPrincipalType: 演算子のIDタイプ。 SubUserはRAMユーザー、AssumedRoleUserはRAMロール、FederatedはSSO IDを示します。

• AuthPrincipalDisplayName: ID。 オペレータがRAMユーザの場合、ユーザのIDが表示される。 演算子がRAMロールの場合、ロールの名前とセッション名 (RoleName:RoleSessionNameなど) が表示されます。 演算子がSSO IDの場合、IdPのタイプと名前 (saml-provider/AzureADなど) が表示されます。

• AuthPrincipalOwnerId: 現在のIDが属するAlibaba CloudアカウントのID。

オペレータの必要な権限を特定します。

AuthActionフィールドは、オペレーターが実行する権限を持たない操作を提供します。 操作に基づいて権限を確認または付与できます。

アクセス拒否エラーの原因となるポリシーの種類を特定します。

PolicyTypeフィールドは、アクセス拒否エラーの原因となるポリシーのタイプを提供します。 ポリシーは、制御ポリシー、セッションポリシー、ロール固有の信頼ポリシー (ロールポリシーを想定) 、またはアカウントまたはリソースグループレベルのIDベースのポリシーです。 詳細については、「ポリシー評価プロセス」をご参照ください。

ポリシーを調整する方法は、ポリシータイプによって異なります。

• コントロールポリシーに基づいて操作が拒否された場合は、リソースディレクトリの管理アカウントに連絡して、必要な権限を付与する必要があります。 コントロールポリシーは、リソースディレクトリ内のメンバーに付与される権限を指定します。 制御ポリシーの決定は、単一のアカウント内で行われる決定よりも高い優先度を有する。

• セッションポリシーに基づいて操作が拒否された場合は、アカウント管理者に連絡して、AssumeRole操作を呼び出して、オペレータにアタッチされているセッションポリシーを確認する必要があります。

• ロール固有の信頼ポリシーに基づいて操作が拒否された場合は、アカウント管理者に連絡して、オペレーターが想定するRAMロールの信頼ポリシーを確認する必要があります。

• IDベースのポリシーに基づいて操作が拒否された場合は、アカウント管理者に連絡して、オペレーターのIDにアタッチされているポリシーを確認する必要があります。

アクセス拒否エラーの原因が暗黙的拒否か明示的拒否かを確認してください。

• Implicit deny: NoPermissionTypeフィールドにImplicitDenyが表示されます。 この場合、アカウント管理者に連絡して必要な権限を付与する必要があります。 アカウント管理者は、AuthActionフィールドで示される操作をAllowステートメントに追加できます。

• Explicit deny: NoPermissionTypeフィールドにExplicitDenyが表示されます。 この場合、アカウント管理者に連絡して、付与された権限を確認し、AuthActionフィールドで示される操作がDenyステートメントに含まれているかどうかを確認する必要があります。

  説明

  ポリシーがコントロールポリシーの場合、AuthActionフィールドで示される操作がAllowステートメントに含まれていない場合でも、ExplicitDenyが返されます。