Script para traducir reglas en migración StoneGate a Checkpoint

"Se adjunta una script que puede ser utilizado como punto de partida para la traducción de reglas de firewall y NAT en las migraciones Stonegate a Checkpoint utilizando los ficheros XML y dbedit respectivamente"

Adjunto un Script que he hecho para traducir los ficheros XML exportados por los Stonegate a comandos dbedit para importarlos en Checkpoint (probado con R75), ya que en alguna migración de este tipo puede ahorrar gran parte del trabajo.

Lo hice en Shell de Linux porque, en principio solo iba a traducir objetos host, pero luego fui añadiendo cosas y más cosas… Al final, ya que no está muy bien programado que digamos, hace que el script tarde algo de tiempo en migrar ficheros XML de gran tamaño.

Aconsejo correrlo bajo un Linux de verdad, incluso máquina virtual, no desde Cygwin, ya que el tiempo de ejecución en ese entorno es insufrible.

Cosas que SI que hace

• Migra objetos Host (si detecta que tiene IPs secundarias generará un grupo en el que incluirá todos los componentes host, uno por cada IP secundaria)

• Migra objetos Routers (incluso con IPs secundarias)

• Migra objetos  Networks

• Migra objetos Address-range

• Migra grupos de objetos

• Migra servicios TCP

• Migra servicios UDP

• Migra grupos de servicios

• Migra Headers de las reglas de firewall

• Migra reglas de Firewall (las migra en un policy package llamado igual que el nombre del conjunto de políticas en Stonegate, no en el Standard )

• Migra reglas de NAT (con la restricción que se incluye más abajo), incluso si en Stonegate tienen varios orígenes, destinos o servicios en una misma regla (lo detecta y genera grupos nuevos para ello)

• Crea objetos que pueden ser de ayuda en la configuración de Anti-spoofing

• Genera un fichero con los campos que encuentra y no migra

• Indica en número de objetos migrados

Cosas que hace a medias

• Añade un comentario en la configuración de dbedit si se utilizan elementos Alias en la configuración del Stonegate (para que puedan ser fácilmente localizados y cambiados a mano más tarde)

• Corrige los nombres de los objetos de Stonegate para que cumplan los (exigentes) resquisitos de nombramiento de Checkpoint. Solo corrige los problemas que he he ido encontrado… no hace que se cumplan todas las reglas, por lo que se más que probable que si se utiliza el script se tenga que retocar esta parte

• Se crean los servicios tcp, udp y rpc, así como los gurpos de estos que existen por defecto en Stonegate y no en Checkpoint. Sucede lo mismo que en el anterior punto, solo lo hace para los que he ido encontrado.

• Se  hace un match de los servicios por defecto que existen en Stonegate y que también existen por defecto en Checkpoint pero que se nombran diferente. Al igual que las anteriores, solo para los que me he encontrado en mi migración.

• Migra conjuntos de reglas subrule. En ese caso inserta las reglas subrule a partir de la regla que lo lanza y, en caso de que las reglas de subrule tengan ANY inserta el campo del “padre”, pero cuidado!, porque si el Stonegate está mal configurado (en las subrules se tienen objetos menos específicos que en la regla padre que lo lanza) se pueden estar abriendo más IPs de las pretendidas!!! (esto hay que revisarlo una a una)

Cosas que NO hace

• No tiene en cuenta el port-forwarding con cambio de puerto de las reglas NAT

• No configura las  deep-inspections de los servicios

• No genera objetos gateway Checkpoint, por lo que las referencias a los servidores de gestión o gateways de la configuración de Stonegate se tienen que migrar a mano (o poner los mismos nombres de cluster y servidor de gestión en Checkpoint y haber creado antes dichos objetos  )

• No migra los campos “expression”, ya que en Checkpoint estos no existen. Es importante que este trabajo se haga a mano antes de la importación

• No tiene en cuenta las traslaciones de puerto en los NAT

• No coloca los grupos por dependencias, es decir, si un grupo incluye otro grupo puede que durante la ejeción del dbedit salte un error de que xx componente no existe.

• No modifica parámetros generales de la configuración de checkpoint

• No genera rutas de enrutamiento ni nada de configuración de SO (ya que se limita a comandos dbedit)

• No consolida los servicios que ya existen por defecto en los Checkpoint con los que ha creado el usuario en Stonegate, por lo que tras la migración se deberá hacer este trabajo manualmente (o mejor, haciendo una prueba y cambiando el txt del dbedit antes de meterlo en el SmartCenter). De no hacerse saldrán Warnings en la instalación de las políticas (otro modo de quitarlos es desmarcar Match fo “Any” en alguno de ellos)

