SUR CETTE PAGE
Processus de récupération des rôles d’utilisateur et de recherche de stratégies
Obtention d’informations de nom d’utilisateur et de rôle via l’authentification du pare-feu
Configuration d’un pare-feu de rôle d’utilisateur pour la redirection du portail captif
Exemple : Configuration d’un pare-feu de rôle utilisateur sur un équipement SRX Series
Configuration des stratégies de ressources à l’aide du contrôle de compte d’utilisateur
Rôle d’utilisateur spécifique à la plate-forme Comportement des politiques de sécurité du pare-feu
Rôle d’utilisateur Stratégies de sécurité du pare-feu
Les stratégies de pare-feu de rôle d’utilisateur permettent aux administrateurs d’autoriser ou de restreindre l’accès réseau des utilisateurs en fonction des rôles qui leur sont attribués. Les pare-feu utilisés permettent une plus grande atténuation des menaces, fournissent des ressources d’analyse plus informatives, améliorent l’archivage des enregistrements pour la conformité réglementaire et améliorent le provisionnement des accès de routine.
Comprendre les pare-feu de rôle d’utilisateur
Bientôt, l’application, la surveillance et la création de rapports en matière de sécurité réseau basés uniquement sur les informations IP ne suffiront plus pour les équipes dynamiques et mobiles d’aujourd’hui. En intégrant les politiques de pare-feu des utilisateurs, les administrateurs peuvent autoriser ou restreindre l’accès réseau des employés, sous-traitants, partenaires et autres utilisateurs en fonction des rôles qui leur sont attribués. Les pare-feu utilisés permettent une plus grande atténuation des menaces, fournissent des ressources d’analyse plus informatives, améliorent l’archivage des enregistrements pour la conformité réglementaire et améliorent le provisionnement des accès de routine.
Les pare-feu de rôle utilisateur déclenchent deux actions :
Récupérer les informations sur les utilisateurs et les rôles associés au trafic
Déterminer l’action à entreprendre en fonction de six critères de correspondance dans le contexte de la paire de zones
Le champ source-identity permet de distinguer un pare-feu avec rôle d’utilisateur des autres types de pare-feu. Si l’identité source est spécifiée dans une stratégie pour une paire de zones particulière, il s’agit d’un pare-feu de rôle utilisateur. Les informations sur l’utilisateur et le rôle doivent être récupérées avant que la recherche de stratégie n’ait lieu. Si l’identité source n’est spécifiée dans aucune stratégie, la recherche d’utilisateurs et de rôles n’est pas nécessaire.
Pour récupérer des informations sur les utilisateurs et les rôles, les tables d’authentification recherchent une entrée avec une adresse IP correspondant au trafic. Si une entrée est trouvée, l’utilisateur est classé comme utilisateur authentifié. S’il n’est pas trouvé, l’utilisateur est classé comme utilisateur non authentifié.
Le nom d’utilisateur et les rôles associés à un utilisateur authentifié sont récupérés pour la mise en correspondance des stratégies. La classification d’authentification et les informations d’utilisateur et de rôle récupérées sont utilisées pour faire correspondre le champ d’identité source.
Les caractéristiques du trafic correspondent aux spécifications de la stratégie. Dans le contexte de la zone, la première stratégie qui correspond à l’utilisateur ou au rôle et les cinq critères de correspondance standard déterminent l’action à appliquer au trafic.
Les sections suivantes décrivent l’interaction entre la récupération des utilisateurs et des rôles et le processus de recherche de stratégies, les méthodes d’acquisition des attributions d’utilisateurs et de rôles, les techniques de configuration des stratégies de pare-feu de rôle d’utilisateur et un exemple de configuration des politiques de pare-feu de rôle d’utilisateur.
Processus de récupération des rôles d’utilisateur et de recherche de stratégies
Pour la recherche de stratégies, les politiques de pare-feu sont regroupées par paire de zones (la zone de départ et la zone d’à). Dans le contexte de la paire de zones, les politiques de pare-feu basées sur IP sont mises en correspondance avec le trafic en fonction de cinq critères : l’adresse IP source, le port source, l’adresse IP de destination, le port de destination et le protocole.
Les politiques de pare-feu incluent un sixième critère de correspondance : l’identité source. Le champ source-identity spécifie les utilisateurs et les rôles auxquels la stratégie s’applique. Lorsque le champ source-identity est spécifié dans une stratégie au sein de la paire de zones, les informations sur l’utilisateur et le rôle doivent être récupérées avant que la recherche de stratégie puisse être effectuée. (Si toutes les stratégies de la paire de zones sont définies sur any ou n’ont pas d’entrée dans le champ source-identity, les informations sur l’utilisateur et le rôle ne sont pas requises et les cinq critères de correspondance standard sont utilisés pour la recherche de stratégie.)
La table d’identification de l’utilisateur (UIT) fournit des informations sur les utilisateurs et les rôles d’un utilisateur actif qui a déjà été authentifié. Chaque entrée de la table mappe une adresse IP à un utilisateur authentifié et à tous les rôles associés à cet utilisateur.
Lorsque le trafic nécessite des données d’utilisateur et de rôle, chaque UIT enregistré est recherché pour une entrée avec la même adresse IP. Si un utilisateur n’a pas été authentifié, il n’y a pas d’entrée pour cette adresse IP dans la table. S’il n’existe pas d’entrée UIT, l’utilisateur est considéré comme un utilisateur non authentifié.
La recherche de stratégie reprend une fois que les informations sur l’utilisateur et le rôle ont été récupérées. Les caractéristiques du trafic sont comparées aux critères de correspondance des stratégies. Le champ source-identity d’une stratégie peut spécifier un ou plusieurs utilisateurs ou rôles, ainsi que les mots-clés suivants :
| authenticated-user | Utilisateurs authentifiés. |
| unauthenticated-user | Utilisateurs qui n’ont pas été authentifiés. |
| any | Tous les utilisateurs, quelle que soit leur capacité d’authentification. Si le champ source-identity n’est pas configuré ou s’il est défini sur l’une des stratégies de la paire de zones, seuls cinq critères sont mis en correspondance. |
| unknown-user | Les utilisateurs ne peuvent pas être authentifiés en raison d’une déconnexion du serveur d’authentification, telle qu’une panne de courant. |
Prenons l’exemple de user-c à qui le rôle de gestion est affecté. Lorsque le trafic de la zone de confiance vers la zone de non-confiance est reçu de l’utilisateur c à l’adresse IP 198.51.100.3, la recherche de la stratégie est lancée. Le tableau 1 représente trois stratégies dans un pare-feu de rôle d’utilisateur pour la paire de zones d’approbation et de désapprobation.
|
|
|
|
|
|
|
|
|
|---|---|---|---|---|---|---|---|---|
P1 |
confiance |
défiance |
192.0.2.0 |
203.0.113.0 |
quelconque |
http (en anglais) |
nier |
– |
P2 |
confiance |
défiance |
quelconque |
quelconque |
gestion |
quelconque |
permettre |
– |
P3 (en anglais) |
confiance |
défiance |
198.51.100.3 |
quelconque |
employé |
http (en anglais) |
nier |
– |
Toutes les stratégies de la paire de zones sont d’abord vérifiées pour une option source-identity. Si l’une des stratégies spécifie un utilisateur, un rôle ou un mot-clé, la récupération des utilisateurs et des rôles doit avoir lieu avant que la recherche de stratégie ne se poursuive. Le tableau 1 montre que la stratégie P2 spécifie mgmt comme identité source, ce qui en fait un pare-feu de rôle d’utilisateur. Les utilisateurs et les rôles doivent être récupérés avant que la recherche de stratégie puisse se poursuivre.
La récupération des utilisateurs et des rôles n’est pas effectuée si le mot-clé any ou si aucune identité de source n’est spécifiée dans toutes les stratégies du contexte de zone. Dans ce cas, seules les cinq valeurs restantes correspondent aux critères de stratégie.
L’adresse IP de l’UIT représentée dans le tableau 2 est vérifiée. Étant donné que l’adresse est trouvée, le nom d’utilisateur user-c, tous les rôles répertoriés pour user-c (dans ce cas, mgmt et employee) et le mot-clé authenticated-user deviennent des données utilisées pour faire correspondre le trafic au source-identity champ d’une stratégie.
Adresse IP source |
Nom d’utilisateur |
Rôles |
|---|---|---|
192.0.2.4 |
utilisateur-a |
employé |
198.51.100.3 |
utilisateur-c |
Gestion, Employé |
203.0.113.2 |
utilisateur(s) |
entrepreneur |
La recherche de stratégie reprend et compare les critères de correspondance de chaque stratégie du tableau 1 au trafic entrant. En supposant que tous les autres critères correspondent, la première stratégie qui spécifie user-c, mgmt, employee, authenticated-user ou n’importe quel dans le champ source-identity peut correspondre à ce trafic. La stratégie P1 correspond à l’un des rôles récupérés pour user-c, mais l’adresse IP source ne correspond pas ; Par conséquent, la recherche de politiques se poursuit. Pour la stratégie P2, tous les critères correspondent au trafic ; Par conséquent, l’action de stratégie est suivie et le trafic est autorisé. Notez que le trafic correspond également à la stratégie P3, mais que les politiques de pare-feu utilisateur sont terminales : la recherche de stratégie se termine lorsque la première correspondance de stratégie est trouvée. Étant donné que la stratégie P2 correspond à tous les critères, la recherche de stratégie se termine et la stratégie P3 n’est pas cochée.
Les stratégies peuvent également être basées sur la classification attribuée à un utilisateur à partir des résultats de récupération des utilisateurs et des rôles. Considérons un ensemble de stratégies différent pour la même paire de zones représentée par le tableau 3. Si le trafic provient de user-q à l’adresse IP 198.51.100.5, la récupération des utilisateurs et des rôles est nécessaire car le champ source-identity est spécifié dans au moins une des stratégies.
|
|
|
|
|
|
|
|
|
|---|---|---|---|---|---|---|---|---|
P1 |
confiance |
défiance |
quelconque |
quelconque |
utilisateur non authentifié |
http (en anglais) |
nier |
– |
P2 |
confiance |
défiance |
quelconque |
quelconque |
gestion |
quelconque |
permettre |
– |
P3 (en anglais) |
confiance |
défiance |
198.51.100.3 |
quelconque |
employé |
http (en anglais) |
nier |
– |
Lorsque les entrées UIT du tableau 2 sont cochées, aucune entrée n’est trouvée pour l’adresse IP 198.51.100.5. Par conséquent, l’utilisateur est considéré comme un utilisateur non authentifié. Lorsque la recherche de stratégie reprend, le trafic correspond à la stratégie P1 et le trafic est refusé.
Comprendre le tableau d’identification de l’utilisateur
Sur le pare-feu SRX Series, la table d’identification de l’utilisateur (UIT) contient l’adresse IP, le nom d’utilisateur et les informations de rôle de chaque utilisateur authentifié. Les entrées sont classées par adresse IP. Lorsqu’une stratégie de sécurité exige des informations sur le nom d’utilisateur et le rôle, tous les IUT sont vérifiés. La recherche de l’adresse IP dans une entrée de l’un des UIT signifie que l’utilisateur à cette adresse a déjà été authentifié avec succès.
Chaque source d’authentification gère son propre UIT indépendamment et fournit des fonctions de requête pour accéder aux données. Trois types d’interfaces utilisateur sont pris en charge : la table d’authentification locale, la table d’authentification UAC (Unified Access Control) et la table d’authentification de pare-feu.
| Local authentication table | UIT statique créé sur le pare-feu SRX Series, manuellement ou par programmation, à l’aide de commandes CLI. Tous les utilisateurs inclus dans la table d’authentification locale sont considérés comme des utilisateurs authentifiés. Lorsqu’une adresse IP correspondante est trouvée, les informations sur l’utilisateur et le rôle sont extraites de l’entrée de table et associées au trafic. Les informations sur les utilisateurs et les rôles peuvent être créées manuellement sur l’appareil ou transférées à partir d’un serveur d’authentification tiers, mais les données de la table d’authentification locale ne sont pas mises à jour en temps réel. |
| UAC authentication table | Un UIT dynamique poussé du service de contrôle d’accès Junos Pulse vers le pare-feu SRX Series. La table d’authentification UAC d’un service de contrôle d’accès Junos Pulse contient une entrée pour chaque utilisateur authentifié. Les données de ce tableau sont mises à jour et transmises au pare-feu SRX Series chaque fois que sa table d’authentification est mise à jour. Selon la configuration de l’équipement, l’authentification peut avoir lieu sur le service de contrôle d’accès Junos Pulse lui-même ou sur un serveur d’authentification tiers. Si le service de contrôle d’accès relaie des données à partir d’un serveur tiers, il restructure les données pour qu’elles correspondent au format de fichier de sa table d’authentification et les envoie au pare-feu SRX Series. |
| Firewall authentication table | Un UIT dynamique créé sur le pare-feu SRX Series lorsque Le |
- Tableau d’authentification locale
- Tableau d’authentification UAC
- Tableau d’authentification du pare-feu
- Provisionnement des stratégies avec les utilisateurs et les rôles
Tableau d’authentification locale
La table d’authentification locale est gérée à l’aide de commandes CLI qui permettent d’insérer ou de supprimer des entrées. Une table d’authentification locale peut être utilisée comme solution de secours lorsqu’un UIT dynamique n’est pas disponible, ou pour attribuer des informations d’utilisateur et de rôle à des périphériques qui ne peuvent pas s’authentifier auprès du réseau, tels que des imprimantes ou des serveurs de fichiers. La table d’authentification locale peut être utilisée à des fins de test ou pour démontrer le fonctionnement d’un pare-feu de rôle d’utilisateur sans authentification de pare-feu ni service de contrôle d’accès configuré.
Les adresses IP, les noms d’utilisateur et les rôles provenant d’une source d’authentification tierce peuvent être téléchargés et ajoutés à la table d’authentification locale par programmation à l’aide de commandes CLI. Si une source d’authentification définit des utilisateurs et des groupes, ceux-ci peuvent être configurés en tant que rôles et associés à l’utilisateur comme d’habitude.
Pour être conforme à la table d’authentification UAC, les noms d’utilisateur sont limités à 65 caractères et les noms de rôle à 64 caractères. La table d’authentification locale comporte un maximum de 10 240 entrées d’authentification sur les périphériques SRX1500 et supérieurs, 5 120 entrées d’authentification sur les périphériques SRX650 et inférieurs, en fonction de la version Junos OS de votre installation. La table d’authentification locale comporte 5 120 entrées d’authentification sur le pare-feu virtuel vSRX. Chaque entrée d’authentification peut être associée à un maximum de 200 rôles. La capacité maximale est basée sur une moyenne de 10 rôles attribués à chaque utilisateur. Il s’agit de la même capacité que celle spécifiée pour une table d’authentification UAC.
Utilisez la commande suivante pour ajouter une entrée à une table d’authentification locale. Notez que chaque entrée est saisie par adresse IP.
user@host> request security user-identification local-authentication-table add user user-name ip-address ip-address role [role-name role-name ]
L’option role d’une seule commande CLI accepte jusqu’à 40 rôles. Pour associer plus de 40 rôles à un seul utilisateur, vous devez entrer plusieurs commandes. Gardez à l’esprit les caractéristiques suivantes lorsque vous ajoutez ou modifiez des entrées d’utilisateur et de rôle d’authentification.
Les noms de rôle ne peuvent pas être identiques aux noms d’utilisateur.
L’utilisation de l’option
addavec une adresse IP et un nom d’utilisateur existants agrège les entrées de rôle. La table peut prendre en charge jusqu’à 200 rôles par utilisateur.L’utilisation de l’option
addavec une adresse IP existante et un nouveau nom d’utilisateur remplace le nom d’utilisateur existant pour cette adresse IP.L’agrégation des rôles n’affecte pas les sessions existantes.
Pour modifier la liste des rôles d’une entrée existante, vous devez supprimer l’entrée existante et ajouter une entrée avec la nouvelle liste de rôles.
Pour modifier l’adresse IP d’une entrée existante, vous devez supprimer l’entrée existante et ajouter une entrée avec la nouvelle adresse IP.
Une entrée peut être supprimée par adresse IP ou par nom d’utilisateur.
user@host> request security user-identification local-authentication-table delete (ip-address | user-name)
La table d’authentification locale peut être effacée à l’aide de la commande suivante :
user@host> clear security user-identification local-authentication-table
Pour afficher le contenu de la table d’authentification locale, utilisez la commande suivante show... :
user@host> show security user-identification local-authentication-table all (brief | extensive)
L’option brief (valeur par défaut) affiche les informations dans un format tabulaire séquencé par adresse IP. Les noms d’utilisateur et les listes de rôles sont tronqués pour s’adapter au format.
user@host> show security user-identification local-authentication-table all
Total entries: 2 Source IP Username Roles 198.51.100.1 user1 role1 203.0.113.2 user2 role2, role3
L’option extensive affiche le contenu complet de chaque champ. D’autres options limitent l’affichage à un seul nom d’utilisateur, une seule adresse IP ou un seul rôle.
user@host> show security user-identification local-authentication-table all extensive
Total entries: 3 Ip-address: 198.51.100.2 Username: user1 Roles: role1 Ip-address: 203.0.113.2 Username: user1 Roles: role2 Ip-address: 192.0.2.3 Username: user3 Roles: role1, role2
Tableau d’authentification UAC
Un pare-feu SRX Series peut agir en tant qu’exécuteur pour un service de contrôle d’accès Junos Pulse. Dans cette implémentation, le pare-feu SRX Series agit comme un point d’application de couche 3 et contrôle l’accès aux ressources à l’aide de stratégies de ressources basées sur IP qui ont été transférées du service de contrôle d’accès.
Lorsqu’il est déployé en tant que pare-feu de rôle d’utilisateur, le pare-feu SRX Series peut accéder au réseau UAC de la même manière pour récupérer les rôles d’utilisateur. Dans ce cas, les informations sur les utilisateurs et les rôles de tous les utilisateurs authentifiés sont envoyées à partir du service de contrôle d’accès.
La configuration du pare-feu SRX Series est similaire à celle d’un exécuteur. Pour établir la communication, les deux appareils ont besoin de paramètres de configuration et de mot de passe pour reconnaître l’autre. À partir du pare-feu SRX Series, connectez le service de contrôle d’accès en tant que contrôleur d’infrastructure.
[edit] user@host# set services unified-access-control infranet-controller ic-name address ip-address user@host# set services unified-access-control infranet-controller ic-name interface interface-name user@host# set services unified-access-control infranet-controller ic-name password password
À partir du service de contrôle d’accès, définissez le pare-feu SRX Series en tant que nouvel exécuteur. Utilisez le même mot de passe que celui spécifié sur le pare-feu SRX Series.
Les utilisateurs et les mots de passe sont définis sur le service de contrôle d’accès comme dans une configuration d’authentification standard. Un ou plusieurs rôles peuvent également être associés à des utilisateurs. Lorsqu’un utilisateur est authentifié, une entrée contenant l’adresse IP, le nom d’utilisateur et les rôles associés est ajoutée à la table d’authentification UAC du service de contrôle d’accès.
La table d’authentification UAC est transmise du service de contrôle d’accès au pare-feu SRX Series lorsque la connexion entre les deux périphériques est initialisée. Chaque fois qu’une entrée est ajoutée, supprimée ou mise à jour sur le service de contrôle d’accès, la table d’authentification UAC mise à jour est envoyée au pare-feu SRX Series.
Les stratégies d’accès aux ressources ne sont pas nécessaires sur le service de contrôle d’accès pour l’implémentation d’un pare-feu de rôle utilisateur. Le comportement d’accès est fourni dans les configurations de stratégie sur le pare-feu SRX Series. Si des stratégies d’accès aux ressources sont définies sur le service de contrôle d’accès, elles sont transmises au pare-feu SRX Series, mais elles ne sont pas utilisées à moins qu’une stratégie de pare-feu spécifique n’implémente les stratégies UAC dans le champ Action de la stratégie.
La commande suivante show services affiche le contenu de la table d’authentification UAC sur le pare-feu SRX Series, confirmant que la table a été correctement transmise à partir du service de contrôle d’accès :
user@host> show services unified-access-control authentication-table extended
Id Source IP Username Age Role name 3 192.0.2.1 april 60 Users 6 192.0.2.2 june 60 Employeees Total: 2
Le pare-feu SRX Series surveille les connexions et détecte si la communication avec le service de contrôle d’accès a été perdue. En fonction de la configuration UAC, le pare-feu SRX Series attend une réponse pendant un intervalle configuré avant d’émettre une autre demande. Si une réponse est reçue, le service de contrôle d’accès est considéré comme fonctionnel. Si aucune réponse n’est reçue après un délai d’expiration spécifié, la communication est considérée comme perdue et l’action de délai d’expiration est appliquée. La syntaxe de commande UAC suivante configure l’intervalle, le délai d’expiration et l’action de délai d’expiration :
user@host# set services unified-access-control interval seconds user@host# set services unified-access-control timeout seconds user@host# set services unified-access-control timeout-action (close | no-change | open)
Lors d’une déconnexion, si une recherche d’utilisateur et de rôle est tentée pour l’appareil déconnecté, un code d’échec est renvoyé, quelle que soit l’action de délai d’expiration. En cas de perte d’accès à toutes les sources d’authentification, le mot-clé unknown-user est associé à l’adresse IP. Lorsque la recherche de stratégie reprend, une stratégie avec utilisateur inconnu comme identité source correspond au trafic. En implémentant une stratégie spécifique pour les utilisateurs inconnus, vous pouvez créer une méthode pour gérer la perte de sources d’authentification.
Tableau d’authentification du pare-feu
L’authentification par pare-feu exige que les utilisateurs s’authentifient auprès du pare-feu SRX Series avant d’autoriser l’accès entre les zones et les appareils. Lors de la réception du trafic, l’utilisateur est invité à saisir un nom d’utilisateur et un mot de passe, qui sont ensuite vérifiés par rapport à un profil spécifié d’utilisateurs valides. Selon la configuration de l’appareil, l’authentification par pare-feu vérifie que le trafic telnet, HTTP, HTTPS (pour les appareils SRX5800, SRX5600 et SRX5400) et FTP a été authentifié localement ou par un serveur d’authentification RADIUS, LDAP ou SecureID.
Si l’authentification par pare-feu est utilisée sur un appareil, le processus d’authentification peut également fournir les informations sur le nom d’utilisateur et le rôle nécessaires pour les critères de correspondance du pare-feu du rôle de l’utilisateur. Dans ce cas, les informations sont collectées et conservées dans un UIT appelé table d’authentification de pare-feu. Une ou plusieurs stratégies d’accès dans la hiérarchie définissent les méthodes d’authentification à utiliser pour l’authentification edit access du pare-feu.
La table d’authentification du pare-feu doit être activée en tant que source d’authentification pour la récupération des informations sur le rôle de l’utilisateur. L’option priority spécifie l’ordre dans lequel tous les IUT seront vérifiés.
user@host# set security user-identification authentication-source firewall-authentication priority priority
Dans une stratégie de pare-feu pour une paire de zones donnée, le firewall-authentication service spécifié pour l’action permit lance l’authentification du trafic correspondant. Le user-firewall type d’authentification génère l’entrée UIT pour l’utilisateur authentifié. Le nom spécifié dans l’option access-profile identifie le profil à utiliser pour authentifier les utilisateurs valides.
[edit security policies from-zone zone to-zone zone policy policy-name] user@host# set match source-identity unauthenticated-user user@host# set then permit firewall-authentication user-firewall access-profile profile-name
L’entrée de la table UIT contient l’adresse IP du trafic mappé à l’utilisateur authentifié et aux groupes associés de l’utilisateur. Lorsque l’utilisateur n’est plus actif, l’entrée est supprimée de la table. Étant donné que des entrées sont continuellement ajoutées et supprimées au fur et à mesure que le trafic et les utilisateurs authentifiés changent, la table d’authentification du pare-feu est considérée comme dynamique.
Lorsque les stratégies d’une même paire de zones spécifient le champ dans le source-identity cadre de ses critères de correspondance, une entrée correspondant à l’adresse IP du trafic est recherchée dans toutes les interfaces utilisateur activées. S’ils sont trouvés, le nom d’utilisateur et les groupes associés sont récupérés pour la correspondance source-identité. (Les noms de groupe d’authentification des utilisateurs sont considérés comme des noms de rôle pour la correspondance source-identité.)
Provisionnement des stratégies avec les utilisateurs et les rôles
Tous les utilisateurs et rôles, qu’ils soient définis sur le pare-feu SRX Series ou sur le service de contrôle d’accès, sont conservés dans un fichier de rôles utilisateur sur le pare-feu SRX Series. Pour afficher tous les utilisateurs et rôles disponibles pour le provisionnement, utilisez les commandes suivantes show security... .
Les noms d’utilisateur et les rôles dans le tableau d’authentification du pare-feu ne sont pas inclus dans les affichages suivants.
Pour afficher tous les rôles disponibles pour le provisionnement, utilisez la
show security user-identification role-provision allcommande. Notez que les rôles de toutes les interfaces utilisateur sont répertoriés ensemble.Pour afficher tous les utilisateurs disponibles pour le provisionnement, utilisez la
show security user-identification user-provision allcommande.Pour afficher tous les utilisateurs et rôles disponibles pour le provisionnement, utilisez la
show security user-identification source-identity-provision allcommande.
Lorsqu’une configuration de stratégie est validée, le fichier de rôles d’utilisateur est vérifié pour déterminer si tous les utilisateurs et rôles spécifiés dans la stratégie sont disponibles pour le provisionnement. Si un utilisateur ou un rôle n’est pas trouvé, un avertissement identifie l’utilisateur ou le rôle manquant afin que vous puissiez le définir ultérieurement.
La stratégie est validée même si aucun utilisateur ou rôle n’est encore défini.
Obtention d’informations de nom d’utilisateur et de rôle via l’authentification du pare-feu
Les politiques de pare-feu de rôle d’utilisateur peuvent être intégrées à l’authentification de pare-feu à la fois pour authentifier les utilisateurs et pour récupérer les informations de nom d’utilisateur et de rôle. Les informations sont mappées à l’adresse IP du trafic, stockées dans la table d’authentification du pare-feu et utilisées pour l’application des stratégies de pare-feu des rôles d’utilisateur.
Les instructions CLI suivantes configurent l’authentification par pare-feu pour l’application du pare-feu de rôle d’utilisateur.
Configuration d’un pare-feu de rôle d’utilisateur pour la redirection du portail captif
Pour rediriger automatiquement les utilisateurs non authentifiés vers le service de contrôle d’accès, utilisez la fonctionnalité de portail captif UAC. La syntaxe suivante définit le profil du portail captif :
set services unified-access-control captive-portal profile-name redirect-traffic [unauthenticated | all] set services unified-access-control captive-portal profile-name redirect-url host-url
Le protocole Kerberos, utilisé pour le chiffrement de l’authentification, identifie le service de contrôle d’accès uniquement par son nom principal de service (SPN). Le protocole n’accepte pas d’adresse IP. Par conséquent, le format de l’URL de redirection doit être
service://hostname/options
Dans cette implémentation, le service est HTTP et le nom d’hôte est le nom de domaine complet du service de contrôle d’accès. Les options spécifiées après le nom d’hôte transmettent des informations supplémentaires au service de contrôle d’accès et redirigent l’utilisateur vers la destination d’origine, vers le pare-feu SRX Series ou vers la stratégie à l’origine de la redirection. Vous pouvez configurer les options à l’aide des paires de mots-clés et de variables suivantes :
| ?target=%dest-url% | Spécifie la ressource protégée à laquelle l’utilisateur tente d’accéder. |
| &enforcer=%enforcer-id% | Spécifie l’ID attribué au pare-feu SRX Series lorsqu’il est configuré en tant qu’exécuteur par le service de contrôle d’accès. |
| &policy=%policy-id% | Spécifie l’ID de stratégie chiffrée de la stratégie de sécurité qui a redirigé le trafic. |
Les instructions suivantes définissent le profil du portail captif nommé auth-redirect. Le portail captif redirige les utilisateurs non authentifiés vers l’URL du service de contrôle d’accès pour authentification. Une fois l’authentification réussie, le trafic est redirigé vers le pare-feu SRX Series.
[edit] user@host# set services unified-access-control captive-portal auth-redirect redirect-traffic unauthenticated user@host# set services unified-access-control captive-portal auth-redirect redirect-url "http://ic6000.example.com/?target=%dest-url%&enforcer=%enforcer-id%&policy=%policy-id%"
Un profil de portail captif défini s’affiche dans le cadre de la configuration du contrôle de compte d’utilisateur.
[edit] user@host#show services
unified-access-control {
captive-portal auth-redirect {
redirect-traffic unauthenticated;
redirect-url "http://ic6000.example.com/?target=%dest-url%&enforcer=%enforcer-id%&policy=%policy-id%";
}
}
Une fois le profil défini, une stratégie peut appliquer le portail captif en tant que service d’application lorsque certains critères correspondent. Lorsqu’un rôle d’utilisateur n’est pas authentifié, le portail captif de redirection d’authentification redirige le trafic de la zone de confiance vers la zone de confidentialité. L’exemple suivant définit la stratégie P1 pour appliquer le profil de portail captif de redirection d’authentification à tout trafic HTTP de l’approbation vers l’approbation non fiable :
[edit] user@host# set security policies from-zone trust to-zone untrust policy P1 match application http user@host# set security policies from-zone trust to-zone untrust policy P1 match source-identity unauthenticated-user user@host# set security policies from-zone trust to-zone untrust policy P1 then permit application-services uac-policy captive-portal auth-redirect
Exemple : Configuration d’un pare-feu de rôle utilisateur sur un équipement SRX Series
L’exemple suivant configure un pare-feu de rôle utilisateur sur un pare-feu SRX Series. Le pare-feu contrôle l’accès de la zone de confiance à la zone de non-confiance en fonction des utilisateurs actifs et authentifiés ou de leurs rôles associés. Les stratégies de pare-feu de rôle d’utilisateur établissent les restrictions suivantes :
Seuls les utilisateurs authentifiés sont autorisés à passer de la zone de confiance à la zone de non-confiance.
Les utilisateurs non authentifiés sont redirigés vers un service de contrôle d’accès pour s’authentifier.
Le trafic de l’IP 192.0.2.0 à l’IP 203.0.113.0 dans le contexte de la zone est limité. Seul le trafic provenant des utilisateurs ayant le rôle dev-abc, http-juniper-accessible ou ftp-accessible est autorisé. Le trafic autorisé est évalué plus en détail par les règles AppFW.
Le trafic autorisé identifié comme junos :FACEBOOK-ACCESS, junos :GOOGLE-TALK ou junos :MEEBO est refusé.
Le trafic autorisé pour toute autre application est autorisé.
Tout autre trafic provenant de la zone de confiance vers la zone de non-confiance est autorisé.
Exigences
Avant de commencer, vérifiez que le pare-feu SRX Series avec Junos OS version 12.1 ou ultérieure est configuré et initialisé.
Dans cet exemple, les informations sur les utilisateurs et les rôles associés à l’adresse IP du trafic sont fournies par un service de contrôle d’accès. Pour obtenir des instructions sur la configuration du serveur de contrôle d’accès, consultez Configurer Active Directory comme source d’identité.
Aperçu
Le Tableau 4 décrit un pare-feu qui répond aux exigences de cet exemple. Le pare-feu de rôle utilisateur se compose de quatre stratégies.
|
|
|
|
|
|
|
|
|
|---|---|---|---|---|---|---|---|---|
rôle-utilisateur-fw1 |
confiance |
défiance |
quelconque |
quelconque |
utilisateur non authentifié |
http (en anglais) |
permettre |
portail captif UAC |
rôle-utilisateur-fw2 |
confiance |
défiance |
192.0.2.0 |
203.0.113.0 |
dev-abc http-juniper-accessible ftp-accessible |
http (en anglais) |
permettre |
Ensemble de règles AppFW RS1 |
rôle-utilisateur-fw3 |
confiance |
défiance |
192.0.2.0 |
203.0.113.0 |
quelconque |
http (en anglais) |
nier |
|
rôle-utilisateur-fw4 |
confiance |
défiance |
quelconque |
quelconque |
quelconque |
http (en anglais) |
permettre |
|
Étant donné que le source-identity champ est spécifié pour au moins une des stratégies de ce pare-feu, les informations sur l’utilisateur et le rôle doivent être récupérées avant que la recherche de stratégie ne soit effectuée. L’adresse IP source du trafic est comparée aux éléments de l’UIT. Si l’adresse IP source est trouvée, le mot-clé authenticated, le nom d’utilisateur et tous les rôles associés à cet utilisateur sont stockés pour une utilisation ultérieure dans la recherche de stratégie. Si aucune entrée correspondante pour l’adresse IP n’est trouvée dans l’UIT, le mot-clé unauthenticated-user est stocké pour la recherche de stratégie.
Après avoir récupéré le nom d’utilisateur, les rôles et les mots-clés, la recherche de stratégie commence. Les caractéristiques du trafic entrant sont comparées aux critères de correspondance de chaque stratégie. Si une correspondance est trouvée, l’action spécifiée dans cette stratégie est effectuée.
Une correspondance de stratégie est un événement de terminal, et aucune politique après la correspondance n’est vérifiée. La séquence de stratégie influe sur l’action à effectuer pour faire correspondre le trafic. Dans cet exemple, les stratégies sont appliquées dans l’ordre suivant :
| user-role-fw1 | Applique le service de portail captif UAC à la correspondance du trafic HTTP avec le mot-clé unauthenticated-user, puis le redirige vers le service de contrôle d’accès pour l’authentification. Un profil UAC doit également être configuré pour identifier les spécifications du portail captif. |
| user-role-fw2 | Applique un ensemble de règles AppFW à tout trafic HTTP de l’adresse 192.0.2.0 à l’adresse 203.0.113.0 qui a un nom d’utilisateur ou un rôle correspondant. Un pare-feu applicatif doit également être configuré pour définir l’ensemble de règles. |
| user-role-fw3 | Refuse tout le trafic HTTP restant de l’adresse 192.0.2.0 à l’adresse 203.0.113.0 pour cette paire de zones. |
| user-role-fw4 | Autorise tout le trafic HTTP restant pour cette paire de zones. |
Configuration
L’exemple suivant vous oblige à naviguer à différents niveaux dans la hiérarchie de configuration. Pour obtenir des instructions sur la procédure, reportez-vous à la section Utilisation de l’éditeur CLI en mode configuration dans le guide de l’utilisateur CLI.
- Configuration de la redirection pour les utilisateurs non authentifiés
- Création d’une stratégie de rôle d’utilisateur avec un pare-feu applicatif
- Création des politiques de sécurité restantes en fonction de l’utilisateur et du rôle
Configuration de la redirection pour les utilisateurs non authentifiés
Procédure étape par étape
Lorsqu’une adresse IP n’est pas répertoriée dans l’UIT, le mot-clé unauthenticated-user est utilisé dans la recherche de stratégie. Au lieu de refuser l’accès à ce trafic, une stratégie peut rediriger le trafic vers un portail captif UAC pour authentification.
Il est important de positionner une stratégie de redirection pour les utilisateurs non authentifiés avant une stratégie pour « n’importe quel » utilisateur afin que l’authentification UAC ne soit pas éclipsée par une stratégie destinée aux utilisateurs authentifiés.
Pour configurer la redirection du pare-feu SRX Series vers le service de contrôle d’accès :
À partir du mode de configuration, configurez le profil UAC pour le périphérique acs du portail captif.
[edit] user@host# set services unified-access-control captive-portal acs-device redirect-traffic unauthenticated-user
Configurez l’URL de redirection pour le service de contrôle d’accès ou une URL par défaut pour le portail captif.
[edit] user@host# set services unified-access-control captive-portal acs-device redirect-url “https://%ic-url%/?target=%dest-url%&enforcer=%enforcer-id%”
Cette stratégie spécifie les variables cible et d’exécution par défaut à utiliser par le service de contrôle d’accès pour rediriger l’utilisateur après l’authentification. Cela permet de s’assurer que les modifications apportées aux spécifications du système n’affecteront pas les résultats de la configuration.
Note:Lorsque des variables, telles que
?target=, sont incluses dans la ligne de commande, vous devez placer l’URL et les variables entre guillemets.Configurez une stratégie de pare-feu de rôle d’utilisateur qui redirige le trafic HTTP de zone trust vers zone untrust si l’identité source est unauthenticated-user. Le nom du profil du portail captif est spécifié comme l’action à effectuer pour le trafic correspondant à cette stratégie.
[edit] user@host# set security policies from-zone trust to-zone untrust policy user-role-fw1 match source-address any user@host# set security policies from-zone trust to-zone untrust policy user-role-fw1 match destination-address any user@host# set security policies from-zone trust to-zone untrust policy user-role-fw1 match application http user@host# set security policies from-zone trust to-zone untrust policy user-role-fw1 match source-identity unauthenticated-user user@host# set security policies from-zone trust to-zone untrust policy user-role-fw1 then permit application-services uac-policy captive-portal acs-device
Si vous avez terminé de configurer les stratégies, validez les modifications.
[edit] user@host# commit
Résultats
En mode configuration, confirmez votre configuration en entrant les show services commandes and show security policies . Si la sortie n’affiche pas la configuration prévue, répétez les instructions de cet exemple pour corriger la configuration.
[edit]user@host#show services unified-access-control { captive-portal acs-device { redirect-traffic unauthenticated; redirect-url “https://%ic-ip%/?target=%dest-url%&enforcer=%enforcer-id%”
user@host# show security policies
from-zone trust to-zone untrust {
policy user-role-fw1 {
match {
source-address any;
destination-address any;
application http;
source-identity unauthenticated-user
}
then {
permit {
application-services {
uac-policy {
captive-portal acs-device;
}
}
}
}
}
}
Création d’une stratégie de rôle d’utilisateur avec un pare-feu applicatif
Procédure étape par étape
Cette stratégie restreint le trafic de IP192.0.2.0 à IP 203.0.113.0 en fonction de son utilisateur et de ses rôles, ainsi que de son application. La configuration définit un ensemble de règles d’application et l’applique au trafic de rôle d’utilisateur correspondant.
Configurez l’ensemble de règles AppFW rs1. L’ensemble de règles suivant refuse le trafic applicatif junos :FACEBOOK-ACCESS, junos :GOOGLE-TALK ou junos :MEEBO. Il applique le paramètre par défaut, autoriser, au trafic restant.
[edit security application-firewall rule-sets rs1] user@host# set rule r1 match dynamic-application [junos:FACEBOOK-ACCESS junos:GOOGLE-TALK junos:MEEBO] user@host# set rule r1 then deny user@host# set default-rule permit
Configurez une stratégie pour appliquer l’ensemble de règles de pare-feu d’application rs1 au trafic de l’adresse IP 192.0.2.0 à l’adresse IP 203.0.113.0 avec le rôle d’utilisateur dev-abc, http-mgmt-accessible ou ftp-accessible.
[edit] user@host# set security policies from-zone trust to-zone untrust policy user-role-fw2 match source-address 192.0.2.0 user@host# set security policies from-zone trust to-zone untrust policy user-role-fw2 match destination-address 203.0.113.0 user@host# set security policies from-zone trust to-zone untrust policy user-role-fw2 match application http user@host# set security policies from-zone trust to-zone untrust policy user-role-fw2 match source-identity [dev-abc http-mgmt-accessible ftp-accessible] user@host# set security policies from-zone trust to-zone untrust policy user-role-fw2 then permit application-services application-firewall rule-set rs1
Si vous avez terminé de configurer la stratégie, validez les modifications.
[edit] user@host# commit
Résultats
Vérifiez que l’ensemble de règles AppFW est configuré correctement. Si la sortie n’affiche pas la configuration prévue, répétez les instructions de cet exemple pour corriger la configuration.
[edit]user@host#show security application-firewall rule-sets rs1 { rule r1 { match { dynamic-application [junos:FACEBOOK-ACCESS junos:GOOGLE-TALK junos:MEEBO] } then { deny; } } default-rule { permit; } }
Création des politiques de sécurité restantes en fonction de l’utilisateur et du rôle
Procédure étape par étape
La procédure suivante configure les stratégies pour le trafic restant.
Configurez une stratégie pour refuser le trafic ayant la même adresse source et la même adresse de destination, mais avec des critères d’utilisateur et de rôle différents de ceux spécifiés dans la stratégie user-role-fw2.
[edit] user@host# set security policies from-zone trust to-zone untrust policy user-role-fw3 match source-address 192.0.2.0 user@host# set security policies from-zone trust to-zone untrust policy user-role-fw3 match destination-address 203.0.113.0 user@host# set security policies from-zone trust to-zone untrust policy user-role-fw3 match application http user@host# set security policies from-zone trust to-zone untrust policy user-role-fw3 match source-identity any user@host# set security policies from-zone trust to-zone untrust policy user-role-fw3 then deny
Configurez une stratégie de sécurité pour autoriser tout le reste du trafic HTTP de la zone trust à la zone untrust.
[edit] user@host# set security policies from-zone trust to-zone untrust policy user-role-fw4 match source-address any user@host# set security policies from-zone trust to-zone untrust policy user-role-fw4 match destination-address any user@host# set security policies from-zone trust to-zone untrust policy user-role-fw4 match application http user@host# set security policies from-zone trust to-zone untrust policy user-role-fw4 match source-identity any user@host# set security policies from-zone trust to-zone untrust policy user-role-fw4 then permit
Résultats
Vérifiez le contenu et l’ordre des stratégies de pare-feu pour le rôle de l’utilisateur. Si la sortie n’affiche pas la configuration prévue, répétez les instructions de cet exemple pour corriger la configuration.
[edit]user@host#show security policies ... from-zone trust to-zone untrust { policy user-role-fw1 { match { source-address any; destination-address any; application http; source-identity unauthenticated-user } then { permit { application-services { uac-policy { captive-portal acs-device; } } } } } } from-zone trust to-zone untrust { policy user-role-fw2 { match { source-address 192.0.2.0; destination-address 203.0.113.0; application http; source-identity [dev-abc http-juniper-accessible ftp-accessible] } then { permit { application-services { application-firewall { rule-set rs1 } } } } } } from-zone trust to-zone untrust { policy user-role-fw3 { match { source-address 192.0.2.0; destination-address 203.0.113.0; application http; source-identity any } then { deny } } } from-zone trust to-zone untrust { policy user-role-fw4 { match { source-address any; destination-address any; application http; source-identity any } then { permit } } }
Configuration des stratégies de ressources à l’aide du contrôle de compte d’utilisateur
Lors de l’utilisation de la fonctionnalité de pare-feu de rôle d’utilisateur, les stratégies de ressources ne sont pas nécessaires sur le service de contrôle d’accès. Toutefois, s’il existe des stratégies de ressources, elles sont transmises au pare-feu SRX Series lors de la connexion. Vous pouvez créer des stratégies qui utilisent ces stratégies de ressources en appliquant le service d’application UAC dans la configuration de la stratégie. Le tableau 5 présente trois politiques de pare-feu qui utilisent exclusivement les stratégies de ressources UAC :
|
|
|
|
|
|
|
|
|
|---|---|---|---|---|---|---|---|---|
P1 |
Zone 1 (en anglais) |
Zone 2 (en anglais) |
quelconque |
192.0.2.1 |
quelconque |
http (en anglais) |
permettre |
Sécurité du contenu |
P2 |
Zone 1 (en anglais) |
Zone 2 (en anglais) |
quelconque |
net2 |
quelconque |
http (en anglais) |
permettre |
IDP (en anglais) |
P3 (en anglais) |
Zone 1 (en anglais) |
Zone 2 (en anglais) |
quelconque |
quelconque |
quelconque |
quelconque |
permettre |
UAC (UAC) |
Les stratégies pour le trafic de la zone1 vers la zone2 ne déclenchent pas la récupération des utilisateurs et des rôles, car any est spécifié dans le champ source-identity de chaque stratégie. Dans cet exemple, le trafic vers l’adresse IP 192.0.2.1 est autorisé, mais doit répondre aux exigences de traitement du service d’application spécifié, dans ce cas, la sécurité du contenu. Le trafic vers net2 est autorisé et traité conformément aux exigences de traitement de l’IDP. Tout trafic restant est autorisé et traité conformément aux exigences de traitement de l’UAC.
La configuration de cette stratégie de pare-feu serait la suivante :
[edit]user@host#show security policies from-zone zone1 to-zone zone2 { policy P1 { match { source-address any; destination-address 192.0.2.1; source-identity any; application http; } then { permit { application-services { idp; } } } } } from-zone zone1 to-zone zone2 { policy P2 { match { source-address any; destination-address net2; source-identity any; application http; } then { permit { application-services { utm; } } } } } from-zone zone1 to-zone zone2 { policy P3 { match { source-address any; destination-address any; source-identity any; application any; } then { permit { application-services { uac-policy; } } } } }
Dans cet exemple de configuration, les champs d’action de P1 et P2 appliquent toutes les exigences qui ont été configurées pour l’IDP et la sécurité du contenu, respectivement. En spécifiant l’option uac-policy, les stratégies de ressources transmises au pare-feu SRX Series déterminent si la destination est accessible.
Un pare-feu de rôle d’utilisateur peut implémenter à la fois des stratégies de rôle d’utilisateur et des stratégies de ressources envoyées à partir du service de contrôle d’accès. Le tableau 6 présente les stratégies pour trois paires de zones.
|
|
|
|
|
|
|
|
|
|---|---|---|---|---|---|---|---|---|
P1 |
Zone 1 (en anglais) |
Zone 2 (en anglais) |
quelconque |
quelconque |
utilisateur non authentifié |
quelconque |
permettre |
portail captif UAC |
P2 |
Zone 1 (en anglais) |
Zone 2 (en anglais) |
quelconque |
192.0.2.1 |
rôle2 |
http (en anglais) |
permettre |
IDP (en anglais) |
P3 (en anglais) |
Zone 1 (en anglais) |
Zone 2 (en anglais) |
quelconque |
net2 |
utilisateur authentifié |
http (en anglais) |
permettre |
Sécurité du contenu |
P4 |
Zone 1 (en anglais) |
Zone 2 (en anglais) |
quelconque |
quelconque |
quelconque |
quelconque |
permettre |
|
P5 (en anglais) |
Zone 1 (en anglais) |
Zone3 (en anglais) |
quelconque |
quelconque |
quelconque |
quelconque |
permettre |
UAC (UAC) |
P6 (en anglais seulement) |
Zone 2 (en anglais) |
Zone3 (en anglais) |
quelconque |
quelconque |
quelconque |
quelconque |
permettre |
UAC (UAC) |
Le trafic de la zone1 à la zone2 est soumis à l’une des quatre stratégies de rôle d’utilisateur. La première de ces stratégies utilise le portail captif UAC pour rediriger les utilisateurs non authentifiés vers le service de contrôle d’accès à des fins d’authentification.
L’accès du trafic de la zone1 à la zone3 et de la zone2 à la zone3 est contrôlé par les stratégies de ressources envoyées à partir du service de contrôle d’accès.
Rôle d’utilisateur spécifique à la plate-forme Comportement des politiques de sécurité du pare-feu
Utilisez l’explorateur de fonctionnalités pour confirmer la prise en charge de fonctionnalités spécifiques par la plate-forme et la version.
Utilisez les tableaux suivants pour examiner le comportement spécifique à votre plate-forme :
- Comportement d’authentification local spécifique à la plate-forme
- Comportement d’authentification du pare-feu spécifique à la plate-forme
Comportement d’authentification local spécifique à la plate-forme
| Plateforme |
Différence |
|---|---|
| SRX Series |
|
Comportement d’authentification du pare-feu spécifique à la plate-forme
| Plateforme |
Différence |
|---|---|
| SRX Series |
|