Almacenamiento aislado

Para las aplicaciones de escritorio, el almacenamiento aislado es un mecanismo de almacenamiento de datos que proporciona aislamiento y seguridad mediante la definición de modos estándar de asociar código a los datos guardados. La estandarización ofrece además otras ventajas. Los administradores pueden usar herramientas diseñadas para manipular el almacenamiento aislado para configurar el espacio de almacenamiento de archivos, establecer directivas de seguridad y eliminar los datos no utilizados. Con el almacenamiento aislado, el código ya no requiere rutas de acceso únicas para especificar ubicaciones seguras en el sistema de archivos y los datos están protegidos de otras aplicaciones que solo tienen acceso a un almacenamiento aislado. La información en código que indica la ubicación del área de almacenamiento de la aplicación no es necesaria.

Compartimientos y almacenes de datos

Cuando una aplicación almacena datos en un archivo, el nombre de archivo y la ubicación de almacenamiento se deben elegir con cuidado para minimizar el riesgo de que otra aplicación llegue a conocer dicha ubicación, lo que la haría susceptible de recibir daños. Si no se dispone de un sistema estándar que controle estos problemas, la improvisación de técnicas ad hoc para minimizar los conflictos de almacenamiento puede ser complicada y los resultados poco confiables.

Con el almacenamiento aislado, los datos están siempre aislados por usuario y ensamblado. Las credenciales como el origen o el nombre seguro del ensamblado determinan la identidad del ensamblado. Los datos se pueden aislar también por el dominio de la aplicación, usando credenciales parecidas.

Al usar el almacenamiento aislado, las aplicaciones guardan los datos en un compartimiento de datos único asociado a algún aspecto de la identidad del código, como su publicador o signatura. El compartimiento de datos es abstracto, no una ubicación de almacenamiento concreta; está formado por uno o varios archivos de almacenamiento aislado, denominados almacenes, que contienen las ubicaciones reales del directorio donde están almacenados los datos. Por ejemplo, una aplicación puede tener un compartimiento de datos asociado, y un directorio del sistema de archivos implementaría el almacén que conserva de hecho los datos de esa aplicación. Los datos guardados en el almacén pueden ser de cualquier tipo, desde información de preferencia del usuario hasta el estado de la aplicación. Para el desarrollador, la ubicación del compartimiento de datos es transparente. Los almacenes residen normalmente en el cliente, pero una aplicación de servidor puede usar almacenes aislados para almacenar información suplantando al usuario en cuyo nombre está trabajando. El almacenamiento aislado también puede guardar información en un servidor con un perfil de usuario móvil para que éste pueda tener acceso a la información desde donde se encuentre.

Cuotas para el almacenamiento aislado

Una cuota es un límite de la cantidad de almacenamiento aislado que se puede usar. La cuota contiene bytes de espacio de archivo además de la sobrecarga asociada al directorio y otra información del almacén. El almacenamiento aislado usa cuotas de permisos, que son límites de almacenamiento que se establecen mediante objetos IsolatedStoragePermission . Si se intenta escribir datos que superan la cuota, se produce una excepción IsolatedStorageException . La Directiva de seguridad, que se puede modificar con la herramienta Configuración de .NET Framework (Mscorcfg.msc), determina los permisos que se conceden al código. El código al que se le ha concedido el permiso IsolatedStoragePermission está restringido para que no utilice más almacenamiento que el que permite la propiedad UserQuota . Sin embargo, como el código puede omitir las cuotas de permisos presentando distintas identidades de usuario, dichas cuotas sirven como directrices sobre cómo debe comportarse el código y no como un límite estricto del comportamiento del código.

Las cuotas no se aplican a los almacenes móviles. Por ello, para que el código los use es necesario un nivel de permiso algo más alto. Los valores de enumeración AssemblyIsolationByRoamingUser y DomainIsolationByRoamingUser especifican un permiso para usar el almacenamiento aislado para un usuario móvil.

Acceso seguro

La utilización de un almacenamiento aislado permite que las aplicaciones que no son de plena confianza almacenen datos de una forma controlada por la directiva de seguridad del equipo. Esto resulta especialmente útil para componentes descargados que quizás el usuario desee usar con cautela. La directiva de seguridad raramente concede este tipo de permiso de código cuando se tiene acceso al sistema de archivos mediante los mecanismos de E/S estándar. Sin embargo, de forma predeterminada, el código que se ejecuta desde el equipo local, una red local o Internet tiene derecho a utilizar almacenamiento aislado.

