Palo Alto Panorama – Grundlagen und zentrale Konzepte

Palo Alto Networks Panorama ist die zentrale Management-, Konfigurations- und Monitoring-Plattform für Palo Alto Networks Next-Generation Firewalls. Panorama reduziert den administrativen Aufwand insbesondere in Umgebungen mit mehreren Firewalls und ermöglicht eine konsistente Verwaltung von Konfigurationen, Security Policies, Updates und Logs.

Hinweis: Dieser Beitrag wurde mit Unterstützung von KI erstellt und redaktionell geprüft.

Für das grundlegende Verständnis sind vor allem vier Bereiche relevant:

Bereich	Aufgabe
Device Groups	Zentrale Verwaltung von Policies und Objects
Templates / Template Stacks	Zentrale Verwaltung von Device- und Network-Einstellungen
Log Collectors / Collector Groups	Zentrale und skalierbare Log-Sammlung
RBAC	Delegation administrativer Berechtigungen

Grundlegende Bereiche von Panorama

Diese Bereiche sind weitgehend unabhängig voneinander strukturiert. Eine Firewall kann beispielsweise einer bestimmten Device Group angehören und gleichzeitig über einen Template Stack eine vollkommen anders aufgebaute Konfigurationshierarchie erhalten.

Aufgaben von Panorama

Panorama stellt drei wesentliche Funktionsbereiche bereit.

Funktionsbereich	Beschreibung
Centralized Configuration and Deployment	Zentrale Konfiguration und Verwaltung von Firewalls
Centralized Logging and Reporting	Aggregation, Analyse und Auswertung von Logs
Distributed Administration	Delegation administrativer Aufgaben mittels RBAC

Grundsätzliche Aufgaben von Panorama

Darüber hinaus können über Panorama unter anderem folgende Aufgaben zentral durchgeführt werden:

Verwaltung von Security Policies und Objects
Konfiguration von Network- und Device-Einstellungen
Bereitstellung von PAN-OS Software
Verteilung dynamischer Content Updates
Lizenzverwaltung
zentrale Log-Auswertung
Reporting und Application Command Center (ACC)
User-ID/Data Redistribution
Administration mehrerer Firewalls über eine zentrale Oberfläche

Panorama ersetzt dabei nicht die eigentliche Firewall-Funktion. Die Firewalls bleiben für die Verarbeitung und Kontrolle des Netzwerkverkehrs verantwortlich.

Panorama-Modelle

Panorama kann als Virtual Appliance oder als dedizierte M-Series Appliance betrieben werden.

Virtual Appliance

Die Panorama Virtual Appliance kann unter anderem auf folgenden Plattformen betrieben werden:

VMware ESXi
Microsoft Hyper-V
KVM
AWS
Microsoft Azure
Google Cloud Platform
Oracle Cloud Infrastructure

Abhängig von Ressourcen, Betriebsmodus und Lizenzierung kann eine virtuelle Panorama-Appliance unterschiedliche Größenordnungen von Firewalls verwalten. Aktuell stehen Lizenzen im Management-Only-Modus für 25, 100 und 1.000 Firewalls zur Verfügung; entsprechend dimensionierte virtuelle Appliances unterstützen bis zu 2.500 Firewalls.

M-Series

M-Series Appliances sind dedizierte Hardwareplattformen für Panorama.

Aktuelle Modelle umfassen:

M-200
M-300
M-500
M-600
M-700

Insbesondere M-600 und M-700 sind für größere Installationen ausgelegt und können im Management-Only-Modus bis zu 5.000 Firewalls verwalten.

Betriebsmodelle

Die Rolle eines Panorama-Systems wird wesentlich durch seinen Betriebsmodus bestimmt.

Modus	Management	Lokale Log Collection	Typischer Zweck
Panorama Mode	✓	✓	Kombiniertes Management und Logging
Management Only Mode	✓	–	Dedizierter Management Server
Log Collector Mode	–	✓	Dedicated Log Collector

Betriebsmodelle für Panorama

Panorama Mode

Management von Firewalls
Management von Dedicated Log Collectors
lokale Log Collection möglich
geeignet für kombinierte Management-/Logging-Deployments

Management Only Mode

