Différences entre les groupes de sécurité AWS et le pare-feu virtuel de Palo Alto Networks

Différences entre les groupes de sécurité AWS et le pare-feu virtuel de Palo Alto Networks

57239
Created On 09/25/18 15:12 PM - Last Modified 04/21/20 00:20 AM


Resolution


Introduction

Au fur et à mesure que les entreprises continuent d'embrasser les ressources du cloud public, il est important de garder un œil vif sur la sécurisation des applications et des données. Non pas parce que les données d'entreprise réside potentiellement dans un centre de données autre que le vôtre, mais parce qu'il est encore des données de l'entreprise-indépendamment de ses paramètres régionaux. Les organisations de sécurité au sein de l'entreprise devront s'adapter aux applications corporatives et aux données résidant n'importe où, et être accessibles de partout – et potentiellement à partir de n'importe quel appareil. Cela érode efficacement le modèle de périmètre standard pour la sécurité. Le périmètre est maintenant autour des applications et des données, peu importe où ils résident.

 

Cette transition nécessitera une compréhension de ce que les fonctionnalités de sécurité peuvent être offertes par le fournisseur de cloud public, et tout aussi important-ce qui n'est pas offert. Les offres de sécurité intégrées dans le cloud public ne sont pas comparables à celles offertes par la plate-forme de sécurité des réseaux de Palo Alto. Ce document met en évidence certaines de ces différences – spécifiquement pour AWS, mais les mêmes concepts s'appliquent à Azure. Il est également montré comment la même approche de plate-forme prise dans le centre de données privé doit être étendue au nuage public-ou où vos applications et données sont accessibles.

 

UNE comparaison entre les deux révèle facilement que les fonctionnalités intégrées de sécurité sont en réalité, pas de comparaison à l'approche de la plate-forme de Palo Alto réseaux. En fait, ils sont complémentaires et devraient être déployés ensemble. Pour AWS, la sécurité intégrée ne peut pas être désactivée et est une exigence. Cependant, en laissant votre posture de sécurité avec seulement le moteur intégré est quelque chose que même pas AWS recommande[1].

 

Comparaison de

Le tableau suivant n'est pas exhaustif, mais met en évidence quelques-unes des fonctionnalités qui ne sont pas fournis comme une partie du moteur de sécurité intégré dans le cloud public AWS. La fin du tableau répertorie quelques-uns des contrôles de sécurité spécifiques à AWS. Il est important de se rappeler que la décision pour les organisations n'est pas «l'un ou L'autre», mais d'utiliser les deux approches pour une posture de sécurité globale.

 

Fonctionnalités clés

Pan

AWS

Pare-feu

 

 

Des milliers d'applications de visibilité et de contrôle; possibilité de créer des applications personnalisées; capacité de gérer le trafic inconnu en fonction de la politique

X

 

Identification et contrôle de l'utilisateur: VPN, contrôleurs WLAN, portail captif, proxies, Active Directory, eDirectory, Exchange, services Terminal Server, analyse syslog, API XML

X

 

Décryptage et inspection SSL granulaires (entrants et sortants); contrôle SSH par stratégie (entrant et sortant)

X

 

Mise en réseau: routage dynamique (RIP, OSPF, BGP, BGP multiprotocole), DHCP, DNS, NAT, redistribution de routage, ECMP, LLDP, BFD, inspection du contenu du tunnel

X

 

QoS: mise en forme de trafic basé sur une stratégie (priorité, garantie, maximum) par application, par utilisateur, par tunnel, basé sur la classification DSCP

X

 

Segmentation de réseau basée sur des zones et protection des zones; Protection dos contre les inondations de nouvelles sessions

X

 

Prévention des menaces

 

 

Prévention d'une grande variété de menaces, y compris les exploits de vulnérabilité, les logiciels malveillants et les botnets

X

 

Blocage des logiciels malveillants polymorphes en se concentrant sur la charge utile, au lieu de hash ou filename

X

 

Protections mises à jour automatiquement toutes les cinq minutes avec Wildfire

