 TechNet Magazine June 2007

TechNet Magazine June 2007

Seguridad : Estudio del control de cuenta de usuario (UAC) de Windows Vista

El control de cuentas de usuario, o UAC, es una de las nuevas características peor comprendidas de Windows Vista. Sin embargo, su objetivo, habilitar a los usuarios para que ejecuten con derechos de usuario estándar, puede resolver muchos problemas de seguridad. Estudiemos los problemas para los que UAC está diseñado y veamos exactamente cómo funciona esta nueva característica.

Mark Russinovich Seguridad: Claves para la protección de datos con Cifrado de unidad BitLocker

BitLocker sirve para dos propósitos muy importantes: proporciona tanto el cifrado de datos en el volumen completo como una manera de validar la integridad de los primeros componentes de inicio, antes del inicio de Windows Vista. Obtenga una introducción al funcionamiento de BitLocker y vea cómo puede ayudarle a proteger su organización.

Byron Hynes Seguridad: Exploración de Firewall de Windows

La movilidad ha cambiado las amenazas informáticas y las técnicas para evitarlas. Cuando los equipos portátiles vagan fuera del perímetro y regresan a la red, se necesitan formas más apropiadas de proteger los sistemas. Descubra cómo usar Firewall de Windows para proteger sus equipos, tanto en Internet como en su propia red interna.

Steve Riley Seguridad: Nuevas ACL mejoran la seguridad en Windows Vista

Aunque las listas de control de acceso (ACL) no han tenido una revisión importante, existen varios cambios significativos que debe conocer a la hora de administrar las ACL en un entorno de Windows Vista. Descubra cómo cambiaron 30 ACL para mejorar la seguridad, entienda qué impacto tendrán en la organización y aprenda a administrar estos cambios en la infraestructura.

Jesper Johansson Seguridad: Administración de restricciones de hardware mediante directivas de grupo

Las llaves en miniatura de disco USB y otros dispositivos extraíbles pueden facilitar la vida personal pero hacer más difícil la vida profesional. Para obtener una seguridad mejorada, necesita una manera de controlar qué dispositivos de hardware instalan los usuarios en sus sistemas de trabajo. Ahora puede usar directivas de grupo para controlar cuáles dispositivos pueden usar y cuáles no.

Jeremy Moskowitz Seguridad: Cuatro tecnologías de seguridad que toda organización de TI debe tener

La mayoría de las empresas comparten problemas de seguridad similares. En el mundo conectado de hoy, existen cuatro tipos generales de herramientas de seguridad que toda organización debe tener sin falta. Descubra cuáles son esas herramientas y explore cómo en el futuro las tecnologías implicadas pueden trabajar en conjunto para crear la solución ideal de seguridad.

Matt Clapham and Todd Thompson Seguridad: Una eficaz herramienta nueva para la administración de certificados

Los certificados son un componente clave de su infraestructura: si uno caduca, la productividad puede detenerse. Si depende de un entorno de Microsoft PKI, la nueva solución para la administración de certificados Identity Lifecycle Manager (ILM-CM) puede ayudarle para que todo vaya sobre ruedas. Vea cómo puede ayudarle esta herramienta a mejorar los procesos de autenticación y reducir los costos de administración de certificados.

Kevin Dallmann Nota del editor: Problemas de seguridad

Joshua Trupin Caja de herramientas: Nuevos productos para profesionales de TI

Greg Steen Preguntas y respuestas sobre SQL&: Instalaciones de 64 bits, asignación de memoria de clúster y mucho más

Edited by Nancy Michell Noticias destacadas sobre utilidades: PowerToys de elevación de secuencias de comandos para Windows Vista

El Control de cuentas de usuario ofrece una mejora importante de seguridad, pero la capacidad de elevar los permisos es esencial para llevar a cabo determinadas tareas y funciones administrativas. Estos son algunos PowerToys de elevación que aportan una mayor flexibilidad y eficacia.

Michael Murgolo The Cable Guy: Protocolo de túnel de sockets seguros

Los protocolos VPN en Windows XP y Windows Server 2003 no funcionan en algunas configuraciones. Obtenga un análisis en profundidad de las distintas situaciones y vea cómo Windows Server con nombre en código "Longhorn" y Windows Vista con Service Pack 1 usarán el protocolo de túnel de sockets seguros para resolver estos problemas.

Joseph Davies Windows PowerShell: Trabajo con Active Directory

Windows PowerShell no ofrece un cmdlet Get-ADSIObject, pero eso no impide que sea totalmente compatible con ADSI. Obtenga una introducción sobre los adaptadores de tipo y aprenda a usar Windows PowerShell para que funcione con objetos de directorio.

Don Jones ¡Hola, encargados de las secuencias de comandos!: Trabajo con secuencias de comandos sobre la serpenteante línea roja

¿Busca una manera fácil de agregar términos al diccionario de Microsoft Word que no sea manual, palabra por palabra? ¿Quién no? Este mes, los encargados de las secuencias de comandos le muestran cómo crear diccionarios personalizados en Microsoft Word y cómo configurar Word mediante programación para que use esos diccionarios.

The Microsoft Scripting Guys Archivos del escritorio: Cómo evitar la pérdida de datos

Es sorprendente la frecuencia con que se pierden datos importantes. Pero la realidad es que esa información se pierde porque las personas no la protegen. Explore los pasos importantes que puede y debe realizar para proteger los datos de su organización.

Wes Miller Notas de campo: Hable con sus desarrolladores

Hacer que los desarrolladores generen aplicaciones más fáciles de administrar es más sencillo de lo que piensa. Todo empieza por la comunicación. Los desarrolladores ven el software de manera diferente a los administradores. Pero hablando con los desarrolladores, los administradores pueden explicar qué es importante para ellos y los desarrolladores pueden hacer mejor su trabajo diseñando el código en consecuencia.

David Aiken Confidencial de Windows: Qué ven los nuevos usuarios en el menú Inicio

Imagínese que compra un equipo nuevo, que arranca Windows, hace clic en el botón Inicio y ve un menú en blanco. Hay una razón por la cual el menú Inicio incluye aplicaciones en la posición de elementos más usados antes de que se haya usado nada: para ofrecer una buena experiencia desde el principio. Averigüe cómo se eligen estas aplicaciones.

Raymond Chen Cartas: Respuestas a sus preguntas


 Seguridad : Estudio del control de cuenta de usuario (UAC) de Windows Vista
Seguridad Mark Russinovich

Estudio del control de cuenta de usuario (UAC) de Windows Vista
Resumen:
  • Ejecución como usuario estándar
  • Archivo y virtualización de Registro
  • Elevación del estado de la cuenta

El control de cuentas de usuario (UAC) es a menudo una característica mal comprendida en Windows Vista. En mi serie de TechNet Magazine de tres partes acerca de los cambios del núcleo de Windows Vista, disponible en línea en la dirección technetmagazine.com, no hablé de UAC porque sentía que se merecía su propio artículo.
En este artículo hablo de los problemas que UAC resuelve y describo la arquitectura y la implementación de las tecnologías de sus componentes. Entre estas tecnologías se incluyen la refactorización de las operaciones que anteriormente requerían derechos administrativos, la virtualización ligera para ayudar a los programas a ejecutarse correctamente sin derechos administrativos, la capacidad de los programas de solicitar explícitamente derechos administrativos y el aislamiento de los procesos administrativos de los procesos no administrativos que se ejecutan en el mismo escritorio de usuario.

Objetivo de UAC
UAC sirve para permitir a los usuarios ejecutar operaciones con derechos de usuario estándar, en contraposición con los derechos administrativos. Los derechos administrativos ofrecen a los usuarios la capacidad de leer y de modificar cualquier parte del sistema operativo, como por ejemplo, el código y los datos de otros usuarios, e incluso el propio Windows®. Sin derechos administrativos, los usuarios no pueden modificar de manera accidental (o deliberadamente) la configuración del sistema, el malware no puede modificar la configuración de seguridad del sistema ni deshabilitar software antivirus y los usuarios no pueden poner en peligro la información confidencial de otros usuarios en equipos compartidos. La ejecución con derechos de usuario estándar puede, por tanto, reducir las llamadas al departamento de soporte técnico urgentes en entornos corporativos, mitigar la repercusión del malware, mantener la ejecución sin problemas de los equipos domésticos y proteger los datos confidenciales de los equipos compartidos.
UAC tuvo que tratar varios problemas para que fuera práctica la ejecución con una cuenta de usuario estándar. En primer lugar, antes de Windows Vista™, el modelo del uso de Windows ha sido uno en que se suponían derechos administrativos. Los programadores de software suponían que sus programas podrían tener acceso y modificar cualquier archivo, clave de Registro o configuración del sistema operativo. Incluso cuando Windows NT® incorporó seguridad y diferenció entre accesos concedidos a cuentas de usuario estándar y administrativas, se guiaba a los usuarios a través de un proceso de configuración que les animaba a usar la cuenta de administrador integrada o una que fuera miembro del grupo Administradores.
El segundo problema que UAC tuvo que tratar fue que los usuarios a veces necesitan derechos administrativos para realizar operaciones como, por ejemplo, instalar software, cambiar la hora del sistema y abrir puertos en el firewall.
La solución de UAC para estos problemas es ejecutar la mayoría de las aplicaciones con derechos de usuario estándar, obviar la necesidad de los derechos de administrador todo el tiempo y animar a los programadores de software a crear aplicaciones que se ejecuten con derechos de usuario estándar. UAC alcanza estos objetivos al requerir derechos administrativos con menor frecuencia, habilitar las aplicaciones heredadas para que se ejecuten con derechos de usuario estándar, haciendo que sea adecuado para los usuarios estándar el acceso a los derechos administrativos cuando los necesitan, y habilitar incluso a los usuarios administrativos para que ejecuten como si fueran usuarios estándar.

Ejecución como usuario estándar
Durante una auditoría completa de todas las operaciones administrativas durante el desarrollo de Windows Vista se identificaron muchas que se podrían habilitar para los usuarios estándar sin poner en peligro la seguridad del sistema. Por ejemplo, incluso las corporaciones que adoptaron cuentas de usuario estándar para sus sistemas de escritorio de Windows XP no pudieron quitar a sus usuarios que viajan del grupo Administradores por la única razón de que Windows XP no diferencia entre cambiar la zona horaria y cambiar la hora del sistema. Un usuario de equipo portátil que desea configurar la zona horaria local para que sus citas se muestren correctamente en su calendario cuando viaja debe tener el privilegio "Cambiar la hora del sistema" (denominada internamente SeSystemTimePrivilege) que, de forma predeterminada, sólo se concede a administradores.
La hora se usa normalmente en protocolos de seguridad como Kerberos, pero la zona horaria sólo afecta a la manera en la que se muestra la hora, de modo que Windows Vista agrega un privilegio nuevo, "Cambiar la zona horaria" (SeTimeZonePrivilege) y lo asigna al grupo Usuarios, como se ve en la figura 1. Esto hace posible que en muchas corporaciones los usuarios de equipo portátil trabajen bajo cuentas de usuario estándar.
Figura 1 El privilegio “Cambiar la zona horaria”
Figura 1 El privilegio “Cambiar la zona horaria”
Windows Vista también permite a los usuarios estándar configurar los valores WEP cuando se conectan a redes inalámbricas, crean conexiones VPN, cambian la configuración de administración de energía e instalan actualizaciones críticas de Windows. Además, incorpora la configuración de directivas de grupo que permite a los usuarios estándar instalar controladores de impresora y otros dispositivos aprobados por administradores de TI e instalar controles ActiveX® de los sitios aprobados por el administrador.
¿Qué ocurre con las aplicaciones de línea de negocio y consumidor que no se ejecutan correctamente en cuentas de usuario estándar? Si bien algunos programas de software requieren legítimamente derechos administrativos, muchos programas almacenan innecesariamente datos de usuario en ubicaciones globales del sistema. Microsoft recomienda que los instaladores de aplicaciones globales que esperan ejecutar con derechos administrativos creen un directorio en el directorio %Archivos de programa% para almacenar los archivos ejecutables de la aplicación y los datos auxiliares y creen una clave en HKEY_LOCAL_EQUIPO\Software para la configuración de su aplicación. Cuando se ejecuta una aplicación, se puede ejecutar en diferentes cuentas de usuario y, por tanto, debería almacenar datos de usuario específicos en el directorio % AppData % por usuario y guardar la configuración por usuario en el perfil de Registro del usuario en HKEY_CURRENT_USER\ Software. Las cuentas de usuario estándar no tienen acceso de escritura al directorio %Archivos de programa% ni HKEY_LOCAL_MACHINE\Software pero, debido a que la mayoría de los sistemas de Windows son de un único usuario y la mayoría de los usuarios han sido administradores hasta Windows Vista, las aplicaciones que guardan incorrectamente datos de usuario y configuración en estas ubicaciones funcionan de todos modos.
Windows Vista permite que estas aplicaciones heredadas se ejecuten en cuentas de usuario estándar a través de la ayuda del sistema de archivos y de la virtualización del espacio de nombres del Registro. Cuando una aplicación modifica una ubicación global del sistema en el Registro o el sistema de archivos y hay un error en dicha operación porque se deniega el acceso, Windows redirecciona la operación a un área por usuario; cuando la aplicación lee desde una ubicación global del sistema, Windows comprueba primero los datos en el área por usuario y, si no hay ninguno presente, permite el intento de lectura desde la ubicación global.
Para esta virtualización, Windows Vista trata un proceso como heredado si es de 32 bits (frente a 64 bits), no se ejecuta con derechos administrativos y no tiene un archivo de manifiesto que indique que se escribió para Windows Vista. No se virtualiza ninguna operación cuyo origen no sea un proceso clasificado como heredado según esta definición, incluidos los accesos al recurso compartido de archivos de red. El estado de virtualización de un proceso se almacena como un indicador en su token, que es la estructura de datos del núcleo que realiza el seguimiento del contexto de seguridad de un proceso, incluida su cuenta de usuario, las pertenencias a grupos y los privilegios.
Puede consultar el estado de virtualización de un proceso si agrega la columna Virtualización a la página Procesos del Administrador de tareas. La figura 2 muestra que la mayoría de los componentes de Windows Vista, incluido el Administrador de ventanas del escritorio (Dwm.exe), el subsistema en tiempo de ejecución del cliente-servidor (Csrss.exe) y el Explorador, tienen la virtualización deshabilitada porque tienen un manifiesto de Windows Vista o se ejecutan con derechos administrativos y, por tanto, no admiten la virtualización. Internet Explorer® (iexplore.exe) tiene la virtualización habilitada porque puede alojar varias secuencias de comandos y controles ActiveX, y debe suponer que no se escribieron para funcionar correctamente con derechos de usuario estándar.
Figura 2 El Administrador de tareas muestra el estado de la virtualización
Figura 2 El Administrador de tareas muestra el estado de la virtualización
Las ubicaciones del sistema de archivos que están virtualizadas para procesos heredados son %Archivos de programa%, %ProgramData% y %SystemRoot%, excluyendo algunos subdirectorios específicos. Sin embargo, cualquier archivo con una extensión ejecutable, entre las que se incluyen .exe, .bat, .scr, .vbs, entre otras, se excluye de la virtualización. Esto significa que los programas que se actualizan desde una cuenta de usuario estándar tienen un error en lugar de crear versiones privadas de sus archivos ejecutables que no son visibles para un administrador que ejecuta un programa de actualización global. Para agregar extensiones adicionales a la lista de excepciones, especifíquelas en la siguiente clave del Registro y reinicie el equipo:
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Luafv\Parameters\ExcludedExtensionsAdd
Use un tipo de cadena múltiple para delimitar varias extensiones y no incluya un punto inicial en el nombre de extensión.
Las modificaciones a los directorios virtualizados por procesos heredados se redireccionan al directorio raíz virtual del usuario, %LocalAppData%\VirtualStore. Por ejemplo, si un proceso virtualizado que se ejecuta en mi sistema crea C:\Windows\Application.ini, el archivo que se crea realmente es C:\Users\Markruss\AppData\Local\VirtualStore\Windows\Application.ini. El componente Local de la ruta de acceso resalta el hecho de que los archivos virtualizados no serán itinerantes con el resto del perfil cuando la cuenta tiene un perfil móvil.
Si navega por el Explorador hasta un directorio que contiene archivos virtualizados, el Explorador muestra un botón con la etiqueta Archivos de compatibilidad en su barra de herramientas, tal como se muestra en la figura 3. Al hacer clic en el botón, navegará hasta el subdirectorio de VirtualStore correspondiente para mostrarle los archivos virtualizados.
Figura 3 El botón Archivos de compatibilidad indica los archivos virtualizados cercanos
Figura 3 El botón Archivos de compatibilidad indica los archivos virtualizados cercanos
La figura 4 muestra cómo el controlador de filtros de virtualización de archivos UAC (%SystemRoot%\System32\Drivers\Luafv.sys) implementa la virtualización del sistema de archivos. Debido a que se trata de un controlador de filtros del sistema de archivos, ve todas las operaciones del sistema de archivos pero sólo implementa la funcionalidad para operaciones desde procesos heredados. Puede ver que cambia la ruta del archivo de destino para un proceso heredado que crea un archivo en una ubicación global del sistema, pero no lo hace para un proceso que ejecuta una aplicación de Windows Vista con derechos de usuario estándar. El proceso heredado cree que la operación se realiza correctamente cuando realmente ha creado el archivo en una ubicación completamente accesible para el usuario, pero los permisos predeterminados en el directorio de Windows deniegan el acceso a la aplicación escrita para Windows Vista.
Figura 4 Virtualización del sistema de archivos
Figura 4 Virtualización del sistema de archivos
La virtualización del Registro se implementa de manera algo diferente a la virtualización del sistema de archivos. Entre las claves del Registro virtualizadas se incluyen la mayor parte de la rama HKEY_LOCAL_MACHINE\Software, pero hay numerosas excepciones como, por ejemplo, las siguientes:
HKLM\Software\Microsoft\Windows
HKLM\Software\Microsoft\Windows NT
HKLM\Software\Classes
Sólo se virtualizan las claves que están modificadas comúnmente por aplicaciones heredadas pero que no presentan problemas de compatibilidad ni interoperabilidad. Windows redirecciona las modificaciones de claves virtualizadas por una aplicación heredada a la raíz virtual del Registro de un usuario en HKEY_ CURRENT_USER\Software\Classes\VirtualStore. La clave se encuentra en el subárbol Classes del usuario, %LocalAppData%\Microsoft\Windows\UsrClass.dat que, como cualquier otro elemento de datos de archivo virtualizado, no será itinerante con un perfil de usuario móvil.
En lugar de mantener una lista fija de ubicaciones virtualizadas como lo hace Windows para el sistema de archivos, el estado de virtualización de una tecla se almacena como un indicador, REG_ KEY_DONT_VIRTUALIZE, en la propia clave. La utilidad Reg.exe puede mostrar el indicador así como los otros dos indicadores relacionados con la virtualización, REG_KEY_ DONT_SILENT_FAIL y REG_KEY_ RECURSE_FLAG, como se ve en la figura 5. Cuando se define REG_KEY_DONT_SILENT_FAIL y la clave no está virtualizada (REG_KEY_DONT_VIRTUALIZE está definida), a una aplicación heredada a la que se denegaría acceso para realizar una operación en la clave se le concede en su lugar cualquier acceso que el usuario tiene a la clave en lugar de las que la aplicación ha solicitado. REG_KEY_RECURSE_FLAG indica si las nuevas subclaves heredan los indicadores de virtualización del principal en lugar de únicamente los indicadores predeterminados.
Figura 5 La utilidad Reg muestra los indicadores de virtualización
Figura 5 La utilidad Reg muestra los indicadores de virtualización
En la figura 6 se muestra cómo el Administrador de configuración implementa la virtualización del Registro y administra el Registro en el núcleo del sistema operativo, Ntoskrnl.exe. Al igual que con la virtualización del sistema de archivos, se redirecciona un proceso heredado que crea una subclave de una clave virtualizada a la raíz virtual del Registro del usuario pero a un proceso de Windows Vista se le deniega el acceso por permisos predeterminados.
Además del sistema de archivos y de la virtualización del Registro, algunas aplicaciones requieren ayuda adicional para ejecutarse correctamente con derechos de usuario estándar. Por ejemplo, una aplicación que prueba la cuenta en la que se ejecuta para la pertenencia al grupo Administradores puede funcionar, pero no se ejecutará si no se encuentra en dicho grupo. Por tanto, Windows Vista define varias correcciones de compatibilidad (shim) de aplicaciones para que dichas aplicaciones funcionen de todos modos. Las correcciones de compatibilidad (shim) que se aplican a las aplicaciones heredadas para el funcionamiento con derechos estándar se muestran en la figura 7. Los profesionales de TI corporativos pueden usar herramientas como el kit de herramientas de compatibilidad de aplicaciones (ACT, disponible en technet.microsoft.com/windowsvista/aa905066.aspx) y su utilidad Standard User Analyzer (SUA) o LUA Buglight de Aaron Margosis para identificar los requisitos de correcciones de compatibilidad (shim) para su aplicaciones de línea de negocio. Asignan correcciones de compatibilidad (shim) a una aplicación mediante el Administrador de compatibilidad, que también forma parte del ACT y, a continuación, implementan la base de datos de compatibilidad resultante (archivo .sdb) a sus escritorios mediante la directiva de grupo. Tenga en cuenta que, si fuera necesario, se puede deshabilitar la virtualización por completo para un sistema que usa una configuración de directiva de seguridad local.
Figure 7 Correcciones de compatibilidad (shim) de usuario comunes (Close Figure 7)

Corrección de compatibilidad (shim) | Propósito
ElevateCreateProcess | Cambia CreateProcess para tratar los errores ERROR_ELEVATION_REQUIRED al llamar al Servicio de información de aplicaciones para pedir la elevación.
ForceAdminAccess | Simula consultas de pertenencia a grupos de administrador.
VirtualizeDeleteFile | Simula la eliminación correcta de directorios y archivos globales.
LocalMappedObject | Obliga la colocación de los objetos de sección global al espacio de nombres del usuario.
VirtualizeHKCRLite, VirtualizeRegisterTypeLib | Redirecciona el registro global de objetos COM a una ubicación por usuario.
Efectos de la virtualización
Puede cambiar el estado de la virtualización de un proceso si selecciona Virtualización del menú contextual que aparece al hacer clic con el botón secundario en el Administrador de tareas. En la figura A se muestra el comportamiento de un símbolo del sistema cuando cambia su estado de virtualización. Empieza con la virtualización deshabilitada porque tiene un manifiesto de Windows Vista. Debido a que se ejecuta con derechos de usuario estándar, no puede crear un archivo en el directorio \Windows pero, después de que se virtualiza mediante el Administrador de tareas, parece que crea el archivo correctamente. Cuando su virtualización vuelve a su estado deshabilitado, no encuentra el archivo, que en realidad está en el almacén virtual del usuario.
Figura A Un cambio del estado de virtualización
Figura A Un cambio del estado de virtualización

Modo de aprobación del administrador
Aunque los usuarios ejecutan únicamente programas compatibles con derechos de usuario estándar, algunas operaciones todavía requieren derechos administrativos. La inmensa mayoría de las instalaciones de software requieren derechos de administrador para crear directorios y claves de Registro en ubicaciones globales del sistema o para instalar servicios o controladores de dispositivos. La modificación de la configuración global del sistema de aplicaciones y Windows también requiere derechos administrativos, al igual que la característica de control parental de Windows Vista. Sería posible realizar la mayor parte de estas operaciones si se cambia a una cuenta de administración dedicada; pero el inconveniente de hacerlo es que la mayoría de los usuarios permanecería en la cuenta administrativa para realizar sus tareas diarias.
Por tanto, Windows Vista incluye la funcionalidad mejorada "ejecutar como" de modo que los usuarios estándar pueden iniciar procesos de manera conveniente con derechos administrativos. Esta funcionalidad requería ofrecer a las aplicaciones una manera de identificar las operaciones para las que el sistema puede obtener derechos administrativos en nombre de la aplicación según sea necesario, lo cual describiré en breve.
Además, para que los usuarios que actúan como administradores del sistema puedan ejecutar con derechos de usuario estándar, pero sin tener que especificar nombres de usuario y contraseñas cada vez que desean tener acceso a derechos administrativos, Windows Vista presenta el Modo de aprobación de administrador (AAM). Esta característica crea dos identidades para el usuario al iniciar una sesión: una, con derechos de usuario estándar y otra, con derechos administrativos. Puesto que cada usuario de un sistema de Windows Vista es un usuario estándar o ejecuta la mayoría de las veces como usuario estándar en AAM, los programadores deben suponer que todos los usuarios de Windows son usuarios estándar, lo que dará lugar a más programas trabajando con derechos de usuario estándar sin virtualización o correcciones de compatibilidad (shim).
La concesión de derechos administrativos a un proceso se denomina elevación. Cuando la realiza una cuenta de usuario estándar, se denomina elevación de supervisión continua (OTS) porque requiere la entrada de credenciales para una cuenta que es miembro del grupo del administrador, algo que ha completado generalmente otro usuario escribiendo mientras supervisa al usuario estándar. Una elevación realizada por un usuario de AAM se denomina elevación de consentimiento porque el usuario sólo tiene que aprobar la asignación de sus derechos administrativos.
Windows Vista considera administrador a un usuario si dicho usuario es miembro de cualquier grupo del tipo administrador que se incluye en la lista de la figura 8. Muchos de los grupos incluidos en la lista se usan sólo en sistemas unidos por un dominio y que no conceden directamente derechos administrativos locales a los usuarios pero les permiten modificar la configuración para todo el dominio. Si un usuario es miembro de cualquiera de esos grupos, pero no del grupo Administradores real, el usuario obtiene acceso a sus derechos administrativos mediante elevaciones OTS en lugar de mediante elevaciones de consentimiento.
Figure 8 Grupos administrativos (Close Figure 8)

Administradores integrados
Administradores certificados
Administradores de dominios
Administradores de empresa
Administradores de directivas
Administradores de esquemas
Controladores de dominio
Controladores de dominio de sólo lectura de empresa
Controladores de dominio de sólo lectura
Operadores de cuentas
Operadores de copia de seguridad
Operadores de cifrado
Operadores de configuración de red
Operadores de impresión
Operadores de sistema
Servidores RAS
Usuarios avanzados
Acceso compatible con versiones anteriores de Windows 2000
Cuando inicia sesión un usuario que pertenece a uno de los grupos incluidos en una lista, Windows Vista crea un token que representa la versión del usuario estándar de la identidad administrativa del usuario. Al nuevo token se le quitan todos los privilegios asignados al usuario excepto los incluidos en una lista de la figura 9, que son los privilegios de usuario estándar predeterminados. Además, cualquiera de los grupos de tipo administrador está marcado con el indicador USE_FOR_DENY_ONLY en el nuevo token. La figura 10 muestra Sysinternals Process Explorer (una herramienta de administración de procesos que se puede descargar desde la dirección microsoft .com/technet/sysinternals) y que muestra los privilegios y las pertenencias a grupos de un proceso que se ejecuta con derechos administrativos a la izquierda y sin derechos de administrador a la derecha. (Para impedir un uso involuntario, el modelo de seguridad de Windows requiere que se habilite un privilegio con el indicador deshabilitado para poder usarlo).
Figure 9 Privilegios de usuario estándar (Close Figure 9)

Nombre descriptivo | Nombre interno
Omitir comprobación de recorrido | SeChangeNotifyPrivilege
Apagar el sistema | SeShutdownPrivilege
Eliminar el equipo de la estación de acoplamiento | SeUndockPrivilege
Aumentar un espacio de trabajo del proceso | SeIncreaseWorkingSetPrivilege
Cambiar la zona horaria | SeTimeZonePrivilege
Figura 10 Administrador de AAM y token de usuario estándar
Figura 10 Administrador de AAM y token de usuario estándar
Un grupo con el indicador deny-only únicamente se puede usar para denegar al usuario el acceso a un recurso, nunca admitirlo, solucionando una carencia en la seguridad que se podría crear si, en cambio, el grupo se eliminase por completo. Por ejemplo, si un archivo tenía una lista de control de acceso (ACL) que denegó todo el acceso al grupo Administradores pero concedió algún acceso a otro grupo al que pertenece el usuario, a éste se le concedería acceso si el grupo de administradores estuviera ausente del token, ofreciendo a la versión de usuario estándar de la identidad del usuario una mayor acceso que a su identidad de administrador.
Los sistemas independientes, que son típicamente equipos domésticos, y los sistemas unidos por un dominio tratan el acceso de AAM por usuarios remotos de manera diferente debido a que los equipos conectados por un dominio pueden usar grupos administrativos de dominio en sus permisos de recursos. Cuando un usuario tiene acceso a un recurso compartido de archivos de un equipo independiente, Windows solicita la identidad de usuario estándar del usuario remoto pero en los sistemas unidos por un dominio, Windows respeta todas las pertenencias a grupos de dominio del usuario al solicitar la identidad administrativa del usuario.

Acceso útil a los derechos administrativos
Hay varias maneras para que el sistema y las aplicaciones identifiquen una necesidad de derechos administrativos. Una que aparece en la IU del Explorador es la opción de acceso directo y la entrada de menú contextual "Ejecutar como administrador". Estos elementos incluyen un icono con forma de escudo que debería colocarse en cualquier botón o elemento de menú que daría lugar a una elevación de derechos cuando esté seleccionado. Al elegir la entrada "Ejecutar como administrador", el Explorador llama a la API de ShellExecute con el verbo "runas".
La inmensa mayoría de los programas de instalación requiere derechos administrativos, de modo que el cargador de imágenes, que empieza el inicio de un archivo ejecutable, incluye el código de detección del instalador para identificar probables instaladores heredados. Parte de la heurística que usa es tan sencilla como detectar si la imagen tiene las palabras configuración, instalación o actualización en su nombre de archivo o información de versión interna; las más sofisticadas implican la exploración de secuencias de byte en el archivo ejecutable que son comunes a utilidades de terceros de contenedor de instalación.
El cargador de imágenes también llama a la biblioteca de compatibilidad de aplicaciones (appcompat) para ver si el archivo ejecutable de destino requiere derechos de administrador. La biblioteca mira en la base de datos de compatibilidad de aplicaciones para ver si el archivo ejecutable tiene los indicadores de compatibilidad RequireAdministrator o RunAsInvoker asociados a él.
La manera más común de que un archivo ejecutable solicite derechos administrativos es incluir una etiqueta requestedElevationLevel en su archivo de manifiesto de aplicación. Los manifiestos son archivos XML que contienen información complementaria acerca de una imagen. Se presentaron en Windows XP como una manera de identificar las dependencias en los ensamblados de Microsoft .NET Framework y DLL en paralelo. La presencia del elemento trustInfo en un manifiesto (que se puede consultar en el volcado de cadenas extraído de Firewallsettings.exe a continuación), indica un archivo ejecutable que se escribió para Windows Vista y los nidos del elemento requestedElevationLevel incluidos. El atributo del nivel del elemento puede tener uno de los tres valores siguientes: asInvoker, highestAvailable y requireAdministrator.
<trustInfo
 xmlns=”urn:schema-microsoft-com:asm.v3”>
 <security>
  <requestedPrivileges>
   <requestedExecutionLevel
    Level=”requireAdministrator”
    uiAccess=”false”/>
  </requestedPrivileges>
 </security>