Los administradores pueden limitar la cantidad de almacenamiento aislado de que disponen un usuario o una aplicación, basándose en un nivel de confianza adecuado. Además, los administradores pueden quitar los datos que se conservan de un usuario por completo. Para crear o tener acceso al almacenamiento aislado, el código debe disponer del permiso IsolatedStorageFilePermission correspondiente.

El código debe tener todos los derechos del sistema operativo de plataforma nativa necesarios para tener acceso al almacenamiento aislado. Se deben cumplir las listas de control de acceso (ACL) que controlan qué usuarios tienen derechos para usar el sistema de archivos. Las aplicaciones de .NET ya tienen los derechos de sistema operativo para acceder al almacenamiento aislado a menos que realicen la suplantación (específica de la plataforma). En ese caso, la aplicación tiene la responsabilidad de garantizar que la identidad del usuario suplantado disponga de los derechos de sistema operativo adecuados para tener acceso al almacenamiento aislado. Este acceso proporciona una forma cómoda para que el código que se ejecuta o se descarga desde Web lea y escriba en un área de almacenamiento relacionada con un usuario concreto.

Para controlar el acceso al almacenamiento aislado, Common Language Runtime usa objetos IsolatedStorageFilePermission . Cada objeto tiene propiedades que especifican los valores siguientes:

• Uso permitido, que indica el tipo de acceso permitido. Los valores son miembros de la enumeración IsolatedStorageContainment . Para obtener más información sobre estos valores, vea la tabla de la sección siguiente.

• Cuota de almacenamiento, como se describe en la sección anterior.

El runtime exige el permiso IsolatedStorageFilePermission la primera vez que el código intenta abrir un almacén. Decide si debe conceder este permiso basándose en el nivel de confianza del código. Si se concede el permiso, los valores de uso permitido y cuota de almacenamiento se determinan mediante la directiva de seguridad y la solicitud del código de IsolatedStorageFilePermission. La directiva de seguridad se configura mediante la herramienta Configuración de .NET Framework (Mscorcfg.msc). Se comprueban todos los llamadores de la pila de llamadas, para garantizar que cada llamador tiene al menos el uso permitido adecuado. El motor en tiempo de ejecución comprueba también la cuota impuesta en el código que abrió o creó el almacén en que se va a guardar el archivo. Si se cumplen estas condiciones, se concede el permiso. La cuota se vuelve a comprobar cada vez que se escribe un archivo en el almacén.

El código de la aplicación no necesita solicitar permiso porque Common Language Runtime concederá el IsolatedStorageFilePermission adecuado basándose en la directiva de seguridad. Sin embargo, existen buenas razones para solicitar permisos concretos que necesita la aplicación, como IsolatedStorageFilePermission.

Uso permitido y riesgos de seguridad

El uso permitido que especifica IsolatedStorageFilePermission determina hasta qué punto el código podrá crear y usar el almacenamiento aislado. En la siguiente tabla se muestra la correspondencia entre el uso permitido especificado en el permiso y los tipos de aislamiento, y se resumen los riesgos de seguridad asociados a cada uso permitido.

Seguridad de los componentes de almacenamiento aislado con respecto a los datos que no son de confianza

Esta sección es aplicable a los siguientes marcos:

• .NET Framework (todas las versiones)
• .NET Core 2.1+
• .NET 5 y versiones posteriores

Las plataformas .NET Framework y .NET Core ofrecen almacenamiento aislado como mecanismo para conservar los datos de un usuario, una aplicación o un componente. Se trata de un componente heredado especialmente diseñado para escenarios de seguridad de acceso del código en desuso.

Se pueden usar diversas API y herramientas de almacenamiento aislado para leer datos a través de límites de confianza. Por ejemplo, la lectura de datos desde un ámbito de nivel de máquina puede agregar datos de otras cuentas de usuario, posiblemente de menos confianza, a la máquina. Los componentes o las aplicaciones que leen desde ámbitos de almacenamiento aislado de nivel de máquina deben tener en cuenta las consecuencias de leer estos datos.

