Seguritecnia 371

SEGURITECNIA Enero 2011 87 Artículo Técnico Desventajas VoIP no es una comunicación en tiempo real y puede experimentar, es- pecialmente en casos de alta conges- tión de tráfico, retardos que no serían aceptables. Pero, sin duda, todo esto se superará rápidamente en un en- torno que no deja de evolucionar ha- cia servicios cada vez más competen- tes y seguros. Pero este no es el único problema. El ancho de banda disponible para este servicio está limitado a las necesi- dades de una comunicación inteligible de voz y esto puede suponer una seria barrera para los protocolos de comu- nicación empleados por los sistemas de seguridad, incluyendo las funcio- nes bidireccionales. Algunos opera- dores que brindan ya ADSL y con ella una tarifa plana en llamadas naciona- les para RTB basada en VoIP, advierten expresamente de este hecho en los kits que proporcionan a sus clientes: Este tipo de línea seudo RTB puede generar problemas con los sistemas de seguridad. La actual situación de las comunicaciones en Banca Las líneas Frame Relay con que las en- tidades financieras iniciaron sus co- municaciones de datos, que contaban además con otras vías de respaldo de tipo RDSI, están desapareciendo y en algunos casos, lo han hecho ya por completo. Hoy, estas comunicaciones están servidas por una línea ADSL, muy se- mejante a la que un usuario privado contrata para su casa y que está nor- malmente sopor tada por una línea RTB tradicional. Las líneas Frame Relay y RDSI han pasado a la historia en este caso, con el correspondiente ahorro, pero esto ha hecho cambiar el escena- rio de comunicación para los sistemas de seguridad. Comunicación IP&RTB Durante la implantación de la comuni- cación IP de los sistemas de seguridad, se ha mantenido la línea RTB como backup o respaldo, ante un posible fa- llo de la línea digital. Esta alternativa era totalmente válida en sus orígenes, cuanto Frame Relay prestaba servi- cio, debido a que el soporte físico de la vía principal (IP) y la alternativa (RTB) eran diferentes (distintos pares de co- bre y distinta infraestructura de comu- nicación). Hoy en día esto no es así. La línea ADSL susti tutiva de las anter iores presta el servicio IP y la alternativa RTB sobre un par de hilos común y esto puede suponer un serio problema. En caso de sabotaje o de fallo téc- nico de este par, ambas comunicacio- nes se pierden con la correspondiente incertidumbre. Incluso en el caso de que la alternativa RTB fuera prestada por una línea independiente, por ejem- plo, una que da servicio a un fax, el pro- blema no se resuelve ya que, si la aco- metida de ambas es común, ambos son simultáneamente vulnerables ante el ci- tado sabotaje. Es evidente que este pro- blema siempre ha existido, incluyendo los tiempos de Frame Relay, RDSI y RTB. EN50131 y las comunicaciones La aplicación de la nueva normativa desterrará en ciertos casos las comu- nicaciones que hasta ahora hemos conocido. La nueva Ley exige para el grado 3 que estas comunicaciones estén encriptadas por cualquier vía y esto supone aquí la desaparición de los protocolos de toda la vida emplea- dos por RTB. Contact ID y SIA, los más extendidos, sólo podrán ser emplea- dos en los grados 1 y 2. ¿Qué alternativa tenemos entonces? Está claro que, para el grado 3, se per- mite el empleo de una única vía de comunicación encriptada si se efec- túa un control periódico de la misma cada 3 minutos o menos, lo cual es perfectamente alcanzable por varios sistemas comerciales pero, si se desea una vía alternativa como se ha hecho hasta ahora y tal como la legislación exige en determinados casos, la solu- ción ya no es tan fácil. ¿Es válido emplear sólo ADSL? Para empezar, el empleo de ADSL como única vía de soporte de la co- municación IP y RTB es discutible si consideramos lo que dice la legislación Estructura de un sistema básico VoIP junto con una LAN No se puede poner en duda la vulnerabilidad de una comunica- ción que, empleando 2 tecnolo- gías, IP y RTB analógica, emplea como soporte físico un único par de hilos de cobre. Y ya existe so- lución para ello.

RkJQdWJsaXNoZXIy MTI4MzQz