• Accueil / Salesforce / Qu’est-ce que DevSecOps ?…
, Qu&rsquo;est-ce que DevSecOps ? 6 choses que vous devez savoir<span class="wtr-time-wrap after-title"><span class="wtr-time-number">1</span> minutes de lecture</span>

Qu’est-ce que DevSecOps ? 6 choses que vous devez savoir1 minutes de lecture


Si votre entreprise est comme la plupart des entreprises, vous avez beaucoup investi dans votre Salesforce. La plate-forme facilite la personnalisation de votre expérience de Salesforce, mais cela signifie également que vous devez apporter des améliorations constantes pour ajuster les outils à vos processus métier. Dans les systèmes d’engagement, cela peut signifier plusieurs fois par jour. Comme le Moon Shot d’il y a 50 ans, vous devez réussir jour après jour et heure après heure. Contrairement à Apollo 11, votre mission ne se termine pas au bout d’une semaine.

Les failles de sécurité ont fait l’actualité assez souvent ces derniers temps. Le hack de Capital One était un exemple typique de la façon dont une technologie puissante peut être rendue inutile si elle est mal configurée. C’est à vous et à votre équipe de vous assurer que les systèmes sur lesquels vous comptez sont correctement configurés, en particulier pour les systèmes orientés client comme Salesforce.

, Qu&rsquo;est-ce que DevSecOps ? 6 choses que vous devez savoir<span class="wtr-time-wrap after-title"><span class="wtr-time-number">1</span> minutes de lecture</span>

Tirer le meilleur parti de votre investissement est un travail à multiples facettes. Dans cet article, nous nous concentrons sur les aspects liés à l’intersection de DevOps et de la sécurité, connue sous le nom de DevSecOps.

Qu’est-ce que DevSecOps ?

Dans le monde de Salesforce, la sécurité est principalement gérée via des profils, des ensembles d’autorisations et des règles de partage. Ces entités contrôlent :

  • Accès au Service (Autorisations Admin et Login), et
  • Accès aux données au niveau de l’objet, du champ et de l’enregistrement

Ce type de sécurité est important, mais ne représente pas toute l’étendue de ce qu’il faut pour protéger votre investissement. Vous devez également protéger votre Données, paramètres et code source contre les écrasements et suppressions accidentels. En fait, il ne s’agit pas simplement de pouvoir se remettre de ces incidents – le temps nécessaire pour restaurer complètement les objets perdus est également important.

Dans cet article, nous examinerons 6 éléments clés qui ont un impact sur votre pratique DevSecOps sur Salesforce avec des recommandations de bonnes pratiques pour chacun.

#1 : Source unique de vérité

Établir une source unique de vérité (SSoT) dans d’autres plates-formes est assez évident, mais ce n’est pas le cas dans Salesforce où des modifications peuvent être apportées aux environnements de production et de sandbox en un clin d’œil.

Pourquoi est-ce important pour DevSecOps ? Tout est question de travail perdu. Les modifications apportées en production ou en test peuvent être facilement effacées lors du prochain déploiement. Si les modifications sont apportées strictement dans les environnements de développement et enregistrées dans un système de contrôle de version comme Git, les risques d’écrasement sont réduits. Cela permet aux administrateurs et aux développeurs d’utiliser la même source de vérité pour capturer les modifications. C’est aussi la première étape de notre prochain sujet : Audit Trail.

#2 : Piste d’audit

En matière de conformité et de sécurité, il ne s’agit pas seulement de s’assurer que vous effectuez les bons changements. Souvent, vous devez être en mesure de prouver que vous avez fait la bonne chose et prouver que la mauvaise chose n’a jamais été faite. C’est là qu’intervient la piste d’audit.

En termes simples, une piste d’audit répond aux questions suivantes :

  • Qui a fait le changement ?
  • Quand a-t-il été fabriqué ?
  • Qu’est-ce qui a été changé ?
  • Pourquoi le changement a-t-il été fait.

L’établissement d’un dépôt Git en tant que SSoT vous donne une longueur d’avance. Il capture toutes les modifications apportées à vos paramètres et à votre code. Il peut même être utilisé pour capturer vos modifications de données de configuration, ce qui est important pour des applications telles que CPQ. La capture des modifications dans Salesforce va encore plus loin et crée un enregistrement d’audit qui peut être signalé à l’aide des rapports standard de Salesforce.

Copado recommande les User Stories comme unité de publication pour la gestion du changement. L’avantage de votre piste d’audit est que les histoires d’utilisateurs capturent non seulement le qui, le quoi et le quand, mais également le pourquoi. Cela n’est généralement pas fait dans un dépôt Git.

#3 : Portes de qualité

Protéger votre investissement Salesforce signifie protéger toutes les améliorations fonctionnelles que vous avez réalisées à ce jour. Certaines organisations ont consacré des milliers d’heures-personnes de travail pour que leur implémentation existante fonctionne comme elles le souhaitent. Un mauvais changement peut annuler une grande partie de cet investissement. Les barrières de qualité ne consistent pas seulement à garantir que les nouvelles fonctionnalités fonctionnent comme prévu, mais également à garantir que les nouvelles fonctionnalités ne brisent pas les anciennes.

Les tests fonctionnels sont l’aspect de la qualité qui garantit que les fonctionnalités fonctionnent comme prévu. Selenium, Provar et Fusion sont des outils qui peuvent aider à cette vérification.

