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

• Sécuriser la communication avec 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

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

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

• Vérifier les certificats X.509 utilisés pour authentifier les connexions SSL, TLS et DTLS
• Configurer un certificat TLS/SSL pour un domaine personnalisé dans Azure App Service
• Forcer tout le trafic vers Azure App Service sur une connexion HTTPS
• Activer HTTP Strict Transport Security (HSTS)

• Vérifier le chiffrement de la connexion sql server et la validation des certificats
• Forcer des communications chiffrées vers SQL Server

• Vérifiez que la communication avec stockage Azure est sur HTTPS
• Valider le hachage MD5 après le téléchargement de blobs si le protocole HTTPS ne peut pas être activé
• Utiliser le client compatible SMB 3.0 pour garantir le chiffrement des données en transit vers des partages de fichiers Azure

• Implémenter l’épinglage de certificat

• Activer HTTPS - Canal de transport sécurisé
• WCF : Définir le niveau de protection de la sécurité des messages sur EncryptAndSign
• WCF : Utiliser un compte avec privilèges minimum pour exécuter votre service WCF

• Forcer tout le trafic vers les API web à passer par une connexion HTTPS

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

• Sécuriser la communication de périphérique à passerelle de terrain

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

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

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

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

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

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

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.

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.

• 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.

• 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.

• 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.