Architecture d’approche zéro fédéral avec WireGuard

La publication Architecture d’approche zéro fédérale NIST (appelée aussi NIST SP 800-207) décrit ce que signifie “zéro fédéral” dans le contexte de la sécurisation des réseaux informatiques et des systèmes d’information, et qu’est une architecture standard de zéro fédéral. Pour de nombreuses organisations, passer à une architecture de zéro fédéral n’est pas quelque chose que vous faites en un jour — c’est un processus progressif d’amélioration d’un système ici, affinement d’une politique là-bas, collecte de plus de données de ce groupe d’appareils, et ainsi de suite.

Dans cet article, nous couvrirons les bases du zéro fédéral et montrerons comment vous pouvez commencer à migrer vers une architecture de zéro fédéral en utilisant WireGuard — même pour des systèmes et applications qui ne correspondent pas nativement au paradigme :

1. Principe fondamentaux du zéro fédéral
2. Composants de l’architecture de zéro fédéral
3. Contrôle des politiques pour les applications Web
4. Contrôle des politiques pour d’autres applications
5. Comment commencer
6. Gestion de base
7. Les prochaines étapes

Principe fondamental du zéro fédéral

Qu’est-ce que le zéro fédéral ? NIST SP 800-207 établit les principes du zéro fédéral (en section 2.1). Voici un résumé de chaque principe avec une étiquette courte et pithy, pour faciliter la retenue de chaque règle :

Tout est dans le champ d’application

(1) Toutes les sources de données et services de calcul sont considérées comme des ressources.

Inventoriez tout : appareils, systèmes, sources de données, applications – internes et externes. Incluez tous les SaaS (Software as a Service), PaaS (Platform as a Service), IaaS (Infrastructure as a Service) et tout autre service-à-service que vous utilisez ; ainsi que tout équipement externe ou opéré par d’autres qui peut accéder à vos ressources internes.

Réseau non fédéral

(2) Toutes les communications sont sécurisées indépendamment de la localisation du réseau.

En d’autres termes, assumez une pénétration. Vos adversaires sont dans votre réseau et sur vos appareils utilisateur (s’ils ne le sont pas maintenant, ils le seront à un certain moment), donc vous devez concevoir votre infrastructure interne pour les empêcher de se déplacer et d’accéder à plus de systèmes et de données.

Accès au niveau minimal

(3) L’accès aux ressources individuelles de l’entreprise est accordé sur une base sessionnelle.

L’accès aux systèmes et aux données doit être limité et granulaire : basé sur les sessions, orienté tâche et temporel.

Contrôle d’accès basé sur des politiques

(4) L’accès aux ressources est déterminé par une politique dynamique – y compris l’état observable de l’identité du client, de l’application/service et de l’actif demandeur – et peut inclure d’autres attributs comportementaux et environnementaux.

Au lieu d’accords d’accès statiques énumérant chaque utilisateur et ressource, l’accès devrait être défini par des politiques de niveau supérieur reflétant les besoins commerciaux ; et ces politiques devraient être évaluées dynamiquement en utilisant les attributs les plus à jour du utilisateur et de la ressource, ainsi que le comportement observé du utilisateur, de son appareil, de l’environnement réseau global et le paysage actuel des menaces.

Aucun appareil n’est de confiance

(5) L’entreprise surveille et mesure l’intégrité et la posture de sécurité de tous les actifs possédés et associés.

Tous les appareils (internes et externes) doivent être surveillés pour des risques potentiels de sécurité, et l’accès doit être restreint en fonction du risque.

Évaluation continue de l’accès

(6) Toutes les authentifications et autorisations des ressources sont dynamiques et strictement appliquées avant que l’accès ne soit autorisé.

L’authentification et l’autorisation doivent être évaluées continuellement pour vérifier non seulement les changements dans le utilisateur accédant et ses autorisations, mais aussi pour tenir compte des données entrantes sur le comportement du utilisateur, de son appareil, de l’environnement réseau, des menaces émergentes, etc. L’accès doit être coupé lorsque quelque chose change tel que ce qui fait que le utilisateur ou son appareil ne répond plus aux exigences de la politique pour accéder à une ressource.

Surveiller et enregistrer tout

