Acceso seguro a los datos
Para escribir código de ADO.NET seguro, debe comprender los mecanismos de seguridad disponibles en el almacén de datos subyacente o en la base de datos. También debe tener en cuenta las implicaciones en la seguridad de otras características o componentes que pudieran incluirse en la aplicación.
Autenticación, autorización y permisos
Si se conecta a Microsoft SQL Server, puede usar la autenticación de Windows, también conocida como seguridad integrada, que emplea la identidad del usuario de Windows activo en lugar de pasar un identificador de usuario y una contraseña. Es muy recomendable usar la autenticación de Windows para bases de datos locales, ya que las credenciales del usuario no están expuestas en la cadena de conexión. Si no puede usar la autenticación de Windows para conectarse a SQL Server, puede crear cadenas de conexión en tiempo de ejecución mediante SqlConnectionStringBuilder.
Importante
Microsoft recomienda usar el flujo de autenticación más seguro disponible. Si se conecta a Azure SQL, el método de autenticación recomendado es Identidades administradas para recursos de Azure.
Las credenciales utilizados para la autenticación deben tratarse de manera diferente dependiendo del tipo de aplicación. Por ejemplo, en una aplicación de Windows Forms, se puede solicitar al usuario que proporcione información de autenticación o bien, se pueden utilizar las credenciales de Windows del usuario. Sin embargo, una aplicación web normalmente obtiene acceso a los datos mediante credenciales proporcionadas por la misma aplicación y no por el usuario.
Una vez que los usuarios se han autenticado, el ámbito de sus acciones depende de los permisos que se les hayan concedido. Siga siempre el principio de los privilegios mínimos y conceda solo los permisos absolutamente necesarios.
Para obtener más información, vea los recursos siguientes.
| Resource | Descripción |
|---|---|
| Proteger la información de conexión | Describe las prácticas y técnicas recomendadas de seguridad para proteger la información de conexión, como el uso de configuración protegida para cifrar cadenas de conexión. |
| Generadores de cadenas de conexión | Describe cómo crear cadenas de conexión a partir de la entrada del usuario en tiempo de ejecución. |
| Seguridad para el motor de base de datos de SQL Server y Azure SQL Database | Incluye los vínculos para ayudarle a buscar la información sobre seguridad y protección en el motor de base de datos de SQL Server y Azure SQL Database. |
Comandos con parámetros e inyección de código SQL
La utilización de comandos con parámetros ayuda en la protección contra ataques por inyección de código SQL, en los que un atacante "inyecta" un comando en una instrucción SQL que pone en peligro la seguridad del servidor. Los comandos con parámetros protegen de ataques por inyección de código SQL ya que garantizan que los valores recibidos desde un origen externo pasan solo como valores y no como parte de la instrucción de Transact-SQL. Como resultado, los comandos Transact-SQL insertados en un valor no se ejecutan en el origen de datos. En cambio, se evalúan únicamente como un valor de parámetro. Además de las ventajas en el aspecto de la seguridad, los comandos con parámetros proporcionan un método práctico para organizar los valores que se pasan con una instrucción de Transact-SQL a un procedimiento almacenado.
Para obtener más información sobre el uso de comandos con parámetros, vea los siguientes recursos.
| Resource | Descripción |
|---|---|
| Parámetros de DataAdapter | Describe cómo usar parámetros con DataAdapter. |
| Modificar datos con procedimientos almacenados | Describe cómo especificar parámetros y cómo obtener un valor devuelto. |
| Procedimientos almacenados (motor de base de datos) | Describe las ventajas de usar procedimientos almacenados y los distintos tipos de procedimientos almacenados. |
Ataques mediante sondeo
Es muy frecuente que los atacantes utilicen la información de una excepción, como el nombre del servidor, de la base de datos o de una tabla, para llevar a cabo un ataque contra el sistema. Como las excepciones pueden contener información específica sobre la aplicación o el origen de datos, puede mejorar la protección de la aplicación y del origen de datos exponiendo únicamente la información necesaria al cliente.
Para obtener más información, vea los recursos siguientes.
| Resource | Descripción |
|---|---|
| Controlar y generar excepciones en .NET | Describe las formas básicas Try/Catch/Finally del control de excepciones estructurado. |
| Procedimientos recomendados para excepciones | Describe los procedimientos recomendados para controlar excepciones. |
Proteger orígenes de datos de Microsoft Access y Excel
Microsoft Access y Microsoft Excel pueden funcionar como almacén de datos para una aplicación de ADO.NET cuando los requisitos de seguridad son mínimos o no existen. Sus características de seguridad son eficaces para fines de disuasión, aunque solo es conveniente confiar en ellas para evitar la intromisión por parte de usuarios no informados. Los archivos de datos físicos de Access y Excel existen en el sistema de archivos y todos los usuarios deben tener acceso a ellos. Esto los hace vulnerables ante ataques que pueden dar lugar al robo o pérdida de datos, ya que los archivos se pueden copiar o modificar fácilmente. Cuando sea necesaria una seguridad potente, use SQL Server u otra base de datos basada en servidor donde los archivos de datos físicos no se puedan leer desde el sistema de archivos.
Enterprise Services
COM+ contiene su propio modelo de seguridad que se basa en las cuentas de Windows y en la suplantación de procesos y subprocesos. El espacio de nombres System.EnterpriseServices proporciona contenedores que permiten a las aplicaciones .NET integrar código administrado con servicios de seguridad COM+ mediante la clase ServicedComponent.
Interoperación con código no administrado
.NET Framework permite la interacción con código no administrado, incluidos componentes COM, servicios COM+, bibliotecas de tipos externas y muchos servicios del sistema operativo. El trabajo con código no administrado supone traspasar el perímetro de seguridad del código administrado. Tanto su código como cualquier otro código que llame a su código, deben tener el permiso de código no administrado (SecurityPermission con el marcador UnmanagedCode especificado). El código no administrado puede insertar de forma involuntaria vulnerabilidades de seguridad en la aplicación. Por tanto, debe evitar la interoperabilidad con código no administrado a menos que sea absolutamente necesario.
Para más información, consulte Interoperating with Unmanaged Code (Interoperar con código no administrado)