Mostrando las entradas con la etiqueta ciber security. Mostrar todas las entradas
Mostrando las entradas con la etiqueta ciber security. Mostrar todas las entradas

domingo, 1 de marzo de 2026

Por qué a cada agente le tengo que poner nombre y apellido

 

Una de las cosas que me costó más vender internamente este año fue la idea de tratar a cada agente como una identidad de primera clase. La cara del CFO cuando le dije “oye, vamos a tener miles de identidades nuevas, y todas van a costarnos gobernarlas” no fue de las mejores reuniones del trimestre.

Pero es lo que toca.

Microsoft Entra Agent ID, todavía en preview a mayo de 2026, es la pieza estructural. La idea es simple: el agente no es un script anónimo que corre con el token de un humano. El agente tiene su propia identidad, sus propios permisos, su propio dueño accountable, y entra al ciclo de vida de IGA igual que un empleado.

 

The image is a digital dashboard interface displaying a user log with actions for accessing SharePoint, showing user information and status.

El contenido generado por IA puede ser incorrecto.

Lo que cambia en la práctica

Antes, si el agente “robot-X” hacía algo raro, el log decía “user: maria.gonzalez”. Tenías que preguntarle a María si era ella o su agente. Ahora el log dice “agent: robot-x | sponsor: maria.gonzalez”. Forensia más limpia, accountability sin ambigüedad.

Antes, cuando María se iba de la empresa, el agente seguía corriendo con su identidad heredada hasta que alguien se acordara. Ahora hay sponsor tasks en Lifecycle Workflows: si el sponsor humano sale, hay un workflow que pide reasignar o suspender al agente. No es perfecto — la implementación a veces requiere intervención manual — pero existe el carril.

Antes, no podías hacer access reviews sobre lo que un agente puede ver. Ahora sí. Y aquí va lo importante: la primera vez que corrí un access review sobre un agente de Copilot Studio que llevaba ocho meses corriendo, encontré que tenía acceso a SharePoint sites que ya nadie usaba. Permisos que se habían heredado de la cuenta de servicio que el agente reemplazó. Limpiamos casi 200 permisos huérfanos en una tarde.

The image depicts a diagram illustrating the lifecycle of an agent and governance, with key points such as sponsor activation, operational status, disconnection, and access review, including tasks and alerts for reassignment.

El contenido generado por IA puede ser incorrecto.

 

Lo que no me gusta

Que sigue siendo preview. Quiero esto en GA ya. Las features de governance de identidades de máquina nunca van rápido en el roadmap, y entiendo por qué (es complicado hacerlo bien), pero el problema ya está aquí.

Que la integración con Copilot Studio aún tiene gaps. No todos los agentes legacy se migran solos. Tienes que ir uno por uno reasignando, lo cual con una empresa con cientos de agentes pequeños es trabajo manual.

Que el billing de las identidades de agente no está claro todavía. Microsoft dice que se factura como parte de Agent 365, pero la documentación todavía es ambigua sobre cuándo cuenta como identidad facturable y cuándo no. He visto facturas con sorpresas.

Para empezar

Define la política primero, antes de tocar el portal. ¿Qué agentes requieren sponsor? ¿Cuántos sponsors mínimos necesita un agente crítico, uno o dos? ¿Cómo defines “crítico” para empezar? ¿Qué pasa si el sponsor está de vacaciones, sigue corriendo el agente o se pausa? Sin estas definiciones, te vas a meter en un lío político con managers que se sienten responsables de algo que no entienden.

Inventario antes que governance. Si no sabes cuántos agentes corren ya en tu tenant, el primer ejercicio es contarlos. Yo hice un script básico de exportar todo lo que Copilot Studio reporta y crucé contra lo que Defender ya estaba viendo. Aparecieron varios que no estaban en mi lista. Eso solo ya valió el ejercicio.

The image depicts a diagram with a dual focus on governmental policy planning and a cloud infrastructure setup, featuring agents, dashboards, and various metrics such as sponsorship levels and gap detection percentages.

El contenido generado por IA puede ser incorrecto.

Y por último — y esto es opinión personal — no esperes a que GA salga para empezar a pensar en esto. La gobernanza de identidades de agente va a ser el control compensatorio más importante del 2026 y 2027. Si llegas tarde, no hay forma de retro-encajarlo limpiamente.

viernes, 27 de abril de 2018

ADFS versus AD Connect + Seguridad

Cuando hablamos de Single Sign On , lo primero que vino a la mente fue (o sigue siendo) la regla por defecto de sincronización de directorios + AD FS = SSO, la única cosa que ha cambiado es que la sincronización de directorios fue reemplazado por AD Conectar y esta combinación todavía se ve en la mayoría de los diseños de solución.

¿Pero realmente necesitamos tanto el ADFS hoy en día?

Cuando el AD Connect vino a reemplazar el DirSync, junto vinieron mejoras que sumadas a Azure AD podemos sacar bastante provecho y diseñar soluciones cada vez más "secas" y más seguras también. El discurso estándar cuando hablamos de los beneficios de la nube es que se puede dedicar su tiempo las cosas que son importantes para su negocio.

En base a este argumento, veo que ADFS se está quedando atrás cuando hablamos de escenarios donde el principal objetivo es sincronismo de usuarios y SSO, pues el AD Connect provee esa solución nativamente. Además, mantener una infraestructura de AD FS requiere una gran cantidad de gestión del personal de TI para mantener la redundancia y alta disponibilidad, ya que para un escenario simple que necesita al menos 2 AD FS + 2 Servidores WAP y / o multiplicar esta infraestructura para tener un sitio de recuperación para ese servicio, si no, si los servidores quedan indisponibles por algún motivo, nadie de la corporación tendrá acceso a los servicios de Office 365 o quedará varias horas esperando el servicio ser restablecido. Si decide cambiar el método de autenticación de federado a administrado como medida paliativa, también tendrá que esperar mucho tiempo hasta que la sincronización finalice.

Cuando el cliente opta por no sincronizar las contraseñas de los usuarios a la nube, no teníamos otra opción que ADFS. Sin embargo, actualmente AD Connect también cubre este requisito con la opción de sincronización Pass Through, de modo que las contraseñas se mantienen sólo en Active Directory local.

Hoy para un escenario donde el objetivo es tener el SSO para las aplicaciones de nube o aplicaciones locales publicadas por Azure Application Proxy ciertamente, salvo alguna excepción, yo recomendaría el AD Connect + Azure AD + Reglas Condicionales.

Un escenario optimizado, más fácil de manejar, menos costoso y mucha seguridad .

Las reglas condicionales AD Azure permiten imponer controles sobre el acceso a las aplicaciones en el entorno en base a las condiciones específicas en una ubicación central, pero eso es un tema para otro artículo.

¡Ah, yo me iba a olvidar! La funcionalidad que existía sólo a través de ADFS de bloquear usuarios basados ​​en el horario de trabajo ya está en la vista previa en Azure AD y luego debe ser liberado al público

