Partager via

Cadre de sécurité : Sécurité des communications | Atténuation

Produit/Service Article
Azure Event Hub
Dynamics CRM
Azure Data Factory.
Serveur d’identité
Application Web
Base de données
Stockage Azure
Client mobile
WCF
API web
Cache Azure pour Redis
Passerelle locale IoT
Passerelle de cloud IoT

Sécuriser la communication avec Event Hub à l’aide de SSL/TLS

Titre Détails
Composant Azure Event Hub
Phase SDL Construire
Technologies applicables Générique
Attributs N/A
Informations de référence Présentation du modèle de sécurité et de l’authentification Event Hubs
Étapes Sécuriser les connexions AMQP ou HTTP à Event Hub à l’aide de SSL/TLS

Vérifiez les privilèges du compte de service et vérifiez que les services personnalisés ou les pages ASP.NET respectent la sécurité de CRM

Titre Détails
Composant Dynamics CRM
Phase SDL Construire
Technologies applicables Générique
Attributs N/A
Informations de référence N/A
Étapes Vérifiez les privilèges du compte de service et vérifiez que les services personnalisés ou les pages ASP.NET respectent la sécurité de CRM

Utiliser la passerelle de gestion des données lors de la connexion de SQL Server local à Azure Data Factory

Titre Détails
Composant Azure Data Factory.
Phase SDL Déploiement
Technologies applicables Générique
Attributs Types de services liés - Azure et local
Informations de référence Déplacement de données entre local et Azure Data Factory
Étapes

L’outil de passerelle de gestion des données (DMG) est requis pour se connecter aux sources de données qui sont protégées derrière un réseau d’entreprise ou un pare-feu.

  1. Le verrouillage de la machine isole l’outil de passerelle de gestion des données et empêche les programmes ne fonctionnant pas correctement d’endommager la machine hébergeant les sources de données ou d’espionner celle-ci. (Par exemple, les dernières mises à jour doivent être installées, activer les ports minimum requis, l’approvisionnement de comptes contrôlés, l’audit activé, le chiffrement de disque activé, etc.)
  2. La clé de passerelle de données doit être pivotée à intervalles fréquents ou chaque fois que le mot de passe du compte de service DMG se renouvelle
  3. Les transits de données via le service de liaison doivent être chiffrés

Vérifiez que tout le trafic vers Identity Server est sur la connexion HTTPS

Titre Détails
Composant Serveur d’identité
Phase SDL Déploiement
Technologies applicables Générique
Attributs N/A
Informations de référence N/A
Étapes Par défaut, IdentityServer nécessite que toutes les connexions entrantes proviennent du protocole HTTPS. Il est absolument obligatoire que la communication avec IdentityServer soit effectuée uniquement sur les transports sécurisés. Il existe certains scénarios de déploiement tels que le déchargement TLS où cette exigence peut être assouplie. Consultez la page de déploiement identity Server dans les références pour plus d’informations.

Vérifier les certificats X.509 utilisés pour authentifier les connexions SSL, TLS et DTLS

Titre Détails
Composant Application web
Phase SDL Construire
Technologies applicables Générique
Attributs N/A
Informations de référence N/A
Étapes

Les applications qui utilisent SSL, TLS ou DTLS doivent vérifier entièrement les certificats X.509 des entités auxquelles ils se connectent. Cela inclut la vérification des certificats pour :

  • Nom de domaine
  • Dates de validité (dates de début et d’expiration)
  • État de révocation
  • Utilisation (par exemple, Authentification du serveur pour les serveurs, Authentification du client pour les clients)
  • Chaîne de confiance. Les certificats doivent être chaînés à une autorité de certification racine approuvée par la plateforme ou configurée explicitement par l’administrateur
  • La longueur de clé de la clé publique du certificat doit être >de 2 048 bits
  • L’algorithme de hachage doit être SHA256 et ultérieur

Configurer un certificat TLS/SSL pour un domaine personnalisé dans Azure App Service

