Mon métier de Cloud Security Architect

Mon métier de Cloud Security Architect

Pour faire écho aux articles récents de Damy.R, et mcorbin, je me suis dit qu’il serait sympa que je vous explique en quoi consistait mon métier :

À la découverte du métier de consultant cloud et DevOps
Envie de découvrir le quotidien d’un consultant cloud et DevOps ?
(mcorbin.fr): Le métier de développeur Cloud

En effet les métiers de l’IT sont très nombreux, et il est parfois compliqué de comprendre ce qui se cache derrière nos étiquettes.

Consultant avant tout

Tout comme mon collègue Damyr, je suis un consultant pour WeScale, je travaille donc en prestation pour des clients pour des missions plus ou moins longues.

Être consultant n’est pas forcément un métier adapté à tous, en effet, il faut accepter de changer de contexte régulièrement, de repartir de zéro sur certains sujets, de se "faire sa place" dans l’entreprise du client.

Mais pour moi, c’est aussi une richesse. Cela me permet de voir plein de secteurs d’activités différents, de comprendre des problématiques diverses, de faire des choses différentes avec des outils différents.

Toutefois, il faut se méfier de certaines entreprises de services (ESN/SSII), car elles ne valorisent pas forcément l’aspect humain, mais uniquement l’argent que rapporte le sac de viande qu’on va mettre chez un client. Ce terme peut paraître brutal, mais c’est malheureusement quelque chose de vécu (et que j’ai entendu de la bouche même de mon manager…).

Le consulting peut aussi être un vrai tremplin, car cela permet de voir beaucoup plus de choses différentes, parfois sur le même sujet, ce qui permet de vite monter en compétence via l’expérience. Ça peut aussi parfois se retourner contre soi lorsqu’on est "survendu", c’est d’ailleurs un point que j’avais abordé il y a quelque temps :

Recrutement dans l’IT : Les rôles se sont inversés
Comme beaucoup de personnes évoluant dans le monde du travail aujourd’hui qui sefont aujourd’hui chasser, je suis présent (entre autre) sur des réseaux sociauxtels que LinkedIn. Pourtant, de part mon passé professionnel, je fais parti desgens qui ont eu beaucoup de mal à décrocher leur premier em…

De la sécurité, mais pas que

Au vu du titre de mon poste, vous vous doutez que je fais de la sécurité. Toutefois, limiter le poste à ce simple terme est réducteur.

Pour beaucoup la sécurité signifie mettre 12 solutions de tests, faire des audits et empêcher les gens de travailler.

Pourtant la discipline de la sécurité est quelque chose de très vaste en entreprise, la sécurité c’est, entre autres :

  • La sécurité des utilisateurs (IAM : Identity and Access Management)
  • La sécurité des applications
  • Le suivi des versions et dépendances
  • L’étude de risque
  • La communication, la sensibilisation
  • de la veille technologique
  • de la gouvernance

Comme vous pouvez le voir, c’est un domaine qui est déjà assez large.

De l'architecture avant la sécurité

Avant de passer du côté sécurité de la force, j’ai d’abord été Cloud Architect. Un architecte est là pour étudier les besoins technicofonctionnels d’une application pour savoir comment y répondre au mieux que ce soit :

  • Au niveau de la complexité
  • Au niveau du MCO
  • Au niveau des coûts
  • Au niveau des RTO (Temps de retour en ligne en cas d’incident) et RPO (Perte de donnée tolérable en cas d’incident) identifiés
  • Au niveau de la sécurité

Le tout s’inscrivant dans le paysage du système d’information de l’entreprise. En entreprise on essaiera autant que possible d’avoir un modèle "blueprint" réutilisable d’un projet à un autre.

L’architecture demande de fait d’avoir une connaissance assez large des technologies, limitations et fonctionnement des clouds providers, sans pour autant être un expert dessus.

Pour ma part, je suis spécialisé sur AWS, même si je compte me diversifier un peu.

Le rôle d’un architecte est donc de convertir ce besoin technicofonctionnel en réponse d’infrastructure, qui sert de base pour la mise en place de l’applicatif par les équipes DevOps. Cela passe souvent par la rédaction de dossier d’architecture, document regroupant les besoins, les informations sur les RTO/RPO, les schémas de l’infrastructure cible, les flux réseau (voire fonctionnels), le but de ce document est d’avoir une vision d’ensemble cohérente de l’application et de connaître ses adhérences avec les autres.

Pas que de la documentation

D’après ce que je viens de dire, on imagine aisément l’architecte comme étant quelqu’un qui fait de la documentation toute la journée. Pourtant ce n’est pas complètement ça non plus !

Une partie de mon travail consiste aussi à faire de la réalisation :

  • Application/script pour gérer les identités
  • Tests d’application, d’infrastructure (pour éviter de proposer des choses qui ne fonctionnent pas ou sont inadaptées)
  • Automatisation en tout genre (export d’alarmes par exemple)

De plus, une des facettes primordiales de mon métier est la partie conseil, très souvent dans une posture SecOps, je suis aussi là pour accompagner les équipes et les aider à trouver les solutions adaptées ET sécurisées pour leur besoin.

C’est d’ailleurs un point que j’avais abordé dernièrement :

Pour une posture efficace de la sécurité
Je travaille dans le domaine de l’IT depuis plus de 10 ans maintenant et j’aicôtoyé pas mal d’équipes “sécurité” au sein des entreprises dans lesquelles jesuis passé. Je suis moi-même un “security guy” (Cloud Security Architect) depuisun peu plus d’un an. Durant ces années, j’ai souvent constaté…

Mes missions

Pour vous donner une idée, voici quelques missions que je fais/j’ai fait pour WeScale :

  • Accompagnement pour la mise en place d’IAM technique et humain sur AWS
  • Audit de sécurité suite à des attaques DDOS
  • Remplacement de l’IAM sur un site exposé publiquement (en binôme, pour ma part, je documente et design la solution)
  • Création et animation d’une formation "DevSecOps awareness"

Comme vous pouvez le voir, il y a des missions clairement distinctes, de la simple posture de conseil à la réalisation et l’implémentation de solution.

C’est un rôle qui me plait justement pour sa richesse, le fait de pouvoir toucher plein de domaines différents tout en ayant une ligne directrice : la sécurité.

Un des aspects que je n’ai pas évoqués est aussi l’énorme part que prend la veille technologique, d’autant plus dans le domaine de la sécurité. Le télétravail généralisé a augmenté le rythme des attaques et plus que jamais il n’est nécessaire d’être au courant des derniers modèles d’attaques !

Pour terminer

La description que je fais du poste est basée uniquement sur mon expérience, il faut bien noter que d’une entreprise à une autre, le même intitulé de poste peut signifier des choses bien distinctes. Un titre n’est qu’une étiquette, et il est important de ne pas s’y fier aveuglément, mais plutôt de demander une fiche de poste, censée décrire la mission.

La prestation est un modèle que j’ai choisi, bien que j’ai été à quelques reprises en interne, je me sens plus libre en tant que prestataire, tout du moins actuellement. Il faut bien comprendre que ce modèle n’est pas adapté à tout le monde, et il n’y a aucun mal à préférer la stabilité de son poste !

Les métiers de l’IT sont pour beaucoup très riches, et vont bien au-delà de ce qu’un simple titre peut vouloir dire, je pense que nous (professionnels de l’IT) avons tout à gagner à promouvoir ce que nous faisons afin de mieux cerner la complexité et l’intérêt de nos métiers.