Communication entre processus avec gRPC

Les processus exécutés sur le même ordinateur peuvent être conçus pour communiquer entre eux. Les systèmes d’exploitation fournissent des technologies permettant une communication entre processus (IPC) rapide et efficace. Les sockets de domaine Unix et les canaux nommés sont des exemples populaires de technologies IPC.

.NET prend en charge la communication entre processus à l’aide de gRPC.

La prise en charge intégrée des canaux nommés dans ASP.NET Core nécessite .NET 8 ou version ultérieure.

Prise en main

Les appels IPC sont envoyés d’un client à un serveur. Pour communiquer entre les applications sur un ordinateur avec gRPC, au moins une application doit héberger un serveur gRPC ASP.NET Core.

Un serveur gRPC principal ASP.NET est généralement créé à partir du modèle gRPC. Le fichier projet créé par le modèle utilise Microsoft.NET.SDK.Web comme SDK :

<Project Sdk="Microsoft.NET.Sdk.Web">

  <ItemGroup>
    <PackageReference Include="Grpc.AspNetCore" Version="2.47.0" />
    <Protobuf Include="Protos\greet.proto" GrpcServices="Server" />
  </ItemGroup>

</Project>

La valeur du Kit de développement logiciel (SDK) Microsoft.NET.SDK.Web ajoute automatiquement une référence à l’infrastructure ASP.NET Core. La référence permet à l’application d’utiliser ASP.NET types Core requis pour héberger un serveur.

Il est également possible d'ajouter un serveur à des projets non-ASP.NET Core existants, tels que les services Windows, les applications WPF ou les applications WinForms. Consultez Héberger gRPC dans des projets non-ASP.NET Core pour plus d’informations.

Transports de communication entre processus (IPC)

Les appels gRPC entre un client et un serveur sur différents ordinateurs sont généralement envoyés via des sockets TCP. TCP est un bon choix pour communiquer sur un réseau ou sur Internet. Cependant, les transports IPC offrent des avantages lors de la communication entre des processus sur la même machine :

• Moins de travail supplémentaire et des vitesses de transfert plus rapides.
• Intégration aux fonctionnalités de sécurité du système d’exploitation.
• N’utilise pas de ports TCP, qui sont une ressource limitée.

.NET prend en charge plusieurs transports IPC :

• Les sockets de domaine Unix (UDS) sont une technologie IPC largement prise en charge. UDS est le meilleur choix pour créer des applications multiplateformes, et il est utilisable sur Linux, macOS et Windows 10/Windows Server 2019 ou version ultérieure.
• Les canaux nommés sont pris en charge par toutes les versions de Windows. Les canaux nommés s’intègrent bien à la sécurité Windows, qui peut être utilisée pour contrôler l’accès du client au canal.
• Des transports IPC supplémentaires en implémentant IConnectionListenerFactory et en inscrivant l’implémentation au démarrage de l’application.

Selon le système d’exploitation, les applications multiplateformes peuvent choisir différents transports IPC. Une application peut vérifier le système d’exploitation au démarrage et choisir le transport souhaité pour cette plateforme :

var builder = WebApplication.CreateBuilder(args);
builder.WebHost.ConfigureKestrel(serverOptions =>
{
    if (OperatingSystem.IsWindows())
    {
        serverOptions.ListenNamedPipe("MyPipeName");
    }
    else
    {
        var socketPath = Path.Combine(Path.GetTempPath(), "socket.tmp");
        serverOptions.ListenUnixSocket(socketPath);
    }

    serverOptions.ConfigureEndpointDefaults(listenOptions =>
    {
        listenOptions.Protocols = HttpProtocols.Http2;
    });
});

Considérations de sécurité

Les applications IPC envoient et reçoivent des appels RPC. La communication externe est un vecteur d’attaque potentiel pour les applications IPC et doit être correctement sécurisée.

Sécuriser l’application serveur IPC sur les appelants inattendus

L’application serveur IPC héberge les services RPC pour que d’autres applications appellent. Les appelants entrants doivent être authentifiés pour empêcher les clients non approuvés d’effectuer des appels RPC au serveur.