Titre Détails
Composant Application web
Phase SDL Construire
Technologies applicables Générique
Attributs EnvironmentType – Azure
Informations de référence Activer HTTPS pour une application dans Azure App Service
Étapes Par défaut, Azure active déjà HTTPS pour chaque application avec un certificat générique pour le domaine *.azurewebsites.net. Toutefois, comme tous les domaines génériques, il n’est pas aussi sécurisé que l’utilisation d’un domaine personnalisé avec un propre certificat Référence. Il est recommandé d’activer TLS pour le domaine personnalisé auquel l’application déployée sera accessible via

Forcer tout le trafic vers Azure App Service via la connexion HTTPS

Titre Détails
Composant Application web
Phase SDL Construire
Technologies applicables Générique
Attributs EnvironmentType – Azure
Informations de référence Appliquer HTTPS sur Azure App Service
Étapes

Bien qu’Azure active déjà HTTPS pour les services d’application Azure avec un certificat générique pour le domaine *.azurewebsites.net, il n’applique pas HTTPS. Les visiteurs peuvent toujours accéder à l’application à l’aide de HTTP, ce qui peut compromettre la sécurité de l’application et, par conséquent, HTTPS doit être appliqué explicitement. ASP.NET applications MVC doivent utiliser le filtre RequireHttps qui force une requête HTTP non sécurisée à renvoyer via HTTPS.

Vous pouvez également utiliser le module de réécriture d’URL inclus dans Azure App Service pour appliquer HTTPS. Le module de réécriture d’URL permet aux développeurs de définir des règles appliquées aux requêtes entrantes avant que les demandes ne soient transmises à votre application. Les règles de réécriture d’URL sont définies dans un fichier web.config stocké à la racine de l’application

Exemple :

L’exemple suivant contient une règle de réécriture d’URL de base qui force tout le trafic entrant à utiliser 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>

Cette règle fonctionne en retournant un code d’état HTTP de 301 (redirection permanente) lorsque l’utilisateur demande une page à l’aide de HTTP. Le 301 redirige la requête vers la même URL que celle demandée par le visiteur, mais remplace la partie HTTP de la requête par HTTPS. Par exemple, HTTP://contoso.com serait redirigé vers HTTPS://contoso.com.

Activer HTTP Strict Transport Security (HSTS)

Titre Détails
Composant Application web
Phase SDL Construire
Technologies applicables Générique
Attributs N/A
Informations de référence Aide-mémoire OWASP HTTP Strict Transport Security
Étapes

HTTP Strict Transport Security (HSTS) est une amélioration de sécurité d’opt-in spécifiée par une application web à l’aide d’un en-tête de réponse spécial. Une fois qu’un navigateur pris en charge reçoit cet en-tête que le navigateur empêche toute communication envoyée via HTTP au domaine spécifié et envoie à la place toutes les communications via HTTPS. Il empêche également les invites de clic HTTPS dans les navigateurs.

Pour implémenter HSTS, l’en-tête de réponse suivant doit être configuré pour un site web globalement, dans le code ou dans la configuration. Strict-Transport-Security : max-age=300 ; includeSubDomains HSTS traite les menaces suivantes :

  • L'utilisateur utilise des signets ou saisit manuellement https://example.com et s'expose à un attaquant de type man-in-the-middle : HSTS redirige automatiquement les requêtes HTTP vers HTTPS pour le domaine cible.
  • L’application web destinée à être purement HTTPS contient par inadvertance des liens HTTP ou sert du contenu via HTTP : HSTS redirige automatiquement les requêtes HTTP vers HTTPS pour le domaine cible
  • Un attaquant intermédiaire tente d’intercepter le trafic d’un utilisateur victime à l’aide d’un certificat non valide et espère que l’utilisateur acceptera le certificat incorrect : HSTS ne permet pas à un utilisateur de remplacer le message de certificat non valide

Vérifier le chiffrement de la connexion sql server et la validation des certificats

Titre Détails
Composant Base de données
Phase SDL Construire
Technologies applicables SQL Azure
Attributs Version SQL - V12
Informations de référence Meilleures pratiques relatives à l’écriture de chaînes de connexion sécurisées pour SQL Database
Étapes

