Palo Alto Panorama – Deployment planen

Nach dem Verständnis der grundlegenden Panorama-Konzepte folgt vor der eigentlichen Installation die Planung des Deployments. Ziel ist es, Architektur, Kapazitäten und organisatorische Strukturen festzulegen, bevor Panorama produktiv bereitgestellt und Firewalls angebunden werden.

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

Die Deployment-Planung beantwortet insbesondere folgende Fragen:

Planungsbereich	Zentrale Fragestellung
Management	Welche Systeme und Funktionen sollen zentral verwaltet werden?
Plattform	Virtual Appliance oder M-Series?
Architektur	Management und Logging kombiniert oder getrennt?
Verfügbarkeit	Wird Panorama redundant als HA-Paar betrieben?
Netzwerk	Wie werden Management-, Logging- und Administrationsverkehr angebunden?
Logging	Welche Log-Menge und Aufbewahrungsdauer werden benötigt?
Organisation	Wie werden Device Groups und Templates strukturiert?
Administration	Welche Rollen und Authentifizierungsverfahren werden benötigt?
Security	Wie werden Panorama und Managed Devices gegenseitig authentifiziert?
Migration	Werden bestehende Firewalls in das zentrale Management übernommen?

Die eigentliche Installation und Konfiguration ist nicht Bestandteil dieser Planungsphase. Das Ergebnis sollte vielmehr ein dokumentiertes Zielbild sein, auf dessen Grundlage die spätere Inbetriebnahme kontrolliert durchgeführt werden kann.

Informationen vor der Planung erfassen

Vor der Auswahl einer konkreten Architektur sollte zunächst der Ist- und Zielzustand erfasst werden.

Managed Devices

Zu erfassen sind insbesondere:

• Anzahl der Palo Alto Networks Firewalls
• Firewall-Modelle
• aktuelle PAN-OS-Versionen
• geplante PAN-OS-Version
• Anzahl und Nutzung von Virtual Systems (vsys)
• Standorte und geografische Verteilung
• bereits produktive oder neu zu installierende Firewalls
• bestehende lokale Konfigurationen
• erwartetes zukünftiges Wachstum

Bei bestehenden Firewalls muss zusätzlich geklärt werden, ob deren lokale Konfiguration in das zentrale Panorama-Management überführt werden soll.

Panorama kann Firewalls mit derselben oder einer älteren PAN-OS-Version verwalten. Die konkrete Versionskompatibilität sollte vor der Inbetriebnahme anhand der aktuellen Compatibility Matrix geprüft werden.

Bei bestehenden Multi-vsys-Firewalls sollte außerdem frühzeitig entschieden werden, wie die vorhandenen vsys-Konfigurationen in das zentrale Management überführt werden.

Alle vsys sollten von Panorama aus verwaltet werden, sonst kommt es zu Commit-Problemen auf der Firewall und die optimierten Shared-Object-Pushes stehen nicht zur Verfügung. Und namensgleiche lokale Shared-Objekte müssen vorher gelöscht oder umbenannt werden, sonst scheitern Pushes nach dem Upgrade mit der Meldung, dass der Objektname bereits in Verwendung ist.

Plattform und Architektur planen

Virtual Appliance oder M-Series

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

Die Entscheidung sollte nicht ausschließlich anhand der Anzahl verwalteter Firewalls erfolgen.

Kriterium	Zu bewerten
Anzahl Firewalls	Aktueller Bestand und erwartetes Wachstum
Logging Rate	Logs pro Sekunde (LPS)
Retention	Benötigte Aufbewahrungsdauer
Storage	Erforderliche Log-Speicherkapazität
Virtualisierung	Vorhandene und unterstützte Plattform
Cloud	On-Premises oder Public Cloud
HA	Anforderungen an Management-Verfügbarkeit
Skalierung	Zukünftiges Wachstum
Betriebsmodell	Kombiniertes oder getrenntes Management/Logging

Die endgültige Plattformdimensionierung sollte anhand der aktuellen Panorama Models sowie des Panorama Sizing and Design Guide erfolgen.

Management und Logging

Eine der wichtigsten Architekturentscheidungen betrifft die Trennung von Management und Logging.

Grundsätzlich stehen drei Betriebsmodi zur Verfügung:

Modus	Management	Logging	Einsatz
Panorama Mode	✓	✓	Kombiniertes Management und Logging
Management Only Mode	✓	nur System	Dediziertes Management
Log Collector Mode	–	✓	Dedicated Log Collector

