[ARTICULO] Active Directory Domain Services | Diseño de Estrategia de Grupos apropiada para el Acceso a Recursos – Parte 2/2

Last Updated on 22 agosto, 2017 by Pablo Ariel Di Loreto

Dependiendo el tamaño de la organización que administramos, el contar o no con una estrategia de grupos para asignar acceso a recursos puede convertirse algo fundamental. En términos generales, en una organización con pocos usuarios (digamos ¿20?), el asignar permisos a usuarios individuales para cada recurso que utilicen puede ser una «opción». Ahora, cuando pensamos en organizaciones de 100, 500 o 5.000 usuarios ya no resulta muy agradable este procedimiento: ¿se imaginan asignando permisos por usuario?

Aquí es donde comienza a ser importante contar con una adecuada estrategia de grupos para luego asignar accesos a los recursos. Este método nos permite ganar tiempo en la administración y, además, puede resultar un atajo en la resolución de problemas provenientes de la asignación incorrecta de permisos.

En este última entrega, veremos cuáles son las estrategias recomendadas para la asignación de permisos en un equipo local, en una organización con «single domain» y en una organización con más de un dominio / bosque. En la primera parte de este artículo hemos recorrido, a modo de recordatorio, cuáles son los grupos existentes en ambientes Microsoft Windows y sus características principales.

Introducción

Esta es la parte 2/2 de la publicación de este artículo. Para acceder a las otras partes, por favor revise las Publicaciones Relacionadas al final de la página.

Objetivo y Alcance

Como recordatorio, esta publicación tiene como objetivo:

• Conocer los tipos de grupos existentes en Windows, tanto en un ambiente local como de dominio.
• Conocer cuáles son las «buenas prácticas» relacionadas a organización de grupos por anidamiento.

En esta segunda y última entrega de la serie «Diseño de Estrategia de Grupos apropiada para el Acceso a Recursos», este documento tiene como alcance recorrer las prácticas recomendadas en la estrategia de grupos para la asignación de permisos en Windows Server en los siguientes ambientes:

• Equipo local.
• Single Forest / Single Domain.
• Single Forest / Multiple Domain.
• Multiple Forest / Multiple Domain.

La primera entrega, recordemos, ha tenido como objetivo recorrer cuáles son los grupos existentes en ambientes Microsoft Windows, y especificar sus características principales. Esta entrega se encuentra disponible a través del link al finalizar la presente página.

Desarrollo

Diseño de Estrategias de Grupo para Acceso a Recursos

Recorreremos, en detalle, la estrategia de grupos para los siguientes escenarios:

• Workgroup.
• Single Domain Forest.
• Multiple Domain Forest.
• Single Domain in Multiple Forest.

Estrategias de Grupo para Escenarios de Workgroup

Estrategia Elegida

En este caso, cuando estamos en un escenario workgroup, las cuentas están alojadas en individualmente en las computadoras. Simplemente ubicamos el usuario en el Grupo Local del equipo, el cual existe solo en dicha computadora, y se le brinda a dicho grupo los permisos para el recurso al cual accederá (el cual también está en dicha computadora). No existen más complejidades que dicha estrategia.

Nomenclatura

La nomenclatura de los grupos elegida para este escenario suele ser simple:

• Una parte puede representar el nombre del recurso al cual se brindará acceso: por ejemplo «Documentos», «Finanzas» o «RRHH».
• Otra parte puede representar el tipo de acceso que se le dará: por ejemplo «Lectura», «Read», «Escritura» o «Write».

Un ejemplo de esta nomenclatura es la siguiente:

• DocumentosRead: representa acceso de lectura a un recurso llamado «Documentos», el cual puede ser una carpeta.
• FinanzasEscritura: representa un acceso de escritura a un recurso llamado «Finanzas», el cual puede ser una carpeta.

No hay más complejidades para este escenario, el cual es el más simple de todos.

Estrategias de Grupo para Escenarios Single Domain Forest de Active Directory

Estrategia Elegida

En Escenarios Single Domain Forest, la asignación de permisos es un tanto distinta a la anterior. Para estos escenarios, se puede utilizar el acrónimo «IGDLA» para la asignación de permisos. IGDLA es el acrónimno de:

• Identities -> Cuentas de usuario o de computadora…
• Global Group -> van dentro de grupos «Global Group», que representan roles o funciones…
• Domain Local -> los cuales deben estar en grupos «Domain Local», que representan reglas de negocio…
• Access -> y éstos últimos sirven para dar «Access» (acceso) a los recursos.

