Informationen zum Sicherheitsstatus
Mit Sammlungen den Überblick behalten
Sie können Inhalte basierend auf Ihren Einstellungen speichern und kategorisieren.
securityPosture
ist die Sicherheitsbewertung eines Geräts, die vom aktuellen Gerätestatus abhängt.
Der aktuelle Gerätestatus wird unter anderem anhand von Faktoren wie dem Root-Status des Geräts und der Ausführung eines benutzerdefinierten ROM bestimmt.
securityPosture
wird in der Antwort in devicePosture
und eine zusätzliche Liste von postureDetails
unterteilt, die das Feld securityRisk
enthält.
Das Feld securityRisk
gibt Aufschluss darüber, warum das Gerät nicht als sicher eingestuft wird. Die Liste advice
kann Ihnen dabei helfen, Maßnahmen zur Verbesserung der Sicherheit des Geräts zu ergreifen.
Beispiel:
{
"devicePosture": "POTENTIALLY_COMPROMISED",
"postureDetails": [
{
"securityRisk": "UNKNOWN_OS",
"advice": [
{
"defaultMessage": "The user should lock their device's bootloader."
}
]
},
{
"securityRisk": "HARDWARE_BACKED_EVALUATION_FAILED"
}
]
}
Sicherheitsstatus bewerten
Standardmäßig wird securityPosture
mithilfe der Schlüsselattestierung bewertet, insbesondere der hardwaregestützten Schlüsselattestierung (HBKA), sofern verfügbar. Dadurch wird ein vertrauenswürdiges Sicherheitsurteil geliefert, da die Attestierung in sicherer Hardware generiert und signiert wird.
Manchmal kann HBKA für diese Bewertung nicht verwendet werden. Daher gibt securityRisk
„HARDWARE_BACKED_EVALUATION_FAILED“ zurück. Das bedeutet, dass securityPosture
ausgewertet werden kann, aber nicht mit HBKA. Der Boot-Integritätsstatus des Geräts könnte also manipuliert werden (z. B. könnte das Gerät gerootet sein) und von der softwarebasierten Erkennung nicht erkannt werden.
Sicherheitsstatus-Bewertungen
Anhand verschiedener Kombinationen von devicePosture
und securityRisk
lässt sich die allgemeine Sicherheit des Geräts ermitteln. Die folgende Liste ist nicht vollständig:
- Wenn
devicePosture
„SECURE“ und securityRisk
„HARDWARE_BACKED_EVALUATION_FAILED“ zurückgibt, ist die Integrität des Geräts gesichert, konnte aber nicht durch HBKA bestätigt werden.
- Wenn
devicePosture
„POTENTIALLY_COMPROMISED“ zurückgibt und kein securityRisk
-Ergebnis zurückgegeben wird, wird HBKA bei der Bewertung verwendet und das Gerät wird als manipuliert betrachtet.
- Wenn
devicePosture
„POTENTIALLY_COMPROMISED“ und securityRisk
„HARDWARE_BACKED_EVALUATION_FAILED“ zurückgibt, konnten nur softwarebasierte Prüfungen durchgeführt werden, die Integritätsbedrohungssignale sind jedoch stark genug, um das Gerät als manipuliert zu betrachten.
- Wenn
devicePosture
„POSTURE_UNSPECIFIED“ zurückgibt, konnte die Sicherheitsbewertung nicht abgeschlossen werden. Wir empfehlen, auf die Neuausstellung der HBKA zu warten, die erfolgt, wenn ein neues Urteil zurückgegeben wird, um zu sehen, ob ein bestimmter Wert zurückgegeben werden kann. Bei der Erstinstallation kann es jedoch vorkommen, dass „POSTURE_UNSPECIFIED“ für einen kurzen Zeitraum angezeigt wird.
Zuordnungen der Android Management API zur Play Integrity API
In der folgenden Tabelle finden Sie die Zuordnung zwischen dem AM API-Urteil und der Antwort der Play Integrity API.
Sofern nicht anders angegeben, sind die Inhalte dieser Seite unter der Creative Commons Attribution 4.0 License und Codebeispiele unter der Apache 2.0 License lizenziert. Weitere Informationen finden Sie in den Websiterichtlinien von Google Developers. Java ist eine eingetragene Marke von Oracle und/oder seinen Partnern.
Zuletzt aktualisiert: 2025-07-26 (UTC).
[null,null,["Zuletzt aktualisiert: 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` |"]]