¿Le resultó útil esta página?
Sus comentarios sobre este contenido son muy importantes. Háganos saber su opinión.
¿Tiene comentarios adicionales?
Caracteres restantes: 1500
Exportar (0) Imprimir
Expandir todo
Este artículo se tradujo de forma manual. Mueva el puntero sobre las frases del artículo para ver el texto original. Más información.
Traducción
Original

Conceptos clave de seguridad

Microsoft .NET Framework ofrece transparencia en seguridad, seguridad de acceso del código y seguridad basada en roles para ayudar a solucionar problemas de seguridad relativos a código móvil y para permitir que los componentes determinen qué usuarios tienen autorización para operar. Estos mecanismos de seguridad usan un modelo sencillo y coherente para que los desarrolladores familiarizados con la seguridad de acceso del código puedan utilizar fácilmente la seguridad basada en roles y viceversa. Tanto la seguridad de acceso del código como la seguridad basada en roles se implementan mediante una infraestructura común proporcionada por Common Language Runtime.

Nota Nota

A partir de .NET Framework 4, la transparencia en seguridad es el mecanismo predeterminado de seguridad. La transparencia en seguridad separa el código que se ejecuta como parte de la aplicación del código que se ejecuta como parte de la infraestructura. Para obtener más información, consulte el artículo sobre Código transparente en seguridad.

Puesto que usan el mismo modelo e infraestructura, la seguridad de acceso del código y la seguridad basada en roles comparten varios conceptos subyacentes, que se describen en esta sección. Asegúrese de que está familiarizado con estos conceptos antes de leer la documentación de seguridad de acceso del código de .NET Framework y la seguridad basada en roles.

Common Language Runtime permite que el código realice únicamente las operaciones para las que tiene permiso. El runtime usa objetos denominados permisos para aplicar restricciones en el código administrado. El runtime proporciona clases de permiso integradas en varios espacios de nombres y también admite el diseño y la implementación de clases de permiso personalizadas.

Hay dos tipos de permisos y cada una tiene una finalidad específica:

Los permisos de seguridad pueden ser en forma de una clase de permiso (seguridad imperativa) o de un atributo que representa una clase de permiso (seguridad declarativa). La clase base para permisos de seguridad es System.Security.CodeAccessPermission; la clase base para los atributos de permiso de seguridad es System.Security.Permissions.CodeAccessSecurityAttribute.

A una aplicación, en forma de un ensamblado, se le concede un conjunto de permisos en el momento en que se carga en un dominio de aplicación. Normalmente, las concesiones se realizan mediante el uso de conjuntos de permisos predefinidos que vienen determinados por el método SecurityManager.GetStandardSandbox. El conjunto de permisos determina los permisos que el código tiene a su disposición. El runtime concede permisos basados en la ubicación de origen del código (por ejemplo, la máquina local, intranet local o Internet). El código también puede obtener permisos especiales si se carga en un espacio aislado. Para obtener más información, vea el artículo sobre la Cómo: Ejecutar código de confianza parcial en un recinto.

Los usos principales de permisos son los siguientes:

  • El código de biblioteca puede exigir que sus llamadores tengan permisos específicos. Si coloca un Demand para un permiso en el código, se espera que todo el código que usa su código tenga ese permiso para poder ejecutarse. Las peticiones ({i>demands<i}) pueden usarse para determinar si los llamadores tienen acceso a recursos específicos o para detectar la identidad del llamador.

  • El código puede usar permisos para denegar el acceso a los recursos que desea proteger. Puede usar SecurityAction.PermitOnly para especificar un conjunto de permisos limitados y denegar implícitamente el resto de los permisos. Sin embargo, no le recomendamos usar PermitOnly para prohibir el acceso con el fin de proteger contra el uso indebido intencionado. Los ensamblados llamados, que tienen los permisos denegados implícitamente en su conjunto de permisos, pueden invalidar los permisos denegados mediante un SecurityAction.Assert para cualquier permiso que deseen usar. Por ejemplo, si permite solo UIPermission y llama a un ensamblado que tiene inherentemente FileIOPermission, el ensamblado puede hacer simplemente un Assert para FileIOPermission y realizar operaciones de archivo. Es la única manera de proteger los recursos de forma segura de código no seguro en los ensamblados con referencia es ejecutar ese código con un conjunto de permisos que no incluya esos permisos.

z164t8hs.collapse_all(es-es,VS.110).gifPermisos de acceso del código

Los permisos de acceso del código son objetos de permiso que se usan para ayudar a proteger los recursos y las operaciones contra el uso no autorizado. Son una parte fundamental del mecanismo de Common Language Runtime para aplicar restricciones de seguridad en el código administrado.

Cada permiso de acceso del código representa uno de los siguientes derechos:

  • El derecho a tener acceso a un recurso protegido, como archivos o variables de entorno.

  • El derecho a realizar una operación protegida, como tener acceso a código no administrado.

