PowerShell ISE na sterydach (2.0), część 4
Tworzone w ramach organizacji skrypty, szczególnie te, które działać będą w środowisku produkcyjnym, powinny podlegać pewnemu procesowi weryfikacji. Korzystne jest też, by weryfikował skrypt ktoś inny niż autor (lub autorzy) – zdecydowanie zmniejsza to szansę “przemycenia” błędów logicznych, wynikających z błędnych założeń. ISESteroids ułatwia taki formalny proces przez kilka elementów: ułatwienie analizy zawartości skryptu pod kontem jego potencjalnych zagrożeń, uproszczenie podpisywania skryptu podpisem cyfrowym czy umożliwienie jego publikację jako “zamkniętej” aplikacji.
Co może pójść nie tak?
Przeglądając skrypt napisany przez kogoś innego, możemy łatwo przeoczyć te elementy składni, które potencjalnie mogą spowodować zmiany katastrofalne w naszym środowisku. Oprócz tego przydałby się mechanizm, dzięki któremu skrypty raz “przeanalizowane” i ocenione, jako bezpieczne/poprawne, byłyby oznaczone jako takie. I wreszcie: przydałoby się by wprowadzenie zmian w skrypcie cofało takie oznaczenie. Wszystkie te funkcje oferuje “Risk Manager”, dodany w wersji 2.0.10.24 ISESteroids. Po otwarciu skryptu, który nie jest podpisany cyfrowo, uzyskujemy informację o bezpieczeństwie uruchomienia skryptu. Ocena opiera się na użytych elementach składni: głównie poleceniach i konstrukcjach bazujących na klasach w .NET (takich jak [scriptblock]::Create()). Wyodrębnione są trzy poziomy: brak zagrożeń, niewielkie zagrożenie, znaczne zagrożenie. Oczywiście, ocena może być myląca:
Narzędzie pozwala jednak sprawdzenie po kolei potencjalnych zagrożeń i jeśli uznamy, że coś jest istotnie niebezpieczne, lub wręcz przeciwnie, nie stanowi zagrożenia, możemy taką ocenę wystawić:
Jak widać – analiza jest dogłębna i nie pomija takich elementów jak podwyrażenia. Oczywiście, wiele zależy od poprawnej konfiguracji. W domyślnej wersji analiza ogranicza się do “pełnych” poleceń, wszelkie aliasy czy polecenia systemowe są ignorowane. Na szczęście wszystkie trzy listy możemy sami kontrolować przy pomocy interfejsu graficznego:
Narzędzie oferuje cztery zakładki: trzy na poszczególne kategorie komend, oraz czwartą, zawierającą informacje o zaufanych podpisach cyfrowych. Zaufane podpisy gwarantują nam integralność skryptu, wobec czego nie musimy poświęcać czasu na jego analizę (założenie jest takie, że przed podpisaniem autor taką analizę już przeprowadził). W pozostałych trzech zakładkach możemy dodawać nowe polecenia, lub modyfikować polecenia już istniejące:
Możemy też skorzystać z innych narzędzi. Informacja o naszych ustawieniach przechowywana jest w plikach CSV w folderze “$env:APPDATA\ISESteroids\RiskManagement”. Każdej zakładce odpowiada osobny plik, więc nie trudno sobie wyobrazić centralne kontrolowanie tych ustawień.
Po przeanalizowaniu zagrożeń możemy dojść do wniosku, że oceniany skrypt jest bezpieczny. Wówczas, po “oddaleniu” wszelkich zagrożeń potwierdzić musimy naszą aprobatę. Edytor korzysta przy tym z alternatywnego strumienia danych “ApprovalState”:
Oczywiście, nic nie stoi na przeszkodzie by taką operację przeprowadzić poza edytorem (zarówno aprobowanie jak i usuwanie odpowiedniej flagi). Flaga ta zostanie również usunięta przez ISESteroids w momencie, gdy zmienimy i zapiszemy plik uprzednio zaaprobowany. Niestety, ze względu na sposób oznaczeniu skryptu (prosta flaga, bez informacji o zawartości skryptu) zmiany w innych edytorach mogą pozostać niezauważone. Dlatego też, jeśli chcemy zagwarantować integralność skryptu, lepiej jest skorzystać z podpisów cyfrowych, których używanie również poprawiło się w nowej wersji ISESteroids.
“To pisałem ja – Jarząbek.“
ISESteroids w wersji pierwszej zawierał już elementy ułatwiające pracę z podpisem cyfrowym. W wersji obecnej używanie podpisu cyfrowego zostało poprawione. Przede wszystkim zapisując skrypt podpisany cyfrowo nie musimy się już martwić o aktualizację podpisu. Dodatek sam zadba o to, by (jeśli to możliwe) zaktualizować podpis i zapisać na dysku wersję podpisaną. Druga poprawka nie jest krytyczna, ale pozwala zadbać o to, by skrypt pozostał “zaufany” nawet po wygaśnięciu certyfikatu. W poprzedniej wersji mogliśmy jedynie określić, czy chcemy korzystać z serwera czasu. W wersji obecnej może również określić, z jakiego serwera narzędzie powinno korzystać:
Wreszcie opcja będącą połączeniem możliwości oferowanych przez wspomniany już “Risk Manager”: dodanie podpisu do listy podpisów “zaufanych” w ramach tego narzędzia powoduje, że sam skrypt pojawia się wśród wyjątków i nie będziemy już ostrzegani, o ewentualnych ryzykownych poleceniach, które są w nim używane:
Wszystko w jednym
Korzystanie ze skryptów napisanych w PowerShellu bywa kłopotliwe, szczególnie jeśli chcemy nimi “uszczęśliwić” osoby o mniejszej wiedzy informatycznej. Na ogół problem obchodzimy tworząc prosty plik cmd, który uruchomi PowerShella z odpowiednimi parametrami. ISESteroids oferuje rozwiązanie o wiele bardziej profesjonalne: przerobienie naszego skryptu, na “normalny” plik wykonywalny:
Możemy pominąć opcje zaawansowane i od razu wygenerować plik exe. Warto jednak zapoznać się z domyślnymi opcjami i jeśli to zasadne, zmienić je, zgodnie z naszymi potrzebami. Dla przykładu: jeśli nasz skrypt generuje interfejs graficzny i nie zwraca żadnych wartości do “normalnej” konsoli, najrozsądniejsza wydaje się opcja “Hide Console Window”. Jeśli natomiast chcemy przeanalizować zwrócone przez PowerShella obiekty, najlepszą opcją będzie opcja domyślna, oczekująca na reakcję użytkownika. Jak widać możemy też wymusić uruchomienie jako administrator i wybrać alternatywną ikonkę dla naszego dzieła. Opcja “Apply Digital Signature” w wersji testowanej jeszcze nie działała, ale z pewnością będzie cennym dodatkiem, ułatwiającym ocenę potencjalnego ryzyka przed uruchomieniem naszej aplikacji. Trzeba pamiętać jednak o ograniczeniach tego narzędzia: plik exe zawierać będzie jedynie nasz skrypt (przynajmniej w obecnej wersji), więc wszelkie zależności muszą być rozwiązywalne niezależnie od miejsca uruchomienia. Jeśli chcemy wczytywać plik konfiguracyjny, zadbajmy o to, by skrypt bez trudu go odnalazł. Jeśli zamierzamy użyć modułów, upewnijmy się, że są dostępne (wyświetlając przyjazną informację o błędzie, jeśli tak nie będzie). Problemu nie będzie, jeśli nasz skrypt będzie “samowystarczalny” i to, moim zdaniem, najbardziej kusząca perspektywa. Oprócz tego skrypt nasz (od wersji opublikowanej w Mikołajki) wspiera parametry: zarówno te określone przez nas, jak i “domyślny” parametr zwracający pomoc:
I to wszystko o czym chciałem napisać w tej części. W następnej postaram się przybliżyć “debugger”, wraz z opcjami dodanymi w najnowszej wersji, która opublikowana została kilka dni temu.
PowerShell po polsku 