Toutes les communications entre SQL Database et une application cliente sont chiffrées à l’aide du protocole TLS (Transport Layer Security), précédemment appelée SSL (Secure Sockets Layer), à tout moment. SQL Database ne prend pas en charge les connexions non chiffrées. Pour valider des certificats avec du code ou des outils d’application, demandez explicitement une connexion chiffrée et n’approuvez pas les certificats de serveur. Si le code ou les outils de votre application ne demandent pas de connexion chiffrée, ils reçoivent toujours des connexions chiffrées.

Toutefois, ils peuvent ne pas valider les certificats de serveur et seront donc susceptibles aux attaques de l'homme du milieu. Pour valider des certificats avec ADO.NET code d’application, définissez Encrypt=True et TrustServerCertificate=False dans la chaîne de connexion de base de données. Pour valider des certificats via SQL Server Management Studio, ouvrez la boîte de dialogue Se connecter au serveur. Cliquez sur Chiffrer la connexion sous l’onglet Propriétés de connexion

Forcer la communication chiffrée vers SQL Server

Titre Détails
Composant Base de données
Phase SDL Construire
Technologies applicables Local
Attributs Version SQL - MsSQL2016, Version SQL - MsSQL2012, Version SQL - MsSQL2014
Informations de référence Activer les connexions chiffrées au moteur de base de données
Étapes L’activation du chiffrement TLS améliore la sécurité des données transmises sur des réseaux entre des instances de SQL Server et des applications.

Vérifiez que la communication avec stockage Azure est sur HTTPS

Titre Détails
Composant Stockage Azure
Phase SDL Déploiement
Technologies applicables Générique
Attributs N/A
Informations de référence Chiffrement Transport-Level stockage Azure : utilisation du protocole HTTPS
Étapes Pour garantir la sécurité des données de stockage Azure en transit, utilisez toujours le protocole HTTPS lors de l’appel des API REST ou de l’accès aux objets dans le stockage. En outre, les signatures d’accès partagé, qui peuvent être utilisées pour déléguer l’accès aux objets stockage Azure, incluent une option permettant de spécifier que seul le protocole HTTPS peut être utilisé lors de l’utilisation des signatures d’accès partagé, ce qui garantit que toute personne envoyant des liens avec des jetons SAP utilisera le protocole approprié.

Valider le hachage MD5 après le téléchargement de blobs si le protocole HTTPS ne peut pas être activé

Titre Détails
Composant Stockage Azure
Phase SDL Construire
Technologies applicables Générique
Attributs StorageType – Blob
Informations de référence Vue d’ensemble de Windows Azure Blob MD5
Étapes

Le service Blob Windows Azure fournit des mécanismes pour garantir l’intégrité des données à la fois dans les couches d’application et de transport. Si, pour une raison quelconque, vous devez utiliser HTTP au lieu de HTTPS et que vous utilisez des objets blob de blocs, vous pouvez utiliser la vérification MD5 pour vérifier l’intégrité des objets blob transférés

Cela permet de protéger contre les erreurs de couche réseau/transport, mais pas nécessairement avec les attaques intermédiaires. Si vous pouvez utiliser HTTPS, qui fournit une sécurité au niveau du transport, l’utilisation de la vérification MD5 est redondante et inutile.

Utiliser le client compatible SMB 3.x pour garantir le chiffrement des données en transit vers des partages de fichiers Azure

Titre Détails
Composant Client mobile
Phase SDL Construire
Technologies applicables Générique
Attributs StorageType - Fichier
Informations de référence Azure Files, Prise en charge SMB d’Azure Files pour les clients Windows
Étapes Azure Files prend en charge HTTPS lors de l’utilisation de l’API REST, mais est plus couramment utilisé comme partage de fichiers SMB attaché à une machine virtuelle. SMB 2.1 ne prend pas en charge le chiffrement. Par conséquent, les connexions sont autorisées uniquement dans la même région dans Azure. Toutefois, SMB 3.x prend en charge le chiffrement et peut être utilisé avec Windows Server 2012 R2, Windows 8, Windows 8.1 et Windows 10, ce qui autorise l’accès interrégion et même l’accès sur le bureau.