lunes, 13 de febrero de 2017

Cybersecurity Consultant of the Year 2017

En el ultimo 7 de febrero, fui nuevamente seleccionado como uno de los ganadores del premio Cybersecurity Excellence Awards 2017 en la categoría (Cybersecurity Consultant of the Year - LATAM)




Quisiera agradecer a todos los amigos, compañeros de equipo y sobre todo a clientes que no solo me han votado sino que dejaros sus comentarios, la verdad este tipo de reconocimiento siempre nos animan a seguir adelante.

Conozcamos un poco mas sobre este reconocimiento:

¿Cuándo se entregaron los premios?



¿Quién los otorga?



¿Cómo fueron nominados?

  • Yo fui nominado en la categoría Cybersecurity Consultant of the Year 2017. Saliendo Galardonado con el primer lugar como en su versión anterior 2016 


¿Cómo eligen a los ganadores?

  • En la página de nominacion de cada candidato, en la zona superior derecha, todos tenían dos formas de proporcionar los votos y la retroalimentación: La más sencilla era el voto por like o pulgar arriba, Los votantes también podrían añadir un comentario a la página de nominación, justo por debajo del like.  Ambas formas tenían peso. 


¿Qué significa para un profecional de seguridad que le hayan otorgado este reconocimiento?

  • La participación en este programa de premios es una gran oportunidad de ser reconocido por nuestra excelencia en la seguridad cibernética.  También es una oportunidad única para los profesionales de la seguridad informática para mejorar la visibilidad y reputación en la comunidad en línea más grande del mundo de los profesionales cibernéticos
  • Los Premios Cybersecurity excellence awards 2017. reconoce a individuos y empresas que demuestran la excelencia, la innovación y el liderazgo en seguridad de la información. Los premios a la excelencia de seguridad cibernética se producen en cooperación con la Comunidad de Seguridad de Información en LinkedIn, aprovechando la experiencia de más de 350,000+ profesionales de seguridad cibernética para reconocer los mejores productos de seguridad cibernética, individuos y organizaciones del mundo. 
  • Los ganadores y finalistas también recibirán premios, reconocimientos en los medios y logotipos para mostrar en su página web.



Espero ver mucho mas profesionales locales nominados en la próxima versión, ya que cada año se suman mas empresas, mas productos y mas profesionales de todo el mundo.




sábado, 3 de diciembre de 2016

Administración de la seguridad en Azure

Los suscriptores de Azure pueden administrar sus entornos de nube desde diversos dispositivos, incluidas estaciones de trabajo de administración, equipos de desarrollador e incluso dispositivos de usuario final con privilegios que tengan permisos específicos para la tarea. En algunos casos, las funciones administrativas se realizan mediante consolas web tales como Azure Portal. En otros casos, puede haber conexiones directas a Azure desde sistemas locales a través de redes privadas virtuales (VPN), Terminal Services, protocolos de aplicación de cliente o Azure Service Management API (SMAPI). Además, los puntos de conexión de cliente pueden estar unidos a un dominio o aislados y no administrados, como tabletas o smartphones.

Aunque las diversas funcionalidades de administración y acceso proporcionan un amplio conjunto de opciones, esta variabilidad puede suponer un riesgo importante para una implementación en la nube y dificultar la administración, el seguimiento y la auditoría de las acciones administrativas. Esta variabilidad también puede presentar amenazas para la seguridad debidas al acceso no regulado a los puntos de conexión de cliente que se usan para administrar los servicios en la nube. El uso de estaciones de trabajo personales o generales para desarrollar y administrar infraestructuras abre la puerta a amenazas impredecibles que se producen tanto en la exploración web (por ejemplo, ataques a los sitios web más utilizados) como en el correo electrónico (tales como ingeniería social y suplantación de identidad [phishing]).




En este tipo de entorno, el riesgo de ataques es mayor porque es difícil construir las directivas y los mecanismos de seguridad para administrar correctamente el acceso a las interfaces de Azure (como SMAPI) desde puntos de conexión muy diversos.

Amenazas de la administración remota

Para obtener acceso con privilegios, los atacantes intentan comprometer las credenciales de cuenta (por ejemplo, forzando la contraseña, mediante suplantación de identidad [phishing] o recopilando credenciales), o intentan engañar a los usuarios para que ejecuten código perjudicial (por ejemplo, desde sitios web malintencionados con descargas ocultas o desde datos adjuntos de correo electrónico perjudiciales). En un entorno de nube administrado de forma remota, las infracciones de cuenta permiten el acceso desde cualquier lugar y en cualquier momento, lo que provoca un riesgo mayor.

Incluso con controles estrictos en las cuentas de los administradores principales, las cuentas de usuario de niveles inferiores se pueden usar para vulnerar los puntos débiles de la estrategia de seguridad de cada uno. La falta de un aprendizaje de seguridad adecuado también puede provocar infracciones debidas a la revelación o la exposición accidental de información de la cuenta.

Cuando una estación de trabajo de usuario se usa también para realizar tareas administrativas, puede presentar muchos puntos de riesgo distintos, por ejemplo, al explorar la Web, al utilizar herramientas de código abierto y de terceros o al abrir un documento perjudicial que contiene un troyano.

En general, la mayoría de los ataques dirigidos que provocan infracciones de datos pueden rastrearse hasta vulnerabilidades del navegador, complementos (por ejemplo, Flash, PDF, Java) y suplantación de identidad (correo electrónico) en equipos de escritorio. Estos equipos pueden tener permisos de nivel administrativo o de nivel de servicio para tener acceso a los servidores activos o los dispositivos de red para operaciones cuando se usan para el desarrollo o la administración de otros activos.

Fundamentos de la seguridad operativa

Para que la administración y las operaciones sean más seguras, puede minimizar la superficie de ataque de un cliente reduciendo el número de posibles puntos de entrada. Esto puede hacerse a través de los principios de seguridad: "segregación de controles" y "segregación de entornos".

Aislamiento de funciones confidenciales entre sí para reducir la probabilidad de que un error en un nivel dé lugar a una infracción de seguridad en otro. Ejemplos:

  • Las tareas administrativas no deben combinarse con las actividades que pueden suponer un riesgo (por ejemplo, un malware en el correo electrónico de un administrador que luego infecte un servidor de la infraestructura).
  • Una estación de trabajo que se usa para operaciones de alta confidencialidad no debería estar en el mismo sistema que se usa para acciones de alto riesgo, como explorar Internet.


Reducción de la superficie de ataque del sistema mediante la eliminación de software innecesario. Ejemplo:

  • Por ejemplo, una estación de trabajo administrativa, de soporte técnico o de desarrollo estándar no debería requerir la instalación de un cliente de correo electrónico o de otras aplicaciones de productividad si la finalidad principal del dispositivo es administrar servicios en la nube.