La qualité du code source est souvent négligée. Pourquoi devriez-vous vous en soucier si le code source est écrit selon certaines règles de style ? C’est comme maintenir une bonne alimentation et faire de l’exercice. Manger de la malbouffe et sauter la salle de gym pendant quelques jours ne vous tuera pas tout de suite, mais attention à long terme. Le développement de logiciels d’entreprise est un sport d’équipe. L’écriture de code par rapport à une norme de style d’entreprise garantit que le prochain développeur qui y travaillera comprendra ce qu’il voit. L’analyse de code statique peut cependant faire bien plus qu’appliquer le style. Il peut découvrir de mauvaises pratiques telles que le DML à l’intérieur de boucles imbriquées qui ont un impact sur les performances du code et peuvent entraîner l’atteinte des limites Apex sur la plate-forme Salesforce.

Les tests unitaires sont un moyen simple de s’assurer que le code fonctionne comme prévu. La couverture de test Apex peut sembler pénible, mais maintenir une couverture minimale sera payante à long terme si les ingénieurs adoptent vraiment la pratique et n’essaient pas de jouer avec le système.

#4 : Conformité

Les analyses et la surveillance automatisées de la conformité ne sont pas largement utilisées dans le monde Salesforce, mais elles devraient l’être.

Les analyses de conformité permettent de garantir que les types de modifications suivants n’ouvrent pas de failles de sécurité dans votre service Salesforce :

  • Contrôles d’accès au système – Plages IP, heures de connexion
  • Contrôles d’accès aux données – Sécurité au niveau des objets et des champs
  • Contrôles d’accès aux enregistrements – Règles de partage

La clé ici est de garantir l’accès le moins privilégié, ce qui signifie qu’aucun utilisateur n’a accès aux informations dont il n’a pas besoin pour faire son travail. C’est une chose difficile à faire et souvent gênante, mais les conséquences sont souvent plus… gênantes.

Un bon système de conformité peut alerter et empêcher les déploiements qui violent les règles. Il peut également être réglé pour fournir des niveaux de contrôle appropriés à chaque étape du pipeline de développement. La création d’un ensemble complet de règles pour votre organisation prendra du temps, mais c’est un investissement qui peut sauver votre organisation des amendes de cent millions de dollars subies récemment par Capital One, British Airways et Marriott.

#5 : Sauvegardes

La plupart des organisations considèrent les sauvegardes comme une protection des données. Dans Salesforce, la protection de vos métadonnées est tout aussi importante. Un problème récent avec la perte de profils a mis en lumière ce problème. De nombreuses organisations n’étaient pas prêtes à restaurer les derniers profils pour tous les utilisateurs simplement parce qu’elles ne disposaient pas d’une copie enregistrée des derniers profils pour tous les utilisateurs. Sauvegardez donc non seulement vos données, mais également votre code et vos configurations.

À quelle fréquence devez-vous sauvegarder ? La réponse courte pour vos métadonnées est que vous devez mettre en place un processus de publication qui capture chaque changement tel qu’il se produit dans chaque environnement. L’utilisation de Git en tant que SSoT avec des modifications liées aux histoires d’utilisateurs fournira les sauvegardes nécessaires pour la restauration et la restauration.

Les sauvegardes de données sont plus difficiles en raison de la taille des ensembles de données impliqués. Prendre un instantané à un moment donné est utile mais pas pratique sur une base continue. Sélectionnez un outil de sauvegarde qui peut effectuer des sauvegardes incrémentielles continues et qui vous permet facilement de restaurer votre organisation à un moment donné à l’aide de ces enregistrements.

#6 : Promotion vs. Surveillance

La dernière chose à considérer pour votre plan est l’équilibre entre la réalisation de tests pendant la promotion d’un changement d’un environnement à un autre, par rapport à l’analyse de l’ensemble de l’environnement à chaque changement. L’exécution de tous les tests Apex et tests fonctionnels peut prendre des heures dans un environnement d’entreprise. Dans un monde de livraison continue où les changements affectent un environnement plusieurs fois par heure, un test complet ne démarre pas plus tôt qu’il doit recommencer en raison d’un autre changement.

Dans ce scénario, il est préférable pour les entreprises d’exécuter des tests limités aux modifications individuelles pendant la promotion et d’exécuter des tests à l’échelle de l’environnement sur une base planifiée. Dans le meilleur des mondes possibles, vos outils DevOps pourraient identifier l’étendue de l’impact et effectuer uniquement les tests requis. L’industrie n’en est pas encore là, mais restez à l’écoute.

Résumé

La protection de votre investissement Salesforce est importante, mais comme la plupart des objectifs liés à la sécurité, il s’agit au mieux d’un travail en cours. Vous n’aurez peut-être jamais terminé, mais cela ne signifie pas que vous ne devriez pas commencer. Prenez du recul et réfléchissez à vos priorités. Si vous travaillez pour une entreprise de services financiers ou de soins de santé, vos contrôles d’accès aux données peuvent être votre priorité numéro un. Pour d’autres entreprises, la continuité des activités peut être primordiale. Quelle que soit votre situation, élaborez un plan hiérarchisé et lancez-vous. Automatisez ce que vous pouvez et utilisez les processus d’approbation là où vous ne pouvez pas. Alors lancez-vous. Lent et régulier ne gagnera peut-être pas la course, mais cela pourrait certainement minimiser vos pertes. Il suffit de demander à Capital One.

, Qu&rsquo;est-ce que DevSecOps ? 6 choses que vous devez savoir<span class="wtr-time-wrap after-title"><span class="wtr-time-number">1</span> minutes de lecture</span>



Source de l’article traduit automatiquement en Français

Besoin d'aide ?
Vous utilisez Pardot depuis un certain temps mais vous n'êtes pas sûr d'en
exploiter tout le potentiel

Notre analyse de votre Pardot offerte dès aujourd'hui
Merci, vous pouvez compléter notre questionnaire
Nous allons revenir vers vous rapidement !

Fermer