¿Cómo funciona Azure Security Center?

En el artículo anterior hicimos una breve introducción a Azure Security Center. En esta oportunidad, haremos un pequeño recorrido por el sito y sus pantallas principales.

Para ingresar al Azure Security Center, ingresamos con nuestra cuenta al Portal de Azure y en el menú principal, seleccionamos la opción Security Center.

1.png

Desde el Security Center, podemos crear y configurar políticas de seguridad, monitorear nuestras configuraciones de seguridad y ver las alertas de seguridad.

Políticas de Seguridad

 Se pueden definir políticas para la suscripción de Azure de acuerdo con nuestros requerimientos corporativos de seguridad. Además, se pueden ajustar según la aplicación que utilicemos o la sensibilidad de los datos en cada suscripción. Por ejemplo, los recursos utilizados para desarrollo o pruebas funcionales podrían tener diferentes requerimientos de seguridad que aquellos utilizados en producción. Así mismo, las aplicaciones que utilicen información definida como sensible por regulaciones internacionales pueden configurarse con medidas de seguridad especiales.

 Para ver una lista de suscripciones y grupos de recursos, seleccionamos Directivas en el Security Center.

2

 Si seleccionamos Directivas de Seguridad, podremos ver los detalles para cada suscripción.

3

La opción Recolección de Datos permite habilitar esta característica para cada directiva de seguridad. Al hacerlo, permitimos:

  • Revisión diaria de las máquinas virtuales soportadas para su monitoreo y realizar recomendaciones.
  • Recolección de eventos de seguridad para análisis y detección de amenazas.

Dentro del menú Prevención podemos ver los controles de seguridad que queremos monitorear y las recomendaciones que queremos ver basado en las necesidades de seguridad para cada recurso en nuestra suscripción.

4

Recomendaciones de Seguridad

Security Center analiza el estado de seguridad de los recursos de Azure para identificar potenciales vulnerabilidades de seguridad. Una lista de recomendaciones nos guiará durante el proceso de configuración de los controles necesarios. Algunos ejemplos son:

  • Aprovisionamiento de antimalware para ayudar a identificar y remover software malicioso.
  • Configuración de grupos de seguridad de red y reglas para configurar el tráfico de las máquinas virtuales.
  • Aprovisionamiento de aplicaciones web de firewalls para ayudar a defendernos contra ataques a nuestras aplicaciones web.
  • Despliegue de actualizaciones de sistema faltantes.
  • Atención a configuraciones de sistema operativo que no estén de acuerdo con las recomendaciones de base.

Al hacer clic en Recomendaciones aparecerá una lista con las recomendaciones. Al hacer clic en una recomendación podremos ver información adicional para tomar acciones y resolver el incidente.

5

Estado de Seguridad de los recursos de Azure

La sección Prevención del panel nos muestra un resumen de la postura de seguridad del ambiente, por tipo de recurso, incluyendo VMs, aplicaciones web y otros recursos.

Al seleccionar un tipo de recurso, podremos ver más información, incluyendo una lista de potenciales vulnerabilidades de seguridad que hayan sido identificadas.

6

Alertas de seguridad

 Security Center automáticamente recolecta, analiza e integra datos desde los logs de los recursos de Azure, red y soluciones de partner como programas de antimalware y firewalls. Cuando se detecta una amenaza, se crea una alerta de seguridad. Algunos ejemplos son:

  • VMs comprometidas que tengan comunicación con direcciones IP maliciosas.
  • Detección de malware avanzado usando Windows error reporting.
  • Ataques de fuerza bruta contra VMs.
  • Alertas de seguridad desde programas antimalware y firewalls integrados.

7

Felipe Zuñiga, Consultor Cloud, Blue Solutions.

Advertisements

¿Qué es Azure Security Center?

Azure Security Center

 En el último tiempo hemos visto distintos tipos de amenazas de seguridad que han afectado a empresas en todo el mundo. Si bien estas amenazas han aprovechado fallos de seguridad existentes en sistemas más antiguos, uno de los protocolos aun utilizado por múltiples aplicaciones en el mercado permitió la rápida expansión del ataque.

Ante esto, muchas empresas se han preguntado cómo prevenir estos ataques y como poder saber si alguna parte de su infraestructura tecnológica está siendo afectada.