Sistemas cliente que tienen acceso de administrador a los componentes de la infraestructura deben estar sujetos a la directiva más estricta posible para reducir los riesgos de seguridad. Ejemplos:

  • Entre las directivas de seguridad pueden incluirse la configuración de directiva de grupo que deniega el acceso a Internet abierto desde el dispositivo y el uso de una configuración restrictiva de firewall.
  • Uso de redes VPN con protocolo de seguridad de Internet (IPsec) si se necesita acceso directo.
  • Configuración de dominios de Active Directory de desarrollo y administración independientes.
  • Aislamiento y filtrado del tráfico de red de las estaciones de trabajo de administración.
  • Uso de software antimalware.
  • Implementación de la autenticación multifactor para reducir el riesgo de credenciales robadas.


La consolidación de los recursos de acceso y la eliminación de puntos de conexión no administrados también simplifica las tareas de administración.

Seguridad para la administración remota de Azure

Azure proporciona mecanismos de seguridad para ayudar a los administradores que administran servicios en la nube y máquinas virtuales de Azure. Estos mecanismos incluyen:

  • Autenticación y control de acceso basado en rol.
  • Supervisión, registro y auditoría.
  • Certificados y comunicación cifrada.
  • Un portal de administración web.
  • Filtrado de paquetes de red.


Además de configurar la seguridad del lado cliente y de implementar una puerta de enlace de administración en el centro de datos, es posible restringir y supervisar el acceso de administrador a datos y aplicaciones en la nube.

Estación de trabajo protegida para administración

El objetivo de proteger una estación de trabajo es eliminar todas las funciones excepto las más necesarias para que funcione, reduciendo así al mínimo la superficie de ataque. Para proteger el sistema se minimiza también el número de servicios y aplicaciones instalados, se limita la ejecución de aplicaciones, se restringe el acceso de red a lo estrictamente necesario y el sistema se mantiene siempre actualizado. Además, el uso de estaciones de trabajo protegidas para la administración aísla las herramientas y las actividades administrativas de las demás tareas del usuario final.

Dentro de un entorno empresarial local, puede limitar la superficie de ataque de la infraestructura física mediante redes de administración dedicadas, salas de servidores con acceso por tarjeta y estaciones de trabajo que se ejecutan en las áreas protegidas de la red. En un modelo de TI de nube o híbrido, ser diligente con los servicios de administración segura puede resultar más complejo debido a la falta de acceso físico a los recursos de TI. La implementación de soluciones de protección requiere una cuidadosa configuración del software, procesos centrados en la seguridad y directivas completas.

Usar una huella digital de software minimizada con privilegios mínimos en una estación de trabajo bloqueada para la administración en la nube, así como para el desarrollo de aplicaciones, normaliza los entornos de desarrollo y administración remota y reducir el riesgo de incidentes de seguridad. La configuración de una estación de trabajo protegida puede ayudar a cerrar muchas de las vías vulnerables normalmente usadas por el malware, lo que ayuda a evitar riesgos en las cuentas que se usan para administrar recursos de nube críticos. En concreto, puede usar Windows AppLocker y la tecnología Hyper-V para controlar y aislar el comportamiento del sistema de cliente y mitigar las amenazas, incluido el correo electrónico o la exploración de Internet.

En una estación de trabajo protegida, el administrador ejecuta una cuenta de usuario estándar (que impide la ejecución en el nivel administrativo) y las aplicaciones asociadas se controlan mediante una lista de permitidos. Los elementos básicos de una estación de trabajo protegida son los siguientes:

  • Análisis y revisión activos. Implementar software antimalware, realizar un análisis regular de vulnerabilidades y actualizar todas las estaciones de trabajo con la actualización de seguridad más reciente de manera oportuna.
  • Funcionalidad limitada Desinstale todas las aplicaciones que no sean necesarias y deshabilite los servicios innecesarios (inicio).
  • Protección de la red. Use reglas de Firewall de Windows para permitir solo direcciones IP, puertos y direcciones URL válidos relacionados con la administración de Azure. Asegúrese de bloquear también las conexiones remotas entrantes a la estación de trabajo.
  • Restricción de la ejecución. Permita solo el conjunto de archivos ejecutables predefinidos que se necesitan para realizar la administración (lo que se conoce como "denegación predeterminada"). De forma predeterminada, se deberá denegar el permiso a los usuarios para ejecutar cualquier programa a menos que esté definido explícitamente en la lista de permitidos.
  • Privilegios mínimos. Los usuarios de las estaciones de trabajo de administración no deben tener privilegios administrativos en el propio equipo local. De este modo, no pueden cambiar la configuración del sistema ni los archivos del sistema, ya sea intencionadamente o por accidente.


Para aplicar todo esto, puede usar objetos de directiva de grupo (GPO) en Active Directory Domain Services (AD DS) y aplicarlos mediante su dominio de administración (local) a todas las cuentas de administración.

Administración de servicios, aplicaciones y datos

La configuración de servicios en la nube de Azure se realiza mediante el Portal de Azure o SMAPI, mediante la interfaz de línea de comandos de Windows PowerShell o mediante una aplicación personalizada que aprovecha estas interfaces de RESTful. Los servicios que usan estos mecanismos son Azure Active Directory (Azure AD), Almacenamiento de Azure, Sitios web de Azure y Red virtual de Azure, entre otros.

Máquina virtual: las aplicaciones implementadas proporcionan sus propias herramientas e interfaces de cliente según sea necesario, como Microsoft Management Console (MMC), una consola de administración empresarial (Microsoft System Center o Windows Intune) u otra aplicación de administración (Microsoft SQL Server Management Studio, por ejemplo). Estas herramientas suelen residir en una red de cliente o en un entorno empresarial. Pueden depender de protocolos de red específicos, como el Protocolo de escritorio remoto (RDP), que requiere conexiones directas con estado. Algunos pueden tener interfaces habilitadas para web que no se deben publicar ni ser accesibles a través de Internet.

Puede restringir el acceso a la administración de los servicios de infraestructura y plataforma en Azure mediante la autenticación multifactor, los certificados de administración X.509 y las reglas de firewall. El Portal de Azure y SMAPI requieren Seguridad de capa de transporte (TLS). Sin embargo, los servicios y las aplicaciones que implemente en Azure requieren que tome medidas de protección adecuadas en función de la aplicación. Estos mecanismos se suelen habilitar más fácilmente mediante una configuración de estación de trabajo protegida estándar.

Puerta de enlace de administración

Para centralizar todo el acceso administrativo y simplificar la supervisión y el registro, puede implementar un servidor de Puerta de enlace de Escritorio remoto dedicado en su red local, conectado a su entorno de Azure.

