보안 상태 이해
컬렉션을 사용해 정리하기
내 환경설정을 기준으로 콘텐츠를 저장하고 분류하세요.
securityPosture
는 현재 기기 상태에 따라 결정되는 기기의 보안 평가입니다.
현재 기기 상태는 기기가 루팅되었는지, 맞춤 ROM을 실행 중인지 등의 요인에 따라 결정됩니다.
securityPosture
는 응답에서 devicePosture
및 securityRisk
필드가 포함된 추가 postureDetails
목록으로 분류됩니다.
securityRisk
필드는 기기가 가장 안전한 상태로 간주되지 않는 이유를 알려 주고 advice
목록은 기기의 보안 상태를 개선하기 위한 작업을 실행하는 데 도움이 됩니다.
예를 들면 다음과 같습니다.
{
"devicePosture": "POTENTIALLY_COMPROMISED",
"postureDetails": [
{
"securityRisk": "UNKNOWN_OS",
"advice": [
{
"defaultMessage": "The user should lock their device's bootloader."
}
]
},
{
"securityRisk": "HARDWARE_BACKED_EVALUATION_FAILED"
}
]
}
보안 상태 평가
기본적으로 securityPosture
는 키 증명, 특히 해당하는 경우 하드웨어 지원 키 증명 (HBKA)을 사용하여 평가되며, 보안 하드웨어에서 증명을 생성하고 서명함에 따라 신뢰할 수 있는 보안 확인 결과를 제공합니다.
이 평가에 HBKA를 사용할 수 없는 경우도 있습니다. 이를 반영하기 위해 securityRisk
는 'HARDWARE_BACKED_EVALUATION_FAILED'를 반환합니다. 즉, securityPosture
는 평가할 수 있지만 HBKA는 평가할 수 없습니다. 즉, 기기의 부팅 무결성 상태가 손상될 수 있으며 (예: 기기가 루팅될 수 있음) 소프트웨어 기반 감지에서는 감지되지 않을 수 있습니다.
보안 상태 확인 결과 이해하기
devicePosture
및 securityRisk
의 다양한 조합을 해석하여 기기의 전반적인 보안을 파악할 수 있습니다. 아래 목록은 일부에 불과하며,
devicePosture
가 'SECURE'를 반환하고 securityRisk
가 'HARDWARE_BACKED_EVALUATION_FAILED'를 반환하면 기기의 무결성이 안전하지만 HBKA에서 이를 확인할 수 없습니다.
devicePosture
가 'POTENTIALLY_COMPROMISED'를 반환하고 securityRisk
결과가 반환되지 않으면 평가에 HBKA가 사용되고 기기가 손상된 것으로 간주됩니다.
devicePosture
가 'POTENTIALLY_COMPROMISED'를 반환하고 securityRisk
가 'HARDWARE_BACKED_EVALUATION_FAILED'를 반환하면 소프트웨어 기반 검사만 실행할 수 있지만 무결성 위협 신호가 충분히 강력하여 기기를 손상된 것으로 간주할 수 있습니다.
devicePosture
가 'POSTURE_UNSPECIFIED'를 반환하면 보안 평가를 완료할 수 없습니다. 새 확인 결과가 반환될 때 발생하는 HBKA 재발급을 기다렸다가 특정 값을 반환할 수 있는지 확인하는 것이 좋습니다. 하지만 초기 설치 시 'POSTURE_UNSPECIFIED'가 잠시 표시될 수 있습니다.
Android Management API와 Play Integrity API 매핑
다음 표에는 AM API 확인 결과와 Play Integrity API 확인 결과 응답 간의 매핑 등가가 나와 있습니다.
달리 명시되지 않는 한 이 페이지의 콘텐츠에는 Creative Commons Attribution 4.0 라이선스에 따라 라이선스가 부여되며, 코드 샘플에는 Apache 2.0 라이선스에 따라 라이선스가 부여됩니다. 자세한 내용은 Google Developers 사이트 정책을 참조하세요. 자바는 Oracle 및/또는 Oracle 계열사의 등록 상표입니다.
최종 업데이트: 2025-07-26(UTC)
[null,null,["최종 업데이트: 2025-07-26(UTC)"],[[["\u003cp\u003e\u003ccode\u003esecurityPosture\u003c/code\u003e provides a security evaluation of an Android device based on factors like rooting, custom ROMs, and key attestation.\u003c/p\u003e\n"],["\u003cp\u003eIt uses \u003ccode\u003edevicePosture\u003c/code\u003e and \u003ccode\u003esecurityRisk\u003c/code\u003e fields to determine if a device is secure, potentially compromised, or if evaluation failed.\u003c/p\u003e\n"],["\u003cp\u003eHardware-backed key attestation (HBKA) provides a trustworthy security verdict, but software-based checks are used if HBKA fails.\u003c/p\u003e\n"],["\u003cp\u003eDifferent combinations of \u003ccode\u003edevicePosture\u003c/code\u003e and \u003ccode\u003esecurityRisk\u003c/code\u003e values offer insight into the specific security state of a device.\u003c/p\u003e\n"],["\u003cp\u003eThe Android Management API security verdicts have corresponding mappings to Play Integrity API verdict responses.\u003c/p\u003e\n"]]],["`securityPosture` evaluates device security based on factors like rooting or custom ROMs. It breaks down into `devicePosture` and `postureDetails`, the latter including `securityRisk` and `advice`. `securityRisk` highlights potential security issues. Evaluations use hardware-backed key attestation (HBKA) when possible; failures are marked by `HARDWARE_BACKED_EVALUATION_FAILED` in `securityRisk`. Different `devicePosture` and `securityRisk` combinations indicate varying security levels, such as \"SECURE\" with HBKA failure, or \"POTENTIALLY_COMPROMISED\". It also maps the AM API verdicts to the Play Integrity API.\n"],null,["# Understanding Security Posture\n\n[`securityPosture`](/android/management/reference/rest/v1/enterprises.devices#securityposture) is the security evaluation of a device, determined by the current device status.\nCurrent device status is determined by factors such as if the device has been rooted, if it is running a custom ROM, and more.\n\n`securityPosture` is broken down in the response into [`devicePosture`](/android/management/reference/rest/v1/enterprises.devices#deviceposture) and an additional list of [`postureDetails`](/android/management/reference/rest/v1/enterprises.devices#posturedetail) which contains the field [`securityRisk`](/android/management/reference/rest/v1/enterprises.devices#securityrisk).\n\nThe `securityRisk` field gives an idea of why the device is not considered to be in the most secure state, while the `advice` list can help perform actions to improve the security posture of the device.\nFor example: \n\n```gdscript\n {\n \"devicePosture\": \"POTENTIALLY_COMPROMISED\",\n \"postureDetails\": [\n {\n \"securityRisk\": \"UNKNOWN_OS\",\n \"advice\": [\n {\n \"defaultMessage\": \"The user should lock their device's bootloader.\"\n }\n ]\n },\n {\n \"securityRisk\": \"HARDWARE_BACKED_EVALUATION_FAILED\"\n }\n ]\n}\n```\n\nEvaluating Security Posture\n---------------------------\n\nBy default, `securityPosture` is evaluated using key attestation, specifically [hardware-backed key attestation (HBKA)](https://developer.android.com/training/articles/security-key-attestation) if applicable, providing a trustworthy security verdict as it generates and signs the attestation in secure hardware.\n\nIt may sometimes be the case that HBKA cannot be used for this evaluation. To reflect this, `securityRisk` will return \"HARDWARE_BACKED_EVALUATION_FAILED\". This means that `securityPosture` can be evaluated but not with HBKA, meaning that the device's boot integrity state could be compromised (e.g. the device could be rooted) and go undetected by software-based detection.\n\nUnderstanding Security Posture Verdicts\n---------------------------------------\n\nDifferent combinations of `devicePosture` and `securityRisk` can be interpreted to understand the overall security of the device. Please be aware that the list below is not exhaustive:\n\n- If `devicePosture` returns \"SECURE\" and `securityRisk` returns \"HARDWARE_BACKED_EVALUATION_FAILED\" the device's integrity is secure, but this could not be confirmed by HBKA.\n- If `devicePosture` returns \"POTENTIALLY_COMPROMISED\" and no `securityRisk` result is returned, then HBKA is used in the evaluation and considers the device as compromised.\n- If `devicePosture` returns \"POTENTIALLY_COMPROMISED\" and `securityRisk` returns \"HARDWARE_BACKED_EVALUATION_FAILED\" then only software based checks could be performed, yet the integrity threat signals are strong enough to consider the device as compromised.\n- If `devicePosture` returns \"POSTURE_UNSPECIFIED\" then the security evaluation could not be completed. We recommend waiting for the re-issuance of the HBKA, which occurs when a new verdict is returned, to see if it can return a specific value. However, it is expected for \"POSTURE_UNSPECIFIED\" to occur on initial install for a short period of time.\n\n### Android Management API to Play Integrity API mappings\n\nThe following table provides the mapping equivalence between AM API verdict and\nthe Play Integrity API verdict response.\n\n| [AM API DevicePosture](/android/management/reference/rest/v1/enterprises.devices#deviceposture) | [AM API Posture.Detail.SecurityRisk](/android/management/reference/rest/v1/enterprises.devices#PostureDetail.FIELDS.security_risk) | [Play Integrity API verdict equivalent](/google/play/integrity/verdicts#device-integrity-field) |\n|------------------------------------------------------------------------------------------------------------------------------------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------|-------------------------------------------------------------------------------------------------|\n| [`SECURE`](/android/management/reference/rest/v1/enterprises.devices#DevicePosture.ENUM_VALUES.SECURE) | [`SECURITY_RISK_UNSPECIFIED`](/android/management/reference/rest/v1/enterprises.devices#SecurityRisk.ENUM_VALUES.SECURITY_RISK_UNSPECIFIED) | `MEETS_STRONG_INTEGRITY` |\n| [`SECURE`](/android/management/reference/rest/v1/enterprises.devices#DevicePosture.ENUM_VALUES.SECURE) | contains: [`HARDWARE_BACKED_EVALUATION_FAILED`](/android/management/reference/rest/v1/enterprises.devices#SecurityRisk.ENUM_VALUES.HARDWARE_BACKED_EVALUATION_FAILED) | `MEETS_DEVICE_INTEGRITY` |\n| [`AT_RISK`](/android/management/reference/rest/v1/enterprises.devices#DevicePosture.ENUM_VALUES.AT_RISK) | contains: [`HARDWARE_BACKED_EVALUATION_FAILED`](/android/management/reference/rest/v1/enterprises.devices#SecurityRisk.ENUM_VALUES.HARDWARE_BACKED_EVALUATION_FAILED) | `MEETS_DEVICE_INTEGRITY` |\n| [`POTENTIALLY_COMPROMISED`](/android/management/reference/rest/v1/enterprises.devices#DevicePosture.ENUM_VALUES.POTENTIALLY_COMPROMISED) | contains: [`UNKNOWN_OS`](/android/management/reference/rest/v1/enterprises.devices#SecurityRisk.ENUM_VALUES.UNKNOWN_OS) | `MEETS_BASIC_INTEGRITY` |\n| [`POTENTIALLY_COMPROMISED`](/android/management/reference/rest/v1/enterprises.devices#DevicePosture.ENUM_VALUES.POTENTIALLY_COMPROMISED) | contains: [`COMPROMISED_OS`](/android/management/reference/rest/v1/enterprises.devices#SecurityRisk.ENUM_VALUES.COMPROMISED_OS) | `\u003cunset\u003e` |\n| [`POSTURE_UNSPECIFIED`](/android/management/reference/rest/v1/enterprises.devices#DevicePosture.ENUM_VALUES.POSTURE_UNSPECIFIED) | `\u003cany\u003e` | `\u003cunset\u003e` |"]]