Implémenter l’épinglage de certificat

Titre Détails
Composant Stockage Azure
Phase SDL Construire
Technologies applicables Générique, Windows Phone
Attributs N/A
Informations de référence Certificate and Public Key Pinning (Épinglage de clé publique et de certificat)
Étapes

L’épinglage de certificat assure une protection contre les attaques d’intercepteur (MITM). L’épinglage consiste à associer un hôte à sa clé publique ou à son certificat X509 attendus. Une fois qu’un certificat ou une clé publique est connu ou visible pour un hôte, le certificat ou la clé publique est associé ou « épinglé » à l’hôte.

Par conséquent, lorsqu’une personne mal intentionnée tente une attaque MITM TLS, lors de la liaison TLS, la clé du serveur de l’attaquant sera différente de la clé du certificat épinglé et la demande sera ignorée, empêchant ainsi l’attaque MITM. L’épinglage de certificat peut être obtenu en implémentant le délégué ServerCertificateValidationCallback de ServicePointManager.

Exemple :

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();
        }
    }
}

Activer HTTPS - Canal de transport sécurisé

Titre Détails
Composant WCF (Windows Communication Foundation)
Phase SDL Construire
Technologies applicables NET Framework 3
Attributs N/A
Informations de référence MSDN, Fortify Kingdom
Étapes La configuration de l’application doit s’assurer que HTTPS est utilisé pour tous les accès aux informations sensibles.
  • EXPLICATION: Si une application gère les informations sensibles et n’utilise pas le chiffrement au niveau du message, elle doit uniquement être autorisée à communiquer via un canal de transport chiffré.
  • RECOMMANDATIONS: Vérifiez que le transport HTTP est désactivé et activez plutôt le transport HTTPS. Par exemple, remplacez la balise <httpTransport/> par la balise <httpsTransport/>. Ne vous fiez pas à une configuration réseau (pare-feu) pour garantir que l’application est accessible uniquement via un canal sécurisé. D’un point de vue philosophique, l’application ne doit pas dépendre du réseau pour sa sécurité.

Du point de vue pratique, les personnes responsables de la sécurisation du réseau ne suivent pas toujours les exigences de sécurité de l’application au fur et à mesure qu’elles évoluent.

WCF : Définir le niveau de protection de la sécurité des messages sur EncryptAndSign

Titre Détails
Composant WCF (Windows Communication Foundation)
Phase SDL Construire
Technologies applicables .NET Framework 3
Attributs N/A
Informations de référence MSDN
Étapes
  • EXPLICATION: Lorsque le niveau de protection est défini sur « none », il désactive la protection des messages. La confidentialité et l’intégrité sont obtenues avec le niveau de définition approprié.
  • RECOMMANDATIONS:
    • quand Mode=None - Désactive la protection des messages
    • quand Mode=Sign - Signes mais ne chiffre pas le message ; doit être utilisé lorsque l’intégrité des données est importante
    • quand Mode=EncryptAndSign - Signe et chiffre le message

Envisagez de désactiver le chiffrement et de signer uniquement votre message lorsque vous venez de valider l’intégrité des informations sans souci de confidentialité. Cela peut être utile pour les opérations ou les contrats de service dans lesquels vous devez valider l’expéditeur d’origine, mais aucune donnée sensible n’est transmise. Lorsque vous réduisez le niveau de protection, veillez à ce que le message ne contienne aucune donnée personnelle.

Exemple :

La configuration du service et de l’opération pour signer uniquement le message s’affiche dans les exemples suivants. Exemple de contrat de service : ProtectionLevel.Signvoici un exemple d’utilisation de ProtectionLevel.Sign au niveau du contrat de service :

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

Exemple :

Exemple de contrat d’opération ( ProtectionLevel.Sign pour le contrôle granulaire) : voici un exemple d’utilisation ProtectionLevel.Sign au niveau OperationContract :

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

WCF : Utiliser un compte avec privilèges minimum pour exécuter votre service WCF