Puerta de enlace de Escritorio remoto es un servicio de proxy RDP basado en directivas que aplica requisitos de seguridad. La implementación de Puerta de enlace de Escritorio remoto junto con Windows Server Network Access Protection (NAP) ayuda a garantizar que solo podrán conectarse los clientes que cumplen los criterios de mantenimiento de seguridad específicos establecidos por Servicios de dominio de Active Directory (AD DS) y Objetos de directiva de grupo (GPO). Además:

  • Aprovisione un certificado de administración de Azure en Puerta de enlace de Escritorio remoto para que sea el único host con permiso para acceder al Portal de administración de Azure.
  • Una Puerta de enlace de Escritorio remoto al mismo dominio de administración que las estaciones de trabajo de administrador. Esto es necesario cuando se usa una VPN IPsec de sitio a sitio o ExpressRoute dentro de un dominio que tenga una confianza unidireccional con Azure AD, o si federa las credenciales entre su instancia de AD DS local y Azure AD.
  • Configure una directiva de autorización de conexión de cliente para que Puerta de enlace de Escritorio remoto pueda comprobar si el nombre de la máquina cliente es válido (unido a un dominio) y tiene permiso para acceder al Portal de administración de Azure.
  • Use IPsec para que la VPN de Azure pueda proteger aún más el tráfico de administración contra la interceptación y el robo de tokens, o podría usar un vínculo a Internet aislado mediante Azure ExpressRoute.
  • Habilite la autenticación multifactor (mediante Azure Multi-Factor Authentication) o la autenticación de tarjeta inteligente para los administradores que inician sesión mediante Puerta de enlace de Escritorio remoto.
  • Configure las restricciones de direcciones IP de origen o los grupos de seguridad de red en Azure para minimizar el número de puntos de conexión de administración permitidos.

Directrices de seguridad

En general, para ayudar a proteger las estaciones de trabajo de administrador para su uso con la nube se usan procedimientos muy similares a los usados para cualquier estación de trabajo local, por ejemplo, compilación minimizada y permisos restrictivos. Algunos aspectos únicos de la administración en la nube son más parecidos a la administración remota o empresarial fuera de banda. Estos incluyen el uso y la auditoría de credenciales, el acceso remoto con seguridad mejorada y la detección de amenazas y respuesta a las mismas.

Autenticación

Puede usar las restricciones de inicio de sesión de Azure para impedir que direcciones IP de origen tengan acceso a herramientas administrativas y solicitudes de acceso de auditoría. Para ayudar a Azure a identificar los clientes de administración (estaciones de trabajo o aplicaciones), puede configurar SMAPI (mediante herramientas desarrolladas por el cliente tales como cmdlets de Windows PowerShell) y el Portal de administración de Azure para que requieran la instalación de certificados de administración del lado cliente, además de los certificados SSL. Se recomienda también que el acceso de administrador requiera autenticación multifactor.

Algunas aplicaciones o servicios que se implementan en Azure pueden tener sus propios mecanismos de autenticación para el acceso de usuario final y de administrador, mientras que otras aprovechan toda la funcionalidad de Azure AD. Dependiendo de si desea federar credenciales mediante Servicios de federación de Active Directory (AD FS), usar la sincronización de directorios o mantener las cuentas de usuario únicamente en la nube, el uso de Microsoft Identity Manager (parte de Azure AD Premium) lo ayuda a administrar los ciclos de vida de las identidades entre los recursos.

Conectividad

Existen varios mecanismos para ayudar a proteger las conexiones de cliente de las redes virtuales de Azure. Dos de estos mecanismos, VPN de sitio a sitio (S2S) y VPN de punto a sitio (P2S), permiten usar el estándar del sector IPsec (S2S) o el Protocolo de túnel de sockets seguros (SSTP) (P2S) para el cifrado y la tunelización. Cuando Azure se conecta a la administración de servicios de Azure accesibles desde Internet, como el Portal de administración de Azure, Azure requiere el protocolo HTTPS.

Una estación de trabajo protegida independiente que no se conecta a Azure mediante Puerta de enlace de Escritorio remoto debe usar VPN de punto a sitio basada en SSTP para crear la conexión inicial a la Red virtual de Azure y, después, establecer la conexión RDP a las máquinas virtuales individuales desde el túnel VPN.

Auditoría de administración y aplicación de directivas

Normalmente, hay dos enfoques para proteger los procesos de administración: auditoría y aplicación de directivas. Ambos proporcionarán controles completos, pero pueden no ser posibles en todas las situaciones. Además, cada método tiene distintos niveles de riesgo, costo y esfuerzo asociados con la administración de la seguridad, especialmente en relación con el nivel de confianza en las personas y las arquitecturas del sistema.

La supervisión, el registro y la auditoría proporcionan una base para el seguimiento y la descripción de las actividades administrativas, pero puede que no siempre sea factible auditar todas las acciones con detalle debido a la cantidad de datos generados. Sin embargo, auditar la efectividad de las directivas de administración es un procedimiento recomendado.

La aplicación de directivas que incluyen controles estrictos de acceso coloca mecanismos de programación que rigen la acciones del administrador, y ayuda a garantizar que se están usando todas las medidas de protección posibles. El registro proporciona una prueba de cumplimiento, además de un registro de quién hizo qué, desde dónde y cuándo. El registro también permite auditar y verificar la información acerca de cómo los administradores usan las directivas, y proporciona pruebas de las actividades.

Configuración de cliente

Se recomiendan tres configuraciones principales para una estación de trabajo protegida. Los principales puntos de diferencia entre ellas son el costo, la facilidad de uso y la accesibilidad, pero el perfil de seguridad es similar en todas las opciones. La tabla siguiente proporciona un breve análisis de las ventajas y los riesgos de cada una. (Observe que "equipos corporativos" hace referencia a una configuración de PC de escritorio estándar que se puede implementar para todos los usuarios del dominio, independientemente de sus roles).




Es importante que la estación de trabajo protegida sea el host y no el invitado, y que no haya nada entre el sistema operativo host y el hardware. Para seguir el "principio del origen limpio" (también conocido como "origen seguro"), el host debe estar lo más protegido posible. De lo contrario, la estación de trabajo protegida (invitado) puede ser objeto de ataques en el sistema en el que se hospeda.

Puede separar aún más las funciones administrativas mediante imágenes de sistema dedicadas para cada estación de trabajo protegida, que solo tengan las herramientas y los permisos necesarios para administrar determinadas aplicaciones de Azure y en la nube, con GPO de AD DS locales específicos para las tareas en la nube.

Para los entornos de TI que carecen de infraestructura local (por ejemplo, sin acceso a una instancia de AD DS local para los GPO porque todos los servidores se encuentran en la nube), un servicio como Microsoft Intune puede simplificar la implementación y el mantenimiento de configuraciones de estación de trabajo.

Estación de trabajo protegida independiente para administración

Con una estación de trabajo protegida independiente, los administradores tienen un equipo o un portátil que usan para las tareas administrativas, y otro equipo o portátil diferente para las tareas no administrativas. Una estación de trabajo dedicada para administrar los servicios de Azure no necesita tener otras aplicaciones instaladas. Además, el uso de estaciones de trabajo que admiten un Módulo de plataforma segura (TPM) o una tecnología de criptografía de nivel de hardware similar ayuda a autenticar dispositivos e impedir ciertos ataques. TPM también admite la protección del volumen completo de la unidad del sistema mediante Cifrado de unidad BitLocker.