(7) L’entreprise collecte autant d’informations que possible sur l’état actuel des actifs, de l’infrastructure réseau et des communications, et l’utilise pour améliorer sa posture de sécurité.

Collectez toutes les données que vous pouvez sur l’utilisateur, son appareil, votre réseau et l’environnement de menace mondiale, puis renvoyez tout cela à votre contrôle d’accès.

Composants du Zéro-Trust

Les composants principaux d’une architecture zéro-trust sont assez simples :

1. Un Sujet (c’est-à-dire un utilisateur) utilise

2. Un Système (c’est-à-dire un appareil local de l’utilisateur) pour se connecter via

3. Un Point d’exécution des politiques (PEP), qui vérifie avec

4. Un Point de décision des politiques (PDP), composé de

   1. Un Administrateur de politique (PA), qui communique sur les décisions d’accès (et gère les détails d’implémentation comme l’émission de crédentiels ou la gestion de l’état de session) entre le PEP et
   2. Un Engine de politique (PE), qui évalue les politiques d’accès pour prendre la décision d’accès ; et si l’accès est accordé, le PEP permet la connexion de poursuivre jusqu’à

5. Une Ressource (c’est-à-dire un système, une application ou une collection de données), l’objet de la connexion

Un diagramme d’une connexion individuelle ressemblerait à ceci :

Figure 1. Composants individuels d’une architecture zéro-trust

Bien que les politiques utilisées par ces composants zéro-trust soient applicables à l’ensemble de l’organisation, il peut y avoir de nombreux points d’exécution (PEPs) répartis tout au long du réseau de l’organisation ; et elle pourrait également avoir plusieurs points de décision (PDPs) pour gérer les vérifications d’accès pour différents types de technologies ou pour gérer les vérifications à des emplacements physiques différents :

Figure 2. Zero-trust avec plusieurs points de contrôle et décision

Contrôle des politiques pour les applications Web

Le contrôle des politiques pour les applications qui utilisent HTTP est généralement beaucoup plus facile avec une architecture zero-trust que pour les applications qui utilisent d’autres protocoles. Il existe de nombreux outils prêts à l’emploi (nginx, Apache, HAProxy, etc.) qui peuvent terminer les connexions TLS, décodifier la requête HTTP et vous permettre d’intégrer vos vérifications de politiques zero-trust avant de les transmettre à l’application serveur appropriée si les vérifications passent.

Bien que certains applications Web puissent nécessiter une réécriture de leurs systèmes d’authentification et d’autorisation pour permettre cela, plus et plus d’applications Web sont construites du fond en remontant avec des systèmes plug-and-play qui permettent de contrôler leur authentification et leur autorisation à travers un proxy HTTP (ou peuvent être personnalisés pour le faire avec une petite quantité d’effort).

Et de nombreuses applications Web qui sont exécutées externement en tant que SaaS permettent des technologies SSO (Single Sign-On), comme OIDC, OAuth2 ou SAML, qui permettent également le contrôle des politiques zero-trust.

Contrôle des politiques pour d’autres applications

Cependant, de nombreuses applications ou systèmes que les utilisateurs doivent accéder ne sont pas disponibles via HTTP. Des exemples courants comprennent des partages de fichiers, l’impression, le Voice-over-IP (VoIP), la vidéoconférence, le bureau à distance (RDP), l’accès aux bases de données et l’accès au terminal (SSH).

La mise en œuvre d’une stratégie de politique zero-trust pour ces applications peut être plus difficile, car il n’y a généralement pas de logiciel hors du rayon qui puisse servir comme proxy natif pour insérer une authentification et une autorisation personnalisées dans leur flux d’accès. Au lieu de mettre en œuvre un proxy natif pour chaque application, vous pouvez configurer la mise en œuvre de stratégie zero-trust via un outil de réseau virtuel comme WireGuard, associé à un pare-feu traditionnel comme iptables ou nftables.

L’authentification mutuelle obligatoire et la routage par clé cryptographique de WireGuard vous permettent de sécuriser l’affectation d’une adresse IP privée à un appareil. Cela vous permet ensuite d’imposer des politiques zero-trust pour l’appareil avec un pare-feu hors du rayon, en utilisant l’adresse IP de WireGuard pour identifier l’appareil.

