ES2911500T3

ES2911500T3 - Autorización físicamente asegurada para aplicaciones de servicios públicos

Info

Publication number: ES2911500T3
Application number: ES20154890T
Authority: ES
Inventors: Raj Vaswani; Wilson Chuen Yew Yeung; Cristina Seibert; Nelson Bruce Bolyard; Benjamin N Damm; Michael C Stjohns
Original assignee: Itron Networked Solutions Inc
Current assignee: Itron Networked Solutions Inc
Priority date: 2010-11-04
Filing date: 2011-10-11
Publication date: 2022-05-19
Anticipated expiration: 2031-10-11
Also published as: US10609562B2; CN103430183B; EP3664367B1; US20160249220A1; DK3684007T3; EP3684007A1; JP2014501955A; CA2816989A1; EP3664367A1; DK3664367T3; SG190152A1; WO2012060979A1; AU2011323917B2; EP2635994A1; US9961550B2; EP2635994B1; KR101430376B1; BR112013011804A2; JP6349347B2; EP3684007B1

Abstract

Un procedimiento de operación de una red que tiene una pluralidad de puntos finales (26) que se comunican con un primer centro de datos (70) y un segundo centro de datos (72) a través de puntos de acceso (AP), en el que el primer centro de datos (70) incluye un primer entorno físicamente seguro que tiene un primer certificado, y el segundo centro de datos (72) incluye un segundo entorno físicamente seguro que tiene un segundo certificado, comprendiendo el procedimiento: recibir, por parte del segundo entorno físicamente seguro, una indicación de que la seguridad del primer entorno seguro ha sido comprometida; y en respuesta a la recepción de la indicación, emitir, por el segundo entorno físicamente seguro, una orden a los puntos de acceso para configurar una lista de revocación de certificados que indique que el certificado asociado al primer entorno físicamente seguro no es válido; y emitir, por parte del segundo entorno físicamente seguro, una orden a los nodos de los puntos finales para que carguen la lista de revocación de certificados desde cualquiera de los puntos de acceso.

Description

DESCRIPCIÓN

Autorización físicamente asegurada para aplicaciones de servicios públicos

Campo técnico

La presente divulgación se refiere a la gestión y el control de operaciones asociadas a las empresas de servicios públicos, y más concretamente a la seguridad de los sistemas que gestionan y controlan dichas operaciones.

Antecedentes

Las empresas de servicios públicos tienen sistemas complejos y altamente interconectados, que se ejecutan en servidores físicos que ejecutan una multitud de módulos de software asociados para gestionar y controlar las operaciones de la empresa de servicios públicos. La figura 1 es un diagrama de bloques general de algunos de los componentes que pueden encontrarse en un sistema típico de gestión y control de una empresa de servicios públicos que suministra energía eléctrica a los clientes, y posiblemente otros productos básicos como gas, agua, etc. El back office (oficina de gestión de la empresa) 10 del sistema comprende una serie de subsistemas individuales asociados a diversas operaciones de la empresa, por ejemplo un sistema de información al cliente (CIS) 12, un módulo de relaciones con el cliente (CRM) 14, un sistema de gestión de interrupciones (OMS) 16, un sistema de información GPS 18, un sistema de facturación 20, un módulo de estabilidad de la red 22 y una interfaz de usuario 24. Aunque no se ilustra en la figura 1, pueden existir otros módulos funcionales en el back office 10. Algunos de estos subsistemas pueden tener la capacidad de comunicarse con los dispositivos de la red de distribución de los servicios que se suministran, y controlar a distancia las operaciones asociadas a esos dispositivos. Por ejemplo, el servidor de back office puede comunicarse con los contadores individuales 26 situados en las instalaciones de los clientes para obtener datos de consumo con fines de facturación, y ordenar a los contadores que desconecten o reconecten selectivamente al cliente del suministro de uno o más de los productos básicos proporcionados por la empresa de servicios públicos. Otras órdenes del servidor de back office a los contadores individuales pueden incluir órdenes para aceptar el flujo de energía saliente de los clientes.

En el ejemplo de la Figura 1, los contadores constituyen nodos finales que se comunican con el back office por medio de una red de área local 30 que tiene puntos de acceso 32 que proporcionan salida y entrada a la red. La red de área local puede ser una red de malla inalámbrica. Los puntos de acceso 32 se comunican con los servidores del back office 10 mediante una red de área amplia 34 o un enlace de comunicaciones dedicado.

En un sistema de este tipo, una cuestión que preocupa es la gestión segura de las desconexiones y reconexiones remotas, que pueden producirse cuando un cliente abandona un local o no cumple con los pagos, o cuando un nuevo cliente toma posesión del local, respectivamente. Las órdenes malintencionadas o erróneas de desconexión y/o reconexión de forma remota de instalaciones pueden desestabilizar la red de distribución de energía eléctrica. Las reconexiones no autorizadas también podrían provocar el robo de energía distribuida. Para limitar estas posibilidades, hay que hacer esfuerzos para garantizar que las operaciones de mando y control se realicen de forma segura, y sólo por parte de las entidades autorizadas para llevarlas a cabo tales operaciones. Sin embargo, dado que el back office de una empresa típica de servicios públicos se compone de una variedad de sistemas interconectados, la aplicación del acceso seguro se hace difícil. Muchos grupos diferentes dentro de la empresa de servicios públicos necesitan acceder a todo o parte del sistema de software, lo que complica la capacidad de limitar el acceso lógico y/o físico a subsistemas individuales.

