Access Gate mit Fortinet FortiGate bereitstellen

Dieser Leitfaden führt eine Fortinet FortiGate von „Access Gate im Rack" bis „OT-Datenverkehr fließt durch das Gate", von Anfang bis Ende. Sie verbinden zwei Ports, geben dem Gate einen Platz im Netzwerk und wählen, wie der Datenverkehr dorthin gelangt. An den OT-Geräten ändert sich nichts. Die CLI wird gezeigt; jeder Schritt hat ein Äquivalent unter Network und Policy & Objects in der GUI.

Was Sie aufbauen werden

Das Access Gate ist ein physisches Gerät, das Sie mit zwei Ports an zwei verschiedenen Subnetzen verbinden: einem Admin-Port in Ihrem Admin-VLAN und einem Protection-Port in einem kleinen dedizierten Subnetz, das den Datenverkehr trägt, den Sie durch das Gate leiten.

Referenz-Lab

1. Physische Konnektivität: zwei Ports, zwei Subnetze

Platzieren Sie den Admin-Port und den Protection-Port in verschiedenen Subnetzen, damit Management-Datenverkehr und gesteuerter Datenverkehr niemals eine Broadcast-Domäne teilen. Verwenden Sie zwei physische Ports (oder zwei VLAN-Subinterfaces an einem Trunk).

config system interface
    edit "admin"
        set ip 192.168.254.1 255.255.255.0
        set allowaccess ping https ssh
        set interface "port5"
        set vlanid 254
    next
    edit "ag-protect"
        set ip 100.65.0.1 255.255.255.248
        set allowaccess ping
        set interface "port1"
        set vlanid 65
    next
end

Verbinden Sie den FortiGate-Port, der admin trägt, mit dem Access Gate Admin-Port (5) und den Port, der ag-protect trägt, mit dem Protection-Port (1). Das Admin-Interface bezieht eine DHCP-Lease vom Admin-VLAN oder fällt nach etwa einer Minute auf 10.0.0.1 zurück, falls keine vorhanden ist; setzen Sie es über die Konsole statisch auf 192.168.254.50, wenn Sie eine feste Adresse bevorzugen.

2. Dem Overlay eine Route geben

Das Secure Twin befindet sich im Overlay 100.64.0.0/16, dem parallelen Adressraum, in dem jedes Asset einen Twin erhält. Fügen Sie eine statische Route hinzu, damit jeder Datenverkehr, der für diesen Bereich bestimmt ist, über 100.65.0.6, den Protection-Port des Access Gate, weitergeleitet wird (über das Interface ag-protect):

config router static
    edit 0
        set dst 100.64.0.0 255.255.0.0
        set gateway 100.65.0.6
        set device "ag-protect"
    next
end

Zu lesen als: Für das Zielnetzwerk 100.64.0.0/16 das Paket an 100.65.0.6 über ag-protect senden. Von nun an verlässt alles, was an eine Twin-(Overlay-)Adresse adressiert ist, die FortiGate über den Protection-Link, kommt am Access Gate an, und das Gate leitet es per Proxy an das echte Gerät weiter. Das Ansprechen einer Twin-Adresse ist also das, was den Datenfluss durch das Gate zieht.

Fügen Sie eine Firewall-Richtlinie hinzu, die dem OT-Subnetz den Zugriff auf ag-protect (und zurück) erlaubt, damit die FortiGate den gesteuerten Datenverkehr weiterleitet statt verwirft.

3. DNS auf das Access Gate zeigen lassen

Das Gate betreibt einen Resolver unter 100.65.0.6, der Asset-Namen in Overlay-Adressen auflöst. Sie können ihn für alles oder nur für eine Subdomain verwenden.

• Alles: Setzen Sie den Resolver im OT-DHCP-Scope:

  config system dhcp server
      edit 1
          set interface "ot"
          set dns-service specify
          set dns-server1 100.65.0.6
          config ip-range
              edit 1
                  set start-ip 192.168.1.100
                  set end-ip 192.168.1.200
              next
          end
      next
  end
  