En el escenario de la estación de trabajo protegida independiente (se muestra a continuación), la instancia local de Firewall de Windows (o un firewall de cliente no sea de Microsoft) está configurada para bloquear las conexiones entrantes, como RDP. El administrador puede iniciar sesión en la estación de trabajo protegida e iniciar una sesión de RDP que se conecta a Azure después de establecer una conexión de VPN con una Red virtual de Azure, pero no puede iniciar sesión en un equipo corporativo ni usar RDP para conectarse a la propia estación de trabajo protegida.




Equipo corporativo como máquina virtual

En aquellos casos en los que una estación de trabajo independiente protegida sea muy cara o no resulte conveniente, la estación de trabajo protegida puede hospedar una máquina virtual para llevar a cabo tareas no administrativas.




Para evitar varios riesgos de seguridad que pueden surgir del uso de una estación de trabajo para la administración de sistemas y otras tareas del trabajo diario, puede implementar una máquina virtual de Windows Hyper-V en la estación de trabajo protegido. Esta máquina virtual puede usarse como equipo corporativo. El entorno del equipo corporativo puede permanecer aislado del host, lo que reduce la superficie de ataque y evita que las actividades diarias del usuario (por ejemplo, el correo electrónico) coexistan con tareas administrativas importantes.

La máquina virtual del equipo corporativo se ejecuta en un espacio protegido y proporciona aplicaciones de usuario. El host sigue siendo un "origen limpio" y aplica directivas de red estrictas en el sistema operativo de raíz (por ejemplo, bloqueo del acceso RDP desde la máquina virtual).

Windows To Go

Otra alternativa al uso de una estación de trabajo protegida independiente es usar una unidad Windows To Go, una característica que admite la funcionalidad de arranque USB del lado cliente. Windows To Go permite a los usuarios iniciar un equipo compatible con una imagen de sistema aislada ejecutando desde una unidad flash USB cifrada. Proporciona controles adicionales para los puntos de conexión de administración remota porque la imagen se puede administrar totalmente con un grupo de TI corporativo, con directivas de seguridad estrictas, una compilación de sistema operativo mínima y compatibilidad con TPM.

En la ilustración siguiente, la imagen portátil es un sistema unido a un dominio que está preconfigurado para conectarse únicamente a Azure, requiere autenticación multifactor y bloquea todo el tráfico no sea de administración. Si un usuario inicia el mismo equipo con la imagen corporativa estándar e intenta obtener acceso a las herramientas de administración de Azure mediante Puerta de enlace de Escritorio remoto, se bloqueará la sesión. Windows To Go se convierte en el sistema operativo del nivel raíz y no se necesitan capas adicionales (sistema operativo host, hipervisor, máquina virtual) que pueden ser más vulnerables a ataques del exterior.



Es importante tener en cuenta que las unidades flash USB se pierden más fácilmente que un equipo de escritorio promedio. Si se utiliza BitLocker para cifrar todo el volumen junto con una contraseña segura, se reducen las probabilidades de que un atacante pueda usar la imagen de la unidad con fines malintencionados. Además, si se pierde la unidad flash USB, puede revocar y emitir un nuevo certificado de administración, y restablecer la contraseña rápidamente, para reducir la exposición. Los registros de auditoría administrativa residen en Azure, no en el cliente, lo que reduce aún más las posibles pérdida de datos.

Prácticas recomendadas

Tenga en cuenta las siguientes directrices adicionales cuando administre aplicaciones y datos en Azure.

Consejos

No dé por sentado que si una estación de trabajo está bloqueada ya no es necesario cumplir otros requisitos de seguridad comunes. El riesgo potencial es mayor debido a los niveles de acceso con privilegios elevados que normalmente poseen las cuentas de administrador. En la tabla siguiente se muestran ejemplos de riesgos y los procedimientos de seguridad alternativos.



Operaciones de Azure

Dentro de las operaciones que Microsoft realiza con Azure, los ingenieros de operaciones y el personal de soporte técnico que tienen acceso a los sistemas de producción de Azure usan equipos de estación de trabajo protegidos con máquinas virtuales aprovisionadas en ellos para el acceso a las aplicaciones y a la red corporativa interna (como correo electrónico, intranet, etc.). Todos los equipos de estación de trabajo de administración tienen TPM, la unidad de arranque del host está cifrada con BitLocker y están unidas a una unidad organizativa (OU) especial en el dominio corporativo principal de Microsoft.

La protección del sistema se aplica mediante la directiva de grupo, con actualizaciones de software centralizadas. Para auditoría y análisis, los registros de eventos (por ejemplo, seguridad y AppLocker) se recopilan desde estaciones de trabajo de administración y se guardan en una ubicación central.

Además, en la red de Microsoft se usan cuadros de salto dedicados que requieren autenticación en dos fases para conectarse a la red de producción de Azure.

Lista de comprobación de seguridad de Azure

Reducir el número de tareas que los administradores pueden realizar en una estación de trabajo protegida le ayudará a minimizar la superficie de ataque en su entorno de administración y desarrollo. Use las siguientes tecnologías para ayudar a asegurar su estación de trabajo protegida:

  • Protección de Internet Explorer. El explorador Internet Explorer (o, en este caso, cualquier explorador web) es un punto de entrada clave para el código perjudicial debido a sus amplias interacciones con servidores externos. Revise las directivas de cliente y aplique la ejecución en modo protegido, la deshabilitación de complementos, la deshabilitación de descargas de archivos y el uso del filtrado Microsoft SmartScreen. Asegúrese de que se muestran las advertencias de seguridad. Aproveche las ventajas de las zonas de Internet y crear una lista de sitios de confianza para los que ha configurado una protección razonable. Bloquee todos los demás sitios y el código en el explorador, como ActiveX y Java.
  • Usuario estándar Trabajar como usuario estándar ofrece una serie de ventajas, la principal es que dificulta el robo de las credenciales de administrador mediante software malintencionado. Además, una cuenta de usuario estándar no tiene privilegios elevados en el sistema operativo raíz, y muchas opciones de configuración y API están bloqueadas de forma predeterminada.
  • AppLocker. Puede usar AppLocker para restringir los programas y los scripts que los usuarios pueden ejecutar. Puede ejecutar AppLocker en modo auditoría o cumplimiento. De forma predeterminada, AppLocker tiene una regla de permiso que permite a los usuarios que tengan un token de administrador ejecutar todo el código en el cliente. Esta regla existe para impedir que los administradores se bloqueen a sí mismos y solo se aplica a los tokens con privilegios elevados. Consulte también el tema sobre la integridad del código, que forma parte de la seguridad fundamental de Windows Server.
  • Firma del código. La firma del código de todas las herramientas y scripts que usan los administradores es un mecanismo fácil de administrar para la implementación de directivas de bloqueo de aplicaciones. Los valores hash no se escalan con cambios rápidos al código y las rutas de acceso de archivo no proporcionan un alto nivel de seguridad. Debe combinar reglas de AppLocker con una directiva de ejecución de PowerShell que solo permita la ejecución de código y scripts específicos firmados.
  • Directiva de grupo. Cree una directiva administrativa global que se aplique a cualquier estación de trabajo del dominio que se use para administración (y bloquee el acceso de todas los demás), así como a las cuentas de usuario autenticadas en esas estaciones de trabajo.
  • Aprovisionamiento con seguridad mejorada. Proteja la imagen de su estación de trabajo protegida de referencia contra la manipulación. Use medidas de seguridad tales como cifrado y aislamiento para almacenar imágenes, máquinas virtuales y scripts, y restrinja el acceso (quizás con un proceso de inserción y extracción del repositorio que se pueda auditar).
  • Aplicación de revisiones. Mantenga una compilación coherente (o use imágenes diferentes para desarrollo, operaciones y otras tareas administrativas), examine de forma rutinaria si hay cambios y malware, mantenga la compilación al día y active los equipos solo cuando se necesiten.
  • Cifrado. Asegúrese de que las estaciones de trabajo de administración tengan TPM para habilitar Sistema de cifrado de archivos (EFS) y BitLocker de forma más segura. Si usa Windows To Go, utilice solo llaves USB cifradas junto con BitLocker.
  • Gobierno. Use GPO de AD DS para controlar todas las interfaces de Windows de los administradores, como el uso compartido de archivos. Incluya las estaciones de trabajo de administración de procesos de auditoría, supervisión y registro. Realice un seguimiento del acceso y uso de los administradores y programadores.

