Comprendre la stratégie de sécurité

securityPosture correspond à l'évaluation de la sécurité d'un appareil, déterminée par son état actuel. L'état actuel de l'appareil est déterminé par des facteurs tels que si l'appareil a été en mode root, s'il exécute une ROM personnalisée, etc.

Dans la réponse, securityPosture est décomposé en devicePosture et une liste supplémentaire de postureDetails contenant le champ securityRisk.

Le champ securityRisk donne une idée de la raison pour laquelle l'appareil n'est pas considéré comme étant dans l'état le plus sécurisé, tandis que la liste advice peut aider à effectuer des actions pour améliorer la posture de sécurité de l'appareil. Exemple :

 {
  "devicePosture": "POTENTIALLY_COMPROMISED",
  "postureDetails": [
    {
      "securityRisk": "UNKNOWN_OS",
      "advice": [
        {
          "defaultMessage": "The user should lock their device's bootloader."
        }
      ]
    },
    {
      "securityRisk": "HARDWARE_BACKED_EVALUATION_FAILED"
    }
  ]
}

Évaluer la stratégie de sécurité

Par défaut, securityPosture est évalué à l'aide d'une attestation de clé, en particulier d'une attestation de clé intégrée au matériel (HBKA), le cas échéant. Il fournit ainsi une évaluation de sécurité fiable, car il génère et signe l'attestation sur du matériel sécurisé.

Il peut arriver que la HBKA ne puisse pas être utilisée pour cette évaluation. Pour refléter cette situation, securityRisk renvoie "HARDWARE_BACKED_EVALUATION_FAILED". Cela signifie que securityPosture peut être évalué, mais pas avec HBKA. Par conséquent, l'état d'intégrité de démarrage de l'appareil peut être compromis (par exemple, l'appareil peut être en mode root) et ne pas être détecté par la détection logicielle.

Comprendre les évaluations de la stratégie de sécurité

Différentes combinaisons de devicePosture et securityRisk peuvent être interprétées pour comprendre la sécurité globale de l'appareil. Veuillez noter que la liste ci-dessous n'est pas exhaustive:

• Si devicePosture renvoie "SECURE" et securityRisk renvoie "HARDWARE_BACKED_EVALUATION_FAILED", l'intégrité de l'appareil est sécurisée, mais cela n'a pas pu être confirmé par HBKA.
• Si devicePosture renvoie "POTENTIALLY_COMPROMISED" et qu'aucun résultat securityRisk n'est renvoyé, HBKA est utilisé dans l'évaluation et considère l'appareil comme piraté.
• Si devicePosture renvoie "POTENTIALLY_COMPROMISED" et securityRisk renvoie "HARDWARE_BACKED_EVALUATION_FAILED", seules des vérifications logicielles peuvent être effectuées, mais les signaux de menace d'intégrité sont suffisamment forts pour considérer l'appareil comme compromis.
• Si devicePosture renvoie "POSTURE_UNSPECIFIED", l'évaluation de la sécurité n'a pas pu être effectuée. Nous vous recommandons d'attendre la nouvelle émission de l'avis de non-responsabilité pour les contenus haineux, qui se produit lorsqu'un nouvel avis est renvoyé, afin de voir s'il peut renvoyer une valeur spécifique. Toutefois, "POSTURE_UNSPECIFIED" doit s'afficher pendant une courte période lors de l'installation initiale.

Mappages de l'API Android Management vers l'API Play Integrity

Le tableau suivant fournit l'équivalence de mise en correspondance entre l'évaluation de l'API AM et la réponse d'évaluation de l'API Play Integrity.

API AM DevicePosture	Posture.Detail.SecurityRisk de l'API AM	Équivalent de l'évaluation de l'API Play Integrity
SECURE	SECURITY_RISK_UNSPECIFIED	MEETS_STRONG_INTEGRITY
SECURE	contient: HARDWARE_BACKED_EVALUATION_FAILED	MEETS_DEVICE_INTEGRITY
POTENTIALLY_COMPROMISED	contient: UNKNOWN_OS	MEETS_BASIC_INTEGRITY
POTENTIALLY_COMPROMISED	contient: COMPROMISED_OS	<unset>
POSTURE_UNSPECIFIED	<any>	<unset>