Comment commencer

Commencez par une application et les appareils qui l’utilisent. Si le système auquel les utilisateurs se connecteraient normalement pour accéder à l’application peut héberger WireGuard et un pare-feu approprié, utilisez-le comme PEP (point de contrôle de stratégie). Sinon, configurez un autre hôte en tant que PEP, installez WireGuard et un pare-feu sur celui-ci, et bloquez toutes les connexions entrantes au réseau à l’application sauf via le PEP.

Sélectionnez une sous-réseau privé disponible pour le réseau WireGuard (nous utiliserons 10.0.0.0/24 dans notre exemple). Resservez une adresse pour le PEP lui-même (10.0.0.1) et une adresse pour l’application (10.0.0.2). Attribuez une adresse sur le sous-réseau WireGuard à chaque appareil qui doit accéder à l’application. Dans notre exemple, nous utiliserons 10.0.0.11 pour le portable d’Alice, 10.0.0.12 pour son téléphone et 10.0.0.13 pour le poste de travail de Bob.

Pour accéder à l’application, les utilisateurs utiliseront l’adresse du réseau WireGuard de l’application (10.0.0.2) ; et pour identifier chaque appareil utilisateur, notre infrastructure zéro-fidélité utilisera l’adresse du réseau WireGuard de l’appareil (par exemple 10.0.0.11 pour le portable d’Alice).

Configuration de WireGuard

La configuration de WireGuard pour notre PEP ressemblera à ceci :

# paramètres locaux pour le PEP
[Interface]
PrivateKey = AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEE=
Address = 10.0.0.1/24
ListenPort = 51820

# paramètres distants pour le portable d'Alice
[Peer]
PublicKey = fE/wdxzl0klVp/IR8UcaoGUMjqaWi3jAd7KzHKFS6Ds=
AllowedIPs = 10.0.0.11

# paramètres distants pour le téléphone d'Alice
[Peer]
PublicKey = jUd41n3XYa3yXBzyBvWqlLhYgRef5RiBD7jwo70U+Rw=
AllowedIPs = 10.0.0.12

paramètres distants pour le bureau de Bob

[Peer] PublicKey = MMsBeTT9v/7XNWB8a/jSMn9O8olPVNduUwvUPJ6eB14= AllowedIPs = 10.0.0.13

Et la configuration WireGuard pour chaque appareil qui doit accéder à l'application ressemblera à ceci (si l'adresse IP publique du PEP est `198.51.100.10`):