Resumen

Usar una configuración de estación de trabajo protegida para administrar los servicios en la nube de Azure, las máquinas virtuales y las aplicaciones puede ayudarle a evitar muchos riesgos y amenazas que pueden derivar de la administración remota de la infraestructura de TI esencial. Tanto Azure como Windows proporcionan mecanismos que puede emplear para ayudar a proteger y controlar el comportamiento de las comunicaciones, la autenticación y los clientes.

Procedimientos recomendados de cifrado y seguridad de datos en Azure

Les dejo un conjunto de procedimientos recomendados para el cifrado y la seguridad de los datos con funcionalidades de Azure integradas.

Uno de los elementos clave para la protección de datos en la nube consiste en tener en cuenta los posibles estados en que se pueden producir datos y qué controles hay disponibles para ese estado. Como parte de los procedimientos recomendados de cifrado y seguridad de datos en Azure, se ofrecen recomendaciones relacionadas con los estados de datos siguientes:

  • En reposo: esto incluye información sobre todos los objetos de almacenamiento, los contenedores y los tipos que existen de forma estática en medios físicos, ya sean discos magnéticos u ópticos.
  • En tránsito: se considera que los datos están en movimiento cuando se transfieren entre componentes, ubicaciones o programas. Por ejemplo, a través de la red o un bus de servicio (desde una ubicación local hacia la nube, y viceversa, incluidas las conexiones híbridas como ExpressRoute) o durante el proceso de entrada y salida.


En este artículo, veremos un conjunto de procedimientos recomendados de cifrado y seguridad de datos en Azure. Estos procedimientos recomendados se derivan de nuestra experiencia con el cifrado y la seguridad de datos en Azure, y las experiencias de clientes como usted.

Para cada procedimiento recomendado, explicaremos:

  • Qué es el procedimiento recomendado
  • Por qué le conviene habilitar este procedimiento recomendado
  • Cuál podría ser el resultado si no habilita el procedimiento recomendado
  • Alternativas posibles al procedimiento recomendado
  • Cómo aprender a habilitar el procedimiento recomendado


Este artículo parte de una opinión consensuada y se basa en las funcionalidades y los conjuntos de características de la plataforma Azure existentes cuando se redactó. Las opiniones y las tecnologías cambian con el tiempo, por lo que se actualizará de forma periódica para reflejar esos cambios.

Entre los procedimientos recomendados de cifrado y seguridad de datos en Azure, se incluyen:

  • Aplicación de Multi-Factor Authentication
  • Uso del control de acceso basado en rol (RBAC)
  • Cifrado de máquinas virtuales de Azure
  • Uso de modelos de seguridad de hardware
  • Administración con estaciones de trabajo seguras
  • Habilitación del cifrado de datos SQL
  • Protección de los datos en tránsito
  • Aplicación del cifrado de datos a nivel de archivos


Aplicación de Multi-Factor Authentication

El primer paso relativo al acceso y al control de datos en Microsoft Azure consiste en autenticar al usuario. Azure Multi-Factor Authentication (MFA) es un método de verificación de la identidad del usuario que no se limita al nombre de usuario y la contraseña. Este método de autenticación ayuda a proteger el acceso a los datos y las aplicaciones, además de satisfacer a los usuarios, que demandan un proceso de inicio de sesión simple.

Si habilita Azure MFA para los usuarios, agrega una segunda capa de seguridad a sus transacciones e inicios de sesión. En este caso, es posible que durante una transacción se acceda a un documento que se encuentra en un servidor de archivos o en SharePoint Online. Azure MFA también ayuda al equipo de TI a reducir la probabilidad de que se acceda a los datos de la organización usando credenciales en peligro.

Por ejemplo: si aplica Azure MFA para los usuarios y lo configura para que use una llamada de teléfono o un mensaje de texto como comprobación, si las credenciales del usuario están en peligro, el atacante no podrá acceder a los recursos porque no tendrá acceso al teléfono del usuario. Las organizaciones que no agreguen esta capa adicional de protección de la identidad son más susceptibles a los ataques de robo de credenciales, que pueden poner en peligro los datos.

Una alternativa para las organizaciones que desean mantener un control local de la autenticación es usar Servidor Azure Multi-Factor Authentication, también denominado MFA local. Mediante este método, podrá seguir aplicando la autenticación multifactor y mantener el servidor MFA local.

Uso del control de acceso basado en rol (RBAC)

Restrinja el acceso siguiendo los principios de seguridad de limitar el acceso a lo que se necesita saber y conceder los privilegios mínimos. Esto es fundamental para las organizaciones que deseen aplicar directivas de seguridad para el acceso a los datos. El control de acceso basado en rol (RBAC) de Azure sirve para asignar permisos a usuarios, grupos y aplicaciones en un ámbito determinado. El ámbito de una asignación de roles puede ser una suscripción, un grupo de recursos o un único recurso.

Puede aprovechar los roles de RBAC integrados en Azure para asignar privilegios a los usuarios. Considere usar Colaborador de la cuenta de almacenamiento para los operadores en la nube que necesiten administrar cuentas de almacenamiento y Colaborador de la cuenta de almacenamiento clásica para administrar cuentas de almacenamiento clásicas. En el caso de los operadores en la nube que necesiten administrar máquinas virtuales y cuentas de almacenamiento, podría agregarlos al rol Colaborador de la máquina virtual.