Una posible solución a este problema es colocar ciertos sistemas, o partes de dichos sistemas, dentro de un entorno físicamente seguro, denominado en adelante búnker. Entre los ejemplos de búnker se encuentran una sala o contenedor de acceso restringido, por ejemplo, una sala cerrada con llave, y una carcasa o recinto a prueba de manipulaciones alrededor de un sistema protegido. El búnker restringe severamente el acceso físico a los dispositivos de hardware en los que se ejecutan los sistemas, o partes protegidas de los mismos. Además, los sistemas dentro del búnker exportan un acceso lógico muy limitado. Sin embargo, esta solución sigue presentando un problema, ya que es difícil refactorizar los sistemas de software de las empresas de servicios públicos para determinar qué partes deben estar dentro del búnker y qué partes pueden permanecer fuera de él para proporcionar un acceso más flexible a quienes lo necesitan.

El documento US2006/095454 describe un sistema y un procedimiento para la autenticación segura de la identidad del terminal en colaboración entre un dispositivo de comunicación inalámbrica y un operador inalámbrico. El documento WO02/063847 describe la distribución de certificados móviles en una PKI.

Sumario

Para proporcionar seguridad general a un sistema de gestión de servicios públicos, se requiere que los mensajes de órdenes y control críticos que se emiten a los componentes del sistema sean aprobados explícitamente por una autoridad segura. La aprobación explícita autentifica la acción solicitada y autoriza la realización de la acción específica indicada en un mensaje. Los componentes clave del sistema de gestión y control de los servicios públicos que están asociados al control de acceso se encuentran en un entorno físicamente seguro. Con este enfoque, sólo es necesario asegurar físicamente los subsistemas que se encargan de aprobar las acciones de la red, por ejemplo, mediante un búnker. En otras palabras, la mayoría de los módulos de gestión, como el CIS, CRM, OMS, facturación, etc. pueden permanecer fuera del búnker, evitando así la necesidad de dividir esos subsistemas en componentes bunkerizados y no bunkerizados. El acceso a los componentes críticos de cada uno de los subsistemas no bunkerizados se controla a través del sistema de aprobación bunkerizado.

La invención a la que se refiere esta patente europea se define en las reivindicaciones adjuntas.

Breve descripción de las figuras

La figura 1 es un diagrama de bloques general de un sistema de gestión y control de servicios públicos según un ejemplo útil para comprender la presente divulgación;

La figura 2 es un diagrama de bloques de un sistema de back office de servicios públicos con componentes bunkerizados según un ejemplo útil para entender la presente divulgación;

La figura 3 es un diagrama de bloques que representa esquemáticamente el flujo de datos cuando se envía un mensaje a un contador según un ejemplo útil para comprender la presente divulgación;

La figura 4 es un diagrama de bloques de la configuración de un módulo de seguridad de hardware según un ejemplo útil para entender la presente divulgación;

La figura 5 es un diagrama de bloques de una memoria intermedia de varias etapas que cuenta las operaciones criptográficas a lo largo de una ventana deslizante según un ejemplo útil para comprender la presente divulgación;

La figura 6 ilustra un ejemplo de sistema y procedimiento de emisión de permisos de órdenes según un ejemplo útil para la comprensión de la presente divulgación;

La figura 7 es un diagrama de bloques de un formato ejemplar de una carga útil de permiso según un ejemplo útil para comprender la presente divulgación; y

La figura 8 es un diagrama de bloques de un sistema de control y gestión de servicios públicos implementados en múltiples centros de datos según una realización de la invención a la que se refiere esta patente europea.

Descripción detallada

Para facilitar la comprensión de los principios en los que se basa la presente divulgación, ésta se describe a continuación con referencia al control seguro de las órdenes de conexión y desconexión remotas en un sistema de distribución de energía eléctrica. No obstante, se apreciará que este ejemplo no es la única aplicación práctica de estos principios. Más bien, pueden emplearse en relación con cualquier tipo de orden crítica que, si se emite de forma inadecuada o errónea, podría tener el potencial de perturbar o dañar gravemente un sistema. Asimismo, pueden utilizarse junto con todas las órdenes y mensajes de control enviados a un componente crítico del sistema cuyo funcionamiento correcto es esencial en todo momento.

La figura 2 ilustra un ejemplo de un centro de datos 40 en el que se ilustran los conceptos de la presente divulgación. Como es convencional, el centro de datos contiene un número de servidores físicos en los que se ejecutan varias aplicaciones 12, 14, 16. Aunque en la figura sólo se ilustran algunas aplicaciones representativas, se apreciará que se podría implementar un número mayor de dichas aplicaciones dentro del centro de datos. A la inversa, las funciones realizadas por dos o más de las aplicaciones pueden integrarse en un programa único y completo.

También se encuentra dentro del centro de datos un búnker físico 42 con acceso físico limitado, como una sala cerrada con paredes reforzadas. Como otro ejemplo, el búnker puede ser, además de o en lugar de estar cerrado, una zona estrechamente vigilada o protegida mediante cámaras de seguridad, detectores de movimiento, etc. Otro ejemplo es que el búnker puede estar distribuido físicamente, habiéndose establecido una relación de seguridad entre las partes distribuidas. Como otro ejemplo, el búnker puede estar asegurado lógicamente, como por ejemplo, mediante el uso de software y/o firmware de ejecución segura cuya funcionalidad está asegurada contra la manipulación física, como el embalaje autodestructivo. El búnker no tiene por qué ser una habitación, sino que, por ejemplo, puede ser una caja físicamente segura.