• Migrar configuración del Cluster (claro!! ), ni VPNs, ni…. bueno lo que no está puesto en lo que si hace

* NOTA1 : EL script dbedit que genera, en alguna ocasión contiene una linea adicional (en blanco) al final de fichero que, si no es borrada, dará un error a la hora de la importación

* NOTA2 : Solo lo he probado con dos configuraciones así que puede que si existe algún tipo raro de regla de firewall o de NAT falle la migración. Si se da ese caso…. el script no está bajo soporte…. :)

Link al script "Stonegate-XML_a_Checkpoint-dbedit.sh"

Opciones para la consolidación de las redes SAN y LAN

"La consolidación de las redes SAN y LAN no se limita al protocolo FCoE, hay más protocolos que permiten una arquitectura común no obstante, FCoE es la que habitualmente mejor puede encajar en las arquitecturas de los Data Centrer debido a las cualidades que se expondrán a continuación"

Si bien es cierto que hoy en día las implementaciones de este tipo de redes no son las más numerosas , también lo es que la utilización de este tipo de despliegues, en el que se utilizan los mismos elementos para encaminar tanto el tráfico de red (LAN) como el de almacenamiento basado en bloque (SAN), será la tendencia en los siguientes años, ya que proporciona algunas ventajas derivadas de la reducción de la infraestructura física, al consolidar los switches FC y de red en un mismo equipo, como por ejemplo:

• Reducción de las necesidades de alimentación eléctrica

• Disminución de las tareas de gestión

• Simplificación del cableado

• Reducción del número de tarjetas de red y almacenamiento necesarias en los equipos terminales

• Reducción del equipamiento de red

Existen varios protocolos que pueden unificar la transmisión de datos de red y almacenamiento, cada uno de ellos con sus peculiaridades, aunque todos deben cumplir lo siguiente:

1. Baja latencia
2. Alto ancho de banda disponible
3. Transmisión sin pérdidas

Estos son algunos de los protocolos que son o podrían ser utilizados a tal efecto:

  

Figura 1– Capas en los protocolos convergentes LAN/SAN

1. Fibre Channel (FC)

Aunque en teoría el protocolo FC se podría haber utilizado para el envío de los paquetes de red, esto nunca se llevó a cabo debido al alto coste de la infraestructura FC y a la convención global de utilizar Ethernet como método de transporte, no obstante ha quedado como el protocolo más común de transporte para la información de almacenamiento basada en bloques, debido a sus procedimientos de detección de errores y control de flujos.

2. InfiniBand (IB)

Este protocolo puede ser utilizado para transportar la comunicación inter-procesador, LAN y de almacenamiento pero su despliegue para este cometido no es práctico debido a su alto coste, no solo de los componentes puramente IB, sino también de los elementos que harían la traducción al resto de protocolos LAN y almacenamiento en los bordes de la red convergente.

Este protocolo ha sido adoptado casi únicamente por los entornos de supercomputación y grid computing, es decir, computación de alto rendimiento.

3. Internet SCSI (iSCSI)

iSCSI realiza un mapeo directo entre la información SCSI de almacenamiento y la pila de protocolos TCP/IP. 

Su implementación permite despliegues capaces de encaminar el almacenamiento por bloque con un coste mucho más reducido que con la infraestructura Fibre-Channel, es por ello que muchas empresas de mediano y pequeño tamaño han adoptado esta tecnología, consolidando los switches de almacenamiento y de red en solo un elemento físico, o bien creando una red paralela dedicada de almacenamiento pero basada en switches de red (más económicos) en lugar de switches FC. También suele ser utilizado en las SAN destinadas a desarrollo mientras que FC es utilizado en producción.

Como contra se puede señalar un número menor de funcionalidades de los dispositivos iSCSI de almacenamiento, comparándolas con Fibre-Channel, que la implementación de arquitecturas de almacenamiento puede necesitar, tanto desde el punto de vista de seguridad como de rendimiento.

Por otro lado, para poder desplegarlo como un protocolo destinado a la consolidación de las comunicaciones LAN y SAN, habría que tener en cuenta los dispositivos que permitan la conversión desde la red convergente a los protocolos de red y almacenamiento por separado, y para el caso de iSCSI se puede constatar que dichos equipos conversores iSCSI/FC (denominados gateways) tiene un elevado coste. 

