Wybieranie opcji zabezpieczeń QoS
Opcje QOS zabezpieczeń są przekazywane jako część parametru SecurityQOS podanego do funkcji RpcBindingSetAuthInfoEx. Skorzystaj z poniższych najlepszych rozwiązań.
Korzystanie z wzajemnego uwierzytelniania
Prawdziwe wzajemne uwierzytelnianie jest dostępne tylko dla niektórych dostawców zabezpieczeń: Negotiate (podczas negocjowania protokołu Kerberos), Kerberos i Schannel. Protokół NTLM nie obsługuje wzajemnego uwierzytelniania. Użycie wzajemnego uwierzytelniania wymaga podania dobrze sformułowanej głównej nazwy serwera. Wielu deweloperów stosuje następującą wadliwą praktykę zabezpieczeń: serwer jest wywoływany, aby poprosić o nazwę główną (RpcMgmtInqServerPrincName), a następnie ślepo pytają o wzajemne uwierzytelnianie przy użyciu tej głównej nazwy. Takie podejście łamie całą ideę wzajemnego uwierzytelniania; ideą wzajemnego uwierzytelniania jest to, że wywoływane są tylko niektóre serwery, ponieważ są zaufane do analizowania i obsługi danych. Korzystając z opisanej właśnie błędnej praktyki zabezpieczeń, deweloperzy udostępniają swoje dane każdemu, kto jest wystarczająco sprytny, aby podać swoje imię.
Jeśli na przykład oprogramowanie klienckie powinno wywoływać tylko serwer działający na kontach Joe, Pete, lub Alice, należy wywołać funkcję RpcMgmtInqServerPrincName i sprawdzić otrzymaną nazwę. Jeśli jest to Joe, Pete lub Alice, należy zażądać wzajemnego uwierzytelniania przy użyciu głównej nazwy serwera. Gwarantuje to, że obie połowy rozmowy są skierowane do tego samego głównego podmiotu.
Jeśli oprogramowanie klienckie powinno wywoływać usługę działającą tylko na koncie Joe, należy bezpośrednio utworzyć główną nazwę serwera Joe i wykonać wywołanie. Jeśli serwer nie jest Joe, wywołanie po prostu zakończy się niepowodzeniem.
Wiele razy usługi są uruchamiane jako usługi systemowe systemu Windows, co oznacza, że działają na koncie komputera. Wzajemne uwierzytelnianie i tworzenie głównej nazwy serwera jest nadal zalecane.
Użyj najniższego poziomu uprawnień delegowania, który pozwala na realizację wywołania
Ta najlepsza praktyka jest dość samoobjaśniająca. Nawet jeśli jest używane wzajemne uwierzytelnianie, nie należy udzielać serwerowi więcej praw niż jest to konieczne; Legalny serwer mógł zostać skompromitowany, i nawet jeśli dane, które wysyłasz, trafią w niewłaściwe ręce w takich przypadkach, przynajmniej serwer nie będzie mógł uzyskać dostępu do innych danych w sieci w Twoim imieniu. Niektóre serwery odrzucają wywołanie, które nie ma wystarczających informacji, aby określić, i ewentualnie personifikować, obiekt wywołujący. Należy również pamiętać, że niektóre sekwencje protokołów obsługują zabezpieczenia na poziomie transportu (ncacn_np i ncalrpc). W takich przypadkach serwer zawsze może się personifikować, jeśli określisz wystarczająco wysoki poziom personifikacji za pośrednictwem parametru NetworkOptions podczas tworzenia uchwytu powiązania.
Na koniec niektórzy dostawcy zabezpieczeń lub transporty mogą w sposób przezroczysty podbić typ personifikacji na wyższy poziom niż określony. Podczas tworzenia programu upewnij się, że próbujesz wykonać wywołania za pomocą zamierzonego typu ImpersonationType (typ personifikacji) i sprawdź, czy na serwerze uzyskujesz wyższy typ personifikacji.