Chez PagerDuty, nous prenons la sécurité très au sérieux. Pour nous, la sécurité signifie protéger les données des clients et garantir que les clients peuvent communiquer en toute sécurité avec PagerDuty. Étant donné l’importance que nous accordons à la haute disponibilité, nous accordons une grande attention à la manière dont nous concevons et surveillons notre infrastructure de sécurité.

Dans un environnement dynamique comme celui de PagerDuty, assurer une sécurité robuste au niveau de l'hôte et du réseau n'est pas facile. Le faire d’une manière distribuée, tolérante aux pannes et indépendante du fournisseur d’hébergement introduit encore plus de défis. Dans cette série d'articles de blog, nous souhaitions mettre en évidence certaines des stratégies et techniques utilisées par l'équipe d'ingénierie des opérations de PagerDuty pour sécuriser la plate-forme PagerDuty et protéger les données des clients.

Voici quelques-unes des meilleures pratiques que nous suivons en matière de sécurité :

Établir des normes internes

Toutes nos décisions internes en matière de sécurité vont à l'encontre d'une liste de philosophies et de conventions que nous respectons. Cette liste n'est pas gravée dans la pierre, car nous la mettons à jour lorsque nous découvrons des problèmes, mais elle nous oblige à comprendre où nous faisons des compromis et nous aide dans notre prise de décision. Elle permet également aux nouveaux ingénieurs de comprendre rapidement pourquoi les choses sont configurées de cette manière.

Sécurisé par défaut

Nous suivons une convention de sécurisation de tout par défaut, ce qui signifie que la désactivation de tout service de sécurité doit être effectuée via une règle de remplacement ou d'exception. Cela permet de garantir la cohérence dans nos environnements de développement, de test et de production.

Il est tentant de percer un trou dans le pare-feu local ou de désactiver SSL lors de la connexion à MySQL, mais nous ne souhaitons pas effectuer ce type de modifications de sécurité dans nos environnements de production ou de test. Configurer nos outils pour qu'ils « fassent automatiquement ce qu'il faut » permet à tous nos ingénieurs de rester honnêtes. De plus, en ayant ce type de cohérence, nous pouvons déboguer les problèmes liés à la sécurité plus tôt dans le cycle de développement.

Supposons un réseau hostile et instable

L'ensemble de notre infrastructure est déployée auprès de fournisseurs d'hébergement cloud, dont nous ne pouvons pas contrôler les réseaux. De plus, nous sommes déployés dans plusieurs régions, de sorte qu'une bonne partie de notre trafic de données passe par le WAN. Cela pose des problèmes de perte de paquets et de latence élevée, ainsi que la possibilité que des intrus tentent d'écouter notre trafic.

Dans cette optique, nous cryptons toutes les données en transit et partons toujours du principe que nos données circulent sur des réseaux où nous avons peu de visibilité.

Soyez indépendant du fournisseur

Groupes de sécurité, VPC, consoles de secours, etc. Ce sont tous des exemples d'outils spécifiques à un fournisseur que nous ne pouvons pas utiliser car nous sommes répartis entre plusieurs fournisseurs d'hébergement et devons éviter de dépendre d'un fournisseur. Tous nos outils de sécurité doivent être basés sur des outils Linux ou des packages installables couramment disponibles, ce qui élimine notre dépendance aux outils de sécurité spécifiques à chaque fournisseur et conduit à une meilleure stabilité. Nous utilisons Chef pour effectuer la plupart de ce travail à notre place et avons développé presque tous nos outils sur cette base.

Centraliser la gestion des politiques et répartir leur application

La plupart des entreprises abordent la question de l'authentification, de l'autorisation et de l'accès (AAA) en ayant des sources uniques de vérité pour le contrôle d'accès, puis en utilisant également cette source de vérité comme mécanisme d'autorisation. Par exemple, l'utilisation d'un serveur LDAP, d'un serveur RADIUS ou d'un pare-feu de périmètre pour stocker les politiques réseau. Au lieu de s'appuyer sur ces sources uniques de vérité pour la gestion et l'application des politiques, nous divisons et distribuons les éléments d'application aux différents nœuds du réseau. Notre modèle typique est que lorsqu'un changement est introduit dans le réseau, la source unique de vérité met à jour la politique, puis est diffusée vers tous les nœuds.

Valider en permanence

Bien que tout ce qui précède serve à fournir une architecture de sécurité robuste, il est important que nous validions nos mesures de sécurité pour garantir qu’elles font ce dont nous avons réellement besoin.

Certaines entreprises effectuent des tests d'intrusion trimestriels, mais dans notre environnement dynamique, cela est trop lent. Nous analysons, surveillons et alertons activement sur les changements (avec PagerDuty) lorsqu'il y a quelque chose qui n'est pas attendu. Nous détectons rapidement les problèmes si une erreur est commise (par exemple, un ingénieur ouvre accidentellement le mauvais port réseau sur un serveur) ou en cas de comportement malveillant réel (par exemple, quelqu'un essayant de forcer brutalement un point de terminaison), nous sommes immédiatement alertés du problème.

Ceci est le premier article d'une série sur la façon dont nous gérons la sécurité chez PagerDuty. Pour continuer à lire cette série, consultez Définition et distribution des protocoles de sécurité pour la tolérance aux pannes