Cómo diseñar y dimensionar Panorama entornos de recopilador de registros

La Panorama solución consta de dos funciones generales:
 

1. Configuración y administración de dispositivos: Esto incluye actividades como la administración e implementación de la configuración, la implementación de Firewalls de Palo Alto Networks, la actualización de software y las actualizaciones de contenido.

2. Colección de registros: Esto incluye la recopilación de registros de uno o varios firewalls, ya sea a una sola Panorama o a una infraestructura de recopilación de registros distribuidos. Además de recopilar registros de firewalls implementados, se pueden generar informes basados en esos datos de registro, ya sea que residan localmente en la Panorama (por ejemplo, M- una sola serie o VM dispositivo) para una infraestructura de registro distribuida.

La Panorama solución permite flexibilidad en el diseño mediante la asignación de estas funciones a diferentes piezas físicas de la infraestructura de gestión. Por ejemplo: la administración de dispositivos se puede realizar desde un VM Panorama archivo , mientras que los firewalls reenvían sus registros a recopiladores de registros dedicados:

 

En el ejemplo anterior, la función de administración de dispositivos y los informes se realizan en un VM Panorama dispositivo. Hay tres grupos de colector de registro. Grupo A , contiene dos recopiladores de registros y recibe registros de tres firewalls independientes. Grupo B , consta de un único recopilador y recibe registros de un par de firewalls en una configuración de alta disponibilidad activa/pasiva ( HA ). El C grupo también contiene dos recopiladores de registros y recibe registros de dos pares de HA firewalls. El número de colectores de registro en cualquier lugar determinado depende de varios factores. Las consideraciones de diseño están cubiertas por debajo. Nota: cualquier plataforma puede ser solo de administración y también actuar como registrador incluyendo VM y M- series.

• Cualquier característica física o virtual Panorama que admita la colección de registros.
• PAN-OS 8.1 y superior

Dispositivos

administrados

de recopilación de registros Mientras que todas las plataformas actuales Panorama tienen un límite superior de 5000 dispositivos para fines de administración (5000 firewalls que utilizan uno solo o desde M-600 PAN-OS 9.0), es importante que Panorama el tamaño entienda cuál será la velocidad de registro entrante de todos los dispositivos administrados. Para empezar, haga un inventario del total de firewall electrodomésticos que serán gestionados por Panorama .
 
Utilice la tabla siguiente como ejemplo para realizar un inventario de los dispositivos que necesitan reenviar registros:

Consulte el siguiente artículo sobre cómo determinar la velocidad de registro: Cómo determinar la velocidad de registro en dispositivos con un Panorama recopilador de registros



Requisitos deregistro

Esta sección cubrirá la información necesaria para dimensionar e implementar correctamente la infraestructura de registro para admitir los requisitos Panorama del cliente. Hay tres factores principales para determinar la cantidad de almacenamiento total requerido y cómo asignar ese almacenamiento de información mediante colectores de registro distribuido. Estos factores son:

1. Requisitos de ingesta de registros: Este es el número total de registros que se enviarán por segundo a la Panorama infraestructura.

2. Requisitos de almacenamiento de registros: Este es el período de tiempo para el cual el cliente necesita retener los registros en la plataforma de administración. Hay diferentes factores de conducción para esto, incluyendo motivadores de cumplimiento tanto basados como policy reglamentarios.

3. Ubicación del dispositivo: La ubicación física de los firewalls puede impulsar la decisión de colocar DLC dispositivos en ubicaciones remotas en función del WAN ancho de banda, etc.

Cada uno de estos factores se discute en las secciones siguientes:

Requisitos de ingesta de registros
La velocidad
agregada de reenvío de registros para dispositivos administrados debe entenderse para evitar un diseño donde se envían regularmente más registros Panorama de los que pueden recibir, procesar y escribir al disco.  La tabla siguiente describe el número máximo de registros por segundo que cada hardware plataforma puede reenviar Panorama y se puede utilizar al diseñar una solución para calcular el número máximo de registros que se pueden reenviar Panorama en el entorno del cliente.