```bash
# paramètres locaux pour le portable d'Alice
[Interface]
PrivateKey = ABBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBFA=
Address = 10.0.0.11

# paramètres distants pour le PEP
[Peer]
PublicKey = /TOE4TKtAqVsePRVR+5AA43HkAK5DSntkOCO7nYq5xU=
Endpoint = 198.51.100.10:51820
AllowedIPs = 10.0.0.0/24

(Voir le guide WireGuard Hub et Spoke Configuration pour plus de détails sur chaque paramètre de configuration WireGuard.)

Configuration du Pare-feu

Configurez le pare-feu sur le PEP pour :

1. Traduire l’adresse virtuelle de l’application en adresse IP réelle de l’application (du point de vue du PEP lui-même)
2. Bloquer les connexions entrantes à l’application sauf depuis les adresses WireGuard des appareils autorisés
3. Enregistrer tous les accès à l’application

Si le PEP est sur le même hôte que l’application elle-même, un ensemble de règles de base pour un pare-feu nftables pourrait ressembler à ceci (si l’application est par exemple une partage de fichiers SMB) :

#!/usr/sbin/nft -f
flush ruleset

define pub_iface = "eth0"
define wg_iface = "wg0"
define wg_port = 51820

define pep = 10.0.0.1
define fileshare_virt = 10.0.0.2
define fileshare_real = $pep
define fileshare_tcp = { 139, 445 }
define fileshare_udp = { 137, 138 }

define alices_laptop = 10.0.0.11
define alices_phone = 10.0.0.12
define bobs_workstation = 10.0.0.13

table inet nat {
    chain prerouting {
        type nat hook prerouting priority -100; policy accept;
        # traduire l'adresse virtuelle de l'application en adresse IP réelle
        ip daddr $fileshare_virt dnat ip to $fileshare_real
    }
}

table inet filter {
    # ensemble de dispositifs autorisés à accéder au partage SMB
    set device-access-to-fileshare {
        typeof ip saddr
        elements = { $alices_laptop, $alices_phone, $bobs_workstation }
    }

    chain device-access-policies {
        # enregistrer les accès réseau non fiables
        log level debug prefix "device-access-policies: "
        # appliquer les politiques d'accès non fiables
        ip saddr @device-access-to-fileshare ip daddr $fileshare_real tcp dport $fileshare_tcp accept
        ip saddr @device-access-to-fileshare ip daddr $fileshare_real udp dport $fileshare_udp accept
        reject with icmpx type admin-prohibited
    }

    chain input {
        type filter hook input priority 0; policy drop;

        # accepter tous les paquets de boucle locale
        iif "lo" accept
        # accepter tous les paquets ICMP/ICMPv6
        meta l4proto { icmp, ipv6-icmp } accept
        # accepter tous les paquets qui font partie d'une connexion déjà établie
        ct state vmap { invalid : drop, established : accept, related : accept }
        # rejeter les nouvelles connexions au-delà de la limite de taux
        ct state new limit rate over 1/second burst 10 packets drop

        # accepter tous les paquets DHCPv6 reçus à une adresse locale
        ip6 daddr fe80::/64 udp dport dhcpv6-client accept
        # accepter tous les paquets WireGuard reçus sur une interface publique
        iifname $pub_iface udp dport $wg_port accept
        # filtrer les paquets entrants à partir du réseau WireGuard via la chaîne de politiques d'accès des appareils
        iifname $wg_iface goto device-access-policies

        # rejeter avec une réponse ICMP polie "port unreachable"
        reject
    }

```bash
chain forward {
    type filter hook forward priority 0; policy drop;
    reject with icmpx type host-unreachable
}
}

