Hable acerca de Big Data y no pasará mucho tiempo para que Hadoop esté presente en la conversación. El software de código abierto de Apache se utiliza para organizar clusters de computadoras genéricas para procesar información de montañas de datos.
Aunque Hadoop existe desde hace tiempo -fue creado en el 2005 por Doug Cutting y Mike Cafarella y recibió el nombre de un elefante de juguete-, está empezando a ganar interés. De acuerdo con un informe realizado por el Transparency Market Research, el mercado de Hadoop estará creciendo a una tasa compuesta de crecimiento anual de 54,7% en los próximos seis años, a 20,9 mil millones de dólares en el 2018 de 1,5 mil millones de dólares en el 2012.
Para alcanzar ese crecimiento, sin embargo, Hadoop va a tener que hacer algunos avances en el mercado empresarial; y para ello tendrá que hacer frente a sus deficiencias de seguridad. “Es evidente que estamos en un punto de inflexión en donde una gran cantidad de organizaciones están empezando a ponerlo en producción, pero más bien quieren ampliar su uso”, señala Clarke Patterson, director senior de marketing de producto en Cloudera, un fabricante de una distro Hadoop.
“Ellos quieren almacenar mucho más datos y hacer mucho más con ellos”, continuó. “Si lo hacen, entonces la seguridad se eleva rápidamente a la cima de sus preocupaciones. Esto es importante para impulsar Hadoop al quehacer principal de la empresa”.
Al igual que con muchas de las tecnologías incipientes, la seguridad no estaba en los primeros lugares de la lista de prioridades para los creadores de Hadoop. “No fue diseñada teniendo en mente la seguridad”, anota Jim Vogt, director ejecutivo y presidente de Zettaset, un fabricante de software de gestión de clúster Hadoop. “Tuvo sus raíces en Yahoo y Google, así que era mucho más acerca de dar sentido a los datos no estructurados que acerca de proporcionar seguridad”.
Estos datos pueden ser un objetivo tentador para los hackers, ya que hay mucho en ellos. “Cuantos más datos se tiene, se carga un objetivo más grande en la espalda”, comenta Dodi Glenn, director senior de inteligencia de seguridad y de laboratorios de investigación en ThreatTrack, una compañía de detección avanzada y remediación de amenazas.
Aunque la comunidad Hadoop es rápida para tapar las fallas de seguridad en el código del software, ha sido menos rápida en la adición de características de seguridad como el control de acceso de archivos, la autenticación y el cifrado de datos que son necesarios para que el programa esté listo para el prime time en la empresa.
“HBase es uno de los mejores proyectos de calidad que escaneamos”, anota Zack Samocha, director senior de productos y SaaS en Coverty, la cual proporciona escaneos de código para identificar fallas de seguridad. HBase es el software de base de datos utilizado por Hadoop.
“Apache Hadoop es un proyecto muy activo”, agrega. “Su comunidad está muy comprometida”. Por ejemplo, la comunidad se ha ocupado de 220 fallas de seguridad en HBase descubiertas por las exploraciones Coverity.
Mientras que la comunidad de código abierto trabaja en la adición de características de seguridad para Hadoop, proveedores como Zettaset, MapR y Cloudera ahora están trayendo esas características al software. “Ha tomado un tiempo a la comunidad eliminar esas cosas”, anota Vogt de Zettaset. “Estamos cerca de 18 meses delante de los proyectos que se están trabajando en la comunidad”.
Una de las características de seguridad que las empresas desean ver en Hadoop es el control de acceso a los archivos. Quieren el poder de determinar quién puede ver qué, con base en criterios determinados por la organización. “Eso es algo que ha hecho falta en el código abierto de Hadoop”, explicó Christian.
El software de Zettaset está diseñado para trabajar en las distros importantes de Hadoop, como aquellas de Cloudera y Horntonworks, y para aprovechar los recursos existentes -el Active Directory, por ejemplo, o el LDAP server- para sus políticas de acceso. “La gente ya ha creado esas políticas así que nos parece tonto recrear algo que ya existe”, explica Christian.
Eso puede ser así, pero hay otros que creen que los controles de acceso necesitan ser redefinidos y enterrados más profundamente en la pila de Hadoop. “Debe reforzar el acceso a archivos al nivel más bajo de la arquitectura”, señala Tomer Shiran, vicepresidente de gestión de producto de MapR, que también tiene una distribución de Hadoop.
“No se puede hacer el control de acceso más arriba en la pila, porque si se restringe a alguien en un nivel superior y todavía tiene acceso a un nivel inferior, no se ha asegurado nada”, explica. “Es como bloquear la puerta principal y dejar abiertas la trasera y las ventanas”.
Las organizaciones no solo quieren controlar quién tiene acceso a qué en Hadoop, también quieren asegurarse de que alguien es quien dice ser. Una forma de hacer esto es a través de Kerberos, una tecnología de autenticación ampliamente utilizada. Aunque algunos fabricantes de distros soportan Kerberos, también están poniendo sus propios arreglos en la autenticación. “Un montón de nuestros clientes no desean correr Kerberos”, señala Shiran. “Es demasiado complejo. Es una pesadilla operativa“.
Sin un medio para la autenticación segura, continúa, las organizaciones estaban renunciando a almacenar información confidencial en Hadoop. “Eso les estaba limitando los posibles casos de uso”, anota. “Cuando no tiene seguridad, Hadoop es todavía útil, pero limita lo que puede hacer con él”.
Para hacer frente a ese problema, MapR incluye un esquema de autenticación nativa como una alternativa a Kerberos en su distro de Hadoop. Al igual que SSH, el sistema combina Active Directory o la consulta LDAP con los certificados y los nombres de usuario y contraseñas para autenticar a los usuarios de un modo seguro, pero sencillo.
En lugar de ofrecer una alternativa a Kerberos, Zettaset optó por simplificar la instalación del software de autenticación. “Podemos configurar Kerberos con un par de clics del mouse”, sostiene Vogt. “Tenemos un documento de 115 páginas con una distro y un segmento de una hora de duración de un curso de entrenamiento”, comenta.
El cifrado es otra característica que las empresas quieren ver en Hadoop antes de confiarle los datos confidenciales. Por ejemplo, MapR encripta todos los datos en tránsito de los clientes a un clúster Hadoop, dentro de los nodos del clúster en sí y entre los grupos, incluidos los datos que se envían a los sistemas de recuperación de desastres.
Otras distribuciones, como Cloudera y programas de software como Zettaset, también cifran los datos que se asienta en el clúster Hadoop, o que están en reposo. Cloudera va un paso más allá y cifra todos los metadatos en el clúster -datos que forma parte de la agrupación, pero no forman parte del sistema de archivos Hadoop, como el metastore Hbase.
El esquema de cifrado de Cloudera también aborda las preocupaciones que una organización puede tener sobre el cifrado de “fraccionando” sus aplicaciones. “Es transparente en la encriptación de datos en reposo”, explica el director de gestión de producto de Cloudera,
Sam Heywood. “No requiere ninguna modificación a las aplicaciones”. Las aplicaciones acceden al sistema de archivos como lo hacen normalmente, pero los datos cifrados en el disco se convierten en cleartext antes de que se alimente a las aplicaciones.
Dado que cleartext plantea un riesgo para la seguridad, Cloudera también incluye un conjunto de controles de acceso para los procesos. “Hay una lista finita de los procesos que tienen permiso para acceder a los datos en cleartext“, señala Heywood, ex vicepresidente de marketing de Gazzang, que fue comprado recientemente por Cloudera. “Cualquier proceso que no esté en esa lista no podrá acceder a los datos de ninguna manera -incluso si es un comando root o pseudo-emitido”.
A medida que la comunidad de código abierto y los desarrolladores le dan a Hadoop los elementos de seguridad necesarios para un uso más amplio dentro de la empresa, Patterson de Cloudera advierte acerca de un desarrollo que podría perjudicar las perspectivas de la tecnología en el mercado. Explicó que hay una serie de cargas de trabajo que entran en el conjunto de datos -las cargas de trabajo de proceso por lotes, SQL en Hadoop, aprendizaje automático y otros. “Hay un riesgo de que cada una de las cargas de trabajo vaya a terminar con su propio enfoque de seguridad”, señala.
“Lo que estamos tratando de hacer”, continúa, “es eliminar ese tipo de fragmentación y llevar seguridad al núcleo de la distribución, para que pueda ser administrado en una sola forma unificada”.
John P. Mello Jr., CSO (EE.UU.)