IGDLA también es conocido como AGDLP, que es el acrónimo de:

• Accounts -> Las cuentas de usuario…
• Global Group -> van dentro de grupos «Global Groups»…
• Domain Local -> los cuales deben estar en grupos «Domain Local»…
• Permissions -> y estos últimos sirven para asignar «Permissions» a los recursos.

El cambio de AGDLP a IGDLA se corresponde a la definición más general del alcance de la aplicación de esta estrategia, dado que no solo se aplica a cuentas de usuario (Accounts) sino a Identidades.

La estrategia IGDLA resume la recomendación de Microsoft para la implementación de RBAC en ambientes de «Single Domain Forest» y, también (como veremos más adelante) en relaciones de confianza Cross-Forest. Esta recomendación se corresponde con el uso de los diferentes alcances explicados anteriormente, esto sería:

• Los Grupos Globales (Global Groups) deberían representar roles, porque los roles son generalmente colecciones de objetos del mismo directorio. Por ejemplo, grupos globales llamados «Contabilidad», «Administración» y «Gerencia» pueden representar quiénes forman parte del área Contabilidad, Administración y Gerencia respectivamente.
• Los Grupos de Dominio Local (Domain Local Groups) son usados principalmente para administrar permisos a recursos. Básicamente, se utilizan para administrar reglas de negocio, como por ejemplo reglas de acceso a recursos. Por ejemplo: «ACL_Contabilidad_Write» ó «ACL_Administracion_Read» puede ser usado para administrar permisos de escritura y lectura a carpetas de contabilidad y administración respectivamente.

Nomenclatura

Para este escenario, indicar el nombre del dominio sería «malgastar» caracteres que podemos utilizar para otra función. La nomenclatura de los grupos elegida para este escenario podría ser la siguiente:

• Para los Grupos Globales (Global Groups):
  • Una parte del nombre podría indicar su alcance. Por ejemplo, se podría utilizar la nomenclatura «GG» para los «Global Groups».
  • Otra parte del nombre podría indicar su nombre, propiamente dicho. Por ejemplo, «Administracion» ó «Gerencia».
  • Ejemplos de esta nomenclatura: GG_Administracion, GG_Gerencia.
• Para los Grupos Locales de Dominio (Domain Local Groups):
  • Una parte del nombre podría indicar la función para la cual es creado. Por ejemplo, se podría utilizar la nomenclatura «FILES» indicando que son grupos «Domain Local Groups» que definirán accesos a recursos de fileserver. Si, en cambio, los grupos definirán permisos de Administración (por ejemplo de servidores), se podría utilizar la nomenclatura «ADMIN».
  • Otra parte del nombre podría indicar el nombre del recurso al cual se dará acceso. Por ejemplo, «Balances», «Sueldos», «RRHH» ó «Gerencia» en el caso de estar hablando de carpetas. Si hablaramos de servidores o ambientes, podríamos utilizar «PRODUCCION», «SERVER1», etc.
  • Otra parte podría indicar el nivel de acceso: «Read», «Write», «Full», etc.
  • Ejemplos de estas nomenclaturas: «FILES_Sueldos_Read» y «FILES_RRHH_Write» para nomenclaturas de acceso a files. «ADMIN_PRODUCCION_FULL» y «ADMIN_SERVER1» para el acceso a administrar equipos o ambientes. La convención elegida se sugiere respetar en toda la implementación y muchas convenciones (depende su aplicación) pueden ser utilizadas a la vez J.

Como vemos, los nombres deberían ser lo más simples y representativos del área / sector /unidad de negocio y, también, del recurso y tipo de acceso que querramos dar acceso. Vamos a realizar, en el siguiente ítem, un escenario práctico.

Ejemplo de Aplicación

Vamos a ejemplificar esto que acabamos de ver en una aplicación para acceso a archivos. Supongamos que existe el siguiente escenario:

• Single Domain: llamado «DILUX.LOCAL».
• Las siguientes Áreas y Usuarios:
  • Administración:
    • Juan.
    • Pedro.
  • Recursos Humanos:
    • Mariana.
  • Gerencia:
    • Marcela.
    • Jorge.
    • Rodrigo.