Cette configuration de pare-feu permet à Alice d’accéder au partage SMB en utilisant son adresse IP virtuelle WireGuard 10.0.0.2 (par exemple, smbclient //10.0.0.2/share1) depuis son ordinateur portable et son téléphone lorsque sa connexion WireGuard est active, et à Bob de son poste de travail lorsque sa connexion WireGuard est active.

(Voir le guide WireGuard avec Nftables pour plus de détails sur la configuration des pare-feux nftables avec WireGuard.)

PEP sur un Autre Hôte

Si le PEP est sur un autre hôte que l’application, modifiez la chaîne forward dans le jeu de règles nftables ci-dessus pour sauter à la chaîne device-access-policies pour les accès entrants depuis le réseau WireGuard et permettre le transfert des paquets renvoyés pour les connexions établies :

    chain forward {
        type filter hook forward priority 0; policy drop;

        # transférer tous les paquets qui font partie d'une connexion déjà établie
        ct state vmap { invalid : drop, established : accept, related : accept }
        # rejeter les nouvelles connexions au-delà du taux limité
        ct state new limit rate over 1/second burst 10 packets drop

        # filtrer les paquets entrants depuis le réseau WireGuard à travers la chaîne de politiques d'accès aux appareils
        iifname $wg_iface goto device-access-policies

        # rejeter avec une réponse ICMPx polie "hôte non atteignable"
        reject with icmpx type host-unreachable
    }

Modifiez également la définition de l’adresse IP réelle de l’application dans les règles ; dans l’exemple ci-dessus, remplacez la variable $fileshare_real par l’adresse IP réelle de l’hôte de l’application (du point de vue du PEP) :

define fileshare_real = 192.168.1.123

Assurez-vous également d’activer le transfert de paquets sur l’hôte PEP (par exemple sysctl -w net.ipv4.conf.all.forwarding=1) ; et soit ajustez le réseau entre l’hôte PEP et celui de l’application pour qu’il puisse router les paquets du réseau WireGuard, soit appliquez la masquerade des paquets à la configuration nftables du PEP en ajoutant la chaîne postrouting suivante à sa table nat :

table inet nat {
    chain prerouting {
        type nat hook prerouting priority -100; policy accept;
        # traduisez l'adresse virtuelle de l'application en adresse réelle
        ip daddr $fileshare_virt dnat ip to $fileshare_real
    }

    chain postrouting {
        type nat hook postrouting priority 100; policy accept;
        # masquerade les adresses du réseau WireGuard sur le LAN
        iifname $wg_iface oifname $pub_iface masquerade
    }
}

Accès distant au PEP

Assurez-vous également de sécuriser l’accès distant au PEP lui-même. Le seul port qui devrait être accessible à distance est le port d’écoute WireGuard (51820 dans notre exemple). Traitez tout accès distant au PEP comme une application protégée par le PEP : chaque appareil nécessitant un accès au PEP doit utiliser le réseau WireGuard, où son accès sera limité et enregistré par le pare-feu.

Par exemple, pour permettre à Alice d’administrer le PEP par SSH depuis son ordinateur portable, mettez à jour la chaîne device-access-policies de l’exemple précédent comme suit :

    # ensemble de dispositifs autorisés à accéder au partage de fichiers SMB
    set device-access-to-fileshare {
        typeof ip saddr
        elements = { $alices_laptop, $alices_phone, $bobs_workstation }
    }

    # ensemble de dispositifs autorisés à accéder au PEP lui-même pour l'administration
    set device-access-to-pep-admin {
        typeof ip saddr
        elements = { $alices_laptop }
    }

    chain device-access-policies {
        # enregistrer les accès réseau sans confiance
        log level debug prefix "device-access-policies: "
        # appliquer des politiques d'accès sans confiance
        ip saddr @device-access-to-fileshare ip daddr $fileshare_real tcp dport $fileshare_tcp accept
        ip saddr @device-access-to-fileshare ip daddr $fileshare_real udp dport $fileshare_udp accept
        ip saddr @device-access-to-pep-admin ip daddr $pep tcp dport ssh accept
        reject with icmpx type admin-prohibited
    }

Avec cette politique en place, et lorsque l’interface WireGuard de son ordinateur portable est active, Alice pourra se connecter au PEP par SSH à l’aide de l’adresse directe WireGuard du PEP (par exemple via ssh 10.0.0.1).

Gestion de base

Les règles de pare-feu que nous avons configurées ci-dessus représentent la première itération de nos politiques de contrôle d’accès à zéro fiori. Bien qu’elles soient primitives, elles sont déjà puissantes : elles affirment que seules Alice et Bob ont le droit d’accéder à notre application et sont authentifiés par la possession des clés privées WireGuard enregistrées pour leurs appareils.

Mise à jour des politiques

Plus tard, vous pouvez connecter ces règles à un moteur de politique dynamique pour les renforcer davantage ; mais initialement, vous pouvez simplement maintenir un ensemble de règles statiques dans votre système de gestion de configuration et les redéployer sur le PEP lorsque leurs paramètres changent. Nftables est particulièrement pratique pour cela : vous pouvez facilement extraire des morceaux et des parties de vos définitions de règles principales dans des fichiers externes qui peuvent être gérés et mis à jour séparément.

Par exemple, au lieu d’énumérer les appareils autorisés à accéder à chaque application dans notre fichier principal nftables.conf, nous pourrions simplement définir des ensembles vides pour ces appareils dans notre fichier principal et utiliser une instruction include à la fin du fichier principal pour inclure des fichiers supplémentaires d’un autre répertoire (/etc/nftables.conf.d/ dans ce cas) :

#!/usr/sbin/nft -f
flush ruleset

# ...

table inet filter {
    # ensemble d'appareils autorisés à accéder au partage de fichiers SMB
    set device-access-to-fileshare { type ip saddr; }

    # ensemble d'appareils autorisés à accéder au PEP lui-même pour l'administration
    set device-access-to-pep-admin { type ip saddr; }

    chain device-access-policies {
        # enregistrer les accès réseau à zéro fiori
        log level debug prefix "device-access-policies: "
        # appliquer les politiques d'accès à zéro fiori
        ip saddr @device-access-to-fileshare ip daddr $fileshare_real tcp dport $fileshare_tcp accept
        ip saddr @device-access-to-fileshare ip daddr $fileshare_real udp dport $fileshare_udp accept
        ip saddr @device-access-to-pep-admin ip daddr $pep tcp dport ssh accept
        reject with icmpx type admin-prohibited
    }

    # ...
}

include "/etc/nftables.conf.d/*.*"

Dans le répertoire inclus, nous pourrions créer un fichier comme celui-ci pour remplir l’ensemble device-access-to-fileshare, contenant les adresses IP WireGuard des appareils autorisés à accéder au partage de fichiers :

# /etc/nftables.conf.d/device-access-to-fileshare.conf
table inet filter { set device-access-to-fileshare { typeof ip saddr; elements = {
    10.0.0.11,
    10.0.0.12,
    10.0.0.13,
}; }; }

Et nous pourrions créer un deuxième fichier comme celui-ci pour remplir l’ensemble device-access-to-pep-admin, contenant les adresses IP WireGuard des appareils autorisés à administrer le PEP via SSH :

# /etc/nftables.conf.d/device-access-to-pep-admin.conf
table inet filter { set device-access-to-pep-admin { typeof ip saddr; elements = {
    10.0.0.11,
}; }; }

Vous pouvez stocker ces petits fichiers inclus tels quels dans votre système de gestion de configuration (SCM), ou les construire sur-le-champ à partir des règles de politique et de la liste d’inventaire dans votre base de données de gestion de configuration. Avec cette première itération, nous utilisons effectivement notre SCM comme notre moteur de stratégie zero-trust (PE) et nos pipelines CI/CD (Continuous Integration / Continuous Deploment) comme l’administrateur de stratégie (PA).

$ sudo nft -f /etc/nftables.conf

$ sudo nft add element inet filter device-access-to-fileshare { 10.0.0.14 }

$ sudo nft delete element inet filter device-access-to-fileshare { 10.0.0.13, 10.0.0.14 }

Ajout d’appareils utilisateurs

Pour ajouter un nouvel utilisateur ou appareil à l’application, vous avez simplement besoin de générer une nouvelle paire de clés publiques et d’adresse WireGuard pour le nouvel appareil de l’utilisateur ; ajoutez la clé publique et l’adresse IP de l’appareil au fichier de configuration WireGuard sur le PEP :

# paramètres locaux pour le PEP
[Interface]
PrivateKey = AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEE=
Address = 10.0.0.1/24
ListenPort = 51820

# ...

# paramètres distants pour le bureau de Cate
[Peer]
PublicKey = kAYKIv6gpBDqueaVNOsY8ddKmIC2dnnXJQ0iKzWxfBI=
AllowedIPs = 10.0.0.14

$ sudo bash -c 'wg syncconf wg0 <(wg-quick strip wg0)'

$ sudo wg set wg0 peer kAYKIv6gpBDqueaVNOsY8ddKmIC2dnnXJQ0iKzWxfBI= allowed-ips 10.0.0.14

$ sudo wg set wg0 peer kAYKIv6gpBDqueaVNOsY8ddKmIC2dnnXJQ0iKzWxfBI= remove

Surveillance des journaux

Toute instruction log que vous avez dans votre règleset nftables sera enregistrée dans la facility de messages du noyau. Si vous pipez déjà vos journaux de noyau vers votre SIEM (Système d’information et de gestion des événements de sécurité), et que vous enregistrez aux points suggérés dans le config nftables exemple ci-dessus, vous aurez un enregistrement de chaque nouvelle tentative de connexion (rejetée ou acceptée) au sein du réseau WireGuard.

Sinon, vous pouvez faire en sorte que le démon de journalisation du hôte pousse ces journaux dans un fichier ou un flux personnalisé de journal. Par exemple, si vous utilisez rsyslogd, vous pouvez ajouter la ligne suivante à votre configuration rsyslogd pour envoyer les messages contenant le préfixe de journalisation personnalisé device-access-policies: (que nous avons utilisé dans notre exemple de configuration nftables) au fichier /var/log/device-access-policies.log :

# /etc/rsyslog.d/20-nftables.conf
:msg,contains,"device-access-policies:" /var/log/device-access-policies.log

Les entrées de journal seront similaires à celles-ci, par exemple lorsque Alice démarre une nouvelle connexion SMB depuis son ordinateur portable au partage de fichiers :

Aug 22 23:52:41 pep kernel: [98200.220647] device-access-policies: IN=wg0 OUT=eth0 MAC= SRC=10.0.0.11 DST=192.168.1.123 LEN=60 TOS=0x00 PREC=0x00 TTL=63 ID=41412 DF PROTO=TCP SPT=39122 DPT=445 WINDOW=64860 RES=0x00 SYN URGP=0

Les Étapes Suivantes

Une fois que vous avez un PEP (Point de mise en œuvre de la stratégie) de base avec WireGuard et un pare-feu comme nftables en place, vous avez une base sólide pour votre architecture zéro-fidélité sur laquelle vous pouvez ajouter des politiques plus fortes et sophistiquées, ainsi que le suivi et l’analyse. Donc, la première chose à faire est d’appliquer cette même architecture à tout application ou système qui n’est pas actuellement bien sécurisé.

Politiques Dynamiques

La prochaine amélioration majeure à apporter est de mettre à niveau votre PDP (Point de décision de stratégie) afin de rendre votre PE (Générateur de stratégie) plus dynamique. Si vous n’avez pas d’automatisation en place pour mettre à jour automatiquement la configuration du pare-feu de chaque PEP lorsque l’administrateur accorde ou révoque un accès utilisateur à une application, faites-le d’abord.

Ensuite, vous pourriez envisager d’ajouter de l’automatisation pour temporairement bloquer les utilisateurs ou les appareils en fonction du comportement suspect. Cela pourrait être quelque chose aussi simple qu’un script personnalisé qui compile périodiquement une liste noire de IPs suspects à partir de vos flux d’intelligence des menaces et des journaux d’activité réseau, la sauvegarde dans votre SCM et le déploiement auprès de vos PEPs via un pipeline CI/CD.

Cependant, vous pourriez envisager de déployer un outil spécialisé pour définir et mettre en œuvre des politiques complexes, comme OPA, Permify, Aserto ou une variété d’autres produits commerciaux.

Dans un monde idéal, vous auriez un seul PE (répliqué dans plusieurs environnements selon la nécessité) que vous pouvez utiliser uniformément pour tous vos PEPs et qui est capable de combiner toutes les éléments suivants dans ses décisions d’accès :

1. Votre système de gestion des identités
2. Votre inventaire d’actifs
3. Vos politiques d’accès aux données
4. Vos journaux d’activité réseau et système
5. Des flux d’intelligence des menaces externes
6. Vos systèmes de gestion et de surveillance des actifs
7. Toute autre outil d’analyse de sécurité (SIEM, XDR, etc) que vous utilisez

Plus et Meilleure Données

Une fois que vous avez un PDP qui peut utiliser des sources de données plus sophistiquées, vous pouvez améliorer la quantité et la variété de données que vous lui fournissez. Vous pourriez également vouloir affiner le journalisation du pare-feu sur vos PEPs afin de fournir au PDP des informations supplémentaires, comme les adresses IP publiques utilisées par les appareils distants se connectant aux PEPs (consultez certains de nos autres articles sur la surveillance de l’utilisation de WireGuard pour plus d’ suggestions à ce sujet).

Vous devriez également vous assurer que vous avez un agent de gestion des points de terminaison en cours d’exécution sur tous les appareils autorisés à se connecter à vos PEPs. Ces agents seront capables de fournir au PE des informations sur le niveau de patchage de l’appareil, l’intégrité de ses composants système et tout comportement inhabituel ou suspect récemment observé par son utilisateur.

Cela permettra à votre PE de bloquer l’accès aux applications pour les utilisateurs qui sont autrement autorisés à utiliser l’application – mais uniquement lorsque vous avez une grande confiance que l’utilisateur est en réalité celui qu’il dit être, et non un adversaire qui a compromis le périphérique de l’utilisateur. L’ajout de l’authentification multi-facteur WireGuard peut également renforcer davantage votre confiance dans l’authenticité de l’identité de l’utilisateur du périphérique.

8/23/2022

by Justin Ludwig

• WireGuard
• Réseautage
• Pare-feu
• nftables
• Hub et Spoke