Seguridad de scripts

Se aplica a: Exchange Server 2007 SP3, Exchange Server 2007 SP2, Exchange Server 2007 SP1, Exchange Server 2007

Última modificación del tema: 2007-02-12

En este tema se explica cómo la seguridad de scripts del Shell de administración de Exchange resulta útil para evitar que scripts dañinos o no deseados, por cualquier otra razón, se ejecuten en la organización; además, se describen las opciones de las que se dispone para modificar esta seguridad de tal manera que se cumplan los requisitos de la organización.

El origen de los scripts suele ser uno de estos tres: el propio usuario, otro usuario de la organización o creadores de scripts ajenos a la organización (por ejemplo, Internet). Si un usuario escribe un script, confiará en que su función sea la razón para la que la diseñó. Si este usuario comparte el script con otros administradores de la organización, pueden confiar en él también, pero sólo porque confían en el usuario que la creó.

Sin embargo, cuando el origen de los scripts es ajeno a la organización, como Internet, la seguridad se convierte en una preocupación. El único modo de confiar en scripts cuyo origen sea ajeno a la organización es inspeccionarlo directamente y probarlo en un entorno de pruebas aislado. Este proceso puede llevar mucho tiempo y resultar tedioso. No obstante, es recomendable para evitar una ejecución no intencionada de código malintencionado o destructivo.

El Shell de administración de Exchange admite el uso recomendado de firmas digitales para asegurarse de que un script no ha sufrido alteración alguna tras su creación. Para obtener más información acerca de las firmas digitales, vea "Conceptos básicos de firma de código" más adelante en este tema. 

Modos de ejecución de scripts

Para que el Shell de administración de Exchange pueda controlar cómo se utilizan los scripts, en función de su firma y de si provienen de orígenes conocidos o no, la ejecución de los mismos se puede realizar de cuatro modos. La siguiente tabla describe los modos de ejecución de secuencias de comandos.

Modos de ejecución de secuencias de comandos

Para cambiar el modo de ejecución de secuencias de comandos del modo de ejecución de secuencias de comandos RemoteSigned predeterminado, utilice el cmdlet Set-ExecutionPolicy en el Shell de administración de Exchange. Por ejemplo, para cambiar la directiva de ejecución al modo AllSigned, ejecute el comando siguiente:

Set-ExecutionPolicy AllSigned

El Shell de administración de Exchange reconoce inmediatamente el cambio realizado en la directiva.

Las organizaciones grandes que deseen establecer el mismo modo de ejecución de secuencias de comandos en todos los equipos que ejecuten el Shell de administración de Exchange deben aplicar el modo de ejecución mediante una directiva de grupo Active Directory. Puede configurar la directiva de grupo Active Directory para definir el valor ExecutionPolicy que se encuentra en la clave de registro HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\PowerShell\1\ShellIds\Microsoft.PowerShell en el modo de ejecución de la secuencia de comandos que desee.

Conceptos básicos de firma de código

Las firmas digitales se crean mediante un algoritmo de firma de clave pública que utiliza dos claves de cifrado diferentes; estas claves reciben el nombre de par de claves, y son: la clave pública y la clave privada. La privada es una clave que solo conoce su propietario, mientras que la clave pública está disponible para cualquier usuario. En las firmas digitales, la clave privada es la que genera la firma, y la pública, la que la valida.

Un certificado es un documento digital que se suele utilizar con fines de autenticación y para proteger la información en redes abiertas. Un certificado relaciona de forma segura una clave púbilica con la entidad que contiene la correspondiente clave privada. La entidad de certificación (CA) se encarga de firmar digitalmente los certificados. Mediante un certificado de firma de código, el autor del script agrega una firma digital al archivo del script. Durante este proceso, se crea y se cifra un hash de un sólo sentido del script mediante la clave privada. El hash cifrado es una cadena de firma digital que se agrega al archivo del script. La cadena de firma digital se incluye como comentario para que no interfiera en la funcionalidad del script.

Cuando el script se ejecuta en un entorno del Shell de administración de Exchange en el que es necesaria la firma de código, se produce un nuevo hash de un sólo sentido del archivo de script. El hash de un sólo sentido se compara al hash cifrado que se incluye en el archivo de script después de ser descifrado mediante la clave pública. Si el script no recibió alteración alguna tras su firma, los dos valores hash coincidirán. El equipo intenta, entonces, comprobar que la firma procede de un emisor de confianza mediante la creación de una cadena de certificados con la entidad de certificación de confianza. Si, efectivamente se comprueba, el script se ejecuta.

Que un script sea o no de un origen de confianza depende del origen del certificado de firma de código que se utilizó para firmarlo digitalmente. Se suelen utilizar dos tipos de certificados:

• Certificados emitidos por una entidad de certificación de confianza   La entidad de certificación comprueba la identidad del solicitante antes de emitir un certificado de firma de código. La autoridad emisora puede ser una entidad externa dedicada a la venta de certificados, o bien una autoridad interna de la propia organización. Si está firmado con este tipo de certificado, el script se puede compartir con otros equipos que reconozcan y confíen en la entidad que emitió el certificado.

• Certificados autofirmados   En este tipo de certificado, el equipo es la autoridad que crea el certificado. La ventaja que ofrece este tipo de certificado es que el usuario puede escribir, firmar y ejecutar scripts en el equipo que utilice. Sin embargo, no se podrá compartir el script para que se ejecute en otros equipos porque éstos no reconocen al equipo desde el que procede el script como una entidad de certificación de confianza. De este modo, no podrán validar la firma autofirmada y no se ejecutará el script.

Cmdlets para administrar firmas de código

El Shell de administración de Exchange incluye dos cmdlets para administrar firmas de código. El cmdlet Set-AuthenticodeSignature se utiliza para agregar firmas digitales a archivos de secuencia de comandos. El cmdlet Set-AuthenticodeSignature toma el nombre del archivo que se ha de firmar como su primer parámetro posicional. Si el archivo no está en el directorio de trabajo que se utilice, es necesario proporcionar su ruta. El segundo parámetro de entrada para este cmdlet es el certificado que se utiliza para firmar. Este certificado se almacena en el almacén de certificados local. Es necesario proporcionar este parámetro en forma de cadena que haga referencia al certificado. Se puede tener acceso a este certificado a través de la unidad Cert .‏‏‎

El segundo cmdlet para administrar firmas de código es Get-AuthenticodeSignature . El cmdlet Get-AuthenticodeSignature se utiliza para comprobar y confirmar el estado actual de firma de código del archivo que se proporciona como entrada de parámetro. Si al utilizar un script de código firmado, la salida del cmdlet Get-AuthenticodeSignature incluirá información para solucionar el problema.

Para ejecutar scripts de orígenes externos, como Microsoft, es necesario adaptarlos en función del modo de ejecución del entorno en el que se trabaje. Un usuario puede recibir scripts como archivos .txt básicos, cambiarles el nombre a archivos de scripts .ps1, y posteriormente, y tras aplicar una firma determinada, ejecutar dichos scripts como si el mismo los hubiera escrito.

Para obtener más información acerca de la firma digital y las directivas de ejecución de scripts, ejecute Get-Help About_Signing en el Shell de administración de Exchange. Este comando devuelve información útil que incluye instrucciones para firmar digitalmente scripts.