4. Fibre-Channel over IP (FCIP)

FCIP realiza un mapeo directo entre el protocolo FC y la pila de protocolos de red TCP/IP. Debido a ello es un protocolo que es comúnmente utilizado para realizar extensiones de SAN geográficamente separadas a lo largo de redes TCP/IP, eliminando la necesidad de adquisición de líneas de fibra dedicadas exclusivamente al tráfico FC entre ambos puntos, lo que en algunas ocasiones físicamente es imposible o genera un coste adicional de infraestructura no asumible.

Sin  embargo FCIP no debería ser considerado un protocolo que pueda llevar a cabo la consolidación LAN/SAN pues no está diseñado para la comunicación entre los host y el almacenamiento, sino para el cometido descrito anteriormente, la extensión SAN, ya que de él derivarían una serie de problemas de complejidad, falta de escalabilidad y coste de la solución.

5. Fibre-Channel over Ethernet (FCoE)

Hasta hace poco existían dos problemas para utilizar Ethernet como sustento de las redes LAN/SAN consolidadas:

• Limitación del ancho de banda que permitía transmitir, si se comparaba con FC

• Imposibilidad de dedicación de recursos y fiabilidad a flujos concretos

Desde la aparición y popularización de los enlaces Ethernet de 10Gbps el primer problema ha desaparecido, por lo que actualmente es considerado el método principal para logar la consolidación de las redes de almacenamiento y LAN.

El segundo problema ha sido resuelto mediante los nuevos estándares IEEE Data Center Bridging (DCB) se ha logrado mejorar el protocolo Ethernet, eliminando las pérdidas de paquetes debido a la congestión de colas y añadiendo la posibilidad de reservar anchos de banda específicos a los enlaces.

DCB  define las siguientes tecnologías que proporcionan ventajas al protocolo FCoE:

• 802.1Qbb  - Priority-based Flow Control (PFC): Permite realizar control de flujo, pero diferenciando entre tipos de tráfico sobre los  que puede utilizar las “pausas”. Evita las pérdidas de paquetes y es por el por el que a las redes DCB también se las denomina redes Ethernet sin pérdidas, o “lossless Ethernet”.

• 802.1Qaz  - Enhanced Transmission Selection (ETS): Define el procedimiento para garantizar ancho de banda del enlace así como para asignar prioridades a los flujos de tráfico.

• 802.1Qau  - Quantized Congestion Notification (QCN): Gestiona el control de flujo de extremo a extremo, lo cual elimina la congestión que pueda existir. Es importante que para que este protocolo funcione correctamente, todos los elementos intermedios en la comunicación LAN deben poseer esta funcionalidad.

• 802.1Qaz -  Data Center Bridging Exchange Protocol (DCBX): Es el protocolo que conversa y descubre a los elementos colindantes que soportan los anteriores protocolos.

Ya que los protocolos DCB son imprescindibles para lograr una red SAN, con propiedades similares en rendimiento y fiabilidad que las redes FC, para poder implementar FCoE será necesario que los switches de la red que formen parte de la red convergente sean de última generación, ya que son estos los que incluyen dichas funcionalidades DCB.

Por parte de los servidores, FCoE también requiere un nuevo tipo de conector llamado CNA que sustituye a las NICs y HBAs y que también incluye los protocolos DCB.

No obstante, aunque FCoE imponga la necesidad de switches con capacidades DCB y nuevas tarjetas CNA en los servidores, presenta numerosas ventajas frente al resto de posibilidades presentadas anteriormente, ya que el coste de adquisición y mantenimiento de los equipos implicados es menor (y este cada vez será inferior debido a la popularización de este protocolo entre los fabricantes de productos de red y almacenamiento durante los últimos años), por lo que es más fácil que el ahorro en infraestructura y costes de gestión que proporcione la red convergente, compense la inversión en nuevo equipamiento.

También hay que tener en cuenta que la mayor parte de los conceptos de seguridad y gestión de las redes SAN FC han sido trasladados a las redes convergentes basadas en FCoE, lo cual hace más fácil la transición a este tipo de red convergente.

A continuación se muestra un ejemplo entre un servidor tradicional con diferentes NICs que conectan a los segmentos de red y las HBAs que conectan al Fabric FC:

  

Figura 2 – Ejemplo de conexión de servidor a redes SAN LAN de modo tradicional

