Architecture “zéro trust” avec Wireguard

La publication NIST Zero Trust Architecture (alias NIST SP 800-207) décrit ce que « zéro confiance » signifie dans le contexte de la sécurisation des réseaux informatiques et des systèmes d’information, et à quoi ressemble une architecture standard zéro confiance. Pour de nombreuses organisations, passer à une architecture de confiance zéro ne se fait pas du jour au lendemain — c’est un processus graduel d’amélioration d’un système ici, d’affinement d’une politique là-bas, de collecte de plus de données à partir de ce groupe d’appareils, etc.

Dans cet article, nous couvrirons les bases de la confiance zéro et vous montrerons comment vous pouvez commencer à migrer vers une architecture de confiance zéro à l’aide de WireGuard — même pour les systèmes et les applications qui ne correspondent pas nativement au paradigme :

• Principes de la confiance zéro
• Composants Zero Trust
• Application des politiques pour les applications Web
• Application des politiques pour d’autres applications
• Comment commencer
• Gestion de base
• Les prochaines étapes

Principes de la confiance zéro

Que signifie zéro confiance ? NIST SP 800-207 énonce les principes de la confiance zéro (dans la section 2.1). Vous trouverez un extrait dans les sections ci-dessous et un résumé de chaque principe avec une étiquette courte et concise, pour qu’il soit facile de garder chaque principe à l’esprit :

Tout est dans le périmètre.

Le réseau n’est pas de confiance

Accès le mons privilégié

Contrôle d’accès baseè sur les politiques

Aucun appareil n’est approuvé

Evaluation continu de l’accès

Surveillez et enregistrez tout.

Composants Zero Trust

Les composants de base d’une architecture Zero Trust sont assez simples :

• Un sujet (c’est-à-dire un utilisateur) utilise
• Un système (c’est-à-dire un appareil utilisateur local) pour se connecter via
• Un point d’application des politiques (PEP), qui vérifie avec
• Un point de décision politique (PDP), composé de
  • Un administrateur de politique (PA), qui communique sur les décisions d’accès (et gère les détails de mise en œuvre comme l’émission d’informations d’identification ou la gestion de l’état de la session) entre le PEP et
  • Un moteur 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 autorise la poursuite de la connexion vers
• 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 :

Application des politiques pour les applications Web