Uno o más dispositivos de servidor adicionales que tienen un módulo de seguridad de hardware asociado 44 están ubicados dentro del búnker, para la implementación de un motor de autorización 46 que tiene módulos de software que realizan operaciones relacionadas con la seguridad como la autorización, la autenticación y la contabilización. El módulo de seguridad de hardware contiene claves privadas y otras claves secretas de forma segura. También puede contener certificados públicos vinculados a las claves privadas. El módulo de seguridad de hardware utiliza preferentemente un algoritmo de seguridad robusto, como la criptografía de curva elíptica u otro procedimiento criptográfico de alta seguridad, para realizar las operaciones criptográficas. Un ejemplo de módulos de seguridad de hardware que son adecuados para las aplicaciones descritas en este documento es la línea de módulos de seguridad de hardware SafeGuard CryptoServer de Utimaco Safeware AG.

El acceso seguro al búnker, y a los dispositivos del servidor ubicados dentro de él, puede reforzarse con tecnología de biosensores, por ejemplo, detección de huellas dactilares, llaves físicas o tokens, y/o protección por contraseña. En una implementación, se puede emplear un sistema de seguridad jerárquico y por niveles para maximizar la protección. Si falla un nivel de seguridad, por ejemplo, si se revelan accidentalmente o se roban las contraseñas, puede activarse un mecanismo de seguridad de nivel superior, como una cerradura de cerrojo accionada por clave o token, para mantener la seguridad física de todo el sistema.

Ciertos tipos de órdenes de las aplicaciones de back office 12-16, etc., que no son de uso restringido, no podrán ser ejecutados a menos que sean autenticados individualmente. Por ejemplo, las órdenes de desconexión y reconexión remotas son una categoría de estas órdenes restringidas, debido al potencial que presentan para la perturbación grave de la estabilidad de la red de distribución de energía. Para reforzar la seguridad de este tipo de operaciones, las aplicaciones que las llevan a cabo sólo pueden aceptar órdenes para hacerlo si se originan en una consola dentro del búnker 42, o son autenticadas de otro modo por un permiso emitido desde el búnker 42. Por lo tanto, sólo el personal que tenga autoridad para emitir esas órdenes, y que posea los medios necesarios para acceder al búnker, por ejemplo, contraseña, clave, huella digital, etc., podrá emitir las órdenes restringidas a la aplicación.

Cuando se inicia una operación que provoca la generación de una orden, éste puede ser firmada o autenticada de otro modo por el motor de autorización 46, y luego reenviado a una interfaz de programación de aplicaciones (API) asociada con la aplicación apropiada externa al búnker 42. Por ejemplo, la orden puede ser firmada por una clave privada almacenada dentro del módulo de seguridad de hardware 44. Al recibir la orden firmada en una aplicación externa, por ejemplo, una de las aplicaciones 12-16 o una aplicación que se ejecuta en uno de los contadores 26, se verifica mediante una clave pública a la que la aplicación tiene acceso. Una vez verificado que se ha originado en el búnker, la orden es ejecutada por la aplicación externa.

En algunas situaciones, puede no ser práctico que una entidad que emita órdenes de desconexión remota esté físicamente presente dentro del búnker. Sin embargo, si se admite la generación remota de dichas órdenes, éstas podrían ser emitidas de forma maliciosa por usuarios que se hagan pasar por entidades autorizadas. Para limitar la posibilidad de estos sucesos, se implementa un módulo de política 48 dentro del búnker. El módulo de política puede ser un componente de software o firmware separado, como se muestra en la Figura 2, o estar lógicamente incorporado al módulo de seguridad de hardware, como se describe más adelante. El módulo de política 48 puede ser reconfigurado o reprogramado de forma segura, como por ejemplo mediante órdenes introducidas desde el interior del búnker. Este módulo contiene la lógica comercial que examina una acción solicitada y determina si se permitirá llevarla a cabo. Por ejemplo, si las órdenes de reconexión se emiten en una secuencia, o con una sincronización relativa, que podría perturbar la estabilidad de la red de distribución de energía, pueden ser bloqueadas por la política y no pasar al motor de autorización para su firma. Además, se pueden levantar banderas de política y tomar acciones apropiadas, como desconectar una entidad que emite órdenes, cuando se detectan ciertas condiciones. Estas condiciones pueden incluir, por ejemplo:

1. Un gran número de órdenes de desconexión remota se emiten al mismo tiempo, por ejemplo, en un intervalo de tiempo predeterminado, lo que indica una posible intención de desconectar maliciosamente a los usuarios de la red de distribución de energía;

2. Las órdenes se emiten en un orden sospechoso, como una secuencia de órdenes repetitivas de conexión y desconexión que se asocian con el mismo cliente, u órdenes que son inconsistentes con el estado actual de un cliente, por ejemplo, emitir una orden de desconexión a un usuario que no está ya conectado a la red eléctrica;

3. Una aplicación que se solicita no proporciona las credenciales necesarias, o no se autentifica de otra manera;