La utilización de varias NICs que conectan a los diferentes segmentos suele venir dada por las restricciones de ancho de banda, y fiabilidad (por perdida de paquetes ante congestión), hechos que con las interfaces de 10Gbps con capacidades DCB han sido solventados, por lo que un posible esquema de conexión de los servidores conectados a la red convergente podría ser el siguiente:

  

Figura 3 – Ejemplo de conexión de servidor a redes SAN LAN de modo convergente

El hecho de disponer de 10Gbps en cada enlace, no reduce la necesidad de la correcta configuración de QoS en toda la red convergente, para evitar que el tráfico de unas pocas redes pueda constreñir al del resto dentro de un mismo enlace físico, así como para garantizas latencias bajas en las redes que sean necesarias.

A día de hoy se recomienda que la convergencia de las redes SAN y LAN se limite al primer salto, debido a las restricciones de funcionalidades y conectividad que existen en algunos fabricantes cuando se tiene más de un salto FCoE en la arquitectura. La mayor parte de los fabricantes de Chasis para servidores Blade ya pueden proporcionar esa red convergente de primer salto tal y como se muestra a continuación:

Ilustración 186 – Ejemplo de conexión de servidor a redes SAN LAN de modo convergente

Ideas básicas sobre Software Defined Network (SDN)

"Durante los próximos años, las redes definidas por software o Software Defined Networks (SDN), serán cada vez más comunes, seguramente en un principio en despliegues híbridos con los despliegues tradicionales de red, debido a las múltiples ventajas que introduce y que serán revisadas en esta entrada"

Las redes, tal y como están implementadas hoy en día, tienen una serie de problemas, entre los que se encuentran que:

• Son difíciles de personalizar, ya que la configuración y diseño se debe hacer conforme a los parámetros de numerosos protocolos aislados (STP, protocolos de enrutamiento, etc)

• Son difíciles de integrar con los nuevos servicios que requieren movilidad de máquinas virtuales y usuarios, así como la integración con entornos de Cloud.

• Son difíciles de mantener seguros, ya que los protocolos en los que se basan pueden ser vulnerables a ciertos ataques y la configuración de todos sus elementos lo ha de tener en cuenta.

• Son difíciles de integrar con el resto de elementos TI, como por ejemplo las plataformas de virtualización o el Software que presta el servicio final.

• Son difíciles de optimizar,  pues las opciones de configuración son rígidas y dependen de los protocolos implementados en los switches.

• Es complicado el manejo de los cambios en la red,  ya que la modificación de los flujos en cierto momento tendría que venir dada por la reconfiguración de todos los protocolos independientes de los equipos de red implicados.

• Difíciles de administrar, ya que cada fabricante de Hardware dispone de un CLI, e incluso métodos de gestión, diferentes al resto. También hay que remarcar las dificultades que algunas veces brindan las redes híbridas de dos o más fabricantes, ya que su integración suele ser compleja en algunos casos.

• El Hardware que los soporta es costoso, al tener cada uno de ellos que ejecutar números procesos complejos de decisión de encaminamiento de paquetes.

El origen de los problemas anteriores es que los elementos de la arquitectura de red (switches, routers y demás componentes) se han ido convirtiendo en dispositivos cada vez más complejos, debido al creciente número de protocolos distribuidos que se les han ido integrando los cuales, en muchos casos, no siguen los estándares además de su necesidad de ser gestionados por interfaces  CLIs propietarias.

Mientras el resto de componentes TI se ha adaptado a las necesidades de agilidad, reducción de costes globales y sencillez de gestión, las arquitecturas de red no han seguido ese mismo camino con la misma rapidez, debido a las limitaciones que se han descrito, es por ello por lo que han surgido una serie de tecnologías para modificar el modo en el que trabajan hoy en día las redes.

Las tecnologías Software Defined Networking (SDN) tienen como objetivo el control minucioso de flujos de tráfico mediante un software que brinde una interfaz que permita al usuario personalizar dichos flujos de una manera centralizada, sin recaer en los procesos independientes en cada equipo de red, y sin depender del Hardware subyacente.

La principal idea de SDN es externalizar la responsabilidad del control de flujo y la inteligencia de red fuera del Hardware de los switches y routers, centralizándolo en un servidor llamado controlador, o Controller, que realiza todas las tareas que los antiguos protocolos independientes hacían para para garantizar el correcto encaminamiento de los paquetes.

