Partager via

Considérations relatives à la sécurité dans gRPC pour ASP.NET Core

  • Article

Remarque

Ceci n’est pas la dernière version de cet article. Pour la version actuelle, consultez la version .NET 9 de cet article.

Avertissement

Cette version d’ASP.NET Core n’est plus prise en charge. Pour plus d’informations, consultez la stratégie de support .NET et .NET Core. Pour la version actuelle, consultez la version .NET 9 de cet article.

Important

Ces informations portent sur la préversion du produit, qui est susceptible d’être en grande partie modifié avant sa commercialisation. Microsoft n’offre aucune garantie, expresse ou implicite, concernant les informations fournies ici.

Pour la version actuelle, consultez la version .NET 9 de cet article.

Par James Newton-King

Cet article fournit des informations pour sécuriser gRPC avec .NET Core.

Sécurité du transport

Les messages gRPC sont envoyés et reçus à l’aide de HTTP/2. Nous recommandons les actions suivantes :

  • TLS (Transport Layer Security) est utilisé pour sécuriser les messages dans les applications gRPC de production.
  • Les services gRPC doivent uniquement écouter et répondre sur des ports sécurisés.

TLS est configuré dans Kestrel. Pour plus d’informations sur la configuration des points de terminaison Kestrel, consultez Configuration des points de terminaison Kestrel.

TLS est configuré dans Kestrel. Pour plus d’informations sur la configuration des points de terminaison Kestrel, consultez Configuration des points de terminaison Kestrel.

Un proxy de terminaison TLS peut être combiné avec TLS. Les avantages de l’utilisation de la terminaison TLS doivent être pris en compte par rapport aux risques de sécurité liés à l’envoi de requêtes HTTP non sécurisées entre des applications du réseau privé.

Exceptions

Les messages d’exception sont généralement considérés comme des données sensibles qui ne doivent pas être révélées à un client. Par défaut, gRPC n’envoie pas les détails d’une exception levée par un service gRPC au client. Au lieu de cela, le client reçoit un message générique indiquant qu’une erreur s’est produite. La remise de messages d’exception au client peut être remplacée (par exemple, en développement ou en test) par EnableDetailedErrors. Les messages d’exception ne doivent pas être exposés au client dans les applications de production.

Limites de taille des messages

Les messages entrants aux clients et services gRPC sont chargés en mémoire. Les limites de taille des messages sont un mécanisme permettant d’empêcher gRPC de consommer des ressources excessives.

gRPC utilise des limites de taille par message pour gérer les messages entrants et sortants. Par défaut, gRPC limite les messages entrants à 4 Mo. Il n’existe aucune limite pour les messages sortants.

Sur le serveur, les limites de messages gRPC peuvent être configurées pour tous les services d’une application avec AddGrpc :

public void ConfigureServices(IServiceCollection services)
{
    services.AddGrpc(options =>
    {
        options.MaxReceiveMessageSize = 1 * 1024 * 1024; // 1 MB
        options.MaxSendMessageSize = 1 * 1024 * 1024; // 1 MB
    });
}

Les limites peuvent également être configurées pour un service individuel à l’aide de AddServiceOptions<TService>. Pour plus d’informations sur la configuration des limites de taille des messages, consultez Configuration de gRPC.

Validation du certificat client

Les certificats clients sont initialement validés lorsque la connexion est établie. Par défaut, Kestrel n’effectue pas de validation supplémentaire du certificat client d’une connexion.

Nous recommandons que les services gRPC sécurisés par des certificats clients utilisent le package Microsoft.AspNetCore.Authentication.Certificate. L’authentification de certification ASP.NET Core effectue une validation supplémentaire sur un certificat client, en vérifiant notamment :

  • Que le certificat a une utilisation de clé étendue (EKU) valide
  • Qu’il est dans sa période de validité
  • Sa révocation