Vamos a diseñar la estrategia de grupos para estas áreas y usuarios. Cuando hablamos de áreas o «roles» hablamos de «Global Groups». Por eso primero comencemos con los Grupos Globales que debemos crear. Vamos a respetar la nomenclatura sugerida en el punto anterior, por lo cual tendremos los siguientes 3 grupos globales que representan a nuestras áreas y sus integrantes:

• GG_Administracion:
  • Juan.
  • Pedro.
• GG_RRHH:
  • Mariana.
• GG_Gerencia:
  • Marcela.
  • Jorge.
  • Rodrigo.

Ahora, supongamos que existen los siguientes recursos compartidos (carpetas):

• Los siguientes recursos compartidos:
  • Administración:
    • Debería tener acceso de lectura y escritura «Juan», «Pedro» y «Gerencia».
  • RRHH:
    • Debería tener acceso de lectura y escritura «Mariana» y «Gerencia».
    • Debería tener acceso de solo lectura «Administracion».
  • Gerencia:
    • Sólo deberían poder ingresar con acceso de lectura y escritura «Marcela», «Jorge» y «Rodrigo».

Ahora vamos a definir los Grupos de Dominio Local que, recordemos, deberían representar permisos de bajo nivel o los derechos de usuario correspondientes a los recursos compartidos. Siguiendo con esta lógica, obtendríamos los siguientes Grupos de Dominio Local (Domain Local):

• FILES_AdminCobros_Write.
• FILES_RRHH_Write.
• FILES_RRHH_Read.
• FILES_Gerencia_Write.

En base a los requerimientos, hemos creado los grupos que representan nuestros permisos de bajo nivel. Ahora bien: ¿quién formará parte de cada uno de los Grupos de Dominio Local? Los siguientes:

• FILES_AdminCobros_Write:
  • GG_Administracion.
  • GG_Gerencia.
• FILES_RRHH_Write:
  • GG_RRHH.
  • GG_Gerencia.
• FILES_RRHH_Read:
  • GG_Administracion.
• FILES_Gerencia_Write:
  • GG_Gerencia.

Como último paso, debemos ingresar los grupos Domain Local (FILES) en las carpetas correspondientes (recursos compartidos) y asignarles los permisos que corresponden. Cuando hablamos de «asignar permisos» nos estamos refiriendo a indicar si tendrán un acceso de lectura o lectura y escritura a nivel NTFS (es decir generar los «Access Control Entires» ó ACE). Realizada esta acción, ya tenemos asignados nuestros permisos de acceso tal cual nos fue solicitado J.

Ahora bien, podemos ver rápidamente como se simplifica la administración de los permisos en base a la estrategia elegida:

• Si ingresara una nueva persona a Recursos Humanos, solo deberíamos agregarla al grupo «GG_RRHH», y por anidamiento obtendría los permisos a los cuales dicho sector está asignado.
• Si, en cambio, algún Gerente deja su cargo pero sigue perteneciendo a la empresa, solo deberíamos quitarlo del grupo «GG_Gerencia» y automáticamente dicho usuario ya no tendría más acceso a dicha información sensible.

Como vemos a través de este ejemplo, la simplificación que agrega una estrategia de grupos en un ambiente «Single Domain Forest» es muy interesante y flexible. Veremos, en el siguiente ítem, la estrategia correspondiente a ambientes «Multi Domain Forest».

Estrategias de Grupo para Escenarios Multiple Domain Forest de Active Directory

Estrategia Elegida

En Escenarios Multi Domain Forest, la asignación de permisos tiene una pequeña variación en cuanto al esquema IGDLA. Para estos escenarios, se puede utilizar el acrónimo «IGUDLA» para la asignación de permisos. IGUDLA significa lo siguiente:

• Identities -> Cuentas de usuario o de computadora del dominio «A»…
• Global Group -> van dentro de grupos «Global Group» del dominio «A», que representan roles o funciones…
• Universal Group -> éstos van dentro de «Universal Groups» del dominio «A», que pueden representar roles o funciones y/o reglas de negocio…
• Domain Local -> los cuales deben estar en grupos «Domain Local» del dominio «B», que representan las reglas de negocio o asignaciones de permisos…
• Access -> y éstos dos últimos sirven para dar «Access» (acceso) a los recursos del dominio «B».

IGUDLA también es conocido como AGUDLP, que es el acrónimo de:

• Accounts -> Las cuentas de usuario del dominio «A»…
• Global Group -> van dentro de grupos «Global Groups» del dominio «A»…
• Universal Group -> éstos van dentro de «Universal Groups» del dominio «A»…
• Domain Local -> los cuales deben estar en grupos «Domain Local» del dominio «B»…
• Permissions -> y estos últimos sirven para asignar «Permissions» a los recursos del dominio «B».

