Eforcers S.A.

En Eforcers ya tenemos cerca de 3 años de experiencia en implementaciones de Google Apps por toda Colombia, hemos pasado por empresas pequeñas hasta empresas muy grandes en una gran variedad de industrias. También hemos tenido la oportunidad de trabajar con diferentes perfiles de departamentos de TI y de usuarios finales de la plataforma. A lo largo de todo este tiempo hemos ejecutado las dos grandes estrategias en implementación de Google Apps: despliegue Big Bang y despliegue por fases. Podemos decir muy seguros y sin dudar un segundo que, sin importar el tamaño de la organización ni la plataforma de correo anterior, Big Bang suele ser la mejor opción.

¿Qué es un despliegue por fases?
Un despliegue por fases consiste en el cambio de plataforma por grupos de usuarios, usualmente se hace por área o subárea operativa, en otros casos se aplica por cada piso del edificio, sucursal regional u otras. Los grupos son lo suficientemente manejables como para realizar la migración, la capacitación, la configuración y la entrega de cuentas a todo el grupo de manera muy personalizada, antes de poder continuar con el siguiente grupo. Preferiblemente cada grupo tarda alrededor de una semana. Para empresas grandes esta estrategia puede tomar a la implementación varios meses.

¿Qué es un despliegue Big Bang?
Un despliegue Big Bang implica un cambio drástico y contundente de la plataforma en la gran mayoría de usuarios de la organización, lo que coloquialmente se conoce como "de un día para otro". El proceso de cambio toma mucho menos tiempo, pero necesariamente supone una pérdida en la personalización de la entrega y una transferencia de responsabilidad a los usuarios.



Y el Ganador es...
Precisamente, la principal ventaja de un despliegue por fases es el control que siente tener el departamento de TI sobre el cambio en cada grupo, también el tiempo que puede dedicar para la personalización y la entrega para cada usuario. En teoría el depliegue por fases no suena nada mal, pero hemos identificado varias desventajas que opacan de lejos las ventajas recién mencionadas, las mencionamos una a una a continuación:

Primero, la duración o tiempo total del proyecto de implementación suele causar insatisfacción en altos mandos, ya que el equipo de TI es necesario para otros proyectos, igualmente el proyecto tiende a perder impacto positivo por su larga duración. Segundo y principal problema, se tienen dos plataformas diferentes al mismo tiempo. Esto puede significar, estar pagando doble en licenciamiento, así mismo el equipo de mesa de ayuda debe dar soporte a dos plataformas diferentes simultáneamente. En el ámbito de coexistencia, aunque existan herramientas, muchas de éstas no abarcan el 100% de las funcionalidades disponibles y requieren gran esfuerzo en instalación y configuración que en última instancia va a ser desechados cuando finalice la implementación. Por último y como conclusión: el proyecto sale mucho más costoso y es mucho más desgastante, tanto para la empresa implementada como para el partner implementador.

Sin embargo el sólo hecho de definir que la estrategia que se va a llegar a cabo sea Big Bang no es suficiente y el peor error que se puede cometer en un despliegue grande o pequeño es cambiar una plataforma tecnológica de un día para otro para todos los usuarios sin que ellos sepan. Es por esto que se recomienda tener a consideración los siguientes factores para hacer que el depliegue Big Bang sea exitoso:

• Limitar el alcance del cambio. Tanto en término de aplicaciones a incluir como de datos a ser migrados. Para simplificar, entre menos se migre y menos se abarque inicialmente mejor. Siempre está la opción de ir cubriendo progresivamente el resto de aplicaciones o ir migrando el resto de datos.
• Planeación. Hacer una excelente planeación y seguimiento del proyecto. Esto implica definir (y respetar) cuidadosamente las fechas del cambio y de las comunicaciones, conocer al detalle qué hay que llevar a cabo, cuál es el alcance del proyecto, cuáles son los distintos perfiles de los usuarios.
• Comunicación. Hacer entender a los usuarios los motivos del cambio y los beneficios que traerá, comunicar las fechas exactas y dar instrucciones de qué hacer, comunicar acerca de recursos disponibles que le pueden ayudar a hacer más fácil la transición.
• Entrenamiento. Ofreces distintas opciones de capacitación a los usuarios como auto-guiada con manuales y documentación, presencial liderada por un instructor, webinar o incluso uno a uno bajo demanda. 
• Soporte. No sólo mediante los mecanismos tradicionales de mesa de ayuda sino con líderes voluntarios que se postulen a ayudar a sus compañeros, también son válidas la realización de sesiones grupales de preguntas y respuestas, foros, encuestas, entre otras.