X

 

Protection avancée contre les logiciels malveillants (Wildfire)

 

 

Analyse dynamique: détonation de fichiers dans un environnement virtuel personnalisé et résistant à l'évasion, permettant la détection de logiciels malveillants et d'exploits à zéro jour

X

 

Analyse statique: détection des logiciels malveillants et des exploits qui tentent d'échapper à l'analyse dynamique; identification instantanée des variantes des logiciels malveillants existants

X

 

Apprentissage machine: extraction de milliers de fonctionnalités uniques à partir de chaque fichier, formation d'un classificateur d'apprentissage machine prédictif pour identifier les nouveaux logiciels malveillants et les exploits

X

 

Analyse du métal nu: les menaces d'évasion automatiquement envoyées à un environnement matériel réel pour la détonation, supprimant entièrement la capacité d'un adversaire de déployer l'analyse anti-VM

X

 

Mises à jour de signatures automatisées toutes les cinq minutes pour les logiciels malveillants et les exploits de zéro jour découverts par un abonné Wildfire

X

 

Service intelligent de menaces contextuelles (autofocus)

 

 

Contexte entourant les attaques, les adversaires et les campagnes, y compris les industries ciblées

X

 

Accélération des efforts d'analyse et d'intervention, y compris des alertes prioritaires pour les menaces les plus critiques

X

 

Filtrage d’URL

 

 

Protection contre les sites malveillants exposant vos personnes et vos données aux logiciels malveillants et aux kits d'exploitation

X

 

Protection contre le phishing d'informations d'identification en inspectant les pages pour déterminer si le contenu et le but sont malveillants dans la nature. Catégories d'URL personnalisées, alertes personnalisables et pages de notification.

X

 

Filtrage des fichiers et des données

 

 

Contrôle bidirectionnel du transfert non autorisé de types de fichiers et de numéros de sécurité sociale, de numéros de carte de crédit et de modèles de données personnalisés

X

 

Sécurité mobile (Global Protect)

 

 

VPN d'accès à distance (SSL, IPSec, client) et prévention des menaces mobiles et application des politiques basées sur les applications, les utilisateurs, le contenu, le périphérique et l'état du périphérique

X

 

BYOD: VPN App-Level pour la confidentialité des utilisateurs

X

 

Outils de gestion et de visibilité (Central Policy Management)

 

 

Contrôle intuitif des stratégies avec les applications, les utilisateurs, les menaces, la protection avancée des logiciels malveillants, l'URL, les types de fichiers, les modèles de données – le tout dans la même stratégie

X

 

Aperçu de l'action dans le trafic et les menaces avec l'Application Command Center (ACC), entièrement personnalisable Reporting

X

 

Journalisation agrégée et corrélation d'événements

X

 

Gestion cohérente de tous les matériels et de toutes les séries VM, contrôle d'accès basé sur les rôles, groupes de périphériques logiques et hiérarchiques et modèles

X

 

GUI, CLI, XML-based REST API

X

 

Balisage dynamique pour l'automatisation des stratégies

 

 

Utilisation de stratégies de filtrage granulaire combinées à un marquage automatique pour déplacer des hôtes compromis entre des groupes de sécurité. C'EST-À-DIRE mettre en quarantaine un hôte si le trafic de commande et de contrôle est vu, par exemple.

X

 

Utilisation des politiques de marquage pour envoyer automatiquement des données pertinentes à un système de billetterie lors d'une violation de sécurité

X

 

Fonctionnalités générales

 

 

IP/port/protocole de sécurité basé

X

X

Plages de ports utilisées dans la stratégie

X

X

Source et/ou destination au sein de la politique (Remarque: AWS sépare les règles entrantes et sortantes en tant que règlements distincts)

X

X

Règles basées sur le CIDR

X

X

Fonctionnalités de genre ACL dans une stratégie

X

X

Sécurité appliquée après l'Entrée du trafic VPC

X

X

Drop vs refuser la distinction dans une politique

X

 

Fonctionnalités spécifiques à AWS

 

 