Titre Détails
Composant WCF (Windows Communication Foundation)
Phase SDL Construire
Technologies applicables .NET Framework 3
Attributs N/A
Informations de référence MSDN
Étapes
  • EXPLICATION: N’exécutez pas les services WCF sous un compte d’administrateur ou de privilège élevé. en cas de compromission des services, cela entraînera un impact élevé.
  • RECOMMANDATIONS: Utilisez un compte à privilèges minimum pour héberger votre service WCF, car il réduit la surface d’attaque de votre application et réduit les dommages potentiels si vous êtes attaqué. Si le compte de service nécessite des droits d’accès supplémentaires sur les ressources d’infrastructure telles que MSMQ, le journal des événements, les compteurs de performances et le système de fichiers, les autorisations appropriées doivent être accordées à ces ressources afin que le service WCF puisse s’exécuter correctement.

Si votre service doit accéder à des ressources spécifiques pour le compte de l’appelant d’origine, utilisez l’emprunt d’identité et la délégation pour transmettre l’identité de l’appelant pour une vérification d’autorisation en aval. Dans un scénario de développement, utilisez le compte de service de réseau local, qui est un compte intégré spécial qui a des privilèges réduits. Dans un scénario de production, créez un compte de service de domaine personnalisé avec des privilèges minimum.

Forcer tout le trafic vers les API web via la connexion HTTPS

Titre Détails
Composant Web API
Phase SDL Construire
Technologies applicables MVC5, MVC6
Attributs N/A
Informations de référence Application du protocole SSL dans un contrôleur d’API web
Étapes Si une application a à la fois une liaison HTTPS et HTTP, les clients peuvent toujours utiliser HTTP pour accéder au site. Pour éviter cela, utilisez un filtre d’action pour vous assurer que les demandes adressées aux API protégées sont toujours sur HTTPS.

Exemple :

Le code suivant montre un filtre d’authentification d’API web qui recherche 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);
        }
    }
}

Ajoutez ce filtre à toutes les actions d’API web qui nécessitent TLS :

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

Vérifiez que la communication avec Le Cache Azure pour Redis est sur TLS

Titre Détails
Composant Cache Azure pour Redis
Phase SDL Construire
Technologies applicables Générique
Attributs N/A
Informations de référence Prise en charge de TLS par Azure Redis
Étapes Le serveur Redis ne prend pas en charge TLS hors connexion, mais le Cache Azure pour Redis le fait. Si vous vous connectez à Azure Cache pour Redis et que votre client prend en charge TLS, comme StackExchange.Redis, vous devez utiliser TLS. Par défaut, le port non TLS est désactivé pour les nouvelles instances du Cache Azure pour Redis. Assurez-vous que les valeurs par défaut sécurisées ne sont pas modifiées sauf s’il existe une dépendance sur la prise en charge TLS pour les clients Redis.

Notez que Redis est conçu pour être accessible par des clients approuvés dans des environnements approuvés. Cela signifie qu’il n’est généralement pas judicieux d’exposer l’instance Redis directement à Internet ou, en général, à un environnement dans lequel les clients non approuvés peuvent accéder directement au port TCP Redis ou au socket UNIX.

Sécuriser la communication entre l’appareil et la passerelle locale

Titre Détails
Composant Passerelle locale IoT
Phase SDL Construire
Technologies applicables Générique
Attributs N/A
Informations de référence N/A
Étapes Pour les appareils ip, le protocole de communication peut généralement être encapsulé dans un canal SSL/TLS pour protéger les données en transit. Pour les autres protocoles qui ne prennent pas en charge SSL/TLS, examinez s’il existe des versions sécurisées du protocole qui fournissent la sécurité au niveau du transport ou de la couche de messages.

Sécuriser la communication d’appareil à passerelle cloud à l’aide de SSL/TLS

Titre Détails
Composant Passerelle cloud IoT
Phase SDL Construire
Technologies applicables Générique
Attributs N/A
Informations de référence Choisir votre protocole de communication
Étapes Sécuriser les protocoles HTTP/AMQP ou MQTT à l’aide de SSL/TLS.
  • Last updated on