Do czasu, gdy uzyskujemy dostęp do systemów lub zasobów z wykorzystaniem zintegrowanego uwierzytelniania Windows, temat poświadczeń jest przyjemny i łatwy. Dlatego wszędzie tam, gdzie to możliwe wykorzystuję przede wszystkim Integrated Windows Authentication (IWA).

Jeśli nie, to istnieje kilka opcji na przekazywanie a co najważniejsze przechowywanie poświadczeń. Pokaże kilka możliwych sposobów, niektóre nie nadają się do wykorzystania ze względu na bezpieczeństwo lub bardziej ze względu na jego brak. Na przykład tak jak…

Jawny tekst

Jest to super szybki, super prosty i najmniej bezpieczny sposób wykorzystywania poświadczeń. Ktokolwiek kto ma dostęp do skryptu, ma dostęp do poświadczeń. Nie rób tak.

Lepszym pomysłem będzie wyodrębnienie hasła poza skrypt, ale tylko pod warunkiem umieszczenia pliku w lokalizacji z odpowiednią kontrolą dostępu (ACL). Jednak tego również nie rekomenduje.

Poświadczenia na żądanie

Rozwiązanie idealne… do momentu, gdy nie interesuje nas automatyzacja skryptu. Jeśli jednak piszesz skrypt z myślą wykonywania interaktywnego, to zdecydowanie wykorzystaj ten sposób.

Szyfrowanie z wykorzystaniem Data Protection API

Data Protection API to wbudowana w system Windows prosta usługa umożliwiająca chronić poufne dane (np. hasła) przy użyciu informacji z bieżącego konta użytkownika lub komputera. Korzystając z DPAPI, zmniejszasz trudny problem generowania i przechowywania klucza kryptograficznego.

Do przygotowania pliku z poświadczeniami wykorzystaj polecenie Export-Clixml, które zapisze reprezentacje obiektu do pliku XML. Jak pewnie zauważyłeś SecureString został zapisany w postaci zaszyfrowanej.

Chociaż jest to interesującą metodą ma jedną wadę. Zaszyfrowany ciąg można pobrać tylko w tym samym kontekście komputera i użytkownika, który zaszyfrował ciąg.

Próba odszyfrowania Twojego pliku poświadczeń przez kogoś innego zakończy się błędem: Import-Clixml : Key not valid for use in specified state. Może to i dobrze… ale o przenoszalności takich skryptów możesz zapomnieć.

Tak przygotowane poświadczenia w poniższy sposób zaimportuj w skrypcie.

Być może w przypadku poświadczeń nie jest to wada ale SecureString ma limit 65536 znaków który uniemożliwia przechowywania dużej ilości wrażliwych danych.

Szyfrowanie kluczem

ConvertFrom-SecureString ma możliwość wskazania klucza o długości 16, 24 lub 32 bajtów jako elementu szyfrującego. W tym momencie rezygnujemy z wykorzystania DPAPI na rzecz algorytmu szyfrowania symetrycznego AES. (czyli samym kluczem zarówno zaszyfrujesz, jak i odszyfrujesz wartość).

Sposób wygląda na złożony, ale tylko ze względu na dodatkowy krok związany z przygotowaniem klucza szyfrującego.

Tak przygotowany zestaw (klucz + hasło) wykorzystaj do zbudowania poświadczeń.

Pamiętaj, w tym podejściu najważniejszym elementem jest klucz a poziom bezpieczeństwa determinuję sposób jego przechowywania i dystrybuowania.

Podsumowanie

Każda z wymienionych metod ma swoje zalety i wady. Z pewnością wykorzystanie DPAPI dla własnych poświadczeń jest najwygodniejsze i bezpieczne.

Poziom trudności rośnie, gdy chcemy współdzielić skrypty wraz z poświadczeniami, wtedy rozwiązanie z kluczem będzie lepszym podejściem. Jednak, dbaj o element szyfrujący.

Temat nie został wyczerpany w pełni, jeśli interesują Cię alternatywne metody przechowywania poufanych danych, to daj znać w komentarzu lub napisz maila.

22 Najważniejsze Wskazówki Pisania Skryptów PowerShell

Mateusz Nadobnik

Zachwycony językiem skryptowym Windows PowerShell. Swoją wiedzę, doświadczenia i spostrzeżenia opisuję na blogu.

read more