En este artículo, nos concentraremos en Microsoft Azure y como una de sus herramientas permite prevenir, detectar y responder ante amenazas de seguridad que puedan afectar nuestros servicios en la nube de Microsoft.

 ¿Qué es Azure Security Center?

Security Center permite prevenir, detectar y responder a amenazas mediante mejoras en la visibilidad y control sobre la seguridad de los recursos implementados en Azure. Provee monitoreo integrado de seguridad y administración de políticas en la suscripción a Azure, ayudando a detectar amenazas que podrían pasar desapercibidas de otra forma.

 Capacidades claves

Security Center entrega capacidades efectivas y rápidas de usar de prevención, detección y respuesta incluidas en Azure.

 Estas capacidades se dividen en:

 Prevención:

  • Monitoreo del estado de seguridad de los recursos de Azure.
  • Definición de políticas para las suscripciones de Azure basada en los requerimientos de seguridad de la empresa, los tipos de aplicaciones utilizados y la sensibilidad de los datos.
  • Uso de recomendaciones de seguridad basadas en las políticas para guiar a los dueños de cada servicio durante el proceso de implementación de los controles necesarios.
  • Despliegue rápido de servicios de seguridad de Microsoft o Partners.

 Detección:

  • Recolección y análisis automático de datos de seguridad desde los recursos de Azure, la red y soluciones de partners como antimalware y firewalls.
  • Uso de la inteligencia global de amenazas desde los productos y servicios de Microsoft, Microsoft Digital Crimes Unit (DCU), Microsoft Security Response Center (MSRC) y fuentes externas.
  • Aplicación de analíticas avanzadas, incluyendo Machine Learning y análisis de comportamiento.

Respuesta:

  • Provee alertas de incidentes de seguridad de manera prioritaria.
  • Ofrece una mirada completa a la fuente del ataque y a los recursos afectados.
  • Sugiere formas de detener el ataque en curso y ayuda a prevenir futuros ataques.

En otros artículos iremos profundizando en cada una de las características del Azure Security Center y mostraremos como utilizarlo para prevenir amenazas a nuestros recursos alojados en Azure.

Felipe Zuñiga, Consultor Cloud, Blue Solutions.

Office 365 | Planificación de ancho de banda de internet

Hay muchos factores que intervienen en la migración hacia Office 365. Cada organización tiene experiencia y su diferencia se basa en la configuración de su correo actual. El entorno de Exchange existente tiene que estar en algún estándar o cumplir con algunos criterios antes de empezar a moverse a Office 365.  A continuación, se detallan algunos pasos previos antes de realizar cualquier tipo de implementación de Office 365.

Estimando uso de ancho de banda

Hay varias variables que debemos considerar cuando estimamos el tráfico de la red. Algunas de éstas son:

  • Ofertas de Servicio que la organización está suscrito al Servicio de Office 365.
  • Cantidad de estaciones de trabajo conectadas al mismo tiempo.
  • El tipo de tarea de cada equipo cliente se está
  • El rendimiento del software del navegador de Internet.
  • La capacidad de las conexiones de red y segmentos de red asociados a cada equipo cliente.
  • Topología de red de la organización y la capacidad de los distintos elementos de hardware de red.

Calculadoras de ancho de banda que debe utilizar para Office 365

Hay calculadoras disponibles que ayudan con la estimación de los requerimientos de ancho de banda de la red. Estas calculadoras trabajan en las instalaciones, así como despliegues de Office 365. Se puede utilizar la calculadora de ancho de banda de red de cliente de Exchange para estimar el ancho de banda requerido para un conjunto específico de Outlook, Outlook Web App, y los usuarios de dispositivos móviles para la implementación de Office 365. Con la calculadora de 2010 y 2013 de ancho de banda de Skype for Business Server, se introduce la información sobre los usuarios y el Skype for Business Online las prestaciones que desea implementar, dicha calculadora le ayuda a determinar los requisitos de ancho de banda.

  • Exchange Client Network Bandwidth Calculator
  • Lync 2010 and 2013 Bandwidth Calculator
  • OneDrive for Business Synchronization Calculator

Prueba de velocidad de migración

