Aller au contenu
Parlons de votre projet

Identifiez les risques qui méritent votre attention.

De nouveaux rôles. Des données sensibles. Une application qui évolue. Nexolth examine les accès et les risques d’un périmètre autorisé pour vous aider à décider quoi corriger, pourquoi et dans quel ordre.

Définir ce que l’audit doit examiner

Qui peut consulter ce dossier ? Que devient cette information lorsqu’elle est partagée ? Nous partons des questions importantes pour votre application, puis définissons ce qui peut être examiné et dans quelles conditions.

Comptes et rôles
Les droits attendus, les utilisateurs concernés et les comptes d’essai utiles pour observer les accès. Un rôle doit être relié aux opérations qu’il est censé permettre.
Données et actions
Les informations à protéger et les gestes retenus dans l’examen : consulter, modifier, partager ou valider. La conséquence se lit dans le contexte de votre activité.
Écrans et interfaces
Les fonctions, les API et les échanges compris dans l’autorisation. L’examen ne s’étend pas implicitement à tous les systèmes qui les entourent.
Conditions d’intervention
L’environnement, les configurations accessibles, les précautions et les contraintes d’exploitation. Les éléments exclus ou inaccessibles restent identifiés.

Comprendre ce qu’un risque change pour vos utilisateurs

La restitution relie ce qui a été observé à ce que cela pourrait permettre, aux éléments qui étayent le constat et aux corrections proposées. La priorité est argumentée, pas réduite à un score.

Cas d’usage fictif

Un compte voit un dossier
qui ne lui appartient pas.

Le compte d’essai A demande le dossier du compte B. Dans cet exemple, l’application le renvoie alors que le rôle prévu ne l’autorise pas. C’est ce lien entre une identité, une opération et une ressource qui doit être examiné.

Lire la conséquence et la correction

Une information peut être exposée.

La conséquence dépend du contenu du dossier et des conditions nécessaires pour y accéder. Ces éléments doivent accompagner le constat.

Vérifier les droits sur le dossier demandé.

La recommandation vise le contrôle qui autorise la consultation pour le compte concerné. Sa réalisation et les essais après correction se définissent séparément.

Conserver les limites de l’examen.

Cet exemple ne décrit ni une application réelle ni l’ensemble des contrôles nécessaires. Un constat sur ce parcours ne conclut pas à lui seul sur toute l’application.

Comment se déroule l’examen

L’autorisation et les précautions précèdent toute opération. L’examen se construit autour d’un cadre explicite, jusqu’à la restitution.

  1. Préparer l’intervention

    Définir les questions, les composants, les accès d’essai et l’environnement adapté. Consigner ce qui est compris dans le travail et ce qui reste en dehors.

  2. Documenter les observations

    Examiner les parcours et les contrôles convenus. Conserver les conditions d’observation et les éléments utiles pour comprendre ou vérifier les constats.

  3. Mettre les résultats en contexte

    Présenter les conséquences possibles, discuter les priorités pour votre activité et identifier les corrections ou investigations à engager.

Des constats pour décider des corrections utiles

La restitution situe chaque observation, explique la conséquence envisagée et motive la priorité proposée. Elle précise les recommandations, les hypothèses et les limites de l’examen.

Les corrections et leur nouvel examen sont des travaux à convenir. Ils ne sont pas inclus par défaut dans toute mission d’audit.

Préparer l’évolution de votre application
Le constat et son contexte
Le composant, le parcours, les conditions et les éléments qui étayent l’observation.
La conséquence et la priorité
Les données ou opérations concernées, les conditions d’accès et la raison de l’ordre proposé.
La recommandation et les limites
Les points à corriger ou à examiner davantage, les exclusions et les éléments qui restent à vérifier.

Quel accès mérite un examen plus attentif ?

Présentez votre application, les personnes qui l’utilisent et la question à éclaircir. Aucun mot de passe ni donnée sensible n’est nécessaire pour ce premier échange. Les accès et le cadre d’examen se définissent ensuite avec vous.

Définir le périmètre de l’audit
L’audit garantit-il une application sans faille ?

Non. Il porte sur un périmètre, des accès et des conditions définis. Les constats et leurs limites sont expliqués ; la restitution ne constitue ni une certification ni une garantie d’absence de vulnérabilité.

Quels accès faut-il préparer ?

Ils dépendent du périmètre : comptes d’essai, documentation, interfaces et configurations utiles. Les accès et les précautions concernant les données et l’exploitation sont convenus avant l’intervention.

L’examen peut-il toucher la production ?

L’environnement et les opérations autorisées doivent être définis explicitement. Un environnement d’essai adapté peut être nécessaire. Une demande d’information n’autorise aucun test sur une application.

Les corrections sont-elles incluses ?

La restitution contient les recommandations convenues. La réalisation des corrections et leur nouvel examen font l’objet d’un périmètre explicite, distinct de l’audit.