Standard d'architecture et de sécurité non appliqué sur les projets DevOps

Standard d'architecture et de sécurité non appliqué sur les projets DevOps

Publié le


Do not index
Do not index
Primary Keyword
Lié à Analyse sémantique (Articles liés) 1
Lié à Analyse sémantique (Articles liés)
Statut rédaction
Terminé
Lié à Analyse sémantique (Articles liés) 2

I - Pourquoi est-ce un problème ?

1 - Cela peut créer des failles de sécurité dans le système d'information
Pourquoi est-ce un problème ? Des personnes mal intentionnés pourraient attaquer le SI
Pourquoi est-ce un problème ? S’ils ont accès aux data ou aux applications, ils peuvent mettre à mal le business en demandant des rançons ou en supprimant des données
Pourquoi est-ce un problème ? Cela peut coûter très cher à l’entreprise en argent et en image
2 - Cela peut impacter la qualité de service des projets
Pourquoi est-ce un problème ? Ce impacte directement l’image de l’entreprise et génère souvent des pénalité ou une perte de CA direct pour l’entreprise
Pourquoi est-ce un problème ? Des entreprises font faillite pour moins que ça

II - Les root cause de ce problème

1 - Distance entre les équipes
Les équipes d’architectes et de sécurité n’étant pas forcément dans les équipes projets, il est fréquent de voir des projets ne pas appliquer ces standards pour une ou plusieurs des raisons suivantes :
  • Manque de temps : Les livraisons doivent se faire vite au détriment du reste
  • Ignorance : Les équipes ne connaissent pas forcement tous les standards
2 - Manque d’expérience et de framework sur lesquelles s'appuyer
Quelques soit le niveau de maturité des entreprises dans leurs démarches de transformations et sur le DevOps, il reste compliqué d’avoir le niveau d’expertise et d’expérience requis dans chaque projet afin de faire un choix judicieux en prenant en compte tous les critères suivants :
  • La sécurité
  • La disponibilité (PCA / PRA)
  • La gouvernance (FinOps / Organisation des équipes)

III - Comment évaluer l’impact de ce problème, les questions à se poser

1. Utilisez vous actuellement des standards d’architecture et de sécurité pour vos projets ? 2. Pensez-vous que chacun d’entre eux les respecte ? Pourquoi ? 3. Combien cela coûterait à votre entreprise si un de vos projets se fait attaquer ? 4. Combien cela coûterait à votre entreprise si un projet souffre d’une indisponibilité d’une heure (jour ou autre) ?

IV - Idées de solution pour résoudre ce problème

1 - Apporter des standards by design aux équipes
Les équipes projets n’ayant pas forcément le temps de s’occuper de la sécurité et des contraintes de disponibilités, des démarches de Software Factory / Digital Factory sont un moyen d’apporter ces standards by design.
En effet, grâce à une Digital Factory, les équipes se focalisent sur le développement et les mises en production, tandis qu’une autre équipe composée de DevOps, expert sécurité et architecte, se charge de créer des services pour les projets.
Avantages
  • Tous les collaborateurs sont sensibilisés aux enjeux business de l’entreprise
Inconvénients
  • Cela prend beaucoup d’énergie à former les collaborateurs
Risques
  • Fuite de l’expertise (turnover, mauvaise documentation…)
2 - Rapprocher les équipes d’architecture et de sécurité
Avantages
  • La sécurité est appliquée dès le début du projet
  • Les coûts opérationnels peuvent être optimisés dès le début par les architectes
Inconvénients
  • Demande de réorganiser les équipes si elles ne sont pas déjà dans cet agencement
Risques
  • Assurer un niveau de standard équivalent dans toutes les équipes peut être complexe (niveau d’expertise éparse dans les équipes, silos …)
  • Re-développement multiple des infrastructures (silos, manque de documentation …)
  • Complexité à positionner des experts pour toutes les équipes (expertise rare sur le marché, budgets …)
  • Utilisation des architectes et des experts sécurité sur d’autres sujets (pour livrer plus rapidement, support …)
3 - Créer ou utiliser des référentiels
Avantages
  • Les équipes ont un cahier des charges à suivre pour garantir un niveau de sécurité et de disponibilité équivalent dans toute l’entreprise (ERM, CobiT, ISO 27XXX…)
Inconvénients
  • Chronophage de certifier chaque projet
Risques
  • Les équipes n’appliquent pas les référentiels car trop contraignant pour livrer dans les temps

V - Pourquoi utiliser le Catalogue de Service Keltio

Le catalogue de service Keltio est une plateforme permettant d’apporter des standards d’architecture et de sécurité by design sur les projets via la mise en place d’un catalogue de service DevSecOps.
De cette façon,
les projets :
  • Livrent plus rapidement sans besoin d’expertise DevSecOps
  • Appliquent la sécurité et la disponibilité by design
les architectes :
  • Ont un oeil sur les infras
les équipes sécurité :
  • Peuvent auditer rapidement les infras
  • Peuvent patcher rapidement les infras
les équipes support :
  • Résolvent plus rapidement les incidents

S'inscrire à la newsletter DevSecOps Keltio

Pour recevoir tous les mois des articles d'expertise du domaine

S'inscrire

Écrit par

Kévin Didelot
Kévin Didelot

Kévin est notre super expert DevSecOps et le fondateur de Keltio 👨🏻‍💻