Todos los permisos de acceso del código pueden solicitarse o exigirse mediante código, y el runtime decide qué permisos, si los hay, se deben conceder al código.

Cada permiso de acceso del código se deriva de la clase CodeAccessPermission, lo que significa que todos los permisos de acceso del código tienen métodos en común, como Demand, Assert, Deny, PermitOnly, IsSubsetOf, Intersect y Union.

Nota importante Importante

En .NET Framework 4, se ha quitado la compatibilidad de runtime para exigir las solicitudes de permiso Deny, RequestMinimum, RequestOptional y RequestRefuse. Estas solicitudes no deben usarse en código basado en .NET Framework 4 o en una versión posterior. Para obtener más información sobre este y otros cambios, vea el artículo sobre Cambios de seguridad en .NET Framework.

z164t8hs.collapse_all(es-es,VS.110).gifPermisos de seguridad basada en roles

PrincipalPermission es un permiso de seguridad basada en roles que puede usarse para determinar si un usuario tiene una identidad especificada o es miembro de un rol especificado. PrincipalPermission es el único permiso de seguridad basada en roles proporcionado por la biblioteca de clases de .NET Framework.

El código seguro de tipos sólo tiene acceso a las ubicaciones de memoria para las que tiene autorización. A efectos de esta descripción, la seguridad de tipos se refiere concretamente a la seguridad de tipos en memoria y no debe confundirse con la seguridad de tipos en un sentido más amplio. Por ejemplo, el código seguro de tipos no puede leer valores de los campos privados de otro objeto. Sólo puede obtener acceso a tipos siguiendo métodos permitidos y perfectamente definidos.

Durante la compilación Just-in-time (JIT), un proceso opcional de comprobación examina los metadatos y el lenguaje intermedio de Microsoft (MSIL) de los métodos a compilar a código máquina nativo, para comprobar si tienen seguridad de tipos. Este proceso se omite si el código tiene permiso para evitar la comprobación. Para obtener más información acerca de la comprobación, vea el artículo sobre el Proceso de ejecución administrada.

Aunque la comprobación de la seguridad de tipos no es obligatoria para la ejecución de código administrado, la seguridad de tipos desempeña un rol crucial en el aislamiento del ensamblado y la exigencia de seguridad. Cuando el código tiene seguridad de tipos, Common Language Runtime puede aislar totalmente ensamblados entre sí. Este aislamiento ayuda a garantizar que los ensamblados no puedan ejercer influencias negativas entre sí y aumenta la confiabilidad de la aplicación. Los componentes seguros de tipos se pueden ejecutar de forma segura en el mismo proceso aunque dispongan de confianza en diferentes niveles. Cuando el código no tiene seguridad de tipos, pueden producirse efectos secundarios no deseados. Por ejemplo, el runtime no puede evitar la llamada de código administrado en código nativo (no administrado) ni la realización de operaciones malintencionadas. Cuando el código tiene seguridad de tipos, el mecanismo de exigencia de seguridad del motor en tiempo de ejecución garantiza que no tiene acceso a código nativo salvo que tenga permiso explícito para ello. El código sin seguridad de tipos debe haber obtenido permiso SecurityPermission con el miembro de enumeración SkipVerification transferido para la ejecución.

Para obtener más información, consulte el artículo sobre cómo escribir código seguro comprobable.

Una entidad de seguridad (principal) representa la identidad y el rol de un usuario y actúa en nombre del usuario. La seguridad basada en roles de .NET Framework admite tres tipos de entidades de seguridad:

  • Las entidades de seguridad genéricas representan usuarios y roles que son independientes de los roles y los usuarios de Windows.

  • Las entidades de seguridad de Windows representan a los usuarios de Windows y sus roles (o grupos de Windows). Una entidad de seguridad de Windows puede suplantar a otro usuario, lo que significa que la entidad de seguridad puede tener acceso a un recurso en nombre de un usuario presentando la identidad que pertenece a dicho usuario.

  • Una aplicación puede definir entidades de seguridad personalizadas que se adapten a las necesidades de esa aplicación en particular. Asimismo, se puede ampliar la noción básica de la identidad y los roles de la entidad de seguridad.

Para obtener más información, consulte el artículos sobre los Objetos Principal e Identity.

La autentificación es el proceso de detectar y comprobar la identidad de una entidad de seguridad examinando las credenciales del usuario y validando esas credenciales contra alguna autoridad. Su código puede usar fácilmente la información obtenida durante la autenticación. También puede usar la seguridad basada en roles de .NET Framework para autenticar al usuario actual y para determinar si esa entidad de seguridad puede tener acceso a su código. Vea las sobrecargas del método WindowsPrincipal.IsInRole para obtener ejemplos de cómo autenticar la entidad de seguridad para roles específicos. Por ejemplo, puede usar la sobrecarga WindowsPrincipal.IsInRole(String) para determinar si el usuario actual es miembro del grupo Administradores.