Por último vale la pena mencionar que la gran mayoría de los más grandes casos de éxito a nivel mundial fueron implementados siguiendo una estrategia de Big Bang, el mismo equipo de despligue de Google lo confirma.

Espero que después de esto, si aún no ha hecho el cambio a Google Apps, lo haga en Big Bang ya sabe que en Eforcers estamos para ayudarlo. Si ya lo hizo, déjenos saber cómo le fue en los comentarios.

En Eforcers creemos que es muy importante haber participado del evento más grande de Google, no solo por ser Resellers autorizados de Google Apps para Colombia sino sobre todo por ser aliados y estar alineados con su visión. Es la tercera oportunidad en que lo hacemos, desde su inicio con Google I/O 2008.

Ésta, a diferencia de los dos anteriores versiones, fue una conferencia muy enfocada en desarrolladores empresariales, demostrando que es tal vez una de las áreas en las que Google está invirtiendo más fuertemente y espera crecer significativamente en el futuro cercano. Muchas de las sesiones se centraron en las tecnologías que se utilizan en el Google Apps Marketplace como OpenID y OAuth, otras en uso efectivo de APIs como DocumentList, Sites o Gadgets y Robots de Wave aplicados a entornos empresariales mostrando las posibilidades de hasta donde se puede llegar.

Sin duda el anuncio más importante para nosotros fue Google App Engine for Business, ya que brinda a las empresas mayor confianza con una versión más robusta de la plataforma y con características como:
SLA, la mejor forma de garantizar la confiabilidad del servicio es estar dispuesto a devolver dinero si las cosas por algun motivo no salen bien.
Soporte preferencial, asumo que basado en tickets. Aunque en los foros del App Engine normal el soporte de la comunidad haya sido grandioso, no hay ninguna garantía de una respuesta satisfactoria o la calidad puede no ser la mejor. Esa era una preocupación muy válida en las empresas hasta ahora.
Políticas de seguridad y control de acceso basado en roles. Una capa extra de seguridad que hacía falta y es muy útil para compartir información recolectada del uso de la aplicación sin necesidad de dar acceso a todo.
Persistencia con bases de datos relacionales (SQL). Hay que reconocer que muchas de las aplicaciones empresariales actuales tienen una base de datos relacional como back-end y el costo de hacer la conversión a BigTable simplemente no se justificaría. El licenciamiento va a ser similar al de Google Apps pagando USD 8 por usuario por mes sólo para usuarios que utilicen las aplicaciones, quotas de uso ilimitadas.

Otro gran anuncio, fue la liberación de Google Wave para dominios Google Apps, trayendo la herramienta más efectiva y novedosa en colaboración en tiempo real a los equipos de trabajo en empresas de todos los tamaños. Nosotros como Resellers de Google Apps en Colombia, ahora tenemos el reto de no solo capacitar a nuestros clientes sino de mostrar las mejores prácticas y mostrar como sacar el mayor provecho de la herramienta, eso nos emociona mucho.

Google Docs no fue la excepción en anuncios importantes, fue liberada la conectividad JDBC desde Google Apps Script, esto significa que desde los scripts es ahora posible acceder a bases de datos relacionales mediante el conector JDBC. Por otro lado y algo indirectamente, la iniciativa de Google Web Fonts va a traer continuo mejoramiento al editor y aumentará la fidelidad de documentos importados de otros editores tradicionales de publicación.

Por último, pero no menos importante, fue liberada oficialmente la integración con gadgets contextuales de Gmail, anunciada previamente en Campfire One. Éstos dan la posibilidad a productos instalados desde el Google Apps Marketplace de mostrar información relevante al interior del mismo mensaje de correo, permitiendo al usuario tomar acción sin necesidad de dejar en ningún momento su intefaz de Gmail.

Los que estén interesados en mi punto de vista en los anuncios y reseñas de sesiones en todas las demás áreas fuera de Enterprise, pueden dar un vistazo a mi blog personal, donde entro en más detalle en algunos de ellos.

Actualización: En la parte inferior incluímos algunas fotografías del evento