API relativas a la seguridad que pueden leer el ámbito de nivel de máquina

Los componentes o las aplicaciones que llaman a cualquiera de las siguientes API se leen desde el ámbito de nivel de máquina:

• IsolatedStorageFile.GetEnumerator (pasa un ámbito que incluye la marca IsolatedStorageScope.Machine)
• IsolatedStorageFile.GetMachineStoreForApplication
• IsolatedStorageFile.GetMachineStoreForAssembly
• IsolatedStorageFile.GetMachineStoreForDomain
• IsolatedStorageFile.GetStore (pasa un ámbito que incluye la marca IsolatedStorageScope.Machine)
• IsolatedStorageFile.Remove (pasa un ámbito que incluye la marca IsolatedStorageScope.Machine)

La herramienta de almacenamiento aisladostoreadm.exe se ve afectada si se le llama con el modificador /machine, tal y como se muestra en el código siguiente:

storeadm.exe /machine [any-other-switches]

La herramienta de almacenamiento aislado se proporciona como parte de Visual Studio y el SDK de .NET Framework.

Si la aplicación no implica llamadas a las API anteriores, o si el flujo de trabajo no implica la llamada a storeadm.exe de esta manera, no se aplica este documento.

Efecto en entornos multiusuario

Como se mencionó anteriormente, el efecto en la seguridad de estas API se deriva de que los datos escritos en un entorno de confianza se leen en otro entorno de confianza. En general, el almacenamiento aislado usa una de estas tres ubicaciones para leer y escribir datos:

1. %LOCALAPPDATA%\IsolatedStorage\: Por ejemplo, C:\Users\<username>\AppData\Local\IsolatedStorage\ para el ámbito User.
2. %APPDATA%\IsolatedStorage\: Por ejemplo, C:\Users\<username>\AppData\Roaming\IsolatedStorage\ para el ámbito User|Roaming.
3. %PROGRAMDATA%\IsolatedStorage\: Por ejemplo, C:\ProgramData\IsolatedStorage\ para el ámbito Machine.

Las dos primeras ubicaciones están aisladas por usuario. Windows garantiza que las distintas cuentas de usuario de una misma máquina no puedan acceder a las carpetas de perfil de usuario de las demás. Dos cuentas de usuario diferentes que utilizan los almacenes User o User|Roaming no verán los datos de la otra ni pueden interferir con los datos de la otra.

La tercera ubicación se comparte entre todas las cuentas de usuario de la máquina. Distintas cuentas pueden leer y escribir en esta ubicación y pueden ver los datos de las demás.

Las rutas de acceso anteriores pueden diferir en función de la versión de Windows en uso.

Ahora plantéese usar un sistema multiusuario con dos usuarios registrados Mallory y Bob. Mallory tiene la capacidad de acceder a su directorio de perfil de usuario C:\Users\Mallory\, así como a la ubicación de almacenamiento compartida de nivel de máquina C:\ProgramData\IsolatedStorage\. No puede acceder al directorio de perfil de usuario de Bob C:\Users\Bob\.

Si Mallory quiere atacar a Bob, puede escribir datos en la ubicación de almacenamiento de nivel de máquina y luego intentar influir en Bob para que lea desde el almacén de nivel de máquina. Cuando Bob ejecute una aplicación que lea en este almacén, la aplicación operará en los datos que Mallory colocó en él, pero desde el contexto de una cuenta de usuario de Bob. En el resto de este documento se contemplan varios vectores de ataque y los pasos que pueden seguir las aplicaciones para minimizar el riesgo de estos ataques.

Elevación de privilegios

Un ataque de elevación de privilegios se produce cuando la aplicación de Bob lee el archivo de Mallory y automáticamente intenta realizar alguna acción en función del contenido de esa carga. Plantéese usar una aplicación que lea el contenido de un script de inicio del almacén de nivel de máquina y pase ese contenido a Process.Start. Si Mallory puede colocar un script malintencionado dentro del almacén de nivel de máquina, cuando Bob inicia su aplicación:

• La aplicación analiza el script malintencionado de Mallory y lo ejecuta en el contexto del perfil de usuario de Bob.
• Mallory obtiene acceso a la cuenta de Bob en la máquina local.

