Auswählen von Sicherheits-QOS-Optionen
Die QOS-Sicherheitsoptionen werden als Teil des SecurityQOS-Parameters übergeben, der der RpcBindingSetAuthInfoEx-Funktion zugewiesen wird. Verwenden Sie die folgenden bewährten Methoden.
Verwenden der gegenseitigen Authentifizierung
Die gegenseitige True-Authentifizierung ist nur für bestimmte Sicherheitsanbieter verfügbar: Negotiate (wenn Kerberos ausgehandelt wird), Kerberos und Schannel. NTLM unterstützt keine gegenseitige Authentifizierung. Für die gegenseitige Authentifizierung muss ein wohlgeformter Serverprinzipalname angegeben werden. Viele Entwickler verwenden die folgende fehlerhafte Sicherheitspraxis: Der Server wird aufgerufen, um nach seinem Prinzipalnamen (RpcMgmtInqServerPrincName) zu fragen, und dann bitten sie blind um gegenseitige Authentifizierung mit diesem Prinzipalnamen. Dieser Ansatz bricht die gesamte Idee der gegenseitigen Authentifizierung; Die Idee der gegenseitigen Authentifizierung besteht darin, dass nur bestimmte Server aufgerufen werden, da sie vertrauenswürdig sind, um Ihre Daten zu analysieren und zu verarbeiten. Mithilfe der soeben beschriebenen fehlerhaften Sicherheitspraxis geben Entwickler ihre Daten an jeden weiter, der intelligent genug ist, um seinen Namen zurückzugeben.
Wenn die Clientsoftware beispielsweise nur einen Server aufrufen soll, der unter Joe, Pete oder Alices Konten ausgeführt wird, sollte die Funktion RpcMgmtInqServerPrincName aufgerufen werden, und der zurückgesendete Name sollte überprüft werden. Wenn es Joe, Pete oder Alice ist, sollte die gegenseitige Authentifizierung unter Verwendung ihres Serverprinzipalsnamens angefordert werden. Dadurch wird sichergestellt, dass beide Hälften der Unterhaltung an den gleichen Prinzipal wechseln.
Wenn die Clientsoftware nur einen Dienst aufrufen soll, der nur unter Joes Konto ausgeführt wird, erstellen Sie den Serverprinzipalnamen von Joe direkt, und tätigen Sie den Anruf. Wenn der Server nicht Joe ist, schlägt der Aufruf einfach fehl.
Häufig werden Dienste als Windows-Systemdienste ausgeführt, was bedeutet, dass sie unter dem Computerkonto ausgeführt werden. Die gegenseitige Authentifizierung und erstellung eines Serverprinzipalnamens wird weiterhin empfohlen.
Verwenden Sie den niedrigsten Identitätswechseltyp, durch den der Aufruf durchlaufen kann.
Diese bewährte Methode ist ziemlich selbsterklärend. Selbst wenn die gegenseitige Authentifizierung verwendet wird, sollten Sie dem Server nicht mehr Rechte als erforderlich erteilen. Ein legitimer Server wurde möglicherweise kompromittiert, und obwohl die von Ihnen gesendeten Daten in solchen Fällen in die falschen Hände geraten, kann der Server nicht in Ihrem Namen auf andere Daten im Netzwerk zugreifen. Einige Server lehnen einen Aufruf ab, der nicht über ausreichende Informationen verfügt, um den Aufrufer zu bestimmen und möglicherweise die Identität zu annehmen. Beachten Sie außerdem, dass einige Protokollsequenzen die Sicherheit auf Transportebene (ncacn_np und ncalrpc) unterstützen. In solchen Fällen kann der Server immer ihre Identität annehmen, wenn Sie beim Erstellen des Bindungshandles über den Parameter NetworkOptions eine ausreichend hohe Identitätswechselebene angeben.
Schließlich können einige Sicherheitsanbieter oder Transporte ImpersonationType transparent auf eine höhere Ebene als die angegebene erhöhen. Stellen Sie beim Entwickeln eines Programms sicher, dass Sie versuchen, Aufrufe mit dem beabsichtigten ImpersonationType auszuführen, und überprüfen Sie, ob Sie höhere ImpersonationType-Werte auf dem Server erhalten.