Für kleinere oder weniger komplexe Umgebungen kann Management und Logging auf demselben Panorama-System erfolgen.

Mit steigenden Anforderungen können beide Funktionen getrennt skaliert werden:

• Panorama Management Server für zentrale Administration
• Dedicated Log Collectors für Log-Verarbeitung und Storage
• Collector Groups zur logischen Zusammenfassung mehrerer Log Collectors

Die Architekturentscheidung hängt insbesondere von folgenden Faktoren ab:

• Anzahl der Firewalls
• Logging Rate
• Retention
• erforderliche Storage-Kapazität
• Redundanzanforderungen
• geografische Verteilung
• Netzwerkbandbreite
• zukünftiges Wachstum

Hochverfügbarkeit

Für produktive Panorama-Deployments empfiehlt Palo Alto Networks den Aufbau eines Active/Passive-HA-Paars.

Bereits während der Planung sollten deshalb folgende Punkte geklärt werden:

• HA erforderlich?
• Plattformen der beiden Peers
• Standort der Systeme
• Management-IP-Adressen
• HA-Kommunikation
• Netzwerkpfade
• Latenz zwischen den Peers
• DNS- und NTP-Anbindung
• Routing
• Firewall-Regeln
• Zertifikate
• Verhalten der Logging-Infrastruktur bei Ausfällen

Die konkrete Einrichtung und Synchronisierung des HA-Paars gehört anschließend zur Inbetriebnahme.

Netzwerk und Segmentierung

Panorama benötigt Kommunikationsbeziehungen zu verschiedenen internen und gegebenenfalls externen Systemen.

Typische Kommunikationspartner sind:

• Administratoren
• verwaltete Firewalls
• Log Collectors
• HA-Peer
• DNS
• NTP
• PKI
• Authentication Server
• Syslog / SIEM
• Palo Alto Networks Update-/Lizenzdienste
• gegebenenfalls Strata Logging Service

Bei M-Series Appliances kann neben dem Management Interface mit zusätzlichen Interfaces gearbeitet werden.

Dadurch können beispielsweise:

• administrative Zugriffe,
• Device Management,
• Log Collection,
• Collector-Kommunikation und
• Software-/Content-Deployment

stärker voneinander getrennt werden.

Design-Grundsatz: Management- und Logging-Kommunikation sollten bereits bei der Netzwerkplanung berücksichtigt und nicht erst während der Installation durch bestehende Netzwerkstrukturen „hindurchgebaut“ werden.

Authentifizierung zwischen Systemen

Panorama verwendet TLS-gesicherte Verbindungen für die Kommunikation mit Managed Devices und dem HA-Peer.

Neben den vordefinierten Zertifikaten können eigene Zertifikate eingesetzt werden.

Für produktive Umgebungen sollte daher frühzeitig entschieden werden:

• Verwendung der Standardzertifikate oder eigener Zertifikate?
• Enterprise PKI vorhanden?
• interne CA oder andere Vertrauenskette?
• Zertifikatslaufzeiten
• Erneuerungsprozess
• Verantwortlichkeiten
• benötigte DNS-Namen/FQDNs

Mit eigenen Zertifikaten kann eine unternehmensspezifische Chain of Trust für die gegenseitige Authentifizierung von Panorama, Firewalls und Log Collectors aufgebaut werden.

Logging und Storage planen

Die Logging-Anforderungen haben erheblichen Einfluss auf die Dimensionierung einer Panorama-Umgebung.

Vor der Plattformauswahl sollten mindestens drei Werte bekannt oder abgeschätzt werden:

Logging Rate + Retention + Redundanz-Entscheidung = Storage-Bedarf.

Anforderungen erfassen

Für die Planung sind insbesondere relevant:

Merkmal	Fragestellung
LPS	Wie viele Logs pro Sekunde werden erzeugt?
Retention	Wie lange müssen Logs verfügbar bleiben?
Log-Typen	Welche Logs werden erzeugt und gespeichert?
Redundancy	Müssen Logs redundant gespeichert werden?
Quotas	Wie soll Storage zwischen Log-Typen aufgeteilt werden?
SIEM	Werden Logs zusätzlich extern gespeichert?
Growth	Wie stark wird das Log-Aufkommen wachsen?