</trustInfo>
Los archivos ejecutables sin ninguna necesidad de derechos administrativos, como Notepad.exe, especifican el valor asInvoker. Algunos archivos ejecutables esperan que los administradores siempre deseen el máximo acceso, de manera que usen el valor highestAvailable. A un usuario que ejecuta un archivo ejecutable con dicho valor se le pedirá elevar sólo si ejecuta en AAM o si se considera un administrador según las reglas definidas anteriormente y debe elevar para tener acceso a sus derechos administrativos. Regedit.exe, Mmc.exe y Eventvwr.exe son ejemplos de aplicaciones que usan highestAvailable. Por último, requireAdministrator siempre produce una solicitud de elevación y se usa por cualquier archivo ejecutable que tenga un error al operar sin derechos administrativos.
Las aplicaciones de accesibilidad especifican "true" para el atributo uiAccess con el fin de controlar la entrada de ventana de procesos elevados y también deben estar firmadas y en una de las distintas ubicaciones seguras, entre las que se incluyen %SystemRoot% y %Archivos de programa%, para obtener dicho poder.
Una manera sencilla de determinar los valores especificados por un archivo ejecutable es ver su manifiesto con la utilidad Sysinternals Sigcheck, tal como se muestra a continuación:
sigcheck –m <executable>
La ejecución de una imagen que solicita derechos administrativos hace que el Servicio de información de aplicaciones (también conocido como AIS, incluido en %SystemRoot%\System32\Appinfo.dll), que se ejecuta dentro de un proceso de host de servicio (%SystemRoot%\System32\Svchost .exe), inicie Consent.exe (%SystemRoot%\System32\Consent.exe). El consentimiento captura un mapa de bits de la pantalla, le aplica un efecto de atenuación, conmuta a un escritorio al que sólo se tiene acceso por la cuenta del sistema local, pinta el mapa de bits como el segundo plano y muestra un cuadro de diálogo de elevación que contiene información acerca del archivo ejecutable. La visualización en un escritorio independiente impide que cualquier malware presente en la cuenta del usuario modifique el aspecto del cuadro de diálogo.
Figura 11 Cuadros de diálogo de elevación de OTS
Figura 11 Cuadros de diálogo de elevación de OTS
Si una imagen es un componente de Windows firmado digitalmente por Microsoft y la imagen se encuentra en el directorio del sistema Windows, el cuadro de diálogo muestra una banda azul en la parte superior, tal como se muestra en la figura 11. La banda gris (el cuadro de diálogo intermedio) es para las imágenes firmadas digitalmente por alguien ajeno a Microsoft y la banda naranja (el cuadro de diálogo inferior) es para imágenes sin firmar. El cuadro de diálogo de elevación muestra el icono, la descripción y el editor de la imagen para las imágenes firmadas digitalmente. Para las imágenes sin firmar, sólo muestra un icono genérico, el nombre del archivo y "Editor no identificado". Esto hace que para el malware sea más difícil imitar el aspecto de software legítimo. El botón Detalles de la parte inferior del cuadro de diálogo se expande para mostrar la línea de comandos que se pasará al archivo ejecutable si se inicia. El cuadro de diálogo de consentimiento de AAM, que se muestra en la figura 12, es similar pero, en lugar de pedir credenciales de administrador, tiene los botones Continuar y Cancelar.
Figura 12 Cuadro de diálogo de elevación de AAM
Figura 12 Cuadro de diálogo de elevación de AAM
Si un usuario rechaza una elevación, Windows devuelve un error de acceso denegado al proceso que empezó el inicio. Cuando un usuario acepta una elevación al especificar credenciales de administrador o al hacer clic en Continuar, AIS llama a CreateProcessAsUser para iniciar el proceso con la identidad administrativa apropiada. Aunque AIS sea técnicamente el padre del proceso elevado, AIS usa nuevo soporte en la API de CreateProcessAsUser que establece el Id. de proceso principal de dicho proceso al del proceso que lo inició originalmente (consulte la figura 13). Ese es el motivo por el que los procesos elevados no aparecen como hijos del proceso de alojamiento de servicio de AIS en herramientas como Process Explorer que muestra árboles del proceso.
Figura 13 Flujo de elevación
Figura 13 Flujo de elevación
Aunque los cuadros de diálogo de elevación aparezcan en un escritorio seguro independiente, de forma predeterminada, los usuarios no tienen ninguna manera de comprobar que están visualizando un cuadro de diálogo legítimo y no uno presentado por malware. Eso no supone un problema para AAM porque el malware no puede obtener derechos administrativos con un cuadro de diálogo de consentimiento falso. Sin embargo, el malware podría esperar la elevación OTS de un usuario estándar, interceptarlo y usar un cuadro de diálogo de caballo de Troya para capturar las credenciales de administrador. Con dichas credenciales pueden obtener acceso a la cuenta del administrador e infectarla.
Por este motivo, las elevaciones de OTS no son nada recomendables en entornos corporativos. Para deshabilitar elevaciones de OTS, y así reducir las llamadas al servicio de soporte técnico, ejecute el editor de directivas de seguridad local (Secpol.msc) y configure "Control de cuentas de usuario: comportamiento del indicador de elevación para los usuarios estándar" en "Rechaza solicitudes de elevación automáticamente".
Los usuarios de equipos domésticos conscientes de la seguridad deben configurar las elevaciones de OTS para requerir una secuencia de aviso de seguridad (SAS) que el malware no pueda interceptar ni simular. Para configurar SAS, ejecute el Editor de directivas de grupo (Gpedit.msc), navegue hasta Configuración del equipo | Plantillas administrativas | Componentes de Windows | Interfaz de usuario de credenciales, y habilite "Requerir ruta de acceso de confianza para la entrada de credenciales". Después que hacerlo, deberá presionar Ctrl+Alt+Supr para tener acceso al cuadro de diálogo de elevación.

Aislamiento de los procesos elevados
Windows Vista coloca una barrera alrededor de los procesos elevados para protegerlos de la ejecución de malware que se ejecuta en el mismo escritorio con derechos de usuario estándar. Sin una barrera, el malware podría controlar una aplicación administrativa enviándole entradas de ventana y mouse sintetizadas mediante mensajes de ventana. Y, aunque el modelo de seguridad de Windows estándar impide que la ejecución de malware en un proceso con derechos de usuario estándar modifique un proceso elevado que se ejecute como un usuario diferente, no impide que la ejecución de malware como la versión de derechos estándar de un usuario administrativo abra los procesos elevados del usuario, inyectándoles código, e iniciando subprocesos en ellos para ejecutar el código inyectado.
El escudo de Windows Vista para mensajes de ventana se denomina aislamiento de privilegios en la interfaz de usuario (UIPI). Se basa en el nuevo mecanismo de integridad de Windows que Windows Vista usa también como barrera alrededor de procesos elevados. En este nuevo modelo de seguridad, todos los procesos y los objetos tienen niveles de integridad, y la directiva de integridad de un objeto puede restringir los accesos que de otro modo se concederían a un proceso mediante el modelo de seguridad de control de acceso discrecional (DAC) de Windows.
Los niveles de integridad (IL) están representados por identificadores de seguridad (SID), que también representan usuarios y grupos, donde el nivel está codificado en el identificador relativo del SID (RID). En la figura 14 se muestra el nombre para mostrar, el SID y la versión hexadecimal del RID del SID para los cuatro IL principales. Los números hexadecimales revelan intervalos de 0x1000 entre cada nivel que permite el uso de los niveles intermedios por las aplicaciones de accesibilidad de IU así como el crecimiento futuro.
Figure 14 Niveles de integridad principales (Close Figure 14)

Nombre | SID | RID
Nivel obligatorio bajo | S-1-16-4096 | 0x1000
Nivel obligatorio medio | S-1-16-8192 | 0x2000
Nivel obligatorio alto | S-1-16-12288 | 0x3000
Nivel obligatorio del sistema | S-1-16-16384 | 0x4000
En la figura 15 se incluye una lista las directivas de IL de objeto y los tipos de acceso que restringen, que corresponden a los accesos genéricos definidos para un objeto. Por ejemplo, No-Write-Up impide que un proceso de IL inferior obtenga cualquiera de los accesos representados por los accesos de GENERIC_WRITE. La directiva predeterminada para la mayoría de los objetos, entre los que se incluyen archivos y claves de registro, es No-Write-Up, que impide que un proceso obtenga acceso de escritura a objetos que tengan un IL superior a él mismo, incluso si la lista de control de acceso discrecional (DACL) del objeto concede al usuario dicho acceso. Los únicos objetos con una directiva diferente son los objetos de proceso y subproceso. Su directiva, No-Write-Up más No-Read-Up, detiene un proceso que se ejecuta en un IL inferior para que no inyecte código ni lea datos, tales como contraseñas, fuera de un proceso que tenga un IL superior.
Figure 15 Directivas de nivel de integridad (Close Figure 15)

Directiva | Efecto
No-Write-Up | Un proceso de IL inferior no puede modificar un objeto de IL superior
No-Read-Up | Un proceso de IL inferior no puede leer de un objeto de IL superior
No-Execute-Up | Un proceso de IL inferior no puede ejecutar un objeto de IL superior
Windows asigna a cada proceso un IL que coloca en el token del proceso junto con los SID de los grupos a los que pertenece el usuario que ejecuta el proceso. En la figura 16 se incluye una lista con los ejemplos de los procesos asignados a diferentes IL. Los procesos suelen heredar el IL de su padre pero un proceso también puede iniciar otro proceso en un IL diferente, como lo hace AIS cuando inicia un proceso elevado. Es posible ver los niveles de integridad del proceso con la utilidad Whoami integrada si se especifica la opción /all, o bien mediante Sysinternals Process Explorer o AccessChk. Process Explorer puede mostrar los IL del proceso con la adición de la columna de nivel de integridad.
Figure 16 Asignación de nivel de integridad de proceso de ejemplo (Close Figure 16)

Nivel de integridad | Procesos de ejemplo
Nivel obligatorio bajo | Internet Explorer de modo protegido y los procesos iniciados por Internet Explorer de modo protegido
Nivel obligatorio medio | Usuario estándar y procesos de AAM no elevados
Nivel obligatorio alto | Procesos que se ejecutan con derechos administrativos
Nivel obligatorio del sistema | Procesos de Sistema local, Servicio local y Servicio de red
Cada objeto asegurable tiene un IL explícito o implícito. El proceso, el subproceso y los objetos de token siempre tienen un IL explícitamente asignado que suele ser el mismo que el IL almacenado en el token del proceso correspondiente. La mayoría de los objetos no tienen IL explícito y, por tanto, se vuelven de manera predeterminada a un IL de medio. Los únicos objetos creados con un IL distinto al medio son los objetos creados por un proceso que se ejecuta en el IL bajo, que por tanto tiene un IL bajo. Puede usar la herramienta iCacls integrada (%SystemRoot%\System32\iCacls.exe) para ver los IL de archivos y la utilidad Sysinternals AccessChk para ver los ILs de archivos, claves de Registro, servicios y procesos. La figura 17 revela que el IL de un directorio que necesita ser accesible por Internet Explorer de modo protegido es bajo.
Figura 17 AccessChk que muestra el IL del directorio de favoritos de un usuario
Figura 17 AccessChk que muestra el IL del directorio de favoritos de un usuario
Si un objeto tiene un IL explícito, se almacena en una entrada de control de acceso (ACE) de un tipo nuevo para Windows Vista, la ACE de etiqueta, en la lista de sistema de acceso (SACL) del descriptor de seguridad del objeto (consulte la figura 18). El SID de la ACE corresponde al IL del objeto y los indicadores de ACE codifican la directiva de integridad del objeto. Antes de Windows Vista, las SACL almacenaban únicamente las ACE de auditoría, que requieren el privilegio "Administrar registro de seguridad y auditoría" (SeSecurityPrivilege), pero la lectura de una ACE de etiqueta sólo requiere acceso de permisos de lectura (READ_CONTROL). Para que un proceso modifique el IL de un objeto, debe tener acceso de Cambiar el propietario (WRITE_OWNER) para el objeto y un IL que sea igual o mayor que el objeto, y el proceso sólo puede establecer el IL como su propio IL o inferior. El nuevo privilegio "Modificar la etiqueta de un objeto" (SeRelabelPrivilege) ofrece a un proceso la capacidad de cambiar el IL de cualquier objeto al que el proceso tiene acceso e incluso elevar el IL por encima del IL propio del proceso, pero de forma predeterminada no se asigna dicho privilegio a ninguna cuenta.
Figura 18 ACE de etiqueta de un objeto
Figura 18 ACE de etiqueta de un objeto
Cuando un proceso intenta abrir un objeto, se produce la comprobación de integridad antes de la comprobación de DACL de Windows estándar en la función SeAccessCheck del núcleo. Dadas las directivas de integridad predeterminadas, un proceso sólo puede abrir un objeto para acceso de escritura si su IL es igual o mayor que el IL del objeto y la DACL también concede al proceso los accesos que desea. Por ejemplo, un proceso de IL bajo no puede abrir un proceso de IL medio para acceso de escritura, incluso aunque el DACL conceda el acceso de escritura del proceso.
Con la directiva de integridad predeterminada, los procesos pueden abrir cualquier objeto, a excepción de los objetos de proceso y subproceso, para acceso de lectura siempre que la DACL del objeto les conceda acceso de lectura. Eso significa que un proceso que se ejecuta en IL bajo puede abrir archivos accesibles para la cuenta de usuario en la que se ejecuta. Internet Explorer de modo protegido usa IL para ayudar a impedir que el malware lo infecte al modificar la configuración de la cuenta de usuario, pero no impide que el malware lea documentos del usuario.
Los objetos de proceso y subproceso son excepciones porque su directiva de integridad también incluye No-Read-Up. Eso significa que el IL de un proceso debe ser igual o superior al IL del proceso o subproceso que desea abrir y la DACL debe concederle los accesos que desea para que uno abierto sea correcto. Suponiendo que las DACL admitan el acceso deseado, la figura 19 muestra los accesos que los procesos que ejecutan en medio y bajo tienen a otros procesos y objetos.
Figura 19 Accesos de objetos y procesos
Figura 19 Accesos de objetos y procesos
El subsistema de mensajería de Windows también respeta los niveles de integridad para implementar UIPI al impedir que un proceso envíe todos los mensajes de ventanas informativas, salvo algunos, a las ventanas que son propiedad de un proceso con un IL superior. Eso no permite que los procesos de usuario estándar controlen la entrada en las ventanas de procesos elevados o que rompan un proceso elevado enviándole mensajes con formato incorrecto que desencadenen desbordamientos de búfer internos. Los procesos pueden elegir admitir que mensajes adicionales pasen la guardia al llamar a la API de ChangeWindowMessageFilter. UIPI también bloquea enlaces de ventana para que no afecten a las ventanas de procesos de IL superior de manera que el proceso de un usuario estándar no pueda registrar las pulsaciones de tecla que el usuario escribe en una aplicación administrativa, por ejemplo.

Límites de elevaciones y seguridad
Es importante ser consciente de que las elevaciones de UAC son comodidades y no límites de seguridad. Un límite de seguridad requiere que la directiva de seguridad dicte qué puede pasar a través del límite. Las cuentas de usuario son un ejemplo de límite de seguridad en Windows porque un usuario no puede tener acceso a los datos que pertenecen a otro usuario sin tener el permiso de dicho usuario.
Debido a que las elevaciones no son límites de seguridad, no hay garantía de que un malware que se ejecute en un sistema con derechos de usuario no ponga en peligro un proceso elevado para obtener derechos administrativos. Por ejemplo, los cuadros de diálogo de elevación sólo identifican el archivo ejecutable que se elevará; no dicen nada acerca de lo que hará cuando se ejecute. El archivo ejecutable procesará los argumentos de la línea de comandos, cargará archivos DLL, abrirá archivos de datos y se comunicará con otros procesos. Cabe la posibilidad de que cualquiera de esas operaciones podría admitir que malware pusiera en peligro el proceso elevado y obtuviera así derechos administrativos.
Reproducción en un recinto de IL bajo
Internet Explorer de modo protegido se ejecuta en IL bajo para crear una barrera alrededor del malware que quizá infecte a su proceso. Esto impide que malware cambie la configuración de la cuenta del usuario y se instale en una ubicación de inicio automático. Puede usar la utilidad Sysinternals PsExec, junto con el conmutador -l, para iniciar los procesos arbitrarios en el IL bajo para explorar el recinto. En la figura B se muestra cómo un símbolo del sistema que se ejecuta en IL bajo no puede crear un archivo en el directorio temporal del usuario, que tiene un IL medio, pero puede hacerlo en el directorio temporal de Internet Explorer, que tiene un IL bajo.
Figura BEl símbolo del sistema sólo puede crear los archivos en un IL similar

Los procesos de AAM elevados son especialmente susceptibles de verse puestos en peligro porque se ejecutan en la misma cuenta de usuario que los procesos de derechos estándar del usuario de AAM y comparten el perfil del usuario. Muchas aplicaciones leen la configuración y cargan las extensiones registradas en el perfil de un usuario, ofreciendo oportunidades para que se eleve el malware. Por ejemplo, los cuadros de diálogo de control comunes cargan las extensiones de Shell configuradas en la clave de Registro de un usuario (bajo HKEY_CURRENT_USER), de manera que el malware puede agregarse como una extensión para cargarse en cualquier proceso elevado que use dichos cuadros de diálogos.
Incluso los procesos elevados de cuentas de usuario estándar pueden verse en peligro a causa del estado compartido. Todos los procesos que se ejecutan en una sesión de inicio comparten el espacio de nombres interno en el que Windows almacena objetos como, por ejemplo, eventos, exclusiones mutuas, semáforos y memoria compartida. Si el malware sabe que un proceso elevado tratará de abrir y de leer un objeto de memoria compartido específico cuando se inicie el proceso, podría crear el objeto con contenido que desencadene un desbordamiento del búfer para inyectar código en el proceso elevado. Ese tipo de ataque es relativamente sofisticado pero su posibilidad impide que las elevaciones de OTS sean un límite de seguridad.
Lo fundamental es que las elevaciones se presentaron como una comodidad que anima a los usuarios que desean tener acceso a derechos administrativos para que ejecuten con derechos de usuario estándar de manera predeterminada. Los usuarios que desean que las garantías de un límite de seguridad puedan equilibrar la comodidad usando una cuenta de usuario estándar para las tareas diarias y Cambio rápido de usuario (FUS) a una cuenta de administrador dedicada para realizar las operaciones administrativas. Por otro lado, los usuarios que deseen renunciar a la seguridad en favor de la comunidad puede deshabilitar UAC en un sistema en el cuadro de diálogo Cuentas de usuario del Panel de control, pero deben ser conscientes de que esto deshabilita además el Modo protegido de Internet Explorer.

Conclusión
La ejecución como usuario estándar tiene numerosos beneficios, entre los que se incluyen la ayuda para proteger los sistemas de daños accidentales o deliberados, y de proteger los datos y la integridad de los usuarios que comparten un sistema del acceso no autorizado. Las tecnologías y los distintos cambios de UAC tendrán como resultado un cambio principal en el modelo de uso de Windows. Con Windows Vista, los usuarios de Windows pueden realizar por primera vez la mayoría de las tareas diarias y ejecutar la mayor parte del software usando derechos de usuario estándar, y muchas corporaciones pueden ahora implementar cuentas de usuario estándar.

Mark Russinovich es empleado técnico de Microsoft en la división de servicios y plataformas. Es coautor de Microsoft Windows Internals (Microsoft Press, 2004) y orador frecuente en conferencias de programadores y TI. Se unió a Microsoft con la adquisición reciente de la compañía que cofundó, Winternals Software. También creó Sysinternals, donde publicó las utilidades Process Explorer, Filemon y Regmon
© 2007 Microsoft Corporation and CMP Media, LLC. Reservados todos los derechos; queda prohibida la reproducción parcial o total sin previa autorización.


 Seguridad: Claves para la protecci&#243;n de datos con Cifrado de unidad BitLocker
Seguridad Byron Hynes

Claves para la protección de datos con Cifrado de unidad BitLocker
Resumen:
  • Cifrado de volumen completo
  • Claves de BitLocker
  • Configuración de BitLocker

El Cifrado de unidad BitLocker de Windows es sin duda una de las características más mencionadas en Windows Vista. Sin embargo, la mayoría de las personas todavía no tuvieron demasiada oportunidad de probar BitLocker para averiguar directamente
qué hace y cómo funciona, especialmente en un equipo con un Módulo de plataforma segura (TPM). En este artículo, le presentaré los principios de BitLocker™ para que pueda evaluar su potencial e incluirlo en su planeamiento de actualización. Empezaré con información previa y conceptual, y analizaré a continuación la habilitación de BitLocker, la recuperación de datos, la administración y cómo BitLocker puede ser útil al final de la vida de un equipo. Para entender mejor la terminología de este artículo, examine la barra lateral "Discos y volúmenes".
Discos y volúmenes
La terminología sobre discos y volúmenes con frecuencia suele ser confusa. Este es un glosario abreviado para su referencia.
Partición Una partición es una sección de un disco duro físico. Se trata de una estructura lógica definida en una tabla de partición almacenada en el disco.
Volumen Un volumen es una estructura lógica en Windows compuesta de una o más particiones y definida por un componente de Windows llamado administrador de volúmenes. Con excepción del administrador de volúmenes y los componentes de inicio, el resto del sistema operativo y las aplicaciones trabajan con volúmenes, no con particiones. En el caso de los sistemas operativos cliente de Windows, incluido Windows Vista, las particiones y los volúmenes normalmente tienen una relación de uno a uno. En servidores, un volumen está compuesto frecuentemente de múltiples particiones, tal como en una configuración típica de RAID.
Partición activa Sólo una partición a la vez puede ser marcada como la partición activa. Se trata de la partición que contiene el sector de inicio usado para iniciar el sistema operativo. La partición activa se denomina a veces partición de sistema o volumen del sistema, pero no confunda estos términos con Volumen del sistema operativo Windows.
Volumen del sistema operativo Windows Este volumen contiene la instalación de Windows, incluidas las carpetas System y System32. Antes del lanzamiento de Windows Vista, se usaba el término partición de inicio (y todavía se usa a menudo). El término volumen del sistema operativo Windows es más claro y evita la confusión interminable entre partición de inicio y partición de sistema. En los viejos tiempos, los instructores algunas veces les decían a sus estudiantes que recordaran que "el inicio se realiza desde la partición de sistema y los archivos de sistema se encuentran en la partición de inicio".
Antes de Windows Vista, el volumen del sistema operativo Windows (también conocido como la partición de inicio) y la partición activa (también conocida como la partición de sistema) eran la misma cosa, porque en la mayoría de los equipos cliente los discos duros se configuraban como una única partición de gran tamaño. En la figura A puede observar las funciones asignadas a cada partición o volumen en la consola de Administración de discos en Windows Vista.
Figura A Funciones de partición
Figura A Funciones de partición

BitLocker en realidad hace dos cosas que son complementarias pero diferentes. En primer lugar, BitLocker ofrece cifrado de volumen completo en el volumen del sistema operativo Windows®. En segundo lugar, en equipos con un TPM compatible, BitLocker ofrece una manera de validar la integridad de los primeros componentes de inicio, antes de permitir que se inicie Windows Vista™.
Para usar toda la funcionalidad de BitLocker, su equipo debe tener un microchip y un BIOS compatible con TPM. Compatible significa una versión 1.2 de TPM y un BIOS compatible con TPM y la raíz estática de la medida de confianza según la definición del Trusted Computing Group (TCG). Sin embargo, los equipos sin TPM y BIOS compatibles aún pueden usar el cifrado de BitLocker.

Cifrado de volumen completo
BitLocker ofrece cifrado de volumen completo para garantizar que todos los datos escritos en el volumen del sistema operativo Windows sean cifrados. Esto es fundamental para proteger la información confidencial almacenada en los equipos de la organización, especialmente en equipos portátiles y móviles.
Los equipos móviles se pierden o son robados todos los días. Con una capacidad informática portátil en aumento y una fuerza de trabajo cada vez más móvil, un único trabajador puede transportar centenares de gigabytes de secretos comerciales de la organización, documentos confidenciales o información de identificación personal de clientes (PII). Cualquier búsqueda en las noticias le informará que se han perdido demasiados datos. (Privacy Rights Clearinghouse afirma que más de 104 millones de registros con información personal se han perdido o divulgado sólo desde 2005).
La mayoría de las organizaciones ya cuentan con exigencias legales y corporativas para proteger distintos tipos de información privada; y aunque aún no tenga exigencias legales, probablemente tiene un interés comercial de peso para hacerlo.

¿Por qué cifrar el volumen completo?
Si es un administrador experimentado de Windows, probablemente ya está familiarizado con las opciones de cifrado basadas en Windows tales como el Sistema de cifrado de archivos (EFS) y quizá el cifrado y protección ofrecidos por Rights Management Services (RMS). La gran diferencia con BitLocker es que, una vez habilitado, es automático, transparente e incluye el volumen completo.
Por ejemplo, con EFS, tiene que indicar específicamente cuáles archivos y carpetas serán protegidos. En Windows Vista, hay algunas nuevas opciones que hacen a EFS más flexible, y EFS y RMS abordan algunos escenarios que BitLocker no cubre. Pero tanto EFS como RMS requieren una configuración considerable por parte del administrador y no están diseñados para proteger todo lo almacenado en el volumen.
Por el contrario, BitLocker cifra todo lo escrito en un volumen protegido por BitLocker, incluidos el sistema operativo mismo, el Registro, los archivos de hibernación y paginación, las aplicaciones y los datos usados por las aplicaciones.
Existen tres elementos no cifrados: el sector de inicio, todos los sectores incorrectos marcados ilegibles y los metadatos de volumen. Los metadatos de volumen consisten en tres copias redundantes de datos usadas para administrar BitLocker, incluidas la información estadística del volumen y las copias protegidas de algunas claves de descifrado. Estos elementos no requieren cifrado porque no son exclusivos, valiosos, ni de identificación personal.
El cifrado de volumen completo protege contra ataques sin conexión; la clase de ataques montados al tratar de omitir el sistema operativo. Por ejemplo, un ataque común sin conexión es robar un equipo, quitar el disco duro, e instalarlo como segunda unidad de disco en otro equipo (y ejecutar una copia diferente de Windows o un sistema operativo diferente) para evitar los permisos NTFS y las contraseñas de usuario. Si se usa esta clase de ataque, no es posible leer un volumen protegido por BitLocker.

Manera en que BitLocker cifra los datos
BitLocker usa el algoritmo Estándar de cifrado avanzado (AES), con claves de 128 bits. Para una mejor protección, se pueden aumentar las claves a 256 bits mediante directivas de grupo o con el proveedor del instrumental de administración de Windows (WMI) de BitLocker.
Cada sector en el volumen se cifra individualmente, con una parte de la clave de cifrado derivada del número de sector mismo. Esto significa que dos sectores que contienen datos descifrados idénticos tendrán como resultado bytes cifrados diferentes escritos en el disco, lo que hace mucho más difícil intentar descubrir las claves mediante creación y cifrado de datos conocidos.
Antes de cifrar los datos mediante AES, BitLocker usa también un algoritmo llamado difusor. Sin entrar en detalles de criptografía, una descripción sencilla del difusor es que garantiza que incluso los cambios mínimos en el texto sin formato tengan como resultado cambios en el sector completo en el texto cifrado. Esto hace también mucho más difícil que el atacante pueda descubrir claves o datos.
Si está interesado en los detalles del algoritmo de cifrado de BitLocker, puede leer el documento de Neil Ferguson al respecto, "AES-CBC + difusor elefante: un algoritmo de cifrado del disco para Windows Vista".

Claves de BitLocker
En cada ocasión que trata con cifrado, necesita conocer sobre claves, y BitLocker no es la excepción. BitLocker usa una arquitectura de claves elegante, pero un poco compleja.
Los sectores en sí mismos se cifran mediante una clave denominada clave de cifrado de volumen completo (FVEK). Sin embargo, los usuarios no pueden usar la FVEK, ni tener acceso a ella. La FVEK se cifra en cambio con una clave denominada clave maestra de volumen (VMK). Este nivel de abstracción ofrece algunos beneficios exclusivos, pero puede hacer el proceso un poco más difícil de entender. La FVEK se mantiene como un secreto muy bien guardado porque, si estuviera en peligro, todos los sectores deberán volverse a cifrar. Dado que esto sería una operación que tarda mucho tiempo, es algo que se quiere evitar. En vez de eso, el sistema funciona con la VMK.
La FVEK (cifrada con la VMK) se almacena en el disco mismo, como parte de los metadatos de volumen. Aunque la FVEK se almacena de forma local, nunca se escribe sin cifrado en el disco.
La VMK también se cifra, o se "protege", pero por medio de uno o más protectores de clave posibles. El protector de clave predeterminado es el TPM. El uso de un TPM se analiza en la siguiente sección sobre comprobación de integridad. También se crea una contraseña de recuperación como protector clave, para emergencias. La recuperación también se analiza más tarde.
Puede combinar el TPM con un PIN numérico o con una clave parcial almacenada en una unidad de disco USB para aumentar la seguridad. Cada uno de estos métodos es una forma de autenticación en dos fases. Si el equipo no tiene un chip y BIOS compatibles con TPM, BitLocker se puede configurar para almacenar completamente un protector de clave en una unidad de disco USB. Esto se denomina clave de inicio.
BitLocker se puede deshabilitar sin descifrar los datos; en este caso, la VMK está protegida sólo por un nuevo protector de clave que se almacena sin cifrar. Tenga en cuenta que esta clave sin cifrado permite que el sistema tenga acceso a la unidad de disco como si no estuviera protegida.
En el inicio, el sistema busca un protector de clave apropiado consultando al TPM, comprobando los puertos USB o, si fuera necesario, preguntando al usuario (lo que se denomina recuperación). Encontrar un protector de clave permite a Windows descifrar la VMK, que descifra la FVEK que, a su vez, descifra los datos almacenados en disco. El proceso se muestra en la figura 1.
Figura 1 Proceso de inicio predeterminado de BitLocker
Figura 1 Proceso de inicio predeterminado de BitLocker

Comprobación de integridad
Debido a que los componentes del principio del proceso de inicio deben permanecer sin cifrado para que el equipo pueda iniciar, un atacante podría cambiar el código en esos primeros componentes de inicio (piense en un rootkit), y así obtener acceso al equipo, aunque los datos en el disco estén cifrados.
Mediante esta clase de ataque, un intruso quizá podría obtener acceso a información confidencial, como por ejemplo claves de BitLocker o contraseñas de usuario, y aprovechar esa información para evitar otras protecciones de seguridad.
Evitar esta clase de ataque fue uno de los objetivos originales del programa y del equipo que creó BitLocker. En algunos sentidos, el cifrado fue casi un medio para conseguir un fin. El cifrado de volumen completo permite que BitLocker proteja la integridad del sistema e impedir el inicio de Windows si los primeros componentes de inicio han cambiado.
En equipos con un TPM compatible, cada vez que se inicia el equipo, cada uno de los primeros componentes de inicio (tal como el BIOS, el registro de arranque maestro (MBR), el sector de inicio y el código del administrador de arranque) examina el código que se va a ejecutar, calcula un valor hash y almacena el valor en registros específicos del TPM, denominados registros de configuración de la plataforma (PCR). Una vez que un valor está almacenado en un PCR, no puede ser reemplazado ni borrado a menos que el sistema se reinicie. BitLocker usa el TPM y los valores almacenados en los PCR para proteger la VMK.
Un TPM puede crear una clave asociada a valores específicos de PCR. Cuando se crea este tipo de clave, el TPM cifra la clave y sólo ese TPM específico la puede descifrar. No obstante, más allá de eso, el TPM descifra la clave sólo si esos valores actuales de PCR coinciden con los valores especificados al crear la clave. Este proceso se denomina sellado de la clave en el TPM.
De forma predeterminada, BitLocker sella las claves según las medidas de la raíz central de la medida de confianza (CRTM), el BIOS y todas las extensiones de plataforma, código ROM de opción, código de MBR, el sector de arranque de NTFS y el administrador de arranque. Si cualquiera de estos elementos se modifica de manera inesperada, BitLocker bloqueará la unidad de disco e impedirá que se obtenga acceso a ella o que ésta sea descifrada.
De forma predeterminada, BitLocker se configura para buscar y usar un TPM. Puede usar directivas de grupo o una configuración de directiva local para permitir que BitLocker funcione sin un TPM y almacenar las claves en una unidad flash externa USB, pero sin un TPM, BitLocker no puede comprobar la integridad del sistema.

Habilitación de BitLocker por primera vez
BitLocker está disponible en Windows Vista Enterprise y Windows Vista Ultimate. (BitLocker también será un componente opcional incluido con la próxima versión de Windows Server® con nombre en código "Longhorn").
El siguiente análisis supone que el usuario dispone de un equipo compatible con TPM para la prueba. Si desea habilitar BitLocker en un equipo sin un TPM, siga los pasos descritos en la barra lateral "Uso de BitLocker sin un TPM".
Uso de BitLocker sin un TPM
BitLocker se configura de forma predeterminada para usar un TPM, y si no dispone de uno, Windows de fábrica no le permitirá habilitar BitLocker. Sin embargo, el procedimiento siguiente, tomado de la Guía paso a paso del Cifrado de unidad BitLocker de Windows, le permitirá usar BitLocker sin un TPM.
Para realizar estos pasos, debe iniciar sesión como administrador. Incluso sin un TPM, el equipo debe admitir la lectura de una unidad flash USB durante el proceso de inicio. Además, debe tener una unidad flash USB disponible cuando habilite BitLocker y cada vez que reinicia el equipo.
Siga estos pasos para activar el Cifrado de la unidad BitLocker en un equipo sin un TPM compatible:
  1. Haga clic en Inicio, escriba gpedit.msc en el cuadro Iniciar búsqueda y presione INTRO.
  2. Si aparece el cuadro de diálogo Control de cuentas de usuario, compruebe que la acción propuesta es la que solicitó y haga clic en Continuar.
  3. En el árbol de consola del Editor de objetos de directiva de grupo, haga clic en Directiva de equipo local, Plantillas administrativas y Componentes de Windows. A continuación, haga doble clic en Cifrado de unidad BitLocker.
  4. Haga doble clic en el valor de Configuración del Panel de control: habilitar opciones de inicio avanzadas. Aparecerá el cuadro de diálogo Configuración del Panel de control: habilitar opciones de inicio avanzadas.
  5. Seleccione la opción Habilitada, seleccione la casilla de verificación Permitir BitLocker sin un TPM compatible y haga clic en Aceptar. Ha cambiado la configuración de la directiva para poder usar una clave de inicio en vez de un TPM.
  6. Cierre el Editor de objetos de directiva de grupo.
  7. Para forzar la aplicación inmediata de la directiva de grupo, puede hacer clic en Inicio, escribir gpupdate.exe /force en el cuadro Iniciar búsqueda y presionar INTRO. Espere a que finalice el proceso.

