W pracy administratora zdarza się, że musimy uruchamiać polecenia z uprawnieniami innego użytkownika, najczęściej o podwyższonych uprawnieniach. Delegując uprawnienia, możemy pozwolić sobie na pracę w bezpiecznym (gdyż pozbawionym uprawnień) środowisku, podnosząc je jedynie na czas wykonywania polecenia lub skryptu.

W artykule przyjrzymy się temu, jak zadbać, by tego rodzaju skrypty i funkcje przechowywały nasze poświadczenia w sposób możliwie bezpieczny. Omówimy też kilka rozwiązań, które pozwolą nam pominąć przekazywanie poświadczeń przy każdorazowym uruchomieniu skryptu.

> PSCredential

Pisząc skrypty bądź funkcje, musimy przede wszystkim zadbać o to, by przekazywanie poświadczeń było nie tylko możliwe, ale także możliwie proste, bez obniżania poziomu zabezpieczeń. Tradycyjnie do przechowywania poświadczeń w PowerShellu wykorzystywany jest typ PSCredential. Przede wszystkim powinniśmy więc zadbać, by przekazywanie dowolnego rodzaju poświadczeń odbywało się za pomocą obiektów tego typu. Nie wystarczy jednak dodanie parametru wykorzystującego ten typ. Będzie to rozwiązanie bezpieczne, ale mało wygodne.

Dodając do naszej funkcji bądź skryptu parametr zawierający poświadczenia, powinniśmy stosować się do kilku reguł. Jeśli korzystamy tylko z jednego obiektu tego typu, to warto nadać parametrowi nazwę „Credential”. Dzięki temu tworzone przez nas polecenie będzie spójne z innymi poleceniami wspierającymi przekazywanie poświadczeń.

Druga, szalenie istotna sprawa, to wsparcie dla użytkowników pragnących podać hasło bądź hasło i nazwę użytkownika w trakcie uruchomienia polecenia. Bardzo często polecenia nie wspierają tego rodzaju pracy z poleceniem Credential, zmuszając nas poniekąd do utworzenia zmiennej w bieżącej sesji, i dopiero tę zmienną przekazywać będziemy dalej:

$poświadczenia = Get-Credential
Invoke-Command -ComputerName test -Credential $poświadczenia `
-ScriptBlock { hostname }

Polecenia poprawnie obsługujące parametr Credential umożliwiają przekazanie do tego parametru ciągu znaków, który traktowany będzie jak nazwa użytkownika. Dalej polecenie poprosi nas jedynie o hasło dla tego właśnie użytkownika:

Invoke-Command -ComputerName test -Credential `
testadministrator -ScriptBlock { hostname }

Aby uzyskać taki efekt, będziemy musieli skorzystać z klasy przekształcającej, o którą wzbogacimy definicję parametru.

Ostatnia rzecz, która może się okazać przydatna, to umożliwienie uruchomienia polecenia bez podawania poświadczeń (jeśli możemy się bez nich obejść) lub wymuszenie podania ich, jeśli bez nich nasze polecenie z pewnością nie zadziała. Poprawnie zaimplementowany parametr PSCredential wyglądałby więc następująco:

function Get-Secret {
 param (
 # Parametr niezbędny
 [Parameter(Mandatory)]
 [PSCredential]
 [Management.Automation.Credential()]
 $Credential
 ) }
function Get-Something {
 param (
 # Parametr przydatny
 [Parameter()]
 [PSCredential]
 [Management.Automation.Credential()]
 $Credential = [PSCredential]::Empty
 )
 if ($Credential -eq [PSCredential]::Empty) {
 # Nie mamy poświadczeń…
} }

Konieczność stosowania atrybutów jest niezwykle istotna. Jeśli odwrócimy kolejność typu naszego parametru (PSCredential) i atrybutu, który potrafi dokonać przekształcenia (Management.Automation.Credential), to uzyskamy efekt daleki od zamierzonego, przynajmniej w starszych wersjach PowerShella – w czasie testów udało się odtworzyć takie zachowanie w PowerShellu w wersji czwartej. Co się wówczas wydarzy? Ciąg znaków, który przekażemy do PSCredential, nie nadaje się do bezpośredniego przypisania do zmiennej typu PSCredential, więc nasza funkcja zwróci w takim przypadku błąd. Co ciekawe, w nowszych wersjach atrybut możemy pominąć. Typ PSCredential sam będzie usiłował dokonać przekształcenia. Poniżej zachowanie funkcji z błędną kolejnością i bez atrybutu w PowerShellu 4 i 5.1:

# Funkcja
function Get-WrongSecret {
 param (
 [Parameter()]
 [Management.Automation.Credential()]
 [PSCredential]
 $Credential
 ) }
# PowerShell 5.1
Get-WrongSecret -Credential test
<zapytanie o hasło dla użytkownika test>
# PowerShell wersja 4.0
Get-WrongSecret -Credential test
Cannot process argument transformation on parameter 'Credential'. Cannot convert the "test" value of type "System.String" to type "System.Management.Automation.PSCredential".

Jeśli więc nasz skrypt ma wspierać również starsze wersje PowerShella, to musimy zadbać o to, by parametr najpierw został przekształcony przez atrybut (który potrafi poradzić sobie z ciągiem znaków), a dopiero wynik takiej transformacji PowerShell spróbuje przypisać do kompatybilnego z nim typu PSCredential.

[...]