Die Retention kann beispielsweise durch folgende Anforderungen bestimmt werden:

• interne IT-/Security-Richtlinien
• Incident Response
• Forensik
• Audit
• Compliance
• regulatorische Anforderungen

Logging Rate bestimmen

Die Logging Rate wird in Logs per Second (LPS) angegeben.

Bestehen bereits produktive Firewalls, sollte die reale Logging Rate möglichst gemessen und nicht lediglich geschätzt werden.

Methode / Situation	Befehl / OID	Messwert / Verwendung
Firewall – Panorama sammelt noch keine Logs	debug log-receiver statistics	Zeigt die in der letzten Sekunde empfangenen Logs. Werte aller Firewalls summieren, um die gesamte Logging Rate abzuschätzen.
Panorama / Log Collector – Logging bereits aktiv	debug log-collector log-collection-stats show incoming-logs	Zeigt die durchschnittlich eingehenden Logs der letzten fünf Minuten.
SNMP – Log Collector	panLogCollector – OID 1.3.6.1.4.1.25461.1.1.6	Monitoring der Logging-Statistiken auf Panorama beziehungsweise Log Collectors.
SNMP – Firewall	panDeviceLogging – OID 1.3.6.1.4.1.25461.2.1.2.7	Monitoring der Logging-Statistiken direkt auf den Firewalls.

Palo Alto Networks empfiehlt mehrere Messungen:

• Peak-Zeiten
• normale Betriebszeiten
• schwache Lastzeiten
• mehrere Messpunkte pro Tag

Anschließend wird aus den Messwerten ein realistischer Durchschnitt gebildet.

Für eine belastbare Planung sollte zusätzlich eine Wachstumsreserve vorgesehen werden.

Beispiel:

Messung	Logging Rate
Vormittag	1.250 LPS
Mittag	1.700 LPS
Nachmittag	1.550 LPS
Nacht	500 LPS

Der Durchschnitt dient als Ausgangspunkt für das Storage-Sizing. Peaks müssen zusätzlich mit den unterstützten Ingestion-Grenzen der geplanten Plattform abgeglichen werden.

Storage berechnen

Palo Alto Networks stellt für eine erste Abschätzung folgende Berechnungslogik bereit:

LPS × 86.400 × Retention × durchschnittliche Log-Größe

Das Ergebnis wird anschließend von Byte in GB umgerechnet.

Als Näherungswert nennt Palo Alto Networks eine durchschnittliche Log-Größe von 489 Byte.

Die Formel lautet:

[(LPS × 86.400) × Retention in Tagen] × 489 ÷ (1.024³)

Beispiel:

Parameter	Wert
Logging Rate	1.500 LPS
Retention	30 Tage
Durchschnittliche Log-Größe	489 Byte

Daraus ergeben sich ungefähr:

1.770 GB Detail-Logs

Dieser Wert entspricht jedoch noch nicht dem gesamten benötigten Storage.

Bei den Standard-Quotas stehen laut Palo Alto Networks ungefähr 60 % des verfügbaren Speichers für Detail-Logs zur Verfügung.

Daraus folgt:

1.770 GB ÷ 0,60 ≈ 2.951 GB

Zusätzlich ist ungefähr ein Drittel des verfügbaren Disk Space für logd-formatierte Logs reserviert, unter anderem zur Unterstützung von Up-/Downgrades und Datenbankreparaturen.

Daraus ergibt sich näherungsweise:

2.951 GB ÷ 0,66 ≈ 4.471 GB

Für das Beispiel werden somit rund 4,5 TB Gesamtspeicher benötigt.

Wichtig: Die Berechnung ist eine Näherung. Die tatsächliche Log-Größe unterscheidet sich je nach Log-Typ und Umgebung.

Einfluss von Log Redundancy

Wird innerhalb einer Collector Group Log Redundancy aktiviert, existieren zwei Kopien jedes Logs.

Für das Storage-Sizing bedeutet dies grundsätzlich:

• Doppelter Storage-Bedarf für die redundanten Logs
• Halbierte Logging Rate.

Redundanz sollte deshalb bereits vor der Dimensionierung entschieden werden.

Retention und Quotas

Nicht jeder Log-Typ muss zwingend gleich lange gespeichert werden.

Panorama unterstützt:

• Storage Quotas nach Log-Typ
• Expiration Periods
• automatische Löschung älterer Logs bei erschöpftem Storage