Muchos de nuestros prospectos suelen tener una pregunta en común en la fase de preventas: cuáles son los límites de Google Apps? ya sea en términos de almacenamiento, de uso, de nombramiento, de cantidad, de alcance, entre otros. Aunque Google ha demostrado que su infraestructura es una de las más escalables del mundo y que el costo de almacenamiento digital va en picada, todavía algunos recursos son limitados o simplemente ellos ponen salvaguardas y restricciones para evitar abusos del sistema. De todos modos, después de ver las grandes cuotas que ofrece Google comparadas con la competencia, Google sigue siendo líder y la mejor alternativa para pequeñas y grandes empresas.

Nosotros hace algún tiempo compilamos y centralizamos esta información para cada uno de los diferentes servicios en un documento (obviamente en Google Docs) que hemos tratado de tener actualizado como recurso de ventas. Hoy publicamos esta información para una mayor difusión y comprensión acerca de las herramientas, esperamos sea de su utilidad.

La totalidad de esta información es pública y fue tomada de la documentación de Google, de los centros de ayuda o de foros oficiales. Como siempre ocurre con Google, en cualquier momento los valores allí mencionados pueden ser aumentados, disminuídos o removidos, nosotros haremos nuestro mejor esfuerzo por tener la información actualizada.

Todavía tienes preguntas? Contáctenos para una presentación, solicitenos asesoría gratuíta o escriba a comercial@eforcers.com

Para todos es conocido que la gran mayoría de mensajes de correo electrónico NO solicitado utiliza la práctica de falsificación de identidad, tanto usando el dominio como en muchos casos el nombre del emisor. Por esto es que a menudo recibimos mensajes con contenido de dudosa reputación que proviene de nuestras propias cuenta y por supuesto no hemos enviado, o de fuentes cercanas y conocidas. Todo tipo de Spam, Phising, virus, estafas y fraudes, entre otros, utilizan dominios y cuentas conocidas para lograr sus oscuros propósitos.

El problema real consiste en que el correo electrónico con este tipo de prácticas ve amenazada su efectividad y confiabilidad como medio de comunicación, además y aún más grave, nosotros como usuarios y empresas perdemos credibilidad en nuestros nombres y marcas.

Un primer intento, vigente hasta hoy, consiste en mantener listas negras con las direcciones IP de los servidores que envían este tipo de comunicaciones, el problema de este enfoque consiste en que los Spammers son muy hábiles y rara vez utilizan la misma dirección IP estática, claro a menos que sea un virus que utilice el servidor de otro, y esto hace que sea muy costoso el mantenimiento de estas listas.

Una vez, nosotros como usuarios, caemos en las trampa de los Spammers y somos reportados en las listas negras, empieza el camino de la negación de responsabilidades y de recuperación de nuestra reputación. Lo primero con que nos estrellamos es que no hay una sola fuente de la verdad, sino cientos de listas negras que no cuentan con información actualizada ni sincronizada y al tratar de salir de ellas notamos que tampoco hay un procedimiento estándar, sino que éste varía dependiendo de cada proveedor. En conclusión este tipo de soluciones NO escala.

SPF y Cómo Funciona?

SPF (Secure Policy Framework) es una especificación (RFC 4408) que pretende ser el comienzo del fin de este tipo de prácticas. La estrategia para lograrlo consiste en definir que servidores están autorizados para enviar correo electrónico a nombre de un dominio específico. Es un

Para entender mejor cómo funciona, a continuación se presenta un diagrama muy simplificado de las partes de un correo electrónico:

Análogo a un mensaje de correo real el correo electrónico cuenta con una envoltura o sobre (envelope) que tiene el objetivo de enrutar el mensaje al lugar de destino sin importar que contenido lleva adentro. Ésta envoltura tiene la siguiente información: emisor, receptor y servidor que hace el envío. Es ahí donde está el poder de los registros SPF ya que el servidor de correo del destinatario, al recibir un correo, verifica que el servidor del emisor está autorizado a enviar correos electrónico a nombre del dominio haciendo una simple consulta directamente al DNS, sin necesidad de transmitir el contenidos en sí del mensaje, ni encabezados ni cuerpo.