Las pruebas y la validación del ancho de banda de Internet (descarga, carga, y las limitaciones de latencia) son vitales para la comprensión de cómo lograr la migración de alta velocidad de contenido de buzones de correos locales a Office 365 y ambientes de Exchange Online. La conectividad lenta o latente, reduce el número de migraciones de buzones que se pueden realizar durante una ventana de la migración. Asegúrese de realizar los siguientes pasos:

  • Prueba y confirmación que el ancho de banda de Internet de la organización puede gestionar el impacto de red         en migraciones de Office 365
  • Evaluar la disponibilidad de ancho de banda de red interna para eventos de migración de Office 365.
  • Hacer uso de herramientas de red disponibles, tales como:

– Microsoft Network Monitor – Permite capturar el tráfico de red, verlo y analizarlo. Buscar HTTPS/ SSL, tiempos de espera ajustados, muy bajo en Proxy / Firewall / Router y transmisiones excesivas.

– Microsoft Remote Connectivity Analyzer – Chequea la conectividad del ambiente de Exchange Online.

– Office 365 Network Analysis Tool – Ayuda a analizar los problemas relacionados con la red antes de la implementación de servicios de Office 365: Norteamérica: http://na1-fasttrack.cloudapp.net / EMEA: http://em1-fasttrack.cloudapp.net / APAC: http://ap1-fasttrack.cloudapp.net

– Determinar su carga, descarga y latencia entre su control local y el centro de datos de servicios cloud Microsoft más cercano. Las siguientes actividades pueden ayudar en esta tarea: Ping a outlook.com para determinar la dirección IP del centro más cercano a Microsoft datos de los servicios en la nube desde su ubicación. / Consulte a un sitio web de mapas IP de terceros (por ejemplo, iplocation.net) para determinar la ubicación de ese centro de datos. / Use un sitio web prueba de velocidad (por ejemplo speedtest.net) para determinar la carga, descarga y las estadísticas de la latencia entre su entorno local y la ubicación más cercana al centro de datos de servicios cloud Microsoft. / Determinar los períodos en los que el sistema local de Exchange se utiliza en gran medida (por ejemplo, durante las copias de seguridad).

Estrategias para mejorar la velocidad de migración

Para mejorar la velocidad de migración, así como reducir las limitaciones de ancho de banda de su organización, se debe considerar lo siguiente:

  • Reducir el tamaño de los buzones. Mientras más pequeño sea el tamaño del buzón, aumenta la mejora de la               velocidad de migración.
  • Limpieza de carpetas públicas – asegúrese de la limpieza de su público para cumplir con el buzón de                          carpetas públicas en Office 365.
  • Utilice la capacidad de movimiento de buzones con una implementación híbrida de Exchange. Con una                      implementación híbrida de Exchange, el correo sin conexión (.ost) no requiere volver a descargar al migrar a              Exchange Online. Esto reduce significativamente los requisitos de ancho de banda de descarga.
  • Horario del buzón, se mueve al ocurrir períodos de tráfico de Internet y una baja utilización de Exchange                    local. Al programar movimientos, entender que las solicitudes de migración son enviadas al proxy de                          replicación de buzón y pueden no tener lugar inmediatamente.

Para más detalles respecto a la migración, revisar el siguiente link http://go.microsoft.com/fwlink/?LinkId=393510

Luis Arancibia, Consultor Cloud, Blue Solutions. 

 

Microsoft Advance Threat Analytics

Microsoft Advance Threat Analytics (ATA) es una herramienta enfocada a la seguridad de la plataforma de Active Directory para detectar en tiempo real amenazas, y acciones sospechosas sobre el dominio.

¿Qué es ATA?

Microsoft ATA es una plataforma de seguridad para Active Directory con el fin de detectar amenazas. ATA toma información de los eventos y registros de la red con el fin de aprender comportamiento de los usuarios u otras entidades creando un perfil de comportamiento.

ATA aprovecha un motor de análisis sobre la red para capturar y analizar el tráfico de red de diversos protocolos (Kerberos, DNS, NTLM entre otros), ATA obtiene información de las siguientes maneras:

  • Creación de reflejos de puertos en los DC y servidores de DNS directos hacia la puerta de enlace de ATA.
  • Implementación de ATA Light Gateway (LGW) en los DC.

ATA nos permite detectar actividades sospechosas centrándose en:

  • Reconocimiento
  • Desplazamiento lateral
  • Dominio del dominio (persistencia)

Ademas de actividades sospechosas, ATA permite detectar ataques malintencionados como cuales:

  • Pass-the-Ticket (PtT)
  • Pass-the-Hash (PtH)
  • Overpass-the-Hash
  • PAC falsificado (MS14-068)
  • Golden ticket
  • Replicaciones malintencionadas
  • Reconocimiento
  • Fuerza bruta
  • Ejecución remota

