Q. Quel niveau d'accès de sécurité devrait avoir un utilisateur d'ordinateur pour faire son travail ?
A. Les mesures de sécurité sont un compromis entre le risque et le coût. Il n'y a pas de solution "taille unique". Un point de départ simple est de relier la sécurité à la formation - si vous n'avez pas eu la formation, vous n'avez pas l'accès (et cela inclut les patrons). La finesse de cet accès dépend des facteurs de risque.
L'accès administrateur / root en particulier ne devrait être donné qu'à ceux qui ont à la fois la formation et la responsabilité - une copie des codes d'accès peut être le coffre-fort des patrons au cas où ils changeraient le personnel informatique employé pour faire le travail, mais une fois que vous avez une infrastructure à plusieurs niveaux, généralement les directeurs et les cadres supérieurs ne devraient pas avoir d'accès admin/root.
Pour un exemple qui m'est arrivé au siècle dernier, un directeur d'école primaire a donné à ses enfants le mot de passe root pour qu'ils puissent "jouer" pendant qu'il était occupé à travailler - ils ont détruit suffisamment le système pour que le bibliothécaire apporte le système xenix au magasin d'informatique local pour une réparation bon marché ou pour éviter l'embarras, le magasin a rapidement effacé la "partition dos corrompue" et a installé dos (le système ne fonctionnait pas sous dos). Cela a fini par coûter cher à la bibliothèque d'expédier l'ordinateur chez nous pour le réinstaller complètement, recharger leur sauvegarde vieille de plusieurs semaines, puis de le leur renvoyer pour réintégrer une semaine de travail.
De même, la paie et d'autres informations personnelles doivent souvent être gardées privées par la loi dans la plupart des pays, et il y a des coûts juridiques si vous êtes pris à ne pas le faire.
Les entreprises doivent décider quels sont les risques que vous essayez d'atténuer, quels sont les coûts d'une défaillance de sécurité, et quelle est la probabilité que ces risques se produisent. Ensuite, l'entreprise doit prendre une décision, de préférence avec le retour d'informations des spécialistes de la sécurité physique et informatique et de leur compagnie d'assurance, quant au niveau et à la combinaison de mesures de sécurité appropriés. J'inclus la compagnie d'assurance parce que le coût et la couverture de la responsabilité civile et d'autres assurances peuvent être affectés par ces décisions et devraient donc être un facteur inclus.
L'une des grandes décisions de mise en œuvre est de savoir si vous commencez par défaut tout ce qui est autorisé ou tout ce qui est interdit.
Du côté des coûts, une bonne sécurité se situe quelque part dans une fourchette allant d'une légère gêne jusqu'à un impact significatif sur la productivité, ainsi que le coût de mise en œuvre, de surveillance et de maintenance.
À titre d'exemple, il a fallu des semaines et des milliers de dollars de temps à l'un de mes clients pour déterminer entièrement qui avait besoin de quoi parmi les 105 rôles de sécurité lors de la mise à niveau vers AX 2012 [Et nous ne pouvions pas donner à tout le monde "Admin" car cela exposait la paie et d'autres informations confidentielles]. Saviez-vous que "waterspider", par exemple, était un rôle de sécurité comportant six fonctions secondaires ? Je ne le savais pas ! La plupart des employés ont fini par avoir une quinzaine de rôles, et souvent, nous ne pouvions les découvrir qu'en effectuant une recherche inversée à partir de chaque formulaire et rapport qu'ils utilisaient pour voir quels rôles de sécurité correspondaient (et vous ne pouviez pas simplement choisir tous les rôles de "manager" parce que certains des rôles de travailleurs comprenaient des fonctions et donc des accès que les rôles de managers n'accordaient pas). Il a fallu des mois avant que le dernier problème d'autorisation ne soit découvert et résolu après la mise en service.
De même, toutes les API externes ont essentiellement dû être exercées et déboguées jusqu'à ce qu'elles cessent de déclencher des problèmes d'accès sur l'une des milliers de classes et plus de 6 000 tables, puis les utilisateurs qui utilisaient des logiciels utilisant ces API se sont vus attribuer ces rôles.