Erreicht der Log Storage seine maximale Kapazität, löscht Panorama ältere Logs, um Speicherplatz für neue Logs bereitzustellen.

Damit ist insbesondere bei Compliance-Anforderungen wichtig:

Storage-Kapazität ersetzt keine definierte Retention-Strategie.

Externes Logging

Zusätzlich sollte entschieden werden, ob Logs ausschließlich innerhalb der Panorama-Infrastruktur verbleiben.

Mögliche weitere Ziele:

• Syslog
• SIEM
• Strata Logging Service
• andere externe Logging-/Archivierungssysteme

Fragestellungen:

• Ist langfristige Archivierung erforderlich?
• Existiert bereits ein SIEM?
• Welche Logs müssen extern gespeichert werden?
• Welche Retention übernimmt Panorama?
• Welche Retention übernimmt das SIEM?
• Muss Panorama auch bei Ausfall des externen Systems Logs vorhalten?

Management-Struktur vorbereiten

Neben der technischen Plattform sollte vor der Installation bereits ein grundlegendes Modell für die spätere Konfigurationsverwaltung existieren.

Device Groups planen

Device Groups organisieren primär:

• Policies
• Objects
• Policy-Vererbung
• administrative Zuständigkeiten

Mögliche Kriterien für die Gruppierung:

• Funktion
• Security Policy
• Region
• Standort
• Netzwerksegmentierung
• Organisationseinheit

Die zentrale Fragestellung lautet:

Welche Firewalls benötigen gemeinsame Policies und Objects?

Dabei sollte zwischen sehr vielen kleinen Device Groups und wenigen großen Device Groups abgewogen werden.

Eine Device Group Hierarchy ermöglicht zusätzlich eine mehrstufige Vererbung gemeinsamer Policies und Objects.

Policy Layering

Neben der Device-Group-Struktur muss geplant werden, auf welcher Ebene Policies verwaltet werden.

Zu unterscheiden sind beispielsweise:

• unternehmensweit gemeinsame Regeln
• Regeln einer Device Group
• Regeln untergeordneter Device Groups
• Firewall-spezifische Anforderungen

Das Ziel sollte sein, gemeinsame Security-Vorgaben möglichst zentral zu verwalten und Ausnahmen bewusst zu definieren.

Templates und Template Stacks planen

Templates organisieren die zentrale Device- und Network-Konfiguration.

Mögliche Gruppierungskriterien:

• Hardwaremodell
• Region
• Standort
• Zeitzone
• DNS-/NTP-Infrastruktur
• Interface-Design
• Routing
• gemeinsame Device Settings

Ein mögliches Layering:

Global → Region → Funktion / Standort

Vor der Inbetriebnahme muss nicht jedes einzelne Template vollständig konfiguriert sein. Die geplante Struktur sollte jedoch feststehen, bevor größere Mengen an Firewalls integriert werden.

Planungsgrundsatz: Device Groups sollten anhand gemeinsamer Policies und Objects strukturiert werden. Templates und Template Stacks dagegen anhand gemeinsamer Device- und Network-Einstellungen.

Administration und RBAC

Auch das administrative Berechtigungsmodell sollte vor der produktiven Nutzung definiert werden.

Zu klären sind:

Bereich	Entscheidung
Administratoren	Welche Personen/Teams administrieren Panorama?
Rollen	Welche Berechtigungen benötigen sie?
Access Domains	Auf welche Bereiche dürfen sie zugreifen?
Authentifizierung	Local, LDAP, RADIUS, TACACS+ oder SAML?
MFA	Wie wird Mehrfaktor-Authentifizierung umgesetzt?
Break Glass	Welche Notfallzugänge werden benötigt?
Auditing	Wie werden administrative Änderungen nachvollzogen?

Insbesondere Rollen und Access Domains sollten an das spätere Device-Group-/Template-Modell angepasst werden.

Sonderfall Prisma Access

Panorama kann abhängig vom eingesetzten Prisma-Access-Modell auch für die Verwaltung von Prisma Access verwendet werden.

In diesem Fall kommen zusätzliche Anforderungen hinzu, beispielsweise:

• benötigte Panorama Plugins
• Prisma-Access-Lizenzierung
• Tenant-/Service-Informationen
• zusätzliche Device Groups
• zusätzliche Templates
• Service Connections
• Mobile Users
• Remote Networks
• entsprechende Policy-Strukturen

