Compartir a través de

Marco de seguridad: seguridad de comunicación | Mitigaciones

Producto o servicio Artículo
Centro de eventos de Azure
Dynamics CRM
Azure Data Factory
Identity Server
Aplicación web
Base de datos
Azure Storage
Cliente para dispositivos móviles
WCF
Web API
Azure Cache for Redis
Puerta de enlace de campo de IoT
Puerta de enlace de nube de IoT

Protección de la comunicación con el centro de eventos mediante SSL/TLS

Título Detalles
Componente Centros de eventos de Azure
Fase de SDL Construir
Tecnologías aplicables Genérico
Atributos No disponible
Referencias Introducción al modelo de autenticación y seguridad de Event Hubs
Pasos Protección de conexiones AMQP o HTTP al centro de eventos mediante SSL/TLS

Compruebe los privilegios de la cuenta de servicio y compruebe que los servicios personalizados o ASP.NET Pages respetan la seguridad de CRM.

Título Detalles
Componente Dynamics CRM
Fase de SDL Construir
Tecnologías aplicables Genérico
Atributos No disponible
Referencias No disponible
Pasos Compruebe los privilegios de la cuenta de servicio y compruebe que los servicios personalizados o ASP.NET Pages respetan la seguridad de CRM.

Uso de Data Management Gateway al conectar SQL Server local a Azure Data Factory

Título Detalles
Componente Azure Data Factory
Fase de SDL Despliegue
Tecnologías aplicables Genérico
Atributos Tipos de servicio vinculados: Azure y local
Referencias Movimiento de datos entre el entorno local y Azure Data Factory
Pasos

La herramienta Data Management Gateway (DMG) es necesaria para conectarse a orígenes de datos que están protegidos detrás de una red corporativa o un firewall.

  1. Bloquear la máquina aísla la herramienta DMG y evita que los programas defectuosos dañen o espíen en la máquina del origen de datos. (Por ejemplo, las actualizaciones más recientes deben instalarse, habilitar los puertos mínimos necesarios, el aprovisionamiento controlado de cuentas, la auditoría habilitada, el cifrado de disco, etc.)
  2. La clave de puerta de enlace de datos debe rotarse a intervalos frecuentes o cada vez que se renueva la contraseña de la cuenta de servicio DMG.
  3. Los tránsitos de datos a través del servicio Link deben cifrarse

Asegúrese de que todo el tráfico a Identity Server se realiza a través de la conexión HTTPS

Título Detalles
Componente Servidor de Identidad
Fase de SDL Despliegue
Tecnologías aplicables Genérico
Atributos No disponible
Referencias No disponible
Pasos De forma predeterminada, IdentityServer requiere que todas las conexiones entrantes lleguen a través de HTTPS. Es absolutamente obligatorio que la comunicación con IdentityServer se realice solo a través de transportes protegidos. Hay ciertos escenarios de implementación, como el desvío de carga de TLS, donde este requisito puede relajarse. Consulte la página Implementación de Identity Server en las referencias para obtener más información.

Comprobación de los certificados X.509 usados para autenticar conexiones SSL, TLS y DTLS

Título Detalles
Componente Aplicación web
Fase de SDL Construir
Tecnologías aplicables Genérico
Atributos No disponible
Referencias No disponible
Pasos

Las aplicaciones que usan SSL, TLS o DTLS deben comprobar completamente los certificados X.509 de las entidades a las que se conectan. Esto incluye la comprobación de los certificados para:

  • Nombre de dominio
  • Fechas de validez (fechas de inicio y expiración)
  • Estado de revocación
  • Uso (por ejemplo, Autenticación de servidor para servidores, Autenticación de cliente para clientes)
  • Cadena de confianza. Los certificados deben encadenar a una entidad de certificación (CA) raíz que sea de confianza para la plataforma o configurada explícitamente por el administrador.
  • La longitud de clave de la clave pública del certificado debe ser >de 2048 bits
  • El algoritmo hash debe ser SHA256 y versiones posteriores

Configuración del certificado TLS/SSL para un dominio personalizado en Azure App Service

