Voici le deuxième article d'une série consacrée à la gestion de la sécurité chez PagerDuty. Pour commencer, consultez : Comment nous assurons la sécurité de PagerDuty pour nos clients .

La haute disponibilité et la fiabilité sont primordiales chez PagerDuty. Nous avons consacré énormément de temps à concevoir et à architecturer notre service afin de résister aux pannes affectant les serveurs, les centres de données, les régions, les fournisseurs, les dépendances externes et bien d'autres facteurs. Mais étant donné que les pannes sont inévitables, comment intégrer la tolérance aux pannes à notre système de sécurité ?

Deux points importants à retenir : premièrement, l’utilisation de matériel réseau ou de sécurité dédié pose le problème des points de défaillance uniques, où la panne d’un dispositif VPN peut paralyser un centre de données entier. Deuxièmement, dans un modèle de sécurité où seule la périphérie du réseau est protégée, un attaquant capable de pénétrer cette unique couche aura accès à l’ensemble du système.

Pour éviter ces problèmes, notre approche globale consiste à gérer de manière centralisée nos politiques de sécurité et à les appliquer à tous les nœuds. Chaque nœud est responsable de la consultation des définitions de politique, ainsi que de la définition et de l'application d'un ensemble de règles personnalisé.

Pare-feu locaux calculés dynamiquement

La première stratégie que nous avons mise en œuvre dans notre modèle de gestion centralisée/application distribuée a été celle de nos pare-feu dynamiques.

Ces deux dernières années, nous avons migré PagerDuty vers une architecture orientée services (SOA), ce qui nous permet de mieux isoler chaque service et de limiter les déplacements latéraux. Lors de la création d'un nouveau cluster de serveurs dans Chef, nous configurons également les règles de pare-feu définissant le groupe auquel appartient chaque serveur et les groupes autorisés à communiquer avec lui. Ainsi, chaque serveur peut créer automatiquement des chaînes IPTables complètes, ouvrir les ports de service appropriés et bloquer tout autre trafic. Par conséquent, l'ajout ou la suppression d'un serveur ne nécessite aucune mise à jour des politiques : les nœuds détectent le changement et recalculent les règles en conséquence.

Nous avons constaté de nombreux avantages grâce à cette approche :

