Plus souvent qu'on ne le croit, les concepteurs négligent cette importante question. Or, le type d'utilisateur final influencera le modèle d'authentification, les limites de sécurité, et les activités de l'utilisateur final, etc.
Par exemple, une application destinée à être utilisée par un employé de saisie de commandes n'aura probablement pas
besoin d’une authentification
complexe – comme un certificat numérique – et empêchera probablement
l’utilisateur d’entrer directement
des commandes système. En revanche,
une application destinée à être utilisée
par un opérateur système peut fort
bien avoir de multiples niveaux d’authentification
et permettre à l’utilisateur
d’exécuter certaines commandes
système ad hoc limitées – par exemple,
pour contrôler une file d’attente d’impression.
Différents utilisateurs finaux peuvent
avoir des exigences de sécurité
différentes selon la sensibilité des données.
Un utilisateur dans une zone non
sécurisée, comme un réceptionniste
d’hôtel, n’aura probablement pas l’occasion
d’accéder aux données financières
de la société propriétaire. En revanche,
un tel accès peut se justifier à
l’occasion pour un manager de la
même organisation. L’application devra
alors être pourvue de niveaux d’authentification
multiples assortis des
listes de contrôle correspondantes.
Il faut donc bien se demander qui
utilisera l’application. Il faut déterminer
d’emblée ce que seront les diverses méthodes
d’accès (FTP, ODBC, émulation
5250, par exemple) et élaborer les politiques
de sécurité appropriées compatibles
avec l’application. Peut-être que
l’aspect le plus important de tout modèle
de sécurité est la manière dont
votre application imposera la politique
de sécurité de l’entreprise. Voyons cela.
L'évolution du paysage des menaces et les conséquences sur votre infrastructure, vos outils de contrôles de sécurité IT existants. EPP, XDR, EDR, IA, découvrez la synthèse des conseils et recommandations à appliquer dans votre organisation.