Arquitectura de ATA

ATA analiza el tráfico de red de los controladores de dominio mediante el uso de la creación de reflejo de puerto a una puerta de enlace de ATA con conmutadores físicos o virtuales, o implementando la puerta de enlace ligera de ATA directamente en los controladores de dominio. ATA puede sacar provecho de los eventos de Windows (reenviados directamente desde los controladores de dominio o desde un servidor SIEM) y analizar los datos en busca de amenazas y ataques.

1

Arquitectura de ATA

El siguiente diagrama muestra el flujo de red, captura de eventos y explorar en profundidad para la funcionalidad de los componentes de ATA.

2

Componentes de ATA

  • El ATA Center recibe datos de cualquier puerta de enlace de ATA o puerta de enlace ligera de ATA que implemente.
  • El ATA Gateway se instala en un servidor dedicado que supervisa el tráfico de los controladores de dominio mediante la creación de reflejo del puerto o un TAP de red.
  • La ATA Light Gateway se instala directamente en los controladores de dominio y supervisa el tráfico directamente, sin necesidad de un servidor dedicado ni de una configuración de creación de reflejo del puerto. Es una alternativa a la puerta de enlace de ATA.

ATA Center

El ATA Center cumple la función de administras la configuración de los Gateway de ATA, recibir datos desde los ATA Gateway, detectar actividades sospechosas, ejecutar algoritmos de aprendizajes de comportamiento. El ATA Center recibe el tráfico analizado por el ATA Gateway y la ATA Light Gateway, genera perfiles, lleva a cabo una detección determinista y ejecuta el aprendizaje automático.

ATA Gateway y ATA Light Gateway

El ATA Gateway cumple la función de captura y análisis del tráfico de red en los controladores de dominio, recibir eventos de servidores de Syslog o SIEM, recuperar datos sobre usuarios y dispositivos del dominio, realizar tareas de resolución de objetos y transferir los análisis hacia el ATA Center.

ATA es una herramienta la cual llegó para dar fin a la problemática de seguridad especial para Active Directory, considerando la importancia de esta solución (AD) y que es esencial para el resto de las soluciones Microsoft mantener un control sobre AD era una tarea difícil, con la implementación de ATA en su plataforma, podrá mantener control sobre cualquier tipo de ataque, actividades sospechosas e incluso comunicación entre servidores y AD.

Ernesto León, Consultor Infraestructura, Blue Solutions.

 

Arquitectura Ideal de Exchange 2013 (PA)

Simplicidad

Las fallas ocurren. No hay tecnología que pueda cambiar eso. Discos, servidores, racks, redes, generadores, sistemas operáticos, aplicaciones (como Exchange), drivers, y otros servicios, simplemente no existe un servicio entregado por IT que no esté sujeto a fallos.

Una manera de mitigar las fallas es con una infraestructura redundante. Donde una entidad que falla, siempre tendrá una o más entidades para utilizar en su lugar. Esto se puede observar en los Web Server Array, disk array, y similares. Pero la redundancia puede ser costosa, por ejemplo, el costo y la complejidad del sistema de almacenamiento basado en SAN que estaba en el corazón de Exchange hasta la versión 2007, condujeron al equipo de Exchange en aumentar la inversión en almacenamiento para su arquitectura. Nos dimos cuenta de que cada sistema de SAN en última instancia, falla, y que la implementación de un sistema altamente redundante utilizando la tecnología SAN sería un costo muy alto. En respuesta a esto, Exchange a evolucionado de una exigencia costosa de alto rendimiento en almacenamiento SAN y periféricos relacionados, para ahora ser capaz de correr en servidores más baratos con los productos básicos SAS/SATA. Esta arquitectura permite a Exchange ser resistente a fallos relacionados con el almacenamiento permitiendo almacenar buzones de gran tamaño a un costo razonable. Con la construcción de la arquitectura de replicación y optimización de Exchange en almacenamiento, los fallos en temas de almacenamiento son prescindibles. Esta arquitectura no se detiene en la capa de almacenamiento, NIC redundantes, fuentes de poder, etc. Si se trata de un disco, controlador o placa base que falla, el resultado final debe ser el mismo, otra copia de base de datos se activa y se hace cargo. Cuanto más complejo sea el hardware o software de la arquitectura, los errores de hardware ya no se vuelven una prioridad. Ejemplos de redundancia complejos son pares activos/pasivos de red, puntos de agregación de la red con configuraciones complejas de enrutamiento, la colaboración de red, RAID, múltiples vías de fibra, etc. La eliminación de redundancia compleja no parece algo creíble, pero puede lograrse a través de una redundancia basada en Software. La Arquitectura preferida (PA) elimina la complejidad y redundancia cuando sea necesario para impulsar la arquitectura a un modelo de recuperación predecible: cuando se produce un fallo, se activa otra copia de la base de datos afectada.El PA se divide en cuatro áreas de interés:

  • Diseño de espacios de nombres
  • Diseño de datacenter
  • Diseño del servidor
  • Diseño del DAG

