1. Le modèle d'accès #
Identité, groupes, politiques.
Couches #
// Politique : l'équipe paiement lit ses logs et ses événements métier, et rien d'autre
ALLOW storage:logs:read, storage:bizevents:read
WHERE storage:dt.security_context = "payment";
ALLOW storage:buckets:read WHERE storage:bucket-name STARTSWITH "payment_";Le contexte de sécurité (dt.security_context) est un champ posé sur les données (par OneAgent, Kubernetes ou OpenPipeline) que les politiques utilisent comme condition : c'est le vrai mécanisme de cloisonnement de la nouvelle plateforme.
2. Audit et protection #
Prouver et minimiser.
Pratiques #
- SSO SAML et provisionnement SCIM : pas de comptes locaux, départs gérés automatiquement.
- Journaux d'audit consultables en DQL : qui a modifié une configuration, qui a lu des données sensibles.
- Masquage à la capture (OneAgent : paramètres de confidentialité, masquage des IP RUM, règles de logs) puis dans OpenPipeline.
- Rétention minimale pour les données personnelles, buckets dédiés.
- Application Security : vulnérabilités à l'exécution et protection contre les attaques applicatives.
Bonne Pratique : Revoyez chaque trimestre les groupes et politiques : les droits s'accumulent au fil des projets et des urgences.
À savoir : Dynatrace évolue très vite (nouvelle plateforme, Grail, applications) : vérifiez les noms d'écrans et les versions d'API dans la documentation de votre environnement.