Límites de reenvío de registros de dispositivos

La velocidad de ingesta de inicio de sesión Panorama está influenciada por la plataforma y el modo en uso (modo mixto vs modo registrador). La siguiente tabla muestra las tasas de ingesta Panorama para las diferentes plataformas y modos de funcionamiento disponibles. Los números entre paréntesis junto a VM paranotar el número de CPU y Gigabytes RAM de asignados al VM archivo .


Panorama Tasas de ingesta de registros admitidas

Los números de arriba son todos los valores de máxima. En implementaciones de vivo, la tasa de registro real es generalmente una fracción del máximo apoyo. Determinación de tasa de registro actual es fuertemente dependiente de la mezcla de tráfico del cliente y no está necesariamente ligada a rendimiento. Por ejemplo, una sola sesión descargada SMB mostrará un alto rendimiento, pero solo generará un registro de tráfico. Por el contrario, puede tener un rendimiento más pequeño que consta de miles de consultas que generan cada una un registro de UDP DNS tráfico independiente. Para el tamaño, se puede dibujar una correlación aproximada entre las conexiones por segundo y los registros por segundo.

*En Panorama las máquinas virtuales, se pueden lograr capacidades adicionales con más asignaciones de recursos. Consulte Requisitos previos de configuración para el dispositivo Panorama virtual para obtener más información.

Métodos para determinar la tasa de registro

de nuevosclientes:

• Aprovechar la información de las fuentes existentes del cliente. Muchos clientes tienen una solución de registro de terceros como Splunk, ArcSight, Qradar, etc. El número de registros enviados desde su solución existente firewall se puede extraer de esos sistemas. Cuando utilice este método, obtenga un recuento de registros de la solución de terceros para un día completo y divídalo entre 86.400 (número de segundos en un día). Hacer esto durante varios días para obtener un promedio. Asegúrese de incluir tanto los días laborables como los no laborables, ya que normalmente hay una gran varianza en la tasa de registro entre los dos..

• Utilice los datos de los dispositivos de evaluación. Esta información puede proporcionar un muy útil punto de partida para el dimensionamiento de fines y, con la entrada del cliente, se pueden extrapolar datos de otros sitios en el mismo diseño. Este método tiene la ventaja de producir un promedio durante varios días. A Script (con instrucciones) para ayudar a calcular esta información se puede encontrar se adjunta a este documento. Para utilizarlo, descargue el archivo denominado "ts_lps.zip" de Documentos de recopilador de registros de diseño.rar. Desempaquete el archivo zip y haga referencia al README .txt para obtener instrucciones.

• Si no hay información disponible, utilice la tabla Device Log Forwarding anterior como punto de referencia. Este será el método menos exacto para cualquier cliente en particular.

Clientes existentes:

Para los clientes existentes, podemos aprovechar los datos recopilados de sus firewalls y recopiladores de registros existentes:

• Para comprobar la velocidad de registro de un único archivo de firewall descarga denominado "Device.zip" de Design Log-Collector Documents.rar, desempaquete el archivo zip y haga referencia al README archivo .txt para obtener instrucciones. Este paquete consultará un único firewall período de tiempo especificado (puede elegir cuántos ejemplos) y conceder un número medio de registros por segundo para ese período. Al mínimo, esta secuencia de comandos debe ejecutarse durante 24 horas consecutivas en un día hábil. La ejecución de la secuencia de comandos durante una semana completa ayudará a capturar el flujo cíclico de la red. Si el cliente no tiene un recopilador de registros, este proceso deberá ejecutarse en cada uno firewall de los entornos.

• Si el cliente tiene un recopilador de registros (o recopiladores de registros), descargue el archivo denominado "lc_lps.zip" de Documentos del recopiladorde registros de diseño.rar , desempaquete el archivo zip y haga referencia al README archivo de .txt para obtener instrucciones Este paquete consultará al recopilador de registros MIB para tomar una muestra de la tasa de registro entrante durante un período especificado.

Factores de requisitos de almacenamiento
de registros que afectan a los

requisitos de almacenamiento de registros:

hay varios factores que impulsan los requisitos de almacenamiento de registros.  La mayoría de estos requisitos son reglamentario en la naturaleza. Es posible que los clientes necesiten cumplir con los requisitos de cumplimiento para HIPAA PCI Sarbanes-Oxley.

• PCI DSS requisito 10.7
• Ley Sarbanes-Oxley, sección 802
• HIPAA - § 164.316(b)(2)(i)

Hay otras normas gubernamentales y la industria que pueden necesitar ser considerado. Además, algunas compañías tienen requerimientos internos. Por ejemplo: mantener un cierto número de días el valor de los registros en la plataforma de administración original. Asegúrese de que todos estos requisitos se tratan con el cliente al diseñar una solución de almacenamiento de registro.
 
El foco está en el número mínimo de días de registros que debe almacenarse. Si se requiere un número máximo de días (debido a la regulación policy o), puede establecer el número máximo de días para mantener los registros en la configuración de la cuota.
 

Cálculo del almacenamiento requerido:

Calcular el espacio de almacenamiento necesario en función de los requisitos de un cliente determinado es un proceso bastante sencillo, pero puede ser intensivo en mano de obra al lograr mayores grados de precisión. Con PAN-OS 9.1, el tamaño promedio en todos los tipos de registro es de 489 Bytes*. Este número tiene en cuenta el tamaño total del registro almacenado en el disco. 
 
* El tamaño medio del registro puede variar dependiendo de la mezcla de tráfico/registro y las características habilitadas.

Tenga en cuenta que es posible que no seamos la solución de registro para el archivado a largo plazo. En estos casos sugieren el reenvío de Syslog para fines de archivo. 

La ecuación para determinar los requisitos de almacenamiento para un tipo de registro determinado:

Ejemplo: El cliente desea poder guardar 30 días de los registros de tráfico con una tasa de registro de 1500 registros por segundo:

El resultado del cálculo anterior solo tiene cuentas para registros detallados de ElasticSearch. Con la configuración de cuota predeterminada, Reserve el 60% del almacenamiento disponible para registros detallados. Esto significa que el número calculado representa el 60% del almacenamiento utilizado por ElasticSearch. Para calcular el almacenamiento total necesario para ElasticSearch, divida este número entre .60:

Un tercio (33%) del espacio en disco disponible se asigna a los registros con formato de registro. Los registros con formato de registro se almacenan para admitir la actualización, la degradación y para admitir la corrección de daños en la base de datos. Para calcular el almacenamiento total que se necesitará comprar, divida el almacenamiento necesario para ElasticSearch por .66:

Cuotas de registro predeterminadas para Panorama 8.0 y versiones posteriores:

Tipo de registro % Registros detallados de almacenamiento
Firewall
60 Registros de resumen Firewall 30
Infraestructura y Registros de auditoría 5 Palo Alto
Networks Platform Logs .1
3rd Party External Logs .1

Consulte el siguiente artículo obtenga más información sobre la asignación de espacio Panorama en:

Cómo se asigna el espacio en disco en los recopiladores de registros

Además, la hoja de trabajo adjunta tendrá en cuenta la cuota predeterminada y proporcionará una cantidad total de almacenamiento Panorama requerido.



Disponibilidad del registro

Hay dos métodos para lograr la redundancia para los registros cuando se utiliza una infraestructura de recopilador de registros (ya sea dedicada o en modo mixto).
 

Redundancia de registros:

PAN-OS 8.1 y versiones posteriores incluyen una opción explícita para escribir cada registro en 2 recopiladores de registros en el grupo de recopiladores de registros. Al habilitar esta opción, un dispositivo envía su registro al recopilador de registros principal, que luego replica el registro en otro recopilador del mismo grupo:




Duplicación de registros garantiza que haya dos copias de cualquier registro determinado en el grupo de recopiladores de registros. Esta es una buena opción para clientes que necesitan para garantizar la disponibilidad de registro en todo momento. Cosas a considerar:

1. La replicación sólo tiene lugar dentro de un grupo de colectores de registro.

2. El espacio de almacenamiento disponible total se reduce a la mitad (ya que cada registro está escrito dos veces).