Utilisation d'un groupe de sécurité AWS comme source/destination. * Note: une alternative de Palo Alto Networks peut être d'utiliser IPSec entre VPC pour contrôler le trafic.

*

X

Sécurité appliquée avant que le trafic n'entre en VPC. * Note: ce serait une fonctionnalité supplémentaire utilisée en conjonction avec les pare-feu virtuels de réseau de Palo Alto.

 

X

 

Effets de L'utilisation de la sécurité AWS uniquement

Pour utiliser uniquement les groupes de sécurité et les ACL disponibles dans AWS serait de prendre votre posture de sécurité en arrière 25 ans en termes de protection. Cela est dû à l'approche orientée port/protocole des groupes de sécurité. Il fut un temps où L'utilisation de cette méthode était tout ce qui était nécessaire. Lorsque le trafic HTTP a été seulement vu sur le port TCP 80, ou lorsque le trafic Telnet a été seulement vu sur le port TCP 23 etc. Ce n'est tout simplement plus le cas-et n'a pas été le cas depuis de nombreuses années. Le trafic d'applications réside non seulement sur un plus large éventail de ports, mais ces ports peuvent souvent être dynamiques dans la nature couvrant un spectre énorme. Il est donc impossible de créer une stratégie de sécurité basée sur les port ou les plages de ports, car cela ouvre la porte à des logiciels malveillants qui peuvent utiliser ces mêmes ports bien connus.

 

Un autre problème avec l'utilisation strictement port/protocole de sécurité basée est que de nombreuses applications potentiellement utiliser les mêmes plages de ports. La sécurité moderne nécessite un moyen de faire la distinction entre les applications, quel que soit le port ou le protocole utilisé. La capture d'écran suivante révèle la sécurité basée sur le port/protocole intégré au modèle AWS:

 

Picture1.png

 

Notez la colonne "type" dans L'exemple. Ceci ne doit pas être confondu avec la reconnaissance d'application. Il s'agit simplement d'une façon de choisir une application à partir d'une liste uniquement pour que le port standard soit inséré dans la règle réelle. Pour effectuer l'identification de l'application, quel que soit le port ou le protocole, nécessite une inspection approfondie des paquets de session. Toutefois, ce n'est pas la façon dont un port/protocole fonctionne moteur.

 

Que les données d'entreprise vivent dans un centre de données d'entreprise ou dans le nuage public, il est essentiel de réduire la surface d'attaque dans la posture de sécurité. Par whitelisting applications qui sont nécessaires pour les entreprises et l'élimination des applications inconnues, la surface d'attaque peut être réduite sensiblement. Lorsqu'elle est combinée à la restriction des utilisateurs d'accéder uniquement aux applications/données nécessaires en fonction du rôle ou du groupe par exemple, la surface d'attaque est réduite encore. Cela nécessite les fonctionnalités avancées du pare-feu de la prochaine génération de Palo Alto Networks. Cela est vrai indépendamment de l'endroit où les données résident.

 

Où les fonctionnalités de sécurité intégrées d'AWS entrent-elles dans L'image? Ils sont utilisés comme une couche supplémentaire de sécurité, plutôt que d'un remplacement de l'inspection du trafic moderne. Par exemple, il est possible d'utiliser la fonctionnalité groupes de sécurité sur le périmètre (extérieur) du VPC pour supprimer le trafic des plages IP spécifiques (c'est-à-dire des adresses géo-basées ou mal-IP, etc.). Un autre cas d'utilisation potentiel consiste à contrôler la gestion du VPC ou à contrôler le trafic entre les VPC. L'exigence de fonctionnalités d'inspection avancées existe encore en dehors de l'utilisation des composants de sécurité intégrés AWS.

 

Résumé