Für ein klassisches Panorama-Deployment zur Verwaltung physischer oder virtueller NGFWs ist dieser Bereich nicht erforderlich.

Planungshinweis: Soll Panorama sowohl klassische NGFWs als auch Prisma Access verwalten, sollte Prisma Access von Beginn an in das Device-Group-, Template-, RBAC- und Lifecycle-Design einbezogen werden.

Von der Planung zur Inbetriebnahme

Die offizielle Deployment-Reihenfolge von Palo Alto Networks lässt sich konzeptionell in folgende Phasen überführen:

Phase	Inhalt
1. Planung	Anforderungen, Architektur und Sizing festlegen
2. Bereitstellung	VM beziehungsweise M-Series bereitstellen
3. Basis-Konfiguration	Management-Zugang und grundlegende Systemeinstellungen
4. Registrierung	Panorama registrieren und lizenzieren
5. Lifecycle	Software und Content aktualisieren
6. Hochverfügbarkeit	HA-Paar einrichten
7. Onboarding	Firewalls als Managed Devices hinzufügen
8. Management-Struktur	Device Groups, Templates und Template Stacks implementieren
9. Logging	Log Collection und externe Weiterleitung konfigurieren
10. Validierung	Management, Logging, Monitoring und Reporting überprüfen

Die Schritte ab der eigentlichen Bereitstellung gehören zur Inbetriebnahme und sollten auf Grundlage der zuvor dokumentierten Planungsentscheidungen erfolgen.

Checkliste / Planungsformblatt

Das folgende Formblatt kann vor der Inbetriebnahme ausgefüllt und anschließend als technische Grundlage für das Deployment verwendet werden.

Allgemeine Anforderungen

Merkmal	Auswahl / Wert	Bemerkung
Projekt / Umgebung	__________
Anzahl Firewalls aktuell	__________
Anzahl Firewalls geplant	__________
Wachstum 3–5 Jahre	__________
PAN-OS-Version(en)	__________
geplante Panorama-Version	__________
Multi-vsys vorhanden	☐ Ja ☐ Nein
Bestehende Firewalls	☐ Ja ☐ Nein
Konfigurationsmigration erforderlich	☐ Ja ☐ Nein
Prisma Access	☐ Ja ☐ Nein

Plattform und Architektur

Merkmal	Auswahl / Wert	Bemerkung
Plattform	☐ Virtual Appliance ☐ M-Series
Virtualisierungsplattform	__________
Betriebsmodell	☐ Panorama Mode ☐ Management Only Mode ☐ Dedicated Log Collector
Anzahl Log Collectors	__________
Collector Groups	__________
HA	☐ Ja ☐ Nein
HA-Modell	Active / Passive
Systeme an getrennten Standorten	☐ Ja ☐ Nein
Wachstumsreserve berücksichtigt	☐ Ja ☐ Nein

Netzwerk und Basisdienste

Merkmal	Auswahl / Wert	Bemerkung
Management-Netz	__________
Panorama IP	__________
HA-Peer IP	__________
Default Gateway	__________
DNS Server	__________
NTP Server	__________
FQDN Panorama	__________
FQDN HA-Peer	__________
Dedizierte Service Interfaces	☐ Ja ☐ Nein
Management segmentiert	☐ Ja ☐ Nein
Firewall-Regeln vorbereitet	☐ Ja ☐ Nein
Internet-/Update-Zugriff	☐ Direkt ☐ Proxy ☐ Sonstiges

Zertifikate und Security

Merkmal	Auswahl / Wert	Bemerkung
Device Authentication	☐ Standard ☐ Custom Certificates
Enterprise PKI	☐ Ja ☐ Nein
CA	__________
Zertifikatslaufzeit	__________
Renewal-Prozess definiert	☐ Ja ☐ Nein
Administrative MFA	☐ Ja ☐ Nein
Break-Glass-Account	☐ Ja ☐ Nein

Logging und Storage

Merkmal	Auswahl / Wert	Bemerkung
Durchschnittliche Logging Rate	__________ LPS
Peak Logging Rate	__________ LPS
Retention	__________ Tage
Log Redundancy	☐ Ja ☐ Nein
Berechneter Detail-Log-Storage	__________ GB/TB
Berechneter Gesamt-Storage	__________ GB/TB
Wachstumsreserve	__________ %
Local Log Collector	☐ Ja ☐ Nein
Dedicated Log Collectors	__________
Externes Logging	☐ Ja ☐ Nein
Syslog	☐ Ja ☐ Nein
SIEM	__________
Strata Logging Service	☐ Ja ☐ Nein
Log Quotas geplant	☐ Ja ☐ Nein
Expiration Periods definiert	☐ Ja ☐ Nein