L’application des politiques pour les applications qui utilisent HTTP est généralement beaucoup plus facile avec une architecture de confiance zéro que les applications qui utilisent d’autres protocoles. Il existe de nombreux outils prêts à l’emploi (nginx, Apache, [HAProxy](https://www. haproxy.org/), etc.) qui peut mettre fin aux connexions TLS, décoder la requête HTTP et vous permettre de brancher vos vérifications de politique de confiance zéro, avant de la transmettre par proxy au serveur d’application approprié si les vérifications réussissent.

Alors que certaines applications Web peuvent avoir besoin de réécrire leurs systèmes d’authentification et d’autorisation pour permettre cela, de plus en plus d’applications Web sont construites à partir de zéro avec des systèmes enfichables qui permettent de contrôler leur authentification et leur autorisation via un proxy HTTP (ou peuvent être personnalisés le faire avec un peu d’effort).

Et de nombreuses applications Web exécutées en externe en tant que SaaS autorisent les technologies SSO (authentification unique), telles que OIDC, OAuth2 ou SAML, qui permettent également l’application d’une politique de confiance zéro.

Application des politiques pour d’autres applications

Cependant, de nombreuses applications ou systèmes auxquels les utilisateurs doivent accéder ne sont pas disponibles via HTTP. Les exemples courants incluent les partages de fichiers, l’impression, la voix sur IP (VoIP), la visioconférence, le bureau à distance (RDP), l’accès à la base de données et l’accès au terminal (SSH).

L’application de la politique de confiance zéro pour des applications comme celle-ci peut être plus difficile, car il n’existe généralement pas de logiciel prêt à l’emploi qui peut proxy ces applications de manière native pour insérer une authentification et une autorisation personnalisées dans leur flux d’accès. Au lieu d’implémenter un proxy natif pour chacune de ces applications, vous pouvez à la place configurer l’application d’une politique de confiance zéro via un outil de réseau virtuel comme WireGuard, associé à un pare-feu traditionnel comme iptables ou nftables.

L’authentification mutuelle obligatoire et le routage de clé de chiffrement de WireGuard vous permettent de lier en toute sécurité une adresse IP privée à un appareil. Cela vous permet à son tour d’appliquer des politiques de confiance zéro pour l’appareil avec un pare-feu standard, en utilisant l’adresse IP WireGuard pour identifier l’appareil.

Comment commencer

Commencez avec une application et les appareils qui l’utilisent. Si le système auquel les utilisateurs se connectent normalement pour accéder à l’application peut héberger WireGuard et un pare-feu approprié, utilisez-le comme PEP (point d’application de la politique). Sinon, configurez un autre hôte en tant que PEP, installez WireGuard et un pare-feu dessus, et bloquez toutes les connexions réseau entrantes vers l’application, sauf via le PEP.

Sélectionnez un sous-réseau privé disponible pour le réseau WireGuard (nous utiliserons 10.0.0.0/24 dans notre exemple). Réservez une adresse pour le PEP lui-même (10.0.0.1) et une adresse pour l’application (10.0.0.2). Désignez une adresse sur le sous-réseau WireGuard pour chaque appareil qui doit accéder à l’application. Dans notre exemple, nous utiliserons 10.0.0.11 pour l’ordinateur 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 pour l’application (10.0.0.2) ; et pour identifier l’appareil de chaque utilisateur, notre infrastructure zéro confiance utilisera l’adresse du réseau WireGuard pour l’appareil (par exemple 10.0.0.11 pour l’ordinateur portable d’Alice).

Configuration de Wireguard

La configuration WireGuard pour notre PEP ressemblera à ceci :

# local settings for the PEP
[Interface]
PrivateKey = AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEE=
Address = 10.0.0.1/24
ListenPort = 51820

# remote settings for Alice's laptop
[Peer]
PublicKey = fE/wdxzl0klVp/IR8UcaoGUMjqaWi3jAd7KzHKFS6Ds=
AllowedIPs = 10.0.0.11

# remote settings for Alice's phone
[Peer]
PublicKey = jUd41n3XYa3yXBzyBvWqlLhYgRef5RiBD7jwo70U+Rw=
AllowedIPs = 10.0.0.12

# remote settings for Bob's workstation
[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) :

# local settings for Alice's laptop
[Interface]
PrivateKey = ABBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBFA=
Address = 10.0.0.11

# remote settings for the PEP
[Peer]
PublicKey = /TOE4TKtAqVsePRVR+5AA43HkAK5DSntkOCO7nYq5xU=
Endpoint = 198.51.100.10:51820
AllowedIPs = 10.0.0.0/24

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

Configuration du Firewall

Configurez le pare-feu sur le PEP pour :

• Traduire l’adresse virtuelle de l’application en adresse IP réelle de l’application (du point de vue du PEP lui-même)
• Bloquer les connexions entrantes vers l’application, sauf à partir des adresses WireGuard des appareils autorisés
• 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 ressemblerait à ceci (si l’application est par exemple un 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;
        # translate application's virtual address to real address
        ip daddr $fileshare_virt dnat ip to $fileshare_real
    }
}

table inet filter {
    # set of devices authorized to access SMB fileshare
    set device-access-to-fileshare {
        typeof ip saddr
        elements = { $alices_laptop, $alices_phone, $bobs_workstation }
    }

    chain device-access-policies {
        # log zero-trust network access
        log level debug prefix "device-access-policies: "
        # enforce zero-trust access policies
        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;

        # accept all loopback packets
        iif "lo" accept
        # accept all icmp/icmpv6 packets
        meta l4proto { icmp, ipv6-icmp } accept
        # accept all packets that are part of an already-established connection
        ct state vmap { invalid : drop, established : accept, related : accept }
        # drop new connections over rate limit
        ct state new limit rate over 1/second burst 10 packets drop

        # accept all DHCPv6 packets received at a link-local address
        ip6 daddr fe80::/64 udp dport dhcpv6-client accept
        # accept all WireGuard packets received on a public interface
        iifname $pub_iface udp dport $wg_port accept
        # filter packets inbound from WireGuard network through device access policies chain
        iifname $wg_iface goto device-access-policies

        # reject with polite "port unreachable" icmp response
        reject
    }

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

Cette configuration de pare-feu permettrait à Alice d’accéder au partage de fichiers SMB en utilisant son adresse IP WireGuard virtuelle de 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 depuis son poste de travail lorsque sa connexion WireGuard est active.

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

PEP sur un hôte différent

Si le PEP se trouve sur un hôte différent de l’application, modifiez la chaîne de transfert dans l’ensemble de règles nftables ci-dessus pour accéder à la chaîne de politiques d’accès aux périphériques pour l’accès entrant depuis le réseau WireGuard et pour lui permettre de transférer les paquets de retour pour les connexions établies. :

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

        # forward all packets that are part of an already-established connection
        ct state vmap { invalid : drop, established : accept, related : accept }
        # drop new connections over rate limit
        ct state new limit rate over 1/second burst 10 packets drop

        # filter packets inbound from WireGuard network through device access policies chain
        iifname $wg_iface goto device-access-policies

        # reject with polite "host unreachable" icmp response
        reject with icmpx type host-unreachable
    }

Modifiez également la définition de l’adresse IP réelle de l’application dans le jeu de 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

Activez également le transfert de paquets sur l’hôte PEP (par exemple, sysctl -w net.ipv4.conf.all.forwarding=1) ; et ajustez le réseau entre l’hôte PEP et l’hôte d’application pour pouvoir acheminer les paquets depuis le réseau WireGuard, ou appliquez le masquage de paquets à la configuration nftables du PEP en ajoutant la chaîne de postroutage suivante à sa table nat :

table inet nat {
    chain prerouting {
        type nat hook prerouting priority -100; policy accept;
        # translate application's virtual address to real address
        ip daddr $fileshare_virt dnat ip to $fileshare_real
    }

    chain postrouting {
        type nat hook postrouting priority 100; policy accept;
        # masquerade WireGuard network addresses on LAN
        iifname $wg_iface oifname $pub_iface masquerade
    }
}

Accès à distance au PEP

Assurez-vous également de verrouiller l’accès à distance 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 à distance nécessaire au PEP comme une application protégée par le PEP lui-même : chaque appareil qui a besoin d’accéder 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 via SSH à partir de son ordinateur portable, mettez à jour la chaîne device-access-policies de l’exemple ci-dessus à la suivante :

# set of devices authorized to access SMB fileshare
    set device-access-to-fileshare {
        typeof ip saddr
        elements = { $alices_laptop, $alices_phone, $bobs_workstation }
    }

    # set of devices authorized to access PEP itself for administration
    set device-access-to-pep-admin {
        typeof ip saddr
        elements = { $alices_laptop }
    }

    chain device-access-policies {
        # log zero-trust network access
        log level debug prefix "device-access-policies: "
        # enforce zero-trust access policies
        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 sur son ordinateur portable est active, Alice pourra se connecter au PEP via SSH en utilisant l’adresse WireGuard directe du PEP (par exemple via ssh 10.0.0.1).

Gestion de base

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

Polotiques de mise à jours

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

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

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

# ...

table inet filter {
    # set of devices authorized to access SMB fileshare
    set device-access-to-fileshare { typeof ip saddr; }

    # set of devices authorized to access PEP itself for administration
    set device-access-to-pep-admin { typeof ip saddr; }

    chain device-access-policies {
        # log zero-trust network access
        log level debug prefix "device-access-policies: "
        # enforce zero-trust access policies
        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 créer à la volée à partir des règles de politique et de la liste d’inventaire de votre base de données de gestion de configuration. Avec cette première itération, nous utilisons efficacement notre SCM comme moteur de politique de confiance zéro (PE) et nos pipelines CI/CD (intégration continue/déploiement continu) comme administrateur de politique (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 tout nouvel utilisateur ou appareil à l’application, il vous suffit de générer une nouvelle paire de clés publiques et une adresse WireGuard pour l’appareil du nouvel utilisateur ; ajoutez la clé publique et l’adresse IP de l’appareil à la configuration WireGuard sur le PEP :

# local settings for the PEP
[Interface]
PrivateKey = AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEE=
Address = 10.0.0.1/24
ListenPort = 51820

# ...

# remote settings for Cate's workstation
[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

Journaux de surveillance

Toutes les instructions de journal que vous avez dans votre ensemble de règles nftables seront enregistrées dans la fonction de messagerie du noyau. Si vous dirigez déjà vos journaux de noyau vers votre système SIEM (Security Information and Event Management) et que vous vous connectez aux points suggérés dans l’exemple de configuration nftables ci-dessus, vous aurez un enregistrement de chaque nouvelle connexion tentée (rejetée ou acceptée) au sein du réseau WireGuard.

Sinon, vous pouvez demander au démon de journalisation de l’hôte de transférer ces journaux dans un fichier journal ou un flux personnalisé. Par exemple, si vous utilisez rsyslogd, vous pouvez ajouter la ligne suivante à votre configuration {rsyslogd pour envoyer des messages contenant le préfixe de journal personnalisé device-access-policies : (que nous avons utilisé dans notre exemple de configuration nftables) au fichier /var/log Fichier /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 ressembleront à ceci, par exemple lorsqu’Alice démarre une nouvelle connexion SMB depuis son ordinateur portable vers le 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 (Policy Enforcement Point) de base avec WireGuard et un pare-feu comme nftables en place, vous disposez d’une base solide pour votre architecture zéro confiance sur laquelle vous pouvez superposer des politiques, une surveillance et une analyse plus solides et plus sophistiquées. Donc, la première chose que vous voudrez faire est d’appliquer cette même architecture à toutes les applications ou tous les systèmes qui ne sont actuellement pas bien sécurisés.

Politiques Dynamiques

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

Ensuite, vous voudrez peut-être ajouter une automatisation pour bloquer temporairement les utilisateurs ou les appareils en fonction d’un comportement suspect. Il peut s’agir de quelque chose d’aussi simple qu’un script personnalisé qui compile périodiquement une liste de blocage d’adresses IP suspectes à partir de vos flux de renseignements sur les menaces et de vos journaux d’activité réseau, l’enregistre dans votre SCM et la transmet à vos PEP via un pipeline CI/CD.

Cependant, vous souhaiterez peut-être éventuellement déployer un outil plus 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é sur plusieurs environnements si nécessaire) que vous pouvez utiliser uniformément pour tous vos PEP, et qui est capable d’intégrer tous les éléments suivants dans ses décisions d’accès :

• Votre système de gestion des identités
• Votre inventaire d’actifs
• Vos politiques d’accès aux données
• Journaux d’activité de votre réseau et de votre système
• Flux externes de renseignements sur les menaces
• Vos systèmes de gestion et de surveillance des actifs
• Tout autre outil d’analyse de sécurité (SIEM, XDR, etc.) que vous utilisez

Plus de données pertinentes

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é des données que vous y introduisez. Vous souhaiterez peut-être affiner la journalisation du pare-feu sur vos PEP pour fournir au PDP des informations supplémentaires, telles que les adresses IP publiques utilisées par les périphériques distants se connectant aux PEP (consultez certains de nos autres articles sur la surveillance de l’utilisation de WireGuard pour plus d’informations). propositions à ce sujet).

Vous devez également vous assurer qu’un agent de gestion des points de terminaison s’exécute sur tous les appareils autorisés à se connecter à vos PEP. Ces agents seront en mesure de fournir à votre PE des informations sur le niveau de correctif de l’appareil, l’intégrité de ses composants système et tout comportement inhabituel ou suspect que son utilisateur a récemment adopté.

Cela permettra à votre EP de bloquer l’accès aux applications des utilisateurs qui sont autrement autorisés à utiliser l’application — mais autorisés uniquement lorsque vous avez une grande confiance dans le fait que l’utilisateur est réellement celui qu’il prétend être, et non un adversaire qui a compromis l’appareil de l’utilisateur . L’ajout de l’authentification multifacteur WireGuard peut également renforcer votre confiance dans l’authenticité de l’identité de l’utilisateur de l’appareil.