El cambio de AGUDLP a IGUDLA se corresponde, al igual que en el caso anterior, a la definición más general del alcance de la aplicación de esta estrategia, dado que no solo se aplica a cuentas de usuario (Accounts) sino a Identidades.

La estrategia IGUDLA, como nos estamos dando cuenta, aplica a más de un dominio (mínimo 2) del mismo Forest. Es muy parecida a la estrategia IGDLA, con la diferencia que se agregan los grupos Universales. Ahora bien… ¿por qué este cambio?

La respuesta es muy simple y está en el alcance de los grupos Universales. Estos grupos tienen disponibilidad completa en todo el Forest, y pueden contener dentro grupos globales y otros grupos universales. Esta característica hace que su alcance sea único, y puedan representar roles, funciones o permisos que engloban grupos de varios dominios en el Forest y pueden ser aplicados a varios dominios del Forest. Esto es esencial y permite tener un mecanismo «pivot» o integrador en el Forest que no se logra con otro tipo de grupo.

Ahora bien, supongamos la siguiente pregunta: ¿debo utilizar siempre la estrategia IGUDLA en los ambientes Multi-Domain Forest? No, no siempre es necesario. Lo debemos utilizar en un entorno Multi-Domain Forest en los casos que necesitemos que grupos de diferentes dominios tengan presencia para asignación de permisos en varios dominios del forest. En los casos donde esto no haga falta, podemos continuar utilizando la estrategia IGDLA.

En resumen, y volviendo a IGUDLA, cada grupo debería representar lo siguiente:

• Los Grupos Globales (Global Groups) se ubican en el dominio «A», el cual por definición es el dominio desde el cual se quiere acceder a recursos del otro dominio. Estos grupos deberían representar roles y/ó funciones dentro del Organigrama de la empresa (de la misma forma que la estrategia AGDLP). Por ejemplo «Contabilidad», «Administración», «Gerencia».
• Los Grupos Universales (Universal Groups) se ubican en el dominio «A. Estos grupos tienen una función más flexible y pueden representar roles/funciones y/o reglas de negocio y estarán disponibles globlamente en todo el Forest.
• Los Grupos de Dominio Local (Domain Local Groups) deberían representar las reglas de negocio a bajo nivel, o los permisos y/o los derechos de usuario para los cuales será asignado. Por ejemplo: «FILES_Contabilidad_Write» ó «ADMIN_Administracion».

Nomenclatura

La nomenclatura de los grupos elegida para este escenario podría ser la siguiente:

• Para los Grupos Globales (Global Groups):
  • Una parte del nombre podría indicar su tipo de grupo. Por ejemplo, se podría utilizar la nomenclatura «GG» para los «Global Groups».
  • Otra parte del nombre sería bueno que indique el dominio al cual pertenece. Por ejemplo: «DOMINIO1».
  • Y otra parte del nombre podría indicar su nombre, propiamente dicho. Por ejemplo, «Administracion» ó «Gerencia».
  • Ejemplos de esta nomenclatura: GG_DOMINIO1_Administracion, GG_DOMINIO2_Gerencia.
• Para los Grupos Universales (Universal Group):
  • Una parte podría representar su tipo: «U» para «Universales» por ejemplo.
  • Otra parte podría indicar su nombre, propiamente dicho, en el caso que se trate de roles o funciones: «Administracion» ó «Gerencia».
  • Si en cambio estos grupos se utilizarán para reglas de negocio, una parte indicar su función. No es del todo común, pero a veces los grupos universales se crean para asignación de permisos. En este caso, si es así, podría ser: «FILES» para indicar permisos de fileserver, o «ADMIN» para indicar permisos de administración, por ejemplo.
  • Por último, y si el grupo es utilizado para reglas de negocio, una parte podría indicar el nivel de acceso: «READ», «WRITE», etc.
  • Ejemplos de esta nomenclatura para indicar roles y funciones: «U_Administracion», ó «U_Gerencia_Latinoamerica».
  • Ejemplos de esta nomenclatura para indicar reglas de negocio: «U_AdministracionGlobal_Write» ó «U_GerenciaLatinoamerica_Read».