Panorama dient ausschließlich als Management Server
keine reguläre lokale Log Collection
Logging wird beispielsweise über Dedicated Log Collectors realisiert
ermöglicht eine stärkere Trennung von Management und Logging

Log Collector Mode

System fungiert ausschließlich als Dedicated Log Collector
wird durch einen Panorama Management Server verwaltet
keine normale administrative Weboberfläche
CLI primär für Initialkonfiguration und Troubleshooting

Hinweis: Der frühere Legacy Mode wird seit dem 1. September 2025 nicht mehr unterstützt.

Zentrale Konfigurationsverwaltung

Für die Konfigurationsverwaltung sind zwei Konzepte besonders wichtig:

Templates und Template Stacks → Device- und Network-Konfiguration
Device Groups → Policies und Objects

Diese Trennung gehört zu den wichtigsten Grundprinzipien von Panorama.

Templates und Template Stacks

Templates dienen primär zur zentralen Konfiguration der Einstellungen, die auf der Firewall unter Device und Network zu finden sind.

Typische Beispiele:

Interfaces
Zones
Routing
VPN-Konfiguration
Server Profiles
Logging-/Syslog-Konfiguration
Device Settings

Ein Template bildet dabei einen wiederverwendbaren Konfigurationsbaustein.

Beispielhafte logische Aufteilung:

Global-Base
Region-EMEA
Site-Darmstadt

Dadurch müssen gemeinsame Einstellungen nicht für jede Firewall separat gepflegt werden.

Template Stacks

Ein Template Stack kombiniert mehrere Templates.

Priorität	Template	Inhalt
1	Site-Darmstadt	standortspezifische Konfiguration
2	Region-EMEA	regionale Konfiguration
3	Global-Base	globale Basiswerte

Beispiel für ein Template Stack

Die Reihenfolge ist relevant:

Panorama wertet Templates innerhalb eines Stacks von oben nach unten aus.
Höher angeordnete Templates besitzen bei konkurrierenden Einstellungen eine höhere Priorität.
Gemeinsame Basiskonfigurationen können dadurch von spezifischeren Templates übersteuert werden.

Das ermöglicht ein Layering-Prinzip:

Global < Region < Funktion < Standort

Template Variables

Templates und Template Stacks unterstützen Variablen.

Variablen dienen als Platzhalter beispielsweise für:

IP-Adressen
Interfaces
Group IDs

Damit lässt sich eine gemeinsame Konfigurationsstruktur verwenden, obwohl einzelne Firewalls unterschiedliche Werte benötigen.

Device Groups

Device Groups gruppieren Firewalls, die gemeinsame Policies und Objects verwenden sollen.

Mögliche Gruppierungskriterien:

Region
Standort
Organisationseinheit
Firewall-Funktion
Netzwerksegmentierung
Sicherheitsanforderungen

Innerhalb einer Device Group werden insbesondere verwaltet:

Security Policies
NAT Policies
weitere Policy-Typen
Addresses
Address Groups
Services
Service Groups
weitere Policy Objects

Device Groups können hierarchisch aufgebaut werden.

Dadurch können übergeordnete Device Groups gemeinsame Policies und Objects bereitstellen, während untergeordnete Device Groups spezifischere Konfigurationen ergänzen.

Beispiel:

Ebene	Device Group	Zweck
0	Shared / Global	unternehmensweite Vorgaben
1	EMEA	regionale Vorgaben
2	Germany	länderspezifische Vorgaben
3	Branch	standortspezifische Policies

Device-Group-Hierarchie

Die Device-Group-Hierarchie sollte daher nicht lediglich die physische Standortstruktur abbilden. Sie beschreibt primär, welche Firewalls gemeinsame Policies und Objects erben sollen.

Device Groups vs. Templates

Die Unterscheidung lässt sich vereinfacht so zusammenfassen:

Fragestellung	Panorama-Konzept
Welche Security Policy soll gelten?	Device Group
Welche Address Objects werden verwendet?	Device Group
Wie ist ein Interface konfiguriert?	Template
Welche Zone existiert?	Template
Wie ist die Netzwerk-/Device-Konfiguration aufgebaut?	Template
Welche gemeinsamen Einstellungen sollen kombiniert werden?	Template Stack

Device Groups vs. Templates