Denegación de servicio

Un ataque por denegación de servicio se produce cuando la aplicación de Bob lee el archivo de Mallory y se bloquea o deja de funcionar correctamente. Plantéese de nuevo usar la aplicación mencionada anteriormente, que intenta analizar un script de inicio desde el almacén de nivel de máquina. Si Mallory puede colocar un archivo con un contenido incorrecto dentro del almacén de nivel de máquina, podría:

• Hacer que la aplicación de Bob inicie una excepción al principio de la ruta de acceso de inicio.
• Evitar que la aplicación se inicie correctamente debido a la excepción.

Después, ha denegado a Bob la posibilidad de iniciar la aplicación en su propia cuenta de usuario.

Divulgación de información

Un ataque de divulgación de información se produce cuando Mallory puede engañar a Bob para que revele el contenido de un archivo al que Mallory no tiene acceso normalmente. Tenga en cuenta que Bob tiene un archivo de secreto C:\Users\Bob\secret.txt que Mallory quiere leer. Mallory conoce la ruta de acceso a este archivo, pero no puede leerlo porque Windows le prohíbe obtener acceso al directorio del perfil de usuario de Bob.

En su lugar, Mallory coloca un vínculo físico en el almacén de nivel de máquina. Se trata de un tipo especial de archivo que no contiene ningún contenido, sino que apunta a otro archivo en el disco. Al intentar leer el archivo de vínculo físico, se leerá en su lugar el contenido del archivo de destino del vínculo. Después de crear el vínculo físico, Mallory todavía no puede leer el contenido del archivo porque no tiene acceso al destino (C:\Users\Bob\secret.txt) del vínculo. Sin embargo, Bob sí tiene acceso a este archivo.

Cuando la aplicación de Bob lee desde el almacén de nivel de máquina, ahora lee involuntariamente el contenido de su archivo secret.txt, como si el propio archivo hubiera estado presente en el almacén de nivel de máquina. Cuando se cierra la aplicación de Bob, si intenta volver a guardar el archivo en el almacén de toda la máquina, terminará colocando una copia del archivo en el directorio *C:\ProgramData\IsolatedStorage*. Dado que este directorio es legible para cualquier usuario de la máquina, Mallory ahora puede leer el contenido del archivo.

Procedimientos recomendados para defenderse frente a estos ataques

Importante: Si su entorno tiene varios usuarios que no son de confianza mutua, no llame a la API IsolatedStorageFile.GetEnumerator(IsolatedStorageScope.Machine) ni invoque la herramienta storeadm.exe /machine /list. Ambas acciones presuponen que trabajan en datos de confianza. Si un atacante puede inicializar una carga malintencionada en el almacén de nivel de máquina, esa carga puede conducir a un ataque de elevación de privilegios en el contexto del usuario que ejecuta estos comandos.

Si trabaja en un entorno multiusuario, reconsidere el uso de características de almacenamiento aislado que tengan como destino el ámbito de máquina. Si una aplicación debe leer datos de una ubicación de nivel de máquina, es preferible leer los datos de una ubicación en la que solo puedan escribir las cuentas de administrador. El directorio %PROGRAMFILES% y el subárbol del Registro HKLM son ejemplos de ubicaciones en las que solo pueden escribir los administradores y que pueden leer todos los usuarios. Por lo tanto, los datos leídos de esas ubicaciones se consideran de confianza.

Si una aplicación debe usar el ámbito Machine en un entorno multiusuario, se valida el contenido de cualquier archivo que se lea desde el almacén de toda la máquina. Si la aplicación deserializa los gráficos de objetos de estos archivos, plantéese la posibilidad de usar serializadores más seguros como XmlSerializer, en lugar de serializadores peligrosos como BinaryFormatter o NetDataContractSerializer. Sea cauto con los gráficos de objetos profundamente anidados o los gráficos de objetos que realizan la asignación de recursos en función del contenido del archivo.

Ubicaciones del almacenamiento aislado