• Para los Grupos Locales de Dominio (Domain Local Groups):
  • Una parte del nombre podría indicar la función para la cual es creado. Por ejemplo, se podría utilizar la nomenclatura «FILES» indicando que son grupos «Domain Local Groups» que definirán accesos a recursos de fileserver. Si, en cambio, los grupos definirán permisos de Administración (por ejemplo de servidores), se podría utilizar la nomenclatura «ADMIN».
  • Otra parte del nombre podría indicar el nombre del recurso al cual se dará acceso. Por ejemplo, «Balances», «Sueldos», «RRHH» ó «Gerencia» en el caso de estar hablando de carpetas. Si hablaramos de servidores o ambientes, podríamos utilizar «PRODUCCION», «SERVER1», etc.
  • Otra parte podría indicar el nivel de acceso: «Read», «Write», «Full», etc.
  • Ejemplos de estas nomenclaturas: «FILES_Sueldos_Read» y «FILES_RRHH_Write» para nomenclaturas de acceso a files. «ADMIN_PRODUCCION_FULL» y «ADMIN_SERVER1» para el acceso a administrar equipos o ambientes. La convención elegida se sugiere respetar en toda la implementación y muchas convenciones (depende su aplicación) pueden ser utilizadas a la vez J.

Como vemos, e igual que dijimos en la estrategia IGDLA, los nombres deberían ser lo más simples y representativos del área / sector /unidad de negocio y también, del recurso y tipo de acceso que querramos dar acceso. En el caso de los grupos universales, como éstos pueden ser utilizado para varios fines, el nombre dependerá de dicho fin. Vamos a realizar, en el siguiente ítem, un escenario práctico que represente exactamente la necesidad de utilización de IGUDLA.

Ejemplo de Aplicación

Vamos a ejemplificar esto que acabamos de ver. Supongamos que existe el siguiente escenario:

• Forest: llamado «DILUX.LOCAL».
• Dominios:
  • DILUX.LOCAL (Forest Root Domain)
  • LATAM.DILUX.LOCAL.
  • EUROPE.DILUX.LOCAL.
  • AFRICA.DILUX.LOCAL.
• Cada dominio tiene su sector «Sistemas.
• Cada Dominio tiene una base de datos «Sistemas» a la cual:
  • Los usuarios del sector «Sistemas» necesitan Full Control sobre dicha base en sus propios dominios.
  • Los usuarios del sector «Sistemas» de los otros dominios necesitan acceso de Solo Lectura a dicha base.

Para resolver este inconveniente, vamos a hacer lo siguiente:

• Para cada Dominio, creamos un Global Group que represente el rol de Sistemas:
  • GG_LATAM_Sistemas -> para el dominio LATAM.DILUX.LOCAL.
  • GG_EUROPE_Sistemas -> para el dominio EUROPE.DILUX.LOCAL.
  • GG_AFRICA_Sistemas -> para el dominio AFRICA.DILUX.LOCAL.
• Para cada dominio, creamos dos Domain Local Group que representen las reglas de negocio «Full Access» y «Read»:
  • DB_Sistemas_Full -> representa la regla de negocio «Full Access» a la base de datos «Sistemas».
  • DB_Sistemas_Read -> representa la regla de negocio «Read» a la base de datos «Sistemas».
• Agregamos al Domain Local Group «DB_Sistemas_Full» de cada dominio al grupo Global Group de su propio dominio, para que cada grupo de usuarios de Sistemas tenga acceso Full Access a la base de datos de su propio dominio.
• Creamos un Universal Group:
  • U_Sistemas -> en cualquiera de los dominios o en el Forest Root Domain «DILUX.LOCAL».
• Agregamos al Universal Group «U_Sistemas» los Global Group «Sistemas» de cada dominio.
• Agregamos el Universal Group «U_Sistemas» al grupo Domain Local «DB_Sistemas_Read» de cada dominio, para que los grupos de usuarios de Sistemas de los restantes dominios tengan Acceso de Solo Lectura a la base de datos de Sistemas de los restantes dominios.

Como vemos a través de este ejemplo, requerimos la utilización de Grupos Universales para representar en un grupo de presencia global (o universal) a los grupos de diferentes dominios, y así poder aplicarlos a cualquier dominio. También podemos notar que una parte del ejemplo no utilizamos el grupo Universal como anidamiento, sino que especificamos directamente los grupos Globales a grupos Domain Local para asignación de permisos (Full Access sobre la base Sistemas para cada dominio).

Este ejemplo representa la flexibiliad que da la correcta utilización de estrategia de grupos para ambientes multi-dominio en un Forest.