Namespace

Desde una perspectiva de espacio de nombres las opciones son, o bien implementar un espacio de nombres con destino preferido (que tiene una preferencia por los usuarios para operar fuera de un centro de datos específico) o un espacio de nombres no unida (que tienen los usuarios se conectan a cualquier centro de datos sin preferencia). El método recomendado es utilizar el modelo no unido, el despliegue de un único espacio de nombres según el protocolo de cliente para el par de estaciones tolerantes del datacenter (donde se supone que cada datacenter  para representar su propio sitio de Active Directory). Por ejemplo:

  • Autodiscover.dominio.com
  • Para clientes http: mail.dominio.com
  • Para clientes IMAP: imap.dominio.com
  • Para clientes SMTP: smtp.dominio.com

Cada espacio de nombre debe estar balanceado entre todos los datacenter en una configuración que no aprovecha la afinidad de sesión, lo que resulta en un cincuenta por ciento del tráfico se distribuye entre los datacenter. El tráfico se distribuye por igual entre los datacenter via DN round-robin, geo-DNS, o soluciones similares. Aunque desde nuestro punto de vista, la solución más simple es la menos complejo y más fácil de manejar, por lo que nuestra recomendación es aprovechar el DNS round-robin. En el caso de que usted tiene sitios múltiples de datacenter flexibles en su entorno, tendrá que decidir si quiere tener un único espacio de nombres en todo el mundo, o si desea controlar el tráfico a cada datacenter específico mediante el uso de espacios de nombres regionales. En última instancia su decisión depende de la topología de red y el costo asociado con el uso de un modelo no unido; por ejemplo, si usted tiene un datacenter ubicados en América del Sur y Europa, el enlace de red entre estas regiones podría no sólo ser costoso, si no también podría tener una alta latencia, que puede presentar dolor de cabeza para el usuario y las cuestiones operativas. En ese caso, tiene sentido para implementar un modelo enlazado con un espacio de nombres separado para cada región.

Diseño de Servidores

En la PA, todos los servidores son multi-rol y físicos. Se prefiere hardware físico por dos razones:

  • Los servidores se escalan para utilizar el 80% de los recursos en el peor de los casos.
  • La virtualización añade una capa adicional de administración y recuperación que no añaden valor a Exchange.

Mediante el despliegue de servidores multi-rol, la arquitectura se simplifica ya que todos los servidores tienen el mismo hardware, proceso de instalación y las opciones de configuración. Consistencia a través de servidores también simplifica la administración. servidores multi-rol proporcionan un uso más eficiente de los recursos del servidor mediante la distribución del CAS y los recursos del Mailbox a través de un mayor número de servidores. CAS y DAG son más resistente a fallas, ya que hay más servidores disponibles para el equilibrio de carga del CAS y para el DAG.

1

Figura 1: Diseño de servidores

Diseño DAG

Para cada sitio será necesario tener como mínimo un DAG.

Configuración del DAG

Al igual que con el namespace design, cada DAG dentro del sitio del datacenter opera en un modelo no unido con copias activas distribuidas por igual entre todos los servidores en el DAG. Este modelo ofrece dos ventajas:

  • Se asegura de que cada servicio de la base de datos se encuentre valida (conectividad con cliente, replicación, transporte, etc).
  • distribuye la carga a través de tantos servidores como sea posible durante un escenario de error, lo que aumenta de forma incremental solamente la utilización de recursos a través de los miembros restantes dentro del DAG.

