Deuxièmement, les entreprises peuvent faire passer la sécurité des processus à un niveau supérieur en établissant une séparation des tâches, qui peut être requise par la loi Sarbanes-Oxley ou d'autres normes de conformité. Par exemple : « Un développeur ne peut pas approuver le déploiement de son propre code dans un environnement de test. Le développeur doit archiver le code, qui est automatiquement scanné et déplacé vers la création d'image, où il doit être approuvé par un responsable avant que la création n'ait lieu sur un serveur de test » est un exemple de bonne pratique de séparation des tâches. L'application de ces politiques peut être automatisée, et cela également est activé via RBAC.
Sécurité individuelle et collaborative
Semblable à la sécurisation des processus, garantir un accès sécurisé aux individus et à la collaboration en équipe commence par la gestion de l’accès des utilisateurs en activant RBAC. Les personnes participant au développement de logiciels doivent avoir des droits d'accès différents en fonction de leur rôle, qu'il s'agisse de développeur, de testeur, de gestionnaire, etc. Cela devient particulièrement compliqué dans un environnement distribué à grande échelle, où plusieurs équipes contribuent à une application, où plusieurs utilisateurs contribuent à plusieurs microservices qui sont combinés de différentes manières pour différentes applications et où plusieurs équipes travaillent sur plusieurs applications en utilisant différents outils et différentes technologies.
Par exemple, les droits d’accès d’une équipe de banque mobile sont susceptibles d’être très différents de ceux d’une équipe de gestion des risques. Autrement dit, une équipe de services bancaires mobiles ne devrait probablement pas avoir accès au référentiel Git d'une équipe de gestion des risques. Pendant ce temps, un responsable peut avoir un accès en lecture seule aux deux référentiels, tandis qu'une équipe de gestion de build peut avoir un accès complet aux deux.
GIPHY App Key not set. Please check settings