4. Una aplicación que se solicita no se encuentra entre un conjunto de solicitudes aprobadas que tienen permiso para emitir determinadas operaciones; y

5. El estado de la red de distribución, basado en las cargas reales de energía y las necesidades de energía proyectadas.

Para implementar esta funcionalidad, el búnker puede contener un proxy 50 para las interfaces de programación de aplicaciones (API) de las aplicaciones que son externas al búnker. En funcionamiento, cuando se realiza una llamada a la API para una de estas aplicaciones "externas", la llamada se dirige al proxy 50 dentro del búnker. El proxy consulta la lógica comercial de utilidad en el módulo de políticas 48 que puede ser necesaria para autorizar la solicitud, y hace que la solicitud sea firmada por la lógica comercial apropiada. A continuación, la solicitud se transmite al motor de autorización 46 para su firma. Una vez autorizado, el proxy invoca la API normal para la aplicación llamada que es externa al búnker, y transmite la llamada autorizada.

En una implementación alternativa, el búnker 42 puede no incluir un proxy. En este caso, se puede hacer una petición directamente a la API de una aplicación externa. A su vez, la aplicación externa llama al motor de autorización dentro del búnker si determina que la operación solicitada requiere una firma. Por defecto, todas las solicitudes podrían pasar al búnker para su autorización, para evitar la necesidad de cualquier determinación por parte de la aplicación externa.

Las solicitudes enviadas al búnker son primero verificadas y firmadas por el módulo de políticas, y luego pasadas al motor de autorización 46. Una vez que se autoriza una solicitud, la aplicación llamada actúa sobre la solicitud.

El módulo de seguridad de hardware 44 incluido en el búnker 42 puede operar a dos niveles. A continuación se describen ejemplos relacionados con las operaciones que se realizan en los contadores 26. En el primer nivel de operación, la empresa de servicios públicos podría instituir una política según la cual todas las comunicaciones entre una aplicación en el back office 10 y un contador 26, o cualquier otro componente de la red 30, deben estar cifradas y firmadas. La implementación de esta política se representa en el ejemplo de la figura 3. En este ejemplo, una aplicación de gestión de contadores 52 tiene un mensaje, por ejemplo una orden, para enviar a uno o más de los contadores 26. Este mensaje se construye en un módulo de mando e interfaz de contadores 54 de la aplicación, y se envía al módulo de seguridad de hardware 44 del búnker 42, con una solicitud para realizar el cifrado y la firma adecuados del mensaje. El módulo de política 48 puede comprobar en primer lugar para confirmar que la solicitud procede de una fuente autorizada. Si es así, se pasa al módulo de seguridad de hardware. El módulo de seguridad de hardware 44 realiza la operación solicitada sobre el mensaje, utilizando las claves adecuadas asociadas a la aplicación, y devuelve los datos cifrados y firmados. El módulo de mando e interfaz 54 de la aplicación de gestión de contadores crea entonces un paquete de datos que incorpora el mensaje cifrado y firmado, y lo transmite al contador a través de la red 30.

En el caso de los mensajes recibidos de los nodos de la red 30 por la aplicación 52, estos se reenvían primero al módulo de seguridad de hardware, para ser descifrados. El módulo 48 también puede realizar cualquier verificación apropiada de la autenticidad del remitente del mensaje recibido, y de la integridad de los datos. El mensaje verificado y descifrado se devuelve entonces a la aplicación 52.

Para las operaciones críticas, como las conexiones y desconexiones remotas, el módulo de seguridad de hardware puede operar en un segundo nivel para hacer cumplir un límite de tasa en tales operaciones. La figura 4 muestra un ejemplo de configuración interna de un módulo de seguridad de hardware. El módulo está configurado con un número de ranuras. Cada ranura contiene una colección de claves privadas, certificados, claves secretas y privilegios de acceso, para realizar servicios criptográficos como la firma, el cifrado, el descifrado, etc. Las diferentes ranuras están asociadas a diferentes contextos de seguridad, y contienen las claves, certificados y otra información pertinente a sus respectivos contextos. La realización de un servicio criptográfico en una orden con el módulo de seguridad de hardware, como la firma con una clave privada, permite al receptor de la orden, por ejemplo, un nodo 26, autenticar la fuente de la orden, utilizando una clave pública asociada. El módulo de política 48 realiza la determinación inicial de si se permite presentar una orden solicitada al módulo de seguridad de hardware para uno o más servicios criptográficos.

Cada ranura puede configurarse selectivamente con uno o más límites de tasa, por ejemplo mediante una herramienta de administración de línea de órdenes, para hacer cumplir la lógica comercial deseada. Un ejemplo de orden para configurar una ranura es el siguiente:

HSM_configure slot=2 rate-name="ratel" window=24h count=10000

Dicha orden configura la Ranura 2 con un límite de tasa máxima de 10.000 operaciones criptográficas por ventana deslizante de 24 horas. Si se produce más de este número asignado de operaciones criptográficas en las 24 horas anteriores, la ranura detiene todas las operaciones criptográficas adicionales. A partir de entonces, será necesario que un administrador reinicie la ranura enviando una orden de reinicio.

Una ranura puede configurarse con más de una tasa, como se indica a continuación:

HSM_configure slot=2 rate-name="ratel" window=24h count=40000

HSM_configure slot=2 rate-name="rate2" window=60m count=2000

