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.
En este artículo, presentamos actividades y controles de seguridad que se deben tener en cuenta al desarrollar aplicaciones para la nube. Se tratan las preguntas y conceptos de seguridad que se deben tener en cuenta durante las fases de implementación y comprobación del ciclo de vida de desarrollo de seguridad (SDL) de Microsoft. El objetivo es ayudarle a definir actividades y servicios de Azure que puede usar para desarrollar una aplicación más segura.
En este artículo se tratan las siguientes fases del SDL:
- Implementation
- Verification
Implementation
El enfoque de la fase de implementación es establecer procedimientos recomendados para la prevención temprana y detectar y quitar problemas de seguridad del código. Supongamos que la aplicación se usa de maneras que no tenía intención de usarla. Esto le ayuda a protegerse contra el uso indebido accidental o intencional de la aplicación.
Realización de revisiones de código
Antes de proteger el código, realice revisiones de código para aumentar la calidad general del código y reducir el riesgo de crear errores. You can use Visual Studio to manage the code review process.
Realización de análisis de código estático
El análisis de código estático (también conocido como análisis de código fuente) se realiza como parte de una revisión de código. El análisis de código estático normalmente hace referencia a la ejecución de herramientas de análisis de código estático para encontrar posibles vulnerabilidades en código que no se está ejecutando. Static code analysis uses techniques like taint checking and data flow analysis.
Azure Marketplace offers developer tools that perform static code analysis and assist with code reviews.
Validar y sanear cada entrada de la aplicación
Trate toda la entrada como que no es de confianza para proteger la aplicación frente a las vulnerabilidades de aplicaciones web más comunes. Los datos que no son de confianza son un vehículo para ataques por inyección. La entrada de la aplicación incluye parámetros en la dirección URL, la entrada del usuario, los datos de la base de datos o de una API, y cualquier cosa que se pase en que un usuario podría manipular potencialmente. An application should validate that data is syntactically and semantically valid before the application uses the data in any way (including displaying it back to the user).
Valide la entrada al principio del flujo de datos para asegurarse de que solo los datos formados correctamente entran en el flujo de trabajo. No desea que los datos mal formados se conserven en su base de datos o que se desencadene un mal funcionamiento en un componente aguas abajo.
La inclusión en listas de bloqueados y la lista de permitidos son dos enfoques generales para realizar la validación de la sintaxis de entrada:
La inclusión en la lista de bloqueados intenta comprobar que una entrada de usuario determinada no contiene contenido "malintencionado".
La lista de permitidos intenta comprobar que una entrada de usuario determinada coincide con un conjunto de entradas "buenas conocidas". La lista de permitidos basada en caracteres es una forma de lista de permitidos en la que una aplicación comprueba que la entrada del usuario contiene solo caracteres "correctos conocidos" o que la entrada coincide con un formato conocido.
Por ejemplo, esto podría implicar comprobar que un nombre de usuario solo contiene caracteres alfanuméricos o que contiene exactamente dos números.
El listado de permitidos es el enfoque preferido para crear software seguro. La creación de listas de bloqueo es susceptible a errores porque es imposible pensar en una lista completa de entradas potencialmente maliciosas.
Realice este trabajo en el servidor, no en el lado cliente (o en el servidor y en el lado cliente).
Comprobación de las salidas de la aplicación
Cualquier salida que presente visualmente o dentro de un documento siempre debe codificarse y escaparse. Escaping, also known as output encoding, is used to help ensure that untrusted data isn't a vehicle for an injection attack. El escape, combinado con la validación de datos, proporciona defensas superpuestas para aumentar la seguridad del sistema en su conjunto.
Escaping makes sure that everything is displayed as output. Escaping also lets the interpreter know that the data isn't intended to be executed, and this prevents attacks from working. This is another common attack technique called cross-site scripting (XSS).
Si usa un marco web de un tercero, puede comprobar las opciones de codificación de salida en sitios web mediante la hoja de características clave de prevención XSS de OWASP.
Uso de consultas con parámetros al ponerse en contacto con la base de datos
Nunca cree una consulta de base de datos en línea "sobre la marcha" en el código y envíela directamente a la base de datos. El código malintencionado insertado en la aplicación podría provocar que la base de datos se robe, borre o modifique. La aplicación también puede usarse para ejecutar comandos de sistema operativo malintencionados en el sistema operativo que hospeda la base de datos.
En su lugar, use consultas con parámetros o procedimientos almacenados. Al usar consultas parametrizadas, puede invocar el procedimiento desde su código de forma segura y pasarle una cadena sin preocuparse de que se tratará como parte de la sentencia de consulta.
Eliminación de encabezados de servidor estándar
Los encabezados como Server, X-Powered-By y X-AspNet-Version revelar información sobre el servidor y las tecnologías subyacentes. Se recomienda suprimir estos encabezados para evitar la huella digital de la aplicación. Consulte eliminación de encabezados de servidor estándar en sitios web de Azure.
Separar los datos de producción
Los datos de producción o los datos "reales" no deben usarse para el desarrollo, las pruebas ni ningún otro propósito que no sea el previsto para la empresa. A masked (anonymized) dataset should be used for all development and testing.
Esto significa que menos personas tienen acceso a los datos reales, lo que reduce la superficie expuesta a ataques. También significa que menos empleados ven datos personales, lo que elimina una posible vulneración de confidencialidad.
Implementación de una directiva de contraseña segura
Para defenderse contra la adivinación basada en diccionarios y por fuerza bruta, debe implementar una directiva de contraseña segura para asegurarse de que los usuarios creen una contraseña compleja (por ejemplo, 12 caracteres de longitud mínima y que requieran caracteres alfanuméricos y especiales).
El Id. externa de Microsoft Entra en inquilinos externos le ayuda con la administración de contraseñas, ya que proporciona restablecimiento de contraseña de autoservicio y mucho más.
Para defenderse contra ataques en cuentas predeterminadas, compruebe que todas las claves y contraseñas se pueden reemplazar y que se generan o reemplazan después de instalar los recursos.
Si la aplicación debe generar automáticamente contraseñas, asegúrese de que las contraseñas generadas son aleatorias y que tienen una entropía alta.
Validación de cargas de archivos
If your application allows file uploads, consider precautions that you can take for this risky activity. El primer paso de muchos ataques es obtener código malintencionado en un sistema que está bajo ataque. El uso de una carga de archivos ayuda al atacante a hacerlo. OWASP ofrece soluciones para validar un archivo para asegurarse de que el archivo que está cargando es seguro.
La protección antimalware ayuda a identificar y eliminar virus, spyware y otro software malintencionado. You can install Microsoft Antimalware or a Microsoft partner's endpoint protection solution (Trend Micro, Broadcom, McAfee, Microsoft Defender Antivirus in Windows, and Endpoint Protection).
Microsoft Antimalware includes features like real-time protection, scheduled scanning, malware remediation, signature updates, engine updates, samples reporting, and exclusion event collection. Puede integrar soluciones de asociados y Microsoft Antimalware con Microsoft Defender para la nube para facilitar la implementación y las detecciones integradas (alertas e incidentes).
No almacenar en caché contenido confidencial
No almacene en caché contenido confidencial en el explorador. Los exploradores pueden almacenar información para el almacenamiento en caché y el historial. Los archivos almacenados en caché se almacenan en una carpeta como la carpeta Archivos de Internet temporales, en el caso de Internet Explorer. Cuando se vuelve a hacer referencia a estas páginas, el explorador muestra las páginas de su caché. If sensitive information (address, credit card details, Social security number, username) is displayed to the user, the information might be stored in the browser's cache and be retrievable by examining the browser's cache or by pressing the browser's Back button.
Verification
La fase de comprobación implica un esfuerzo completo para garantizar que el código cumpla los principios de seguridad y privacidad establecidos en las fases anteriores.
Búsqueda y corrección de vulnerabilidades en las dependencias de la aplicación
Examine la aplicación y sus bibliotecas dependientes para identificar los componentes vulnerables conocidos. Los productos que están disponibles para realizar este análisis incluyen OWASP Dependency Check, Snyk y Black Duck.
Prueba de la aplicación en un estado operativo
Las pruebas dinámicas de seguridad de aplicaciones (DAST) son un proceso de prueba de una aplicación en un estado operativo para encontrar vulnerabilidades de seguridad. Las herramientas DAST analizan programas mientras se ejecutan para encontrar vulnerabilidades de seguridad, como daños en la memoria, configuración de servidor no segura, scripting entre sitios, problemas de privilegios de usuario, inyección de código SQL y otros problemas de seguridad críticos.
DAST es diferente de las pruebas de seguridad de aplicaciones estáticas (SAST). Las herramientas de SAST analizan el código fuente o las versiones compiladas del código cuando el código no se está ejecutando para encontrar errores de seguridad.
Perform DAST, preferably with the assistance of a security professional (a penetration tester or vulnerability assessor). Si un profesional de seguridad no está disponible, puede realizar DAST usted mismo con un escáner de proxy web y algún entrenamiento. Conecte un escáner DAST al principio para asegurarse de que no introduce problemas de seguridad obvios en el código. See the OWASP site for a list of web application vulnerability scanners.
Realización de pruebas de vulnerabilidades
In fuzz testing, you induce program failure by deliberately introducing malformed or random data to an application. La inducción del error del programa ayuda a revelar posibles problemas de seguridad antes de que se publique la aplicación.
Detección de riesgos de seguridad es el servicio de pruebas aproximadas único de Microsoft para encontrar errores críticos para la seguridad en el software.
Realización de una revisión de la superficie expuesta a ataques
Revisar la superficie expuesta a ataques después de la finalización del código ayuda a garantizar que se haya considerado cualquier cambio de diseño o implementación en una aplicación o sistema. Ayuda a garantizar que los nuevos vectores de ataque que se crearon como resultado de los cambios, incluidos los modelos de amenazas, se han revisado y mitigado.
Puede crear una imagen de la superficie expuesta a ataques examinando la aplicación. Microsoft ofrece una herramienta de análisis de superficie expuesta a ataques denominada Analizador de superficie expuesta a ataques. Puede elegir entre muchas herramientas o servicios de análisis dinámicos y de vulnerabilidades comerciales, como Detector de superficie expuesta a ataques de OWASP, Arachni y w3af. Estas herramientas de escaneo rastrean tu aplicación y asignan las partes accesibles a través de la web. You can also search the Azure Marketplace for similar developer tools.
Realizar pruebas de penetración de seguridad
Asegurarse de que la aplicación es segura es tan importante como probar cualquier otra funcionalidad. Make penetration testing a standard part of the build and deployment process. Programe pruebas de seguridad y exámenes de vulnerabilidades periódicos en las aplicaciones, y supervise si hay puertos abiertos, ataques y puntos de conexión.
Ejecución de pruebas de comprobación de seguridad
Azure Tenant Security Solution (AzTS) de Secure DevOps Kit for Azure (AzSK) contiene SVT para varios servicios de la plataforma Azure. Estos SVT se ejecutan periódicamente para asegurarse de que la suscripción de Azure y los distintos recursos que componen la aplicación están en un estado seguro. También puede automatizar estas pruebas mediante la característica de extensiones de integración continua e implementación continua (CI/CD) de AzSK, que hace que los SVT estén disponibles como una extensión de Visual Studio.
Next steps
En los artículos siguientes, se recomiendan controles de seguridad y actividades que pueden ayudarle a diseñar e implementar aplicaciones seguras.