Hoy en día se usan diversos mecanismos de autenticación, muchos de los cuales pueden utilizarse con la seguridad basada en roles de .NET Framework. Algunos de los mecanismos más usados son básico, implícito, Passport, sistema operativo (como NTLM o Kerberos) o los mecanismos definidos por la aplicación.

z164t8hs.collapse_all(es-es,VS.110).gifEjemplo

El ejemplo siguiente requiere que la entidad de seguridad activa sea un administrador. El parámetro name es null, que permite que cualquier usuario que sea administrador pase la petición.

Nota Nota

En Windows Vista, el control de cuentas de usuario (UAC) determina los privilegios de un usuario. Si es miembro del grupo Administradores integrados, se le asignarán dos símbolos (tokens) de acceso en tiempo de ejecución: un símbolo (token) de acceso de usuario estándar y un símbolo (token) de acceso de administrador. De forma predeterminada, se le asignará el rol de usuario estándar. Para ejecutar código que requiere permisos de administrador, primero debe elevar el nivel de sus privilegios de usuario estándar a administrador. Para ello, inicie una aplicación haciendo clic con el botón derecho en el icono de la aplicación e indique que desea ejecutarla como administrador.


using System;
using System.Threading;
using System.Security.Permissions;
using System.Security.Principal;

class SecurityPrincipalDemo
{

    public static void Main()
    {
        AppDomain.CurrentDomain.SetPrincipalPolicy(PrincipalPolicy.WindowsPrincipal);
        PrincipalPermission principalPerm = new PrincipalPermission(null, "Administrators");
        principalPerm.Demand();
        Console.WriteLine("Demand succeeded.");
    }
}


En el ejemplo siguiente se muestra cómo determinar la identidad de la entidad de seguridad y los roles disponibles para dicha entidad de seguridad. Una posible aplicación de este ejemplo sería la confirmación de que el usuario actual está en un rol permitido para usar la aplicación.


using System;
using System.Threading;
using System.Security.Permissions;
using System.Security.Principal;

class SecurityPrincipalDemo
{
    public static void DemonstrateWindowsBuiltInRoleEnum()
    {
        AppDomain myDomain = Thread.GetDomain();

        myDomain.SetPrincipalPolicy(PrincipalPolicy.WindowsPrincipal);
        WindowsPrincipal myPrincipal = (WindowsPrincipal)Thread.CurrentPrincipal;
        Console.WriteLine("{0} belongs to: ", myPrincipal.Identity.Name.ToString());
        Array wbirFields = Enum.GetValues(typeof(WindowsBuiltInRole));
        foreach (object roleName in wbirFields)
        {
            try
            {
                // Cast the role name to a RID represented by the WindowsBuildInRole value.
                Console.WriteLine("{0}? {1}.", roleName,
                    myPrincipal.IsInRole((WindowsBuiltInRole)roleName));
                Console.WriteLine("The RID for this role is: " + ((int)roleName).ToString());

            }
            catch (Exception)
            {
                Console.WriteLine("{0}: Could not obtain role for this RID.",
                    roleName);
            }
        }
        // Get the role using the string value of the role.
        Console.WriteLine("{0}? {1}.", "Administrators",
            myPrincipal.IsInRole("BUILTIN\\" + "Administrators"));
        Console.WriteLine("{0}? {1}.", "Users",
            myPrincipal.IsInRole("BUILTIN\\" + "Users"));
        // Get the role using the WindowsBuiltInRole enumeration value.
        Console.WriteLine("{0}? {1}.", WindowsBuiltInRole.Administrator,
           myPrincipal.IsInRole(WindowsBuiltInRole.Administrator));
        // Get the role using the WellKnownSidType.
        SecurityIdentifier sid = new SecurityIdentifier(WellKnownSidType.BuiltinAdministratorsSid, null);
        Console.WriteLine("WellKnownSidType BuiltinAdministratorsSid  {0}? {1}.", sid.Value, myPrincipal.IsInRole(sid));
    }

    public static void Main()
    {
        DemonstrateWindowsBuiltInRoleEnum();
    }
}


La autorización es el proceso de determinar si una entidad de seguridad puede realizar una acción solicitada. La autorización se produce después de la autenticación y usa información sobre la identidad y los roles de la entidad de seguridad para determinar a qué recursos puede tener acceso la entidad de seguridad. Para implementar la autorización, se puede usar la seguridad basada en roles de .NET Framework.

Nunca base la seguridad de su aplicación en un miembro que esté marcado con el modificador internal virtual en C# (Overloads Overridable Friend en Visual Basic). A pesar de que los miembros marcados con estos modificadores solo pueden ser invalidados por otros miembros del ensamblado actual, únicamente aplican esta regla los lenguajes C# y Visual Basic. El runtime no la aplica. Por lo tanto, es posible invalidar los miembros marcados como internal virtual en C# y Overloads Overridable Friend en Visual Basic usando el Lenguaje Intermedio de Microsoft o cualquier otro lenguaje que no aplique esta regla.

Adiciones de comunidad

AGREGAR
Mostrar:
© 2015 Microsoft