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

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 Keltio

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
Lire plus d'article de ce genre
Consulter nos publications
Comment Keltio m'aide sur le sujet ?
Découvrir notre produit