Trasladar el lenguaje Cobol al web con seguridad
Los problemas inherentes a esta práctica son infinitos
Cobol es un lenguaje sencillo y tan fácil de leer que resulta imposible ocultar programas dañinos en él. Se trata de un lenguaje para datos residentes en mainframe, que son guardados de manera segura detrás de unos controles de acceso de eficacia probada, como RACF (Resource Access Control Facility), Top Secret y ACF2. Sin embargo, actualmente todo esto está cambiando ya que las compañías están tratando de conectar electrónicamente a clientes y proveedores con su propia información almacenada en los mainframe, y, para ello, están escribiendo una codificación middleware que permitirá que algún día Cobol “hable” con el lenguaje de la Web (HTML).
No obstante, rescribir un middleware que permita que los datos de los mainframe se comuniquen con Internet entraña graves riesgos puesto que, al hacerlo, las compañías están desechando unos mecanismos de seguridad que son inherentes a los controles de acceso Cobol, que es seguro en virtud de su simplicidad. Además, lo están envolviendo en torno a lenguajes como C, C++, Perl y Java, o convirtiéndolo a estos lenguajes. Después, empujan y arrastran esos datos a un servidor de conversión CGI (Common Gateway Interface), que tiene unos sistemas operativos menos seguros.
Tomar algo que históricamente ha estado protegido y dejarlo abierto al exterior sin tener instalado un plan de seguridad, supone dejar abiertos a Internet todos esos datos. Y el problema no queda ahí, sino que tiene una doble cara: en primer lugar, las empresas están almacenando esos datos en un servidor middleware que tiene unos sistemas operativos y unos controles de acceso menos seguros; el otro problema de seguridad está en el nivel de programación middleware, puesto que mientras que comprobar si hay programas dañinos en la codificación es fácil en Cobol, los lenguajes Perl, C++ e incluso Java son excelentes para ocultar esta codificación dañina, porque son más complicados de leer.
Para asegurarse de que este nuevo programa middleware sea manejado de una forma bien definida, un director de sistemas tendrá que leer series muy complejas de símbolos, números y caracteres, ya que el sistema es muy propenso a errores.
Ese es el motivo de que no haya dos aplicaciones de cambio de sistema antiguo-a-Web que sean iguales. Ni deberá haberlas, corroboran diferentes analistas, ya que, en su opinión, las empresas que tengan motivos justificados para abrir sus sistemas antiguos a la Web deberán prever un acceso mínimo al crear su infraestructura.
Algunas organizaciones no dejan abiertas a los clientes sus aplicaciones antiguas sino que han optado por dotar de capacidad Web a muchas de ellas, de forma que pueden buscar información de clientes y acceder a formularios electrónicamente. Otras, deben atender a los requerimientos de los clientes en demanda de transacciones en vivo mediante acceso en tiempo real a sus sistemas antiguos, para no perder negocio frente a la competencia. Y también están aquellas organizaciones que ocupan una posición intermedia, que renuevan cada hora los datos antiguos en el servidor middleware, en lugar de permitir el acceso Web directo a su sistema antiguo. La primera norma de seguridad fue mantener lo más simples posible las aplicaciones. Como la seguridad mainframe tradicional no puede escalar hasta abarcar a millones de usuarios procedentes de la Web, esta es actualmente la mejor adición a gran escala a los controles de acceso y listas privilegiadas de IBM, de eficacia probada.
Un Acto de Equilibrio
Sin embargo, todavía existen compañías en las que siguen rigiendo los controles RACF mainframe de IBM. En la aplicación extranet Cobol-a-Web de una organización, los proveedores de productos acceden mediante sus navegadores a los datos.
Los proveedores que utilizan esta aplicación deben superar dos tests de autentificación, primero suministrando un certificado digital al servidor Web y después en el mainframe mismo, lo cual les concede o les deniega el acceso en base a criterios predefinidos en RACF. De cualquier forma, esto resulta bastante arduo e incómodo.
RACF sigue dominando en aquellas compañías que son conscientes de los problemas de seguridad al convertir Cobol a C++ o al envolver Cobol en C++ o en otros lenguajes más complicados. Así, además de planificar y probar cuidadosamente la codificación middleware, se añade además un nivel de prevención adicional: controles de acceso RACF.
Como esta arquitectura de autorización doble no funciona en una escala más alta, la conversión de aplicaciones antiguas-a-Web de estas compañías están limitadas a usuarios intranet corporativos, como los directores de seguros de distrito. Por otro lado, otras organizaciones no abrirán aplicaciones al público por ahora pues quieren asegurarse de que quienes están accediendo a aplicaciones antiguas desde el Web no tienen acceso al mismo tiempo a otros recursos de aplicación, tales como aplicaciones restringidas internas. Sin embargo, el lado del cliente presenta un dilema. No sólo será problemático RACF en términos de expansión o escalamiento; también lo serán los certificados ya que para ampliar una red corporativa, sería necesario emitir 20.000 certificados para autentificar a nuestros asegurados. Probablemente, se requerirían entre dos y cinco años para acomodar certificados de bajo nivel como estos.
Problemas de Escalabilidad
Algunos especialistas comenzaron hace dos años a realizar ensayos con herramientas de conversión Cobol-a-Web, y han determinado que es más seguro mantener los datos de clientes en Cobol, por lo que están experimentando con un plug-in de navegador web. Una vez que funcione este plug-in, los clientes podrán visitar el sitio Web del distribuidor y, al hacer click en el vínculo de entrada de pedidos, aparecerá un objeto Cobol real funcionando dentro del navegador. Aunque el usuario podrá incorporar sus elementos de HTML dentro del objeto, la lógica que lo soporta todo es Cobol. Sin el plug-in, el objeto no se ejecutará, y los datos no tendrán sentido.
La otra ventaja de este sistema es que el cliente no tiene contacto directo con el sistema back-end antiguo porque el objeto Cobol es transportado desde el servidor middleware (que es renovado cada hora) al navegador del cliente. Ese objeto es lo que ve el cliente. No hay datos a los que puedan acceder en el sistema antiguo, sino sólo datos en el servidor Web basados en permisos procedentes de la pantalla utilizada para conectarse al sistema.
Por lo tanto, ningún sistema que empuje datos antiguos al Web deberá entrar en actividad sin tener instalada la seguridad necesaria en la planificación y el desarrollo de la estructura de comercio electrónico misma. La gente piensa que, de repente, uno tiene que estar seguro en un entorno que es inherentemente inseguro, como la Internet pero las empresas deben saber que están perdiendo en seguridad si instalan en Internet sus aplicaciones securizadas. Si se hace, será mejor llevarlas de nuevo a líneas cedidas, donde se dispone de cierto grado de control.
No obstante, rescribir un middleware que permita que los datos de los mainframe se comuniquen con Internet entraña graves riesgos puesto que, al hacerlo, las compañías están desechando unos mecanismos de seguridad que son inherentes a los controles de acceso Cobol, que es seguro en virtud de su simplicidad. Además, lo están envolviendo en torno a lenguajes como C, C++, Perl y Java, o convirtiéndolo a estos lenguajes. Después, empujan y arrastran esos datos a un servidor de conversión CGI (Common Gateway Interface), que tiene unos sistemas operativos menos seguros.
Tomar algo que históricamente ha estado protegido y dejarlo abierto al exterior sin tener instalado un plan de seguridad, supone dejar abiertos a Internet todos esos datos. Y el problema no queda ahí, sino que tiene una doble cara: en primer lugar, las empresas están almacenando esos datos en un servidor middleware que tiene unos sistemas operativos y unos controles de acceso menos seguros; el otro problema de seguridad está en el nivel de programación middleware, puesto que mientras que comprobar si hay programas dañinos en la codificación es fácil en Cobol, los lenguajes Perl, C++ e incluso Java son excelentes para ocultar esta codificación dañina, porque son más complicados de leer.
Para asegurarse de que este nuevo programa middleware sea manejado de una forma bien definida, un director de sistemas tendrá que leer series muy complejas de símbolos, números y caracteres, ya que el sistema es muy propenso a errores.
Ese es el motivo de que no haya dos aplicaciones de cambio de sistema antiguo-a-Web que sean iguales. Ni deberá haberlas, corroboran diferentes analistas, ya que, en su opinión, las empresas que tengan motivos justificados para abrir sus sistemas antiguos a la Web deberán prever un acceso mínimo al crear su infraestructura.
Algunas organizaciones no dejan abiertas a los clientes sus aplicaciones antiguas sino que han optado por dotar de capacidad Web a muchas de ellas, de forma que pueden buscar información de clientes y acceder a formularios electrónicamente. Otras, deben atender a los requerimientos de los clientes en demanda de transacciones en vivo mediante acceso en tiempo real a sus sistemas antiguos, para no perder negocio frente a la competencia. Y también están aquellas organizaciones que ocupan una posición intermedia, que renuevan cada hora los datos antiguos en el servidor middleware, en lugar de permitir el acceso Web directo a su sistema antiguo. La primera norma de seguridad fue mantener lo más simples posible las aplicaciones. Como la seguridad mainframe tradicional no puede escalar hasta abarcar a millones de usuarios procedentes de la Web, esta es actualmente la mejor adición a gran escala a los controles de acceso y listas privilegiadas de IBM, de eficacia probada.
Un Acto de Equilibrio
Sin embargo, todavía existen compañías en las que siguen rigiendo los controles RACF mainframe de IBM. En la aplicación extranet Cobol-a-Web de una organización, los proveedores de productos acceden mediante sus navegadores a los datos.
Los proveedores que utilizan esta aplicación deben superar dos tests de autentificación, primero suministrando un certificado digital al servidor Web y después en el mainframe mismo, lo cual les concede o les deniega el acceso en base a criterios predefinidos en RACF. De cualquier forma, esto resulta bastante arduo e incómodo.
RACF sigue dominando en aquellas compañías que son conscientes de los problemas de seguridad al convertir Cobol a C++ o al envolver Cobol en C++ o en otros lenguajes más complicados. Así, además de planificar y probar cuidadosamente la codificación middleware, se añade además un nivel de prevención adicional: controles de acceso RACF.
Como esta arquitectura de autorización doble no funciona en una escala más alta, la conversión de aplicaciones antiguas-a-Web de estas compañías están limitadas a usuarios intranet corporativos, como los directores de seguros de distrito. Por otro lado, otras organizaciones no abrirán aplicaciones al público por ahora pues quieren asegurarse de que quienes están accediendo a aplicaciones antiguas desde el Web no tienen acceso al mismo tiempo a otros recursos de aplicación, tales como aplicaciones restringidas internas. Sin embargo, el lado del cliente presenta un dilema. No sólo será problemático RACF en términos de expansión o escalamiento; también lo serán los certificados ya que para ampliar una red corporativa, sería necesario emitir 20.000 certificados para autentificar a nuestros asegurados. Probablemente, se requerirían entre dos y cinco años para acomodar certificados de bajo nivel como estos.
Problemas de Escalabilidad
Algunos especialistas comenzaron hace dos años a realizar ensayos con herramientas de conversión Cobol-a-Web, y han determinado que es más seguro mantener los datos de clientes en Cobol, por lo que están experimentando con un plug-in de navegador web. Una vez que funcione este plug-in, los clientes podrán visitar el sitio Web del distribuidor y, al hacer click en el vínculo de entrada de pedidos, aparecerá un objeto Cobol real funcionando dentro del navegador. Aunque el usuario podrá incorporar sus elementos de HTML dentro del objeto, la lógica que lo soporta todo es Cobol. Sin el plug-in, el objeto no se ejecutará, y los datos no tendrán sentido.
La otra ventaja de este sistema es que el cliente no tiene contacto directo con el sistema back-end antiguo porque el objeto Cobol es transportado desde el servidor middleware (que es renovado cada hora) al navegador del cliente. Ese objeto es lo que ve el cliente. No hay datos a los que puedan acceder en el sistema antiguo, sino sólo datos en el servidor Web basados en permisos procedentes de la pantalla utilizada para conectarse al sistema.
Por lo tanto, ningún sistema que empuje datos antiguos al Web deberá entrar en actividad sin tener instalada la seguridad necesaria en la planificación y el desarrollo de la estructura de comercio electrónico misma. La gente piensa que, de repente, uno tiene que estar seguro en un entorno que es inherentemente inseguro, como la Internet pero las empresas deben saber que están perdiendo en seguridad si instalan en Internet sus aplicaciones securizadas. Si se hace, será mejor llevarlas de nuevo a líneas cedidas, donde se dispone de cierto grado de control.