Al poder tener una visibilidad completa de la red desde los Controllers, en lugar de la actual vista parcial a la que están restringidos los switches y routers, es posible redirigir flujos con gran agilidad y conseguir una optimización máxima de los recursos, incluso mediante comportamientos que son imposibles realizar con los protocolos independientes que actualmente manejan la red.

También se mejora la respuesta ante fallos o incluso congestión en la red, ya que al tener una mayor visibilidad se puede calcular instantáneamente el mejor camino alternativo extremo a extremo, en lugar de la manera local en la que se hace actualmente.

La arquitectura SDN se compone de tres capas diferenciadas:

• Capa de infraestructura, en la que reside el Hardware. Es importante destacar que los componentes de esta red son dispositivos de red, pero que solo se tiene en cuenta el Hardware que lo componen, no los protocolos que contengan ni ningún tipo de inteligencia, por lo que pueden ser equipos de muy bajo coste y no tendrían que ser de un único fabricante, tan solo deberán contar con el soporte del método que les conecta con el controlador, o lo que es lo mismo, el protocolo OpenFlow.

• Capa de control, aquí se encontrarían los controladores, quienes mantienen la inteligencia de la red. Los controladores se comunicarían con los Hardware  de la capa de infraestructura con el protocolo OpenFlow y brindarían una API abierta para que puedan ser programados desde la capa de aplicación.

• Capa de aplicación, es la de más alto nivel y desde la cual se controla el comportamiento de la red. Para ello se utiliza la API del controlador, que puede ser utilizada por usuarios o por otros Software de orquestación o aplicaciones de infraestructura o corporativas.

Figura 1 - Capas de la arquitectura SDN

Al añadir esta tercera capa de aplicación al diseño, es posible programar la red de la misma manera  que las aplicaciones software, de modo que se pueden conseguir implementaciones que se integren ágilmente con el resto de componentes IT, por ejemplo, haciendo que la red se adapte automáticamente a los movimientos de máquinas virtuales entre Data Centers, permitiendo grandes mejoras frente a los diseños tradicionales.

Para entender mejor las posibilidades que brinda SDN, se puede ver un par de ejemplos en los siguientes videos de la Universidad de Stanford (donde principalmente se desarrolló la idea de openflow): 

• Utilización de openflow para el mejor aprovechamiento de las redes Wireless

• Utilización de openflow para la distribución dinámica de flujos

• Aplicación FlowVisor para virtualizar, como si de un "hypervisor" se tratase, los diferentes redes virtuales

También se puede consultar en este enlace un repaso de los puntos básicos sobre redes SDN.

Elementos de la gestión de red

"Esta entrada no es más que una simple enumeración de los principales elementos de gestión con los que debería contar una arquitectura de red más o menos compleja"

Estos son algunos de los bloques funcionales que se pueden distinguir en las plataformas de gestión de red:

• Control de fallos, como puedan ser herramientas de Syslog, gestión de traps SNMP y alarmas lanzadas por otros dispositivos y software.

• Gestión de configuraciones, que permitan realizar un seguimiento de los cambios en las configuraciones  de los equipos, así como herramientas que aseguren el cumplimiento de las políticas de red, como puedan ser las asignaciones de QoS, así como elementos que faciliten o automaticen la configuración de dispositivos. También se incluirán en este ámbito las herramientas de gestión de direcciones IP y nombres de red.

• Accounting, no solo de accesos a red, si no también herramientas que almacenen la utilización de la infraestructura, como pueda ser un log de las llamadas VoIP efectuadas por los usuarios, o un seguimiento del uso que hace de sus privilegios los usuarios con ciertos permisos de administrador.

• Seguimiento del rendimiento, compuesto por herramientas que obtengan métricas de rendimiento de paquetes y un avanzado análisis de comportamiento, para hacer un seguimiento del rendimiento de  las aplicaciones y de la red en el tiempo real, y notificar cualquier desviación del comportamiento normal. También se pueden complementar con componentes que mejoren los trabajos de troubleshooting de flujos de red, y el análisis de tráfico.  Se podrían incorporar en este punto también los equipos destinados a realizar QoS, limitando el uso de los anchos de banda contratados a los ISPs.

• Control de la seguridad y autenticación, donde se situarían los servidores TACACS, LDAP, etc y otros adicionales, como los componentes de la gestión de la solución NAC.

• Automatización de procesos e integración con elementos de virtualización, sistemas y almacenamiento mediante herramientas Software.

Introducción a Bring your own device ( BYOD )