Device Groups definieren primär, was die Firewall durch Policies durchsetzen soll. Templates definieren, wie die Firewall als System und im Netzwerk konfiguriert ist. Eine Firewall wird deshalb typischerweise sowohl einer Device Group als auch einem Template Stack zugeordnet.

Konfigurationsgröße

Bei größeren Panorama-Umgebungen muss auch die Größe der gesamten Konfiguration berücksichtigt werden.

Die Konfigurationsgröße beeinflusst insbesondere:

Konfigurationsänderungen
Commit-Dauer
Push-Dauer
allgemeine Management-Performance

Im Panorama Mode unterstützt der Panorama Management Server aktuell eine Gesamtkonfigurationsgröße von 80 MB für Templates, Device Groups und Panorama-spezifische Konfigurationen. Im Management-Only-Modus hängt das unterstützte Maximum von Plattform beziehungsweise zugewiesenen Ressourcen ab.

Seit PAN-OS 11.1 überwachen Panorama und verwaltete Firewalls die Konfigurationsgröße aktiv.

Auf Panorama lässt sich unter anderem prüfen:

aktuelle Configuration Size
Verhältnis zum unterstützten Maximum
Größenverteilung nach Konfigurationskomponenten
Auswirkungen eines Commits

Die Überwachung sollte Bestandteil des regulären System-Health-Monitorings sein.

Logging, Reporting und Data Redistribution

Panorama kann Logs verwalteter Firewalls zentral aggregieren und für Analyse und Reporting bereitstellen. Damit entsteht eine zentrale Sicht auf Traffic, Benutzeraktivitäten und Security Events. Gleichzeitig stehen Konfigurationsänderungen für Auditing-Zwecke zentral zur Verfügung.

Log Collectors

Panorama unterscheidet zwei grundlegende Collector-Typen.

Typ	Beschreibung
Local Log Collector	Logging-Funktion auf dem Panorama Management Server
Dedicated Log Collector	Eigenständiges System im Log Collector Mode

Collector-Typen

Dedicated Log Collectors sind insbesondere für größere Umgebungen interessant, weil Management und Log-Verarbeitung unabhängig voneinander skaliert werden können.

Collector Groups

Ein oder mehrere Managed Collectors werden zu einer Collector Group zusammengefasst.

Eine Collector Group kann aktuell aus 1 bis 16 Managed Collectors bestehen.

Die Collector Group:

bildet eine logische Logging-Einheit
definiert, welche Firewalls Logs an welche Collector-Infrastruktur senden
verteilt Logs über die verfügbaren Collectors und Datenträger
kann Log Redundancy bereitstellen
ermöglicht eine Skalierung der Speicherkapazität und Log-Ingestion

Bei mehreren Dedicated Log Collectors verteilt Panorama die Logs über die vorhandenen Systeme.

Besonderheiten mehrerer Log Collectors

Ein Design mit mehreren Collectors benötigt besondere Aufmerksamkeit.

Palo Alto Networks empfiehlt bei einer Collector Group mit mehreren Collectors mindestens drei Log Collectors. Zwei Collectors werden unterstützt, die Collector Group wird jedoch non-operational, wenn einer der beiden ausfällt.

Alle Log Collectors einer Collector Group müssen dasselbe Panorama-Modell sein.
Log Redundancy erfordert, dass alle Collectors dieselbe Anzahl Logging-Disks haben.

Optional kann Log Redundancy aktiviert werden.

Dabei:

existieren zwei Kopien jedes Logs,
liegen die Kopien auf unterschiedlichen Collectors,
steigt die Ausfallsicherheit,
steigt gleichzeitig der Speicherbedarf,
verdoppelt sich der Log-Processing-Traffic,
halbiert sich dadurch die maximale Logging Rate der Collector Group.

Diese Eigenschaften müssen später bei der Dimensionierung der Logging-Architektur berücksichtigt werden.

Log Forwarding

Firewalls speichern Logs standardmäßig zunächst lokal.

Für zentrale Analyse können Logs weitergeleitet werden an:

Panorama / Log Collector
Strata Logging Service
beide Ziele parallel

Für externe Archivierung oder Analyse sind außerdem unter anderem möglich:

Syslog
E-Mail
SNMP Trap
HTTP-basierte Services