Una parte importante de la habilitación de BitLocker es asegurarse de que los volúmenes estén correctamente configurados. BitLocker requiere que la partición activa no esté cifrada para poder leer el sector de inicio, el administrador de arranque y el programa cargador de Windows (estos componentes están protegidos por los pasos de integridad del sistema descritos anteriormente). Debido a que otros componentes de Windows pueden requerir el uso temporal de la partición activa, Microsoft recomienda que la partición activa tenga un tamaño mínimo de 1,5 GB. También es una buena idea configurar los permisos NTFS para que los usuarios no escriban accidentalmente datos en este volumen.
Windows en sí mismo se instalará en un segundo volumen de mayor tamaño, que se puede cifrar. Si instala Windows en un nuevo sistema, puede configurar manualmente los volúmenes si sigue las instrucciones disponibles en la Guía paso a paso del Cifrado de unidad BitLocker de Windows.
Puede usar la Herramienta de preparación de unidad BitLocker para ayudar a configurar el sistema para BitLocker. Esta herramienta elimina el esfuerzo de configurar las unidades de disco y está disponible como una opción adicional de Windows Vista Ultimate o para clientes que implementan Windows Vista Enterprise. Para obtener instrucciones detalladas sobre la Herramienta de preparación de unidad BitLocker, visite support.microsoft.com/kb/930063.
La Herramienta de preparación de unidad BitLocker reduce automáticamente el volumen (si sólo tiene uno), crea la segunda partición, la activa, realiza todos los cambios necesarios de configuración y mueve los archivos de inicio al lugar correcto.
Una vez que los volúmenes están configurados, la habilitación de BitLocker es sencilla. En la sección Seguridad del Panel de control, haga clic en el icono de Cifrado de unidad BitLocker. Después de reconocer la solicitud de consentimiento de UAC, aparecerá una pantalla semejante a la de la figura 2.
Figura 2 Habilitación de BitLocker
Figura 2 Habilitación de BitLocker
La secuencia exacta de lo que sucede a continuación variará en función del estado del chip TPM del equipo. Si el chip de TPM no está inicializado, se ejecutará el Asistente para inicializar TPM. Siga los mensajes para inicializar el TPM, que incluirán el reinicio del equipo.
Después de inicializar el TPM, aparecerá la página Guardar la contraseña de recuperación, tal como se muestra en la figura 3. Para poder recuperar los datos en el caso de un error de TPM o de algún otro problema, necesitará una contraseña de recuperación. Esta página le permite guardar una contraseña de recuperación en una unidad flash USB o en un disco local o de red, o bien imprimirla para guardarla en un lugar seguro. Debe elegir al menos una de estas opciones, y puede elegir guardar varias copias. Una vez guardada la contraseña de recuperación, se habilitará el botón Siguiente. Haga clic en él.
Figura 3 Guardado de la contraseña de recuperación
Figura 3 Guardado de la contraseña de recuperación
Aparecerá la página para cifrar el volumen de disco seleccionado y tiene la opción de ejecutar o no una comprobación de sistema antes de que se inicie el cifrado. La comprobación de sistema requerirá un reinicio, pero es la mejor manera de asegurarse que el TPM, el BIOS y los puertos USB funcionarán apropiadamente con BitLocker. Después del reinicio, si se detecta cualquier problema, verá un mensaje de error. De lo contrario, se muestra la barra de estado Cifrado en curso.
Y esto es todo. El cifrado se completará en segundo plano y el usuario seguirá usando el equipo. Una vez completado el cifrado inicial, aparecerá un mensaje de información. Para supervisar el estado de finalización en curso del cifrado del volumen de disco, arrastre el cursor sobre el icono Cifrado de unidad BitLocker de la barra de herramientas situada en la parte inferior de la pantalla. Para obtener información más detallada, puede referirse a la Guía paso a paso mencionada anteriormente.
Algunos usuarios se sorprenden al ver que BitLocker no realiza ninguna interrupción obvia ni solicitud al usuario en el momento que se inicia el equipo. Eso se debe a que, en su configuración predeterminada, BitLocker depende del TPM para confirmar la integridad del sistema antes de desbloquear el volumen. Esto es automático y transparente para el usuario.
Puede configurar BitLocker para requerir la entrada de un PIN o la presencia de una clave almacenada en una unidad flash USB durante el inicio. Esto aumenta la seguridad y se recomienda en situaciones donde un aumento de la seguridad pesa más que el inconveniente de escribir el PIN. En mi opinión, se recomienda siempre. (En otras palabras, mi equipo de escritorio requiere un PIN y mi equipo portátil requiere una llave USB).

Recuperación de BitLocker
Cuando se trabaja con cifrado, especialmente en una empresa o entorno comercial, es esencial disponer de una manera para que un usuario autorizado recupere sus datos, incluso si no están disponibles los métodos normales de acceso o las claves. BitLocker lo llama recuperación.
Si algo cambia de manera inesperada en los primeros componentes del inicio, o si pierde una llave de inicio USB o un usuario se olvida su PIN, BitLocker no podrá completar el proceso normal de inicio. BitLocker dejará bloqueado el volumen y Windows no podrá iniciar. En su lugar, el código de BitLocker en el administrador de arranque presentará una pantalla de texto. Si se guardó una contraseña de recuperación en una unidad flash USB (denominada a veces una clave de recuperación), aparece una pantalla semejante a la de la figura 4.
Figura 4 Búsqueda de una clave de recuperación
Figura 4 Búsqueda de una clave de recuperación
Para que BitLocker lea una unidad flash USB, ésta debe estar conectada durante el inicio. Entonces, si dispone de una unidad flash USB con una contraseña de recuperación, insértela y presione ESC. Si no dispone de una, presione Intro para ver la pantalla que se muestra en la figura 5. Esta pantalla también aparecerá si nunca se guardó una clave de recuperación en una unidad de disco USB.
Figura 5 Especificación de una contraseña para BitLocker
Figura 5 Especificación de una contraseña para BitLocker
BitLocker busca ahora una contraseña numérica de 48 dígitos que pueda desbloquear la unidad de disco. Este número aparece en la página si oportunamente eligió imprimir la contraseña de recuperación, y también está almacenada en un archivo si guardó la contraseña de recuperación en una carpeta.
La manera más sencilla de administrar contraseñas de recuperación en una empresa es hacer que se almacenen automáticamente en Active Directory®. Puede obtener todos los detalles sobre cómo debe hacerlo en go.microsoft.com/fwlink/?LinkId=87067.
En un artículo posterior explicaré con más detalles la capacidad de administración de BitLocker, pero como parte de esta introducción, debe saber que BitLocker se distribuye con un proveedor WMI completo que permite su administración (y la del TPM) a través de cualquier sistema Web-Based Enterprise Management (WBEM) compatible con WMI. Esto significa que pueden generarse secuencias de comandos para BitLocker con cualquier lenguaje que tenga acceso a objetos WMI, tal como VBScript o Windows PowerShell™.
BitLocker también incluye una herramienta de línea de comandos denominada manage-bde.wsf que usa el proveedor WMI para permitirle administrar BitLocker, en equipos locales o remotos. Para obtener más información, inicie un símbolo de sistema con privilegios elevados y escriba manage-bde.wsf /?.

Retiro de servicio seguro
A veces llega el momento en que todos los equipos se deben retirar del servicio. Las empresas generalmente emplean fondos y esfuerzos significativos para asegurarse de que las unidades de disco están completamente saneadas antes de deshacerse de ellas. La mayoría de los procesos que eliminan los datos confidenciales de las unidades de disco requieren tiempo, son costosos o tienen como resultado la destrucción permanente del hardware. BitLocker ofrece otras opciones más rentables.
En vez de preocuparse por eliminar los datos después del hecho, BitLocker ayuda a garantizar en primer lugar que los datos confidenciales no se almacenan en el disco de una manera riesgosa. Dado que todo lo escrito en el disco está cifrado, los datos se pueden representar completamente inaccesibles de manera permanente si se destruyen todas las copias de las claves de cifrado. El disco duro en sí mismo está completamente ileso y se puede volver a usar.
Puede elegir varios métodos para sacar de servicio activo los volúmenes que han sido protegidos por BitLocker. Puede optar por eliminar todas las copias de claves de metadatos de volumen, mientras las mantiene archivadas en un sitio central seguro. Esto puede permitir transportar sistemas de forma segura o sacarlos temporalmente de servicio activo si permanecen desatendidos durante períodos de tiempo prolongados. Esto garantiza que los usuarios autorizados puedan aún tener acceso a los datos, pero que no tenga acceso ningún usuario no autorizado, como por ejemplo, nuevos propietarios del equipo.
También puede optar por eliminar todas las copias de claves de metadatos de volumen y de todos los archivos, tales como Active Directory (quizá al crear nuevas claves sin almacenar). Dado que no existen claves de descifrado, nadie puede recuperar los datos.
En cualquiera de estos casos, la eliminación y destrucción de las claves contenidas en los metadatos de volumen es casi instantánea y un administrador la puede realizar en varios sistemas. Se requiere una mínima inversión de tiempo y esfuerzo, pero tiene como resultado un nivel muy alto de protección permanente. La utilidad de formato en Windows Vista se actualizó para que un comando de formato elimine los metadatos de volumen y sobrescriba esos sectores para eliminar de forma segura cualquier clave de BitLocker.

Algunas consideraciones finales
BitLocker es una herramienta eficaz diseñada para la protección contra amenazas específicas, y hace un excelente trabajo. Sin embargo, sería un error esperar que BitLocker proteja contra todas las amenazas. Es absolutamente crítico que continúe usando defensas y controles apropiados, como por ejemplo contraseñas seguras.
Entienda que BitLocker está dirigido hacia ataques sin conexión. Lo que significa que si Windows está en ejecución, BitLocker ha desbloqueado el volumen. Es decir, BitLocker no ofrece protección a un sistema en ejecución. Tecnologías como EFS y RMS complementan a BitLocker al proteger información mientras se ejecuta el sistema operativo.
Para obtener más información acerca de BitLocker, visite el sitio web de Microsoft, comenzando en technet.microsoft.com/windowsvista/aa905065.aspx. Para obtener más información acerca de las especificaciones de TPM y el TCG, visite la sección Especificaciones de TPM en el sitio web del TCG en go.microsoft.com/fwlink/?LinkId=72757.

Byron Hynes trabaja en el grupo de asistencia al usuario de Windows Server, en Microsoft. Anteriormente, trabajó como consultor e instructor. Puede ponerse en contacto con él en la dirección bhynes@microsoft.com.


 Seguridad: Exploraci&#243;n de Firewall de Windows
Seguridad Steve Riley

Exploración de Firewall de Windows
Resumen:
  • Protección entrante frente a protección saliente
  • Plataforma de filtrado de Windows
  • Interfaz seguridad avanzada
  • Perfiles de red

En los tiempos de la era paleolítica de la informática, nadie pensaba jamás en instalar firewalls en equipos individuales. ¿Quién los necesitaba? Casi nadie había oído hablar de Internet, TCP/IP no estaba a la vista por ninguna parte y los protocolos de LAN no distribuían más allá del edificio o del campus. Los datos importantes residían en
el mainframe o en servidores de archivos. La información que las personas conservaban en sus equipos de escritorio rara vez era esencial para la misión y el propio peso del equipo proporcionaba una cantidad decente de seguridad física. Si había una conexión a Internet disponible, probablemente existían algunos traductores de protocolos a mitad de camino y un enrutador de filtrado de paquetes (es decir, un "firewall") en el perímetro, quizá configurado con demasiadas reglas y excepciones.
Los entornos informáticos actuales difieren totalmente de los de aquellos tiempos antiguos. Todo se conecta a Internet (y ahora habla TCP/IP) y los dispositivos portátiles son el estándar de hoy. Es probable que su empleador le haya dado un equipo portátil, no sólo porque se preocupa por usted, sino porque le interesa obtener más de usted; esperaba que trabaje cuando tenga cinco minutos libres y una conexión Wi-Fi. Quizá los equipos portátiles puedan costar más que los de escritorio, pero esa inversión sin duda se devuelve en productividad. Como puede ver, es la portabilidad lo que los hace tan cautivantes, tanto para usted como para sus adversarios.
Piense en lo siguiente: de la cantidad total de tiempo que su equipo portátil está encendido y conectado a alguna red, ¿qué porcentaje de ese tiempo está conectado a su red corporativa? Si se parece a mí, quizá un 20 por ciento como máximo. Lo cuál significa que sólo el 20 por ciento del tiempo mi equipo portátil se encuentra seguro dentro de los límites de la red corporativa de Microsoft, protegido de los ataques externos por las defensas del perímetro de la red. Pero ¿qué sucede el 80 por ciento del tiempo cuando mi equipo portátil está, para todo propósito práctico, conectado directamente a Internet? (Y con frecuencia estoy conectado a la red más peligrosa del mundo: la LAN del hotel en una conferencia de seguridad de equipos.) Y esas veces en que estoy conectado a la red corporativa, ¿qué ocurre con las amenazas que suponen los otros equipos en ese entorno?
Los controles de seguridad evolucionan para seguir, a veces muy de lejos, a las amenazas. Los virus eran un problema de los clientes porque las personas intercambiaban disquetes, de modo que los programas antivirus aparecieron primero en los clientes. Más tarde, cuando se hizo popular el correo electrónico y el malware maduró en gusanos que dependían de la distribución del correo electrónico, los programas antimalware evolucionaron y aparecieron en las puertas de enlace de correo electrónico. Con el auge de la Web, el malware maduró en caballos de Troya y los programas antimalware lo siguieron en los servidores proxy de acceso a Internet. Es un camino evolutivo bien conocido que nadie discute.
Ahora apliquemos la misma lógica a los firewalls. Aunque un firewall en el perímetro de la red era suficiente protección contra las amenazas de ayer, esto ya no es así porque las amenazas son diferentes, son más sofisticadas y se encuentran más extendidas. Y no hay que olvidar que los dispositivos y estilos de trabajo difieren apreciablemente de los del pasado. Muchos equipos contienen información confidencial almacenada de forma local y pasan mucho tiempo lejos de la red corporativa (es decir, fuera del perímetro). Por lo tanto, el firewall debe evolucionar en un mecanismo individual de protección del cliente. No se equivoque: los firewalls de cliente ya no son opcionales. Para proteger sus equipos de las amenazas de su propia red corporativa y de Internet, se requieren firewalls de cliente.

Firewalls de cliente y dramatización de seguridad
Muchas personas no notaron que el lanzamiento inicial de Windows ®XP incluía un firewall de cliente. En realidad no es sorprendente porque el firewall estaba desactivado de forma predeterminada y escondido detrás de demasiados clics de mouse. A su propia manera bastante camuflada, el firewall aparecía sin ninguna indicación real de su propósito ni una orientación sobre su uso. Pero funcionaba. Si hubiera habilitado ese firewall, habría estado a salvo de Nimda, Slammer, Blaster, Sasser, Zotob y de todo lo demás que intentaba arrojar tráfico no solicitado en su puerto de red. Al darse cuenta de la importancia de la protección del cliente, Windows XP Service Pack 2 (SP2) habilitó de forma predeterminada el firewall, creó dos perfiles (Internet y red corporativa) y permitió su habilitación mediante directivas de grupo.
Desafortunadamente, dos barreras demoraron la adopción del firewall de Windows XP SP2: las preocupaciones por las aplicaciones y dramatización de seguridad de las mismas. Muchas personas temían que el firewall hiciera que sus aplicaciones dejaran de funcionar correctamente. Sin embargo esto rara vez sucedía, debido al diseño del firewall. El firewall permitía que todo tráfico saliente dejara su equipo, pero bloqueaba todo el tráfico entrante que no fuera una respuesta a alguna solicitud saliente anterior. La única vez que este diseño interrumpía una aplicación en un cliente era cuando la aplicación creaba un socket de escucha y esperaba recibir solicitudes entrantes. El firewall de Windows XP permitía configuraciones sencillas de excepciones para programas o puertos (aunque, desafortunadamente, no mediante directivas de grupo).
El mayor freno fue la dramatización de seguridad realizada por los fabricantes de otros firewalls de cliente. Algunas personas creían que el diseño del firewall de Windows XP, concretamente permitir que todo el tráfico saliente dejara libremente el equipo, era insuficiente funcionalidad para un firewall de cliente. El argumento era que un firewall de cliente adecuado debía bloquear todo el tráfico, entrante y saliente, a menos que el usuario específicamente concediera permisos.
Ahora, pensemos en esto por un instante. Aparecen dos situaciones.
  • Si ejecuta como administrador local y se infecta con malware, éste último simplemente deshabilitará el firewall. Alguien se apropia de su equipo.
  • Si no ejecuta como administrador local y se infecta con malware, éste último hará que un firewall de terceros inicie un diálogo en un lenguaje externo en que intervengan puertos y direcciones IP y que incluya una pregunta muy grave: "¿Quiere permitir esto?" La única respuesta, por supuesto, es: "¡Sí, estúpido equipo, deja de acosarme!" Y una vez que ese diálogo se va, también lo hace su seguridad. O, con más frecuencia, el malware secuestra una sesión existente de un programa que usted ya autorizó, y ni siquiera alcanza a ver el diálogo. Otra vez, alguien se apropia de su equipo.
Existe un axioma importante de seguridad que debe entender: la protección pertenece al activo que quiere proteger, no a aquello contra la cual intenta protegerse. El enfoque correcto es ejecutar el ágil y aún eficaz Firewall de Windows en cada equipo de su organización, para protegerlos del resto de los equipos del mundo. Si intenta bloquear conexiones salientes de un equipo que ya está en peligro, ¿cómo puede estar seguro que el equipo hace lo que le solicita? La respuesta: No puede. La protección saliente es una dramatización de seguridad, es un artificio que sólo ofrece la impresión de mejorar su seguridad pero en realidad no hace nada que la mejore. Por este motivo no existía protección saliente en el firewall de Windows XP y por lo mismo no existe en el firewall de Windows Vista™. (Hablaré más sobre control saliente en Windows Vista en un instante).

¿Qué novedades presenta Windows Vista?
La plataforma de filtrado de Windows, parte de la nueva pila de red, es la base del firewall de Windows Vista. Como Windows XP, Windows Vista bloquea el tráfico entrante de forma predeterminada. Según el perfil usado en el equipo, quizá existan algunas excepciones predeterminadas para servicios de red (hablaré posteriormente sobre perfiles). Si lo desea, puede escribir reglas para permitir conexiones entrantes. También como en Windows XP, Windows Vista permite todo el tráfico saliente de procesos interactivos de forma predeterminada, pero restringe el tráfico saliente de los servicios que participan en restricción de servicio. Y, nuevamente, puede escribir reglas para bloquear conexiones salientes adicionales.
La gran diferencia entre Windows XP y Windows Vista es la nueva interfaz Seguridad avanzada y total compatibilidad con directivas de grupo para configuración y reglas (consulte la figura 1). La antigua IU del Panel de control aún está allí y permanece casi sin cambios excepto en el registro y las configuraciones del Protocolo de mensajes de control de Internet (ICMP), que ahora aparecen en la nueva IU. El complemento MMC de Seguridad avanzada, la nueva IU, ofrece todas las nuevas características y flexibilidad. También existe un nuevo contexto en el comando netsh, netsh advfirewall, a través del cual puede crear secuencias de comandos para agregar y eliminar reglas, establecer y mostrar directivas globales y por perfil, y mostrar el estado activo del firewall. Y para ustedes desarrolladores, FirewallAPI.dll y Netfw.h ofrecen control mediante programación de todas las configuraciones del firewall.
Figura 1 Firewall de Windows con Seguridad avanzada
Figura 1 Firewall de Windows con Seguridad avanzada
La consola MMC de Seguridad avanzada está controlada por un asistente. Al crear una regla, puede elegir uno entre cuatro tipos: programa, puerto, predefinida o personalizada. Estos se describen en la figura 2.
Figure 2 Cuatro tipos de reglas (Close Figure 2)

Tipo | Propósito
Programa | Se usa para permitir o bloquear tráfico para un programa determinado.
Puerto | Se usa para permitir o bloquear tráfico en puertos TCP o UDP determinados.
Predefinida | Se usa un grupo de reglas preexistente para habilitar la funcionalidad de Windows en la red (tal como el uso compartido de impresoras y archivos o la asistencia remota).
Personalizada | Se exponen todas las perillas, cuadrantes, botones e interruptores para que pueda configurar una regla de forma tan específica como desee.
Hay muchos elementos a los que puede hacer referencia cuando escribe las reglas, y todos están disponibles para reglas locales y reglas aplicadas mediante directivas de grupo. Éstos son: Cuentas y grupos de usuarios y equipos de Active Directory®, direcciones IP de origen y destino, puertos TCP y UDP de origen y destino, números de protocolo IP, programas y servicios, tipos de interfaces (cableadas, inalámbricas o de acceso remoto) y tipos y códigos ICMP.
Una vez configurado, el firewall procesa las reglas en el orden siguiente:
Restricciones de servicio Algunos de los servicios en Windows Vista se restringirán a sí mismos para limitar la posibilidad de otro ataque estilo Blaster. Una de las restricciones es una lista de puertos requeridos por el servicio. El firewall la aplica e impide que el servicio use (o se le indique que use) cualquier otro puerto.
Reglas de seguridad de conexión La consola MMC de Seguridad avanzada incorpora IPsec así como el firewall. A continuación, se procesan todas las reglas que incluyen directivas IPsec.
Omisión autenticada Permiten que los equipos autenticados que se especifican omitan otras reglas.
Reglas de bloqueo Bloquean explícitamente el tráfico entrante o saliente especificado.
Reglas permitir Permiten explícitamente el tráfico entrante o saliente especificado.
Las reglas del firewall se almacenan en el Registro, pero no les diré dónde con exactitud. Ah, de acuerdo, las encontrarán en estas ubicaciones:
  • HKEY_LOCAL_MACHINE\SYSTEM\ CurrentControlSet\Services\SharedAccess\Defaults\FirewallPolicy\FirewallRule
  • HKEY_LOCAL_MACHINE\SYSTEM\ CurrentControlSet\Services\SharedAccess\Parameters\FirewallPolicy\FirewallRules
  • HKEY_LOCAL_MACHINE\SYSTEM\ CurrentControlSet\Services\SharedAccess\Parameters\FirewallPolicy\RestrictedServices\Static\System
No edite directamente las reglas en el registro. Si lo hace, ¡lo buscaremos y venderemos su mascota en eBay! Bueno, quizá no, pero la única manera admitida para editar reglas es mediante el uso de la consola MMC de Seguridad avanzada.

Perfiles de red
Windows Vista define tres perfiles de red: dominio, privado y público. Cuando el equipo se une al dominio e inicia correctamente sesión en el dominio, aplica automáticamente el perfil de dominio; el usuario nunca conseguirá hacer esta elección por sí mismo. Cuando el equipo se conecta a una red interna que le falta un dominio (tal como una red doméstica o de oficina pequeña), el usuario (o un administrador) debe aplicar el perfil privado. Por último, cuando el equipo se conecta directamente a Internet, debe aplicar el perfil público.
¿Cómo decide Windows Vista donde colocar el equipo? Siempre que hay un cambio de red (por ejemplo, si recibe una nueva dirección IP, obtiene una nueva puerta de enlace predeterminada u obtiene una nueva interfaz), un servicio denominado Reconocimiento de ubicación de red (NLA) detecta el cambio. Genera un perfil de red, que incluye información acerca de las interfaces existentes, si el equipo se autentica con un controlador de dominio, la dirección MAC de la puerta de enlace, etc. y le asigna un GUID. A continuación, NLA notifica al firewall y éste aplica la directiva correspondiente (existe una directiva definida para cada uno de los tres perfiles).
Si se trata de una nueva interfaz que el equipo nunca obtuvo con anterioridad y NLA no eligió el perfil de dominio, entonces observará un cuadro de diálogo que le solicita indicar a qué clase de red se conecta. Misteriosamente, existen tres alternativas: Doméstica, Trabajo y Pública. Quizá cree que "Trabajo" es el perfil de dominio, pero en realidad no lo es. Recuerde, nunca verá el perfil de dominio porque NLA lo selecciona de forma automática cuando el equipo inicia sesión en un dominio. En realidad, tanto Doméstica como Trabajo corresponden al perfil privado. Funcionalmente, son equivalentes, únicamente los iconos son diferentes. Nota: Debe ser administrador local o poder elevar sus privilegios a administrador local para seleccionar el perfil privado. Como lo esperaba, Pública corresponde al perfil público.
En Windows Vista, un perfil de red se aplica a todas las interfaces del equipo. Este es un resumen del árbol de decisión de NLA:
  1. Examinar todas las redes conectadas.
  2. ¿Hay alguna interfaz conectada a una red clasificada como pública? Si la respuesta es sí, establezca el perfil de equipo a público y salga.
  3. ¿Hay alguna interfaz conectada a una red clasificada como privada? Si la respuesta es sí, establezca el perfil de equipo a privado y salga.
  4. ¿Todas las interfaces ven un controlador de dominio y el equipo inició sesión correctamente? Si la respuesta es sí, establezca el perfil de equipo a dominio y salga.
  5. Sino, establezca el perfil del equipo a público.
El objetivo es seleccionar el perfil más restrictivo posible. Sin embargo, hay dos efectos obvios secundarios. En primer lugar, si el puerto Ethernet del equipo está conectado a la red corporativa y su NIC inalámbrica se conecta al café cercano con conexión inalámbrica a Internet, el equipo seleccionará el perfil público, no el perfil de dominio. En segundo lugar, si el equipo se conecta directamente a Internet (con el perfil público) o se conecta a la LAN doméstica (con el perfil privado) y realiza una conexión VPN a su red corporativa, el equipo permanecerá en el perfil público o privado.
¿Qué puede significar esto? La directiva del firewall para el perfil de dominio incluye las reglas para asistencia remota, administración remota, uso compartido de impresoras y archivos, etc. Si depende de estas reglas para obtener acceso a un cliente de forma remota, no podrá hacerlo si el cliente ha elegido algún otro perfil. Pero no se desespere, puede escribir reglas de firewall para permitir todas las conexiones entrantes que necesite y, a continuación, aplicarlas sólo a conexiones VPN. Todavía puede administrar sus clientes sobre la VPN incluso cuando ellos no se encuentran en el perfil de dominio.

Control de conexiones salientes
Anteriormente dije que la forma típica de protección saliente en firewalls de cliente es sólo una dramatización de seguridad. Sin embargo, hay una forma de control saliente muy útil: el control administrativo de ciertos tipos de tráfico que sabe que no quiere permitir. El firewall de Windows Vista ya lo hace con restricciones de servicio. El firewall permite que un servicio se comunique sólo en los puertos que dice necesitar y bloquea todo lo demás que el servicio intenta hacer. Se puede basar en esta característica para escribir reglas adicionales que permitan o bloqueen tráfico específico para que coincida con la directiva de seguridad de la organización (consulte la figura 3).
Figura 3 Asistente para nueva regla de entrada
Figura 3 Asistente para nueva regla de entrada
Digamos, por ejemplo, que desea prohibir a los usuarios la ejecución de un cliente en particular de mensajería instantánea. Puede crear una regla (en la directiva de grupo, por supuesto) para bloquear conexiones a los servidores de inicio de sesión para ese cliente.
Sin embargo, existen limitaciones prácticas para este enfoque. Por ejemplo, Windows Live™ Messenger (que quizá todavía conozca como MSN® Messenger) puede usar diversos servidores para el inicio de sesión y la lista cambia de forma permanente. Además, recurrirá al puerto 80/tcp si está bloqueado el puerto predeterminado 1863/tcp. Una regla para bloquear la conexión de Windows Live Messenger a sus servidores de inicio de sesión sería demasiado compleja y siempre inestable. Menciono esto para ilustrar que el control administrativo saliente puede ser útil, pero no es un sustituto para las directivas de restricción de software si necesita mantener un control estricto del software que los usuarios pueden instalar y ejecutar.

Proteja su equipo
El perímetro desapareció. Ahora cada equipo debe asumir la responsabilidad de su propia protección. Así como el antimalware se movió del cliente al perímetro, del mismo modo los firewalls se deben mover del perímetro al cliente. Puede tomar acciones inmediatas si habilita el firewall que ya tiene instalado.
Si sus sistemas ejecutan Windows XP o si se encuentra en transición a Windows Vista, Firewall de Windows está disponible para todos sus clientes y ofrecerá la protección que necesita para mejorar la seguridad en la organización, incluso cuando los trabajadores móviles se encuentren a miles de kilómetros de la oficina.

Dónde obtener más información
  • Windows Vista TechCenter: Introducción a Firewall de Windows con Seguridad avanzada
  • Windows Vista TechCenter: Firewall de Windows con Seguridad avanzada: diagnósticos y solución de problemas
  • Presentación TechEd Europe de Steve Riley: Firewall de Windows Vista y mejoras de IPSec Enhancements
  • The Cable Guy: Nuevo Firewall de Windows en Windows Vista y Windows Server "Longhorn"
  • Laboratorio virtual de Firewall de Windows Vista

Steve Riley, responsable jefe de estrategias de seguridad en la Unidad de tecnología y seguridad de Microsoft y redactor colaborador de la revista TechNet Magazine, viaja por todo el mundo para dar conferencias y pasar tiempo con los clientes para ayudarles a protegerse y permanecer protegidos. Su último libro es Protect Your Windows Network (Addison-Wesley, 2005). Puede ponerse en contacto con él en la dirección steve.riley@microsoft.com.


 Seguridad: Nuevas ACL mejoran la seguridad en Windows Vista
Seguridad Jesper Johansson

Nuevas ACL mejoran la seguridad en Windows Vista
Resumen:
  • Novedades en las ACL
  • Controles más estrictos en administrador
  • Permisos del instalador de confianza
  • Usuarios y grupos modificados

La estructura fundamental de las listas de control de acceso no ha cambiado demasiado en Windows Vista, pero existen varios cambios pequeños, aunque importantes, que debe conocer. Algunos cambios
fueron necesarios porque en Windows®XP, las ACL intervinieron en varios problemas. En primer lugar, la mayoría de los usuarios de Windows XP ejecutan como administrador. Es decir, usan una cuenta que es miembro del grupo integrado Administradores. Para usuarios domésticos, esto siempre es una certeza porque todas las cuentas que se agregan durante la instalación pasan a ser administradores. Por lo tanto todos los programas que ejecuten estos usuarios lo harán también con privilegios administrativos, otorgándoles un acceso sin restricciones al sistema operativo. Por supuesto, esto es sobre todo problemático si esos programas son de la variedad indeseable.
El segundo problema que se debía solucionar era que las ACL predeterminadas en versiones anteriores de Windows ponían a mucha gente nerviosa porque incluían entradas de ACL (ACE) para Todos, Usuarios avanzados y opciones similares. Por ejemplo, las ACL predeterminadas en la raíz del volumen de arranque (normalmente C: \) en Windows XP otorgaban acceso de lectura a Todos y permiso para crear carpetas a miembros del grupo Usuarios. Por último, en Windows XP había limitaciones en lo que se podía hacer con las ACL. Por ejemplo en Windows XP no había una manera de asignar permisos al propietario actual de un objeto. Podía asignar permisos de propietario pero al cambiar el propietario, esos permisos no se transferían. De forma similar, los propietarios siempre tuvieron derechos implícitos en un objeto, sin importar qué permisos estuvieran asignados en el mismo.
Con Windows Vista™, Microsoft se embarcó en un proyecto para resolver muchos de estos problemas y permitir otras características, tales como el Control de cuentas de usuario (UAC). Este artículo se centra en los cambios más importantes relacionados con el control de acceso en Windows Vista. El mes que viene continuaré explicando las herramientas que puede usar para administrar el control de acceso.

