Architectures sans agent ou à base d'agent :pourquoi est-ce important ?

Dans le domaine des solutions de sécurité, d'analyse et de surveillance pour le cloud, il y a une tonne de discussions sur les architectures sans agent par rapport aux architectures avec agent. Les professionnels de l'informatique évaluant les produits de surveillance avec agent par rapport aux produits de surveillance sans agent découvriront une égalisation des avantages et des inconvénients pour chacun. Le gagnant visible change en fonction des circonstances. Votre décision d'opter pour une architecture sans agent par rapport à une architecture avec agent peut fortement affecter la compétence de vos tâches quotidiennes en matière de conformité et de sécurité, tout comme votre capacité à assurer votre environnement cloud ultérieurement. Il est impératif de comprendre les différences entre chaque choix et d'être parfaitement conscient des avantages et des inconvénients liés à ce choix.

Quelles sont les différences ?

Les architectures sans agent et avec agent varient fondamentalement les unes des autres par la manière dont elles collectent les données et donnent le contrôle sur les éléments de votre environnement cloud (services de base de données, réseau, équilibreurs de charge, instances de serveur, groupes de sécurité, etc.). Lorsque vous utilisez un produit de sécurité basé sur un agent, un petit agent logiciel doit être installé sur chacun de vos serveurs. L'agent est responsable de la collecte des données importantes du serveur sur lequel il a été installé, il renvoie les données à un cadre de contrôle central et vous permet de contrôler les mesures de sécurité au niveau de l'instance de machine virtuelle/serveur. Par exemple, les produits de sécurité basés sur des agents accumulent des données sur la disposition du pare-feu hôte et le flux de trafic système entre les serveurs et offrent une surveillance de l'intégrité des fichiers et la capacité d'installer le pare-feu sur chaque hôte.

Les architectures sans agent communiquent directement avec la plate-forme cloud fondamentale (par exemple, MS Azure, AWS) via l'API du fournisseur de services pour obtenir des données sur les cas, les administrations, le système et elles contrôlent la sécurité. Étant donné que le sans agent communique directement avec la plate-forme, aucune modification n'est nécessaire dans les ressources qui font partie de votre environnement cloud. Pour cette raison, les architectures sans agent, également appelées services basés sur des API ou natives du cloud, sont totalement claires pour les applications et les tâches en suspens à accomplir.

Commencez votre ESSAI GRATUIT de 30 jours à CloudInstitute.io. Contactez nos experts pour en savoir plus sur nos certifications cloud.

Pourquoi cela fait-il une différence ?

Lorsque les plates-formes de sécurité des charges de travail ont été lancées pour la première fois pour les environnements de cloud public, elles ont été conçues pour être basées sur des agents. Cependant, tout cela était dans une mesure limitée au motif que les systèmes de sécurité découverts par les fournisseurs de services spécialisés dans le cloud avançaient tout le temps et n'étaient pas aussi compétents et robustes auparavant qu'ils le sont aujourd'hui. Ces outils ont en outre donné aux organisations qui transféraient des tâches en suspens vers le cloud public une approche pour récupérer les outils créés pour les environnements de centre de données dans des environnements de cloud public. Cela a permis de simplifier la progression vers le cloud ouvert pour certains d'entre eux.

Cependant, les architectures basées sur des agents conçues pour des environnements de centre de données plus statiques et sans surprise sont parfaitement adaptées au paysage en constante évolution d'un environnement de cloud public. Nous devrions voir les raisons.

1. La gestion des agents vous coûte des frais généraux : Vous êtes responsable de l'introduction d'agents sur chaque instance de votre environnement cloud, de l'enquête sur les problèmes de réseau et de la mise à jour de vos agents dans une solution basée sur des agents. Ceci est évidemment typique dans le domaine des entreprises informatiques à grande échelle. Les clients des solutions de sécurité des terminaux, telles qu'Intel McAfee et Sophos, sont habitués à gérer des agents sur des hôtes Linux et Windows.

Néanmoins, dans les situations de cloud où vous êtes entouré de centaines de machines virtuelles ou d'instances de serveur sur de nombreux VPC à travers le monde avec plusieurs enregistrements qui y parviennent, et vous avez des enregistrements régulièrement inclus et supprimés de votre environnement, la complexité de la supervision dans tous les cas , quelque chose d'aussi basique que les agents, se transforme en un poids énorme. La gestion des agents offre une autre petite fenêtre de faiblesse dans un environnement cloud. Pouvez-vous vous assurer qu'un agent installé sur une instance rouge récemment lancée fait son travail ? Dans les situations avec différentes unités spécialisées et partenaires avec leurs propres systèmes, il est particulièrement difficile de garantir qu'un agent est correctement installé dans chaque instance.

2. Pas de spot pour introduire des agents en FaaS : Si nous regardons AWS il y a cinq ans, pour la plupart des entreprises, il n'offrait que deux ou quatre services, à savoir S3, EBS et EC2. Vous pouvez introduire des agents dans les instances EC2 et garantir complètement votre condition.

De nombreuses organisations utilisent actuellement efficacement les services de base de données par défaut (RDS, DynamoDB), les services Big Data (ElasticSearch, EMR) et les équilibreurs de charge (ELB). Les offres FaaS, telles qu'AWS Lambda (également connue sous le nom d'informatique sans serveur) se généralisent également. Dans un tel cas, soit vous n'avez pas de place pour mettre un agent, soit vous n'êtes pas autorisé à mettre un agent dans l'environnement (alors, où se situe l'agent dans un environnement Lambda ?). Les solutions basées sur les agents négligent totalement de filtrer ou d'assurer ces services. L'utilisation des services Lambda n'est peut-être pas nécessaire pour vous aujourd'hui, mais avez-vous besoin que votre solution de sécurité cloud restreigne ce que vous pouvez filtrer et garantir plus tard ?

