[[["わかりやすい","easyToUnderstand","thumb-up"],["問題の解決に役立った","solvedMyProblem","thumb-up"],["その他","otherUp","thumb-up"]],[["わかりにくい","hardToUnderstand","thumb-down"],["情報またはサンプルコードが不正確","incorrectInformationOrSampleCode","thumb-down"],["必要な情報 / サンプルがない","missingTheInformationSamplesINeed","thumb-down"],["翻訳に関する問題","translationIssue","thumb-down"],["その他","otherDown","thumb-down"]],["最終更新日 2025-09-04 UTC。"],[[["\u003cp\u003eCredential strength policies allow enterprises to control access based on the strength of the credentials used during user authentication, such as hardware security keys or 2-step verification.\u003c/p\u003e\n"],["\u003cp\u003eThis feature leverages Access Context Manager and custom access levels within Google Cloud to define fine-grained, attribute-based access control based on credential strength.\u003c/p\u003e\n"],["\u003cp\u003eThe system dynamically infers the level of trust by assessing multiple data sources, including the user's login method, which in turn determines access to different types of applications.\u003c/p\u003e\n"],["\u003cp\u003eCredential strength checks are currently compatible with Identity-Aware Proxy, Identity-Aware Proxy for TCP, and Google Workspace, enabling enhanced security for these services.\u003c/p\u003e\n"],["\u003cp\u003eThere are several supported credential strength values, such as 'pwd' for password authentication, 'hwk' for hardware keys, and 'mfa' for any multi-factor authentication method, each of which can be defined within a custom access level.\u003c/p\u003e\n"]]],[],null,["# Configuring a credential strength policy\n\n| **Preview\n| --- Credential strength policy**\n|\n|\n| This feature is subject to the \"Pre-GA Offerings Terms\" in the General Service Terms section\n| of the [Service Specific Terms](/terms/service-terms#1).\n|\n| Pre-GA features are available \"as is\" and might have limited support.\n|\n| For more information, see the\n| [launch stage descriptions](/products#product-launch-stages).\n\nA key principle of Chrome Enterprise Premium is \"Access to services is granted based on\nwhat we know about you and your device.\" The level of access given to a single\nuser or a single device is dynamically inferred by interrogating multiple\ndata sources. This level of trust can then be used as part of the decision\nprocess.\n\nA key element to the trust evaluation process is the strength of the user's\nlogin credentials, where access to specific types of applications is determined\nby how the user authenticated to the system. For example, users logged in with\njust a password can only access applications that do not contain any sensitive\ninformation, whereas a user logged in with a hardware security key as a\nsecond factor can access the most sensitive enterprise applications.\n\nCredential strength based policies is a feature that allows an enterprise to\nenable access controls based on the strength of the credential used during the\nauthentication process. By leveraging credential strength as another condition\nin access control policies, enterprises can enforce access controls based on the\nusage of hardware security keys, 2-step verification or other forms of strong\ncredentials.\n| **Note:** To use the credential strength feature, you must be a Chrome Enterprise Premium Enterprise (managed) user.\n\nCredential strength policy overview\n-----------------------------------\n\nAccess Context Manager allows Google Cloud organization administrators to define\nfine-grained, attribute based access control for projects and resources in\nGoogle Cloud.\n\nAccess levels are used for permitting access to resources based on contextual\ninformation about the request. Using access levels, you can start to organize\ntiers of trust. For example, you might create an access level called High_Level\nthat will permit requests from a small group of highly-privileged individuals.\nYou might also identify a more general group to trust, such as an IP range that\nyou want to permit requests from. In that case, you might create an access level\ncalled Medium_Level to permit those requests.\n\nAccess Context Manager provides two ways to define access levels: basic and\ncustom. The credential strength check currently utilizes custom access levels.\nThe information about the credential strength used during user authentication is\ncaptured during the Google login process. That information is captured and\nstored in Google's sessions storage service.\n\nCredential strength check is currently supported for Identity-Aware Proxy, Identity-Aware Proxy for TCP, and Google Workspace.\n\nConfiguring credential strength policy\n--------------------------------------\n\nYou can use an Access Context Manager [custom access\nlevel](https://cloud.google.com/access-context-manager/docs/custom-access-level-spec) definition to set the appropriate policies. Custom access levels use\nboolean expressions written in a subset of [Common Expression Language](https://opensource.google.com/projects/cel) (CEL) to\ntest the attributes of a client making a request.\n\nIn the Google Cloud console, you can configure custom access levels in the **Advanced\nMode** when creating an access level. To create a custom access level, complete the following steps:\n\n1. In the Google Cloud console, [open the Access Context Manager page](https://console.cloud.google.com/security/access-level).\n2. If you are prompted, select your organization.\n3. At the top of the Access Context Manager page, click **New**.\n4. In the **New Access Level** pane, complete the following steps:\n 1. In the **Access level title** box, enter a title for the access level. The title must be at most 50 characters, start with a letter, and can contain only numbers, letters, underscores, and spaces.\n 2. For **Create Conditions in** , select **Advanced Mode**.\n 3. In the **Conditions section** , enter the expressions for your custom access level.The condition must resolve to a single boolean value. For examples and more information about Common Expression Language (CEL) support and custom access levels, see the [Custom access level specification](https://cloud.google.com/access-context-manager/docs/custom-access-level-spec).\n 4. Click **Save**.\n\nSupported credential strength values\n------------------------------------\n\nAdditional information about 2-step verification\n------------------------------------------------\n\nGoogle 2-Step Verification has a feature that allows users to mark their device as trusted and avoid the need for additional 2-step challenges when signing in again on the same device. When this feature is enabled, a user who signs out and signs back in does not receive a 2-step challenge on the second sign-in, and Google would correctly report the credential strength for the second sign-in as password-only, and not Multi-Factor Authentication, since a 2-step challenge was not used on the second sign-in.\n\nIf you have applications or workflows that depend on requiring the user to always use strong credentials, you might want to disable the trusted device feature. For information about enabling or disabling the trusted device feature, see [Add or remove trusted computers](https://support.google.com/accounts/answer/2544838?co=GENIE.Platform%3DDesktop&). Note that disabling the feature will require users to present their second factors every time they sign in, even on frequently used devices. Users might have to sign out and sign back in for their most recent sign-in to have Multi-Factor Authentication assertions."]]
