El control de acceso basado en procesos solo funciona con datos en la memoria transitoria (por ejemplo, RAM). Una vez que los datos se almacenan en un medio semipermanente (por ejemplo, un disco duro, una unidad flash, un DVD, etc.), ese medio se puede conectar fácilmente a un sistema que no respetará ninguna restricción de acceso que se aplique en su entorno nativo.
Puede agregar control de acceso basado en procesos al entorno nativo, pero eso solo protege contra un atacante restringido a ese entorno que ya tiene la capacidad de ejecutar código en su sistema. Un atacante con tal acceso prácticamente tiene reinado en el sistema, por lo que es casi imposible protegerse contra tal amenaza. Cualquier intento de hacerlo, especialmente de la manera que sugiere, tendría que comprometer seriamente la experiencia del usuario y la facilidad de uso del sistema.
Como mínimo, puedo pensar en tres programas que tendría que incluir en la lista blanca para cada archivo:
- Explorador de archivos (por ejemplo, Explorer)
- Visor de documentos (por ejemplo: Acrobat, Word, Excel, etc.)
- Antivirus (haz tu elección)
Dos de estas son cosas que muy ampliamente variarán de un sistema a otro, de un archivo a otro y de un usuario a otro, y todas están sujetas a cambios a través de las actualizaciones de software. Y probablemente hay muchas cosas en las que no estoy pensando. Sería casi imposible para el desarrollador de la herramienta construir y mantener adecuadamente una base de datos completa de solo los programas más utilizados para incluirlos automáticamente en la lista blanca para el usuario.
Por lo tanto, se le debería pedir al usuario que agregue programas a la lista blanca. Estas indicaciones aparecerán, como mínimo, la primera vez que cada programa necesite acceder al volumen y nuevamente cada vez que el programa intente acceder al volumen después de haber aplicado una actualización. Eventualmente, las indicaciones llegarán a los niveles de ruido UAC de la era de Vista y el usuario terminará deshabilitando la seguridad o la aprobación automática, lo que inutilizará la función.
Todo esto se vuelve discutible por cualquier número de medios (rootkits y keyloggers para comenzar) que son comúnmente utilizados por los atacantes para comprometer los sistemas. La mejor manera de evitar que los procesos accedan a sus datos encriptados de manera inapropiada es no permitir que dichos procesos se instalen y ejecuten en primer lugar.