Cada datacenter es simétrico, con igual número de servidores miembro dentro de un DAG que reside en cada datacenter. Esto significa que cada DAG contiene un número par de servidores y utiliza un servidor testigo de arbitraje quórum.

El DAG es el bloque de construcción fundamental en Exchange 2013. Con respecto al tamaño de DAG, un DAG más grande proporciona más redundancia y recursos. Dentro de la PA, el objetivo es el despliegue de los DAG con alta capacidad.

DAG Network

Desde la introducción de la replicación continua en Exchange 2007, Exchange ha recomendado tener múltiples redes de replicación, para separar el tráfico del cliente de tráfico de replicación. La implementación de dos redes le permite aislar ciertos niveles de tráfico a lo largo de las diferentes vías de la red y asegurarse de que, en determinados eventos la interfaz de red no este saturada. Sin embargo, para la mayoría de los clientes, que tiene dos redes que funcionan de esta manera era sólo una separación lógica, ya que el mismo tejido de cobre fue utilizado por ambas redes en la arquitectura de red subyacente.

Witness Server (Servidor de Testigo)

La utilización de un servidor de testigo determina si la arquitectura puede proporcionar capacidades de activación automática por datacenter en caso de fallas, o si se requerirá activación manual para subir el servicio. Si su organización tiene una tercera ubicación con una infraestructura de red que está aislado de los fallos de red que afectan el sitio del centro de datos par resistente en el que se despliega el DAG, entonces la recomendación es implementar servidor testigo del DAG en ese tercer lugar. Esta configuración ofrece la DAG la capacidad de resistencia a fallas y activación de copia pasiva en otro datacenter.

2

Figura 2: DAG (Esquema de 3 datacenter)

El PA se aprovecha de los cambios realizados en Exchange 2013 para simplificar la implementación de Exchange, sin disminuir la disponibilidad o la elasticidad del despliegue. Y en algunos casos, en comparación con las generaciones anteriores, la PA aumenta la disponibilidad y capacidad de recuperación de su implementación.

Ernesto León, Consultor Infraestructura, Blue Solutions.

¿Podemos manejar archivos con doble espacio, ñ y/o caracteres especiales?

La buena noticia es que sí!, es posible, y no representa un gran problema si hablamos únicamente de Sharepoint, la documentación no detalla nada que hiciera sospechar que pueda ser un inconveniente. Sin embargo, les presento un incidente que se nos presentó en un cliente en el cual este punto fue justamente el centro del problema.

Posterior a la migración desde Sharepoint 2010 a 2013, toda la instalación y migración fue hecha siguiendo las mejores prácticas y sin problemas significativos. El proyecto fue considerado un éxito.

Sin embargo, en la etapa de QA, poco tiempo antes de la puesta en producción y finalizando las últimas pruebas, se hizo presente un problema que afectaba a los usuarios de forma aleatoria. En la librería documental, los archivos con símbolos especiales, ñ o dobles espacios generaban el siguiente error:

  1

Después de un poco de troubleshooting llegamos a la conclusión de que el problema no se presentaba de manera aleatoria, el problema se presenta únicamente cuando los archivos son accedidos desde afuera de la red corporativa.

Dado lo anterior, el primer elemento a examinar, fue el dispositivo encargado de la publicación hacia la red externa, en este caso un Microsoft TMG. Después de la revisión se determinó que efectivamente el filtrado HTTP estaba bloqueando el acceso a URL con ciertas características.

Solución

Para dar solución a nuestro problema accedimos a las propiedades de las directivas de Firewall, después a la ficha de tráfico e hicimos click en Filtering > Configurar HTTP.

2

En la configuración HTTP deshabilitamos la opción “Block high bit characters”. Al aplicar este cambio inmediatamente se permitió acceso a los archivos que anteriormente presentaban problemas.

3

Los filtros aplicados por el TMG en los protocolos HTTP por defecto deniegan el acceso a archivos con caracteres especiales. Si bien este tipo de bloqueos es recomendable (por lo mismo es la configuración por defecto) en ciertas situaciones es necesario reconfigurar para cumplir las necesidades del negocio.

Es importante que la información presentada no es la solución definitiva para los problemas de publicación, sin embargo, recomendamos que los dispositivos utilizados para la publicación de herramientas complejas como Sharepoint sean considerados frente a posibles problemas en el funcionamiento.

Nicolás Herrera, Consultor Infraestructura, Blue Solutions.