Standardmäßig erfolgt die Log-Übertragung über das Management Interface. Alternativ kann eine dedizierte Service Route verwendet werden.

Centralized Reporting

Panorama kann aggregierte Daten für zentrale Reports verwenden.

Möglichkeiten umfassen:

Application Command Center (ACC)
Log Viewer
vordefinierte Reports
Custom Reports
Report Groups
zeitgesteuerte Reports
E-Mail-Versand von Reports

Panorama stellt mehr als 40 vordefinierte Reports bereit. Die Daten können aus der Panorama-/Collector-Infrastruktur oder direkt von den verwalteten Firewalls abgefragt werden.

Damit ist zentrale Sichtbarkeit auch möglich, wenn nicht sämtliche Detail-Logs dauerhaft auf Panorama gespeichert werden.

Data Redistribution und User-ID

Panorama kann zusätzlich als zentrale Infrastruktur für Data Redistribution eingesetzt werden.

Das ist insbesondere in größeren Umgebungen relevant, in denen mehrere Firewalls identische Informationen benötigen.

Redistribuiert werden können beispielsweise Informationen für:

User-ID
IP-to-User Mappings
Tags
Authentication Timestamps

Das Prinzip:

Daten werden von einer Quelle erfasst.
Panorama erhält die relevanten Informationen.
Panorama verteilt sie an definierte Firewalls beziehungsweise weitere Panorama-Systeme.
Filter können die Verteilung auf tatsächlich benötigte Daten beschränken.

Dadurch müssen nicht zwischen allen Firewalls separate Redistribution-Verbindungen aufgebaut werden.

Subnetze, IP-Ranges und Regionen können zusätzlich verwendet werden, um die verteilten Informationen einzuschränken und damit Netzwerk- und Gerätekapazitäten effizienter zu nutzen.

Data Redistributiun, Logging und Data Flow

Administration, RBAC und Commit-Modell

Role-Based Access Control

Panorama unterstützt eine granulare rollenbasierte Administration.

Das RBAC-Modell setzt sich im Wesentlichen zusammen aus:

Administrator Accounts
Administrative Roles
Authentication Profiles
Authentication Sequences
Access Domains

Jeder Administrator besitzt:

einen Account,
eine administrative Rolle,
eine Authentifizierungsmethode.

Palo Alto Networks empfiehlt individuelle Administrator-Accounts anstelle einer gemeinsamen Verwendung des vordefinierten admin-Accounts. Dadurch lassen sich administrative Aktionen eindeutig zuordnen und auditieren.

Administrative Roles

Administrative Roles bestimmen, was ein Administrator tun darf.

Panorama unterscheidet unter anderem:

Rollentyp	Beschreibung	Berechtigungen / Beispiele	Verhalten bei neuen Funktionen
Dynamic Roles	Von Panorama vordefinierte administrative Rollen	Superuser, Superuser (read-only), Panorama Administrator	Die Rollendefinition wird automatisch um Berechtigungen für neue Funktionen erweitert.
Admin Role Profiles	Benutzerdefinierte Rollen zur granularen Steuerung administrativer Berechtigungen	Read/Write, Read Only, No Access	Neue Funktionen müssen bei Bedarf manuell in den Rollen berücksichtigt und freigegeben werden.

Administrative Roles

Neue Funktionen werden bei Custom Roles nicht automatisch freigegeben. Nach Software-Upgrades sollte daher geprüft werden, ob bestehende Custom Roles angepasst werden müssen.

Access Domains

Access Domains beantworten eine andere Frage:

Wo darf ein Administrator administrieren?

Sie begrenzen den Zugriff auf:

bestimmte Device Groups
bestimmte Templates
bestimmte Firewalls
Context Switching zu verwalteten Firewalls

Access Domains gelten für Administratoren mit Device Group and Template Roles.

Damit lassen sich beispielsweise Verantwortlichkeiten nach Region oder Organisationseinheit trennen:

Administrator	Rolle	Access Domain
Global Security	Policy Read/Write	Global
EMEA Operations	Device/Network Read/Write	EMEA
Auditor	Read Only	Global
Branch Admin	eingeschränkt	Branches

Beispiel für Rollen und Access Domains

Das Grundprinzip lautet damit:

Role: Was darf der Administrator?
Access Domain: Wo darf er es?