La sécurité du transport est une option pour sécuriser un serveur. Les transports IPC, comme les sockets de domaine Unix et les canaux nommés, prennent en charge la limitation de l’accès en fonction des autorisations du système d’exploitation :

• Les canaux nommés prennent en charge la sécurisation d’un canal avec le modèle de contrôle d’accès Windows. Les droits d’accès peuvent être configurés dans .NET lorsqu’un serveur démarre à l’aide de la classe PipeSecurity.
• Les sockets de domaine Unix prennent en charge la sécurisation d’un socket avec des autorisations de fichier.

Une autre option pour sécuriser un serveur IPC consiste à utiliser l’authentification et l’autorisation intégrées à ASP.NET Core. Par exemple, le serveur peut être configuré pour exiger authentification par certificat. Les appels RPC effectués par les applications clientes sans le certificat requis échouent avec une réponse non autorisée.

Valider le serveur dans l’application cliente IPC

Il est important que l’application cliente valide l’identity du serveur qu’elle appelle. La validation est nécessaire pour protéger un acteur malveillant contre l’arrêt du serveur approuvé, l’exécution de ses propres données et l’acceptation des données entrantes à partir de clients.

Les canaux nommés prennent en charge l’obtention du compte sous lequel un serveur s’exécute. Un client peut valider que le serveur a été lancé par le compte attendu :

internal static bool CheckPipeConnectionOwnership(
    NamedPipeClientStream pipeStream, SecurityIdentifier expectedOwner)
{
    var remotePipeSecurity = pipeStream.GetAccessControl();
    var remoteOwner = remotePipeSecurity.GetOwner(typeof(SecurityIdentifier));
    return expectedOwner.Equals(remoteOwner);
}

Une autre option pour valider le serveur consiste à sécuriser ses points de terminaison avec https à l’intérieur ASP.NET Core. Le client peut configurer SocketsHttpHandler pour valider que le serveur utilise le certificat attendu lorsque la connexion est établie.

var socketsHttpHandler = new SocketsHttpHandler()
{
    SslOptions = new SslOptions()
    {
        RemoteCertificateValidationCallback = (sender, certificate, chain, sslPolicyErrors) =>
        {
            if (sslPolicyErrors != SslPolicyErrors.None)
            {
                return false;
            }

            // Validate server cert thumbprint matches the expected thumbprint.
        }
    }
};

Protéger contre l’escalade des privilèges de canal nommé

Les canaux nommés prennent en charge une fonctionnalité appelée emprunt d’identité. À l’aide de l’emprunt d’identité, le serveur de canaux nommés peut exécuter du code avec les privilèges de l’utilisateur client. Il s’agit d’une fonctionnalité puissante, mais peut permettre à un serveur à privilèges faibles d’emprunter l’identité d’un appelant à privilèges élevés, puis d’exécuter du code malveillant.

Le client peut se protéger contre cette attaque en n’autorisant pas l’emprunt d’identité lors de la connexion à un serveur. Sauf si nécessaire pour un serveur, une valeur TokenImpersonationLevel de None ou de Anonymous doit être utilisée lors de la création d’une connexion cliente :

using var pipeClient = new NamedPipeClientStream(
    serverName: ".", pipeName: "testpipe", PipeDirection.In, PipeOptions.None, TokenImpersonationLevel.None);
await pipeClient.ConnectAsync();

TokenImpersonationLevel.None est la valeur par défaut dans les constructeurs NamedPipeClientStream qui n’ont pas de paramètre impersonationLevel.

Configurer le client et le serveur

Le client et le serveur doivent être configurés pour utiliser un transport de communication entre processus (IPC). Pour plus d’informations sur la configuration de Kestrel et SocketsHttpHandler de l’utilisation d’IPC :

• Communication entre processus avec gRPC et sockets de domaine et Unix
• Communication entre processus avec gRPC et canaux nommés

Notes

La prise en charge intégrée des canaux nommés dans ASP.NET Core nécessite .NET 8 ou version ultérieure.