Título Detalles
Componente Aplicación web
Fase de SDL Construir
Tecnologías aplicables Genérico
Atributos EnvironmentType: Azure
Referencias Habilitación de HTTPS para una aplicación en Azure App Service
Pasos De forma predeterminada, Azure ya habilita HTTPS para cada aplicación con un certificado comodín para el dominio *.azurewebsites.net. Sin embargo, al igual que todos los dominios con caracteres comodín, no es tan seguro como el uso de un dominio personalizado con un certificado propio Refer. Se recomienda habilitar TLS para el dominio personalizado al que se accederá a la aplicación implementada a través de

Forzar todo el tráfico a Azure App Service a través de la conexión HTTPS

Título Detalles
Componente Aplicación web
Fase de SDL Construir
Tecnologías aplicables Genérico
Atributos EnvironmentType: Azure
Referencias Aplicación de HTTPS en Azure App Service
Pasos

Aunque Azure ya habilita HTTPS para los servicios de aplicaciones de Azure con un certificado comodín para el dominio *.azurewebsites.net, no aplica HTTPS. Los visitantes todavía pueden acceder a la aplicación mediante HTTP, lo que puede poner en peligro la seguridad de la aplicación y, por lo tanto, HTTPS debe aplicarse explícitamente. Las aplicaciones MVC de ASP.NET deben usar el filtro RequireHttps que obliga a reenviar una solicitud HTTP no segura a través de HTTPS.

Como alternativa, el módulo reescritura de direcciones URL, que se incluye con Azure App Service, se puede usar para aplicar HTTPS. El módulo Reescritura de direcciones URL permite a los desarrolladores definir reglas que se aplican a las solicitudes entrantes antes de que las solicitudes se entreguen a la aplicación. Las reglas de reescritura de direcciones URL se definen en un archivo web.config almacenado en la raíz de la aplicación.

Ejemplo

El ejemplo siguiente contiene una regla básica de reescritura de direcciones URL que obliga a todo el tráfico entrante a usar HTTPS.

<?xml version="1.0" encoding="UTF-8"?>
<configuration>
  <system.webServer>
    <rewrite>
      <rules>
        <rule name="Force HTTPS" enabled="true">
          <match url="(.*)" ignoreCase="false" />
          <conditions>
            <add input="{HTTPS}" pattern="off" />
          </conditions>
          <action type="Redirect" url="https://{HTTP_HOST}/{R:1}" appendQueryString="true" redirectType="Permanent" />
        </rule>
      </rules>
    </rewrite>
  </system.webServer>
</configuration>

Esta regla funciona devolviendo un código de estado HTTP de 301 (redirección permanente) cuando el usuario solicita una página mediante HTTP. El 301 redirige la solicitud a la misma dirección URL que el visitante solicitado, pero reemplaza la parte HTTP de la solicitud por HTTPS. Por ejemplo, HTTP://contoso.com se redirigiría a HTTPS://contoso.com.

Habilitación de la seguridad de transporte estricta HTTP (HSTS)

Título Detalles
Componente Aplicación web
Fase de SDL Construir
Tecnologías aplicables Genérico
Atributos No disponible
Referencias Hoja de referencia rápida de seguridad de transporte estricto HTTP del Proyecto de seguridad de aplicación web abierta
Pasos

HTTP Strict Transport Security (HSTS) es una mejora en la seguridad optativa especificada por una aplicación web a través de un encabezado de respuesta especial. Una vez que un explorador compatible recibe este encabezado, ese explorador impedirá que las comunicaciones se envíen a través de HTTP al dominio especificado y en su lugar enviarán todas las comunicaciones a través de HTTPS. También evita que aparezcan en los exploradores elementos click-through HTTPS.

