L'automne est arrivé dans la cour, l'utopie techno fait rage. La technologie se précipite. Nous portons un ordinateur dans notre poche, dont la puissance de calcul est des centaines de millions de fois supérieure à la puissance des ordinateurs qui contrôlaient les vols vers la lune. Avec l'aide de Youtube VR, nous pouvons nager dans l'océan avec des méduses et des baleines, et les robots explorent depuis longtemps les horizons sans vie des planètes froides.
Dans le même temps, ingénieurs et spécialistes des services informatiques, développeurs et leurs innombrables collègues se répartissent en deux camps: ceux qui créent de nouvelles solutions (logiciels, stratégies, systèmes d'information), et ceux qui les comprennent.
Faites irruption dans l'écosystème de développement d'applications et la méthode d'utilisation des microservices. Jusqu'à récemment, c'était une technique incompréhensible, à l'abri des regards indiscrets, une technique fondamentalement nouvelle. Mais aujourd'hui, après quelques années seulement, les grandes et moyennes entreprises utilisent déjà cette approche en toute confiance dans leur propre environnement de développement. Comment est-il? Nous n'utiliserons pas les définitions «classiques», mais nous vous le dirons dans nos propres mots.
Architecture de microservice. Conteneurs
Les microservices sont une méthode dans laquelle la fonctionnalité d'un système est divisée en plusieurs petits services, et chacun d'eux effectue une tâche à partir d'une fonctionnalité complexe. L'un agit comme un serveur Web, l'autre comme une base de données, le troisième est occupé par autre chose, etc. Entre tous ces microservices, une interaction réseau est établie et les ressources nécessaires sont allouées. Un exemple drôle et non moins évident d'un tel concept est le système de commande et d'émission de déjeuner dans les restaurants de restauration rapide.
Le client (utilisateur) crée une nouvelle commande à l'aide du terminal ou de la réception (serveur Web), transfère des données sur le nombre de cheeseburgers, de pommes de terre et le type de soda dans son déjeuner (remplit la base de données), effectue un paiement, après quoi les données sont transférées à la cuisine, où une partie les employés font frire des pommes de terre (service de cuisine), et l'autre partie distribue de la nourriture et verse de la soude (service de collecte). Ensuite, la commande collectée est transférée au comptoir d'émission (service d'émission), où le client montre un chèque avec le numéro de commande (il y a même une vérification!), Et ils lui donnent le déjeuner. Dans ce cas, chacune des unités de processus est occupée par une tâche, et cela fonctionne rapidement et sans heurts, cependant, selon un algorithme défini. Vous devez admettre qu'il serait stupide de s'attendre à ce qu'à la réception vous fassiez sauter du soda plus rapidement que dans la cuisine, ou que l'employé qui fait frire les galettes puisse accepter le paiement de votre commande. Cependant, si le système est correctement débogué et que les processus se déroulent comme prévu, alors tout fonctionne très rapidement et efficacement.
En ce qui concerne l'architecture de microservices, il convient de noter un point important - son environnement d'exécution. Aujourd'hui, une option répandue est les conteneurs (salut, Docker). Une caractéristique des conteneurs est l'idée de regrouper dans eux tout l'environnement nécessaire, en commençant par une image de système d'exploitation légère, des packages installés, des cadres et des bibliothèques chargés, et en terminant par l'application elle-même. Comment est-ce utile? Au moins le fait que le développeur ne pourra pas écarter l'explication «Tout fonctionne sur mon ordinateur» lorsque vous lui parvenez avec un message que l'application ne fonctionne pas.
Les conteneurs vous permettent de créer des applications, de les regrouper avec l'ensemble de l'environnement dans une image prête à l'emploi d'un système léger et de ne plus vous soucier des problèmes associés au travail dans divers environnements. Besoin de déployer l'application sur un autre serveur? Nous avons lancé une image de travail avec elle dans le conteneur - et tout fonctionne.
Dans un système d'information construit à l'aide de conteneurs, vous n'avez plus à vous soucier des versions logicielles dans l'environnement où les applications s'exécutent, et avec des processus de livraison continus mis en œuvre, vous devez également livrer du code, etc. l'application s'exécute dans le même environnement de conteneur et, comme le microservice est fermé, peu importe le système d'exploitation ou les packages installés sur lesquels il fonctionne. L'application fonctionne car elle a été créée pour un environnement de conteneur qui ne change pas quel que soit le système entourant le conteneur. Vous n'avez plus besoin d'installer tous les logiciels nécessaires pendant longtemps et fastidieux, pour établir des connexions, des dépendances et des packages. Vous n'avez pas besoin de migrer manuellement les applications lors du passage entre les environnements de développement et de déploiement ou lorsque les capacités du centre de calcul augmentent. Un nouveau niveau d'abstraction est apparu, prenant sa place entre le logiciel final avec ses utilisateurs et l'environnement hôte (virtuel ou bare-metal), sur lequel tout cela fonctionne. Cette approche, en raison de sa commodité, gagne progressivement du terrain et ne va pas ralentir.
De nombreuses grandes organisations s'efforcent d'adopter les meilleures techniques pour améliorer l'efficacité de l'entreprise, son développement, son évolutivité et sa transformation, y compris dans le contexte des systèmes d'information. Après tout, c'est précisément pour les grandes entreprises axées sur le numérique qui sont principalement intéressées par des solutions axées sur la flexibilité, l'évolutivité et la mobilité, car, lorsqu'elles changent de secteur, elles deviennent sensibles aux difficultés associées à l'expansion, à l'adaptation à un marché en évolution, etc. pas nécessairement sur les entreprises informatiques. Dans le cadre des problématiques CI / CD et de sa sécurité, les entreprises du secteur public, les grands acteurs des marchés financiers comme les banques et même les monopoles logistiques se tournent vers notre organisation. Dans tous les cas, une chose les unit: l'utilisation de conteneurs sous une forme ou une autre lors du développement d'applications, de services, etc.
Les grandes entreprises sont souvent comparées aux requins. Dans ce cas, une comparaison plus appropriée est difficile à trouver. Avez-vous vu comment les requins s'attaquent aux bancs de poissons? Avez-vous remarqué à quel point les petits poissons sont plus maniables, même s'ils se trouvent dans un grand troupeau? Qui réagit de façon plus nette, plus maniable et plus rapide - un requin ou un petit maquereau? Il en va de même pour les entreprises du marché dans son ensemble. Bien sûr, nous ne prenons pas en compte Microsoft ou Apple à l'époque où ils rentrent dans le garage, ce sont des cas isolés. Mais statistiquement, le tableau est tel que les grandes entreprises sont capables de dicter des tendances et de définir des orientations, mais il est plus facile pour les petites entreprises de s'adapter et de s'adapter rapidement. Et les grandes entreprises tentent également d'augmenter la mobilité et la flexibilité de manière abordable.
Mais, comme on dit, il y a une nuance ... Les grandes entreprises ne sont en fait pas un monolithe. Ils se composent de nombreux départements, avec de nombreux départements, équipes, unités et un groupe d'employés encore plus important. Et dans le cadre des systèmes d'information et du développement, en particulier, les domaines d'action des équipes peuvent se chevaucher. Et juste à cette jonction, ces situations de conflit surviennent entre les services SI et les développeurs. Autrement dit, il s'avère que ni les grandes ni les moyennes entreprises ne sont à l'abri de telles difficultés.
Tôt ou tard, lors de l'utilisation de conteneurs, l'organisation aura une question. Cela peut se produire au tout début de leur utilisation, ou peut-être après un incident, ce qui entraînera des pertes pour l'entreprise.
Comment sécuriser les processus?
Sous une forme ou une autre, nous entendons souvent cette question et, avec le client, nous réfléchissons à la solution et recherchons des moyens appropriés. En règle générale, une organisation, en particulier une grande qui a mis en œuvre CI / CD, se compose de spécialistes intelligents et expérimentés, y compris ceux en sécurité de l'information. Ces personnes comprennent pourquoi elles ont besoin d'utiliser des microservices, quels problèmes cela résoudra et quelles nouvelles difficultés apparaîtront. Par conséquent, ils prennent des mesures pour la mise en œuvre et l'utilisation réussies de la technologie: préparer l'infrastructure, mener des audits, déployer des systèmes, construire des processus et coordonner les réglementations internes.
Cependant, il n'est pas toujours possible de tout prévoir, de tout suivre et de tout surveiller. Voici comment, par exemple, comprendre si la version du serveur SQL dans le conteneur contient une vulnérabilité critique? Manuellement? Disons. Et s'il y a des dizaines de conteneurs? Et des centaines?
Comment un spécialiste de la sécurité des informations peut-il être sûr que l'image du système d'exploitation de base dans le conteneur avec l'application ne contient pas d'exploit caché? Vérifier manuellement? Et que vérifier exactement, où chercher? Sur toutes les dizaines et centaines de conteneurs? Et où obtenir autant de temps et de ressources?
Avec le développement et la distribution de CI / CD, la question de la sécurité dans le cycle de développement est devenue plus aiguë. Après tout, vous devez être sûr au moins à un niveau de qualité d'image acceptable, vous devez connaître les vulnérabilités des logiciels et des packages, l'état des conteneurs de travail et si des actions suspectes ou manifestement illégitimes s'y déroulent. Et si nous parlons spécifiquement du cycle de développement, alors il vaudrait la peine d'avoir des outils pour assurer la sécurité dans le processus de développement lui-même, dans son pipeline, et pas seulement dans des conteneurs. Et vous devez également contrôler les secrets, vérifier les registres, contrôler l'interaction réseau, etc. Et nous arrivons ici au problème principal.
Pourquoi la sécurité est-elle nécessaire et quelles sont ses fonctionnalités dans CI / CD?
Il s'agit essentiellement d'un ensemble de pratiques permettant d'assurer la sécurité dans et autour du cycle de développement. Autrement dit, c'est l'utilisation de logiciels spéciaux, l'élaboration de méthodes et de règlements, et même la préparation des équipes (les équipes sont la clé de tout!) Pour assurer la sécurité. Et un point important: l'introduction justifiée de toute cette sécurité dans le développement, et ne pas couper de l'épaule!
Ici, nous nous attardons plus en détail. L'approche habituelle de la sécurité informatique en général et du développement en particulier, qui vient à l'esprit, est basée sur les principes de «Interdire / Restreindre / Empêcher». De loin, le système d'information le plus sûr est celui qui ne fonctionne pas du tout. Mais ça doit marcher! Et les personnes utilisant ce système devraient également pouvoir travailler avec lui.
Il y a un conflit d'intérêts mentionné ci-dessus. Le spécialiste de la sécurité de l'information cherche à rendre l'environnement sûr et veut en avoir le contrôle total, le développeur veut fabriquer le produit et veut qu'il se produise rapidement et facilement, et l'ingénieur informatique rend l'environnement fonctionnel, tolérant aux pannes et, de concert avec le développeur, il s'efforce d'automatiser.
La protection dans CI / CD ne concerne pas les logiciels ou les réglementations, c'est le travail d'équipe et l'intégration du concept de sécurité dans le flux de développement. Cette approche vise la participation égale de tous les participants au processus, la répartition des domaines de responsabilité clairs, l'automatisation, le suivi et la transparence des rapports. Et surtout, pour implémenter la sécurité à l'intérieur du processus de développement d'applications de telle sorte qu'elle apparaisse aux premiers stades et ne nécessite pas l'allocation de ressources supplémentaires, à la fois informatiques et humaines.
Jetons un coup d'œil à un exemple. Supposons que l'une des équipes de développement crée une application, cela se produit sur un support conteneur sous la supervision de spécialistes de la sécurité de l'information, tandis que les gestionnaires d'infrastructure maintiennent la santé de cet environnement. À la fin du développement, une application prête à l'emploi apparaît qui entre en production et commence à y travailler, les clients l'utilisent - tout le monde est content. Mais après un certain temps, une vulnérabilité grave est découverte dans le conteneur avec l'application. Un spécialiste de la sécurité de l'information enregistre cette vulnérabilité et la transmet aux développeurs pour élimination; à son tour, elle la corrige avec un correctif, après quoi vous devez réécrire les dépendances et mettre à jour certains packages. Ensuite, la prochaine version de l'application est déployée.
Le temps passé par les spécialistes SI pour localiser le problème, le temps de l'équipe de développement pour le résoudre, et un peu de temps le service SI va effectuer un deuxième audit et clore le dossier. Mais que faire si nous pouvions utiliser une sorte d'outil et le mettre en œuvre au stade du développement? Que faire si notre application ne s'est pas déployée sur le produit, étant inadaptée au niveau de sécurité donné? Et chaque spécialiste impliqué dans le processus, pouvait voir quelles menaces ont été trouvées dans son domaine de responsabilité? Mais que se passe-t-il si l'ensemble du processus est également automatisé, en commençant par la détection et en terminant par les incidents dans le traqueur de bogues?
C'est le but d'organiser un développement et une mise en œuvre sûrs. Que ce n'était pas seulement sûr, mais aussi pratique. L'introduction de nouveaux processus ou l'utilisation d'outils supplémentaires devraient simplifier les activités et non l'inverse.
Il existe des outils et des techniques qui vous permettent de surveiller l'état des éléments système nécessaires et les étapes du processus de développement et aident toutes les parties impliquées à se tenir au courant des événements dans leur domaine de responsabilité. L'accent n'est pas mis ici sur les logiciels spécialisés, mais sur l'interaction des personnes avec le système et entre elles. Est-il plus pratique pour le développeur de corriger et de tester l'application directement à l'intérieur du conteneur de travail? Eh bien, laissez-le le réparer. Dans le même temps, le service SI veut être sûr qu'il n'y a pas d'actions illégitimes à l'intérieur du conteneur? Pas de problème, elle sera au courant. La tâche était terminée et personne n'a interféré avec qui que ce soit dans le processus. Efficacité et rationalité! Et cela est possible si vous appliquez les outils de sécurité des informations nécessaires aux bons endroits de l'environnement de développement et révisez les règles d'interaction entre les services et les équipes. Et puis qu'il n'y ait pas d'utopie, mais vous devez convenir que vivre avec les deux deviendra un peu plus facile.
Pourquoi lier les mains des développeurs et charger le service IB avec lui, si vous pouvez créer des processus pour que le développeur fasse ce qu'il peut (altruiste, épuisé en extase par la perfection de son code), et le spécialiste de l'IB a contrôlé ce processus (sans interférer, mais seulement partager ce plaisir de côté).
Sécurité des conteneurs. Est-ce que ça vaut le coup?
Nous sommes contactés par des clients à des étapes complètement différentes et avec une expérience différente en CI / CD. Il y avait de grandes organisations qui faisaient face à une porte dérobée non détectée dans le conteneur en production grâce à laquelle l'accès aux données importantes était obtenu et les données volées. En conséquence, il est devenu évident que, dans un système envahissant et encombrant, il est trop difficile de suivre et de neutraliser préventivement les menaces potentielles.
Il y avait aussi de petites entreprises qui ont récemment utilisé CI / CD dans le développement. Après avoir analysé les processus dans les pipelines, leurs experts sont parvenus à la conclusion que les outils de sécurité des informations disponibles couvrent un volume insuffisant de processus et qu'il existe des endroits dangereux par lesquels une attaque peut survenir tôt ou tard. Peut-être pas maintenant, peut-être plus tard, ou peut-être jamais du tout. Mais si cela se produit, le prix de l'erreur sera élevé.
Nos clients partagent des préoccupations qui, dans la plupart des cas, se résument au concept même de battre les mains des développeurs, des ingénieurs et de toutes les personnes impliquées dans le processus lorsqu'ils tentent de dépasser le délai. Mais parfois, c'est plus facile et plus rapide de cette façon, et dans certains cas, c'est généralement le cas autrement. Et puis le service SI doit examiner les violations par les doigts. Mais nous sommes pour un concept différent. Pourquoi violer ou ignorer des réglementations écrites avec tant de peine? Pourquoi les services devraient-ils interférer les uns avec les autres pour accomplir leurs tâches? En travaillant avec le client, nous commençons la communication avec ses problèmes. Ils sont toujours là.
"Ne cherchez pas un client, ne trouvez pas un problème et n'offrez pas de solution - le client apparaîtra lui-même."
Après avoir écouté le client, en règle générale, nous comprenons les problèmes auxquels il est confronté. Il peut s'agir de difficultés d'interaction d'équipe, de décisions infructueuses dans la conception du «pipeline», d'un manque de ressources informatiques et humaines, et bien plus encore. Dans notre approche de la mise en œuvre d'améliorations de sécurité dans l'infrastructure du client, nous sommes guidés par le désir d'aider à résoudre ses problèmes et d'y parvenir d'une manière qui minimise la probabilité de nouveaux problèmes. Ainsi, une fondation pour l'avenir est créée, peu importe qui servira le système créé, de nombreux problèmes doivent être prévus et résolus au début. Au début, les décisions s'avèrent dans la plupart des cas moins chères qu'avec des charges de travail élevées en production profonde.
Sur la base de tout cela, nous suggérons de commencer par un audit, qui comprend non seulement l'état des systèmes d'information et de leurs éléments, mais aussi une compréhension de la composante processus entre les équipes de développement, l'approche des services de sécurité de l'information, etc. N'oubliez pas que les personnes sont le facteur le plus important à la fois en termes de menaces et pour les résultats du fonctionnement du système. Un audit est une étape nécessaire, à la suite de laquelle des défauts importants du système ou des erreurs de calcul dans les interactions que, avec le client que nous essayons de résoudre ou de traiter, peuvent être révélés. Il est important de comprendre que l'objectif n'est pas d'accumuler de nombreuses solutions et produits logiciels et de ne pas bloquer les vulnérabilités découvertes par eux. Au contraire, il est probable qu'un scénario d'achat de produits logiciels coûteux ne soit pas du tout nécessaire. Souvent, le processus d'augmentation de la sécurité dans un environnement CI / CD peut être réalisé à l'aide des fonctionnalités de sécurité existantes de l'organisation, à la fois intégrées à l'environnement de conteneurisation (dans l'orchestrateur, par exemple) et tierces. L'important n'est pas tant leur quantité ou leur qualité que l'application correcte.
Sur la base des résultats de l'audit, il devient possible de créer un plan de travail, une feuille de route avec des tâches intermédiaires explicites et un objectif ultime compréhensible. Eh bien, tout est encore une question technique. Une bonne planification dans toute entreprise est une partie importante de la réussite.
Il est important de ne pas trop s'emballer et de ne pas oublier pourquoi tout est fait. Personne n'a la tâche de créer un système incroyablement protégé dans lequel aucun conteneur ne démarre lorsque des menaces y sont détectées, ou aucune application n'est déployée en production s'il y a des écarts par rapport au modèle protégé. Il convient de rappeler que l'introduction ou le lancement d'outils de protection devrait servir non seulement à accroître la sécurité, mais également à des fins de commodité.
Par exemple, l'un de ces cas impliquait l'introduction de logiciels de protection de conteneurs et d'environnements d'orchestration. Il semblerait qu'ils aient implémenté, configuré, scanné, vu toutes les vulnérabilités - puis le long processus d'élimination. Cependant, avec cette approche, des problèmes surgissent, qui ont été discutés au début. Le service de sécurité des informations dispose d'un outil qui vous permet de bloquer de nombreuses activités dans un environnement d'orchestration qui, s'il est mal utilisé, fera plus de mal que de bien. Les développeurs ont les mains liées, car le service de sécurité de l'information réduit leurs capacités. Par exemple, il n'est plus possible de corriger quelque chose à l'intérieur du conteneur «à chaud», et lorsqu'une vulnérabilité de package est détectée dans l'image, le développeur est impliqué dans la bureaucratie réglementaire. En conséquence, la solution à un problème qui pourrait être éliminé pendant la journée est retardée indéfiniment.
Pour éviter de telles situations, nous recommandons que les processus soient organisés de manière à ce que le service de sécurité de l'information ne soit pas à l'écart du processus de développement, comme c'est souvent le cas, mais qu'il y participe. Cela prend certainement du temps, mais cela vaut la peine de déboguer le processus et la vie devient vraiment plus facile. Par exemple, les outils SI vous permettent de surveiller les menaces déjà au stade de l'assemblage dans le pipeline CI / CD, et le service SI peut l'enregistrer. Dans le même temps, les informations sur les menaces à chaque étape de l'assemblage peuvent être automatiquement transférées à l'équipe ou au spécialiste responsable d'une étape particulière, qui prendra à son tour les mesures nécessaires pour éliminer la menace. Et tout cela ne se passe pas sous la supervision d'un whip, mais sous la surveillance du service SI.En fin de compte, le temps consacré à la correction des vulnérabilités peut être considérablement réduit, et avec lui les coûts commerciaux, par exemple financiers ou de réputation.Avec toutes les données initiales, nous nous efforçons de former une approche pour organiser et améliorer le niveau de sécurité du développement de conteneurs, en nous concentrant non seulement sur la conception et la mise en œuvre de solutions spécifiques, mais également dans le respect des ressources humaines. Chaque participant au processus remplit son rôle et plus il est pratique, moins il y a d'interférence inutile, meilleur est son résultat final. Et si vous trouvez un équilibre entre la commodité de toutes les parties impliquées, vous vous retrouverez avec une équipe très efficace. À l'avenir, bien sûr, diverses optimisations, applications ou augmentations de l'automatisation de certains processus, délégation de tâches, etc. sont possibles, mais l'idée principale reste inchangée - une révision de la sécurité en tant que telle. Séparation des tâches, surveillance au lieu d'interdictions aveugles et participation de chacun dans ses domaines de responsabilité.Et bien sûr, la commodité! La sécurité peut être pratique.