Estas dos órdenes configuran la ranura 2 con dos ventanas de límite de tasa, una para 40.000 operaciones criptográficas en una ventana deslizante de 24 horas, y otra para 2.000 operaciones criptográficas en una ventana deslizante de 60 minutos.

Si una ranura está configurada con un límite de tasa, todas las operaciones criptográficas ejecutadas en la ranura son contadas contra el límite asignado sobre una ventana deslizante. En el ejemplo anterior, si hay más de 40.000 operaciones criptográficas en las últimas 24 horas, o más de 2.000 operaciones criptográficas en los últimos 60 minutos, la ranura detiene cualquier otra operación criptográfica.

La contabilización de las violaciones del umbral puede realizarse en incrementos de 5 minutos. La figura 5 ilustra un ejemplo en el que se ha configurado una ranura con un límite de 800 operaciones criptográficas en una ventana deslizante de 25 minutos. La ventana deslizante puede ser implementada como una memoria intermedia de varias etapas 56. La memoria intermedia ilustrada comprende cinco etapas 58, cada una de las cuales representa un intervalo de tiempo de 5 minutos. Cada etapa contiene un recuento del número de operaciones criptográficas realizadas por la ranura durante su correspondiente intervalo de tiempo. La siguiente tabla proporciona una instantánea de los datos contenidos en la memoria intermedia en un momento dado.

Si la suma de todos los recuentos, en este caso 15+0+7+1+6 = 29, supera el umbral, la ranura detiene todas las operaciones criptográficas adicionales hasta que se reinicie administrativamente. Se puede implementar un mecanismo de alerta para notificar al personal administrativo antes de que se detengan las operaciones. Por ejemplo, puede generarse una primera alerta cuando el recuento total supere el 80% de un límite de tasa, y una segunda alerta si alcanza el 90% del límite.

La etapa asociada al intervalo más reciente, en este caso la Etapa 5, mantiene un recuento continuo de cada nueva operación criptográfica. Al final de cada intervalo de 5 minutos, los recuentos almacenados se desplazan a la siguiente etapa más antigua. La última etapa se restablece a cero, y comienza a contar de nuevo las operaciones criptográficas para el siguiente intervalo de 5 minutos.

Dado que cada ranura puede configurarse selectivamente con sus propios límites de tasa, se proporciona flexibilidad en la implementación de la lógica comercial. Por ejemplo, como se describe más adelante, ciertas órdenes críticas pueden requerir un tipo explícito de autenticación, en adelante denominado "permiso", antes de poder ser ejecutados. Estas órdenes pueden ser asignadas a un contexto de seguridad que se asocia con una ranura que lleva a cabo los procedimientos de permiso, y tienen límites de tasa particularmente estrictos. Otros tipos de "ordenes pueden ser asignadas a diferentes contextos de seguridad y ser cifradas y/o firmadas a través de una ranura diferente que tenga límites de tasa menos estrictos.

Para las órdenes críticas, como las órdenes de desconexión y reconexión remotas, puede ser apropiado un nivel más alto de seguridad, como la aprobación por múltiples partes, cada una de las cuales debe ser autenticada en el nodo receptor. Sin embargo, desde el punto de vista de la eficiencia de la red, es deseable que el nodo, al que se dirige la orden, sólo tenga que ser contactado una vez para ejecutar la orden. Estos objetivos pueden alcanzarse mediante un sistema de permisos que proporcione toda la información necesaria para que el nodo pueda autentificar una orden. Esencialmente, cada orden crítica que se envíe a una aplicación, como una orden de desconexión a un contador, puede requerir ir acompañada de un permiso. Como se ha señalado anteriormente, diferentes tipos de órdenes pueden ser asignados a diferentes contextos de seguridad. Cuando se va a emitir una orden, ya sea automáticamente por una aplicación o a través de una interfaz de usuario, la aplicación emisora comprueba el contexto de seguridad de la orden. Si se requiere encriptación, la orden se reenvía a una ranura apropiada del módulo de seguridad de hardware para tal operación. Si se determina que el contexto de seguridad requiere un permiso, la orden se reenvía a un servidor de permisos en el búnker, que emite los permisos. La función del servidor de permisos puede ser implementada por una ranura en el módulo de seguridad de hardware.

En la figura 6 se ilustra un ejemplo de disposición y procedimiento de concesión de permisos, con referencia a una orden de desconexión de un local de la red de distribución eléctrica. En este ejemplo, uno de los módulos de negocio del back office 10, por ejemplo, un sistema de contabilidad, emite una orden a la aplicación de gestión de contadores 52, para desconectar los locales asociados a una cuenta. Al recibir esta orden, la aplicación de gestión de contadores puede programar la operación de desconexión para un momento determinado y, a continuación, envía un mensaje a un módulo gestor de carga 59 a través de un enlace seguro, solicitando permiso para emitir la orden. El gestor de carga es un componente de la lógica comercial que se encuentra dentro del búnker 42 y determina si los cambios de carga en la red de distribución pueden ser perjudiciales. En este ejemplo, el gestor de carga funciona como una implementación de un servidor de permisos. El gestor de carga puede rechazar la solicitud si se determina que el cambio solicitado puede ser perjudicial, aplazar la solicitud durante un periodo de tiempo, por ejemplo, si hay demasiadas solicitudes pendientes, o aprobar la solicitud. La solicitud al gestor de carga puede incluir información como el nodo objetivo, la hora de operación programada y el tamaño de la ventana de tiempo necesaria para completar la ejecución de la orden.