Para implementar HSTS, el siguiente encabezado de respuesta debe configurarse para un sitio web globalmente, ya sea en el código o en la configuración. Strict-Transport-Security: max-age=300; includeSubDomains HSTS aborda las siguientes amenazas:

  • El usuario guarda marcadores o escribe manualmente https://example.com y es vulnerable a un atacante de intermediario; HSTS redirige automáticamente las solicitudes HTTP a HTTPS para el dominio de destino.
  • La aplicación web que está pensada para ser puramente HTTPS contiene accidentalmente vínculos HTTP o sirve contenido a través de HTTP: HSTS redirige automáticamente las solicitudes HTTP a HTTPS para el dominio de destino.
  • Un atacante de tipo "man in the middle" intenta interceptar el tráfico de un usuario víctima mediante un certificado no válido y espera que el usuario acepte el certificado incorrecto: HSTS no permite que un usuario invalide el mensaje de certificado no válido.

Asegúrese de que haya cifrado de la conexión del servidor SQL y validación de certificados.

Título Detalles
Componente Base de datos
Fase de SDL Construir
Tecnologías aplicables SQL Azure
Atributos Versión de SQL: V12
Referencias Procedimientos recomendados para escribir cadenas de conexión seguras para SQL Database
Pasos

Todas las comunicaciones entre SQL Database y una aplicación cliente se cifran mediante la seguridad de la capa de transporte (TLS), anteriormente conocida como Capa de sockets seguros (SSL), en todo momento. SQL Database no admite conexiones sin cifrar. Para validar certificados con código de aplicación o herramientas, solicite explícitamente una conexión cifrada y no confíe en los certificados de servidor. Si el código o las herramientas de la aplicación no solicitan una conexión cifrada, seguirán recibiendo conexiones cifradas.

Sin embargo, es posible que no validen los certificados de servidor y, por tanto, serán susceptibles a ataques de intermediario. Para validar certificados con ADO.NET código de aplicación, establezca Encrypt=True y TrustServerCertificate=False en la cadena de conexión de la base de datos. Para validar certificados a través de SQL Server Management Studio, abra el cuadro de diálogo Conectar con el servidor. Haga clic en Cifrar conexión en la pestaña Propiedades de conexión.

Forzar la comunicación cifrada con SQL Server

Título Detalles
Componente Base de datos
Fase de SDL Construir
Tecnologías aplicables OnPrem
Atributos Versión de SQL: MsSQL2016, versión de SQL: MsSQL2012, versión de SQL: MsSQL2014
Referencias Habilitación de conexiones cifradas al motor de base de datos
Pasos Al habilitar el cifrado TLS aumenta la seguridad de los datos que se transmiten a través de redes entre instancias de SQL Server y las aplicaciones.

Asegúrese de que la comunicación con Azure Storage se realiza a través de HTTPS

Título Detalles
Componente Azure Storage
Fase de SDL Despliegue
Tecnologías aplicables Genérico
Atributos No disponible
Referencias Cifrado de Azure Storage Transport-Level: Uso de HTTPS
Pasos Para garantizar la seguridad de los datos de Azure Storage en tránsito, use siempre el protocolo HTTPS al llamar a las API REST o acceder a objetos en el almacenamiento. Además, las firmas de acceso compartido, que se pueden usar para delegar el acceso a objetos de Azure Storage, incluyen una opción para especificar que solo se puede usar el protocolo HTTPS al usar firmas de acceso compartido, lo que garantiza que cualquier persona que envíe vínculos con tokens de SAS usará el protocolo adecuado.

Validar el hash MD5 después de descargar el blob si no se puede habilitar HTTPS

Título Detalles
Componente Azure Storage
Fase de SDL Construir
Tecnologías aplicables Genérico
Atributos StorageType: blob
Referencias Introducción a Blob md5 de Windows Azure
Pasos

Blob service de Windows Azure proporciona mecanismos para garantizar la integridad de los datos tanto en las capas de aplicación como de transporte. Si por algún motivo necesita usar HTTP en lugar de HTTPS y está trabajando con blobs en bloques, puede usar la comprobación md5 para ayudar a comprobar la integridad de los blobs que se transfieren.

Esto ayudará a proteger los errores de la capa de red o transporte, pero no necesariamente con ataques intermedios. Si puede usar HTTPS, que proporciona seguridad de nivel de transporte, el uso de la comprobación md5 es redundante e innecesario.

Uso del cliente compatible con SMB 3.x para garantizar el cifrado de datos en tránsito a recursos compartidos de archivos de Azure