Usuarios y grupos nuevos y modificados
Algunos usuarios y grupos en Windows Vista son nuevos y se eliminaron algunos viejos amigos de Windows XP. Además, se modificó la manera en que algunos funcionan. Cada uno de los cambios tiene algún impacto en la manera en que administra el control de acceso.
Administrador: deshabilitado de forma predeterminada La cuenta integrada Administrador, que tiene un identificador relativo (RID) de 500, ahora está deshabilitada de forma predeterminada en la mayoría de los casos. La cuenta de administrador pretendía ser una cuenta de emergencia, usada para salvar el equipo cuando todo lo demás fallaba. No obstante, con bastante frecuencia, terminó por usarse como la cuenta administrativa estándar, con lo cual se infringen varios principios de seguridad. Uno de los más notables (la responsabilidad) significa que pierde la capacidad de realizar un seguimiento de quién realiza los cambios en el sistema. Por lo tanto, la cuenta se descartó parcialmente. En algún momento, Microsoft podría descartar la cuenta por completo, pero por ahora está deshabilitada de forma predeterminada. Si no dispone de otras cuentas locales en el grupo Administradores, aún se puede usar RID 500 en la consola de recuperación y modo seguro, pero de otra manera, no se puede, y no se debe usar.
Observe que existe una diferencia entre la cuenta integrada Administrador y otras cuentas del grupo Administradores. Normalmente, comenzamos en mayúscula "Administrador" cuando nos referimos a la cuenta con RID 500 para distinguirla de un "administrador", que son todas las otras cuentas que son miembros del grupo integrado Administradores. De igual forma, los nombres de grupo comienzan en mayúscula.
En Windows XP, la cuenta integrada Administrador tenía varios privilegios especiales que ningún otro administrador tenía. Muchos de estos privilegios se han eliminado en Windows Vista, pero existen dos excepciones notables: En primer lugar, se puede usar una cuenta deshabilitada Administrador en la consola de recuperación si no existen otros administradores locales. En segundo lugar, el Administrador no está sujeto a UAC y siempre tendrá un token administrativo completo. Lo mismo sucede con el Administrador de dominio (RID 500 en un dominio).
Permisos eliminados de Usuarios avanzados El viejo grupo Usuarios avanzados, se ha abolido para todos los fines prácticos. El grupo todavía está allí, pero se quitó la mayor parte de los permisos concedidos. No era precisamente un secreto que un usuario miembro de Usuarios avanzados era efectivamente un administrador que simplemente no se había asignado a sí mismo como administrador. Cierta vez tomé el control de un equipo al que se había aplicado todas las revisiones, y con Windows XP Service Pack 2 (SP2), en menos de 45 minutos me concedí privilegios administrativos. Esto incluyó el reconocimiento, la escritura de un pequeño programa en C ++ y el cierre y nuevo inicio de sesión para completar la toma de control, habilitado totalmente porque era miembro de Usuarios avanzados.
Muchas organizaciones han concedido permisos sofisticados al grupo Usuarios avanzados y dependen de usuarios que son miembros del mismo, de modo que en Windows Vista no era posible eliminar el grupo. Sin embargo, es probable que Microsoft elimine por completo Usuarios avanzados en una futura versión de Windows. Sería recomendable que comience a planear la migración de Usuarios avanzados.
Instalador de confianza El Instalador de confianza es en realidad un servicio, no un usuario, aunque puede ver que se le conceden permisos en todo el sistema de archivos. El sistema de protección de servicios permite que cada servicio sea tratado como una entidad completa de seguridad a la que se pueden asignar permisos como a cualquier otro usuario. Para obtener una descripción general de esta característica, consulte el número de enero de 2007 de TechNet Magazine. El libro Windows Vista Security (Grimes and Johansson, Wiley Press, 2007) explora en detalle el sistema de protección de servicios, incluido como lo aprovechan otras características, tales como el firewall e IPsec.
Los SID de servicio no se envían desde las autoridades que vimos anteriormente, como NT AUTHORITY o un dominio. El nombre completo de la cuenta virtual TrustedInstaller es NT SERVICE\TrustedInstaller y su SID es:
S-1-5-80-956008885-3418522649-1831038044-1853292631-2271478464
Puede ver el SID de cualquier servicio, incluso de los que no existen, si ejecuta el comando sc showsid, tal como se muestra en la figura 1.
Figura 1 sc showsid muestra el SID de cualquier servicio, incluidos los que aún no existen
Figura 1 sc showsid muestra el SID de cualquier servicio, incluidos los que aún no existen
Este SID comienza con S-1-5-80. Observe que aquí la primera subautoridad es 80, lo que significa SECURITY_SERVICE_ID_BASE_RID; es decir que este SID está emitido por la subautoridad NT SERVICE para un servicio. Lo mismo sucede con todos los servicios. Las subautoridades restantes y los RID se basan en el nombre del servicio en sí mismo. Esto permite que un desarrollador conceda permisos a su servicio sin tener primero que crear e instalar el servicio porque el nombre es determinista y no variará de un equipo a otro.
En caso de que no encuentre el servicio TrustedInstaller en el administrador de servicios, su nombre para mostrar es "Instalador de módulos de Windows".
Cuentas de Ayuda y Soporte técnico eliminadas Las cuentas Support_xxxxxx y Asistente de ayuda se quitan en instalaciones limpias de Windows Vista, aunque se conservan cuando actualiza desde una versión anterior de Windows. La cuenta Support_xxxxxx se usaba para ejecutar secuencias de comandos desde el centro del soporte técnico. Algunos OEM que proporcionaban su propio contenido de ayuda pueden haber ofrecido también sus propias cuentas de soporte técnico. No está claro lo que sucederá con las cuentas OEM, pero lo más probable es que los OEM simplemente dejarán de crearlas. En realidad, ya no son necesarias. De hecho, desde una perspectiva de seguridad, no era una buena idea permitir que los usuarios ejecuten secuencias de comandos del centro de ayuda como cualquier otro usuario, de modo que sería mejor si esas cuentas desaparecen. Windows Vista tiene un nuevo mecanismo para realizar esta tarea.
La cuenta Asistente de ayuda se usaba durante la asistencia remota. Al igual que con el centro de ayuda, se realizó nuevamente la ingeniería de la característica de asistencia remota para evitar la necesidad de la cuenta Asistente de ayuda y consecuentemente ha sido eliminada.
Nuevos SID de ubicación de red Los sistemas operativos basados en Windows NT® siempre contaban con algunos SID basados en ubicación de red, tales como NETWORK e INTERACTIVE, que denotaban usuarios que iniciaban sesión desde la red e interactivamente. Hay también un SID REMOTE INTERACTIVE LOGON que se asigna a usuarios que inician sesión mediante Servicios de Terminal Server. (Observe que los usuarios de Servicios de Terminal Server tendrán en sus tokens tanto REMOTE INTERACTIVE LOGON como INTERACTIVE LOGON). En Windows Vista, se agregan dos: DIALUP e INTERNET. El fundamento exacto para agregar una cuenta que denota un inicio de sesión mediante acceso telefónico es poco claro, especialmente cuando cada vez más usuarios no se conectarán si la única red disponible es una línea telefónica, pero ahora está allí. INTERNET obviamente quiere indicar cualquier usuario que inicia sesión más allá de la red de área local. Sin embargo, NETWORK, aún designa cualquier usuario que inicia sesión en la red, incluso Internet.
OWNER RIGHTS y derechos de propietario Ahora existe un SID para OWNER RIGHTS, que se aplica a quienquiera que sea propietario de un archivo en el momento en que se obtiene acceso a éste. Se usa principalmente para restringir lo que el propietario puede hacer con el archivo. Existen dos cambios notables respecto a cómo funcionan los derechos de propietario en comparación con Windows XP. En primer lugar, si es el propietario del objeto, pero existe en él una ACE que se aplica al usuario, los derechos en la ACE sustituirán el hecho de que dicho usuario sea el propietario. Esto es un cambio importante e tendrá un impacto apreciable en ciertos aspectos de administración de sistema donde estamos acostumbrados a que el propietario tenga derechos implícitos. En segundo lugar, el SID OWNER RIGHTS se puede usar para restringir aún más lo que el propietario puede hacer con un objeto.
Supongamos que tenemos una carpeta, que es propiedad del usuario Jesper, con una ACL como la que se muestra en la figura 2. El usuario, Jesper, sólo tiene permiso de Lectura en la carpeta, aunque sea el propietario. Si intenta copiar un archivo en la misma, la copia generará un error porque Jesper no tiene permiso para escribir en la carpeta. Sin embargo, este resultado no es muy intuitivo en los mensajes de error. Si intenta copiar un archivo en una carpeta de su propiedad pero no tiene permisos de escritura para usar Explorador de Windows®, sucede lo siguiente: en primer lugar, Explorador le indica que necesita elevar los permisos para copiar el archivo y le solicita que los eleve, pero la copia del archivo genera error porque no tiene derechos para copiar en esta carpeta. Obtiene un mensaje de error que dice "Necesita permisos para realizar esta acción" y un botón "Intentar de nuevo" por cada acción (como si eso pudiera ayudar) y "Cancelar". Esto a pesar del hecho de que es el propietario.
Figura 2 Sólo Sistema local y otro usuario tienen acceso a esta carpeta
Figura 2 Sólo Sistema local y otro usuario tienen acceso a esta carpeta
Si Jesper intenta cambiar las ACL en el archivo, se le solicitará que eleve su token para hacerlo. Dado que es el propietario del archivo, puede hacerlo. El propietario retiene derechos implícitos para leer y cambiar las ACL (READ_CONTROL y WRITE_DAC) a menos que exista una ACE para OWNER RIGHTS que especifique lo contrario.
Para entender el efecto de los SID de OWNER RIGHTS, agreguémoslos a las ACL anteriores. Ahora tenemos los permisos que se muestran en la figura 3.
Figura 3 La adición de permisos OWNER RIGHTS a la carpeta cambia los permisos de Jesper
Figura 3 La adición de permisos OWNER RIGHTS a la carpeta cambia los permisos de Jesper
Con estos permisos, si la cuenta de Jesper intenta copiar en la carpeta, la acción resulta correcta de inmediato porque Jesper es el propietario y tiene los derechos apropiados. Sin embargo, si Jesper intenta cambiar las ACL en el objeto, esa acción genera un error. La ACE para OWNER RIGHTS especifica que el propietario sólo tendrá el privilegio Modificar, no la capacidad de modificar la lista de control de acceso discrecional (DACL). De esta forma, OWNER RIGHTS se usa principalmente para quitar WRITE_DAC del propietario, la capacidad de modificar el descriptor de seguridad.
Si un administrador cambia el propietario del objeto, los permisos OWNER RIGHTS no se transfieren automáticamente al nuevo propietario. En este caso, la ACE de OWNER RIGHTS se deshabilita al marcarla como Sólo heredar pero sin aplicarlo en ningún contenedor ni objeto; en otras palabras, sin aplicarlo en nada. Esto se hace para asegurar que a los administradores no se les bloquee totalmente el objeto. Para que la ACE de OWNER RIGHTS tenga nuevamente efecto, el Administrador tiene que entrar y volver a habilitar la ACE de forma manual. Para ello, la debe marcar para aplicarla a esta carpeta, a las subcarpetas y a los archivos, de la forma deseada.
Existen varias situaciones interesantes en las que el SID OWNER RIGHTS puede ser útil, como por ejemplo, cuando el administrador desea que los usuarios puedan crear archivos y carpetas en un servidor de archivos, pero no desea que puedan cambiar las ACL en esas carpetas. Otra posible situación ocurre cuando en algún momento los usuarios fueron miembros de un grupo y crearon objetos pero, tal vez por razones de negocio, posteriormente fueron eliminados de este grupo. En ese momento, no podrán modificar los valores de esos objetos.
OWNER RIGHTS se usa ampliamente en el sistema de protección de servicios. Cuando un servicio crea un objeto transitorio en tiempo de ejecución, el creador del objeto es el SID principal del proceso del servicio, típicamente LocalSystem, NetworkService o LocalService, y no el SID del servicio en sí. Esto significa que cualquier otro servicio que se ejecute en el mismo contexto del proceso puede modificar el objeto, lo cual casi con toda seguridad no es deseable. Al establecer un SID de OWNER RIGHTS en dichos objetos, el sistema operativo puede impedir que otros servicios tengan acceso a ellos.

ACL predeterminadas
Las ACL predeterminadas en Windows XP eran bastante buenas en realidad. Aparte de algunos problemas secundarios, tale como permitir que los usuarios pongan los archivos en la raíz del volumen de arranque, generalmente eran razonables. Sin embargo, algunos OEM aparentemente decidieron que conocían mejor lo que constituía una seguridad razonable. La pantalla de la figura 4 muestra una imagen de las ACL en el directorio Windows de un equipo que ejecuta Windows XP Media Center Edition de un OEM de importancia. El OEM fundamentalmente deshabilitó la seguridad del sistema de archivos.
Figura 4 ACL configurada por un OEM
Figura 4 ACL configurada por un OEM
Microsoft realizó algunos ajustes a las ACL en Windows Vista. En primer lugar, si está acostumbrado a Windows XP, sabe que todos los archivos del sistema operativo son propiedad del grupo Administradores y los administradores tienen control total sobre esos archivos. Como miembro de ese grupo, obtuvo acceso sin restricciones a esos archivos. No es el caso de Windows Vista.
Instalador de confianza En Windows Vista, la mayor parte de los archivos del sistema operativo son propiedad del SID TrustedInstaller y sólo ese SID tiene control total sobre éstos. Esto forma parte del trabajo de integridad del sistema que se realizó en Windows Vista y está específicamente destinado a impedir que un proceso que se ejecuta como administrador o Sistema Local reemplace automáticamente los archivos. Para eliminar un archivo de sistema operativo, necesita entonces tomar propiedad del archivo y agregar una ACE que le permita eliminarlo. Esto ofrece una capa delgada de protección contra un proceso que se ejecuta como Sistema local y tiene una etiqueta Integridad del sistema; un proceso que tiene integridad más baja no debe poder elevarse a sí mismo para cambiar la propiedad. Algunos servicios, por ejemplo, se pueden ejecutar con integridad media, aunque lo hagan como Sistema local. Tales servicios no pueden reemplazar archivos de sistema, de manera que si una vulnerabilidad de seguridad toma el control de alguno de ellos, no podrá reemplazar archivos de sistema operativo, lo que hace más difícil la instalación de un rootkit o de otro malware en el sistema. También a los administradores del sistema que se ofenden por la mera presencia de algún binario de sistema les resultará más difícil eliminar ese binario.
ACE de denegación Encontrará que muchos objetos en el sistema de archivos tienen las ACE de denegación para Todos, que han causado bastante consternación a muchos administradores. Si activa la opción "Mostrar todos los archivos ocultos", podrá ver el familiar directorio Documents and Settings. Pero si hace clic en el mismo, obtendrá el error Acceso denegado. Para entender lo que pasa en Documents and Settings, observe la lista de directorios en la figura 5.
Figura 5 Documents and Settings es un punto de unión, no un directorio
Figura 5 Documents and Settings es un punto de unión, no un directorio
Documents and Settings de hecho, no es un directorio, ¡es un punto de unión! Recuerde que los puntos de unión son semejantes a vínculos simbólicos que simplemente redireccionan el acceso a alguna parte. En este caso, la unión va a un directorio llamado C: \Users. Microsoft modificó apreciablemente el espacio de nombres del sistema de archivos en Windows Vista, y los datos de usuario se mueven ahora a C: \Users. También se movieron otros elementos debajo del antiguo "C:\Documents and Settings\<Username>". Por ejemplo, "C:\Documents and Settings\<Username>\Application Data" se movió a C:\Users\<username>\appdata\roaming. Puede ver claramente los cambios si abre una línea de comandos y usa el comando dir/a como lo hice en la figura 5. La razón por la cual el espacio de nombres cambió tan drásticamente es para hacerlo más intuitivo para los usuarios y obtener una separación más clara entre documentos y datos. En vez de almacenar todos los archivos de datos debajo de la carpeta Mis documentos, ahora los desarrolladores pueden crear sus propias carpetas en el perfil de usuario, y el usuario las verá en esa ubicación. Los datos de programa de todos los usuarios ahora entran en una carpeta oculta denominada %systemroot%\ProgramData en vez de estar debajo de Documents and Settings\All Users\Application Data.
Microsoft no eliminó el espacio de nombres "C:\Documents and Settings" porque los antiguos programas pueden estar codificados para usar ese nombre en lugar de las variables de entorno preferidas, tal como %USERPROFILE%. Estas aplicaciones se interrumpirían si desaparece "C:\Documents and Settings". En lugar de eso, ahora están representados como puntos de unión o symlinks, para compatibilidad con versiones anteriores. Es posible que las aplicaciones que codifican esas rutas de acceso aún se interrumpan, en función de cómo tengan acceso a los datos en las mismas, pero esas mismas aplicaciones ya se interrumpen en versiones de Windows en idiomas distintos del inglés. En realidad esta es la clave. Cuando una actualización de Windows, como Windows XP SP2 o Windows Vista, interrumpe programas de terceros, casi siempre se debe a que los desarrolladores de esos programas hicieron suposiciones no válidas o usaron Windows de una manera inapropiada.
Si intenta abrir un archivo, por ejemplo si escribe “C:\Documents and Settings\<Username>\My Documents\foo.txt", funcionará, siempre y cuando exista un archivo en ese lugar llamado foo.txt. Sin embargo, si trata de examinar en "C:\Documents and Settings\<Username>\My Documents", obtendrá el mensaje de error "Acceso denegado". Para entender lo que sucede, mire las ACL en la figura 6.
Figura 6 Existe una ACE de denegación en Documents and Settings
Figura 6 Existe una ACE de denegación en Documents and Settings
Observe la primera ACE de la lista. Es una ACE de denegación para enumerar los contenidos de carpeta para Todos. Los programas pueden atravesar los puntos de unión y abrir documentos con rutas de acceso absolutas porque Todos tiene el privilegio Omitir comprobación de recorrido (también conocido como SeChangeNotifyPrivilege). Los intentos que realicen un usuario o proceso para enumerar los directorios que representan generarán errores a causa de la ACE de denegación. Debido a esto, no puede ver en realidad lo que se encuentra en el interior de C:\Documents and Settings, ni puede eliminar el "directorio". La idea fundamental de poner esa ACE de denegación es impedir que los usuarios eliminen la unión e interrumpan las antiguas aplicaciones. También sirve recordar a los desarrolladores que no codifiquen las aplicaciones usando el antiguo espacio de nombres y que, en su lugar, comiencen a usar variables de entorno o cadenas de registro para aislar la aplicación de cualquier cambio futuro y diferencias de idioma.
Observe que todos estos puntos de unión de forma predeterminada permanecen ocultos, de modo que la inmensa mayoría de usuarios nunca los verá. Para impedir que quienes los ven los eliminen, Microsoft puso una ACE de denegación en "Mostrar lista de carpetas".
Omitir comprobación de recorrido La razón por la cual los usuarios pueden tener acceso a archivos en los que tienen derechos en el interior de carpetas (o puntos de unión) en los que no tienen derechos es que todos tienen el privilegio Omitir comprobación de recorrido. Omitir comprobación de recorrido, o SeChangeNotifyPrivilege, es realmente el privilegio más básico en Windows y se concede a un proceso al que se quitaron todos los demás privilegios a menos que el proceso solicite específicamente que se quite también ese privilegio. Esto es lo que sucede cuando inicia un proceso que usa la línea runas /trustlevel:0x10000 <en Windows Vista. El programa especificado en <command> se ejecutará con un token restringido y todos los privilegios con excepción de SeChangeNotifyPrivilege se quitarán del token del proceso.
Como aspecto interesante, trustlevel 0x20000 le proporciona un token que posee el conjunto normal de SID pero para el que se han quitado los privilegios. 0x40000 le proporciona un token completamente normal.

Permisos predeterminados
Los permisos predeterminados en el sistema de archivos en Windows Vista han cambiado un poco con respecto a Windows XP. Si observa las ACL en %systemdrive% (normalmente la unidad C:, el volumen de arranque), en Windows XP o Windows Server® 2003, verá lo siguiente (o algo muy semejante en versiones anteriores a Windows XP):
D:AR
(A;OICI;FA;;;BA)
(A;OICIIO;FA;;;CO)
(A;;0x1200a9;;;WD)
(A;OICI;FA;;;SY)
(A;OICI;0x1200a9;;;BU)
(A;CI;0x100004;;;BU)
(A;CIIO;0x100002;;;BU)
Esta es la misma ACL en el mismo directorio de Windows Vista:
D:PAI
(A;;FA;;;BA)
(A;OICIIO;GA;;;BA)
(A;;FA;;;SY)
(A;OICIIO;GA;;;SY)
(A;OICI;0x1200a9;;;BU)
(A;OICIIO;SDGXGWGR;;;AU)
(A;;LC;;;AU)
Hay varias diferencias que cabe destacar. En primer lugar, ahora existen dos ACE para BA (BUILTIN\Administrators) en lugar de sólo una. Sin embargo, el resultado final es el mismo. En Windows Vista, una ACE no se hereda y concede acceso completo a la raíz, y una ACE es una ACE de IO (Sólo heredar), heredada por contenedores y objetos, y concede GA (Todo genérico o control total). Lo mismo se aplica en el reemplazo de la única ACE para SY (Sistema local) por dos en Windows Vista. En Windows XP, la única ACE concedía control total y la heredaban los objetos y contenedores. Nuevamente, no existen cambios. La razón principal por la cual se modificaron las ACL fue clarificar y dividir los privilegios para que las ACL sean más fáciles de administrar e incluso potencialmente de restaurar.
Lo más interesante es que desaparece la ACE para CO (Creador/Propietario). Eso significa que si un usuario crea un objeto en la raíz del sistema de archivos, ya no existen permisos especiales acumulados para el creador.
También puede observar que se quitó la ACE para WD (Todos). Muchas personas interesadas en seguridad, que no entendían quizá completamente las consecuencias de sus acciones, estaban indebidamente preocupadas por esta ACE. Durante años, Microsoft intentó en vano explicar que Todos era funcionalmente idéntico al Usuarios integrados, pero parece que finalmente renunciaron y eliminaron por completo esa ACE. Debido a que existe una ACE idéntica para BU (BUILTIN\Users) heredada también tanto por contenedores como por objetos, el resultado final es que nada ha cambiado.
Además, dos de las ACE para BU (Usuarios integrados) han sido reemplazadas con las ACE para AU (Usuarios autenticados). La razón es que la cuenta Invitado es miembro de Usuarios integrados (en virtud del hecho de que INTERACTIVE es miembro de Usuarios integrados), pero Invitado no es miembro de Usuarios autenticados. Para permitir que la cuenta Invitado lea y ejecute archivos, la ACE 0x1200a9 (Lectura y ejecución efectivas) permanece concedida a BU. Sin embargo, las ACE que conceden permisos para crear archivos y carpetas se conceden en cambio a Usuarios autenticados. Este es un cambio respecto de Windows XP. En Windows XP, un Invitado podía crear archivos en la raíz. En Windows Vista, un Invitado no puede crear dichos archivos. Aún así, tenga presente que todo esto es discutible a menos que se habilite la cuenta Invitado y los invitados puedan de algún modo alcanzar la raíz del volumen de arranque. De forma predeterminada, la cuenta Invitado está deshabilitada.
Como he dejado lo mejor para el final, hay un par de ACE muy interesantes y aparentemente fastidiosas en las dos listas anteriores. En Windows XP, dispone de una ACE heredada por contenedores, al especificar 0x100004 para Usuarios integrados. Esa ACE concede a los Usuarios el derecho de crear subcarpetas y subcarpetas dentro de éstas, etc., debido a que es heredada por los contenedores. También existe una ACE de sólo heredar, heredada por subcarpetas para 0x100002. Esa ACE concede a los usuarios el derecho de crear archivos y subcarpetas en carpetas que crean bajo la raíz. Es decir, estas dos ACE permiten a los usuarios, incluidos los Invitados, crear archivos y carpetas bajo la raíz, tal como mencioné antes.
En Windows Vista, las ACE correspondientes son ACE de sólo heredar, heredadas tanto por contenedores como por archivos, que conceden GR (lectura genérica), GX (ejecución genérica) y GW (escritura genérica) junto con un SD (descriptor de seguridad de lectura) y una ACE que se aplica sólo a la raíz en sí que concede el privilegio LC. LC es realmente un término abreviado que pertenece a las ACE en Active Directory®. En Active Directory significa que un usuario puede listar objetos secundarios. Sin embargo, el valor hexadecimal de LC es 0x4. Para un directorio, 0x4 significa FILE_ ADD_SUBDIRECTORY, funcionalmente equivalente a 0x100004, porque ya contamos con 0x100000 (la capacidad de usar el objeto para la sincronización) de la ACE 0x1200a9. Es decir, ofrece exactamente el mismo efecto que en Windows XP; los usuarios pueden crear subdirectorios bajo la raíz.
¿De dónde provienen los valores hexadecimales? ¿Y, qué significan los valores hexadecimales en primer lugar? Como ya se habrá dado cuenta, el control de acceso está lleno de números hexadecimales (base16), como por ejemplo, 0x1200a9. En realidad, son representaciones de máscara de bits en una máscara de acceso y que se establecen en "activado", lo que significa que se usan en una ACE específica. Al usar una herramienta, tal como icacls, sc o secedit para listar una ACL, las máscaras de bits se representan con cadenas de texto mucho más descriptivas si existe una coincidencia 1:1.
Por lo tanto, para determinar lo que significa LC todo lo que tiene que hacer es ir al sitio web de MSDN®, buscar la cadena LC y mirar en la columna del valor de derecho de acceso para encontrar ADS_RIGHT_ACTRL_DS_LIST. Si a continuación abre el archivo de encabezado Iads.h y busca esa cadena, encontrará que corresponde a 0x4. Para cadenas que no pertenecen a Active Directory (las que no comienzan con "ADS_RIGHT"), generalmente encontrará el valor hexadecimal en AccCtrl.h. Una vez que tiene el valor hexadecimal, es un trabajo fácil buscar en la máscara de acceso en WinNt.h o AccCtrl.h para ver lo que significa en realidad.
Si necesita ayuda, es recomendable obtener una copia del libro Protect Your Windows Network (por Jesper Johansson y Steve Riley, Addison-Wesley, 2005). El capítulo 17 trata en profundidad cómo analizar cadenas y ACE del Lenguaje de definición de descriptores de seguridad (SDDL).
Los permisos concedidos a esos subdirectorios se controlan únicamente mediante las ACE (A;OICIIO;SDGXGWGR;AU) en Windows Vista, lo que constituye la mayor diferencia entre Windows Vista y Windows XP. En lugar de conceder control total al creador de los subdirectorios, como en Windows XP, Windows Vista concede a los usuarios autenticados privilegios para modificar.
El resultado final de estas nuevas ACL es que el creador de un objeto ya no tiene ningún derecho especial y que todo resulta más claro. Quizá el mayor cambio es que Usuarios autenticados tiene privilegios para Modificar incluso en subcarpetas creadas por administradores, lo cual es muy diferente de Windows XP. En Windows XP, Usuarios y Usuarios autenticados no tienen derechos en los objetos creados por los administradores bajo la raíz. Sin embargo, en su conjunto, aunque estas ACE pueden parecer molestas, el resultado final no es muy diferente al de Windows XP.
En resumen, en Windows Vista todos, incluido el usuario Invitado, pueden leer y ejecutar archivos en la raíz. Sólo los usuarios autenticados pueden crear nuevos archivos y carpetas, y cuando lo hacen, pueden modificar permisos en esos archivos y carpetas. Es decir, los permisos son ligeramente más estrictos en Windows Vista que en Windows XP, aunque cabe destacar que la cuenta Invitado está deshabilitada de forma predeterminada.

Cambios en tokens
Cuando un usuario que es miembro del grupo Administradores inicia sesión en Windows XP, su token contiene el SID del grupo Administradores y puede hacer todo lo que el grupo Administradores puede hacer. En Windows Vista, por otro lado, esto ya no es así debido al Control de cuentas de usuario. El SID de Administradores todavía está presente en el token, pero se establece en Sólo denegar, tal como se muestra en la captura de pantalla de Process Explorer de la figura 7.
Figura 7 En UAC, el SID de Administradores sólo se usa para denegar el acceso a menos que lo eleve
Figura 7 En UAC, el SID de Administradores sólo se usa para denegar el acceso a menos que lo eleve
Al realizar el control de acceso, dicha entrada en el token se usa sólo para denegar el acceso; en otras palabras, para hacer coincidir las ACE de denegación. Cualquier ACE para permitir de ese SID será omitida. Esto significa que el usuario no es verdaderamente un administrador todo el tiempo, aún si inicia sesión en el sistema como tal.

Niveles de integridad
Ahora Windows admite el etiquetado de procesos y objetos con niveles de integridad. Estos niveles de integridad también se representan como ACE, pero no en la DACL. En lugar de eso, forman parte de la lista de control de acceso de sistema (SACL), con algunos marcadores especiales. Por ejemplo, el marcador NW se usa para indicar el bloqueo de un proceso a un nivel de integridad más bajo para escribir en un objeto a un nivel de integridad más alto (SDDL_NO_WRITE_UP). Mark Russinovich desarrolla extensamente este tema en su artículo "Dentro del Control de cuentas de usuario de Windows Vista" en este mismo número de TechNet Magazine.

Conclusión
Aunque no existe una modificación única y trascendental para el control de acceso en Windows Vista, como sucedió con Windows 2000, hay una cantidad de pequeños cambios. Cuando los observa por separado no parecen demasiado, pero tomados en conjunto significan en realidad que debe volver a pensar mucho en lo que hace cuando administra su sistema. Además, estos cambios son compatibles con una serie de diferentes iniciativas, de las cuales las más notables son UAC y el sistema de protección de servicios. Algunos administradores se pueden frustrar bastante al comenzar a usar Windows Vista por primera vez. Ya he escuchado comentarios sobre "sistemas operativos tiranos" que restringen la capacidad de eliminar partes del sistema operativo que, por una razón u otra, parecen ofensivas. Sin embargo, hay razones sólidas en todos los cambios y, lo más probable es que si dedica un poco de tiempo para analizar lo realizado, entenderá los motivos.

Jesper Johansson es arquitecto de seguridad en una gran empresa de comercio electrónico, responsable de la estrategia de seguridad de aplicaciones en la gama de las propiedades y los servicios. Ha trabajado durante 20 años en seguridad y es autor de numerosos artículos y dos libros sobre seguridad. Cuando no trabaja en seguridad de la información, se dedica a enseñar buceo.


 Seguridad: Administraci&#243;n de restricciones de hardware mediante directivas de grupo
Seguridad Jeremy Moskowitz,

Administración de restricciones de hardware mediante directivas de grupo
Resumen:
  • Restricción de instalaciones de hardware
  • Restricción de dispositivos específicos
  • Restricción de clases de dispositivos

Sabe que es cierto: estas llaves en miniatura de disco USB y otros tipos de dispositivos extraíbles pueden facilitar la vida personal, pero hacer más difícil la vida profesional. Necesita una manera de controlar cuáles
dispositivos de hardware se pueden instalar y cuáles no. Afortunadamente, con directivas de grupo en Windows Vista™ y en la próxima versión de Windows Server® con nombre en código "Longhorn" tiene la opción de permitir los mouse USB pero deshabilitar las llaves de disco USB, permitir lectoras de CD-ROM, pero no grabadoras de DVD, o permitir Bluetooth pero no PCMCIA.
Dos secciones en la directiva de grupo pueden ayudarle a proteger su hardware: Configuración del equipo | Plantillas administrativas | Sistema | Acceso de almacenamiento extraíble (consulte la figura 1) y Configuración del equipo | Plantillas administrativas | Sistema | Instalación de dispositivo | Restricciones de instalación de dispositivos (consulte la figura 2).
Figura 1 Restricciones de hardware predefinidas en la directiva de grupo
Figura 1 Restricciones de hardware predefinidas en la directiva de grupo
Figura 2 Personalice las clases de hardware que desea restringir
Figura 2 Personalice las clases de hardware que desea restringir
El primer conjunto (Acceso de almacenamiento extraíble) no requiere mucha explicación: Si habilita una configuración de directiva para esa clase de medios de almacenamiento extraíbles (CD/DVD, disquete, etc.), puede restringir la lectura y/o escritura a ese tipo completo de dispositivo, si así lo desea. Pero no cuenta exactamente con los superpoderes que tienen las restricciones de instalación de dispositivos.
En Acceso de almacenamiento extraíble, hay grupos de configuración de directivas denominados clases personalizadas: Clases de denegar acceso de lectura y clases personalizadas: Denegar acceso de escritura. Suena bien, pero la directiva Acceso de almacenamiento extraíble no impide en realidad que se instalen los controladores, el controlador para la clase ya está instalado al detectar el hardware. Lo que la directiva hace es impedir que se lea del dispositivo o se escriba en él. En la sección siguiente, cuando explore la configuración de directiva Restricciones de instalación de dispositivos, bloquearé el uso del propio controlador completo.

Control de las clases y los identificadores
Lo primero es lo primero: necesita saber lo que desea restringir. Puede pensar en grande o en pequeño. Es decir, puede restringir una "clase" específica de dispositivos o ser muy específico y restringir sólo un tipo de hardware. O bien, puede hacer lo opuesto y permitir sólo clases específicas de dispositivo, como los mouse USB. Sin embargo, el truco es el siguiente: para que la acción sea realmente eficaz, necesita encontrar el hardware que quiere restringir.
Así, si quiere decir "No se puede instalar ningún controlador de joystick" y "Sólo se pueden instalar los mouse USB" necesita obtener un joystick y un mouse USB. La alternativa es usar Internet para buscar el Id. de hardware, Id. compatible o clase de dispositivo. Sin embargo, es mucho más sencillo si tiene uno de los dispositivos reales delante suyo. De esta manera, lo puede insertar en el equipo y consultar cuál es el Id. de hardware, Id. compatible o clase de dispositivo. Una vez conocido, sabrá exactamente cómo suprimirlo (o mantenerlo disponible).
En el siguiente ejemplo suprimiré una familia específica de tarjetas de sonido: una Creative AutoPCI ES1371/ES1373. Si desea suprimir algo más (por ejemplo, dispositivos USB específicos, puertos USB, etc.), sólo continúe y sustituya el dispositivo que desea.
Inicie el Administrador de dispositivos en un equipo que ya tiene instalados los elementos de hardware. Cuando encuentre el dispositivo, haga clic con el botón secundario, seleccione Propiedades y, a continuación, la ficha Detalles. De forma predeterminada, verá una "Descripción de dispositivo". Aunque interesante, no es de utilidad. Seleccione el elemento desplegable Propiedad y elija "Id. de hardware", tal como se muestra en la figura 3.
Figura 3 La ficha Detalles del dispositivo
Figura 3 La ficha Detalles del dispositivo
La página Id. de hardware muestra de arriba a abajo los Id. de dispositivo desde los más específicos a los menos específicos. Si examina detenidamente el elemento que se encuentra más arriba en la lista de valores de los Id. de hardware, verá que su tarjeta de sonido es específicamente una Rev 2 de la tarjeta de sonido ES1371. Esto es bastante específico. A medida que baja en la lista, la descripción pasa a ser menos específica para abarcar a la familia entera.
Además, puede cambiar la propiedad a Id. compatibles. Estos Id. también describen el hardware y se consideran menos específicos que los que encuentra en los Id. de hardware. Tiene la opción de usar la información en los Id. compatibles para intentar acorralar más hardware similar al suyo en su lista de "no usar", ya que es menos específico y quizá obtenga en realidad más resultados. Por supuesto, en compensación podría restringir algo que quizá no deseaba.
Y, por último, la categoría menos específica se encuentra al seleccionar la clase de dispositivo del elemento desplegable Propiedad. En mi caso, la tarjeta de sonido aparece simplemente como Medios. Pero varios elementos se pueden considerar Medios, de modo que nuevamente, en la medida que elija el menos específico más cauteloso deberá ser.
Una vez que haya decidido qué valor usar, haga clic con el botón secundario en él, seleccione Copiar y péguelo en el Bloc de notas para guardarlo en lugar seguro. Copiarlo directamente tal como se presenta es importante porque en los pasos siguientes, el valor deberá especificarse de manera idéntica. Todos los caracteres en mayúsculas y minúsculas del valor se deben transferir con precisión.
Si desea ser un comando de línea de comandos en vez de usar el Administrador de dispositivos para capturar lis Id. de hardware o las clases de dispositivo, consulte la utilidad Devcon de línea de comandos en la dirección support.microsoft.com/kb/311272. Y observe que Microsoft tiene varios identificadores para clases comunes que pueden ser de utilidad cuando no dispone de acceso físico al dispositivo; consulte la información en la dirección go.microsoft.com/fwlink/?LinkId=52665.