"El aumento de la utilización de móviles inteligentes y otro tipo de dispositivos personales en el entorno empresarial crea una necesidad de planificación y desafíos de la seguridad que deben ser manejados por la infraestructura, ya que cada vez será más difícil evitar que los empleados hagan este uso de sus dispositivos por lo que se deberá intentar sacar provecho de ello, en lugar de intentar detener estos comportamientos."

Bring your own device (del inglés trae tu propio dispositivo) es una política, consistente en permitir que los usuarios accedan a la red de su empresa y a toda clase de aplicaciones desde su propio portátil, tableta o smartphone, que cada vez está ganando más terreno en el mundo empresarial debido a sus numerosas ventajas, tanto para los empleados como para la propia empresa.

Entre las ventajas que ofrece el BYOD, tanto para la empresa como para el trabajador, podemos señalar:

• Se gana en efectividad y flexibilidad, desembocando en una mayor productividad a la larga.

• BYOD favorece la flexibilidad en el trabajo, optimizando la relación entre el tiempo de trabajo y la vida personal y familiar.

• La empresa se evita el comprar estos dispositivos, cargar con el software interno, comprar licencias corporativas, asumir el deterioro de los equipos u ocuparse del mantenimiento informático de estos dispositivos. Por otra parte, los usuarios actualizan su hardware y software personal mucho más a menudo que las empresas, por lo que la empresa se beneficia de las últimas características y capacidades de los equipos más recientes del mercado.

• Los empleados utilizan los dispositivos y aplicaciones a los que están habituados, y que prefieren, en lugar de estar obligados a utilizar los que ha elegido el Departamento de IT y que posiblemente han sido utilizados por numeras personas.

Este incremento de la productividad y flexibilidad que permite la política BYOD plantea dos grandes retos, garantizar la seguridad en el acceso y uso de los recursos y preservar la privacidad de los datos sensibles de la empresa. 

Los retos que se presentan con BYOD son los siguientes:

• Se requieren instrumentos que permitan a los usuarios acceder de manera rápida y sencilla a la red, con una mínima intervención de  los administradores de la red

• Se debe asegurar el crecimiento de las capacidades de conexión de la arquitectura según crezca el número de dispositivos y usuarios que hagan uso de la infraestructura.

• Mantener la seguridad y mitigar los riesgos que se presentan al permitir que los usuarios hagan uso de sus propios dispositivos. También hay que tener en cuenta que se debe implementar políticas de Data Leak Prevention (DLP) para garantizar que no existe riesgo de robo de información sensible, incluso si los dispositivos de los usuarios son robados.

• Al permitir el uso de múltiples plataformas diferentes se necesita una mayor visibilidad de la red y una gestión de accesos más compleja

• Aunque no sea un requisito meramente de la arquitectura de red, si no que estaría principalmente implicado el desarrollo de las aplicaciones, se necesita que el acceso a los recursos por parte de los usuarios sea haga de una forma predecible y confiable, es decir, que sea lo mismo acceder a la información de una aplicación por el PC de la empresa o por el smartphone del empleado.

• Se hace necesario poder acelerar los ciclos de seguridad y conectividad de los productos, ya que los empleados podrán utilizar los últimos dispositivos del mercado, y harán uso de las últimas tecnologías que estos permitan.

Por todo lo anterior, se necesita que los elementos integrados de gestión y despliegue de la nueva red ofrezcan de manera centralizada, una monitorización y facilidad de adaptación al cambio y se preferirá el uso de estándares abiertos antes que protocolos propietarios.

La arquitectura de red, deberá contar con sistemas que permitan:

• Procesos centralizados de autenticación, autorización y accounting (de usuarios y dispositivos)

• Estándares abiertos

• Monitorización unificada de toda la plataforma y generación de reporte de uso

• Gestión integrada de políticas de seguridad

• Gestión de uso de anchos de banda y QoS

• Soporte multi-fabricante

• Conectividad inalámbrica de alto rendimiento  y con funcionalidades avanzadas de seguridad

• Detección y prevención de intrusiones mediante IPS e IDS

• Prevención DLP

Como se ha podido comprobar, BYOD no es una tecnología, es una politica que necesita varias tecnologías de conectividad, seguridad y gestión, para poder englobar una solución frente al aumento de los dispositivos móviles dentro del parqué de equipos que los empleados introducen dentro de las empresas. BYOD hace ver la introducción de equipamiento personal de los empleados como una oportunidad, y no como un problema.