La question à laquelle un identifiant partagé ne peut pas répondre
La plupart des petites équipes commencent avec un seul jeu d'identifiants. Cela fonctionne jusqu'au premier incident, et cela échoue alors d'une manière très précise : quelque chose a changé, le changement est visible, et personne ne peut dire qui l'a fait ni ce qu'il a remplacé.
Cette lacune coûte plus cher que la gêne occasionnée. Sans enregistrement, vous ne pouvez pas distinguer une erreur d'une intrusion. Vous ne pouvez pas annuler le changement en toute confiance, parce que vous ne connaissez pas la valeur précédente. Et vous ne pouvez pas améliorer le processus, parce que « soyez plus prudents » est la seule leçon disponible quand personne ne sait ce qui s'est réellement passé.
Il existe aussi un regard extérieur. Une piste vérifiable des actions administratives et un contrôle d'accès significatif sont des attentes standard dans les questionnaires de sécurité et dans des référentiels comme l'ISO 27001, et des régimes de protection des données comme le RGPD ou la KVKK attendent de vous que vous puissiez montrer qui avait accès à quoi. Que vous cherchiez ou non une certification, l'exigence décrit quelque chose que vous voulez pour vous-même.
Ce qui est enregistré
L'historique d'activité couvre les changements susceptibles d'affecter ce que voient les visiteurs : purges de cache, changements d'enregistrements DNS, changements de règles de diffusion, changements de préréglages de sécurité — y compris HSTS et les listes de blocage par pays et par ASN —, actions sur les certificats et changements de nom d'hôte.
Chaque entrée porte quatre éléments qui la rendent utile. Qui : la personne réelle, de sorte qu'un sous-utilisateur apparaît sous son propre nom plutôt que comme « le compte ». Quand. Quel compte et quel chemin le changement a touché. Et avant et après, de sorte que la valeur précédente est présente au lieu d'être quelque chose que vous devez reconstituer de mémoire.
Ce dernier champ est ce qui transforme le journal d'un rapport en un outil. « Règle de diffusion modifiée » vous dit où regarder. « TTL du cache 3600 → 60 » vous dit ce qui est arrivé à votre trafic d'origine au même instant.
Le lire pendant que quelque chose est cassé
Ouvrez la barre latérale du compte, puis Supervision → Historique d'activité — /management/cdn/activities.
Pendant un incident, une séquence qui fonctionne : réduisez la période qui vous intéresse, regardez l'ensemble du compte plutôt que seulement le changement que vous soupçonnez déjà, et lisez les valeurs avant/après plutôt que les titres des entrées. Le changement qui a cassé le site n'est fréquemment pas celui auquel vous pensiez, et l'indice se trouve généralement dans l'ordre chronologique : deux entrées de personnes différentes à cinq minutes d'intervalle racontent en général toute l'histoire.
Filtrer par type d'action est ce qui rend un compte actif lisible. Un site avec une purge automatisée à chaque publication génère un grand nombre d'entrées qui ne sont pas ce que vous cherchez ; filtrez-les et la poignée de changements de configuration restants est assez courte pour être lue en entier.
En dehors d'un incident, la même page répond à une question plus discrète : quelque chose change-t-il que personne n'a mentionné ? Cela vaut cinq minutes par mois.
Y accéder depuis l'API
L'historique est également disponible via l'API, ce qui est utile si vous l'archivez, le transférez vers votre propre système de journalisation, ou simplement en conservez plus que ce que vous avez envie de faire défiler. action_type accepte les mêmes catégories que le filtre du panneau, et le point de terminaison ne vous montre jamais que les comptes que votre jeton est autorisé à voir.
Les 25 dernières purges sur un compte
curl -s -H "Authorization: Bearer $TOKEN" \
"https://cdn.com.tr/api/accounts/<account-uuid>/activities?per_page=25&action_type=purge_cache"Trois rôles, et à quoi chacun sert
Un journal vous dit ce qui s'est passé. Les rôles réduisent ce qui peut se passer. Un sous-utilisateur sur cdn.com.tr reçoit l'un des trois.
Lecteur consulte tout ce que le compte montre et ne change rien sauf son propre profil et son mot de passe. C'est le rôle qui convient à un responsable qui veut voir les graphiques, une agence qui rend compte des performances, ou toute personne qui doit regarder pendant un incident sans pouvoir l'aggraver.
Éditeur fait le travail opérationnel : purger le cache, modifier les règles de diffusion, gérer les enregistrements DNS, les certificats et les noms d'hôte. Ce qu'un éditeur ne peut pas faire, c'est changer la forme même du compte — ni créer ni supprimer de sous-utilisateurs, pas de facturation, pas de suppression du compte. C'est le rôle des personnes qui font tourner le site au quotidien.
Propriétaire fait tout cela, y compris les trois choses dont un éditeur est délibérément tenu à l'écart. C'est le titulaire du compte, et cette liste devrait rester très courte.
Deux détails à connaître. Si un sous-utilisateur est créé sans qu'un rôle soit choisi, il devient lecteur — l'extrémité prudente de l'échelle, de sorte qu'un champ oublié ne peut jamais accorder plus que ce que vous vouliez. Et les rôles sont appliqués aux jetons API exactement comme dans le panneau : le jeton d'un lecteur peut lire et ne peut pas écrire, donc un script exécuté par quelqu'un qui n'a pas le droit de modifier le DNS ne peut pas modifier le DNS.
Ajouter quelqu'un, avec l'accès dont il a besoin
Allez dans Autorisation — /management/authorization — et choisissez Nouvel utilisateur. Renseignez ses coordonnées et choisissez le rôle avant d'enregistrer ; c'est le champ qui détermine tout le reste de ce que cette personne peut faire.
Deux habitudes qui font que cela fonctionne en pratique. Donnez à chaque personne son propre identifiant plutôt que d'en partager un : l'historique d'activité n'est utile qu'autant que les noms qu'il contient, et « purgé par le compte partagé » est la même impasse que celle dont vous êtes partis. Et quand quelqu'un rejoint pour une tâche précise — une migration, une mission d'agence, un prestataire — donnez le rôle que cette tâche exige et retirez l'accès quand elle se termine. Un accès dormant dont personne n'est responsable est la constatation la plus fréquente de toute revue d'accès, et la plus facile à éviter.
Le moindre privilège sans être pénible
Le moindre privilège a mauvaise réputation parce qu'il est généralement mis en œuvre comme « demandez-moi à chaque fois », ce que les gens contournent en une semaine. La version qui survit au contact d'une équipe qui travaille réellement est plus simple.
Mettez tout le monde par défaut en lecteur et promouvez à la demande. Cela coûte un message la première fois que quelqu'un a besoin de purger, et personne ne porte un accès qu'il n'a jamais demandé.
Donnez le rôle éditeur aux personnes dont le travail est de changer des choses — et remarquez où se trouve la frontière : un éditeur peut faire tout ce qui répare un site en production et rien de ce qui change qui d'autre détient des clés ou ce qui vous est facturé. C'est la ligne qui compte réellement, et c'est pourquoi ce rôle n'est pas un compromis.
Gardez le rôle propriétaire pour les personnes qui répondent du compte, et agissez sur les changements le jour même où ils se produisent. Le journal enregistre ce qui a été fait, pas qui devrait encore pouvoir le faire ; cette partie reste la vôtre.
Les deux fonctionnalités n'en forment qu'un seul contrôle
Il est tentant de traiter le journal comme la fonctionnalité de sécurité et les rôles comme de l'administration. C'est l'inverse qui est vrai.
Les rôles sont de la prévention. Ils décident de ce qui est possible en premier lieu, ce qui est la seule chose qui arrête un accident avant que vos visiteurs ne le voient. Le journal, c'est de la détection et de la responsabilisation : il vous dit ce qui a été fait, par qui, et quelle était la valeur auparavant.
Aucun des deux ne vaut grand-chose seul. Des rôles sans enregistrement signifient que vous faites confiance à une limite que vous ne pouvez jamais vérifier. Un enregistrement sans rôles signifie que vous pouvez décrire parfaitement chaque incident et n'en prévenir aucun. Ensemble, ils répondent à la question que l'on pose réellement après une panne — jamais « qu'est-ce qu'un CDN », toujours « qui a changé cela, et pourquoi était-il autorisé à le faire ? »
Questions fréquentes
Le journal montre-t-il les sous-utilisateurs individuellement, ou seulement le compte ?
Individuellement. L'entrée enregistre la personne réelle qui a fait le changement, de sorte qu'un sous-utilisateur apparaît sous son propre nom plutôt que comme le propriétaire du compte. C'est tout l'intérêt : un journal qui dit « le compte l'a fait » ne répond à rien que vous ne saviez déjà.
Comment savoir qui a purgé le cache ?
Ouvrez Supervision → Historique d'activité sur le compte, filtrez par le type d'action purge, et trouvez l'entrée au moment en question. Elle affiche la personne, l'heure exacte et le chemin ou le motif qui a été purgé.
Quelle est la différence entre lecteur et éditeur ?
Un lecteur peut tout consulter et ne changer que son propre profil et son mot de passe. Un éditeur peut faire le travail opérationnel — purger, règles de diffusion, enregistrements DNS, certificats et noms d'hôte — mais ne peut ni ajouter ni supprimer de sous-utilisateurs, ne peut pas toucher à la facturation et ne peut pas supprimer le compte.
Que se passe-t-il si je crée un sous-utilisateur et que j'oublie de choisir un rôle ?
Il devient lecteur. Le défaut est délibérément l'extrémité en lecture seule de l'échelle, de sorte qu'un champ non rempli n'accorde jamais silencieusement plus d'accès que vous ne le vouliez.
Les rôles s'appliquent-ils aussi aux jetons API ?
Oui. L'API applique les mêmes rôles que le panneau, donc un jeton bearer appartenant à un lecteur peut lire et ne peut pas écrire. L'accès est décidé par qui est la personne, pas par la porte par laquelle elle est entrée.
Puis-je conserver l'historique quelque part de mon côté ?
Oui — le point de terminaison activities est la voie d'export. Parcourez-le avec un jeton bearer, en filtrant par type d'action si vous ne voulez qu'un sous-ensemble, et stockez le JSON où vous conservez vos archives.