Es posible que las organizaciones que no apliquen el control de acceso a los datos mediante funcionalidades como RBAC estén concediendo más privilegios de los necesarios a sus usuarios. Esto puede poner en peligro los datos si algunos usuarios obtienen acceso a datos que no les conciernen.

Cifrado de máquinas virtuales de Azure

Para muchas organizaciones, el cifrado de los datos en reposo es un paso obligatorio en lo que respecta a la privacidad de los datos, el cumplimiento y la soberanía de los datos. Cifrado de discos de Azure permite que los administradores de TI cifren discos de máquina virtual IaaS con Windows y Linux. Cifrado de discos de Azure aprovecha la característica BitLocker de Windows, estándar en el sector, y la característica DM-Crypt de Linux para ofrecer cifrado de volumen para los discos de datos y del sistema operativo.

Puede aprovechar Cifrado de discos de Azure para proteger sus datos y así satisfacer los requisitos de cumplimiento y seguridad de la organización. Además, las organizaciones deberían pensar en usar cifrado como ayuda para mitigar los riesgos relacionados con el acceso no autorizado a los datos. También se recomienda cifrar las unidades antes de escribir datos confidenciales en ellas.

Asegúrese de cifrar los volúmenes de datos y el volumen de arranque de la máquina virtual para proteger los datos en reposo en su cuenta de almacenamiento de Azure. Proteja las claves de cifrado y los secretos mediante el Almacén de claves de Azure.

Para los servidores de Windows locales, podría aplicar los siguientes procedimientos recomendados:


  • Use BitLocker para el cifrado de datos.
  • Almacene la información de recuperación en AD DS.
  • Ante cualquier preocupación por que las claves de BitLocker se hayan puesto en peligro, se recomienda formatear la unidad para quitar todas las instancias de los metadatos de BitLocker o descifrar toda la unidad y cifrarla de nuevo.

Las organizaciones que no aplican el cifrado de datos están más expuestas a sufrir problemas de integridad de datos, como por ejemplo, usuarios no autorizados o malintencionados que roban datos y cuentas en peligro que acceden sin autorización a datos sin cifrar. Además de estos riesgos, las compañías que deben cumplir normativas del sector tienen que demostrar que son diligentes y que usan los controles adecuados para mejorar la seguridad de los datos.

Uso de módulos de seguridad de hardware

Las soluciones de cifrado del sector usan claves secretas para cifrar los datos. Por lo tanto, es fundamental que estas claves se almacenen de forma segura. La administración de claves se convierte en una parte integral de la protección de datos, ya que se encargará de almacenar las claves secretas que sirven para cifrar datos.

Cifrado de discos de Azure se integra con el Almacén de claves de Azure para ayudarlo a controlar y administrar las claves y los secretos de cifrado de discos en su suscripción del almacén de claves. Además, garantiza que todos los datos de los discos de las máquinas virtuales se cifren en reposo en el Almacenamiento de Azure. Debería usar el Almacén de claves de Azure para auditar el uso de la directiva y las claves.

Existen muchos riesgos inherentes a la carencia de controles de seguridad adecuados para proteger las claves secretas que se usaron para cifrar los datos. Si los atacantes obtienen acceso a las claves secretas, podrán descifrar los datos y acceder a información confidencial.

Puede obtener más recomendaciones generales para la administración de certificados en Azure en el artículo Certificate Management in Azure: Do's and Don'ts (Administración de certificados en Azure: qué hacer y qué no hacer).


Administración con estaciones de trabajo seguras

Puesto que la mayoría de los ataques van destinados al usuario final, el punto de conexión se convierte en uno de los principales puntos de ataque. Si un atacante pone en peligro el punto de conexión, puede aprovechar las credenciales del usuario para acceder a los datos de la organización. La mayoría de los ataques a los puntos de conexión aprovechan el hecho de que los usuarios finales son administradores en sus estaciones de trabajo locales.

Para reducir estos riesgos, use una estación de trabajo de administración segura. Se recomienda que use una estación de trabajo con privilegios de acceso (PAW) para reducir la superficie expuesta a ataques en las estaciones de trabajo. Estas estaciones de trabajo de administración seguras pueden ayudar a mitigar algunos de estos ataques y a garantizar la mayor seguridad de sus datos. Asegúrese de usar PAW para proteger y bloquear la estación de trabajo. Se trata de un paso importante para proporcionar garantías de alta seguridad para la protección de cuentas, tareas y datos confidenciales.

La falta de protección en los puntos de conexión puede poner sus datos en riesgo. Asegúrese de aplicar directivas de seguridad en todos los dispositivos que se usen para consumir datos, independientemente de su ubicación (nube o local).

Puede aprender más sobre las estaciones de trabajo con privilegios de acceso en el artículo Securing Privileged Access (Protección del acceso con privilegios).

Habilitación del cifrado de datos SQL

El Cifrado de datos transparente (TDE) de Base de datos SQL de Azure facilita la protección contra la amenaza de actividades malintencionadas, ya que la base de datos se cifra y descifra en tiempo real, se realizan copias de seguridad asociadas y archivos de registro de transacciones en reposo sin requerir cambios en la aplicación. TDE cifra el almacenamiento de una base de datos completa mediante el uso de una clave simétrica denominada clave de cifrado de base de datos.

Incluso cuando se cifra el almacenamiento completo, es muy importante cifrar también la base de datos. Se trata de una implementación del enfoque defensivo en profundidad para la protección de los datos. Si usa Base de datos SQL de Azure y desea proteger datos confidenciales como números de tarjetas de crédito o del seguro social, puede cifrar las bases de datos con el cifrado AES de 256 bits validado por FIPS 140-2, que cumple los requisitos de muchas normas del sector (por ejemplo, HIPAA, PCI).

Es importante comprender que los archivos relacionados con la extensión del grupo de búferes (BPE) no se cifran cuando se cifra una base de datos mediante TDE. Debe usar herramientas de cifrado de nivel de sistema de archivos como BitLocker o Sistema de cifrado de archivos (EFS) para los archivos relacionados con la BPE.

Ya que un usuario autorizado, como un administrador de seguridad o de base de datos, puede acceder a los datos incluso si la base de datos está cifrada con TDE, también se deben seguir estas recomendaciones:

  • Autenticación de SQL en el nivel de base de datos
  • Autenticación de Azure AD mediante roles RBAC
  • Los usuarios y las aplicaciones deberían usar cuentas independientes para la autenticación. De este modo, puede limitar los permisos que se conceden a usuarios y aplicaciones, y reducir los riesgos causados por la actividad malintencionada.
  • Implemente la seguridad de nivel de base de datos con roles fijos de base de datos (como db_datareader o db_datawriter). También puede crear roles personalizados para su aplicación con el fin de conceder permisos explícitos a determinados objetos de la base de datos.


Las organizaciones que no usen el cifrado de nivel de base de datos pueden ser más susceptibles a ataques que podrían poner en peligro los datos ubicados en bases de datos SQL.