Si la solicitud es aprobada, el gestor de carga crea un permiso que puede ser reconocido por el nodo al que se dirigirá la orden. Antes de que el permiso se devuelva a la aplicación de gestión de contadores 52, se firma con una clave asociada al gestor de carga. En el ejemplo ilustrado, el servidor de permisos, es decir, el gestor de carga 59 está separado del módulo de seguridad de hardware 44. En este caso, por tanto, el permiso se envía al módulo de seguridad de hardware para ser firmado con la clave privada del gestor de carga. El permiso firmado se devuelve al gestor de carga para que lo transmita a la aplicación de gestión de contadores 52.

Al recibir el permiso firmado, la aplicación de gestión de contadores envía la orden autorizada al nodo 26 que está asociado con las instalaciones a desconectar, junto con el permiso firmado. A continuación, el nodo puede verificar el permiso, por ejemplo, siguiendo una cadena de certificados desde el permiso, a través de las credenciales del gestor de carga, hasta una autoridad raíz asociada al operador del sistema para la red de distribución de energía. El nodo también verifica que los valores de tiempo dentro del permiso son consistentes con la hora actual. Si toda la información es correcta y está verificada, el nodo ejecuta la orden y envía un recibo firmado a la aplicación de gestión de contadores 52, indicando el cumplimiento de la orden. Se puede enviar una copia del recibo al gestor de carga 59, para que pueda llevar un seguimiento de las solicitudes pendientes.

La aplicación de gestión de contadores 52 también puede firmar la carga útil del paquete que se envía al nodo, para proporcionar dos autorizaciones separadas para la orden que son emitidas por diferentes entidades de control, a saber, la aplicación de gestión de contadores y el gestor de carga. Ambas formas de autorización deben ser verificadas por el nodo antes de ejecutar la orden. En este ejemplo, el servidor de permisos, por ejemplo el gestor de carga, no posee las credenciales necesarias para comunicarse directamente con el nodo 26. Más bien, proporciona credenciales a otra entidad de control, en este caso la aplicación de gestión de contadores 52, para la ejecución de la orden autorizada.

La lógica comercial para determinar si se aprueba una orden puede ser relativamente sencilla, por ejemplo, un algoritmo de cubo agujereado en el que se permite una ráfaga inicial de un número predeterminado de operaciones de desconexión, seguida de un número menor de operaciones por unidad de tiempo. En este caso, la función del gestor de carga podría implementarse dentro de una ranura del módulo de seguridad de hardware, utilizando el control de tasa descrito anteriormente. Otro algoritmo más complejo puede basarse en el estado de la red de distribución de energía, por ejemplo, haciendo un seguimiento de las cargas de energía reales y realizando determinaciones basadas en proyecciones de las necesidades de energía. Este ejemplo puede realizarse fuera del módulo de seguridad de hardware, como se muestra en la Figura 6, por ejemplo dentro de un sistema físico dedicado, un servidor virtual o una aplicación en un sistema compartido.

Además de las desconexiones y reconexiones remotas, se puede exigir que otros tipos de órdenes tengan un permiso, como los comandos de limitación de carga que se dirigen a las instalaciones de un cliente para reducir el consumo durante un periodo de tiempo determinado. Además, si la operación segura de un tipo particular de dispositivo en el sistema es crítico para la estabilidad del sistema, como un componente de automatización de la distribución, se puede exigir que todas las órdenes emitidas a ese dispositivo tengan un permiso. Cada vez que un módulo de back office emite una orden a un dispositivo de este tipo, reenvía la orden al servidor de permisos, para obtener el permiso necesario.

En la Figura 7 se representa un formato ejemplar para un permiso contenido en la carga útil de un mensaje. El primer campo 60 de la carga útil del permiso indica una hora de inicio, es decir, el momento en que el permiso pasa a ser válido. Cuando un nodo recibe un mensaje que contiene una carga útil de permiso, el nodo compara la hora de inicio con su hora actual. Si la hora de inicio es posterior a la hora actual más un incremento predeterminado, por ejemplo, cinco minutos, el nodo rechaza el permiso como no válido.

El segundo campo 62 de la carga útil del permiso indica una ventana de duración durante la cual el permiso sigue siendo válido. Este campo contiene un valor que indica el número de intervalos de tiempo predeterminados, por ejemplo, bloques de cinco minutos, más allá de la hora de inicio de la validez del permiso. Si la hora actual del nodo es mayor que la hora de inicio del permiso más el producto del intervalo predeterminado y el valor de la ventana, el permiso se rechaza como no válido. Por ejemplo, si la hora de inicio es 1:00:00, el valor de la ventana es 2, y la hora actual es 1:12:38, el permiso será rechazado por haber expirado.

El siguiente campo 64 de la carga útil del permiso indica la operación que se permite realizar. Por ejemplo, este campo puede contener un valor que indique una operación de desconexión de energía, o una operación de reconexión de energía. Se pueden asociar varias operaciones a un mismo permiso. El campo de tipo de objetivo 66 indica el formato del campo objetivo 68 que sigue. El campo objetivo 68 designa el nodo, o dispositivo, que debe realizar la operación permitida. Por ejemplo, el objetivo podría ser la dirección MAC del nodo. El campo de tipo de objetivo 66 indica el formato en el que se expresa esta dirección, por ejemplo, una cadena de octetos DER.