Administrative Authentication

Panorama unterstützt lokale und externe Authentifizierungsverfahren.

Authentication Profiles definieren den Dienst, mit dem Administrator-Credentials validiert werden.

Mögliche Verfahren umfassen unter anderem:

Local
LDAP
RADIUS
TACACS+
SAML

Bei SAML, TACACS+ und RADIUS kann neben der Authentifizierung auch die Autorisierung über den externen Dienst erfolgen. Panorama kann dabei beispielsweise Attribute beziehungsweise VSAs auf lokale Rollen und Access Domains abbilden.

Authentication Sequences

Eine Authentication Sequence kombiniert mehrere Authentication Profiles in einer festgelegten Reihenfolge.

Beispiel:

TACACS+
LDAP

Panorama prüft die Profile nacheinander. Erst wenn die Authentifizierung über alle Profile fehlschlägt, wird der Zugriff abgelehnt.

Candidate und Running Configuration

Wie PAN-OS arbeitet Panorama mit unterschiedlichen Konfigurationszuständen.

Zustand	Bedeutung
Candidate Configuration	aktuell bearbeitete, noch nicht aktivierte Konfiguration
Running Configuration	durch Commit aktivierte Konfiguration

Configuration-Types

Eine Änderung in der Weboberfläche bedeutet daher noch nicht automatisch, dass diese Änderung aktiv ist.

Commit und Push

Beim Arbeiten mit Panorama muss zwischen zwei Vorgängen unterschieden werden:

Vorgang	Beschreibung	Ergebnis
Commit to Panorama	Candidate Configuration wird auf Panorama committed.	Änderungen werden Bestandteil der Running Configuration von Panorama.
Push to Devices	Panorama verteilt die relevanten Konfigurationen an die ausgewählten verwalteten Systeme.	Die Panorama-Konfiguration wird auf den entsprechenden Firewalls aktiviert.

Commit und Push

Daraus ergibt sich konzeptionell:

Konfiguration auf Panorama ändern.
Änderung prüfen.
Commit auf Panorama.
Konfiguration auf ausgewählte Geräte bzw. Konfigurationsbereiche pushen.
Ergebnis kontrollieren.

Das ist insbesondere wichtig, weil ein Commit auf Panorama nicht automatisch bedeutet, dass eine Änderung bereits auf allen Firewalls aktiv ist.

Validate und Preview

Panorama stellt zusätzliche Funktionen bereit, um Änderungen vor beziehungsweise während des Rollouts zu kontrollieren.

Funktion	Zweck
Preview	Änderungen vor der Aktivierung beziehungsweise Verteilung überprüfen
Validate	Konfiguration auf Gültigkeit prüfen
Commit	Candidate Configuration zur Running Configuration machen
Push	relevante Konfiguration an verwaltete Systeme übertragen

Validate und Preview

Änderungen können dabei unter anderem nach folgenden Kriterien gefiltert werden:

Administrator
Device Group
Template
Collector Group
Log Collector
Shared Settings
Panorama Management Server

Diese Mechanismen bilden später eine wichtige Grundlage für kontrollierte Change- und Deployment-Prozesse.

Fazit

Vor einer konkreten Panorama-Inbetriebnahme sollten die beschriebenen Konzepte nicht isoliert betrachtet werden. Sie bilden gemeinsam das spätere Panorama-Design.

Die Elemente umfassen:

Device Groups strukturieren Policies und Objects.
Templates strukturieren Device- und Network-Konfigurationen.
Template Stacks kombinieren wiederverwendbare Konfigurationsebenen.
Log Collectors und Collector Groups bilden die Logging-Infrastruktur.
RBAC und Access Domains strukturieren administrative Verantwortlichkeiten.
Commit, Validate, Preview und Push bilden den kontrollierten Konfigurationsworkflow.
Data Redistribution stellt benötigte Identitäts- und Mapping-Informationen skalierbar bereit.

Diese Konzepte sollten vor der eigentlichen Inbetriebnahme verstanden und in ein konsistentes Zielbild überführt werden. Die konkrete Planung von Plattform, Sizing, HA, Device-Group-Hierarchie, Templates, Logging, Firewall-Onboarding und Rollout kann darauf anschließend aufbauen.