Device Groups und Policies

Merkmal	Auswahl / Wert	Bemerkung
Device-Group-Modell definiert	☐ Ja ☐ Nein
Hierarchie erforderlich	☐ Ja ☐ Nein
Global/Shared Policies definiert	☐ Ja ☐ Nein
Regionale Policies	☐ Ja ☐ Nein
Standort-/Funktions-Policies	☐ Ja ☐ Nein
Firewall-spezifische Ausnahmen	☐ Ja ☐ Nein
Object-Konzept definiert	☐ Ja ☐ Nein

Templates und Template Stacks

Merkmal	Auswahl / Wert	Bemerkung
Template-Modell definiert	☐ Ja ☐ Nein
Global Template	☐ Ja ☐ Nein
Region Templates	☐ Ja ☐ Nein
Standort Templates	☐ Ja ☐ Nein
Template Stacks definiert	☐ Ja ☐ Nein
Template-Prioritäten definiert	☐ Ja ☐ Nein
Template Variables benötigt	☐ Ja ☐ Nein
Device-/Network-Ausnahmen dokumentiert	☐ Ja ☐ Nein

Administration

Merkmal	Auswahl / Wert	Bemerkung
Authentifizierung	☐ Local ☐ LDAP ☐ RADIUS ☐ TACACS+ ☐ SAML
Administrative Rollen definiert	☐ Ja ☐ Nein
Access Domains benötigt	☐ Ja ☐ Nein
Read-Only / Audit Role	☐ Ja ☐ Nein
Personalisierte Admin-Accounts	☐ Ja ☐ Nein
Notfallzugang dokumentiert	☐ Ja ☐ Nein
Administrative Logs extern gesichert	☐ Ja ☐ Nein

Freigabe zur Inbetriebnahme

Vor Beginn der eigentlichen Inbetriebnahme sollten mindestens folgende Punkte geklärt sein:

Merkmal	Auswahl / Wert	Bemerkung
Zielarchitektur festgelegt	☐ Ja ☐ Nein
Plattform ausgewählt und dimensioniert	☐ Ja ☐ Nein
Versionskompatibilität geprüft	☐ Ja ☐ Nein
HA-Entscheidung getroffen	☐ Ja ☐ Nein
Netzwerkkommunikation geplant	☐ Ja ☐ Nein
DNS und NTP vorbereitet	☐ Ja ☐ Nein
Zertifikatskonzept festgelegt	☐ Ja ☐ Nein
Logging Rate ermittelt oder belastbar geschätzt	☐ Ja ☐ Nein
Retention festgelegt	☐ Ja ☐ Nein
Storage dimensioniert	☐ Ja ☐ Nein
Logging-Architektur festgelegt	☐ Ja ☐ Nein
Device-Group-Struktur entworfen	☐ Ja ☐ Nein
Policy-Layering definiert	☐ Ja ☐ Nein
Template-/Template-Stack-Struktur entworfen	☐ Ja ☐ Nein
RBAC-/Authentifizierungskonzept festgelegt	☐ Ja ☐ Nein
bestehende Firewalls und Migrationsbedarf erfasst	☐ Ja ☐ Nein
Backup-/Rollback-Anforderungen definiert	☐ Ja ☐ Nein
Verantwortlichkeiten für Deployment und Freigabe festgelegt	☐ Ja ☐ Nein

Sind diese Punkte geklärt, liegt eine belastbare Grundlage für die eigentliche Panorama-Inbetriebnahmeplanung und -durchführung vor.

Quellen

• https://docs.paloaltonetworks.com/panorama/getting-started/plan-your-panorama-deployment
• https://docs.paloaltonetworks.com/panorama/getting-started/plan-your-panorama-deployment/determine-panorama-log-storage-requirements
• https://docs.paloaltonetworks.com/panorama/getting-started/plan-your-panorama-deployment/deploy-panorama-task-overview
• https://docs.paloaltonetworks.com/panorama/getting-started/plan-your-panorama-deployment/cheat-sheet-manage-prisma-access-by-using-panorama