A teraz zobacz co się dzieje, kiedy uruchomisz skrypt zawierający ścieżkę do skryptu, jak pokazuje rysunek 2.
Rysunek 2: Kiedy ścieżka jest zawarta w skrypcie, skrypt otwiera się bez problemu
Czemu jestem ograniczony?
Innym domyślnym ustawieniem, które jest bezpośrednio związane z bezpieczeństwem jest to, że wszystkie skrypty muszą działać interaktywnie. Jest to sposób zabezpieczenia, który zapewnia, że skrypt PowerShell nie może być uruchomiony z wirusa pod postacią skryptu. Oznacza to, że musisz znajdować się w interfejsie PowerShella i uruchomić skrypt w czasie rzeczywistym, aby mógł on zadziałać.
To ustawienie domyślne jest powiązane z ustawieniem polityki wykonania (ExecutionPolicy) w PowerShellu. ExecutionPolicy jest domyślnie ustawiona na „Restricted” (ograniczona), jak pokazuje rysunek 3.
Rysunek 3: ExecutionPolicy (polityka wykonania) jest domyślnie ustawiona na „Restricted” (ograniczona), aby zabezpieczyć wykonanie zdalnych skryptów PowerShell
Przekraczanie ustawień domyślnych
Domyślne ustawienie ExecutionPolicy w PowerShellu jest bardzo bezpieczne. Nie pozwala ono na uruchomienie żadnych skryptów z żadnego miejsca. Tak więc skrypty, które stworzysz i wpiszesz do systemu, nie będą działać. Skrypty, które pobierzesz z Internetu nie będą działać. Nawet skrypty, które podpiszesz i zabezpieczysz do „entej” potęgi nie będą działać. I to dlatego będziesz musiał zresetować poziom ExecutionPolicy zanim uruchomisz skrypty.
Ustawienie poziomu ExecutionPolicy
Istnieją cztery poziomy ExecutionPolicy. Te cztery poziomy dostarczają potężnego zabezpieczenia dotyczącego tego, co skrypty mogą uruchamiać i jakie wymagania muszą być powiązane ze skryptami, aby mogły one działać. Te cztery poziomy i wymagania zawierają:
Restricted
Jest to domyślna konfiguracja w PowerShellu. To ustawienie oznacza, że żaden skrypt nie może działać, niezależnie od sygnatury. Przy tym ustawieniu w PowerShellu uruchomione mogą być tylko indywidualne komendy.
AllSigned
To ustawienie umożliwia uruchamianie skryptów w PowerShellu. Skrypt musi mieć przypisany podpis cyfrowy pochodzący od zaufanego edytora. Zanim uruchomisz skrypt od zaufanego edytora, pojawi się podpowiedź. To naraża użytkownika na uruchomienie podpisanych, lecz złośliwych skryptów.
RemoteSigned
To ustawienie umożliwia uruchamianie skryptów, ale wymaga, aby skrypt oraz pliki konfiguracyjne, które są ściągane z Internetu miały przypisany podpis cyfrowy pochodzący od zaufanego edytora. Skrypty uruchamiane z lokalnego komputera nie muszą być podpisane. Przed uruchomieniem skryptu nie pojawiają się podpowiedzi. Jednak nadal naraża to użytkownika na uruchomienie podpisanych, lecz złośliwych skryptów.
Unrestricted
Nie jest to zalecane ustawienie! Umożliwia ono uruchamianie niepodpisanych skryptów, w tym wszystkich skryptów i plików konfiguracyjnych ściąganych z Internetu. Będą tu zawarte pliki z Outlook’a i Messenger’a. Ryzyko tutaj polega na uruchamianiu skryptów bez jakiegokolwiek podpisu czy zabezpieczenia.
Aby ustawić którykolwiek z tych poziomów, wpisz set-executionpolicy , jak widać na rysunku 4.
Rysunek 4: Ustawienie ExecutionPolicy jest tak proste jak uruchomienie komendy set-executionpolicy.
Używanie Polityki Grupowej
PowerShell jest wspaniały, ale jeśli skrypty nie mogą być uruchamiane na komputerach w danych środowiskach, ma on swoje ograniczenia. Po pierwsze musisz mieć PowerShella na każdym komputerze. Ponieważ PowerShell jest instalowany poprzez EXE, bardzo łatwo jest zainstalować tę aplikację. Możesz użyć albo pliku ZAP i wysłać (push out) go za pomocą Polityki Grupowej, albo możesz użyć aktualnej, scentralizowanej metody instalowania aplikacji. Pamiętaj, że PowerShell uchodzi za narzędzie dynamicznego usuwania usterek, więc Windows Update może także nie dopuścić do instalacji (push out the installation of PowerShell) PowerShella.
Gdy zainstalowałeś PowerShella, wiemy już, że potrzebujesz włączyć skrypty do uruchomienia. Wraz z ExecutionPolicy ustawioną domyślnie na „Restricted”, musisz skonfigurować każdy komputer, który ma uruchamiać skrypty, aby to robił. Jeżeli próbujesz zrobić to ręcznie, może to potrwać kilka dni.
Jednak możesz także użyć Polityki Grupowej, aby ona to zrobiła. Oczywiście możesz stworzyć własny Szablon Administratora (ADM file), aby wykonać tę zmianę lub ściągnąć szablon ADM dostarczany przez Microsoft. Sugeruję to drugie rozwiązanie, czyli ściągnięcie the ADM template.
Po ściągnięciu będziesz musiał zainstalować MSI. Przyznaję, że nie jest to najczystsza lub najwydajniejsza instalacja. Po instalacji, plik ADM jest przeniesiony do folderu C:\program files\Microsoft Group Policy. Jest to idealne zabezpieczenie! Plik, który musisz zaimportować do Group Policy Object Editor to PowerShellExtensionPolicy.ADM. Po imporcie będziesz mieć dwa nowe węzły w swoim Group Policy Object. Jeden będzie na Computer Configuration\Administrative Templates\Windows Components\Windows PowerShell, a drugi na User Configuration\Administrative Templates\Windows Components\Windows PowerShell, jak widać na rysunku 5.
Rysunek 5: Szablon PowerShell ADM dodaje ustawienia do Computer Configuration and User Configuration w celu wykonania skryptów
Jeśli przejdziesz do konfiguracji tej polityki, zobaczysz, że masz trzy opcje na jedno ustawienie, jak widać na rysunku 6.
Rysunek 6: Ustawienie ExecutionPolicy dla PowerShell w GPO
Podsumowanie
PowerShell jest obiecującą nowinką. Razem z Windows Server 2008, który ma się pojawić początkiem 2008 roku, PowerShell wystrzeli z siłą kuli armatniej. Z całą uwagą jaką PowerShell zyskuje, każdy ma nadzieję, że będzie mieć zabezpieczenia już wbudowane. Zamartwianie się jest już poza nami. PowerShell dostarcza zabezpieczeń bezpośrednio od siebie wraz z domyślnymi funkcjami zabezpieczeń. Fakt, że skrypty są ustawione w taki sposób, aby polityka ich wykonania była ograniczona, jest fantastyczny. Nawet jeżeli stworzyłeś plik .PS1, ten skrypt przypisany do Notatnika jest miłym domyślnym zabezpieczeniem. Nawet jeżeli dostałeś się do interfejsu PowerShella, fakt, że ścieżka do skryptu musi zostać wpisana dodaje wartości. Poza ustawieniami domyślnymi, fakt, że można ustawić politykę wykonania i kontrolować PowerShella poprzez Politykę Grupową dostarcza scentralizowanej kontroli nad bezpieczeństwem powłoki PowerShell.
Źródło: www.windowsecurity.com
Tłumaczenie: Małgorzata Kotlińska, Rzeszów