Título Detalles
Componente Cliente móvil
Fase de SDL Construir
Tecnologías aplicables Genérico
Atributos StorageType: archivo
Referencias Azure Files, compatibilidad con SMB de Azure Files para clientes Windows
Pasos Azure Files admite HTTPS cuando se usa la API REST, pero se usa con más frecuencia como un recurso compartido de archivos SMB asociado a una máquina virtual. SMB 2.1 no admite el cifrado, por lo que las conexiones solo se permiten dentro de la misma región de Azure. Sin embargo, SMB 3.x admite el cifrado y se puede usar con Windows Server 2012 R2, Windows 8, Windows 8.1 y Windows 10, lo que permite el acceso entre regiones e incluso el acceso en el escritorio.

Implementación de asignación de certificados

Título Detalles
Componente Azure Storage
Fase de SDL Construir
Tecnologías aplicables Genérico, Windows Phone
Atributos No disponible
Referencias Asignación de certificados y claves públicas
Pasos

La asignación de certificados protege frente a ataques de tipo "man in the middle". La asignación es el proceso de asociar un host a su certificado X509 o clave pública esperados. Una vez que se conoce o ve un certificado o una clave pública para un host, el certificado o la clave pública está asociado o "anclado" al host.

De este modo, cuando un atacante intenta realizar un ataque de tipo "man in the middle" TLS, durante el protocolo de enlace TLS, la clave del servidor del atacante será distinta a la clave del certificado asignado, por lo que la solicitud se descartará, lo que evita que pueda realizarse una asignación de certificados mediante ataque de tipo "man in the middle" al implementar el delegado ServerCertificateValidationCallback de ServicePointManager.

Ejemplo

using System;
using System.Net;
using System.Net.Security;
using System.Security.Cryptography;

namespace CertificatePinningExample
{
    class CertificatePinningExample
    {
        /* Note: In this example, we're hardcoding the certificate's public key and algorithm for 
           demonstration purposes. In a real-world application, this should be stored in a secure
           configuration area that can be updated as needed. */

        private static readonly string PINNED_ALGORITHM = "RSA";

        private static readonly string PINNED_PUBLIC_KEY = "3082010A0282010100B0E75B7CBE56D31658EF79B3A1" +
            "294D506A88DFCDD603F6EF15E7F5BCBDF32291EC50B2B82BA158E905FE6A83EE044A48258B07FAC3D6356AF09B2" +
            "3EDAB15D00507B70DB08DB9A20C7D1201417B3071A346D663A241061C151B6EC5B5B4ECCCDCDBEA24F051962809" +
            "FEC499BF2D093C06E3BDA7D0BB83CDC1C2C6660B8ECB2EA30A685ADE2DC83C88314010FFC7F4F0F895EDDBE5C02" +
            "ABF78E50B708E0A0EB984A9AA536BCE61A0C31DB95425C6FEE5A564B158EE7C4F0693C439AE010EF83CA8155750" +
            "09B17537C29F86071E5DD8CA50EBD8A409494F479B07574D83EDCE6F68A8F7D40447471D05BC3F5EAD7862FA748" +
            "EA3C92A60A128344B1CEF7A0B0D94E50203010001";


        public static void Main(string[] args)
        {
            HttpWebRequest request = (HttpWebRequest)WebRequest.Create("https://azure.microsoft.com");
            request.ServerCertificateValidationCallback = (sender, certificate, chain, sslPolicyErrors) =>
            {
                if (certificate == null || sslPolicyErrors != SslPolicyErrors.None)
                {
                    // Error getting certificate or the certificate failed basic validation
                    return false;
                }

                var targetKeyAlgorithm = new Oid(certificate.GetKeyAlgorithm()).FriendlyName;
                var targetPublicKey = certificate.GetPublicKeyString();
                
                if (targetKeyAlgorithm == PINNED_ALGORITHM &&
                    targetPublicKey == PINNED_PUBLIC_KEY)
                {
                    // Success, the certificate matches the pinned value.
                    return true;
                }
                // Reject, either the key or the algorithm does not match the expected value.
                return false;
            };

            try
            {
                var response = (HttpWebResponse)request.GetResponse();
                Console.WriteLine($"Success, HTTP status code: {response.StatusCode}");
            }
            catch(Exception ex)
            {
                Console.WriteLine($"Failure, {ex.Message}");
            }
            Console.WriteLine("Press any key to end.");
            Console.ReadKey();
        }
    }
}