• Nur Subdomain: Leiten Sie nur secure.acme.corp mit einer FortiGate-DNS-Datenbankzone im forward-Modus an das Gate weiter, oder fügen Sie einen Conditional Forwarder auf Ihrem Site-DNS-Server hinzu. Siehe Configuring Access Gate DNS.

4. Datenverkehr durch das Gate steuern

Zwei Wege, Datenverkehr zum Gate zu bringen. Quellbasiertes Routing sichert, was von einem Netzwerk kommt: Sie filtern danach, wo das Paket gestartet ist. Zielbasiertes Routing sichert, was zu einem Asset geht: Sie filtern nach dem Ziel. Nutzen Sie das eine, das andere oder beides, je nachdem, was Sie schützen wollen. In beiden Fällen übersetzt das Access Gate zwischen der realen Adresse des Assets und seinem Twin.

config router policy
    edit 1
        set input-device "ot"
        set src "192.168.1.0/255.255.255.0"
        set gateway 100.65.0.6
        set output-device "ag-protect"
    next
end

config router static
    edit 10
        set dst 100.64.1.10/255.255.255.255
        set gateway 100.65.0.6
        set device "ag-protect"
    next
end

5. Den vollständigen Pfad überprüfen

Erreichen Sie von einem OT-Gerät aus ein Ziel genau wie zuvor. Die FortiGate leitet den Datenfluss nun beim Ausgang durch das Gate.

ping 192.168.2.20   # from the OT device (192.168.1.10)

Auf dem Access Gate erscheint der Datenfluss unter seinem Enclave mit der Overlay-Identität des Geräts (100.64.1.10); Identität, Richtlinie und Verschlüsselung werden angewendet, bevor das Paket weitergeleitet wird, und die Antwort wird per NAT an das echte Gerät zurückgeleitet.

Sie können auch die Richtung IT zu OT testen: Erreichen Sie von einem IT-Client aus ein OT-Asset über seine Twin-Adresse oder seinen DNS-Namen (ping 100.64.1.10). Die Overlay-Route trägt das Paket zum Gate, das es per Proxy an das echte Gerät weiterleitet.

Was wo liegt

Die FortiGate enthält genau eine Sache: eine Regel, die sinngemäß besagt: „Diese Pakete werden an diesen Next-Hop übergeben." Ob sie auf der Quelle oder auf dem Ziel aufsetzt, sie ist statisch.

Alles andere liegt auf dem Access Gate: Authentifizierung, die Enclave-ACLs, Proxying, Credential-Injection, Sitzungsaufzeichnung, TLS-Terminierung und Logging. Nichts davon lässt sich auf der FortiGate ausdrücken, und nichts davon gehört dorthin.

Diese Trennung sollte dem Netzwerkteam gegenüber klar ausgesprochen werden, denn „wir müssen Ihre Firewall konfigurieren" klingt beunruhigend, bis man sieht, dass es sich um eine Übergaberegel handelt, nicht um eine Policy-Engine. Ihr Change-Control-Prozess sieht eine Policy Route, einmalig.

Zusammenfassung

Sie haben zwei FortiGate-Interfaces in zwei Subnetzen konfiguriert (Admin-VLAN + Protection /29), das Gate unter 100.65.0.6 platziert, das Overlay dorthin geroutet, DNS auf seinen Resolver gezeigt und den Datenverkehr nach Quelle, nach Ziel oder nach beidem gesteuert. OT-Datenverkehr fließt nun durch das Access Gate, ohne dass sich an einem Asset etwas ändert.

Verwandte Themen

• Deploy Secure Twin with Source-Based Routing
• Configuring Access Gate DNS
• Deploy Secure Twin via Gateway NAT (L3)
• Choosing a Secure Twin deployment