Nota:
El acceso a esta página requiere autorización. Puede intentar iniciar sesión o cambiar directorios.
El acceso a esta página requiere autorización. Puede intentar cambiar los directorios.
Proteger una aplicación de base de datos en las capas de conexión, identidad, consulta y despliegue. Una autenticación exitosa no demuestra que la conexión utilice Transport Layer Security (TLS) para validar el servidor o que la identidad solo tenga los permisos que la aplicación necesita.
Lista de verificación de seguridad
| Area | Action |
|---|---|
| Cifrado de red. | Utiliza Encrypt=true o Encrypt=Strict en puntos de conexión compatibles y deja TrustServerCertificate=false para conexiones de producción remotas. |
| Autenticación. | Prefiero autenticación integrada en Windows, identidad gestionada o identidad de carga de trabajo cuando el destino y el host los soporten. |
| Autorización. | Concede solo los permisos necesarios para la base de datos. Utiliza identidades separadas para el despliegue de esquemas y las solicitudes de aplicaciones. |
| Construcción de consultas. | Parametriza los valores de los datos. Selecciona identificadores que no puedan ser parámetros de una lista de permisos controlada por la aplicación. |
| Configuración de conexión. | Usa SqlConnectionStringBuilder y configura un endpoint confiable. No concatenes fragmentos de cadena de conexión controlados por el usuario. |
| Secretos. | Utiliza una tienda secreta protegida o una identidad de host. No confirme contraseñas, claves privadas ni tókenes de portador. |
| Agrupación. | Mantenga la selección de identidad coherente con la clave del grupo, especialmente para las devoluciones de llamadas de token. |
| Errores y diagnósticos. | Devuelva errores seguros de la aplicación y conserve información de diagnóstico restringida sin incluir credenciales ni tokens. |
| Mantenimiento. | Actualizar las dependencias compatibles de controladores y bibliotecas de identidad, y comprobar el comportamiento de la conexión y la autenticación tras las actualizaciones. |
Consulta Cifrado y validación de certificados antes de cambiar la configuración en respuesta a un error de certificado.
TrustServerCertificate=true elimina una comprobación de identidad; no arregla un despliegue de certificado.
Amenazas comunes
Revisa cómo la entrada no confiable llega a los comandos de la base de datos y a la configuración de conexión, qué identidad ejecuta cada operación y qué información de diagnóstico sale de tu servicio.
Inyección de código SQL
La inyección SQL ocurre cuando una aplicación trata la entrada no confiable como Transact-SQL ejecutable (T-SQL) en lugar de datos. Utiliza parámetros de comando para los valores, con tipos explícitos y tamaños apropiados. Valida también los datos de entrada conforme a las reglas de negocio.
Los procedimientos almacenados no impiden la inyección si concatenan entradas no confiables en SQL dinámico. Parametriza las sentencias dinámicas cuando sp_executesql sea apropiado. Si el nombre de una tabla, el nombre de la columna o la dirección de ordenación deben variar, eligírelo de una lista de permisos controlada por la aplicación; los parámetros de valor ordinarios no pueden sustituir identificadores o sintaxis SQL.
No confíe solo en el escape de comillas, en un generador de cadenas de conexión o en un asignador relacional de objetos para que cualquier SQL sin procesar sea seguro. Consulta Comandos y parámetros y Escribe SQL dinámico seguro.
Elevación de privilegios
Ejecuta solicitudes de aplicación bajo una identidad de base de datos con privilegios mínimos. No concedas permisos al administrador del servidor o al propietario de la base de datos solo para que desaparezca un error de aplicación.
Separa las credenciales de migración de esquema de las credenciales en tiempo de ejecución. Concede acceso a través de funciones apropiadas a las tablas o procedimientos requeridos. Utiliza la firma mediante certificado o la suplantación con un alcance cuidadosamente delimitado solo cuando la operación necesite permisos más allá de los del llamante, y revisa ese límite de forma independiente.
La autenticación no es autorización de aplicación. Si un servicio se conecta como una sola identidad de base de datos para muchos usuarios, aún debe hacer cumplir a qué registros y operaciones puede acceder cada usuario.
Sondeo y observación inteligente
No devuelvas detalles brutos de excepciones de base de datos, cadenas de conexión ni rastreos de pila a clientes no confiables. Devuelve un error a nivel de aplicación y un identificador de correlación cuando sea apropiado.
Guarda los registros diagnósticos en un sistema de registro restringido. Registra información como la operación, el número de error de SqlClient, el intento de reintento y el identificador de correlación. Revisa el texto de excepción y la configuración de trazado para el texto de consulta, valores de parámetros, endpoints o datos personales antes de recopilarlos o exportarlos.
Gestiona los errores de forma explícita. No conviertas una consulta o un intento fallido de autenticación en una respuesta exitosa con datos vacíos. Un fallo de certificado, una credencial inválida o un permiso denegado requieren corrección en lugar de intentos ilimitados.
Autenticación
Usa una identidad que sea adecuada para el host de la aplicación. La autenticación de Windows no requiere almacenar una contraseña SQL. Las cargas de trabajo alojadas en Azure pueden usar identidad gestionada cuando sea compatible; los hosts federados pueden usar la identidad de carga de trabajo. La autenticación interactiva es para usuarios, no para servicios desatendidos.
Úsala SqlConnectionStringBuilder para asignar valores de cadena de conexión. Hace las cotizaciones y evade los valores correctamente, pero no autoriza los destinos. Mantén el servidor, la base de datos, el modo de autenticación y la política TLS bajo control de la aplicación o del administrador.
No dejes que una solicitud no confiable elija TrustServerCertificate, Encrypt, Authentication, o una dirección de servidor arbitraria. Para aplicaciones multiinquilino, obtenga la configuración autorizada del cliente en lugar de aceptar cadenas de conexión completas en las solicitudes.
Consulta autenticación de SQL Server y Windows y autenticación de Microsoft Entra.
Contraseñas
Cuando sea necesaria la autenticación SQL o una credencial de secreto cliente, recupera el secreto de una configuración protegida o de un almacén secreto. Restrinja el acceso de lectura, rote el secreto y elimine las credenciales antiguas después de la implementación.
Las variables de entorno pueden transportar secretos inyectados, pero no son un almacén secreto y pueden ser expuestas mediante diagnósticos de procesos o herramientas de despliegue. No los imprimas ni los incluyas en los informes de accidentes. Mantén los secretos de desarrollo fuera del control de versiones.
Deje Persist Security Info=false, el valor por defecto. Esta configuración limita la exposición a través de la propiedad de cadena de conexión de una conexión abierta; no borra la cadena de configuración original ni protege un secreto que registraste.
Tokens de acceso y agrupación de conexiones
Un pool de conexiones reutiliza conexiones físicas autenticadas. Mantén cada pool asociado al contexto de seguridad correspondiente.
- Un literal
AccessTokenforma parte de la clave del pool. SqlClient no puede renovarlo ni inferir su caducidad a partir de esa propiedad. Gestiona la vida útil del token y elimina los pools afectados según sea necesario. - Un
AccessTokenCallbackparticipa en la clave de grupo. Reutilice una instancia estable de delegados y credenciales para conexiones que deberían compartir un grupo. - Devuelva la misma identidad para las mismas entradas de devolución de llamada. No leas la identidad del usuario web actual dentro de una callback compartida a menos que las entradas del pool aíslen consistentemente esa identidad.
- Nunca registres tokens de acceso, secretos de cliente, claves privadas de certificados ni cadenas completas de conexión que lleven credenciales.
Utilice la guía de devolución de llamada de token para implementar la adquisición y renovación. Una función de devolución de llamada de un token no personaliza la validación del certificado TLS.
Despliegue y límites de servicio
Utiliza las versiones compatibles de Microsoft. Data.SqlClient y la biblioteca de autenticación. Mantén sincronizadas las versiones del controlador principal y de la extensión de Azure cuando uses los modos de Microsoft Entra proporcionados por el controlador. Prueba las actualizaciones con la configuración de certificados de tu servidor y el flujo real de autenticación, no solo el análisis de cadenas de conexión.
Mantener las bases de datos fuera de las redes públicas siempre que sea posible y restringir el acceso a los puntos finales requeridos de la aplicación. TLS protege el tráfico en tránsito; no hace cumplir permisos de base de datos ni cifra archivos de base de datos en disco.
LocalDB es una herramienta de desarrollo para Windows. Protege sus archivos y no uses una ejecución solo de LocalDB como prueba de comportamiento remoto de TLS o Microsoft Entra.
Comprueba las capacidades del destino antes de adoptar una función de SQL Server. La base de datos SQL de Microsoft Fabric requiere identidades de Microsoft Entra y no admite inicios de sesión de SQL, roles de aplicación ni tablas de Always Encrypted. Consulta las limitaciones de la base de datos Fabric SQL.
En esta sección
Write secure dynamic SQL explica cómo parametrizar sentencias dinámicas y revisar permisos de ejecución.