¿Qué necesita saber un profesional de seguridad sobre la seguridad de acceso al código (CAS)?
Honestamente diría que no mucho; hasta que necesites saberlo.
¿Por qué se han eliminado estas características de seguridad de .NET 4.0?
Porque la seguridad se estaba complicando, dando lugar a preguntas como esta. También era una solución incompleta ya que era solo las aplicaciones .NET que tenían esta funcionalidad. Tomemos, por ejemplo, que una ejecución de .NET Executable en un recurso compartido de red se ejecutaría con confianza media. La confianza media impediría el acceso a muchas funcionalidades, pero se hizo en nombre de la seguridad. Sin embargo, tenía sus defectos.
-
Los EXE nativos no se comportaron de esta manera. Si alguien iba a escribir un ejecutable malicioso, probablemente no optarían por hacerlo .NET. Un ejecutable nativo no se comporta de manera diferente cuando se ejecuta en un recurso compartido de red. Sin embargo, detuvo un medio muy "barato y simple" de aplicaciones de red que son útiles.
-
Administrarlo fue francamente confuso. Entre los grupos de códigos, las zonas, los nombres fuertes, la identidad de la aplicación y los conjuntos de permisos, se necesitaba conocer mucho por algo que no ofrecía suficiente seguridad.
-
El concepto nació antes de UAC y AppLocker, donde las personas que eran Administradores siempre tenían permisos administrativos. UAC va mucho más allá que una aplicación .NET, está en el nivel del sistema operativo.
¿Cómo aseguramos las aplicaciones .NET 4.0?
Su objetivo real no es "proteger aplicaciones .NET" sino "proteger todas las aplicaciones". AppLocker o SRP son más efectivos porque se aplican a cualquier aplicación. .NET, Java, Native, etc.
Además, al restringir el permiso del usuario, no a la aplicación. Crear una aplicación de políticas por aplicación requiere un gran esfuerzo y es aún más difícil cuando necesita comenzar a crear excepciones para ciertos usuarios.
Eso no quiere decir que .NET 4.0 no tenga ningún modelo de seguridad. El reemplazo de .NET 4.0 es Transparencia de seguridad, y las aplicaciones "hospedadas" como Silverlight, ClickOnce, etc. aún tienen conjuntos de permisos similares a CAS.
La transparencia de seguridad se basa más en un conjunto de concesión proporcionado por un entorno limitado. Tomemos, por ejemplo, Silverlight. Silverlight otorgará un conjunto de subvención diferente según si la aplicación se ejecuta en el navegador (Medium Trust) o fuera del navegador, que puede tener Full Trust. La ejecución fuera del navegador requiere la aprobación de los usuarios para hacerlo, e incluso así está restringido por cosas en el nivel del sistema operativo.
Depende del desarrollador saber qué conjuntos de permisos tiene, dependiendo de la zona de pruebas en la que se ejecute su aplicación. En efecto, las aplicaciones .NET 4 obtienen el mismo "entorno limitado" que las aplicaciones nativas. Silverlight, ClickOnce, etc. obtienen su propia zona de pruebas con mayores restricciones.