Control de acceso al hardware mediante directivas de grupo
Aunque exploraremos todas las configuraciones de directivas que se encuentran en Configuración del equipo | Plantillas administrativas | Sistema | Instalación de dispositivo | Restricciones de instalación de dispositivos (que se muestra en la figura 2), realmente existe sólo una que necesitaremos para completar este ejemplo inicial.
Cree primero un objeto de directiva de grupo (GPO) y establezca un vínculo a una unidad organizativa (o dominio, etc.) que contenga los equipos que ejecutan Windows Vista y que desee controlar. Ahora edite el GPO y profundice en Configuración del equipo | Plantillas administrativas | Sistema | Instalación de dispositivo | Restricciones de instalación de dispositivos | Impedir la instalación de dispositivos que coincidan con cualquiera de estos Id. de dispositivo. Seleccione Habilitada en la configuración de directiva, haga clic en Mostrar (también en la configuración de directiva) y, en el cuadro de diálogo "Mostrar contenido", seleccione Agregar. A continuación, en el cuadro de diálogo "Agregar elemento", pegue la información de dispositivo que guardó con anterioridad, tal como se muestra en la figura 4.
Figura 4 Pegado del Id. de dispositivo para capturar con exactitud la descripción
Figura 4 Pegado del Id. de dispositivo para capturar con exactitud la descripción
Ahora el truco está aquí. Si un equipo ya tiene instalado el dispositivo, no lo desinstala mágicamente y restringe el acceso al mismo. Por lo tanto, si está por restringir hardware, quizá desee hacerlo al comienzo de su implementación de Windows Vista. Sin embargo, debe tener en cuenta que Windows Vista siempre reexaminará un dispositivo que se elimina y vuelve a instalar. Elementos como unidades en miniatura USB (que se extraen y posteriormente se reinsertan) son entonces excelentes candidatos para este proceso. Dado que Windows Vista sólo reexamina el dispositivo cuando se vuelve a insertar, restringe en ese momento al dispositivo (incluso si el controlador de dispositivo se cargó inicialmente en el equipo). El problema más difícil tiene que ver con los dispositivos que se distribuyen con un equipo y no son extraídos y reinsertados. Y para estos dispositivos, no existe una solución obvia inmediata.
Cuando enciende un equipo que nunca antes reconoció el dispositivo de hardware, Windows intentará instalar el controlador, ofreciendo información de estado a medida que avanza la instalación. Si establece una directiva que restrinja tales dispositivos, obtendrá un resultado como el que se muestra en la figura 5.
Figura 5 Se evita la instalación de un dispositivo
Figura 5 Se evita la instalación de un dispositivo

Más restricciones de hardware
En el ejemplo anterior, suprimimos únicamente un solo dispositivo. Si lo deseara, podría seguir el camino contrario; restringir todo el hardware de forma predeterminada y a continuación permitir alguno. Nuevamente, puede obtener una lista de esta configuración de directiva en la figura 2, que muestra la rama de la directiva de grupo Configuración del equipo | Plantillas administrativas | Instalación de dispositivo | Restricciones de instalación de dispositivos. Puede elegir entre varias configuraciones disponibles.
En primer lugar, aparece "Permitir que los administradores invaliden las directivas de restricción de instalación de dispositivos". De forma predeterminada, los administradores locales en Windows Vista deben respetar las restricciones establecidas. Si habilita esta configuración, los administradores locales pueden omitir la restricción e instalar cualquier hardware que deseen.
La siguiente es "Permitir la instalación de dispositivos con controladores que coincidan con estas clases de instalación de dispositivos". Si se escriben descripciones de dispositivo en esta configuración de directiva, se permite expresamente que estos dispositivos de hardware se instalen en el sistema. Observe que esta configuración de directiva respeta sólo clases de instalación, no Id. de dispositivo (como los que se usan en el ejemplo).
Para lograr el efecto contrario, puede establecer "Impedir la instalación de dispositivos con controladores que coincidan con estas clases de instalación de dispositivos".
Las dos configuraciones "Mostrar un mensaje personalizado cuando la directiva impida la instalación (texto del globo) y (título del globo)" le ayudan a personalizar el mensaje, tal como se muestra en la figura 5.
Como mencioné anteriormente, la manera menos específica de describir hardware se basa en la clase de hardware. Se debe tener en cuenta que la configuración de directiva "Permitir la instalación de dispositivos que coincidan con cualquiera de estos Id. de dispositivo" no respeta las descripciones de Id. de clase. Para usar las descripciones de Id. de clase, use "Permitir la instalación de dispositivos con controladores que coincidan con estas clases de instalación de dispositivos" o "Impedir la instalación de dispositivos con controladores que coincidan con estas clases de instalación de dispositivos". Esta última directiva se usa mejor con la configuración "Impedir la instalación de dispositivos no descritos por otras configuraciones de directiva". Al impedir todo (de forma predeterminada) y a continuación usar esta configuración, puede especificar con precisión cuáles dispositivos desea admitir.
En el ejemplo, usé la directiva "Impedir la instalación de dispositivos que coincidan con cualquiera de estos Id. de dispositivo" para restringir un tipo específico de hardware basado en los Id. de dispositivo. Si desea implementar restricciones mediante clases de dispositivo, deberá proporcionar otras configuraciones específicas de directiva tales como "Permitir la instalación de dispositivos con controladores que coincidan con estas clases de instalación de dispositivos" o "Impedir la instalación de dispositivos con controladores que coincidan con estas clases de instalación de dispositivos".
"Impedir la instalación de dispositivos extraíbles" es una manera rápida y genérica de restringir cualquier dispositivo de hardware que se describa a sí mismo como extraíble, incluidos los dispositivos USB. Esta configuración es bastante general, de modo que es mejor no usarla con mucha frecuencia. En su lugar, use las técnicas descritas anteriormente para obtener los Id. de dispositivo moderadamente restrictivos y bloquearlos específicamente.
Por último, "Impedir la instalación de dispositivos no descritos por otras configuraciones de directiva" es la configuración general de la directiva que restringe básicamente todo el hardware a menos que haya dictado específicamente que algo se puede instalar. Esta directiva junto con las diferentes directivas "Permitir" (tal como "Permitir la instalación de dispositivos que coincidan con cualquiera de estos Id. de dispositivo") conforman una herramienta realmente eficaz para permitir sólo el hardware que desea en su entorno.

Conclusión
La directiva de grupo en Windows Vista tiene varios nuevos superpoderes, que son de gran utilidad a la hora de permitir sólo el hardware deseado en el entorno. Implemente las configuraciones de directivas al comienzo de la implementación, para que el hardware que no desea en la red no encuentre en ningún momento una forma de conectarse.
Entrevista con Michael Dennis, director de administración de programas para directivas de grupo en Microsoft
Recientemente tuve la oportunidad de entrevistar a Michael Dennis, que ha dirigido el lanzamiento de directivas de grupo en Microsoft desde sus inicios. Michael deja el equipo de directivas de grupo para dedicarse a otras oportunidades en Microsoft. Conversé con Michael para reflejar los últimos nueve años de directivas de grupo, dónde estuvieron y hacia dónde van.

Jeremy Moskowitz Michael, pienso que muchas personas querrían conocer lo que consideras tus mejores logros durante tu tiempo dirigiendo el equipo de directivas de grupo en Microsoft.

Michael Dennis Los mayores logros nos remontan en el tiempo, cuando nos centramos en desarrollar lo que se conocería como directivas de grupo. Ya contábamos con directivas de sistema en Windows NT® 4.0, de modo que las examinamos junto con sus problemas. Dado que esto sucedió durante el período de desarrollo de Active Directory®, examinamos en dónde necesitábamos dirigir mejor la capacidad de administración de clientes y servidores.
La idea era que las directivas de grupo se construyeran en una jerarquía y el hecho de que esta idea nunca antes había sido realizada fue para nosotros muy importante. Entonces, nos concentramos en la infraestructura principal, los procesos cliente y en la integración con Active Directory.
El resultado de nuestro mejor logro fue también nuestro peor logro. Esto se debe a que la GUI que lanzamos al mercado con Windows 2000 fue problemática. Las personas necesitaban un doctorado en directivas de grupo para usarla de forma eficaz porque los administradores necesitaban conocer cómo funcionaba todo en conjunto. Hubiera deseado crear la Consola de administración de directivas de grupo (GPMC) y el Conjunto resultante de directivas (RSoP) y poder ofrecerlos en ese momento (se encontraba en las especificaciones).

JM ¿Qué elementos hubiera deseado que estuvieran incluidos en la experiencia de directivas de grupo?

MD Las buenas noticias son que todo lo que deseaba desde el lanzamiento de Windows 2000 ahora está aquí en Windows Vista; cosas como RSoP, la GPMC, configuraciones aumentadas, etc. Hubiera deseado que pudiéramos contar mucho tiempo antes con todo esto.
Además, deseo que nuestros asociados pudieran extender la infraestructura de directivas de grupo con mayor facilidad. Nuestro modelo de extensión del servidor/cliente requiere mucho trabajo de los desarrolladores. Sin embargo, se puede argumentar que nuestra estructura de plantilla ADM/ADMX ofrece un marco fácilmente extensible. Pero, sería todavía mejor si esa parte del sistema le permitiera a la gente extender más tipos de configuraciones.
También deseo que los informes de GPMC sean más extensibles para asociados y desarrolladores de herramientas de terceros. Es un área en que los proveedores de herramientas de terceros han protestado bastante.

JM ¿Qué es lo que las personas no conocen sobre el equipo de directivas de grupo?

MD A veces no está claro para las personas dónde encaja el equipo de directivas de grupo en el conjunto. La idea es que construimos la infraestructura, el transporte y las partes del extremo del servidor y del cliente. Pero sólo en Windows Vista nos hemos asociado con cerca de 120 equipos diferentes de Microsoft para obtener en su lugar las nuevas configuraciones para este lanzamiento.
Los lectores deben darse cuenta que las directivas de grupo no son responsables de los problemas de ralentización de sistema en el inicio del sistema ni en el inicio de sesión. Es la carga de las directivas de grupo la responsable de la ralentización. Si le dice a las directivas de grupo que realicen una tarea pesada, simplemente lo harán. Por ejemplo, si les dice que instalen por equipo Microsoft Office, fantástico. Pero sepa que harán lo solicitado; instalarán todo Office antes de que obtenga un mensaje de inicio de sesión. ¿Es eso ralentización? Seguro, pero como administrador que la implementó, es exactamente lo que deseaba que hiciera el sistema.

JM ¿Cuál es el aspecto favorito para destacar con el uso de directivas de grupo?

MD En estos días, me gustaría resaltar algunas de las nuevas configuraciones que se hicieron en Windows Vista. Las configuraciones para dispositivos extraíbles (restringir llaves USB, etc.) son configuraciones que las personas pedían. Existen cerca de 2.400 configuraciones disponibles en Windows Vista, que proporcionan a los administradores un nivel de control significativo. Me gusta preguntarles a los clientes lo que desean controlar y, a continuación, mostrarles cómo hacerlo.

JM ¿Por qué cambió de archivos ADM a ADMX?

MD Técnicamente, no necesitábamos hacerlo para obtener la nueva característica de almacén central de Windows Vista. El gran impulso para convertir a ADMX fue permitirnos ser compatibles con múltiples idiomas de una manera apropiada.
Anteriormente, en entornos con varios idiomas encontraba con frecuencia situaciones en que otro idioma escribía accidentalmente el contenido de los archivos ADM dentro de un GPO. Históricamente, pedimos prestado el formato ADM a Windows NT 4.0, que lo había pedido prestado a Windows 98, que a su vez lo había pedido prestado a Windows 95. Si XML hubiera estado entonces, habría sido un buen candidato para nuestro formato de archivo.
Pero, ahora que contamos con XML, resulta más fácil ser compatible con varios idiomas, y presenta oportunidades futuras para realizar mejoras en el Registro y en la configuración con nuestro idioma ahora esquematizado.

JM ¿Cuál fue el mayor desafío interno que tuvo que vencer al trabajar en el equipo de GP?

MD El mayor problema constante que enfrenta el equipo es tratar de hacer que otros componentes de Windows tengan sus características habilitadas mediante directivas.
El equipo X quizá responda &quot;Hemos generado esta fabulosa nueva característica. ¿Por qué quisiera alguien desactivarla?&quot; Y lo podemos entender. Pero trabajamos con muchos de estos problemas.
También existen desafíos técnicos respecto a la habilitación de ciertas funciones mediante directivas, por ejemplo, el nuevo Firewall de Windows con seguridad avanzada (WFAS). WFAS fue difícil de realizar. No es fácil ni directo habilitarlo correctamente mediante directivas. La interfaz que el equipo de WFAS creó para Windows Vista es magnífica, pero fue difícil realizarla de manera correcta.
En versiones de Windows anteriores a Windows Vista, los equipos de producto en sí mismos no siempre pensaban en habilitar sus componentes mediante directivas. Pero, durante el desarrollo de Windows Vista, un número razonable de equipos nos preguntó cómo hacerlo. ¡Eso fue tremendo!
JM ¿Con qué seguirá?

MD Me traspaso al equipo &quot;Trabajador de información móvil&quot; que tiene bajo su responsabilidad los teléfonos inteligentes, equipos Pocket PC, etc. Mi función será extender algunas de las tecnologías de administración de Windows Server System a dispositivos Windows Mobile®.
Intentaré tener la misma visión y pasión por la capacidad de administración y aplicarla en este nuevo espacio. Mientras tanto, dejo el equipo de directivas de grupo en una posición excepcional para que siga avanzando sin mi presencia.

JM ¿Hay algo más que quiera decirles a nuestros lectores?

MD A lo largo del desarrollo de directivas de grupo, un paso importante fue estar al lado de los clientes y entender realmente lo que intentaban hacer. Si los clientes tienen una opinión bien estructurada de los escenarios que les gustaría ver cubiertos por directivas de grupo y tienen un ejemplo de negocios donde realizarlo, nos lo deben comunicar.
Contamos con un buen mecanismo de comentarios disponible para todos en la dirección WindowsServerFeedback.com. Busque el botón Group Policy (Directivas de grupo).
Si su gente puede decir &quot;Éste es mi problema, éste es mi ejemplo de negocio y necesito que el sistema pueda hacer esto y el porqué es éste&quot;, esa clase de información es muy pero que muy valiosa para nosotros. Los que toman decisiones sobre directivas de grupo avanzan mientras leen cada entrada que viene de ese origen.
Nuevamente, si quiere tener repercusión en la forma que avanzan las directivas de grupo, cuéntenos lo que necesita. Pero por favor, no nos diga &quot;Necesitamos una configuración de directiva que haga X&quot; sin decirnos porqué. Nuestro trabajo es resolver el &quot;cómo&quot;. Lo que el equipo de directivas de grupo realmente necesita conocer es el &quot;por qué&quot;.
JM Gracias por dedicarnos tiempo para contarnos sobre tus experiencias en el equipo de directivas de grupo en Microsoft. ¡Qué tengas suerte!
MD Gracias, Jeremy.

Jeremy Moskowitz,MCSE y MVP en directivas de grupo, dirige GPanswers.com, un foro comunitario sobre directivas de grupo. También dirige una serie de talleres intensivos de aprendizaje sobre directivas de grupo. Su último libro es Group Policy: Management, Troubleshooting and Security (Sybex, 2007). Póngase en contacto con Jeremy en la dirección www.GPanswers.com.


 Seguridad: Cuatro tecnolog&#237;as de seguridad que toda organizaci&#243;n de TI debe tener
Seguridad Matt Clapham and Todd Thompson

Cuatro tecnologías de seguridad que toda organización de TI debe tener
Resumen:
  • Panel de administración de riesgos
  • Antimalware
  • Detección de anomalías de red

En lo que se refiere a la seguridad de TI, la mayoría de las empresas tienen que enfrentar en realidad casi los mismos problemas. Microsoft no es la excepción. Pasamos dos años en el equipo de administración de riesgos y conformidad de
Microsoft® Managed Solutions (MMS). (Consulte "Microsoft da una recarga de energía a su división de TI" para obtener más información sobre MMS).
El equipo de administración de riesgos y conformidad está encargado de definir, supervisar y corregir la postura de riesgo de todos los entornos de MMS (tanto para los servicios orientados al cliente como para la coordinación de infraestructura). Desde el principio, nuestro administrador, Arjuna Shunn, reconoció que necesitábamos una solución de tecnología que ofreciera de forma centralizada y cohesiva los controles y la supervisión deseados. Las tecnologías que analizaremos aquí son el resultado directo de nuestras primeras ideas, unidas a dos años de experiencia en el uso de distintos productos de Microsoft y de terceros en nuestras operaciones.
Antes que nada, necesitamos tecnologías de seguridad que abarquen los tres tipos principales de control (prevención, detección y corrección), así como proporcionar auditoria e informes. Vimos esta colección de herramientas divididas en cuatro categorías: panel de administración de riesgos, antimalware, detección de anomalías de red y administración de la configuración deseada. Intentamos incluir por lo menos un representante de cada categoría en nuestras operaciones de administración de riesgos. Y encontramos que al aprovechar las tecnologías de cada una de las cuatro áreas, el equipo de seguridad de TI puede lograr un equilibrio razonable entre costo y eficacia.
Nuestras dos operaciones principales de administración de riesgos (respuesta a incidentes de seguridad y administración del cumplimiento) se han beneficiado mucho con este enfoque, pero todavía tenemos camino por delante en lograr la coordinación entre las herramientas que en última instancia deseamos. Un conjunto cohesivo de tecnologías puede ofrecer mucha más eficacia operativa, pero lamentablemente todavía el sector no dispone de este sistema integrado.
Afortunadamente, no todo está perdido para los equipos de seguridad de TI; es sólo cuestión de tiempo antes de que los cuatro sistemas comiencen a trabajar juntos e interoperar para un efecto mayor. Una vez que estos sistemas trabajen juntos, no sólo permitirán la supervisión activa de la postura de seguridad del sistema, sino que también serán de utilidad durante las auditorias u otras operaciones rutinarias de TI. En este artículo, describimos la función ideal de cada sistema, interponiendo algunos ejemplos de nuestro uso del tiempo de ejecución.

Panel de administración de riesgos
En nuestra opinión, un panel de administración de riesgos (RMD) es absolutamente esencial. Es la tecnología singular más importante para el funcionamiento de un equipo de seguridad de TI. Los riesgos de confidencialidad, integridad, disponibilidad y responsabilidad (CIA2) en una empresa frecuentemente son supervisados por sistemas y procesos separados que no cuentan con una interfaz única para la agregación de los datos, su correlación y la corrección de riesgos. Además, los requisitos de las disposiciones legales especifican niveles cada vez más difíciles de transparencia de datos empresariales, y no existe un sistema perfeccionado para realizar fácilmente un seguimiento de directivas desde la creación hasta su ejecución en la empresa. Esto se pone en evidencia con las dificultades comunes de las empresas en la adquisición, correlación, evaluación, corrección y cumplimiento de los datos. (Aunque no es una solución completa de RMD como la que resumimos aquí, System Center Operations Manager 2007, tal como se muestra en la figura 1, ofrece una interfaz única para supervisar múltiples recursos y recopilar las alertas relacionadas).
Figura 1 System Center Operations Manager 2007 ofrece una interfaz única para visualizar alertas y administrar recursos a través de la red
Figura 1 System Center Operations Manager 2007 ofrece una interfaz única para visualizar alertas y administrar recursos a través de la red
La adquisición de datos se dificulta debido a la incapacidad de agregar y normalizar datos procedentes de orígenes diferentes. La agregación de datos ya de por sí es un desafío, porque requiere salir del frecuente enfoque de silos para recopilar e notificar datos. Aunque la agregación de datos se consiga, la normalización continúa siendo un desafío todavía mayor, porque es muy difícil establecer el marco común necesario para admitir la normalización de los datos. Sin esta normalización, no se puede comparar de una manera coherente eventos de seguridad y relacionados al estado que procedan de diferentes sistemas.
Para llevar a cabo la automatización necesaria, el panel de administración de riesgos debe tener acceso a suministros de datos de otros orígenes que los de las tecnologías de seguridad que se describen aquí. Una gran cantidad de datos que no son de seguridad se puede usar para determinar la postura general de riesgo. Elementos de información, tales como registros de enrutador, seguimiento de activos, estado de revisiones, usuarios que tienen una sesión iniciada, informes de rendimiento y datos de administración de cambios, pueden ofrecer información pertinente para el investigador del incidente. Por lo tanto, el sistema general necesita tener acceso a todos estos datos. Sabemos que incluso las infraestructuras de empresa más centradas en Microsoft incluyen tecnologías que no son de Microsoft, de modo que el RMD necesita aceptar suministros de dichas tecnologías a través de alguna interfaz común.
Si los datos se pueden adquirir y normalizar, el paso siguiente es correlacionarlos. El objetivo es poner en correlación una secuencia de eventos (tal como un evento de anomalía de red, un evento de informe de antivirus y un evento de variación de configuración deseada) en datos relacionados con riesgos que se puedan procesar. Esto requiere un trabajo manual intensivo para generar la lógica de correlación que tendrá como resultado una alerta coherente basada en riesgos. Según las tecnologías actualmente disponibles, esta lógica de correlación es, en el mejor de los casos, difícil de lograr.
Valorar los datos también requiere un trabajo manual intensivo. En el caso en que sucede la correlación, un analista debe todavía mirar los datos correlacionados para determinar su eficacia. La eficacia de los datos correlacionados será solamente tan fuerte como las reglas en que se basan. Esto conduce a un análisis personal posterior de los datos correlacionados para valorar el riesgo del entorno de TI. Un marco de trabajo claro y codificado de administración de riesgos podría ayudar a reducir en este caso la cantidad de intervención manual necesaria para alcanzar un nivel de selección. Sin este marco, el desarrollo de un conjunto práctico de reglas de correlación en una implementación dada es dificultoso.
Si se supone que un sistema ha alcanzado el punto de evaluación del riesgo, el paso siguiente es la corrección automatizada. Hoy, en realidad, ésta sólo existe en las empresas, y aún así se ha realizado en un conjunto limitado de tecnologías, tal como la administración de revisiones o antivirus. La corrección automatizada encabezada por el sistema RMD ofrecerá a la administración de TI una extraordinaria capacidad para mantener niveles de riesgo de TI aceptables. Cuando varios riesgos se identifican de forma simultánea, la lógica de correlación debe tener la capacidad de ayudar a establecer prioridades en la respuesta al incidente basada en datos de clasificación de activos.
Por último, ofrecer evidencia del cumplimiento con los distintos requisitos de las disposiciones legales es un gigantesco desafío para los departamentos de TI y, como hemos mencionado, este sistema debe admitir dicha funcionalidad. Un sistema centralizado de administración de riesgos vinculado a las directivas puede ser un gran activo para la generación de informes y evidencia del cumplimiento. Pero la directiva necesita abarcar más que los dónde y porqué. Para facilitar la corrección automatizada, la directiva se debe traducir en un conjunto de estándares que el panel pueda supervisar y aplicar, así como proporcionar comentarios sobre ellos.
De modo que podemos resumir el panel de administración de riesgos ideal como una manera de ofrecer una interfaz unificada para la evaluación del estado de la empresa, del cumplimiento de disposiciones legales y directivas y de los procesos de administración de riesgos. Esto se logra al combinar información de productos y orígenes diferentes relacionados con el estado y la seguridad del sistema en una pantalla cohesiva de todo lo que tiene relación con el riesgo. Una buena solución RMD necesita realizar lo siguiente:
  • Agregar, normalizar y poner en correlación datos de orígenes dispares
  • Proporcionar recopilación de información y evaluación de riesgo automatizadas
  • Asignar requisitos de las disposiciones legales a las directivas y admitir auditorias e informes
  • Proporcionar un marco unificado que se pueda modificar para adaptarse a las necesidades de la empresa
El panel debe permitir organizar y visualizar datos con significado, mostrando, por ejemplo, principales incidentes por sistema de origen, incidentes pendientes, incidentes resueltos, etc. También debe permitir explorar cada elemento de la línea del informe para obtener mayores detalles. Cuando observe un evento, el usuario debe tener fácil acceso a cualquiera de los datos relacionados y a su totalidad. Esto mejorará las decisiones y permitirá que éstas se tomen con mayor rapidez.
Debemos remarcar que el RMD también es útil para los administradores que no pertenecen al equipo de seguridad. Dado que el panel abarca una vista integral del entorno, el RMD puede actuar como un punto centralizado para que todo el personal visualice el estado actual. El panel puede, por ejemplo, alertar al equipo de mensajería sobre un ataque de denegación de servicio en la puerta de enlace SMTP. Aunque se trate de un incidente de seguridad para el equipo de administración de riesgos, el equipo de mensajería lo verá como un incidente de disponibilidad. Si bien es posible que el equipo de mensajería no sea responsable de analizar y resolver tal incidente, querrá por lo menos estar enterado de incidentes como éste que afectan a los activos que administra el equipo.

Tecnologías antimalware
Un sistema completo antimalware es importante para proteger su infraestructura contra amenazas ocultas en código y acciones de usuarios imprevistas. En la actualidad, existen generalmente dos tipos diferentes de herramientas para la protección contra malware: antivirus y antispyware. (Windows® Defender, por ejemplo, mostrado en la figura 2, se incluye en la segunda categoría). Ambos evitan, detectan y corrigen diferentes tipos de infección de forma eficaz. Sin embargo, es sólo cuestión de tiempo antes de que estos dos tipos de protección se unifiquen en una única solución y en un sistema habrá sólo una pila antimalware.
Figura 2 Windows Defender ayuda a proteger a los clientes del spyware
Figura 2 Windows Defender ayuda a proteger a los clientes del spyware
Una solución completa antimalware necesita supervisar en tiempo real y realizar análisis de forma periódica. Debe informar de forma centralizada sobre malware conocido (incluidos virus, spyware y rootkits) y desconocido en función de comportamientos típicos de riesgo. Una tecnología robusta antimalware observa todos los puntos de entrada clásicos (incluidos el sistema de archivos, Registro, shell, explorador, correo electrónico y aplicaciones conectadas) a través de una estricta integración con el sistema operativo y las aplicaciones.
Adicionalmente, una solución antimalware debe abarcar más que sólo la seguridad del host. Necesita observar los servicios comunes de mensajería y colaboración por los cuales pasan con frecuencia archivos infectados, tales como SharePoint® y mensajería instantánea. También debe proporcionar una prevención automatizada deteniendo operaciones (conocidas y bajo sospecha) y analizando cuidadosamente los datos del usuario para eliminar, por ejemplo. virus de macros que se ocultan en documentos del usuario y que todavía no infectaron el sistema.
No hace falta decir que el antimalware es inútil sin actualizaciones. El sistema debe mantener actualizados su firma digital y sistemas de eliminación para adelantarse a las últimas amenazas. Si aparece una nueva amenaza, el proveedor debe establecer protecciones adicionales antes de la siguiente interrupción de la amenaza de día cero. Una solución antimalware fácil de administrar también se configura y actualiza de forma centralizada.
Por supuesto, esta protección no se puede realizar a costo del rendimiento. Si el rendimiento sufre, la productividad también lo hará. Incluso es posible que los usuarios intenten deshabilitar la solución antimalware, conduciendo a una ausencia total de protección.
Por último, no pase por alto la importancia de tecnologías auxiliares para asistir al sistema antimalware. Firewalls, limitación de privilegios del usuario y otras estrategias mejoran también la protección contra código y acciones de usuario malintencionados.

Detección de anomalías de red
Mientras el antimalware cuida los sistemas, la detección de anomalías de red (NAD) supervisa los caminos comunes al observar indicadores conocidos de comportamiento sospechoso e informar al RMD para su corrección. (Un firewall, por ejemplo, tal como se muestra en la figura 3, se podría incluir en esta categoría). Los comportamientos sospechosos podrían ser tráfico de ataques conocidos (tal como un gusano o una denegación de servicio) o datos que se adaptan a cierto patrón (tales como los números de Seguridad Social de EE.UU.) que se envían por correo electrónico.
Figura 3 Un firewall es una parte importante de una solución de detección de anomalías de red
Figura 3 Un firewall es una parte importante de una solución de detección de anomalías de red
A pesar de los mejores esfuerzos de la administración de TI, cualquier red de una gran empresa inevitablemente tendrá un incidente ocasional con malware. NAD puede ofrecer un sistema de alerta temprana que puede ayudar a acelerar la corrección. Además, las capacidades de supervisión de datos de NAD y su habilidad para identificar y detener la pérdida de información confidencial, son herramientas útiles para la protección de información en un entorno preocupado por pérdidas de datos y cumplimiento de las disposiciones legales.
Como sucede con las tecnologías antimalware, NAD se debe adaptar constantemente al último conjunto de amenazas y tipos de datos confidenciales o su valor disminuirá apreciablemente. Además, un buen sistema NAD debe entender bastante sobre verdaderas anomalías para minimizar el número de falsos positivos informados. De lo contrario, los administradores pueden comenzar a omitir los informes provenientes de NAD, porque suponen que se trata de otra falsa alarma.
Después de un poco de optimización o entrenamiento, el sistema NAD conoce y supervisa los patrones típicos de uso de tráfico. Esto es importante porque los nuevos tipos de malware y otros ataques pueden revelarse a sí mismos con un cambio en los patrones de uso. Los equipos de red juegan un papel significativo en el sistema NAD general, porque la solución debe procesar datos de enrutadores, conmutadores y firewalls. Las alertas de NAD se pueden procesar con el motor de correlación en el RMD.
Existe aquí una posibilidad interesante de integrar los detectores de anomalías de red en el software antimalware o firewall del host y arrojar una red de protección en donde todos los equipos incluidos ayudan a observar y potencialmente a detener los ataques antes de que se propaguen.

Administración de la configuración deseada
Uno de los mayores desafíos a los que se enfrentan los departamentos de TI en las grandes empresas es mantener los sistemas apropiadamente configurados. Existen muchas motivaciones para querer mantener las configuraciones del sistema; facilitar la administración, simplificar la escalabilidad, garantizar el cumplimiento, bloquear las distintas formas de intrusión y promover la productividad, por nombrar algunas. Muchas de estas razones se toman en cuenta en la seguridad.
La administración de la configuración deseada es un área en gran parte sin explotar en la mayoría de las empresas debido a su complejidad y costos iniciales. Pero los estudios demuestran que a largo plazo, el mantenimiento de los sistemas conduce a ahorros de costos y a una confiabilidad mejorada. Una solución de supervisión de configuración deseada (DCM) puede ayudar.
Un buen sistema DCM debe analizar automáticamente la red para garantizar que los nuevos sistemas se implementan según lo deseado y comprobar además que los sistemas establecidos permanecen en cumplimiento. Tanto si desea estar seguro de la implementación de la última revisión como si pretende minimizar el número de usuarios que tienen privilegio de dominio, una solución completa de DCM debe configurar sistemas, analizarlos y notificar la proximidad de cada configuración de la ideal. Las correcciones pueden ser sencillas (como por ejemplo, aplicar la revisión a nuevos sistemas en la red en el momento que se implementan) o enérgicas (como por ejemplo, implementar la configuración del cliente de correo electrónico para usuarios). La clave está en vincularlas a las directivas y a la postura de la organización sobre las disposiciones legales. (DCM también puede ayudar a identificar e eliminar infecciones provocadas por malware, porque los tipos sencillos se muestran con facilidad en los resultados de la exploración).
DCM es uno de los principales notificadores de datos del motor de correlación del RMD y ofrece detalles importantes sobre cómo el host en cuestión varía respecto a la normalidad. La vigencia de sus datos puede fijar la diferencia entre un incidente de seguridad de una o cinco alarmas, por lo que un activo se debe analizar con una frecuencia proporcional a su valor; por ejemplo un activo con baja sensibilidad se puede analizar mensualmente, mientras que un activo de sensibilidad moderada se analiza semanalmente, y uno de alta sensibilidad se comprueba por lo menos una vez al día.
La instalación de un DCM también es una parte fundamental de un buen mecanismo de protección de acceso a redes (NAP). Esto es así para que el sistema pueda comprobar que todos los sistemas conectados están configurados apropiadamente y bloquear sistemas nuevos o desconocidos hasta que se validen. Además, DCM deberá buscar vulnerabilidades de configuración (tales como listas deficientes de control de acceso en un recurso compartido) para que los administradores puedan tomar las medidas apropiadas.
No imagine que DCM se aplica sólo a hosts tales como clientes o servidores. Los dispositivos de red y el núcleo del directorio en sí mismo son candidatos para incorporar DCM. Cuando existe un diseño de red razonablemente bien entendido, la aplicación de estándares en los dispositivos asociados debe ser un problema trivial para el sistema DCM ideal. ¡Imagine las posibilidades! En vez de ajustar configuraciones de enrutadores de forma manual, el DCM puede controlar la implementación. O bien, digamos que un conjunto de configuraciones estándar de directivas de grupo está asociado a un conjunto específico de servidores o clientes. El DCM los debe supervisar y enviar una alerta si se producen cambios en las configuraciones del dominio.
Los datos que recopila el DCM deben ser lo suficientemente robustos como para que se puedan usar en una auditoria de TI. Un buen DCM debe tener enlaces a la administración de cambios y a los controles de cumplimiento de disposiciones legales para poder tomar medidas sobre las necesidades de auditoria de manera oportuna, y casi continua. Por ejemplo, una de nuestras verificaciones de control rutinario es comprobar que la pertenencia del administrador local en los servidores MMS no cambie. ¡El cumplimiento de esta regla es la razón por la cual DCM fue diseñado!
Aún si su departamento de TI no está listo para un sistema DCM de corrección automática, se puede implementar una variación conocida como supervisión de configuración deseada que ofrece buenos resultados. También ofrece informes y alertas sobre problemas de configuración, pero no se logran necesariamente las mismas economías de escala porque la corrección es fundamentalmente manual. Lo que importa, sin embargo, es que la notificación y los datos que necesita RMD estarán disponibles para la correlación.
No obstante, cabe ofrecer una palabra de advertencia. DCM, en cualquiera de las formas que he descrito, se tiene que limitar sólo a los elementos mínimos de importancia para la configuración junto con los datos estándar de recopilación de activos. De lo contrario, puede afectar a la flexibilidad que necesita el equipo de TI. Si las guías de configuración de DCM se retrasan, DCM será considerado rápidamente como una carga operativa en lugar de una herramienta útil. De modo que es importante mantenerse al tanto de las últimas ideas sobre cómo configurar óptimamente los activos. Aún más, sugerimos que el sistema DCM incluya actualizaciones regulares a sus guías de configuración de acuerdo a las prácticas recomendadas para activos o aplicaciones en cuestión.