En ocasiones resulta útil comprobar un cambio en el almacenamiento aislado usando el sistema de archivos del sistema operativo. También puede que se desee conocer la ubicación de los archivos de almacenamiento aislado. La ubicación cambia dependiendo del sistema operativo. En la tabla siguiente se muestran las ubicaciones raíz en que se crea el almacenamiento aislado en algunos de los sistemas operativos más frecuentes. Busque el directorio Microsoft\IsolatedStorage bajo esta ubicación raíz. Para que se muestren los archivos y carpetas ocultos y ver el almacenamiento aislado en el sistema de archivos debe cambiar la configuración de carpetas.

Crear, enumerar y eliminar almacenamiento aislado

.NET proporciona tres clases del espacio de nombres System.IO.IsolatedStorage para ayudar a realizar tareas relacionadas con el almacenamiento aislado:

• IsolatedStorageFilederiva de System.IO.IsolatedStorage.IsolatedStorage y proporciona administración básica de archivos de aplicación y ensamblado almacenados. Una instancia de la clase IsolatedStorageFile representa un único almacén ubicado en el sistema de archivos.

• IsolatedStorageFileStream que deriva de System.IO.FileStream y proporciona acceso a los archivos de un almacén.

• IsolatedStorageScope es una enumeración que permite crear y seleccionar un almacén con el tipo de aislamiento adecuado.

Las clases de almacenamiento aislado permiten crear, enumerar y eliminar almacenamiento aislado. Los métodos para realizar estas tareas están disponibles mediante el objeto IsolatedStorageFile . Algunas operaciones requieren disponer del permiso IsolatedStorageFilePermission que representa el derecho a administrar el almacenamiento aislado. También podría ser necesario disponer de derechos de sistema operativo para tener acceso a un archivo o directorio.

Para ver una serie de ejemplos que muestran tareas de almacenamiento aislado habituales, vea los temas que aparecen en enumerados en Temas relacionados.

Escenarios del almacenamiento aislado

El almacenamiento aislado resulta útil en muchas situaciones, incluidos estos cuatro escenarios:

• Controles descargados. Los controles de código administrado descargados de Internet no tienen permiso para escribir en el disco duro mediante clases de E/S normales, pero puede usar el almacenamiento aislado para almacenar la configuración del usuario y los estados de la aplicación.

• Almacenamiento de componentes compartidos. Los componentes compartidos entre aplicaciones pueden usar el almacenamiento aislado para proporcionar acceso controlado a los almacenes de datos.

• Almacenamiento en servidor. Las aplicaciones de servidor pueden usar el almacenamiento aislado para proporcionar almacenes individuales a un gran número de usuarios que hacen solicitudes a la aplicación. Puesto que el almacenamiento aislado siempre se aísla por usuario, el servidor debe suplantar al usuario que hace la solicitud. En este caso, los datos se aíslan basándose en la identidad de la entidad de seguridad, que es la identidad que usa la aplicación para diferenciar a los usuarios.

• Movilidad. Las aplicaciones pueden usar también el almacenamiento aislado con perfiles de usuario móvil. De esta manera los almacenes aislados de un usuario se pueden trasladar con el perfil.

No use el almacenamiento aislado en las situaciones siguientes:

• Para guardar información confidencial, como claves o contraseñas sin cifrar, ya que el almacenamiento aislado no está protegido contra código de plena confianza, contra código no administrado ni contra usuarios de confianza del equipo.

• Para almacenar el código.

• Para almacenar los valores de configuración e implementación, que controlan los administradores. (Las preferencias de usuario no se consideran valores de configuración porque los administradores no las controlan.)

Muchas aplicaciones usan bases de datos para almacenar y aislar los datos y, en ese caso, una o varias filas de la base de datos pueden representar el almacenamiento de un usuario concreto. Se puede elegir usar el almacenamiento aislado en lugar de una base de datos si el número de usuarios es reducido, si la sobrecarga resultante de usar una base de datos es alta o si no existe una utilidad de bases de datos. Además, si la aplicación requiere un tipo de almacenamiento más flexible y complejo que el que ofrece una fila de una base de datos, el almacenamiento aislado puede ser una alternativa viable.

Artículos relacionados

Referencia

• System.IO.IsolatedStorage.IsolatedStorage

• System.IO.IsolatedStorage.IsolatedStorageFile

• System.IO.IsolatedStorage.IsolatedStorageFileStream

• System.IO.IsolatedStorage.IsolatedStorageScope