Expandiendo un poco más en la configuración necesaria del lado del DNS consiste en la creación de un registro TXT común y corriente, donde se definen los servidores autorizados por medio de políticas, entendidas cómo registros A, MX, PTR, direcciones IP o también es posible incluir una lista de políticas definidas en otro dominio, con el parametro "include". En el sitio de SPF hay un asistente que ayuda a configurar los registros paso a paso.

Por el lado del servidor de correo que es responsable de hacer la verificación, muchos de los productos disponibles en el mercado de servidores de correo, MTAs y hasta clientes de escritorio, tanto de código abierto como comerciales, tienen módulos ya desarrollados o soporte nativo a la especificación.

En resumen se requieren dos partes para que la estrategia de SPF sea efectiva:
1. Que los emisores de correo saliente publiquen en su servidor DNS los servidores autorizados para el envío de correos en un registro TXT
2. Que los servidores de correo entrante hagan la verificación de las envolturas comparando contra el DNS

Ventajas

• Es un estándar abierto, es decir, no hay patentes ni nadie que sea el "dueño" como tal de la especificación.
• Se basa en tecnologías, protocolos y estándares existentes. No requiere ninguna modificación en la arquitectura ni del e-mail ni de la Web.
  
• Es muy fácil de implementar. También puede ser muy rápido, depende de la propagación de los servidores DNS.
• Ahorra ancho de banda al no tener que transmitir encabezados y contenido, al hacer la verificación con la envoltura.
• Altamente desplegado comparado con otros mecanismos similares. Ver sitio oficial de SPF para estadísticas. Sin embargo, todavía está en una fase muy temprana y sólo una fracción pequeña de los dominios declaran sus registros SPF, incluso en empresas "Fortune 500" según un estudio realizado.
  
• Poco riesgoso, en caso de haber algún error el mensaje de rebote por lo general incluye detalles específicos del error y existe una gran variedad de herramientas para verificar, las cuales se mencionan a continuación.
  

Herramientas Auxiliares

Verificar los registros SPF es igual de fácil que verificar cualquier otra entrada del DNS. Tal vez la herramienta más tradicional (pero ya en declive) es el comando nslookup, donde con simplemente digitar set type=txt y luego el dominio podemos obtener los registros SPF declarados, alternativamente se puede usar el comando dig en la misma manera. Igualmente hay varias herramientas Web disponibles como MxToolbox y Who.is, estas herramientas son excelentes porque hacen las consultas al NameServer directamente, por lo cual no se depende de la replicación del DNS. Por último y tal vez la herramienta más importante es por el mismo medio de un correo electrónico, enviando un mensaje de prueba a check-auth@verifier.port25.com o a spf-test@openspf.org se obtiene de vuelta un reporte detallado no sólo de SPF sino de otros mecanismos de autenticación.

Interrogantes

Existen todavía algunos puntos pendientes por resolver para SPF, en específico el mayor obstáculo que ha enfrentado consiste en el manejo al correo redirigido (forwards), ya que estos mensajes son entregados por un servidor diferente en nombre de un dominio diferente, esto genera falsos positivos. Por ejemplo en el diagrama a continuación supongamos que dominio.com tiene publicados sus registros SPF correctamente, cuando envía correos directamente a gmail.com la validación SPF pasa. Ahora, si dominio.com envía correos a un cuenta en hotmail.com donde se redirecciona a gmail.com la validación SPF va a fallar.

Alternativas y Complementos

Los promotores de SPF hacen enfasis en que la especificación no pretende ser la solución holítica al problema sino simplemente es una parte más. Inclusive admiten que a la fecha está en una versión temprana y que en el futuro las políticas disponibles van a ser mucho más precisas, robustas y posiblemente van a poder ser complementables con otros mecanismos.

El ecosistema de soluciones alternativas se clasifica en protocolos de autenticación de emisor y protocolos de autenticación de contenido. Por el lado de autenticación de emisor se destaca SenderId (de Microsoft) y por el lado de autenticación de contenido se destacan las soluciones que utilizan certificados y llaves públicas y privadas como PGP y DKIM.

Conclusión

Recomiendo publicar los registros SPF si somos responsables del dominio y verificarlos si somos responsables del servidor de correo. Es nuestro granito de arena para volver a hacer del correo electrónico un medio de comunicación confiable y de paso nos ayuda a estar más tranquilos respecto a la reputación de nuestros nombres, empresas y marcas.

A continuación les comparto los slides de mi presentación.