Llegamos a ustedes gracias a:



Columnas de opinión

¿Qué tan seguro son los proveedores Cloud? Segunda parte

Por: David Taber, CEO de SalesLogistix

[21/02/2011] La semana pasada, exploramos los Siete fundamentos de la seguridad de los proveedores de cloud computing, incluyendo la identidad, autenticación, encriptación, ILP DLP / y rastros de auditoría. Ahora aquí viene la inmersión profunda: Control de acceso.

Dependiendo de lo que su aplicación cloud está haciendo, habrá varios niveles de control de acceso. El más simple es a nivel de archivo: El sistema operativo hará cumplir la secuencia usuario / grupo / listas de control de acceso, a cada archivo en el sistema. Una vez que un proceso remoto ha autenticado sus credenciales, el sistema operativo hará cumplir adecuadamente los privilegios C / R / U / D de acuerdo a la función del usuario o perfil. La mayoría de sistemas operativos refuerzan también el control de acceso en los procesos y los objetos del sistema. Esta gestión granular de acceso es básico y bastante uniforme a través de los sistemas cloud -no hay mucho por descubrir.
De manera similar, los sistemas DBMS serán bastante uniformes en la forma en que refuerzan la seguridad a través de las nubes. Todos los sistemas de seguridad DBMS ofrecen al menos refuerzo a nivel de la tabla de control de acceso, y la mayoría ofrece también restricciones a nivel de columna. Además, el DBMS hará cumplir bloqueos a nivel de transacción para manejar la contención y prevenir la corrupción de datos. La nube en realidad no cambia mucho aquí, así que no hay mucho desafío en este nivel.
Las cosas se ponen mucho más interesantes a nivel de aplicación, ya que los proveedores de aplicaciones cloud han tenido que poner mucho más trabajo en sus mecanismos de control de acceso desde el principio. Aquí es donde una parte del trabajo real de clientes que utilizan múltiples proveedores se ha llevado a cabo. Pero los modelos reforzados de control de acceso tienden a ser muy diferentes a través de las diferentes categorías de aplicaciones cloud, así como entre los proveedores específicos. Por ejemplo, los detalles de acceso y partición de datos son completamente diferentes en una red social que en un sistema de contabilidad, un motor de comercio electrónico, un sistema ERP, o un sistema de CRM. Aquí es donde encontrará el desafío de control de acceso cuando se trata de integrar los datos a través de otras nubes.
Para poner ejemplos claros voy a estar usando características de Salesforce.com. Por favor, no interprete esto como publicidad para ellos -es solo que son un objetivo común para la integración entre las nubes y entiendo mejor su modelo de seguridad.
El control de acceso de Salesforce.com se define y aplica a través de una serie de filtros que son increíblemente simples. Los filtros se aplican a cada uno de los grupos o clases de cuentas de usuario:
* Los perfiles definen si cierta clase de usuarios pueden ver una tabla, un objeto o un área de funcionalidad
* Los perfiles definen si cierta clase de usuarios pueden ver una columna de la tabla (atributo de objeto)
* Los roles definen si una clase de usuarios pueden ver un registro (fila)
* Los tipos de registro definen que perfiles pueden ver las celdas individuales dentro de un registro, y se puede utilizar para restringir el acceso a casi cualquier función o tipo de objeto.
Hay algunos modificadores de estos filtros que permiten la delegación y amplían el alcance del control de super usuarios, pero la experiencia para la mayoría de los usuarios es que la aplicación de todos estos mecanismos de filtrado proporciona un nivel muy fino en el control de acceso. A veces hasta el punto de irritación. El bloqueo y filtrado pueden depender del contexto o el estado... y adaptarse en el camino a algunas de las necesidades que requiere el negocio. Así que el sistema proporciona métodos de excepción para el intercambio de datos, otorgados tanto a nivel individual o grupal.
Todo esto está dentro de una sola instancia de Salesforce: También tienen un mecanismo para unir las instancias y así las empresas puedan compartir información individual con sus socios comerciales en una instancia independiente ("org") de SFDC.
Las maravillas de la seguridad
Así que aquí está el punto: ¿alguna de sus aplicaciones en la nube utiliza este modelo de seguridad? Claro, puede haber conceptos equivalentes... pero los detalles serán diferentes para cada proveedor de la aplicación cloud. Al tratar de integrarse a través de las nubes, el objetivo es hacer cumplir estrictamente el modelo de seguridad de las aplicaciones que participan con un objeto, contexto, o transacción. Esto puede ser un verdadero reto para los desarrolladores.
La última cosa que querrá hacer será tratar de emular toda la logística de seguridad fuera de las aplicaciones. Incluso si los desarrolladores entienden el modelo exactamente (y créame, este será un punto de confusión), hay demasiadas cosas en las que se puede equivocar -tanto en la codificación y la configuración/administración en curso del modelo de seguridad.
Pero esa es la cuestión: Cuando se integran aplicaciones en la nube, la aplicación externa clásica tiene que ser capaz de acceder a los registros de (o en nombre de) una amplia gama de usuarios, o de una amplia gama de tablas (objetos).Por ejemplo, un sistema de comercio electrónico tiene que ser capaz de crear y cerrar las oportunidades en el sistema CRM para cualquier territorio de ventas.
El sistema cloud externo de comercio electrónico no tiene que hacerse pasar por el representante (en la mayoría de situaciones, no querrá que lo haga), pero necesita privilegios del CRM al más alto nivel de gestión de ventas para cerrar el trato. La respuesta en este caso es que el punto de integración de comercio electrónico utiliza credenciales que son equivalentes al correspondiente vicepresidente de ventas.
Ese ejemplo funcionó porque el sistema externo hace fundamentalmente una cosa, sin ser provocado por alguna demanda interna del sistema de CRM. ¿Qué pasa si, en cambio, el sistema externo está prestando un servicio que es confidencial, y el acceso debe ser altamente dependiente del usuario (por ejemplo, ver los registros de compensación o cheques de comisión)? En esta situación, la solicitud del servicio cloud externo no se debe hacer directamente desde el navegador del usuario (por ejemplo, hacerlo a través de un mashup o activado vía Javascript y JSON), sino que sea regulada por los mecanismos del sistema "nativo" del usuario. La nube con el modelo de seguridad más flexible debe tener acceso solo a través de la regulación del modelo más fuerte, utilizando una llamada API de la nube. En este ejemplo concreto, la solicitud del usuario para ver los datos de comisión podría llamar de la nube de CRM a la nube de la comisión, y luego trasladar los resultados a las tablas de CRM donde podrá ser aplicado el nivel adecuado de control de acceso.
En esencia, la estrategia de control de acceso debe ser pensada y resuelta de forma independiente para cada clase de integración de datos cruzados en la nube. Dicho esto, para lograr mejores pruebas, mantenimiento y fiabilidad, usted querrá lograr la mayor reutilización posible de estos mecanismos de seguridad.
Amo los estándares - Hay tantos de donde elegir
Debido a las diferencias en los modelos de control de acceso y los mecanismos a través de las nubes, proporcionar un nivel uniforme de acceso y auditoría parece ser un desafío perenne. Por desgracia, yo no veo ningún organismo de normalización que haga que este problema desaparezca - en todo caso, se puede crear una entidad para regularlo.
CIO.com
David Taber es el autor del nuevo libro de Prentice Hall, "Salesforce.com secretos del éxito" y es el CEO de SalesLogistix, una consultora certificada de Salesforce.com que se enfoca en la mejora de procesos de negocio mediante el uso de los sistemas de CRM. Los clientes de SalesLogistix están en América del Norte, Europa, Israel y la India, y David tiene más de 25 años de experiencia en alta tecnología, incluyendo 10 años en el nivel de vicepresidente o superior.