Première transformation

Il est temps de protéger des données. Cet exemple suppose que la configuration de votre portail définit une classe et une propriété pour le champ que vous souhaitez protéger, ainsi qu'un Rights Context qui accorde Protect à un rôle.

Effectuer l'appel

TOKEN=$(curl -s -X POST "$KUSTODYAN_IDENTITY_URL/connect/token" \
  -d grant_type=client_credentials \
  -d client_id="$KUSTODYAN_CLIENT_ID" \
  -d client_secret="$KUSTODYAN_CLIENT_SECRET" | jq -r .access_token)

curl -X POST "$KUSTODYAN_ENGINE_URL/transform" \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "rightsContexts": [{
      "guid": "11111111-1111-1111-1111-111111111111",
      "evidences": [{ "name": "Role", "value": "<role>" }]
    }],
    "processingContexts": [{
      "guid": "22222222-2222-2222-2222-222222222222",
      "evidences": [{ "name": "Action", "value": "Protect" }]
    }],
    "requests": [{
      "guid": "33333333-3333-3333-3333-333333333333",
      "rightsContext": "11111111-1111-1111-1111-111111111111",
      "processingContext": "22222222-2222-2222-2222-222222222222",
      "instances": [{
        "className": "<class>",
        "propertyName": "<property>",
        "value": "<value>"
      }]
    }]
  }'

Les GUID ci-dessus sont des valeurs d'exemple que vous choisissez. Ils peuvent prendre n'importe quelle valeur, fixée par intégration ou générée à chaque appel, du moment que chacun est unique au sein de la requête et que les références concordent : requests[].rightsContext doit être égal à un rightsContexts[].guid, et requests[].processingContext doit être égal à un processingContexts[].guid.

Lire la réponse

{
  "responses": [{
    "request": "33333333-3333-3333-3333-333333333333",
    "instances": [{
      "className": "<class>",
      "propertyName": "<property>",
      "value": "<value>"
    }]
  }]
}

Stockez la valeur protégée à la place de l'originale. Pour déprotéger ultérieurement, renvoyez la valeur protégée via transform avec un processingContext qui pointe vers votre séquence de déprotection. Consultez les Exemples pour la configuration d'exemple et savoir quelles techniques sont réversibles.

Tester d'abord depuis le portail

Avant de câbler votre application, le portail CoreAdmin inclut un testeur de la Transform API. Choisissez une configuration, renseignez des valeurs de preuve, et exécutez des cycles de protection et de déprotection pour confirmer que vos contextes et vos Transformer Sequences se comportent comme prévu. C'est le moyen le plus rapide de valider des changements de configuration avant de toucher au code.

Où intégrer

Plusieurs schémas d'intégration sont possibles. En guise de principe de sécurité général, protégez les données le plus tôt possible et déprotégez-les le plus tard possible, afin que le texte en clair existe dans le moins d'endroits et le moins longtemps possible. Les schémas ci-dessous sont classés approximativement du point de protection le plus précoce au plus tardif.

Protection au niveau de la passerelle : une passerelle API (ou un reverse proxy) placée devant votre application appelle transform sur les requêtes et les réponses qui la traversent. Cette approche fonctionne bien lorsque vous souhaitez protéger des données sans modifier l'application elle-même, ou lorsque vous ajoutez de la protection à un système dont vous ne possédez pas le code.

Protection au niveau applicatif : votre code appelle directement transform avant de persister une ligne, puis de nouveau à la lecture. Cette approche fonctionne bien lorsque vous souhaitez une séparation nette entre la logique de protection et le stockage, ou lorsque plusieurs magasins de données sont impliqués.

Protection au niveau de la base de données : un trigger ou une procédure stockée appelle transform de sorte que la protection s'exécute quel que soit le client qui écrit dans la table. Cette approche fonctionne bien lorsque vous maîtrisez le schéma et souhaitez un point unique où la protection a lieu.