Ceci est le deuxième article d'une série sur la façon dont nous gérons la sécurité chez PagerDuty. Pour commencer depuis le début, consultez, Comment nous garantissons que PagerDuty est sécurisé pour nos clients .

La haute disponibilité et la fiabilité sont extrêmement importantes ici chez PagerDuty. Nous avons passé énormément de temps à concevoir et à structurer notre service pour résister aux pannes des serveurs, des centres de données, des régions, des fournisseurs, des dépendances externes et de nombreux autres facteurs. Mais étant donné que l’échec est inévitable, comment intégrer la tolérance aux pannes dans notre système de sécurité ?

Deux choses à garder à l'esprit : tout d'abord, le matériel de sécurité ou de réseau dédié pose le problème des points de défaillance uniques, où une défaillance d'un appareil VPN peut mettre hors service un centre de données entier. Ensuite, 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 seule couche aura accès à tout.

Pour éviter que ces problèmes ne surviennent, notre approche globale a consisté à gérer de manière centralisée nos politiques de sécurité et à les appliquer à tous les nœuds. Chaque nœud est chargé de rechercher les définitions de politiques ainsi que de dériver et d'appliquer un ensemble de règles personnalisées.

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 était nos pare-feu dynamiques.

Nous avons migré PagerDuty vers une architecture orientée services au cours des deux dernières années, et avec cela, nous avons la possibilité de mieux isoler chaque service et de contenir les mouvements latéraux. Lorsque nous définissons un nouveau cluster de serveurs dans Chef, nous configurons également l'ensemble de règles pour les pare-feu qui définissent à quel groupe appartient ce serveur et quels groupes peuvent communiquer avec ce groupe. À partir de là, chaque serveur est capable de créer automatiquement des chaînes IPTables entières, d'ouvrir des ports de service pour les sources appropriées et d'abandonner tout autre trafic. Cela signifie que chaque fois qu'un serveur est ajouté/supprimé, nous n'avons pas besoin de mettre à jour les politiques. Au lieu de cela, les nœuds détecteront le changement et recalculeront l’ensemble de règles.

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

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

• Nous pouvons isoler des serveurs individuels lorsque nous devons 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 à l’avance.

• Nous utilisons des tables IP Linux simples et directes. En cas de problème de pare-feu, chaque ingénieur sait comment manipuler le pare-feu et déployer un correctif.

• Il n'existe pas de point de défaillance unique sur le réseau. Si un serveur tombe en panne ou si un événement plus catastrophique se produit, le reste du système continuera de fonctionner de manière sécurisée.

Chiffrement du trafic distribué

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

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

• Point de défaillance quasi unique. Même si vous déployez plusieurs passerelles dans chaque région, chaque fois qu'un serveur de passerelle est déconnecté, un basculement ou une réduction de capacité est alors nécessaire. Cela entraînera des problèmes de connectivité.

• Coût et évolutivité. Étant donné que nous utilisons des machines virtuelles standard et non du matériel réseau dédié, nous devrions utiliser des tailles d'instance très importantes pour chiffrer et déchiffrer le trafic des serveurs situés derrière elles. Nous étions préoccupés par la capacité des passerelles VPN conventionnelles à évoluer avec nos pics de trafic.

• Latence. Étant donné que nous effectuons déjà des appels interrégionaux, nous souhaitons effectuer le moins de sauts possible lors de la connexion à des serveurs non locaux.

Les méthodes de chiffrement par application/service, comme forcer MySQL à autoriser uniquement les connexions SSL ou s'assurer que Cassandra utilise le chiffrement entre les nœuds, ont leur place dans notre cadre de sécurité. Mais l'utilisation exclusive de cette approche pose des problèmes :

• Il est facile de l'oublier. Bien que la sécurité fasse partie des tâches de chacun dans une entreprise, les gens oublient souvent d'activer les paramètres de sécurité appropriés.

• Chaque application/service a une manière légèrement différente de crypter les données. Bien que la plupart des bibliothèques de connexion prennent en charge SSL, cette méthode peut être implémentée différemment à chaque fois. De plus, cela signifie que chaque fois que nous ajoutons un nouveau service, nous devons repenser la manière de gérer le cryptage.

Pour résoudre les problèmes ci-dessus, 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 des nœuds spécifiés sur le réseau, quel que soit l'emplacement du nœud et les autres nœuds avec lesquels il communique. Là encore, nous avons suivi notre convention de gestion centralisée des politiques en calculant les relations sur un serveur Chef, puis en les transmettant à chaque nœud.

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

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

• Évolutivité. Étant donné que les relations ne sont calculées que pour les nœuds avec lesquels un seul nœud doit communiquer (par opposition à tous les nœuds), la surcharge du chiffrement est assez faible. Dans nos tests initiaux, nous avons constaté que les performances souffraient lorsqu'un nœud devait communiquer avec des milliers de nœuds, mais tant que nos services restent isolés et contenus, ce modèle devrait s'adapter à nos besoins.

• Efficacité. Nous pouvons tirer parti du matériel AES dédié fourni avec la plupart des chipsets modernes. De plus, comme le trafic est chiffré et compressé, nous n'avons constaté qu'un impact de 2 à 3 % sur le débit de notre réseau.

• Chiffrement au sein du centre de données. L'envoi de trafic via des liens dédiés au sein ou entre des centres de données est généralement sécurisé, mais des événements récents ont fait surgir le spectre de failles de sécurité dans ce type de connexions. Le chiffrement point à point offre une meilleure alternative.

• Une dépendance de moins à la NAT. Comme de plus en plus de réseaux prennent en charge IPv6 et un espace d'adressage global, l'espace d'adressage privé fourni par les VPN devra être refait. Notre modèle point à point prend facilement en charge un espace d'adressage global.

• Chiffrement complet de bout en bout. Les commutateurs, les routeurs, les prises de fibre optique, les hôtes voisins, les fournisseurs d'hébergement eux-mêmes. Ce sont tous des exemples de vecteurs d'intrusion potentiels. En chiffrant le trafic de bout en bout, même si un intrus parvenait à capturer notre trafic, il serait incapable de le lire.

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

PagerDuty suit un modèle d'autorisations de moindre privilège. Fondamentalement, cela signifie que les ingénieurs n’ont accès qu’aux serveurs dont ils ont besoin pour accomplir leur travail. Nous exploitons Chef, de concert avec des utilisateurs/groupes Linux simples, pour développer nos contrôles d'accès.

Chaque fois que nous ajoutons un nouvel utilisateur à notre infrastructure, nous devons ajouter les groupes auxquels cet utilisateur appartient. Chaque fois que nous ajoutons un nouveau groupe de serveurs, nous devons spécifier quels groupes d'utilisateurs ont accès à ces serveurs. Grâce à ces informations, nous sommes en mesure de créer les fichiers passwd et group sur chaque hôte. Étant donné que tout cela est stocké dans des fichiers de configuration JSON et qu'il est sous contrôle de version, il est facile d'intégrer les demandes d'accès/approbations dans notre processus de révision de code.