Co dają identyfikatory SID? Wiele usług korzysta z kont wbudowanych, np. Local Service. Wcześniej powodowało to, że dowolna usługa pracująca w kontekście tego konta miała dostęp do zasobów. Tworzono więc osobne konta dla każdej z usług, co znacząco utrudniało pracę i wprowadzało trudny do opanowania bałagan. Mając SID-y, jesteśmy w stanie ustawić prawa dostępowe dla konkretnej usługi, nawet pracującej w kontekście tego samego konta. Do aktywowania SID na usłudze służy parametr qsidtype w poleceniu sc np.:

sc qsidtype abcd restricted

Spowodowałoby to utworzenie identyfikatora SID Restricted dla usługi "abcd".

Mając identyfikator SID, możemy przydzielać dostęp do zasobów konkretnym usługom. Także zapora Windows ściśle integruje się z SID-ami, co daje dodatkową warstwę ochrony przed atakami.

Śledząc dokumentację W2K8, odnajdziemy możliwość kontrolowania usług pod kątem uprawnień, z jakimi są one uruchamiane. Uprawnienia te nie są związane z kontem, w kontekście którego usługa pracuje. Posłużmy się przykładem. Parametr qprivs w poleceniu sc zwróci nam właśnie te uprawnienia:

Jeżeli uważamy, że usłudze do prawidłowego działania wystarczy mniej uprawnień, wówczas możemy je zabrać np.:

sc qprivs abcd SeImpersonatePrivilege

Ruch sieciowy

Mając ustaloną listę usług i realizowanych przez nie funkcji, możemy pójść o krok dalej - ograniczyć ich komunikację. Dobrą praktyką jest, aby każdy kluczowy zasób był chroniony za pomocą lokalnej zapory ogniowej. W starszych systemach Windows raczej bazowało się na produktach firm trzecich. W W2K8 zapora ogniowa przestała być już tylko przysłowiowym "kwiatkiem do kożucha". Po pierwsze, zestaw dostępnych od ręki funkcji dość mocno się rozrósł, możemy więc tworzyć reguły, wskazując nie tylko port i adres IP, ale także aplikację czy też usługę (związek z SID). Możemy również wymagać, aby komunikacja między poszczególnymi komputerami była uwierzytelniana przy użyciu protokołu IPSec (sekcja Connection Security Rules). Przy okazji IPSec istnieje możliwość tworzenia reguł, które będą działały dla konkretnego użytkownika domenowego.

Począwszy od W2K8 R2, możemy przypisywać polityki osobno dla każdego interfejsu sieciowego - sfery. Inne reguły polityki może mieć więc komputer podłączony do domeny, inne podłączony do sieci publicznej, a jeszcze inne - do sieci prywatnej.

Po drugie, zapora została zintegrowana z samym systemem - a dokładniej z modułem zarządzania serwerem. Oznacza to, że modyfikacja pewnych funkcji w Windows powoduje automatyczne zmiany w zaporze. Jeżeli więc wskazujemy na jakąś konkretną rolę, np. serwer DNS, wówczas zapora automatycznie otworzy tylko te porty, które potrzebne są do realizacji zadań tej roli. Wszystko jest dobrze, jeżeli instalujemy role czy aplikacje, które integrują się z modułem zarządzania.