Chrome Enterprise Premium의 핵심 원칙은 'Google이 알고 있는 사용자와 사용자 기기에 따라 서비스에 대한 액세스 권한이 부여된다'는 점입니다. 단일 사용자 또는 단일 기기에 부여된 액세스 수준은 여러 데이터 소스 조사를 통해 동적으로 추론됩니다. 그런 다음 이 신뢰 수준을 결정 프로세스의 일부로 사용할 수 있습니다.
신뢰 평가 프로세스의 핵심 요소는 사용자의 로그인 사용자 인증 정보 강도입니다. 여기서 특정 유형의 애플리케이션에 대한 액세스는 사용자가 시스템에 인증한 방식에 따라 결정됩니다. 예를 들어 비밀번호로만 로그인한 사용자는 민감한 정보가 포함되지 않은 애플리케이션에만 액세스할 수 있습니다. 반면, 두 번째 단계인 하드웨어 보안 키로 로그인한 사용자는 가장 민감한 엔터프라이즈 애플리케이션에 액세스할 수 있습니다.
사용자 인증 정보 강도 기반 정책은 기업이 인증 프로세스 중 사용된 사용자 인증 정보의 강도에 따라 액세스 제어를 사용 설정할 수 있게 해주는 기능입니다. 액세스 제어 정책에서 사용자 인증 정보 강도를 또 다른 조건으로 사용함으로써 하드웨어 보안 키, 2단계 인증, 다른 형식의 강력한 사용자 인증 정보를 사용해서 액세스 제어를 적용할 수 있습니다.
사용자 인증 정보 강도 정책 개요
Access Context Manager를 사용하면 Google Cloud 조직 관리자는 Google Cloud의 프로젝트와 리소스에 세분화된 속성 기반 액세스 제어를 정의할 수 있습니다.
액세스 수준은 요청에 대한 컨텍스트 정보를 기반으로 리소스에 대한 액세스를 허용하는 데 사용됩니다. 액세스 수준을 사용하면 트러스트 계층을 구성할 수 있습니다. 예를 들어 권한이 높은 소규모 개인 그룹의 요청을 허용하는 High_Level 액세스 수준을 만들 수 있습니다.
또한 요청을 허용할 IP 범위와 같이 신뢰할 수 있는 보다 일반적인 그룹을 식별할 수도 있습니다. 이 경우 이러한 요청을 허용하기 위해 Medium_Level이라는 액세스 수준을 만들 수 있습니다.
Access Context Manager는 액세스 수준을 정의하는 두 가지 방법(기본 및 커스텀)을 제공합니다. 사용자 인증 정보 강도 확인에는 현재 커스텀 액세스 수준이 사용됩니다.
사용자 인증 중 사용되는 사용자 인증 정보 강도에 대한 자세한 내용은 Google 로그인 프로세스 중에 캡처됩니다. 이 정보는 Google의 세션 스토리지 서비스에 캡처되어 저장됩니다.
사용자 인증 정보 강도 검사는 현재 IAP(Identity-Aware Proxy), TCP용 IAP(Identity-Aware Proxy), Google Workspace에서 지원됩니다.
사용자 인증 정보 강도 정책 구성
Access Context Manager 커스텀 액세스 수준 정의를 사용하여 적합한 정책을 설정할 수 있습니다. 커스텀 액세스 수준은 Common Expression Language(CEL)의 하위 집합으로 작성된 부울 표현식을 사용하여 요청하는 클라이언트의 속성을 테스트합니다.
Google Cloud 콘솔에서 액세스 수준을 만들 때 고급 모드로 커스텀 액세스 수준을 구성할 수 있습니다. 커스텀 액세스 수준을 만들려면 다음 단계를 완료합니다.
액세스 수준 제목 상자에 액세스 수준의 제목을 입력합니다. 제목은 최대 50자이고 문자로 시작해야 하며 숫자, 문자, 밑줄, 공백만 제목에 사용할 수 있습니다.
조건 만들기에 고급 모드를 선택합니다.
조건 섹션에 커스텀 액세스 수준의 표현식을 입력합니다. 조건은 단일 부울 값으로 확인되어야 합니다. Common Expression Language(CEL) 지원 및 커스텀 액세스 수준에 대한 예시와 자세한 내용은 커스텀 액세스 수준 사양을 참조하세요.
저장을 클릭합니다.
지원되는 사용자 인증 정보 강도 값
값
Google 정의
커스텀 액세스 수준 예시
pwd
사용자는 비밀번호로 인증되었습니다.
request.auth.claims.crd_str.pwd == true
push
사용자는 모바일 기기로 보낸 푸시 알림을 통해 인증되었습니다.
request.auth.claims.crd_str.push == true
sms
사용자는 SMS로 전송된 코드를 사용하거나 전화 통화를 통해 인증되었습니다.
request.auth.claims.crd_str.sms == true
swk
2SV는 휴대전화와 같은 소프트웨어 키를 보안 키로 사용했습니다.
request.auth.claims.crd_str.swk == true
hwk
2SV는 Google Titan 키와 같은 하드웨어 키를 사용했습니다.
request.auth.claims.crd_str.hwk == true
otp
사용자는 일회용 비밀번호 메서드(Google OTP 및 백업 코드)로 통해 인증되었습니다.
request.auth.claims.crd_str.otp == true
mfa
사용자는 이 표의 메서드 중 하나(pwd 제외)로 인증되었습니다.
request.auth.claims.crd_str.mfa == true
2단계 인증 추가 정보
Google 2단계 인증에는 사용자가 기기를 신뢰할 수 있음으로 표시하고 동일한 기기에 다시 로그인할 때 추가적인 2단계 인증 과정을 방지하는 기능이 있습니다. 이 기능이 사용 설정되어 있으면 로그아웃했다가 다시 로그인하는 사용자는 두 번째 로그인에서 2단계 챌린지를 받지 않으며 Google은 두 번째 로그인에서 2단계 챌린지가 사용되지 않았으므로 다중 인증(MFA)이 아닌 두 번째 로그인의 사용자 인증 정보 강도를 비밀번호 전용으로 올바르게 보고합니다.
사용자가 항상 강력한 사용자 인증 정보를 사용하도록 요구하는 애플리케이션이나 워크플로가 있는 경우 신뢰할 수 있는 기기 기능을 중지하는 것이 좋습니다. 신뢰할 수 있는 기기 기능을 사용 설정하거나 중지하는 방법은 신뢰할 수 있는 컴퓨터 추가 또는 삭제를 참조하세요. 이 기능을 중지하면 사용자는 자주 사용하는 기기에서도 로그인할 때마다 2단계 인증을 제공해야 합니다. 최근 로그인에서 다중 인증(MFA)을 요구하면 사용자는 로그아웃했다가 다시 로그인해야 합니다.
[[["이해하기 쉬움","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."]]