Estrategias de Grupo para Escenarios de Single Domain en Multiple Forest

Estrategia Elegida

Puede existir el caso, también, en que tenemos varios Forest con un dominio cada uno, entre los cuales establecemos relaciones de confianza. Vamos a suponer, por ejemplo, que contamos con dos Bosques de Active Directory con un Dominio cada uno, y establecemos una relación de confianza entre ambos.

La estrategia elegida para este caso es la misma que para Single Domain Forest, es decir IGDLA. No existe necesidad de incluir grupos universales, dado que su scope no representa cambios en ambientes de dominio simple.

Para este caso, entonces, recomendamos revisar el siguiente gráfico y repasar en detalle el apartado que se dedicó a ambientes Single Domain Forest:

Como vemos, podríamos incluir directamente desde el Forest B (Forest al cual queremos acceder a un recurso) dentro del grupo Domain Local, integrantes de grupos Globales del Forest A.

Por supuesto, si por motivos de ordenamiento o distribución queremos generar grupos Universales intermedios en el Forest A, podemos hacerlo, tal como figura en la siguiente imagen:

Sin embargo, normalmente no se utiliza dicho esquema en ambientes de dominio simple y múltiples bosques.

Conclusiones

La utilización de una estrategia de grupos para facilitar el control de acceso mediante roles es un mecanismo utilizado a nivel global que ofrece muchísimas ventajas en la administración y confiabilidad de la infraestructura.

Como hemos visto, RBAC a través de estrategias de anidamiento de grupos no solo es aplicable a la asignación de permisos en Fileservers (que quizás sea la función más extendida en administradores juniors), sino que se extiende a todo tipo de control de acceso por roles, ya sea de administración de sistemas en general como de tecnologías varias.

El objetivo de este artículo ha sido mostrar y ejemplificar las prácticas recomendadas de estrategia de anidamiento de grupos, y dar visibilidad de las distintas opciones en base a los escenarios presentados.

Referencias y Links

• Default local groups: http://technet.microsoft.com/en-us/library/cc785098(v=ws.10).aspx
• Groups: http://technet.microsoft.com/en-us/library/cc739393(v=ws.10).aspx
• Group scopes: http://technet.microsoft.com/en-us/library/cc755692(v=ws.10).aspx
• Group types: http://technet.microsoft.com/en-us/library/cc781446(v=ws.10).aspx
• Default groups: http://technet.microsoft.com/en-us/library/cc756898(v=ws.10).aspx
• Nesting groups: http://technet.microsoft.com/en-us/library/cc776499(v=ws.10).aspx

• Acerca de
• Últimas entradas

Pablo Ariel Di Loreto

Director en TecTimes

Mi nombre es Pablo Ariel Di Loreto, nací en Mayo de 1981 y soy oriundo de la Ciudad de Berazategui, Buenos Aires, Argentina.

Mis lazos con la informática comenzaron en el año 1998, cuando tenía 16 años, y comencé a aprender como administrar servidores bajo la plataforma Microsoft (Windows Server, Exchange Server, IIS, y otros) y a realizar desarrollos de software con tecnologías ASP y PHP. Un tiempo más tarde comencé a trabajar ya en forma productiva en la administración de plataformas y desarrollo de software.

Desde hace varios años he tenido una intensa actividad en las comunidades profesionales, a través de eventos, webcasts, foros y publicaciones diversas. En Abril de 2014 fui reconocido como Most Valuable Professional (MVP) por parte de Microsoft, estando hoy reconocido en las especialidades "Windows and Devices for IT" y "Microsoft Azure".

En la actualidad me desarrollo como Service Delivery Manager en Algeiba (http://www.algeiba.com), una compañía que brinda soluciones y servicios tecnológicos, dirigiendo un Equipo de Trabajo de más de 20 personas. También soy el Director de TecTimes, un Portal de Tecnología que nació en el año 2012 como parte de un proyecto personal de contribución a la comunidad tecnológica en español.

Últimas entradas de Pablo Ariel Di Loreto (ver todo)

• [Evento] Microsoft Azure | Tendencias Digitales 2019 – 26/03/2019 - 30 marzo, 2019
• [Evento] Microsoft Azure | Tendencias Digitales 2019 – 06/02/2019 - 12 febrero, 2019
• [Evento] Microsoft Azure | Modernización de Apps con la Nube de Azure – 20/12/2018 - 22 diciembre, 2018