Vous avez peut-être entendu parler des récentes violations de données provenant de serveurs ElasticSearch non sécurisés et directement connectés à Internet.
C’est pour cette raison qu’il existe des normes de sécurité et des réglementations telles que PCI/DSS, permettant une vérification des pare-feux. Dans un Cloud public, il est aisé de mettre à jour les groupes de sécurité pour effectuer des tests et de complètement oublier ces modifications. Une séparation des tâches peut éviter cette situation, mais les problèmes ont souvent plusieurs origines.
Le mot d’ordre de l’équipe sécurité de Nuxeo est automatisation. Il nous a donc semblé évident d’affronter cette nouvelle problématique de façon automatisée. Dans cet article, je vais vous expliquer comment nous avons automatisé le processus de vérification des pare-feux et nos prochains objectifs en matière d’automatisation de la sécurité.
Nous traitons déjà tous les événements CloudTrail en temps réel et nous avons ainsi ajouté un token à la fin de la règle de chaque groupe de sécurité, comme preuve de validation par notre équipe sécurité. Ces tokens sont ensuite appliqués dans notre environnement de production et toute règle qui n’en contient pas sera supprimée automatiquement.
La règle d’un groupe de sécurité comprend plusieurs attributs : Protocol, Type, Target, Port, Description.
Nous avons choisi d’utiliser l’attribut Description pour ajouter le token. Voici un exemple :
| Type | Protocol | Target | Port | Description | |
|---|---|---|---|---|---|
| Règle | INGRESS | TCP | 1.1.1.1 | 22 | NYC Office |
| Règle avec token | INGRESS | TCP | 1.1.1.1 | 22 | NYC Office$TK123 |
| Token (TK123) | INGRESS | TCP | 1.1.1.1 | 22 | NYC Office |
Puisque chaque client est déployé dans un Cloud virtuel privé (VPC) séparé, nous faisons appel à une expression régulière pour valider le déploiement dans son ensemble :
| Type | Protocol | Target | Port | Description | |
|---|---|---|---|---|---|
| Rule | INGRESS | TCP | My-core-app-sg | 22 | NYC Office |
| Rule with Token | INGRESS | TCP | My-core-app-sg | 22 | NYC Office$TK124 |
| Token (TK124) | INGRESS | TCP | .*-core-app-sg | 22 | NYC Office |
Celle-ci nous permet d’autoriser tous les éléments core-app-sg en tant que cible.
Les tokens font également appel à une regex pour valider le groupe de sécurité auxquels ils s’appliquent.
Depuis notre Security Operations Center (SOC), les utilisateurs peuvent demander de nouveaux tokens et, lorsque la demande est validée par un membre de notre équipe sécurité, le token est envoyé.
Nous avons ensuite la possibilité de voir où un token est utilisé dans nos environnements AWS.
Ces tokens sont accompagnés d’une signature digitale, ce qui empêche toute modification à partir de la base de données (DynamoDB). Voici l’export d’un token en guise d’exemple :
{
"_creationDate": "2020-06-17T16:37:42.056Z",
"_lastUpdate": "2020-06-17T16:37:42.056Z",
"data": "{\"GroupName\":\".*-alb-sg\",\"TokenType\":\"SG_RULE\",\"Target\":\"140.82.112.0/20\",\"Type\":\"INGRESS\",\"Description\":\"GitHub webhooks\",\"ToPort\":\"443\",\"IpProtocol\":\"TCP\",\"login\”:\”uanon\”,\”ts\":1592301098594}",
"publicKey": "-----BEGIN PUBLIC KEY-----\r\nMIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEA33UkG8UoMs+t4iw8/Th/\r\nFFpziS8MUxgKV/Trcs6kqRxz8Ytfj+F30+ylJ4uuiMxlPBZLAGPCCKOCIXUKJNvG\r\nH3AvW9zxf19+OLC0z/qdkCpf5x4LwBy9XCxwy7997YT/429Ah3RZF0GHaAR1Fwbp\r\nOkj8AlX2zv0FV9zx6i2k9eKmbsoD0a0dM7wCJq1p1So9Rj63aJXba4lDu44jLvuq\r\nZJu9Ty0cnDmsXqcR57ULByERqnx8nMCbvPWTq/Ya+UyGQuhbE7Lce3gJ5Wv3m9qU\r\npuVVJn4zGnksIl4mJZyShqDM7t4ETYstkghfOpJDI5ubuidWGOPXJIhmQ9DMtwFp\r\nox7T/q1MdosKej8VZanXQ9ELVemXhfpnnOjQK88Pc0HxbJK5nZAVaiXrb5Audi1R\r\nWRqdXeBMt9d/v9Ugl85VrOtbrlbbF7hK2L/UvxFaI1aoeXvHSkrwFtXDeNkvM8nf\r\nZp7Z0WEwjrpF7zcHE7mneZhmNHUxOQGBSbNHsQM6HNNOcczgx0RqcfbN63YA0gh6\r\nob6lbkU11qa6rYpWmwmKYj2GVEQ5TOJwFbDSH7+BwLhxRqGpro2Zx3AGXMxv/ECe\r\nlZaKHPAHllwoVrAuPS2VoqhqczkMoatouIzuMnbpBo9S3kohZVGmvmtqIghWPiW1\r\nilD0AF5Xf8BiDTNKZi2i8qECAwEAAQ==\r\n-----END PUBLIC KEY-----\r\n",
"signature": "028a286c6e81b5f74f0397e30f1fcc9e9a7b2281148eceb85d67ddc83ba8e13059c8b6835cf7c23b247afd67613fa2de892f5a282f3a27ab5c21cafcdbe30d7679b4a2ba4b77bef6342c1cb5c027ef1a3b0f376c0e147564f3bb272b6086edaf6162f7fa83febe793c9fdea3b3babf34455a6c0e206dc965ffccccfe72e39a5ec633d6f7d695da1740fea1a0e1ecb30169e5a1168f4dc41d02b7fba3d46948d68f8c0425e25429a27da52da5acf8ed07a8aaf36fbc912d99c9b1aba2c4aeb994dd50c4f190144d0a69269a0c09fb5425547e1c19afa74d2c523fc8178262dbad4f379b09036bed70469becce171548d20d051616a78b9539eb2999039332fe989511530d5b53765e350587fc0b0a9ffc513c2a85c634da64f0fdaacdb82ba1d2658dcd6d2cb4c629e75cdec74ac457ac8bd0abc1e6c2ee0821c3b5a4f150f8b7b00dcd4bdb11255ecb90063396a793c6040fd5c5b6f8b223ae8457c15e918c0ec4722cc0acf5567e1abaa7cbb2c72f722d4dd10b122b1085886b3e4d398eea2f251a2857a208c34ba4b042d427444b3bfe6d2bc8548b7d179f793762f61de3298e079767eaab2fbffccebb36d5a5d271603e962408eb088648cc6ccdcc509650ff53c3d63ce3077906a40037642ae1c70c811b58d60a0ab24362e69a07ef8b36b0dbf0719615bf1c7fa1f39d4c8177fef3159fdbddc3f19c2d3dbc95a0d24b4f",
"signedDate": "2020-06-17T16:37:39.515Z",
"signer": “usecurity”,
"type": "SG_RULE",
"uuid": "75_paKzzzeWSjq.h81cjWA"
}
Lorsqu’un groupe de sécurité est modifié, nous analysons chaque règle afin de vérifier qu’elle contient un token. Si ce n’est pas le cas, nous la supprimons afin d’éviter toute circulation de données non autorisée. Et lorsque nous supprimons une autorisation, toutes les règles associées sont également supprimées des environnements concernés.
L’un des objectifs de notre équipe est de simplifier autant que possible ces processus, donc si nous identifions une règle qui correspond à un token sans pour autant en avoir un, nous l’ajoutons pour le compte de l’utilisateur. Nous pouvons ensuite l’informer que le processus n’a pas été respecté, tout en lui permettant de continuer à travailler en toute tranquillité.
Ce système est en place depuis près de 2 ans et nous sommes ravis du résultat et nos équipes comprennent de mieux en mieux les différentes implications.
Mais je dois vous l’avouer, j’ai moi-même été responsable d’une interruption du service d’une heure lors de notre premier déploiement. Voilà ce qui s’est passé : un bug s’était glissé dans notre code, laissant le système d’automatisation croire que les tokens n’étaient pas légitimes, ce qui entraînait la suppression de toutes les règles des groupes de sécurité. Nous avons rapidement identifié le problème et notre équipe de production l’a résolu en une heure. J’aurais pu prétendre que nous étions en train de tester notre capacité de reprise après sinistre, mais nous misons sur la transparence. Et nous apprenons de nos erreurs.
Et la suite ? Nous allons ajouter quelques résolutions DNS dans les tokens pour permettre à certaines règles d’inclure un nom de DNS, pour améliorer l’intégration de notre système. Nous prévoyons également de les déployer sous forme de module IvoryShield. N’hésitez pas à nous contacter si vous voulez en savoir plus.
J’espère que cette présentation vous aura aidé à comprendre comment nous gérons la vérification de nos pare-feux, et j’espère pouvoir continuer à vous présenter nos processus de sécurité à l’avenir, afin de vous montrer que la plateforme Nuxeo est parfaitement adaptée aux entreprises disposant d’environnements réglementaires stricts et complexes.