Para aumentar aún más la seguridad, se puede imponer la restricción de que una orden de desconexión o reconexión sólo puede ser emitida para un contador a la vez. Antes de emitir un permiso, el gestor de carga puede comprobar que la dirección objetivo del dispositivo está asociada a un único dispositivo y no es una dirección de grupo o de difusión.

La carga útil del permiso puede ser firmada por la clave privada asociada a un certificado con privilegios para la operación indicada. Al recibir el paquete de datos que contiene la carga útil del permiso, el nodo comprueba primero si la operación indicada requiere un permiso. Si se requiere un permiso, el nodo confirma que el certificado y la clave privada que se utilizaron para firmar el permiso tienen los privilegios necesarios para ejecutar la operación solicitada. Si la confirmación es afirmativa, el nodo verifica la autenticidad del permiso firmado, ya que ha sido firmado por la correspondiente clave privada del certificado indicado. A continuación, el nodo verifica que la designación de objetivo identifica al propio nodo. Por último, el nodo examina la hora de inicio y los valores de la ventana, en relación con su hora actual, para confirmar que el permiso no ha caducado.

Si todas las comprobaciones de verificación tienen éxito, la operación se ejecuta, y se devuelve una respuesta para confirmar la ejecución exitosa. Si alguno de los pasos de verificación falla, el permiso es rechazado y se devuelve un mensaje de error. En cuanto se hayan completado todas las operaciones del paquete de datos, o se devuelva un mensaje de error, el permiso se descarta y no se retiene más.

En el caso de que el acceso al búnker se vea comprometido, se puede implementar una forma adecuada de acción correctiva. Una de estas soluciones es proporcionar un botón de pánico lógico o físico que esté asociado a un búnker. Este botón de pánico puede ser activado (por ejemplo, por una persona que presiona un botón físico o activa un elemento de la interfaz de usuario, o por una lógica que hace una determinación apropiada de forma automática) para informar al sistema de gestión de que el búnker asociado con el botón de pánico está comprometido, y ya no se debe confiar en él. Por ejemplo, cualquier solicitud de servicios de desconexión remota que esté firmada por un búnker comprometido debe ser ignorada.

El botón de pánico puede ser implementado en una variedad de formas. Algunos ejemplos adecuados son las señales de control que se envían a través de un sistema de comunicación inalámbrico o por cable, pulsadores físicos situados en lugares adecuados, por ejemplo, en los escritorios de los empleados, que están conectados a una red de área local o amplia, y/o los dispositivos portátiles con capacidad de órdenes de audio y conectividad inalámbrica.

La figura 8 ilustra un ejemplo de un sistema según una realización de la invención a la que se refiere esta patente europea, y en el que se puede implementar la funcionalidad de un botón de pánico. En este ejemplo, el sistema de gestión y control de servicios públicos está alojado en dos centros de datos 70 y 72. Por ejemplo, cada centro de datos puede contener una instancia completa de los distintos subsistemas de gestión y control, para que haya redundancia. Cada centro de datos contiene un búnker asociado, etiquetado respectivamente como "búnker1" y "búnker2". Cada búnker tiene un certificado con una cadena de certificados cuya raíz está en una autoridad conocida. Los certificados de los dos búnkeres son diferentes entre sí.

Cada uno de los nodos de la red de control, por ejemplo, los puntos de acceso 32 y los nodos del punto final 26, tiene la capacidad de almacenar e instalar una lista de revocación de certificados. Los puntos de acceso 32 también tienen la capacidad de filtrar las direcciones de origen.

Se describirá una operación ejemplar para una situación en la que el acceso al búnker1 ha sido comprometido. Se activa un botón de pánico asociado al búnker1, y la señal de pánico resultante se envía a un servidor en el búnker2 que implementa la función del botón de pánico. Esta señal de pánico incluye una indicación adecuada de la autentificación del dispositivo desde el que se envía. Por ejemplo, puede incluir una firma asociada al dispositivo, o ir acompañada de un valor hash generado según un algoritmo predeterminado. Al recibir una señal de pánico autentificada, el servidor en el búnker 2 emite comandos para configurar una regla de cortafuegos para todos los puntos de acceso 32, que les ordena descartar los paquetes que se originan en el centro de datos 70. El servidor en el búnker2 también emite comandos para configurar una lista de revocación de certificados en todos los puntos de acceso, lo que indica que el certificado asociado al búnker1 ya no es válido. El servidor en el búnker2 también envía un mensaje a cada nodo final, indicándole que recargue su lista de revocación de certificados desde un punto de acceso.

Configurando el filtro del cortafuegos en el punto de acceso para descartar los paquetes del centro de datos 70, un posible atacante puede ser ralentizado un periodo de tiempo suficiente para permitir que las listas de revocación de certificados se propaguen a todos los nodos de los puntos finales. Para recuperar el búnker después de que se haya producido una posible brecha, hay que instalar un nuevo certificado, y se hacen nuevas asociaciones con ese certificado que se propagan a todos los nodos de la red de control.