Conclusión
Independientemente de si se crea en la empresa o se adquiera a un proveedor acreditado, el panel es esencial, ya que actúa como la herramienta principal de su equipo para respuesta a incidentes. El antimalware también es esencial y le ayudará a protegerse contra las amenazas que se multiplican a diario. La detección de anomalías de red está al borde del cambio, de sólo incluir las firmas digitales de malware y detección de intrusiones en hosts, a incorporar el descubrimiento de pérdida de datos; y esta última función puede ayudar a impedir las futuras infracciones de red bien publicitadas. La administración de la configuración deseada, aunque todavía nueva, pronto será fundamental para la supervisión y el mantenimiento de configuraciones. Independientemente de quién ofrece estas herramientas, ¡debe contar por lo menos con alguna de ellas en cada una de las cuatro categorías!
De lo visto hasta ahora, ningún proveedor de forma individual (incluido Microsoft) ofrece una única solución integrada que resuelva los cuatro espacios. Depende de usted la selección de productos que se adaptarán a sus necesidades específicas. En este artículo sólo quisimos ofrecerle una perspectiva de qué es lo que necesita considerar, qué debería intentar lograr y qué es lo que realizará una solución ideal.

Matt Clapham es un ingeniero de seguridad en el grupo Infrastructure and Security de la división TI de Microsoft. Con anterioridad trabajó durante dos años en el equipo de administración de riesgos y conformidad de Microsoft Managed Solutions.
Todd Thompson es ingeniero de seguridad en el grupo Infrastructure and Security de la división TI de Microsoft. Con anterioridad trabajó durante dos años en el equipo de administración de riesgos y conformidad de Microsoft Managed Solutions.


 Seguridad: Una eficaz herramienta nueva para la administraci&#243;n de certificados
Seguridad Kevin Dallmann

Una eficaz herramienta nueva para la administración de certificados
Resumen:
  • Arquitectura de ILM-CM
  • Administración y plantillas
  • Creación de un flujo de trabajo

Es un día tranquilo en el trabajo cuando, de repente, recibe una llamada del equipo de soporte técnico: caducó un certificado en uno de los sistemas de producción. Ahora el sistema no funciona y la compañía perderá productividad (y dinero) hasta que se renueva el certificado.
Si usted es el responsable de administrar un entorno de infraestructura de claves públicas (PKI), estoy seguro de que le habrá sorprendido que un certificado haya caducado inesperadamente. El día tranquilo ya no es más que un sueño.
Cuando Microsoft agregó los servicios PKI a Windows® 2000 y Windows Server® 2003, era una manera económica y buena mediante la que las compañías podían implementar su propio entorno PKI interno. Lamentablemente, los servicios PKI de Microsoft® no tenían la capacidad para administrar el ciclo de vida de los certificados generados. Sin embargo, Microsoft adquirió recientemente un producto de administración de certificados y lanzó Identity Lifecycle Manager (ILM), que combinaba la administración de certificados con las características de aprovisionamiento y control de identidades de Microsoft® Identity Integration Server (MIIS). Este artículo tratará sobre cómo ILM le puede ayudar a administrar certificados y tarjetas inteligentes en su organización.

Arquitectura de ILM-CM
El núcleo de la arquitectura de la administración de certificados ILM (ILM-CM) es el servidor ILM-CM y los componentes relacionados (consulte la figura 1). El servidor ILM-CM se puede instalar en un solo servidor configurado para interactuar con una o varias entidades emisoras de certificados (CA). ILM-CM requiere SQL Server™, que almacena información acerca del certificado, directivas y otros datos relacionados que se usan para administrar el entorno de certificados. Para administrar los permisos de usuarios y seguridad, el servidor ILM-CM también requiere Active Directory®. Consulte la figura 2 para conocer los componentes y las versiones necesarios.
Figure 2 Compatibilidad de la infraestructura de ILM-CM (Close Figure 2)

Componentes | Versiones
Active Directory | Windows Server 2003
Servidor de base de datos | SQL Server 2000 SP3 o superior o SQL Server 2005
Entidad emisora de certificados | Windows Server 2003 Enterprise Edition o Data Center Edition
SMTP | Servidor SMTP
Figura 1 Arquitectura de ILM-CM
Figura 1 Arquitectura de ILM-CM
Cuando el entorno de ILM-CM esté completamente instalado, todas las solicitudes de certificados se comunicarán al servidor ILM-CM. El servidor ILM-CM se encarga de almacenar toda la información relacionada con el certificado en la base de datos de SQL Server, que se puede usar para crear informes adicionales de certificados, enviar avisos y mantener un entorno de flujo de trabajo.
La arquitectura del software de ILM-CM consta fundamentalmente de tres partes de alto nivel: el servidor ILM-CM, complementos de CA y componentes de cliente. El software del servidor se puede instalar y ejecutar en una entidad emisora de certificados o en un servidor que se use principalmente para ILM-CM. A continuación, el servidor ILM-CM se comunica con las CA, con la base de datos de SQL Server y con Active Directory. El servidor también ofrece un portal web que los administradores de certificados pueden usar para configurar las directivas y los flujos de trabajo de certificados, así como para que los suscriptores de certificados soliciten y renueven sus certificados de software.
Para que la CA se comunique con el servidor ILM-CM, deben instalarse y configurarse los módulos de salida y directiva de ILM-CM en todas las CA que desee administrar. Estos dos módulos se usan para registrar información de certificados en la base de datos. Cuando una CA emite un certificado, el módulo de salida se encarga de enviar esa información al servidor ILM-CM, que, a su vez, registra la información acerca del certificado en la base de datos.
Si prevé administrar tarjetas inteligentes en su entorno, deberá instalar el software de cliente de tarjeta inteligente de ILM-CM. Este software debe instalarse en todos los equipos cliente que vayan a interactuar con el servidor ILM-CM.

Instalación de ILM-CM
La instalación del servidor ILM-CM es bastante sencilla, un asistente le guiará por el proceso. Pero, antes de ejecutar el asistente, deberá realizar unas cuantas funciones de preinstalación.
La primera cosa que requiere ILM-CM es Active Directory y una ampliación del esquema de ILM-CM. La ampliación del esquema agrega algunos atributos de seguridad adicionales de Microsoft .NET Framework que ILM-CM necesita para implementar las plantillas de perfil.
También deberá instalar .NET Framework 2.0 y los componentes mencionados anteriormente (SQL Server, CA y el servidor SMTP). Si va a instalar ILM-CM en un servidor separado de la CA, deberá instalar los módulos de ILM-CM en las CA ejecutando el asistente de instalación de ILM-CM en las CA. Cuando la instalación haya finalizado, debería poder conectarse al portal de ILM-CM especificando en el explorador la dirección http://hostname/CLM.
Para habilitar la notificación de caducidad/renovación de certificados, configure el servicio de ILM-CM en el servidor ILM-CM. Empiece por crear una cuenta apropiada en Active Directory. Entre en los servicios de ILM-CM y agregue esa cuenta como cuenta de inicio de sesión. A continuación, agregue ese usuario a los administradores locales y al grupo IIS_WPG en el servidor ILM-CM, así como a "Actuar como parte del sistema operativo, Generar auditorías de seguridad y Reemplazar un token de nivel de proceso" mediante directivas de grupo. Cuando haya configurado el servicio de ILM-CM, el servidor ILM-CM podrá buscar en la base de datos de SQL Server los certificados caducados y enviar notificaciones por correo electrónico a los propietarios o administradores de los certificados.

Administración de ILM-CM
ILM-CM se administra a través de una interfaz web que se divide en áreas funcionales relacionadas con tareas de administración de usuarios, certificados y tarjetas inteligentes. Cuando se conecta al portal de ILM-CM con los privilegios administrativos apropiados, se muestran varias tareas administrativas que le permiten administrar el entorno de ILM-CM (consulte la figura 3). La sección de tareas comunes ofrece opciones de administración, tales como inscribir a los usuarios a un nuevo conjunto de certificados o una tarjeta inteligente. También puede administrar y aprobar solicitudes.
Figura 3 Tareas del portal de administración de ILM-CM
Figura 3 Tareas del portal de administración de ILM-CM
Si necesita localizar usuarios o certificados, use el área de tareas para administrar usuarios y certificados. Estas tareas le permiten buscar, recuperar, revocar o renovar certificados. También puede buscar una lista de revocación.
Si su organización usa tarjetas inteligentes, le será de utilidad la sección para administrar tarjetas inteligentes de usuario. Si, por ejemplo, un usuario ha bloqueado su tarjeta, el administrador de certificados puede desbloquear la tarjeta aquí. También puede buscar y ver tarjetas inteligentes en el lector de tarjetas local.
El área de solicitudes de la interfaz permite a los administradores de certificados revisar y aprobar las solicitudes de certificado de usuario. Por ejemplo, podría ver todos los certificados que se incluyen en una solicitud de estado pendiente. En el área de administración puede crear y administrar plantillas de perfil. Por último, el área de informes se usa, como se imaginará, para desarrollar y crear informes relacionados con usuarios y certificados.
Al autenticarse en el portal de ILM-CM, si su cuenta no tiene privilegios administrativos, se le dirigirá a una página de suscriptor que ofrece funciones de administración sin intervención del administrador para los usuarios de certificados (consulte la figura 4). Desde este portal, los usuarios pueden ver y administrar sus certificados y tarjetas inteligentes de acuerdo con su configuración de directivas. Algunos ejemplos de tareas comunes son solicitar certificados o una tarjeta inteligente, revisar los certificados existentes y cambiar los códigos PIN de tarjetas inteligentes.
Figura 4 Página del portal del suscriptor para la autoadministración del usuario
Figura 4 Página del portal del suscriptor para la autoadministración del usuario
Para cualquier organización, poder ofrecer un proceso de flujo de trabajo delegado y de alta calidad para emitir, renovar, reemplazar y revocar certificados o tarjetas inteligentes puede suponer un desafío. Ahora, con ILM-CM tiene la posibilidad de delegar estas tareas para ofrecer una mayor garantía de seguridad. Supongamos que tiene un usuario que ha olvidado el código PIN de su tarjeta inteligente. Gracias al modelo de flujo de trabajo delegado, el usuario podría llamar a la línea de soporte técnico y el personal de soporte técnico le realizaría unas cuantas preguntas de verificación. Si el usuario responde a las preguntas correctamente, el personal de soporte técnico podría desbloquear la tarjeta inteligente del usuario. Otro ejemplo de flujo de trabajo delegado sería la recuperación de un certificado EFS (sistema de archivos cifrado) de usuario en caso de eliminación accidental o extravío de un equipo portátil.

Plantillas de perfil
Una plantilla de perfil es el componente fundamental que habilita un proceso completo de administración de flujos de trabajo para ILM-CM. Una plantilla de perfil se considera como un solo objeto administrativo que contiene una o más plantillas de certificado. Las plantillas de perfil se crean y configuran para administrar el funcionamiento del proceso de flujo de trabajo en el entorno de certificados. El aspecto clave de una plantilla de perfil es que puede contener varias plantillas de certificado, que se pueden administrar como un solo elemento. Esto significa que los usuarios se pueden administrar con una plantilla que puede realizar un seguimiento del proceso del certificado a lo largo de su ciclo de vida.
Las plantillas de perfil se pueden configurar para que almacenen los certificados en un equipo (basado en software) o en una tarjeta inteligente (basada en hardware). Puede crear estas plantillas duplicando una muestra del portal de administrador de ILM-CM. Dentro de la plantilla de perfil, puede definir diferentes componentes de directivas de administración (consulte la figura 5).
Figura 5 Una plantilla de perfil
Figura 5 Una plantilla de perfil
Muchos de los componentes de directiva se pueden aplicar a los perfiles de software y de tarjeta inteligente (consulte la figura 6). Algunos de estos componentes merecen un comentario adicional. Durante el proceso de inscripción de certificados, puede usar el componente de directiva de inscripción para definir ciertos criterios relacionados con el flujo del proceso de inscripción. Por ejemplo, podría configurar una colección de datos, de modo que el usuario tenga que especificar información como, por ejemplo, los códigos de departamento, la dirección de correo electrónico y el administrador. También podría crear definiciones que impriman automáticamente un documento oficial cuando el usuario se haya inscrito a un certificado.
Figure 6 Directivas de perfil de software (Close Figure 6)

Componente | Descripción
Detalles del perfil | Proporciona los detalles generales de la plantilla de perfil. Aquí puede agregar una o más plantillas de certificado a la plantilla de perfil.
Directiva de duplicados | Define las entidades de flujo de trabajo de un certificado existente.
Directiva de inscripción | Define el flujo de trabajo del proceso de inscripción.
Directiva de actualización en línea | Es similar a la directiva de renovación, con la diferencia de que puede actualizar los certificados que caducan, el contenido del certificado, las plantillas y los subprogramas de tarjeta inteligente.
Directiva de recuperación en nombre de | Recupera los certificados o la clave privada de un usuario.
Directiva de renovación | Define el flujo de trabajo de renovación cuando caduca un certificado.
Directiva de rehabilitación | Define el proceso para rehabilitar un certificado.
Directiva de recuperación | Define el flujo de trabajo para recuperar un certificado de usuario almacenado en un equipo que fue eliminado, reconstruido o robado.
Directiva de revocación | Define el flujo de trabajo para revocar todos los certificados de un perfil.
La directiva de actualización en línea puede ser muy útil para su organización. Es similar a la directiva de renovación, con la diferencia de que puede actualizar el contenido del certificado, las plantillas del certificado y los subprogramas de tarjetas inteligentes, además de actualizar el propio certificado cuando está a punto de caducar. Para usar todas las funciones de esta directiva, debe habilitar el servicio de ILM-CM y el archivo web.config para permitir el acceso a un atributo multivalor en Active Directory. También debe instalar el servicio de actualización en línea en el equipo cliente.
La directiva de recuperación en nombre de puede ser útil si la compañía usa el cifrado EFS. Suponga que alguien elimina accidentalmente su certificado de cifrado. Podría usar este componente de directiva para configurar un flujo de trabajo en el que el equipo de seguridad de asistencia solicite la clave privada del usuario. Entonces, el usuario podría recuperar su clave privada en un correo electrónico con una contraseña secreta que generó el servidor ILM-CM. Por último, tendría que ir a un vínculo web secreto en el servidor ILM-CM para recuperar el certificado con sus claves privadas asociadas. La directiva de recuperación en nombre de también es muy útil cuando un empleado deja la organización, pero es necesario recuperar sus datos para fines de archivado, administrativos u otros.
Para ofrecer un proceso de renovación más seguro, la directiva de renovación le permite configurar y enviar por correo electrónico la antigua contraseña secreta que necesitan los usuarios para renovar sus certificados. Si revoca un certificado y, después, desea rehabilitarlo y eliminarlo de la Lista de revocación de certificados (CRL), la directiva de rehabilitación puede definir ese proceso de flujo de trabajo.
Los dos componentes de directiva exclusivos y asociados sólo con directivas de certificado de software, y no con tarjetas inteligentes, son la directiva de recuperación y la directiva de revocación. Si se elimina un certificado de usuario almacenado en un equipo o un equipo se vuelve a montar o se roba, la directiva de recuperación podría definir el proceso para restaurar el certificado o las claves si están archivadas en la CA. La directiva de revocación permite al administrador establecer un motivo estático de revocación o dejar que la persona que realiza la solicitud de revocación designe el motivo en el momento de la revocación.
Hay cinco directivas de administración adicionales específicas para las plantillas de perfil de tarjeta inteligente, tal como se muestra en la figura 7.
Figure 7 Directivas de perfil de tarjeta inteligente (Close Figure 7)

Componente | Descripción
Directiva de sustitución | Define el perfil en caso de pérdida o robo de la tarjeta inteligente de un usuario.
Directiva de deshabilitación | Define el proceso de deshabilitar certificados en una tarjeta inteligente antes de su caducidad.
Directiva de retirada | Define el proceso para revocar todos los certificados de una tarjeta inteligente.
Directiva de desbloqueo | Define quién puede desbloquear el PIN de usuario de una tarjeta inteligente.
Directiva de tarjetas temporales | Define una tarjeta de reemplazo a corto plazo. El usuario recibe certificados de firma nuevos, pero podría descifrar sus datos obteniendo los certificados de cifrado del perfil existente.
Puede definir diferentes operaciones para la directiva de retirada, como por ejemplo, borrar datos de usuario de la tarjeta inteligente, bloquear los códigos PIN del usuario y el administrador, y restablecer el código PIN del administrador. La directiva de desbloqueo suele usarse cuando un usuario olvida su código PIN o se envió una tarjeta nueva con un código PIN asignado por ILM-CM. Entonces, el usuario solicita el desbloqueo de la tarjeta inteligente.
Al igual que en el caso de los productos administrativos, la creación de informes es una característica muy útil aquí. La capacidad para capturar una instantánea del entorno de certificados o tarjetas inteligentes es muy importante para cualquier organización. ILM-CM incluye varios informes integrados con inventarios de tarjeta inteligente, resúmenes de solicitudes, uso y caducidad de certificados, etc. Al igual que en otros sistemas de informes, si necesita informes adicionales, puede escribir una consulta personalizada, ya que todos los datos están almacenados en una base de datos de SQL Server.

Desarrollo de un flujo de trabajo
Veamos ahora cómo puede ayudarle ILM-CM a definir un proceso de flujo de trabajo productivo. Supongamos que tiene varios administradores de sistemas responsables de la administración y el mantenimiento de certificados SSL en sus sistemas. La primera pregunta es: ¿Cuáles son los aspectos clave del proceso?
En función del tipo de sistema, el proceso puede requerir diferentes métodos de creación del archivo de solicitud de certificado. Así que la primera tarea consiste en desarrollar una página de intranet que contenga instrucciones detalladas sobre cómo crear la solicitud de certificado para todos los sistemas.
Cuando el administrador haya creado el archivo de solicitud, puede enviarlo al portal de usuarios de ILM-CM para la aprobación del certificado. El administrador puede usar el proceso de flujo de trabajo de ILM-CM para definir varios aprobadores que deberán comprobar y aprobar una solicitud de certificado. Una vez que se haya aprobado un certificado, el usuario puede recuperarlo en ILM-CM. ILM-CM coloca la información del certificado en una base de datos de SQL Server, de modo que los administradores pueden recuperar información histórica.
Un año más tarde, cuando se acerque la fecha de caducidad del certificado, ILM-CM enviará una notificación por correo electrónico al solicitante para informarle de que el certificado está a punto de caducar y debe renovarse. Con este proceso de flujo de trabajo, evitará las situaciones en que los certificados caducan inesperadamente y le arruinan el día.

Resumen
Si su compañía usa un entorno de Microsoft PKI, ILM-CM puede ayudarle a administrarlo. ILM-CM permite a las organizaciones mejorar los procesos de autenticación de seguridad y reducir los costos y la complejidad de la administración de certificados digitales y tarjetas inteligentes. ILM-CM también le servirá como base para desarrollar procesos de flujo de trabajo de certificados y tarjetas inteligentes de los que tantas compañías carecen hoy en día.
Además, Microsoft ha implementado la compatibilidad con API externa para ILM-CM. Si su organización usa aplicaciones personalizadas, puede interconectar dichas aplicaciones para sacar partido de la compatibilidad de la API de ILM-CM.
Para obtener más información acerca de ILM-CM, consulte microsoft.com/technet/clm. También está disponible una guía de inicio rápido (go.microsoft.com/fwlink/?LinkId=87336).

Kevin Dallmann es consultor jefe de ingenieros de sistemas en Accenture y es, principalmente, responsable de la compatibilidad con Active Directory y entornos PKI para empresas grandes. Kevin tiene los certificados MCSE y MCT e imparte cursos de Microsoft.


 Nota del editor: Problemas de seguridad
Nota del editor
Problemas de seguridad
Joshua Trupin

¿Ha observado cómo las cuestiones relacionadas con la seguridad se han hecho más controlables en los últimos tiempos? Por supuesto, a nosotros nos gustaría llevarnos todo el mérito en TechNet Magazine, pero hay otros pocos factores que hay que tener en cuenta. Los dos más importantes son la toma de conciencia y la solidez.
En lo que se refiere a la conciencia, aquí estaríamos hablando simplemente de conocer las posibles amenazas y los trucos de la ingeniería social, además de estar al día de las revisiones y actualizaciones periódicas que protegen el software instalado. La solidez vendría a ser la otra cara de la moneda; la idea que el software puede crearse con la idea de ser más seguro y pueda minimizarse la superficie de ataque mediante la desactivación de forma predeterminada de las características más expuestas.
Ah, y otro más: leer TechNet Magazine regularmente. ¡No hay que olvidarse de eso! Tiene en sus manos nuestro ya casi famoso número sobre temas de seguridad, que contiene ni más ni menos que siete artículos que le ayudarán a convertirse en el analista de seguridad más temido de su empresa. Mark Russinovich empieza echando una ojeada a los UAC internos, mientras que Steve Riley se zambulle en Firewall de Windows y Jesper Johansson explora los cambios de las listas de control de acceso en Windows Vista. También tenemos a Jeremy Moskowitz, que nos habla sobre directivas de grupo y bloqueo de hardware, a Michael Murgolo, que participa en la elevación de secuencia de comandos PowerToys, y así a muchos otros. El número que ahora mismo tiene en sus manos podría ser tranquilamente la mejor revista jamás publicada.
Así que, mientras sigue en estado de alerta, le recomendamos que conozca más acerca de las últimas medidas de seguridad que le ofrece Microsoft. Microsoft Forefront representa esta "solidez" de la que hablamos, ya que se trata de una línea de productos de seguridad empresarial que facilita protección en tres áreas: los sistemas operativos cliente, los servidores de aplicaciones y el perímetro de la red. Incluye herramientas de seguridad para Exchange Server y Sharepoint, al mismo tiempo que incorpora ISA Server e Intelligent Application Gateway para el tráfico de red. Microsoft System Center personifica la parte de &quot;conciencia&quot; del rompecabezas, que le permite conocer mejor sus sistemas, agilizar sus operaciones y administración, generar informes y mejorar la entrega del servicio. Incluye la próxima generación de tecnologías para la administración de la configuración y la supervisión de operaciones, entre otras herramientas.
Para conocer más acerca de Forefront y System Center, visite el sitio de la infraestructura de Microsoft en la dirección Microsoft.com/infrastructure. Y para obtener las mejores soluciones para sus problemas de seguridad, manténgase informado y sólido con TechNet Magazine.
—Joshua Trupin

Mi agradecimiento a los siguientes expertos de Microsoft: Conrad Bayer, David Cross, Michael Dennis, Shon Eizenhoefer, Jason Garms, Russ Humphries, Jesper Johansson, John Lambert, Eric Perlin, Mark Russinovich, Jon Schwartz, David Solomon, Greg Stemp, John Stephens, Kevin Sullivan, Jim Truher y Buck Woody.


 Caja de herramientas: Nuevos productos para profesionales de TI
Caja de herramientas Nuevos productos para profesionales de TI and Greg Steen
myLittleAdmin es una interfaz flexible
La interfaz de usuario basada en la Web es compatible con la mayoría de las operaciones de base de datos, incluidas la creación de bases de datos nuevas, la administración de bases de datos existentes y su contenido y el trabajo con instantáneas y esquemas. La modificación de las propiedades de objetos de base de datos existentes es sencilla y myLittleAdmin tiene una cuadrícula de datos que se puede editar y que es adecuada para modificar filas individuales de las tablas. La interfaz de vista en árbol es muy similar a la vista en árbol de SQL Server Management Studio, de modo que la aplicación requiere poco entrenamiento. La única dificultad es que algunas opciones del botón secundario no abrirán el menú contextual esperado.
También puede usar myLittleAdmin para editar los inicios de sesión, las funciones de servidor y las credenciales de la instancia de SQL. Incluso le permite crear y editar dispositivos de copia de seguridad y servidores vinculados, tareas cuya ejecución remota sería de utilidad.
Con myLittleAdmin también puede realizar tareas tales como hacer consultas ad hoc, conectar y desconectar bases de datos, realizar copias de seguridad y restauraciones, importar datos CSV y comprimir bases de datos. Incluso puede examinar el registro de errores y el monitor de actividad para la solución de problemas.
Precio: A partir de 590 dólares para una sola licencia de servidor. Como parte del conjunto de herramientas de alojamiento web, está disponible a partir de 990 dólares para una única licencia de servidor.


 Preguntas y respuestas sobre SQL&amp;: Instalaciones de 64 bits, asignaci&#243;n de memoria de cl&#250;ster y mucho m&#225;s
Preguntas y respuestas sobre SQL& Instalaciones de 64 bits, asignación de memoria de clúster y mucho más and Editado por Nancy Michell
Figura 1Búsqueda de Windows Live en Libros en pantalla de SQL Server
Pero, digamos que SQL Server tiene toda la RAM en un servidor y se inicia una nueva instancia de SQL Server. ¿Qué sucede con la memoria de la instancia original de SQL Server? Parece que debo planear el escenario del peor caso; que sólo un nodo permanezca en servicio y que todas las instancias de SQL Server dejen de ejecutarse en ese nodo.
R Generalmente se acepta que es mejor establecer un valor de memoria máxima de servidor un poco menor que el total de memoria disponible en un equipo. Sin embargo, es dudoso que un tercio del valor total de memoria fuera la mejor configuración en su situación.
Está preocupado de que tres de los cuatro servidores en su clúster queden quizá fuera de servicio de forma simultánea y que las tres instancias de SQL Server terminen existiendo en el cuarto nodo. Sin embargo, esta situación es improbable.
En la mayoría de los casos, es mejor configurar cada instancia para que use la mayor parte de memoria disponible en cada nodo. Digamos que cada nodo tiene 32 GB de RAM. Establecer la memoria máxima del servidor en 28 GB para cada instancia sería razonable.
Ahora, en el evento de error en un nodo, la instancia que se ejecuta en ese nodo conmutaría al nodo pasivo y podría potencialmente obtener acceso a 28 GB de memoria. Las otras dos instancias no se verán afectadas; se mantienen en ejecución en los otros dos nodos en el clúster.
Indicó un clúster de conmutación por error de cuatro nodos con cinco instancias de SQL Server y una instancia de Analysis Services. Si ejecuta SQL Server 2000 con extensiones de ventanas de dirección (AWE), tendrá que establecer límites de memoria cuidadosamente seleccionados para sus instancias de motores relacionales para que no renuncien a la memoria que han adquirido. La historia es diferente con la situación más flexible de SQL Server 2005 e instancias de 64 bits que tienen acceso a un gran espacio de direcciones con o sin AWE; aún cuando en esta situación use AWE, es dinámica y puede liberar memoria cuando lo solicite. Así, la respuesta a la pregunta de lo que sucede con la instancia original de SQL Server y la memoria que ha adquirido en una situación de conmutación por error en la que comienza una nueva instancia en el equipo es que depende de si ejecuta SQL Server 2000 o SQL Server 2005 y de si usa AWE.
El planeamiento para el escenario del peor caso es una buena idea en principio, pero en términos prácticos, a menos que tenga realmente muy bien configurado el sistema, es improbable que sobreviva al bloqueo de tres de cuatro nodos en un clúster que ejecuta cinco instancias de motores relacionales de SQL Server y una instancia de Analysis Services. El nodo restante no tendrá suficientes recursos de CPU para atender a las instancias originales en un nivel de rendimiento comparable. Como este es el caso, será mejor realizar la ingeniería de la solución de manera tal que se mantenga el rendimiento óptimo con la pérdida de un nodo aunque pueda ser necesaria alguna intervención manual con la pérdida de más de uno. Esto probablemente proporcionará una buena combinación de compatibilidad con alta disponibilidad (HA) a la vez que le permite obtener un uso decente de recursos costosos.
Por último, con SQL Server 2005 el usuario final puede escalar el clúster a hasta ocho nodos. En SQL Server 2000 un clúster de cuatro nodos era el máximo posible.

Límites de reflejo
P Al investigar la creación de reflejo de la base de datos SQL Server 2005, encontré una limitación del reflejo de la base de datos que puede admitir un máximo de sólo 10 bases de datos por instancia de servidor. Mis requisitos son tener dos instancias independientes de SQL Server con almacenamiento independiente, conmutación por error automática entre ambas y redundancia de datos.
Mi plan fue usar réplica de transacción punto a punto (P2P) de SQL Server 2005 combinada con Microsoft® Cluster Server (MSCS), donde tendría una IP de clúster originada por uno de los dos nodos, de modo que todo el tráfico de inserción, actualización, eliminación y lectura fuera a un único nodo en el clúster. Trataría al nodo secundario como pasivo pero tendría transacciones replicadas al mismo. En el caso de que se produzca un error, MSCS conmutaría ese IP sobre el otro nodo y como está configurado para ser P2P y bidireccional, no habría proceso manual para comenzar a publicar las transacciones en el otro nodo (una vez activo). Usaría la configuración del conjunto de nodos mayoritario (MNS) en MSCS para mitigar la necesidad de un recurso de disco compartido para el quórum.
La opción de reflejos aún está sobre la mesa. Disminuimos el número de 1000 a 100 bases de datos por clúster de SQL Server. Sin embargo, ¿debo emplear en los sistemas ese tipo de carga de recursos?
R Para obtener mayor información u orientación acerca de los reflejos de SQL Server, consulte Libros en pantalla o SQL Server Tech Center en microsoft.com/technet/prodtechnol/sql y msdn2.microsoft.com/sql.
Su pregunta generó mucha discusión. Después de examinar lo comentado, aquí adjuntamos las mejores respuestas para su escenario:
La respuesta número uno es que no se exige un límite para el número de bases de datos que se pueden reflejar en una instancia dada. Supongo que se refiere al artículo que menciona que una recomendación es reflejar un máximo de 10 bases de datos por instancia, pero eso es sólo una aproximación y no se exige ningún límite en ningún lugar específico; todo depende de los recursos disponibles en un sistema dado.
La creación de reflejos podría ser una opción, pero 1.000 bases de datos definitivamente es demasiado, a menos que disponga de un servidor de gran capacidad. Si no desea usar almacenamiento compartido y prefiere usar las tecnologías integradas de SQL Server, puede intentar la creación de reflejos, el trasvase de registros o la replicación. Las ventajas y desventajas de cada uno varían.
La respuesta número dos es que si tiene muchas bases de datos sin usar almacenamiento compartido y quiere una solución de recuperación ante desastres ofrecida por Microsoft, debe investigar trasvase de registros y usar un conjunto de pequeños programas personalizados auxiliares para disminuir la sobrecarga administrativa. Un programa puede realizar copias de seguridad y restaurar cada base de datos en orden y evitar así que tenga que ejecutar múltiples agentes de trasvase de registros. Observe que en esta opción hay alguna posibilidad de pérdida de datos. No existe una solución integrada que no requiera almacenamiento compartido o un sistema de administración de bases de datos para asegurar que no exista pérdida de datos.
Por supuesto, está el problema de cómo detectará y conmutará por error MSCS. Normalmente, las configuraciones de MNS en un clúster no eliminan por completo la necesidad de almacenamiento compartido, sólo eliminan la necesidad de tener un LUN compartido dedicado para el quórum. La única manera en que el plan podría funcionar sería si el clúster se configurara para no administrar nada más que los IP y los nombres de red. SQL Server no puede funcionar en clúster sin almacenamiento compartido, ya que no podría incluir en el clúster el servicio SQL, lo cuál significa que el clúster no podría detectar y supervisar los servicios de SQL Server en una configuración típica.
Podría incluir en el clúster el servicio SQL Server agregándolo como un servicio genérico que se debe supervisar, pero entonces el problema surgiría en la conmutación por error: dado que el servicio estaría en el clúster, MSCS trataría de poner en línea el servicio en el nodo pasivo durante la conmutación por error, pero ya existiría allí algún servicio SQL en ejecución. Por supuesto, podría usarlo simplemente para incluir en el clúster las direcciones IP y los nombres de red, y después conmutarlos de forma manual si fuera necesario en el caso que se produzca un error. Podría hacer lo mismo mediante Equilibrio de carga de red (NLB), lo cuál se hace en cualquier parte. Observe la nota técnica en la dirección microsoft.com/technet/prodtechnol/sql/2000/deploy/hasog04.mspx para obtener más información.
Dado el número de bases de datos que intenta admitir, una solución de trasvase de registros quizá funcione mejor para su caso. Por supuesto, necesitaría automatizar el proceso mediante un paquete de servicios de transformación de datos/servicios de integración de SQL Server (DTS/SSIS). De otro modo, probablemente tomaría demasiado tiempo realizar copias de seguridad de forma manual, mover y aplicar los registros activos durante un error.