Habilitación de HTTPS: canal de transporte seguro

Título Detalles
Componente WCF (Windows Communication Foundation)
Fase de SDL Construir
Tecnologías aplicables NET Framework 3
Atributos No disponible
Referencias MSDN, Fortify Kingdom
Pasos La configuración de la aplicación debe asegurarse de que HTTPS se usa para todo el acceso a la información confidencial.
  • EXPLICACIÓN: Si una aplicación controla la información confidencial y no usa el cifrado de nivel de mensaje, solo debe permitirse comunicarse a través de un canal de transporte cifrado.
  • RECOMENDACIONES: Asegúrese de que el transporte HTTP está deshabilitado y habilite el transporte HTTPS en su lugar. Por ejemplo, reemplace la etiqueta <httpTransport/> con la etiqueta <httpsTransport/>. No confíe en una configuración de red (firewall) para garantizar que solo se pueda acceder a la aplicación a través de un canal seguro. Desde un punto de vista filósofo, la aplicación no debe depender de la red para su seguridad.

Desde un punto de vista práctico, las personas responsables de proteger la red no siempre realizan un seguimiento de los requisitos de seguridad de la aplicación a medida que evolucionan.

WCF: establezca el nivel de protección de seguridad de mensajes en EncryptAndSign.

Título Detalles
Componente WCF (Windows Communication Foundation)
Fase de SDL Construir
Tecnologías aplicables .NET Framework 3
Atributos No disponible
Referencias msdn
Pasos
  • EXPLICACIÓN: Cuando el nivel de protección se establece en "none", deshabilitará la protección de mensajes. La confidencialidad y la integridad se logran con el nivel de configuración adecuado.
  • RECOMENDACIONES:
    • when Mode=None : deshabilita la protección de mensajes
    • cuando Mode=Sign : firma pero no cifra el mensaje; debe usarse cuando la integridad de los datos sea importante.
    • when Mode=EncryptAndSign : firma y cifra el mensaje

Considere la posibilidad de desactivar el cifrado y firmar solo el mensaje cuando solo necesite validar la integridad de la información sin preocuparse de la confidencialidad. Esto puede ser útil para operaciones o contratos de servicio en los que necesita validar el remitente original, pero no se transmite ningún dato confidencial. Al reducir el nivel de protección, tenga cuidado de que el mensaje no contenga ningún dato personal.

Ejemplo

La configuración del servicio y la operación para firmar solo el mensaje se muestra en los ejemplos siguientes. Ejemplo de contrato de servicio de ProtectionLevel.Sign: a continuación se muestra un ejemplo de uso de ProtectionLevel.Sign en el nivel contrato de servicio:

[ServiceContract(Protection Level=ProtectionLevel.Sign] 
public interface IService 
  { 
  string GetData(int value); 
  }

Ejemplo

Ejemplo de contrato de operación de ProtectionLevel.Sign (para control granular): a continuación se muestra un ejemplo de uso ProtectionLevel.Sign en el nivel OperationContract:

[OperationContract(ProtectionLevel=ProtectionLevel.Sign] 
string GetData(int value);

WCF: usar una cuenta con privilegios mínimos para ejecutar el servicio WCF

Título Detalles
Componente WCF (Windows Communication Foundation)
Fase de SDL Construir
Tecnologías aplicables .NET Framework 3
Atributos No disponible
Referencias msdn
Pasos
  • EXPLICACIÓN: No ejecute servicios WCF en una cuenta de administrador o con privilegios elevados. Esto tendría una gran incidencia en caso de que los servicios se vieran comprometidos.
  • RECOMENDACIONES: Use una cuenta con privilegios mínimos para hospedar el servicio WCF, ya que reducirá la superficie expuesta a ataques de la aplicación y reducirá el posible daño si se le ataca. Si la cuenta de servicio requiere derechos de acceso adicionales en recursos de infraestructura como MSMQ, el registro de eventos, los contadores de rendimiento y el sistema de archivos, se deben conceder permisos adecuados a estos recursos para que el servicio WCF pueda ejecutarse correctamente.

Si su servicio necesita acceder a recursos específicos en nombre del autor de la llamada original, utilice la suplantación y la delegación para transferir la identidad del autor de la llamada y realizar una comprobación de autorización en un sistema descendente. En un escenario de desarrollo, use la cuenta de servicio de red local, que es una cuenta integrada especial que tiene privilegios reducidos. En un escenario de producción, cree una cuenta de servicio de dominio personalizado con privilegios mínimos.

Direccionamiento forzoso de todo el tráfico a API web a través de una conexión HTTPS

Título Detalles
Componente API de la Web
Fase de SDL Construir
Tecnologías aplicables MVC5, MVC6
Atributos No disponible
Referencias Aplicación de SSL en un controlador de API web
Pasos Si una aplicación tiene un enlace HTTPS y HTTP, los clientes pueden seguir usando HTTP para acceder al sitio. Para evitar esto, use un filtro de acciones para asegurarse de que las solicitudes a las API protegidas siempre se realizan a través de HTTPS.

Ejemplo

En el código siguiente se muestra un filtro de autenticación de API web que comprueba tls:

public class RequireHttpsAttribute : AuthorizationFilterAttribute
{
    public override void OnAuthorization(HttpActionContext actionContext)
    {
        if (actionContext.Request.RequestUri.Scheme != Uri.UriSchemeHttps)
        {
            actionContext.Response = new HttpResponseMessage(System.Net.HttpStatusCode.Forbidden)
            {
                ReasonPhrase = "HTTPS Required"
            };
        }
        else
        {
            base.OnAuthorization(actionContext);
        }
    }
}

Agregue este filtro a cualquier acción de API web que requiera TLS:

public class ValuesController : ApiController
{
    [RequireHttps]
    public HttpResponseMessage Get() { ... }
}

Asegúrese de que la comunicación con Azure Cache for Redis se realiza a través de TLS

Título Detalles
Componente Caché de Azure para Redis
Fase de SDL Construir
Tecnologías aplicables Genérico
Atributos No disponible
Referencias Compatibilidad con TLS de Azure Redis
Pasos El servidor de Redis no admite TLS de forma predeterminada, pero Azure Cache for Redis sí. Si se conecta a Azure Cache for Redis y el cliente admite TLS, como StackExchange.Redis, debe usar TLS. De forma predeterminada, el puerto que no es TLS está deshabilitado para las nuevas instancias de Azure Cache for Redis. Asegúrese de que los valores predeterminados seguros no se cambian a menos que haya una dependencia de la compatibilidad con TLS para los clientes de Redis.

Tenga en cuenta que Redis está diseñado para que los clientes de confianza accedan a ellos dentro de entornos de confianza. Esto significa que normalmente no es una buena idea exponer la instancia de Redis directamente a Internet o, en general, a un entorno en el que los clientes que no son de confianza pueden acceder directamente al puerto TCP de Redis o al socket UNIX.

Comunicación segura de dispositivo a pasarela de campo

Título Detalles
Componente Puerta de enlace de campo de IoT
Fase de SDL Construir
Tecnologías aplicables Genérico
Atributos No disponible
Referencias No disponible
Pasos En el caso de los dispositivos basados en IP, el protocolo de comunicación normalmente se podría encapsular en un canal SSL/TLS para proteger los datos en tránsito. Para otros protocolos que no admiten SSL/TLS, investigue si hay versiones seguras del protocolo que proporcionan seguridad en el nivel de transporte o mensaje.

Protección de la comunicación de dispositivo a puerta de enlace en la nube mediante SSL/TLS

Título Detalles
Componente Puerta de enlace de la nube de IoT
Fase de SDL Construir
Tecnologías aplicables Genérico
Atributos No disponible
Referencias Elegir el protocolo de comunicación
Pasos Proteja los protocolos HTTP/AMQP o MQTT mediante SSL/TLS.
  • Last updated on