En savoir plus :Comment gérer les risques de sécurité dans le cloud

3. Aucune connaissance des services cloud natifs : Les produits de sécurité basés sur des agents négligent non seulement de garantir les administrations natives du cloud, telles que RDS et ELB, mais ils ne permettent pas non plus de démontrer ces services dans les stratégies de sécurité d'instance. Par exemple, il est extrêmement improbable d'indiquer dans une stratégie de sécurité qu'une instance peut envoyer du trafic sortant uniquement vers RDS et peut obtenir des connexions entrantes uniquement à partir d'un ELB. Vous devez vous tourner vers une approche « ouverte à tous » trop clémente en raison de ces obstacles.
4. Assurer la conformité et maintenir la sécurité d'une manière indépendante du cloud est important pour les environnements cloud hybrides ainsi que pour les déploiements multi-cloud où des charges restantes peuvent s'exécuter sur AWS et Azure et ne souhaitent pas être limités uniquement à une plate-forme spécifique. Vous pouvez effectuer une gestion de la sécurité indépendante du cloud même sans introduire ni superviser des agents. Les plates-formes de sécurité cloud vous permettent de gérer la position de sécurité de différents environnements de cloud public en indiquant des solutions et des règles d'une manière indépendante du cloud tout en utilisant les capacités natives de chaque cloud pour actualiser et mettre en œuvre les approches de sécurité. Vous confondez les deux univers, car vous pouvez indiquer une fois les stratégies de sécurité sur différents clouds, puis utiliser les commandes étonnantes données par chaque cloud pour les exécuter.
5. Vous devez payer des taxes inutiles pour une architecture basée sur des agents sur votre environnement AWS : Avec les solutions basées sur des agents, en plus du fait que vous avez des agents travaillant dans chaque instance et réduisant l'utilisation du processeur, vous avez également ces agents qui conversent avec un régulateur d'aide et étendent la transmission de données dans votre environnement cloud.

Le dilemme de l'architecture agent contre architecture sans agent

Le déploiement informatique et l'entreprise elle-même décident de la réponse la plus appropriée à l'architecture agent ou sans agent. Les organisations qui dépendent de la technologie des données en tant que moteur clé de l'exécution générale de l'organisation. Par exemple, un fournisseur d'administration budgétaire peut avoir besoin de la profondeur que véhiculent les cadres basés sur les agents. Les entreprises où les temps d'arrêt ou les goulots d'étranglement du système affectent peu la préoccupation principale peuvent découvrir la facilité de la méthodologie sans agent d'autant plus attrayante.

Les entreprises sont également prêtes à combiner et associer une architecture avec et sans agent. Les organisations ont deux alternatives pour collecter des informations-cadres ; c'est tout sauf un choix. Réfléchissez à l'idée des composants informatiques et de l'entreprise, puis décidez si une méthodologie avec ou sans agent convient le mieux à ce besoin spécifique.

La technologie sans agent est l'utilisation de l'utilité de gestion native et installée d'une machine pour récupérer des données. Qu'une technologie soit ou non désignée comme sans agent, la récupération d'informations à partir d'un gadget nécessite un cycle ou des cycles pour s'exécuter, ce qui dévore les ressources.

Au cours de la phase de découverte, quelques sources d'informations peuvent être utilisées et, pour une vérification organisée, l'utilisation sans agent est la meilleure technique. Pourtant, lorsque vous espérez augmenter les dépenses et réduire la présentation budgétaire, vous devez éventuellement déployer des agents. La question est, Quand ?

L'avantage des technologies sans agent est qu'elles éliminent les obstacles liés à l'introduction de logiciels supplémentaires, ce qui peut être un cycle non négligeable pour les machines actuellement utilisées, et en particulier pour les travailleurs essentiels fonctionnant dans une batterie de serveurs. Le respect des conventions de sécurité, les problèmes d'incohérence logicielle, la garantie de l'installation de la variante la plus récente d'un agent et la surcharge d'actualisation des agents sur de nombreux gadgets ne sont qu'une partie des obstacles auxquels les bureaux informatiques sont confrontés en ce qui concerne le déploiement de logiciels. Le problème avec l'absence d'agent, nonobstant, est que ces technologies ne fournissent pas suffisamment de données pour augmenter les dépenses en logiciels.

Conclusion

Comme toute architecture, une réflexion prudente et des examens approfondis doivent être effectués pour garantir qu'elle répond aux problèmes d'aujourd'hui et prend en charge les modèles commerciaux propulseurs. Compte tenu des avantages centraux de la technologie, de la sécurité et du support amélioré, la structure sans agent est le premier choix par rapport à un plan avec agent, car elle s'identifie aux outils DevOps. Anticipant la méthode des choses à venir avec le cloud computing et l'Internet des objets, CloudInstitute.io pense que l'architecture sans agent est certainement la meilleure solution.

Intéressé à commencer votre carrière dans le cloud computing? CloudInstitute.io propose les meilleurs cours de certification en cloud computing abordables. Apprenez-en plus pour grandir plus !

Connectez-vous avec nos experts et planifiez vos projets futurs pour une carrière réussie dans le cloud. Commencez votre essai gratuit de 30 jours dès aujourd'hui !