セキュリティ対策について理解する
コレクションでコンテンツを整理
必要に応じて、コンテンツの保存と分類を行います。
securityPosture
は、デバイスの現在のステータスによって決定されるデバイスのセキュリティ評価です。デバイスの現在のステータスは、デバイスの root 権限が取得されているかどうか、カスタム 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 の判定結果レスポンスを対応付けた表を示します。
特に記載のない限り、このページのコンテンツはクリエイティブ・コモンズの表示 4.0 ライセンスにより使用許諾されます。コードサンプルは Apache 2.0 ライセンスにより使用許諾されます。詳しくは、Google Developers サイトのポリシーをご覧ください。Java は 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` |"]]