3. Total tasa de ingestión de registro se reducirán en hasta un 50%.

4. La latencia debe ser <10ms between the multiple LCs within the same collector group  to avoid an Inter- LC un problema.

 
  
Lista de preferencias del grupo de colectores:

El método consiste en colocar varios recopiladores de registros en un grupo. En este escenario, firewall se puede configurar con una lista de preferencias, por lo que si el recopilador de registros principal baja, el segundo recopilador de la lista recibirá y almacenará los registros.

La práctica recomendada para el reenvío de registros a recopiladores de registros es tener una lista de preferencias de recopilador de registros. 

Para obtener más información, consulte Advertencias para un grupo de recopiladores con varios recopiladores de registros.

En la arquitectura que se muestra a continuación, Firewall A & se Firewall B configuran para enviar sus registros al recopilador de registros 1 principalmente, con el recopilador de registros 2 como copia de seguridad. Si Log Collector 1 se vuelve inalcanzable, los dispositivos enviarán sus registros al recopilador de registros 2.






Consideraciones para el diseño del grupo del recopilador de registros
 
Hay tres razones principales para configurar los recopiladores de registros en un grupo:
 

1. Se requiere una mayor retención de registros para un firewall conjunto (o conjunto de firewalls) específico que el que puede proporcionar un único recopilador de registros (para escalar la retención).

2. Se requiere una mayor capacidad de ingesta para un recopilador de registros específico firewall que el que puede proporcionar (para escalar la ingesta).

3. Requerimiento de redundancia de logs.

 

Al considerar el uso de grupos de recopiladores de registros hay un par de consideraciones que deben abordarse en la etapa de diseño:
 

1. Distribuir la ingesta entre los recopiladores disponibles: se pueden crear varias listas de preferencias de reenvío de dispositivos. Esto permite que la ingestión sea manejada por varios colectores en el grupo coleccionista. Por ejemplo, la lista de preferencias 1 tendrá la mitad de los cortafuegos y el selector de lista 1 como el primario y el selector 2 como secundario. La lista de preferencias 2 tendrá el resto de los cortafuegos y el selector de lista 2 como el primario y el selector 1 como secundario.

2. Materia de latencia: la latencia de la red entre los colectores en un grupo colector de troncos es un factor importante en el rendimiento. A la directriz general de diseño es mantener todos los recopiladores que son miembros del mismo grupo juntos. En la tabla siguiente se proporciona una idea de lo que puede esperar en diferentes mediciones de latencia con redundancia habilitada y deshabilitada. En este caso, 'Log Delay' es el resultado no deseado de la alta latencia - los registros no aparecen en el UI pozo de hasta después de que se envían a Panorama .

NOTE: La latencia debe ser <10ms between the multiple LCs within the same collector group  to avoid an Inter- LC un problema. 


 
Uso de la hoja de cálculo de tamaño:

La información que necesitará incluye el período de retención deseado y la velocidad de registro promedio.



Período de retención: Número de días que los registros deben mantenerse.

Velocidad media de registro: La velocidad de registro agregada medida o estimada.

Redundancia requerida: Marque esta casilla si se requiere la redundancia del registro.

Almacenamiento para registros detallados: La cantidad de almacenamiento (en Gigabytes) necesaria para cumplir con el período de retención para registros detallados.

Almacenamiento total requerido: El almacenamiento (en Gigabytes) que se va a comprar. Esto explica todos los tipos de registros en la configuración de cuota predeterminada.



EXAMPLE USE CASES









 

• Si tiene alguna pregunta adicional o necesita ayuda con el diseño y la implementación de su entorno de registro, póngase en contacto con el equipo de la cuenta.

• Las documentaciones mencionadas se comprimen y se adjuntan a este artículo como Design Log-Collector Documents , disponible para su descarga.

• Consulte el siguiente documento sobre cómo verificar la configuración de la lista de preferencias en NGFW los firewalls. Verificar el reenvío de registros a Panorama

• Consulte el siguiente documento sobre cómo configurar el reenvío de registros