Mis agradecimientos a los siguientes profesionales de TI de Microsoft por la aportación de sus conocimientos técnicos: Boris Baryshnikov, Chad Boyd, Alan Doby, Patrick Gallucci; Cindy Gross, Chuck Ladd, Pat Martin, Vipul Shah, Nelson Taggart, Kartik Tamhane, Ken Tanner, Chuck Timon, George Walters, Kevin Warren y especialmente a Buck Woody.


 Noticias destacadas sobre utilidades: PowerToys de elevaci&#243;n de secuencias de comandos para Windows Vista
Noticias destacadas sobre utilidades PowerToys de elevación de secuencias de comandos para Windows Vista and Michael Murgolo
Descargar el código de este artículo: Utility2007_06.exe (159KB)
El Control de cuentas de usuario ofrece una mejora importante de seguridad, pero la capacidad de elevar los permisos es esencial para llevar a cabo determinadas tareas y funciones administrativas. Estos son algunos PowerToys de elevación que aportan una mayor flexibilidad y eficacia.
Entre la muchas características de Windows Vista introducidas con fines de seguridad, el Control de cuentas de usuario (UAC) es una de las más destacadas. Con esta característica, incluso los usuarios administradores ejecutan la mayoría de las aplicaciones con el privilegio estándar, aunque tienen el "potencial de elevación" para tareas administrativas y
funciones de la aplicación específicas. Después de usar Windows Vista™ durante muchos meses, la elevación de una tarea o aplicación se ha convertido en algo rutinario. Sin embargo, también encontré una serie de defectos al tratar de elevar algunos tipos de tareas en Windows Vista, lo que resultó frustrante.
De modo que, en la línea de los antiguos PowerToys de Windows®, creé unos cuantos PowerToys de elevación de secuencias de comandos para vencer estas limitaciones. Puede encontrar todos los PowerToys que voy a comentar en la descarga de código en la dirección technetmagazine .com/code07.aspx. También puede leer información acerca del funcionamiento de UAC en el artículo de noviembre de 2006 "Prescinda de cuentas de administrador con Control de cuentas de usuario" de Alex Heaton (consulte la barra lateral "Recursos adicionales").

PowerToy de comandos de elevación
El primer inconveniente era que no había ningún método para elevar una aplicación desde la línea de comandos ni desde el cuadro de diálogo Ejecutar. De modo que, después de preguntar en Microsoft, encontré una secuencia de comandos de ejemplo de John Stephens (un ingeniero de diseño de software de Microsoft) que contenía la información que necesitaba. Resulta que, si se especifica el verbo "runas" en la API ShellExecute o su equivalente COM, el método ShellExecute de Shell.Application, la aplicación iniciada solicitará la elevación (consulte la barra lateral para obtener más detalles). Esto me permitió crear el primer PowerToy de elevación; el PowerToy de comandos de elevación.
Esta herramienta (que consta de los archivos ElevateCommand.inf, elevate.cmd y elevate.vbs) agrega un comando de elevación al sistema. Esto permite iniciar las aplicaciones que requieren elevación desde la línea de comandos, una secuencia de comandos o el cuadro de diálogo Ejecutar. Por ejemplo, el comando siguiente abre Win.ini con el Bloc de Notas (tras solicitar la elevación):
elevate notepad c:\Windows\Win.ini
Cuando se usa el comando de elevación con Windows Script Host (WSH), Windows PowerShell™ u otras secuencias de comandos, debe especificarse el archivo ejecutable de host de secuencias de comandos (como, por ejemplo, wscript, cscript o powershell) como la aplicación. Para ejecutar un vbs, por ejemplo, debe usar lo siguiente:
elevate wscript “C:\windows\system32\
slmgr.vbs” –dli
Figura 2Símbolos del sistema con privilegio elevado

Instalación e implementación
Para instalar estos PowerToys, haga clic con el botón secundario en un archivo INF, seleccione Instalar y apruebe la elevación. Para desinstalarlos, use la sección Programas y características del Panel de control.
En caso de que investigue los archivos INF y se pregunte por qué tres PowerToys instalan elevate.cmd y elevate.vbs en ubicaciones diferentes, se lo explicaré. La mayoría de los PowerToys se implementan agregando una subclave runas a HKEY_CLASSES_ROOT\objecttype\Shell para el tipo de objeto en el Registro.
Sin embargo, para algunos PowerToys, quería que varios tipos de objeto tuviesen dos entradas de menú contextual para la elevación ("Símbolo del sistema aquí como administrador" y "Símbolo del sistema de PowerShell aquí como administrador" para los tipos de objeto Unidad de disco y Directorio; "Ejecutar como administrador" y "Ejecutar como administrador con símbolo del sistema" para todos los tipos de objeto WSH). Dado que sólo puede haber una clave runas para cada tipo de objeto, tuve que implementar la segunda acción llamando al comando elevate. Pero, como quería que todos los INF se pudiesen instalar y desinstalar por separado, tuve que poner las copias asociadas elevate.cmd y elevate.vbs en lugares diferentes. (No se pueden incrementar los contadores de uso de archivo de un archivo INF sin formato. Sí, los instaladores de MSI podrían ser mejores, pero quería que se pudiesen crear y modificar con un editor de texto). Uno de los efectos secundarios de esto es que sólo las entradas de menú contextual implementadas con la clave runas mostrarán un protector en el menú.

Resumen
Espero que estas herramientas le resulten útiles y que mejoren su experiencia con UAC. Quizá le inspiren para crear sus propios PowerToys. (Para los que usen otros lenguajes de secuencias de comandos como Perl o Python en Windows Vista, también es fácil crear un PowerToy "Elevar secuencia de comandos" para esos lenguajes). Al igual que todos los PowerToys, son herramientas no compatibles que debe "usar bajo su propia responsabilidad". ¡En todo caso, diviértase elevando!
Recurso adicional
  • Prescinda de cuentas de administrador con Control de cuentas de usuario
  • Introducción al Control de cuentas de usuario
  • Elevación mediante ShellExecute
  • Método ShellExecute
  • Verbos y asociaciones de archivos
  • Un viejo PowerToy vuelve a ser nuevo


 The Cable Guy: Protocolo de t&#250;nel de sockets seguros
The Cable Guy Protocolo de túnel de sockets seguros and Joseph Davies
Esta columna se basa en una versión preliminar de Windows Server con nombre en código "Longhorn". Por tanto, toda la información de este documento está sujeta a cambios.
Los protocolos VPN en Windows XP y Windows Server 2003 no funcionan en algunas configuraciones. Obtenga un análisis en profundidad de las distintas situaciones y vea cómo Windows Server con nombre en código "Longhorn" y Windows Vista con Service Pack 1 usarán el protocolo de túnel de sockets seguros para resolver estos problemas.
La compatibilidad con la función de red privada virtual (VPN) en Windows XP y Windows Server 2003 le permite conectarse a su intranet privada a través de Internet, como si su equipo estuviera conectado en un puerto Ethernet local. Sin embargo, los protocolos VPN en Windows XP y Windows Server 2003 no funcionan en algunas configuraciones de firewall
y en algunas configuraciones indirectas, como por ejemplo cuando su equipo se encuentra detrás de un traductor de direcciones de red (NAT) o de un servidor proxy web en que se ha bloqueado el tráfico para conexiones VPN. Para resolver estas dificultades, las futuras versiones de Windows Server® con nombre en código "Longhorn" y Windows Vista™ con Service Pack 1 (ambas en la fase de pruebas beta) incluyen compatibilidad con el nuevo protocolo de túnel de sockets seguros (SSTP).

Problemas de acceso VPN
En Windows® XP y Windows Server 2003, los protocolos VPN que permiten conexiones de acceso remoto a una intranet a través de Internet son el protocolo de túnel punto a punto (PPTP) y el protocolo de túnel de capa dos con el protocolo de seguridad de Internet (L2TP/IPsec). Proporcionan la encapsulación de los paquetes que se envían entre un cliente de acceso remoto y la intranet a la que se conecta.
El tráfico VPN basado en PPTP consiste en una conexión TCP al puerto TCP 1723 en el servidor de VPN para realizar el mantenimiento de túnel y en paquetes encapsulados con encapsulación de enrutamiento genérico (GRE) para los datos VPN. Pero el tráfico PPTP puede tener problemas con firewalls, NAT y servidores proxy web. Para evitar problemas, los firewalls se deben configurar para permitir tanto la conexión TCP como los datos encapsulados con GRE. Aunque GRE es un método estándar de encapsulación de paquetes IP, muchos proveedores de servicios de Internet (ISP) eliminan estos paquetes, lo que resulta en pérdida de datos. Además, las conexiones en hoteles y cafeterías se configuran típicamente para tráfico web y de correo electrónico normales y es posible que no admitan el tráfico PPTP. Más aún, si su equipo se encuentra detrás de un objeto NAT, éste debe tener la capacidad de traducir el tráfico GRE. Si no lo puede hacer, podrá establecer la conexión TCP pero no podrá enviar ni recibir ningún elemento de datos encapsulados con GRE. Por último, el tráfico PPTP no puede fluir a través de un servidor proxy web.
El otro protocolo de VPN que funciona en Windows XP y Windows Server 2003, L2TP/IPsec, usa intercambio de claves de Internet (IKE) para negociar la protección del tráfico VPN de la carga de seguridad encapsuladora (ESP) de IPsec, y también puede tener problemas con firewalls, NAT y servidores proxy web.
En esta configuración, se deben configurar los firewall para que permitan tanto el tráfico IKE como los datos encapsulados por GRE. Si su equipo cliente de VPN se encuentra detrás de un objeto NAT, tanto el cliente como el servidor de VPN deben ser compatibles con NAT transversal de IPsec (NAT-T). Observe, no obstante, que el servidor de VPN no se puede situar detrás de un objeto NAT, y que ese tráfico L2TP/IPsec no puede fluir a través de un servidor proxy web.

La nueva solución VPN
Como puede observar, existen varios problemas en torno al funcionamiento del protocolo VPN en Windows XP y Windows Server 2003. Las buenas noticias son que SSTP en Windows Vista con Service Pack 1 y Windows Server con nombre en código "Longhorn" resuelve estos problemas de conectividad de VPN al usar HTTP sobre capa de sockets seguros (SSL). SSL también se conoce como seguridad de la capa de transporte (TLS). HTTP sobre SSL en el puerto TCP 443 es el protocolo que se usa en la Web desde hace un tiempo para recopilar números de tarjeta de crédito y otros datos privados. Cada vez que se conecta a una dirección web que empieza con https:, usa HTTP sobre SSL.
El uso de HTTP sobre SSL resuelve muchos problemas de conectividad de protocolo VPN; los firewalls, NAT y servidores proxy web normalmente permiten este tipo de tráfico porque es generalizado.
SSTP usa una sesión de HTTP sobre SSL entre clientes y servidores de VPN para intercambiar paquetes de IPv4 o IPv6 encapsulados. Tenga en cuenta que una conexión VPN de acceso remoto basada en HTTP sobre SSL es diferente de la conexión que realiza una aplicación que usa HTTP sobre SSL. Por ejemplo, Outlook® Web Access (OWA) le permite tener acceso a su correo electrónico de Microsoft Exchange de su empresa a través de Internet. OWA usa una sesión cifrada de SSL sobre HTTP, pero no es lo mismo que una conexión de acceso remoto. Aunque puede ver su correo electrónico con OWA, no puede alcanzar la ubicación de una dirección URL de intranet incrustada dentro de un mensaje de correo electrónico de Exchange.
(SSTP no admite configuraciones web proxy autenticadas, en que el proxy requiera alguna forma de autenticación durante la solicitud de conexión HTTP).
Una implementación de HTTP sobre SSL en Windows puede disminuir sustancialmente el costo de mantenimiento de la solución de acceso remoto. Por ejemplo, HTTP sobre SSL tiene como resultado menores problemas para el departamento de soporte técnico y elimina problemas relacionados con servidores de VPN que se encuentran detrás de objetos NAT. Y, dado que SSTP funciona casi en todas partes, los usuarios están más felices y aumentan la productividad.
Dado que SSTP se integra con Windows, no tiene que preocuparse de instalar y administrar software de cliente VPN de terceros en los equipos cliente, ni de instalar software adicional en el servidor de VPN. Adicionalmente, SSTP puede ofrecer mejor equilibrio de carga de conexiones VPN a través de equilibradores disponibles de carga SSL.
Nuevas características de SSTP
  • SSTP integra compatibilidad con protección de acceso a redes (NAP), que se puede usar para una mejor protección de los activos de red al aplicar el cumplimiento con los requisitos de estado del sistema. Para obtener más información sobre NAP, consulte microsoft.com/nap.
  • Además, SSTP admite el envío de tráfico nativo de IPv6 dentro del túnel SSTP y conexiones SSTP basadas en IPv6 a través de Internet IPv6.
  • Asimismo, SSTP establece una única sesión HTTP sobre SSL del cliente al servidor SSTP. Otras soluciones VPN de terceros basadas en SSL usan dos sesiones de HTTP sobre SSL. El uso de una única sesión HTTP sobre SSL ofrece menor uso de red y mejor equilibrio de carga.
  • Por último, SSTP está completamente integrado con los componentes de cliente VPN de Windows Vista con Service Pack 1 y Windows Server &quot; Longhorn&quot; y Enrutamiento y acceso remoto en Windows Server &quot; Longhorn&quot; SSTP es un protocolo VPN adicional y puede usar todos los mismos protocolos de autenticación y métodos de configuración, tales como la carpeta Conexiones de red y Administrador de conexiones, que se usan en conexiones basadas en PPTP o en L2TP/IPsec.
A diferencia de los protocolos PPTP y L2TP/IPsec en Windows XP y Windows Server 2003, SSTP no es compatible con conexiones VPN de sitio a sitio.

SSTP en Windows
Un equipo que ejecuta Windows Server "Longhorn" y Enrutamiento y acceso remoto es un servidor de VPN basado en SSTP. No es necesario instalar IIS, ya que Enrutamiento y acceso remoto busca conexiones entrantes en el Identificador uniforme de recursos específico (URI) /sra_{BA195980-CD49-458b-9E23- C84EE0ADCD75}/. No obstante, Enrutamiento y acceso remoto e IIS pueden coexistir en el mismo servidor.
Un equipo que ejecuta Windows Vista (con las mejoras planeadas en el próximo Service Pack 1, actualmente programado para su lanzamiento a fin de año) o Windows Server "Longhorn" es un cliente VPN basado en SSTP, capaz de iniciar conexiones SSTP con un servidor VPN basado en SSTP. El servidor SSTP debe tener instalado un certificado de equipo con autenticación de servidor o la propiedad para todo propósito de uso mejorado de clave (EKU). El cliente SSTP usa este certificado de equipo para autenticar el servidor SSTP cuando se establece la sesión SSL. El cliente SSTP valida el certificado de equipo del servidor de SSTP. Para poder confiar en el certificado de equipo, la autoridad de certificado raíz (CA) de la CA emisora del certificado de equipo del servidor SSTP debe estar instalada en el cliente SSTP.
La figura 1 compara los atributos de los distintos protocolos VPN en Windows Server "Longhorn" y Windows Vista con Service Pack 1. La barra lateral "Nuevas características de SSTP" describe las características de SSTP.
Figure 1 Comparación de los distintos protocolos VPN (Close Figure 1)

Atributos | PPTP | L2TP/IPsec | SSTP
Encapsulación | GRE | L2TP sobre UDP | SSTP sobre TCP
Cifrado | Cifrado punto a punto de Microsoft (MPPE) con RC4 | IPsec ESP con Triple estándar de cifrado de datos (3DES) o Estándar de cifrado avanzado (AES) | SSL con RC4 o AES
Protocolo de mantenimiento del túnel | PPTP | L2TP | SSTP
Cuando se produce la autenticación de usuario | Antes de que comience el cifrado | Después de que se establezca la sesión IPsec | Después de que se establezca la sesión SSL
Certificados requeridos para establecer el túnel VPN | Ninguno | Certificados de equipo tanto en el cliente VPN como en el servidor VPN | Certificado de equipo en el servidor VPN y certificado raíz de la CA en el cliente VPN

Cómo funciona SSTP
Cuando un usuario en un equipo que ejecuta Windows Server "Longhorn" o Windows Vista con Service Pack 1 inicia una conexión VPN basada en SSTP, ocurre lo siguiente:
  1. El cliente SSTP establece una conexión TCP con el servidor SSTP entre un puerto TCP dinámicamente asignado en el cliente y el puerto TCP 443 en el servidor.
  2. El cliente SSTP envía un mensaje SSL Client-Hello, que indica que el cliente desea crear una sesión SSL con el servidor SSTP.
  3. El servidor SSTP envía su certificado de equipo al cliente SSTP.
  4. El cliente SSTP valida el certificado de equipo, determina el método de cifrado para la sesión SSL, genera una clave de sesión SSL y la cifra con la clave pública del certificado del servidor SSTP.
  5. El cliente SSTP envía el formulario cifrado de la clave de sesión SSL al servidor SSTP.
  6. El servidor SSTP descifra la clave de sesión SSL cifrada con la clave privada de su certificado de equipo. Toda futura comunicación entre el cliente SSTP y el servidor SSTP se cifra con el método de cifrado negociado y la clave de sesión SSL.
  7. El cliente SSTP envía un mensaje de solicitud HTTP sobre SSL al servidor SSTP.
  8. El cliente SSTP negocia un túnel SSTP con el servidor SSTP.
  9. El cliente SSTP negocia una conexión de PPP con el servidor SSTP. Esta negociación incluye la autenticación de credenciales de usuario con un método de autenticación PPP y la configuración de valores para tráfico IPv4 o IPv6.
  10. El cliente SSTP comienza el envío de tráfico IPv4 o IPv6 sobre el vínculo PPP.
La figura 2 muestra la estructura de paquetes IPv4 o IPv6 enviados sobre una conexión VPN basada en SSTP.
Figura 2Estructura de paquetes SSTP
Un paquete IPv4 o IPv6 se encapsula primero con un encabezado PPP y un encabezado SSTP. La sesión SSL cifra la combinación del paquete IPv4 o IPv6, el encabezado PPP y el encabezado SSTP. Se agrega un encabezado TCP y un encabezado IPv4 (para conexiones SSTP a través de Internet IPv4) o un encabezado IPv6 (para conexiones SSTP a través de Internet IPv6) para completar el paquete.
Para obtener más información acerca de SSTP, consulte el blog de Enrutamiento y acceso remoto en blogs.technet.com/rrasblog.


 Windows PowerShell: Trabajo con Active Directory
Windows PowerShell Trabajo con Active Directory and Don Jones Windows PowerShell no ofrece un cmdlet Get-ADSIObject, pero eso no impide que sea totalmente compatible con ADSI. Obtenga una introducción sobre los adaptadores de tipo y aprenda a usar Windows PowerShell para que funcione con objetos de directorio.
Si ha invertido tiempo trabajando con Windows PowerShell, probablemente habrá probado el cmdlet Get-WMIObject, también conocido por su alias gwmi. Como expliqué en la columna del mes pasado, este cmdlet resalta la gran mejora que supone Windows PowerShell respecto a los lenguajes de secuencia de comandos y los shells de línea de comandos anteriores
(consulte technetmagazine.com/issues/2007/05/PowerShell). Gwmi permite un acceso rápido y fácil al Instrumental de administración de Windows® (WMI), de modo que puede hacer una cantidad increíble de cosas sin tener que escribir secuencias de comandos complejas.
Get-WMIObject es un buen ejemplo de lo que puede hacer Windows PowerShell™. Siempre que lo muestro en una clase, los estudiantes extrapolan, invariablemente, su funcionalidad a otras áreas de la administración de Windows. Una de las primeras preguntas que me suelen hacer es "¿Hay un cmdlet Get-ADSIObject?"

Compatibilidad con ADSI en Windows PowerShell
ADSI significa Interfaz de servicio de Active Directory®. A pesar de su nombre, ADSI no es específico de Active Directory. Una manera más exacta de leer el nombre sería "Interfaz activa de servicios de directorio", porque ADSI se puede conectar a varios servicios de directorio, incluidos los directorios de estilo de Windows NT®, no sólo a los dominios de Windows NT, pero también al Administrador de cuentas de seguridad (SAM) local en equipos independientes y miembro. Con esta flexibilidad, un cmdlet Get-ADSIObject sería increíblemente útil. Lamentablemente, el equipo de Windows PowerShell no pudo incluir este cmdlet en su primera versión.
Aunque esto no quiere decir que Windows PowerShell no sea compatible con ADSI. De hecho, la compatibilidad de ADSI en Windows PowerShell es tan buena que posiblemente no echará en falta un cmdlet Get-ADSIObject.
Todo empieza con el adaptador de tipo [ADSI]. Los adaptadores de tipo requieren cierta explicación. Recuerde que Windows PowerShell se basa en Microsoft® .NET Framework (2.0 o superior, para ser específico). Como resultado, casi todos los componentes de Windows PowerShell (desde los objetos WMI hasta los archivos y carpetas) se representan como un objeto de Framework. Sin embargo, al equipo de Windows PowerShell no le bastaba con proporcionar objetos de Framework sin formato a los administradores de Windows. Por ejemplo, muchos de los objetos de Framework funcionan de forma un tanto incoherente y la coherencia era uno de los principales objetivos de diseño para Windows PowerShell. Otra razón es que algunos objetos de Framework son excesivos para la administración de Windows, y la sencillez también era un objetivo de diseño principal para Windows PowerShell. Los adaptadores de tipo nacieron como resultado de esta necesidad.
Como el propio nombre indica, un adaptador de tipo "adapta" un tipo de objeto de .NET Framework a un formato más coherente y, a veces, más sencillo. Por ejemplo, suponga que crea una variable de cadena nueva como esta:
[string]$var = “Hello”
Usó una instancia de tipo System.String controlada por el adaptador .NET. El adaptador de tipo [ADSI] se conecta a las clases DirectoryServices de .NET Framework, incluido el tipo DirectoryEntry.

Recuperación de objetos del directorio
La conexión con objetos de directorio es bastante sencilla. Por ejemplo, para conectarse a un usuario llamado Don en la unidad organizativa de TI del dominio Contoso.com, usaría algo como esto:
$user = [ADSI]”LDAP://cn=Don,ou=IT,dc=
Contoso,dc=com”
Si ha trabajado con ADSI en VBScript u otro lenguaje, debería resultarle bastante familiar. Se trata de una cadena de consulta LDAP (Protocolo ligero de acceso a directorios) estándar, que es el medio nativo de acceso a Active Directory. No es necesario especificar un nombre de controlador de dominio (DC) ni otros detalles; este nombre de dominio completo (FQDN) contiene la información suficiente para localizar un DC y recuperar el objeto (suponiendo que tenga permiso para hacerlo, por supuesto).
El trabajo con cuentas de seguridad locales requiere un proceso casi idéntico, salvo que se usa el proveedor WinNT en vez del proveedor LDAP:
$user = [ADSI]”WinNT://don-pc/don”
Tenga en cuenta que los monikers LDAP y WinNT distinguen mayúsculas de minúsculas. Estos recursos de ADSI, a diferencia de Windows PowerShell, distinguen mayúsculas de minúsculas, por lo que debe prestar atención cuando los escriba.
En la figura 1 se muestra lo que sucede si se toma la variable $user resultante y se canaliza a Get-Member: Se obtiene una lista de propiedades del objeto. Lamentablemente, no es una lista completa de todas las propiedades del usuario y no incluye ninguno de los métodos del objeto de usuario. La clase System.DirectoryServices.DirectoryEntry de Framework subyacente funciona de una manera extraña en este aspecto y Windows PowerShell sólo puede mostrarme lo que proporciona la clase de Framework.
Figura 1Recuperación de una lista de propiedades de objeto
La tarea de recuperación de objetos consiste, principalmente, en saber cómo generar una cadena de consulta. El uso del proveedor WinNT es bastante sencillo. Especifique simplemente un nombre de dominio o equipo, una barra diagonal y, a continuación, un nombre de objeto. Esta técnica funciona bien con dominios de Active Directory que, a fin de cuentas, son compatibles con versiones anteriores de dominios de Windows NT. Y, de hecho, usar el proveedor WinNT para recuperar objetos de Active Directory puede ser, a veces, la manera más fácil, ya que el proveedor WinNT le proporciona una vista plana del dominio. Eso significa que no necesita saber en qué unidad organizativa se encuentra un objeto, ya que el proveedor WinNT no consulta las unidades organizativas.
La recuperación de objetos LDAP requieren algo más de precisión. Debe empezar con la información más específica posible, como por ejemplo, el nombre canónico (cn) del objeto o el nombre de una unidad organizativa. A continuación, proporciona la ruta de acceso completa al objeto, desde el contenedor principal hasta el dominio. Por ejemplo, el usuario Don, que se encuentra en la unidad organizativa Sales, que a su vez, se encuentra en la unidad organizativa West del dominio Contoso.com, tendría el aspecto siguiente:
LDAP://cn=Don,ou=Sales,ou=West,dc=Contoso,
dc=com
Este formato requiere cierta práctica y saber dónde se encuentra el objeto. En la figura 2 se proporciona un resumen de los diferentes componentes de un FQDN.
Figure 2 Componentes de FQDN (Close Figure 2)

Componente | Propósito | Ejemplo
cn | Nombre canónico de un objeto. También se usa para contenedores de no unidad organizativa, tales como usuarios y equipos. | cn=Don
ou | Unidad organizativa. | ou=Sales
dc | Componente de nombre de dominio. Cada componente de un nombre de dominio DNS obtiene su propio componente "dc=". | dc=domain, dc=com

Una pequeña ayuda de un amigo
La creación y eliminación de objetos suele requerir una conexión previa con el contenedor del objeto, como una unidad organizativa, y luego una solicitud al contenedor para que cree o elimine el objeto. Siempre olvido la sintaxis correcta pero, afortunadamente, los encargados de las secuencias de comandos de Microsoft pueden echarnos una mano en forma de Scriptomatic para ADSI.
Aunque originalmente se creó para VBScript, Scriptomatic para ADSI es una guía útil para Windows PowerShell, ya que la sintaxis de ADSI es igual. Por ejemplo, tras descargar la herramienta, selecciono la opción para crear un usuario nuevo. Omito todo el código de secuencia de comandos que genera la herramienta hasta después del código "End connect to a container", que tiene el aspecto siguiente:
Set objUser =
 objContainer.Create(“user”, “cn=” & strName)
objUser.Put “sAMAccountName”, strName
objUser.SetInfo
La conversión a Windows PowerShell es sencilla. En primer lugar, me conecto al contenedor donde deseo crear el usuario. Para ser coherente con el código de Scriptomatic, usaré la variable $objContainer para representar a la unidad organizativa. Crearé también una variable, $strName, para guardar el nombre del usuario nuevo:
$strName = “Don”
$objContainer = “LDAP//ou=Test,dc=Contoso,
dc=com”
A continuación, copio encima el código de Scriptomatic, quito todos los rastros de instrucciones Set de VBScript y agrego $ a los nombres de variable:
$objUser = $objContainer.Create(“user”,
  “cn=” & $strName)
$objUser.Put “sAMAccountName”, $strName
$objUser.SetInfo()
Y esto es todo lo que hay que hacer. Se ha creado un usuario nuevo en la unidad organizativa Test del dominio Contoso.com.

Modificación de objetos de directorio
Una vez que se haya conectado a un objeto, como por ejemplo, un usuario o grupo, lo puede modificar. El proveedor WinNT le permite modificar directamente muchas propiedades, tales como las que se muestran en la figura 1. Por ejemplo, para visualizar y cambiar la propiedad Description de un usuario, debería realizar lo siguiente:
Write-Host $user.Description
$user.Description = “New Description”
$user.SetInfo()
Lo importante es recordar que los cambios en la propiedad se hacen en la memoria caché de propiedades local, que es un área de almacenamiento temporal que crea ADSI en el equipo. Al llamar al método SetInfo, la memoria caché se vuelve a escribir en el dominio o el equipo del que recuperó el objeto, de manera que los cambios se vuelven a guardar en el directorio.
Los objetos de Active Directory no proporcionan propiedades directas para la mayoría de los atributos de objeto. En vez de eso, se usan los métodos Get y Put:
Write-Host $user.Get(“Description”)
$user.Put(“Description”,”New Description”)
$user.SetInfo()
Los objetos de WinNT suelen ser bastante simples, ya que los servicios de directorio de Windows NT no almacenaban mucha información acerca de objetos tales como usuarios y grupos. Active Directory, por otro lado, almacena mucha información, por lo que resolver los nombres de atributo correctos puede ser difícil. Por ejemplo, si desea cambiar el apellido de un usuario, deberá cambiar la propiedad Sn. ¿Por qué Sn? Significa apellido.
Afortunadamente, Microsoft proporciona una buena referencia cruzada, que está disponible en línea en la dirección msdn2.microsoft.com/ms677286.aspx. Esta referencia muestra los nombres de atributo para las áreas principales de la consola de usuarios y equipos de Active Directory&, de modo que si sabe lo que desea cambiar en la consola, puede resolver el nombre de atributo subyacente. Tenga en cuenta que tiene a su disposición una referencia cruzada de consola a atributo más completa en el libro ADSI Scripting: TFM de Cade Fassett (SAPIEN press, 2007).

Lo que no puede hacer
Lamentablemente, la compatibilidad de ADSI en Windows PowerShell no es tan completa como para otras tecnologías, tal como WMI. Por ejemplo, es algo difícil enumerar los miembros de los grupos de un equipo local. En Active Directory también nos encontramos algunas dificultades. Mi experiencia es que la recuperación, creación y eliminación básicas de objetos funcionan bien. La modificación de propiedades de objeto también funciona bastante bien, aunque algunas propiedades son inaccesibles. La mayoría de las dificultades surgen al trabajar con objetos y grupos locales a través del proveedor WinNT.
Eso no quiere decir que no se puedan hacer cosas, sólo que algunas cosas son más difíciles o menos intuitivas. Veamos el ejemplo siguiente:
$group = [ADSI]”LDAP://cn=Techs,cn=users,
  dc=contoso,dc=com”
$group.Member.Add(“cn=user1,cn=users,
  dc=contoso , dc=com”)
$group.psbase.CommitChanges()
Esto agrega el usuario denominado User1 al grupo Techs. El inicio es bastante sencillo. Recupera el grupo mediante el FQDN. A continuación, usa la colección de miembros del grupo (más concretamente, el método Add de la colección) para agregar el FQDN del usuario deseado. Pero el último paso no es nada intuitivo. Llama al método CommitChanges de la clase oculta PSBase para guardar los cambios.
PSBase es una clase especial que representa directamente al objeto base de .NET Framework. En este caso, CommitChanges no se muestra directamente en Windows PowerShell (en realidad, el adaptador de ADSI no muestra ningún método), de modo que tiene que ir a la clase subyacente. Esto no es imposible, pero desde luego tampoco es intuitivo. También explica que las capacidades de los servicios de directorio todavía no se han adaptado totalmente a Windows PowerShell.
Esto se debe a varias razones. En primer lugar, el equipo de Windows PowerShell agregó la compatibilidad actual de ADSI al shell un poco tarde en el ciclo de desarrollo. Como suele decir Jeffrey Snover, el arquitecto del shell, "lanzar al mercado es elegir". El equipo tenía una cantidad de tiempo fija para desarrollar y lanzar al mercado el shell, así que tuvieron que decidir qué dejar para la siguiente versión. De lo contrario, se podrían haber pasado años agregando características y nunca lanzarían al mercado un producto compatible.
Otra de las razones es el .NET Framework subyacente. Su clase DirectoryServices es bastante compleja y adaptar esa complejidad a Windows PowerShell requeriría mucho tiempo y un planeamiento estudiado. Las clases de Framework también están, en mi opinión, un poco orientadas a Active Directory y no ofrecen una compatibilidad perfecta con el proveedor WinNT. Por supuesto, Windows PowerShell heredaría estas limitaciones de Framework.
Espero que Windows PowerShell amplíe la compatibilidad de los servicios de directorio, una compatibilidad que igual no se ofrecerá a través de ADSI, sino a través de las mejoras base de .NET Framework. Mientras tanto, la compatibilidad de ADSI disponible en Windows PowerShell le permite realizar la inmensa mayoría de las tareas administrativas, tales como crear usuarios, modificar las propiedades comunes de los usuarios, etc.
No olvide que muchas de las tareas de servicios de directorio pueden llevarse a cabo a través de WMI. Eche un vistazo a las secuencias de comandos disponibles en microsoft.com/technet/scriptcenter/scripts para ver algunos ejemplos excelentes en los que se usa WMI para proporcionar información más detallada sobre un grupo local de la que proporciona ADSI.


 &#161;Hola, encargados de las secuencias de comandos!: Trabajo con secuencias de comandos sobre la serpenteante l&#237;nea roja
