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.
La protección de una aplicación es un proceso en curso. Nunca habrá un punto en el que un desarrollador pueda garantizar que una aplicación sea segura de todos los ataques, ya que es imposible predecir qué tipos de ataques futuros producirán nuevas tecnologías. Por el contrario, solo porque nadie ha descubierto (o publicado) errores de seguridad en un sistema no significa que ninguno exista o pueda existir. Debe planear la seguridad durante la fase de diseño del proyecto, así como planear cómo se mantendrá la seguridad durante la vigencia de la aplicación.
Diseño de seguridad
Uno de los problemas más importantes en el desarrollo de aplicaciones seguras es que la seguridad suele ser una idea posterior, algo que se debe implementar una vez completado el código de un proyecto. No crear seguridad en una aplicación al principio conduce a aplicaciones no seguras porque se ha pensado poco en lo que hace que una aplicación sea segura.
La implementación de seguridad de último minuto conduce a más errores, ya que el software falla bajo las nuevas restricciones o se debe reescribir para adaptarse a la funcionalidad no prevista. Cada línea de código revisado contiene la posibilidad de introducir un nuevo error. Por este motivo, debe considerar la seguridad al principio del proceso de desarrollo para que pueda continuar junto con el desarrollo de nuevas características.
Modelado de amenazas
No puede proteger un sistema contra ataques a menos que comprenda todos los posibles ataques a los que se expone. El proceso de evaluación de amenazas de seguridad, denominado modelado de amenazas, es necesario para determinar la probabilidad y las ramificaciones de las infracciones de seguridad en la aplicación de ADO.NET.
El modelado de amenazas se compone de tres pasos generales: comprender la vista del adversario, caracterizar la seguridad del sistema y determinar las amenazas.
El modelado de amenazas es un enfoque iterativo para evaluar las vulnerabilidades de la aplicación para encontrar aquellas que son las más peligrosas porque exponen la información más confidencial. Una vez que identifique las vulnerabilidades, las clasificará en orden de gravedad y creará un conjunto priorizado de contramedidas para contrarrestar las amenazas.
Para obtener más información, consulte los siguientes recursos:
| Recurso | Descripción |
|---|---|
| Sitio de modelado de amenazas en el Portal de ingeniería de seguridad | Los recursos de esta página le ayudarán a comprender el proceso de modelado de amenazas y crear modelos de amenazas que puede usar para proteger sus propias aplicaciones. |
Principio de privilegios mínimos
Al diseñar, compilar e implementar la aplicación, debe suponer que se atacará a la aplicación. A menudo, estos ataques proceden de código malintencionado que se ejecuta con los permisos del usuario que ejecuta el código. Otros pueden originarse con código bien intencionado que ha sido aprovechado por un atacante. Al planear la seguridad, siempre se supone que se producirá el peor de los casos.
Una medida contramedida que puede emplear es intentar levantar tantas paredes alrededor del código como sea posible mediante la ejecución con privilegios mínimos. El principio de privilegios mínimos indica que se debe conceder cualquier privilegio dado a la menor cantidad de código necesaria durante el menor tiempo necesario para realizar el trabajo.
El procedimiento recomendado para crear aplicaciones seguras consiste en empezar sin permisos en absoluto y, a continuación, agregar los permisos más estrechos para la tarea concreta que se está realizando. Por el contrario, comenzar concediendo todos los permisos y luego denegar los individuales conduce a aplicaciones inseguras que son difíciles de probar y mantener, porque pueden existir agujeros de seguridad debido a la concesión involuntaria de más permisos de los necesarios.
Para obtener más información sobre cómo proteger las aplicaciones, consulte los siguientes recursos:
| Recurso | Descripción |
|---|---|
| Protección de aplicaciones | Contiene vínculos a temas de seguridad generales. También contiene vínculos a temas para proteger aplicaciones distribuidas, aplicaciones web, aplicaciones móviles y aplicaciones de escritorio. |
Seguridad de acceso del código (CAS)
La seguridad de acceso al código (CAS) es un mecanismo que ayuda a limitar el acceso que el código tiene a recursos y operaciones protegidos. En .NET Framework, CAS realiza las siguientes funciones:
Define los permisos y los conjuntos de permisos que representan el derecho a acceder a varios recursos del sistema.
Permite a los administradores configurar la directiva de seguridad asociando conjuntos de permisos con grupos de código (grupos de código).
Permite que el código solicite los permisos que requiere para ejecutarse, así como los permisos que serían útiles para tener y especifica qué permisos el código nunca debe tener.
Concede permisos a cada ensamblado que se carga, en función de los permisos solicitados por el código y de las operaciones permitidas por la directiva de seguridad.
Permite que el código exija que sus autores de llamada tengan permisos específicos.
Permite que el código exija que sus llamadores posean una firma digital, lo que permite que solo los autores de llamadas de una organización o sitio concreto llamen al código protegido.
Aplica restricciones en el código en tiempo de ejecución comparando los permisos concedidos a cada invocador en la pila de llamadas con los permisos que deben tener los invocadores.
Para minimizar la cantidad de daños que pueden producirse si un ataque se realiza correctamente, elija un contexto de seguridad para el código que conceda acceso solo a los recursos que necesita para realizar su trabajo y ya no más.
Para obtener más información, consulte los siguientes recursos:
| Recurso | Descripción |
|---|---|
| Seguridad de acceso del código y ADO.NET | Describe las interacciones entre la seguridad de acceso al código, la seguridad basada en roles y los entornos de confianza parcial desde la perspectiva de una aplicación de ADO.NET. |
| Seguridad de acceso al código | Contiene vínculos a temas adicionales que describen CAS en .NET Framework. |
Seguridad de la base de datos
El principio de privilegios mínimos también se aplica al origen de datos. Algunas directrices generales para la seguridad de las bases de datos incluyen:
Cree cuentas con los privilegios más bajos posibles.
No permita que los usuarios accedan a cuentas administrativas solo para que el código funcione.
No devuelva mensajes de error del lado servidor a las aplicaciones cliente.
Valide toda la entrada tanto en el cliente como en el servidor.
Use comandos con parámetros y evite instrucciones SQL dinámicas.
Habilite la auditoría de seguridad y el registro de la base de datos que está usando para que se le avise a las infracciones de seguridad.
Para obtener más información, consulte los siguientes recursos:
| Recurso | Descripción |
|---|---|
| Seguridad de SQL Server | Proporciona información general sobre la seguridad de SQL Server con escenarios de aplicación que proporcionan instrucciones para crear aplicaciones de ADO.NET seguras destinadas a SQL Server. |
| Recomendaciones para estrategias de acceso a datos | Proporciona recomendaciones para acceder a los datos y realizar operaciones de base de datos. |
Directiva y administración de seguridad
La administración incorrecta de la directiva de seguridad de acceso al código (CAS) puede crear puntos débiles de seguridad. Una vez implementada una aplicación, se deben usar técnicas para supervisar la seguridad y se deben evaluar los riesgos a medida que surgen nuevas amenazas.
Para obtener más información, consulte los siguientes recursos:
| Recurso | Descripción |
|---|---|
| Administración de políticas de seguridad | Proporciona información sobre cómo crear y administrar la directiva de seguridad. |
| Procedimientos recomendados de directivas de seguridad | Proporciona vínculos que describen cómo administrar la directiva de seguridad. |