En résumé, il y a deux questions à poser Lorsqu'il s'agit d'une approche «l'une ou L'autre» de la sécurité des nuages publics.

 

  1. Seriez-vous à l'aise d'abandonner votre NGFWs à l'ac et aux succursales pour protéger les utilisateurs et les données de l'entreprise (périmètre et centre de données) et les remplacer entièrement par un pare-feu AWS (groupes de sécurité et ACL)?

  2. Si la réponse est «non», est-il logique d'utiliser uniquement la sécurité AWS pour protéger vos données d'entreprise dans le nuage public?

Les deux composants sont complémentaires et doivent être déployés ensemble tout comme vous utilisez plusieurs couches à l'ac et les succursales.

 

Références et notes

[1] modèle de responsabilité partagée AWS : https://AWS.Amazon.com/Compliance/Shared-Responsibility-Model/ 

 

Quelle est la meilleure pratique pour déployer AWS et Palo Alto Networks VM-Series pare-feu dans le nuage public?

Dans AWS VPC, les groupes de sécurité et les ACL du réseau contrôlent le trafic entrant et sortant; les groupes de sécurité régulent l'accès à l'instance EC2, tandis que les ACL réseau réglementent l'accès au sous-réseau. Étant donné que vous déployez le pare-feu de la série VM des réseaux Palo Alto, définissez des règles plus permissives dans vos groupes de sécurité et vos ACL réseau et autorisez le pare-feu à activer en toute sécurité les applications dans le VPC tout en inspectant les sessions pour les logiciels malveillants et les activités malveillantes. 

 

Les groupes de sécurité AWS utilisent le port/protocole:

http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EC2_Network_and_Security.html 

"Vous pouvez utiliser des groupes de sécurité pour contrôler qui peut accéder à vos instances. Ceux-ci sont analogues à un pare-feu réseau entrant qui vous permet de spécifier les protocoles, les ports et les plages IP source qui sont autorisés à atteindre vos instances. Vous pouvez créer plusieurs groupes de sécurité et assigner des règles différentes à chaque groupe. Vous pouvez ensuite assigner chaque instance à un ou plusieurs groupes de sécurité, et nous utilisons les règles pour déterminer quel trafic est autorisé à atteindre l'instance. Vous pouvez configurer un groupe de sécurité afin que seules les adresses IP spécifiques ou les groupes de sécurité spécifiques aient accès à l'instance. "

 

http://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/using-network-security.html 

"Un groupe de sécurité agit comme un pare-feu virtuel qui contrôle le trafic pour une ou plusieurs instances. Lorsque vous lancez une instance, vous associez un ou plusieurs groupes de sécurité à l'instance. Vous ajoutez des règles à chaque groupe de sécurité qui autorise le trafic vers ou depuis ses instances associées. "

 

http://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/using-network-security.html 

"Si vous avez des exigences qui ne sont pas remplies par les groupes de sécurité, vous pouvez gérer votre propre pare-feu sur l'une de vos instances en plus d'utiliser des groupes de sécurité."

 

Les groupes de sécurité et les ACL combinés sont référés à un «pare-feu» dans AWS:

http://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/VPC_ACLs.html

"Une liste de contrôle d'accès réseau (ACL) est une couche de sécurité facultative pour votre VPC qui agit comme un pare-feu pour contrôler le trafic dans et hors d'un ou plusieurs sous-réseaux. Vous pouvez configurer des ACL réseau avec des règles similaires à celles de vos groupes de sécurité afin d'ajouter une couche de sécurité supplémentaire à votre VPC. "

 

Les types de règles AWS sont simplement remplacés par le port standard généralement utilisé par l'application:

 

Picture2.png

 

 

Picture3.png

Les règles de sort AWS suivent la même syntaxe de port/Protocol:

 

Picture4.png

Voici un exemple d'ACL AWS Network par défaut pour un VPC qui prend en charge IPv4 uniquement:

 

Picture5.png

 

Exemple de création d'ACL AWS:

 

Picture6.png



Actions
  • Print
  • Copy Link

    https://knowledgebase.paloaltonetworks.com/KCSArticleDetail?id=kA10g000000ClDGCA0&lang=fr&refURL=http%3A%2F%2Fknowledgebase.paloaltonetworks.com%2FKCSArticleDetail

Choose Language