• Nous pouvons facilement créer des partitions réseau en cas de besoin. (C'est ainsi que nous nous assurons que nos environnements de développement, de test et de production ne puissent pas communiquer entre eux.)

• Nous pouvons isoler des serveurs individuels lorsque nous avons besoin de nous entraîner à les attaquer.

• Nous pouvons facilement déterminer quels serveurs communiquent entre eux car toutes les règles entrantes doivent être définies au préalable.

• Nous utilisons un système de configuration IPTables Linux simple et direct. En cas de problème de pare-feu, chaque ingénieur sait comment le configurer et déployer une solution.

• Il n'existe aucun dispositif réseau présentant un point de défaillance unique. Si un serveur tombe en panne ou si un incident plus grave survient, le reste du système continuera de fonctionner en toute sécurité.

Chiffrement du trafic distribué

Pour chiffrer le trafic réseau, il existe deux méthodes dominantes que la plupart des utilisateurs utilisent : les réseaux privés virtuels (VPN) et le chiffrement par application/service, mais nous avons constaté des problèmes avec les deux.

Une implémentation VPN classique avec des passerelles dédiées dans chacune de nos régions AWS et Linode aurait présenté un certain nombre de problèmes :

• Le système présente un point de défaillance quasi unique. Même avec plusieurs passerelles déployées dans chaque région, la défaillance d'un serveur de passerelle entraîne soit un basculement, soit une réduction de capacité, ce qui provoque des problèmes de connectivité.

• Coût et évolutivité. Comme nous utilisons des machines virtuelles standard et non du matériel réseau dédié, nous aurions besoin d'instances très volumineuses pour chiffrer et déchiffrer le trafic des serveurs sous-jacents. Nous étions préoccupés par la capacité des passerelles VPN classiques à absorber nos pics de trafic.

• Latence. Étant donné que nous effectuons déjà des appels interrégionaux, nous souhaitons réduire au minimum le nombre de sauts lors de la connexion à des serveurs non locaux.

Les méthodes de chiffrement par application/service – comme le fait de forcer MySQL à n'autoriser que les connexions SSL ou de s'assurer que Cassandra utilise le chiffrement inter-nœuds – ont leur place dans notre cadre de sécurité. Cependant, cette approche exclusive présente des problèmes :

• C'est facile à oublier. Bien que la sécurité fasse partie du travail de chacun en entreprise, il arrive souvent que l'on oublie d'activer les paramètres de sécurité appropriés.

• Chaque application ou service utilise une méthode de chiffrement des données légèrement différente. Bien que la plupart des bibliothèques de connexion prennent en charge SSL, son implémentation peut varier. Par conséquent, à chaque ajout d'un nouveau service, il est nécessaire de repenser la gestion du chiffrement.

Pour résoudre les problèmes mentionnés, nous avons implémenté un modèle de chiffrement point à point basé sur IPSec en mode transport. Cela permet de chiffrer tout le trafic entre les nœuds spécifiés du réseau, indépendamment de leur emplacement et des nœuds avec lesquels ils communiquent. Nous avons, comme à notre habitude, géré les politiques de sécurité de manière centralisée en calculant les relations sur un serveur Chef, puis en les déployant sur chaque nœud.

L'utilisation du chiffrement point à point au lieu du modèle VPN traditionnel présente plusieurs avantages :

• Chiffrement décentralisé. Au lieu de dépendre de passerelles VPN critiques, chaque nœud peut gérer son propre chiffrement (éliminant ainsi les points de défaillance uniques).

• Évolutivité. Les relations n'étant calculées que pour les nœuds avec lesquels un nœud donné doit communiquer (et non pour chaque nœud), la surcharge liée au chiffrement est très faible. Lors de nos premiers tests, nous avons constaté une baisse de performance lorsqu'un nœud devait communiquer avec des milliers de nœuds. Toutefois, tant que nos services restent isolés et confinés, ce modèle devrait répondre à nos besoins.

• Efficacité. Nous tirons pleinement parti du matériel AES dédié intégré à la plupart des puces modernes. De plus, grâce au chiffrement et à la compression du trafic, l'impact sur le débit de notre réseau n'est que de 2 à 3 %.

• Chiffrement au sein des centres de données. L'acheminement du trafic via des liaisons dédiées, que ce soit au sein d'un même centre de données ou entre différents centres, est généralement sécurisé. Cependant, des incidents récents ont fait planer le spectre de failles de sécurité sur ce type de connexions. Le chiffrement point à point offre une meilleure alternative.

• Une dépendance en moins vis-à-vis du NAT. Avec la généralisation de l'IPv6 et d'un espace d'adressage global sur les réseaux, l'espace d'adressage privé fourni par les VPN devra être repensé. Notre modèle point à point prend facilement en charge un espace d'adressage global.

• Chiffrement de bout en bout intégral. Commutateurs, routeurs, points d'interception fibre optique, hôtes voisins, fournisseurs d'hébergement : autant de vecteurs d'intrusion potentiels. En chiffrant le trafic de bout en bout, même si un intrus parvenait à intercepter nos données, il lui serait impossible d'en lire la moindre information.

Contrôle d'accès basé sur les rôles

PagerDuty applique le principe du moindre privilège. Concrètement, cela signifie que les ingénieurs n'ont accès qu'aux serveurs nécessaires à leur travail. Nous utilisons Chef, associé à des utilisateurs et groupes Linux classiques, pour mettre en place nos contrôles d'accès.

Lorsqu'un nouvel utilisateur est ajouté à notre infrastructure, il est nécessaire d'ajouter les groupes auxquels il appartient. De même, lorsqu'un nouveau groupe de serveurs est ajouté, il faut spécifier les groupes d'utilisateurs autorisés à y accéder. Ces informations nous permettent de créer les fichiers de configuration (passwd et group) sur chaque hôte. Le stockage de ces données dans des fichiers JSON et leur gestion de versions facilitent l'intégration des demandes d'accès et des approbations à notre processus de revue de code.