¡Hola, encargados de las secuencias de comandos! Trabajo con secuencias de comandos sobre la serpenteante línea roja and Los encargados de las secuencias de comandos de Microsoft
Descargar el código de este artículo: HeyScriptingGuy2007_06.exe (151KB)
¿Busca una manera fácil de agregar términos al diccionario de Microsoft Word que no sea manual, palabra por palabra? ¿Quién no? Este mes, los encargados de las secuencias de comandos le muestran cómo crear diccionarios personalizados en Microsoft Word y cómo configurar Word mediante programación para que use esos diccionarios.
Figura 1Documento en Word con errores de ortografía
¿Ha notado algo raro? Efectivamente: Word ha subrayado con líneas onduladas términos de secuencias de comandos como Msgbox. ¿Por qué? Porque Word no los reconoce. ¿No reconoce esos términos? Vamos, Word; a fin de cuentas, durante los últimos años las personas encargadas de redactar las secuencias de comandos han escrito el término Msgbox muchísimas veces. Y han pasado el corrector ortográfico y han indicado que Msgbox era correcto muchas más veces. ¿Y aún así todavía marcas Msgbox, StrReverse y LTrim como palabras incorrectas? ¿Qué ocurre?
Antes de que se apresure a la defensa de Word, sí, sabemos que podemos agregar manualmente estos términos al diccionario de Microsoft Word. Pero, oye, somos los encargados de las secuencias de comandos; ¿qué sabemos nosotros del trabajo manual? Además, la tarea de agregar manualmente funciones VBScript, nombres de clase del Instrumental de administración de Windows® (WMI) y atributos de objeto de las interfaces de seguridad de Active Directory® (ADSI) puede ser un poco tediosa, por no decir otra cosa. ¿Y si queremos hacer esto en todos nuestros equipos? ¿O si queremos compartir estas correcciones con nuestros fieles lectores? Y si... bueno, ya se hace una idea.
La cuestión es: tiene que existir una manera más fácil de agregar los términos relacionados con secuencias de comandos (o cualquier otro término) al diccionario sin tener que hacerlo manualmente, palabra por palabra.
Pero resulta que no hay ninguna manera. ¡Nos vemos el mes que viene!
No, en serio, sólo estábamos bromeando. Por supuesto que hay una manera más fácil de agregar términos al diccionario. Y le enseñaremos a hacerlo en un momentito. Aunque primero hablaremos un poco acerca de los diccionarios.
Hablando de diccionarios, veamos un hecho interesante. ¿Por qué los norteamericanos deletrean "color" sin una U ("color", en vez de "colour")? ¿Por qué los norteamericanos escriben "center" en vez de "centre"? Sabemos la respuesta: Porque a Noah Webster, quien creó el primer diccionario norteamericano, no le gustaban las reglas de ortografía inglesas y decidió cambiar arbitrariamente la ortografía de muchas palabras.
Bueno, vale; no es muy apasionante. Pero bueno, ¡es algo difícil encontrar un dato interesante sobre los diccionarios!
Además del diccionario estándar integrado en la aplicación, Microsoft Word le permite crear los diccionarios personalizados que desee. De forma predeterminada, Word incluye un diccionario personalizado denominado Personal.dic, que suele encontrarse en la carpeta Application Data\Microsoft\Proof dentro de la carpeta de perfil de usuario (\Documents and settings\nombre de usuario predeterminado en Windows XP). Si hace clic con el botón secundario en una palabra mal escrita y selecciona Agregar al diccionario, la palabra se agregará a Personal.dic.
Resulta que Personal.dic no es más que un archivo de texto sin formato. Ábralo en el Bloc de Notas y verá una lista de palabras similar a esta:
Aaberg
Aalling
Abbas
Abercrombie
Abola
Abolrous
Abrus
Y así es cómo podemos agregar, mediante programación, términos relacionados con secuencias de comandos al diccionario de Microsoft Word. Sólo tenemos que crear un archivo de texto que contenga esos términos y configurar Word para que use ese archivo como un diccionario personalizado. ¿Será muy difícil? Teniendo en cuenta que los de las secuencias de comandos están dispuestos a hacerlo ellos mismos, no será muy complicado.
Pero espere, antes tenemos que hacer otra visita rápida. En el modelo de objetos de Microsoft Word, la información acerca de diccionarios personalizados se almacena en la colección CustomDictionaries. En cambio, se puede obtener acceso a esta colección haciendo referencia al objeto Word.Application y la propiedad CustomDictionaries. Por ejemplo, en la figura 2 se muestra una secuencia de comandos que devuelve información acerca de todos los diccionarios personalizados asociados con su copia de Microsoft Word.
Figure 2 Secuencia de comandos que recupera información de diccionarios personalizados (Close Figure 2)
Set objWord = CreateObject(“Word.Application”)

Set colDictionaries = objWord.CustomDictionaries

For Each objDictionary in colDictionaries
  Wscript.Echo “Name: “ & objDictionary.Name
  Wscript.Echo “Language ID: “ & objDictionary.LanguageID
  Wscript.Echo “Language-specific: “ & objDictionary.LanguageSpecific
  Wscript.Echo “Location: “ & objDictionary.Path
  Wscript.Echo “Read-only: “ & objDictionary.ReadOnly
  intType = objDictionary.Type
  Select Case intType
    Case 0 Wscript.Echo “Type: Spelling”
    Case 1 Wscript.Echo “Type: Grammar”
    Case 2 Wscript.Echo “Type: Thesaurus”
    Case 3 Wscript.Echo “Type: Hyphenation”
    Case 4 Wscript.Echo “Type: Spelling (complete)”
    Case 5 Wscript.Echo “Type: Spelling (custom)”
    Case 6 Wscript.Echo “Type: Spelling (legal)”
    Case 7 Wscript.Echo “Type: Spelling (medical)”
    Case 8 Wscript.Echo “Type: Hangual-Hanja Conversion”
    Case 9 Wscript.Echo “Type: Hangual-Hanja Conversion (custom)”
  End Select
  Wscript.Echo
Next

objWord.Quit
Ejecute la secuencia de comandos de la figura 2 y obtendrá información similar a esta:
Name: CUSTOM.DIC
Language ID: 0
Language-specific: False
Location: C:\Documents and Settings\kenmyer\Application Data\Microsoft\Proof
Read-only: False
Type: Spelling (custom)
Bastante sofisticado, ¿no le parece?
Por supuesto, no es lo mismo obtener información acerca de los diccionarios existentes que crear un diccionario personalizado nuevo; es como la diferencia entre leer un artículo sobre alguien que tiene un millón de dólares y tener un millón de dólares. Por lo tanto, veamos cómo se puede crear un diccionario personalizado nuevo en Word.
Empezaremos por agregar todas las funciones VBScript a un diccionario nuevo llamado Scripting.dic. Empezamos por aquí porque es necesario realizar unas cuantas operaciones. Después de todo, le enseñaremos a agregar clases WMI, atributos ADSI y cmdlets de Windows PowerShell™ a su diccionario sin apenas tener que hacer nada. (No es necesario decir que, cuando se trata de no hacer casi nada, los encargados de las secuencias de comandos saben de lo que hablan).
Para empezar, crear un diccionario personalizado en Microsoft Word es tan fácil como esto:
Set objWord = CreateObject _
  (“Word.Application”)

Set colDictionaries = _
  objWord.CustomDictionaries
colDictionaries.Add “Scripting.dic”

objWord.Quit
Como puede ver, primero creamos una instancia del objeto Word.Application. Posiblemente se haya dado cuenta de que nunca establecemos la propiedad Visible en verdadero y, así, Word nunca está visible en pantalla. ¿Por qué? Bien, simplemente porque esta secuencia de comandos sólo tarda un segundo aproximadamente en ejecutarse, por lo que no nos pareció oportuno que Word apareciese brevemente en pantalla y desapareciese inmediatamente. Pero, si le gustan las instancias intermitentes de Word (sólo para saber que la secuencia de comandos está haciendo algo realmente), agréguela como la segunda línea de código en la secuencia de comandos:
objWord.Visible = True
Tras crear el objeto Word.Application, usamos esta línea de código para crear una referencia de objeto a la colección CustomDictionaries:
Set colDictionaries = _
  objWord.CustomDictionaries
A continuación, llamamos al método Add para agregar el diccionario personalizado. Tenga en cuenta que puede que este archivo no exista; si Word no encuentra un archivo denominado Scripting.dic, creará un archivo nuevo vacío con ese nombre. Este es el código para agregar el diccionario personalizado:
colDictionaries.Add “Scripting.dic”
También se habrá dado cuenta de que no especificamos una ruta al agregar el diccionario nuevo. En cambio, simplemente proporcionamos el nombre de archivo (Scripting.dic) al método Add. Está bien. En ese caso, Scripting.dic se creará en la carpeta predeterminada para diccionarios y otras herramientas de corrección (por ejemplo, C:\Documents and Settings\kenmyer\Application Data\Microsoft\Proof).
¿Y si queremos que el diccionario se colocase en una ubicación diferente? No hay problema. Este comando crea Scripting.dic en la carpeta C:\Scripts:
colDictionaries.Add _
  “C:\Scripts\Scripting.dic”
¿Y si, más adelante, decidimos que queremos deshacernos de ese diccionario personalizado? Una vez más, no hay problema. En ese caso, sólo tenemos que enlazar el diccionario en cuestión y usar el método Delete para eliminarlo:
Set objWord = CreateObject _
  (“Word.Application”)
Set objDictionary = _
  objWord.CustomDictionaries _
  (“C:\Scripts\Scripting.dic”)
objDictionary.Delete

objWord.Quit
Figura 3Documento en Word tras agregar un diccionario personalizado
Esto es bastante práctico, especialmente si tiene en cuenta que puede compartir Scripting.dic y la secuencia de comandos de creación de diccionarios personalizados con quien quiera. Hágalo y, en menos de lo que cree, todas las versiones de Word reconocerán Msgbox como una palabra correcta. La verdad es que, si los encargados de las secuencias de comandos fuésemos perezosos, podríamos terminar el artículo de este mes aquí mismo y ya se iría con algo útil. Pero, como se suele decir, todavía no ha visto nada.
Nota: En realidad, somos perezosos. Pero, al ver que teníamos que llenar el espacio de esta columna, decidimos añadir un par de secuencias de comandos adicionales.
Como seguramente sabe, tanto VBScript como Windows Script Host son un poco tímidos, no les gusta hablar de sí mismos. Eso no es el caso de WMI, ADSI ni Windows PowerShell. Sólo tiene que preguntar y esas tecnologías le dirán todo acerca de sus clases, propiedades y métodos; prácticamente todo lo que desee saber.
Veamos, por ejemplo, ADSI. En la figura 4 se muestra una secuencia de comandos que se enlaza con el esquema de Active Directory y recupera todos los atributos del objeto de cuenta de usuario. A su vez, escribe esos atributos en el archivo C:\Scripts\Scripting.dic.
Figure 4 Adición de nombres de atributo de ADSI a un diccionario personalizado (Close Figure 4)
Const ForWriting = 2

Set objFSO = CreateObject(“Scripting.FileSystemObject”)
Set objFile = objFSO.OpenTextFile(“C:\Scripts\Scripting.dic”, ForWriting)

Set objSchemaUser = GetObject(“LDAP://schema/user”)

For Each strAttribute in objSchemaUser.MandatoryProperties
  objFile.WriteLine strAttribute
Next

For Each strAttribute in objSchemaUser.OptionalProperties
  objFile.WriteLine strAttribute
Next

objFile.Close
¿Ve lo genial que es eso? Con tan solo unas líneas de código hemos creado un diccionario que contiene todos los atributos del objeto de usuario de Active Directory. Comparta este código con los creadores de secuencias de comandos y nadie tendrá que preocuparse jamás de que los nombres de atributo como streetAddress o givenName se marquen como incorrectos en Word. Y, por supuesto, esta es lista puede ser infinita. ¿Quiere agregar las propiedades para la clase de equipo? Pues, coloque esta línea de código:
Set objSchemaComputer = _
  GetObject(“LDAP://schema/computer”)
¿Y las clases WMI? En la figura 5 se muestra una secuencia de comandos que recupera una lista de todas las clases WMI del espacio de nombres root\cimV2 y escribe esa información en C:\Scripts\Scripting.dic.
Figure 5 Adición de nombres de clase WMI a un diccionario personalizado (Close Figure 5)
Const ForWriting = 2

Set objFSO = CreateObject(“Scripting.FileSystemObject”)
Set objFile = objFSO.OpenTextFile(“C:\Scripts\Scripting.dic”, ForWriting)

strComputer = “.”

Set objWMIService=GetObject(“winmgmts:\\” & strComputer & “\root\cimv2”)

For Each objClass in objWMIService.SubclassesOf()
  objFile.WriteLine objClass.Path_.Class
Next

objFile.Close
¿Nos olvidamos de los usuarios de Windows PowerShell? Los encargados de las secuencias de comandos nunca harían eso. Bueno, en realidad, sí nos olvidamos. Pero nos acordamos de proponer esta secuencia de comandos de una sola línea, que devuelve todos los nombres de cmdlet y los escribe en C:\Scripts\Scripting.dic:
Get-Command | Foreach-Object `
{Add-Content c:\scripts\scripting.dic -value `
$_.Name}
Lo bueno del artículo de este mes es que todos hemos aprendido algo. Usted aprendió a crear diccionarios personalizados en Microsoft Word y a configurar Word mediante programación para que use esos diccionarios personalizados. Y los encargados de las secuencias de comandos aprendieron que si quieren algo, bueno, siempre es mejor tener a otra persona que lo haga. Pero si todo lo demás falla, siempre puede hacerlo uno mismo.


 Archivos del escritorio: C&#243;mo evitar la p&#233;rdida de datos
Archivos del escritorio Cómo evitar la pérdida de datos and Wes Miller Es sorprendente la frecuencia con que se pierden datos importantes. Pero la realidad es que esa información se pierde porque las personas no la protegen. Explore los pasos importantes que puede y debe realizar para proteger los datos de su organización.
La información anhela ser libre. No importa a quién se la confíe ni al esfuerzo realizado para fijar esos ceros y unos, siempre encontrarán un agujero para salir. Todos los días hay noticias sobre pérdidas de datos, tanto pequeñas como importantes. Es ridículo que se pierdan datos importantes
Figura 2Contraseña poco segura, aunque adore a su madre
La integridad de la contraseña y la autenticación local son esenciales pero, por supuesto, los datos del sistema local no deberían ser datos altamente confidenciales a menos que se hayan protegido físicamente o cifrado. Las contraseñas solas no son la solución. Una contraseña de usuario no es más que una herramienta para evitar que los atacantes que quieran poner en peligro el acceso interactivo directo al sistema pero que no estén dispuestos a emplear herramientas puedan hacerlo.

Seguridad física
Los datos críticos no deberían residir en un sistema que puede estar en peligro físicamente o que se puede sacar de la oficina. Si tiene sistemas que cree que pueden estar en peligro cuando alguien inicia Windows PE y recupera datos, tiene otros problemas; Windows PE no es el culpable. El motivo puede ser uno o más de los siguientes. Sus sistemas no están protegidos físicamente de manera adecuada. Están protegidos, pero usted no confía en los usuarios que tienen acceso a ellos, los datos están en un sistema que no está protegido físicamente (o que no se puede proteger) o los sistemas no se pueden proteger físicamente y no ha usado herramientas de cifrado de volumen, como la característica BitLocker™ de Windows Vista, para mitigar el peligro físico. (Para obtener más información acerca de BitLocker, consulte el artículo de Byron Hynes en este número de TechNet Magazine.)
Reflexione sobre los sistemas que pueden estar en peligro. ¿Puede protegerlos físicamente? ¿Por qué no los coloca en un centro de datos o en otra área con acceso limitado? Si eso no es posible o si se trata de un sistema portátil, ¿emplea software de cifrado de volumen? Si no puede aplicar estos pasos, mueva los datos a un sistema que se pueda proteger o cífrelos. En el caso del equipo portátil robado que mencioné anteriormente, si el volumen se hubiese cifrado con una herramienta de cifrado de volumen seguro, los datos habrían estado casi totalmente protegidos.
El hecho de que un sistema resida en un centro de datos no significa que esté seguro; si tiene muchas conexiones T1 hacia Internet, todavía estará en peligro. El acceso a Internet facilita a los atacantes el acceso físico, por lo que debe considerar escrupulosamente las amenazas a sus sistemas. Considere la posibilidad de mover los datos a un segmento separado de su red donde tenga, como mínimo, otro nivel de protección de redes entre Internet y los sistemas analizados.

Mitigación del riesgo de datos
Otra medida de seguridad disponible consiste en otorgar a los usuarios acceso a través de aplicaciones o herramientas de cliente ligero que aíslen los datos en un servidor físicamente seguro. Esto puede significar el acceso a través de un VPN para que los usuarios que no se encuentren en las instalaciones puedan obtener acceso. Nunca debe permitir que las restricciones físicas de un usuario determinen cómo deben tratarse los datos. Simplemente porque un usuario necesite acceso y se encuentre en una ubicación donde no está disponible una conexión de banda ancha u otro acceso de alta velocidad, no significa que deba mover los datos a una instancia local del equipo del usuario. Si no puede mover el sistema y debe tenerlo en una ubicación no segura, proteja los datos con el cifrado de volumen.

Seguridad en el sistema
Debe estar preparado para la posibilidad de que, a pesar de todos sus esfuerzos, alguien entre en su sistema, elimine el disco duro y lo coloque en otro sistema Windows donde se puedan restablecer las listas de control de acceso (ACL) de NTFS.
Para estar preparado, use el cifrado de volumen que se incluye en Windows Vista. Hay muchas herramientas de terceros disponibles para la mayoría de las otras versiones de Windows. La complejidad de uso de estas herramientas es variable, así como su capacidad para realizar un cifrado de volumen completo y/o un cifrado de archivos o directorios individuales como permite el sistema de cifrado de archivos (EFS). Si el volumen está cifrado, los datos estarán protegidos contra todo, excepto contra el ladrón más avanzado.

Seguridad de archivado
Los datos de copia de seguridad también deben protegerse. La mayoría de las personas tienen dos razones para no realizar copias de seguridad de sus sistemas: el cifrado de copias de seguridad requiere demasiado tiempo o el software de copia de seguridad no lo permite.
Pero si realiza copias de seguridad de sistemas y, sobre todo, si sigue esta recomendación de realizar las copias de seguridad fuera del sitio, debe proteger los datos que se incluyen en las copias de seguridad. Cifre los datos con EFS, si está disponible, u otro software de cifrado de volumen (como la característica BitLocker de Windows Vista u otro software de terceros), o compre un software de copia de seguridad que incluya las capacidades de cifrado y funcione a un nivel aceptable. Simplemente porque los datos estén ofuscados en una cinta de copia de seguridad o divididos en una solución de copia de seguridad basada en disco, no significa que estén seguros. Debe suponer que el mecanismo de transporte también puede ponerse en peligro.

Seguridad de transmisión
Debe proteger todos los datos que se transporten a través del cable. Use únicamente protocolos seguros para obtener acceso al sistema remoto. Use las versiones cifradas de los protocolos y suponga siempre que es posible un ataque de tipo "hombre intermedio" (MITM). No use protocolos mal cifrados o sin cifrar y, si usa cifrado, no use un algoritmo o una longitud de cifrado deficiente. Usted, o alguien de su organización, debe conocer todos los protocolos de comunicación y los algoritmos de cifrado que se usan entre los sistemas de su infraestructura.

Eliminación segura
Todos hemos oído historias de discos duros u otros dispositivos de almacenamiento comprados en eBay o el mercadillo local que se sometieron a software forense o incluso a utilidades de recuperación todavía más ordinarias y revelaron oscuros secretos, datos que deberían haberse borrado completamente antes de vender las unidades de disco.
Si tiene unidades UFD en su organización, considere la posibilidad de usar utilidades de cifrado obligatorio. Los discos que contienen datos de alto riesgo deben cifrarse. A pesar de la creencia popular, no estoy de acuerdo con que el simple cifrado de volúmenes antes de su retirada sea una manera segura de deshacerse de los discos. ¿Recuerda la metáfora sobre deshechos médicos que mencioné anteriormente? Trate los datos de estos sistemas como desechos peligrosos y emplee utilidades de eliminación segura de datos como tratamiento. Use una herramienta de eliminación de datos que implemente la especificación DoD 5220.22-M, como SDelete de Mari Russinovich, antes de devolver al mercado sus discos y sistemas para la reventa, o incluso antes de moverlos en la organización. De lo contrario, el siguiente usuario podrá obtener acceso a los secretos de todos los datos del usuario anterior.

Auditoría
Por último, aunque no por eso menos importante, otro componente clave para la seguridad de los datos es la auditoría, e incluso el modelado de amenazas, del ciclo de vida de los datos en su organización. Conozca los puntos débiles por los que se pueden escapar los datos y vigílelos con atención. Windows ofrece varias herramientas de auditoría integradas. Sin embargo, la auditoría puede derivar fácilmente en el desbordamiento de datos. Asegúrese de vigilar las áreas correctas y de que no se satura de datos. Controle los puntos débiles y asígneles un factor atenuante adecuado, no cubra la presa de datos con modificaciones. Asegúrese también de que los usuarios tengan un entrenamiento adecuado sobre cómo tratar los datos. Ellos son el vínculo crítico en muchos niveles de la organización. Encontrará más información en la barra lateral "Recursos adicionales". No se olvide de seguir todas las sugerencias resumidas aquí; dormirá mejor por las noches si lo hace.
Recursos adicionales
La "Guía de recursos del implementador para la optimización de la infraestructura principal: de básica a estandarizada" ofrece instrucciones para mover la infraestructura de TI de un nivel básico reactivo y muy manual a un nivel estandarizado con más estándares de configuración obligatoria y automatización, y operaciones mejoradas. Descargue la guía desde la dirección go.microsoft.com/?linkid=5795711. Puede encontrar "Guías de recursos adicionales del implementador para la optimización de la infraestructura" en microsoft.com/io. Consulte también el artículo "Las 10 leyes inmutables de la seguridad" para obtener más sugerencias sobre seguridad.


 Notas de campo: Hable con sus desarrolladores
Notas de campo Hable con sus desarrolladores and David Aiken Hacer que los desarrolladores generen aplicaciones más fáciles de administrar es más sencillo de lo que piensa. Todo empieza por la comunicación. Los desarrolladores ven el software de manera diferente a los administradores. Pero hablando con los desarrolladores, los administradores pueden explicar qué es importante para ellos y los desarrolladores pueden hacer mejor su trabajo diseñando el código en consecuencia.
Es extraño, pero los desarrolladores ven el software de manera distinta a los administradores. Los desarrolladores trabajan con código, seguimientos, archivos de configuración XML, GUID y ensamblados. Los administradores trabajan con secuencias de comandos y complementos Microsoft® Management Console (MMC) (al menos es lo que desean).
De hecho, retrocedamos un paso. Algunos días me parece que todo el proceso de desarrollo de software está interrumpido. Invertimos en muchos recursos para averiguar qué desea el usuario final. Creamos prototipos, realizamos estudios de posibilidades de uso, entrevistas, etc., y todavía nos quedamos cortos en lo que se refiere a una experiencia de administración coherente y sencilla. De hecho, nos quedamos muy cortos.
Solía pensar que Xcopy, Regedit y el Bloc de notas eran las mejores maneras de instalar software. Ahora sé que la mejor manera es un archivo de Microsoft Installer (MSI) que se puede personalizar, instalar y desinstalar. Sé que esperar que un administrador configure un servicio web usando el Bloc de notas para editar XML no es probablemente la mejor idea y un complemento MMC (o una secuencia de comandos Windows PowerShell™) es, de lejos, una opción mejor. Sé que un seguimiento de pila no es útil para un usuario o un administrador para transmitir la causa raíz y las posibles soluciones a un problema, y que es mejor un evento bien escrito en los registros de aplicaciones. Sé que para crear software que los administradores puedan administrar y usar, es necesario tratarlos como usuarios.
Con un administrador como usuario, puedo definir los casos de uso, crear prototipos, dirigir estudios de posibilidades de uso, etc. Esto me permitirá ofrecer la mejor experiencia posible para los administradores. Es decir, les ayudará a instalar, configurar, supervisar, solucionar problemas y corregir mi software sin tener que llamarme. Si uso las capacidades de administración integradas en el sistema operativo que conocen, puedo reducir de manera significativa el costo de ejecutar mi aplicación (menor escala de problemas), mejorar la satisfacción del cliente (la aplicación está inactiva menos a menudo y pueden corregir problemas rápidamente) y aumentar las oportunidades de que compren más de mi software y no del suyo (lo cual es fantástico).
Vale, esto es un sueño; pero hacer que los desarrolladores generen aplicaciones más fáciles de administrar no es sólo un sueño, es un objetivo factible. Y usted también puede ayudar. La próxima vez que algo vaya mal, no envíe sólo un mensaje de correo electrónico y se queje de ellos en voz baja. En vez de eso, sugiero que escriban un evento en el registro de la aplicación, u ofrezcan un contador de rendimiento o alguna otra indicación del problema. Lo que es aún mejor, sugiera una posible causa y resolución. Pídales que le creen una secuencia de comandos de Windows PowerShell o consola de MMC para configurar la aplicación. El tema es que los desarrolladores no siempre saben que usted existe y, menos aún, cuáles son sus necesidades. Dígaselas.


 Confidencial de Windows: Qu&#233; ven los nuevos usuarios en el men&#250; Inicio
Confidencial de Windows Qué ven los nuevos usuarios en el menú Inicio and Raymond Chen Imagínese que compra un equipo nuevo, que arranca Windows, hace clic en el botón Inicio y ve un menú en blanco. Hay una razón por la cual el menú Inicio incluye aplicaciones en la posición de elementos más usados antes de que se haya usado nada: para ofrecer una buena experiencia desde el principio. Averigüe cómo se eligen estas aplicaciones.
Pensamos en rellenar con texto este menú Inicio vacío. Algo como "Oye, tranquilo, este espacio está en blanco ahora mismo pero conforme vaya ejecutando programas, aparecerán aquí, confía en mí". El espacio ya no tendría un aspecto ridículo; ahora tendría un aspecto ridículo y poco atractivo.
Se necesitaron realizar algunas pruebas más, pero al final tomamos una decisión sobre lo que se ve en Windows XP. El mes pasado, vio que la lista de los programas usados con frecuencia se basaba en un sistema de puntos: los programas con más puntos aparecían en esta lista dinámica. Para los usuarios completamente nuevos, hemos dado algunos puntos artificiales a distintos programas. Como resultado, el primer menú Inicio presenta un ejemplo de divertidos programas para dar ideas a los usuarios sobre lo que pueden hacer.
El número de puntos artificiales se elige cuidadosamente para que haya puntos suficientes como para que los programas deseados aparezcan en la lista de programas usados con frecuencia, pero que no tengan demasiados puntos de manera que sobrepasen los verdaderos puntos obtenidos por programas a medida que los usuarios inicien las aplicaciones.
Sin embargo, estos puntos artificiales no se daban si el usuario actualizaba desde Windows 2000. En ese caso, los puntos que el menú Inicio de Windows 2000 usaba para los menús inteligentes se usaban para preseleccionar el sistema de puntos de Windows XP. De esa manera, el menú Inicio para una instalación actualizada de Windows XP reflejaba inmediatamente los programas que el usuario ejecutaba con mayor frecuencia en Windows 2000.
En el lanzamiento inicial de Windows XP, los puntos artificiales se asignaron de manera que, de las seis posiciones de la lista de programas usados con frecuencia, los tres primeros los eligiera Windows y los tres últimos, el fabricante del equipo. Si adquirió una versión comercial de Windows XP, en lugar de una preinstalada, Windows rellenó dos de esas tres posiciones y dejó la última en blanco. Así, el primer programa ejecutado aparecería inmediatamente en el menú Inicio.
Estas seis posiciones sufrieron algunas vueltas en Windows XP Service Pack 1. Windows eligió dos de las posiciones, una la eligió el Departamento de Justicia de Estados Unidos y las tres últimas, el fabricante del equipo. Como antes, si adquirió una copia minorista de Windows XP, dos de las posiciones del fabricante del equipo estaban asignadas por Windows y la última se dejaba en blanco.
El menú Inicio es una de las partes más visibles de la interfaz de usuario de Windows y, como puede ver, se dedica mucho trabajo para intentar que resulte natural e intuitivo.


 Cartas: Respuestas a sus preguntas
Cartas Respuestas a sus preguntas
Introducción a Windows PE
Tras leer el artículo de Wes Miller "Introducción a Windows PE" en el número de septiembre de 2006 de TechNet Magazine, creé un menú con el asistente basado en HTML para aplicaciones (HTA). Tengo varias preguntas relativas al funcionamiento del menú en Windows® PE 2.0.
—Andy

Aquí están sus preguntas y las respuestas de Wes:

¿Cómo sé si los componentes de software opcionales HTA y Windows Script Host (WSH) se ejecutan desde mi archivo ISO?
Si instaló los componentes opcionales en el archivo ISO de acuerdo con las instrucciones de la documentación, deberían funcionar. Conozco dos situaciones comunes en que no funcionan: Si no ejecutó el comando peimg /prep para preparar la imagen, o si no usó el parámetro /commit con ImageX para confirmar los cambios realizados en la imagen de Windows PE al desmontarla.

¿Necesito tener instalado el Instrumental de administración de Windows (WMI)? Los archivos del asistente del artículo me dan un error de Internet Explorer®.
Si las aplicaciones HTA están instaladas, los archivos del asistente deberían funcionar; son muy rudimentarios. No necesitan WMI; de hecho, los escribí antes de que se pudiese agregar WMI a Windows PE.

¿Cómo debo incluir OC.bat en el archivo startnet.cmd?
Si usa Windows PE 2.0, no es necesario agregar OC.bat, sólo es necesario para 1.x. Windows PE 2.0 le permite agregar componentes sin usar la corrección de OC.bat.

¿Puedo usar parte del código de Wes en el menú cuando tenga todo en marcha?
No hay problema, puede volver a usar cualquiera de los ejemplos de código como desee, pero no puede revenderlo ni redistribuirlo como parte de un paquete de código de ejemplo. Consulte el contrato de licencia en el sitio web de TechNet Magazine para obtener más detalles.

¿Dónde está Windows PE?
¿Dónde se encuentran las herramientas de generación de Windows PE? ¿Las puedo descargar o tengo que comprarlas?
—Franklin
Las herramientas de generación de Windows PE para Windows Vista™ forman parte del Kit de instalación automatizada de Windows (WAIK). Encontrará la descarga en go.microsoft.com/fwlink/?LinkId=85377.
El WAIK es sólo para la familia de sistemas operativos Windows Vista. Para la implementación de Windows XP, hay muchas herramientas similares disponibles en Business Desktop Deployment Solution Accelerator. Sin embargo, la licencia para Windows PE ha cambiado con Windows Vista. Anteriormente (para Windows XP), Windows PE sólo estaba disponible a través de una licencia Software Assurance (consulte el sitio microsoft.com/licensing/sa/benefits/winpe.mspx para obtener más información).

Administrador de recursos del servidor de archivos
¿El paquete Administrador de recursos del servidor de archivos estará disponible para su descarga pública de modo que se podrá usar en la versión original de Windows Server® 2003? ¿O este paquete sólo es compatible con la versión R2?
—Dan
El Administrador de recursos del Servidor de archivos es una característica de Windows Server 2003 R2. Debido a las dependencias de esa versión, en un principio, no estará disponible para versiones anteriores.

Dentro del núcleo
Tras leer el artículo de Mark Russinovich "Dentro del núcleo de Windows Vista: Parte 3", tengo dos preguntas. En primer lugar, he notado que Process Explorer muestra la ubicación aleatoria de los archivos exe o DLL en cada sesión de inicio. ¿Es posible que algún malware pueda usar el mismo mecanismo para determinar la ubicación del código que quería atacar? En segundo lugar, si la selección aleatoria puede empezar en 256 posiciones (si he entendido el artículo correctamente), ¿qué impide el sondeo con "fuerza bruta" de malware si el código de destino es estático durante la sesión?
—Joe

Mark tiene respuestas para todas sus preguntas:

Process Explorer demuestra la situación del huevo y la gallina: el malware no puede averiguar dónde están los archivos DLL porque no puede ver dónde se encuentra la API que devuelve esa información. El sondeo con "fuerza bruta" de malware no es un método de inyección confiable, ya que si el malware no acierta, en la mayoría de los casos bloqueará la aplicación que intenta infectar. Como mínimo, la selección aleatoria ralentizará la extensión de un virus. En el mejor caso, impedirá que el malware infecte un sistema.

Contacto
¿Tiene algo que decir? ¡No sea tímido! Nos encantan los comentarios de nuestros lectores. Envíenos un correo electrónico a la dirección tnmag@microsoft.com.