Para aprender más acerca del cifrado TDE de SQL, lea el artículo Cifrado de datos transparente con Base de datos SQL de Azure.

Protección de los datos en tránsito

Proteger los datos en tránsito debe ser una parte esencial de su estrategia de protección de datos. Puesto que los datos se desplazan entre muchas ubicaciones, la recomendación general es utilizar siempre los protocolos SSL/TLS para intercambiar datos entre diferentes ubicaciones. En algunas circunstancias, podría aislar todo el canal de comunicación entre su infraestructura local y la nube mediante una red privada virtual (VPN).

Para los datos que se desplazan entre la infraestructura local y Azure, debe plantearse usar medidas de seguridad apropiadas, como HTTPS o VPN.

Para las organizaciones que necesitan proteger el acceso a Azure desde varias estaciones de trabajo locales, use una VPN de sitio a sitio de Azure.

Si la organización necesita proteger el acceso a Azure desde una estación de trabajo local, use una VPN de punto a sitio.

Los conjuntos de datos más grandes se pueden mover por medio de un vínculo WAN dedicado de alta velocidad como ExpressRoute. Si decide usar ExpressRoute, también puede cifrar los datos en el nivel de aplicación mediante SSL/TLS u otros protocolos para una mayor protección.

Si interactúa con el Almacenamiento de Azure a través del Portal de Azure, todas las transacciones se realizan a través de HTTPS. También se puede usar la API de REST de almacenamiento a través de HTTPS para interactuar con el Almacenamiento de Azure y Base de datos SQL de Azure.

Las organizaciones que no protegen los datos en tránsito son más susceptibles a los ataques del tipo "Man in the middle", a la interceptación y al secuestro de sesión. Estos ataques pueden ser el primer paso para obtener acceso a datos confidenciales.

Aplicación del cifrado de datos a nivel de archivos

Otra capa de protección que puede aumentar el nivel de seguridad de los datos es el cifrado del archivo, independientemente de su ubicación.

Azure RMS usa directivas de autorización, identidad y cifrado para ayudar a proteger los archivos y el correo electrónico. Azure RMS funciona en varios dispositivos (teléfonos, tabletas y PC) y los protege tanto dentro como fuera de su organización. Esta funcionalidad es posible porque Azure RMS agrega una capa de protección que acompaña a los datos, incluso cuando salen de los límites de su organización.

Cuando usa Azure RMS para proteger los archivos, utiliza criptografía estándar del sector que es totalmente compatible con FIPS 140-2. Cuando aprovecha Azure RMS para proteger los datos, tiene la garantía de que la protección permanece con el archivo, incluso si se copia en almacenamiento que no esté bajo el control de TI, como un servicio de almacenamiento en la nube. Lo mismo ocurre con los archivos compartidos por correo electrónico: se protege el archivo adjunto al mensaje de correo electrónico y se incluyen instrucciones para abrirlo.

Durante el planeamiento para adoptar Azure RMS, se recomienda lo siguiente:

  • Instale la aplicación RMS sharing. Esta aplicación se integra con las aplicaciones de Office con la instalación de un complemento de Office con el que los usuarios pueden proteger los archivos directamente y de forma sencilla.
  • Configure las aplicaciones y los servicios para que admitan Azure RMS.
  • Cree plantillas personalizadas que reflejen sus requisitos empresariales. Por ejemplo: una plantilla para los datos más delicados que se deba aplicar a todos los correos electrónicos de mayor confidencialidad.


Las organizaciones con puntos débiles en la clasificación de datos y la protección de archivos pueden ser más susceptibles a la fuga de datos. Sin una protección adecuada de los archivos, las organizaciones no pueden obtener perspectivas empresariales, supervisar el abuso ni evitar el acceso malicioso a archivos.

Puede aprender más acerca de Azure RMS en el artículo Introducción a Azure Rights Management.

viernes, 2 de diciembre de 2016

Informe de inteligencia frente a amenazas de Azure Security Center


En este post se explica cómo los informes de inteligencia frente a amenazas de Azure Security Center pueden ayudarle a aprender más sobre una amenaza que ha generado una alerta de seguridad.

¿Qué es un informe de inteligencia frente a amenazas?

La detección de amenazas de Security supervisa la información de seguridad de sus recursos de Azure, la red y las soluciones de asociados relacionadas. Después, analiza estos datos (a menudo, relacionando la información de diferentes orígenes) para identificar las amenazas. Este proceso forma parte de las funcionalidades de detección de Security Center. 

Cuando Security Center identifica una amenaza, desencadena una alerta de seguridad, que contiene información detallada sobre un evento determinado, junto con sugerencias para remediarlo. Para ayudar a los equipos de respuesta a incidentes a investigar y solucionar las amenazas, Security Center incluye un informe de inteligencia frente a amenazas que contiene información sobre la amenaza detectada, y además: 

  • Identidad o asociaciones del atacante (si esta información está disponible)
  • Objetivos de los atacantes
  • Campañas de ataques históricas y actuales (si esta información está disponible)
  • Tácticas, herramientas y procedimientos de los atacantes
  • Indicadores asociados de peligro (IoC), como direcciones URL y hash de archivo
  • Victimología, que es el predominio geográfico y del sector para ayudarle a determinar si sus recursos de Azure están en peligro
  • Información de corrección y mitigación


Security Center tiene tres tipos de informes de amenazas, que pueden variar según el ataque. Los informes disponibles son:

  • Informe de grupo de actividad: proporciona información detallada sobre los atacantes, sus objetivos y las tácticas que empelan.
  • Informe de campaña: se centra en los detalles de campañas de ataque específicas. 
  • Informe de resumen de amenazas: cubre todos los elementos de los dos informes anteriores.


Este tipo de información es muy útil durante los procesos de respuesta a incidentes, donde hay una investigación en curso para comprender el origen del ataque, las motivaciones del atacante y lo que se debe hacer para mitigar este problema más adelante. 

¿Cómo acceder al informe de inteligencia frente a amenazas?

Puede revisar las alertas actuales en el icono Alertas de seguridad . Abra Azure Portal y siga los pasos siguientes para ver más detalles sobre cada alerta:

1.En el panel Security Center, verá el icono Alertas de seguridad .

2.Haga clic en el icono para abrir la hoja Alertas de seguridad que contiene información más detallada sobre las alertas y haga clic en la alerta de seguridad sobre la que quiere más información.




3.En este caso, la hoja Suspicious process executed (Proceso sospechoso ejecutado) muestra los detalles sobre la alerta, como se puede ver en la siguiente ilustración:



4.La cantidad de información disponible para cada alerta de seguridad variará según el tipo de alerta. En el campo INFORMES hay un vínculo al informe de inteligencia frente a amenazas. Haga clic en él. Aparecerá otra ventana del explorador con el archivo PDF.



Desde aquí puede descargar el PDF de este informe y leer más sobre el problema de seguridad que se ha detectado para actuar en función de la información proporcionada.