En resumen, la presente divulgación proporciona una variedad de características de seguridad para reducir el riesgo de acciones maliciosas o inapropiadas asociadas con la entrega de productos básicos proporcionados por los servicios públicos. Las órdenes críticas que tienen el potencial de perturbar la estabilidad de una red de distribución de servicios públicos están aseguradas mediante el mecanismo de un búnker físico que limita el acceso a los componentes sensibles del sistema de gestión del back office, junto con el uso de un módulo de seguridad de hardware para autenticar, firmar y cifrar dichas órdenes. Un marco de autorización basado en permisos proporciona un nivel de seguridad más fino para órdenes especialmente críticas. El módulo de seguridad de hardware también puede configurarse para limitar la tasa de ejecución de las órdenes, para impedir aún más los intentos de emitir secuencias de órdenes inadecuadas.

Se apreciará por los expertos en la materia que los conceptos divulgados pueden ser incorporados en otras formas específicas sin apartarse del espíritu o características esenciales de los mismos. Las formas de realización y los ejemplos ilustrativos divulgados actualmente se consideran en todos los aspectos ilustrativos y no restrictivos. El alcance de la invención a la que se refiere esta patente europea se indica en las reivindicaciones adjuntas, más que en la descripción anterior.

Claims

REIVINDICACIONES

1. Un procedimiento de operación de una red que tiene una pluralidad de puntos finales (26) que se comunican con un primer centro de datos (70) y un segundo centro de datos (72) a través de puntos de acceso (AP), en el que el primer centro de datos (70) incluye un primer entorno físicamente seguro que tiene un primer certificado, y el segundo centro de datos (72) incluye un segundo entorno físicamente seguro que tiene un segundo certificado, comprendiendo el procedimiento:

recibir, por parte del segundo entorno físicamente seguro, una indicación de que la seguridad del primer entorno seguro ha sido comprometida; y

en respuesta a la recepción de la indicación,

emitir, por el segundo entorno físicamente seguro, una orden a los puntos de acceso para configurar una lista de revocación de certificados que indique que el certificado asociado al primer entorno físicamente seguro no es válido; y

emitir, por parte del segundo entorno físicamente seguro, una orden a los nodos de los puntos finales para que carguen la lista de revocación de certificados desde cualquiera de los puntos de acceso.

2. El procedimiento de la reivindicación 1, que comprende además: emitir, por parte del segundo entorno físicamente seguro, una regla de cortafuegos a los puntos de acceso, dando la regla de cortafuegos instrucciones a los puntos de acceso para que descarten los paquetes procedentes del primer entorno físicamente seguro.

3. El procedimiento de la reivindicación 1 o de la reivindicación 2, en el que la indicación incluye una firma asociada al primer centro de datos.

4. El procedimiento de la reivindicación 1 o la reivindicación 2, en el que la indicación incluye un valor hash generado según un algoritmo predeterminado.

5. El procedimiento de cualquier reivindicación anterior, en el que, en respuesta a la recepción de la indicación, se ignora cualquier solicitud de servicios de desconexión remota que esté firmada por la primera ubicación físicamente segura.

6. El procedimiento de cualquier reivindicación anterior, en el que la indicación comprende una señal de pánico.

7. El procedimiento de cualquier reivindicación anterior, en el que el segundo centro de datos contiene una instancia completa de los sistemas de gestión y control contenidos en el primer centro de datos.

8. El procedimiento de cualquier reivindicación anterior, en el que el primer certificado es diferente del segundo certificado.

9. Una red de control que tiene una pluralidad de puntos finales (26) que se comunican con un primer centro de datos (70) y un segundo centro de datos (72) a través de puntos de acceso (AP), en el que un sistema de gestión y control de servicios públicos se encuentra dentro del primer y segundo centro de datos, en el que el primer centro de datos incluye un primer entorno físicamente seguro que tiene un primer certificado, y el segundo centro de datos incluye un segundo entorno físicamente seguro que tiene un segundo certificado;

en la que el primer entorno físicamente seguro está configurado, en respuesta a que la seguridad del primer entorno físicamente seguro se vea comprometida, para enviar una señal de pánico al segundo entorno físicamente seguro;

en la que el segundo entorno físicamente seguro está configurado para emitir una orden a los puntos de acceso para configurar una lista de revocación de certificados que indique que el certificado asociado al primer entorno físicamente seguro no es válido; y

en la que el segundo entorno físicamente seguro está configurado para emitir una orden a los nodos de los puntos finales para que carguen la lista de revocación de certificados desde cualquiera de los puntos de acceso.

10. La red de control de la reivindicación 9, en la que el segundo entorno físicamente seguro está configurado además para emitir una regla de cortafuegos a los puntos de acceso, dando la regla de cortafuegos instrucciones a los puntos de acceso para que descarten los paquetes procedentes del primer entorno físicamente seguro.

11. La red de control de la reivindicación 9 o la reivindicación 10, en la que la señal de pánico incluye una firma asociada al primer centro de datos.

12. La red de control de la reivindicación 9 o la reivindicación 10, en la que la indicación incluye un valor hash generado según un algoritmo predeterminado.

13. La red de control de cualquiera de las reivindicaciones 9 a 12, configurada además, en respuesta al envío de la señal de pánico, para ignorar cualquier solicitud de servicios de desconexión remota que esté firmada por la primera ubicación físicamente segura.

14. La red de control de cualquiera de las reivindicaciones 9 a 13, en la que cada uno del primer y segundo centros de datos contiene una instancia completa del sistema de gestión y control de servicios públicos.

15. La red de control de cualquiera de las reivindicaciones 9 a 14, en la que el primer certificado es diferente del segundo certificado.