Wskazówki dotyczące zabezpieczeń

Narzędzie CLI winapp ułatwia lokalne programowanie w systemie Windows: może wygenerować certyfikat podpisywania, dodać go do zaufanych certyfikatów na komputerze i włączyć za Ciebie Tryb dewelopera. Każdy z tych kroków zmienia stan maszyny lub tworzy plik, który zawiera klucz prywatny, dzięki czemu pomaga dokładnie wiedzieć, co robią.

Na tej stronie wyjaśniono konsekwencję każdego polecenia, sposób jego cofania i co zrobić inaczej podczas wysyłki. Certyfikaty programistyczne i tryb dewelopera to standardowa, obsługiwana metoda testów lokalnych — chodzi o to, aby rozumieć, na co się decydujesz, a nie unikać tych rozwiązań.

Certyfikaty programistyczne

Pakiety MSIX muszą być podpisane, zanim Windows je zainstaluje. Do testów lokalnych winapp cert generate tworzy certyfikat samopodpisany, dzięki czemu można podpisać i zainstalować własny pakiet bez konieczności kupowania czegokolwiek.

Co winapp cert generate tworzy

Wygenerowany certyfikat to certyfikat z podpisem własnym, certyfikat podpisywania kodu jednostki końcowej:

Property Wartość
Key RSA 2048-bitowy, oznaczony jako eksportowalny
Algorytm podpisu SHA-256 z RSA (PKCS#1 w wersji 1.5)
Użycie klucza Podpis cyfrowy
Ulepszone użycie klucza Podpisywanie kodu (1.3.6.1.5.5.7.3.3)
Podstawowe ograniczenia Nie urząd certyfikacji
Ważność Domyślnie 365 dni (--valid-days)
Temat Musi odpowiadać znacznikowi Publisher w manifeście

Polecenie zapisuje dwie rzeczy:

  • devcert.pfx w bieżącym katalogu (lub w ścieżce przekazanej do --output). Ten plik zawiera zarówno certyfikat, jak i jego klucz prywatny.
  • Kopia certyfikatu w Twoim osobistym magazynie certyfikatów (Cert:\CurrentUser\My).

Przy użyciu --export-cer zapisuje również plik .cer obok pliku .pfx. Ten plik zawiera tylko certyfikat publiczny — bez klucza prywatnego — co sprawia, że należy przekazać go do kolegi z zespołu lub maszyny testowej, która musi ufać kompilacjom.

Note

Certyfikat samopodpisany nie jest zaufany przez nikogo, dopóki ktoś wyraźnie mu nie zaufa. To wystarczy na własnym komputerze i na własnych maszynach testowych; nie zastępuje to rzeczywistej tożsamości do podpisywania kodu przy rozpowszechnianiu aplikacji.

Domyślne hasło

winapp cert generate używa password jako hasła do pliku PFX, chyba że przekażesz --password. Ta sama wartość domyślna obowiązuje również, gdy później przekażesz ten certyfikat do winapp sign, którego opcją hasła jest także --password, oraz do winapp pack, który przyjmuje parametr --cert-password.

Dobrze znane hasło oznacza, że klucz prywatny w devcert.pfx programie jest skutecznie niechroniony — każdy, kto uzyskuje plik, może podpisać kod. To akceptowalny kompromis w przypadku jednorazowego certyfikatu, który służy wyłącznie do podpisywania lokalnych kompilacji testowych na własnym komputerze, i właśnie dlatego istnieje to ustawienie domyślne.

Important

Traktuj hasło domyślne jako sygnał, że certyfikat jest jednorazowy. Jeśli certyfikat jest kiedykolwiek używany do podpisywania czegoś, co zainstaluje inna osoba, nie powinien to być certyfikat winapp cert generate z domyślnym hasłem — zobacz Podpisywanie dla środowiska produkcyjnego.

Skrypty i agenci nie muszą same porównywać haseł: winapp cert generate --json zgłasza "defaultPasswordIsPublic": true i powtarza tę informację w tablicy warnings, gdy obowiązuje ustawienie domyślne. Zobacz Generowanie danych wyjściowych w formacie JSON za pomocą polecenia cert.

Miejsce, w którym znajduje się plik certyfikatu

devcert.pfx jest kluczem prywatnym na dysku. Dwie zasady chronią je przed problemami:

Nie zatwierdzaj go.winapp cert generate automatycznie dołącza nazwę pliku certyfikatu do .gitignore obok niego, więc domyślny przepływ jest już omówiony. Jeśli przeniesiesz plik, zmień jego nazwę lub wygenerujesz go do katalogu zarządzanego przez inny .gitignoreelement , sprawdź, czy następuje po nim wpis:

git check-ignore -v devcert.pfx

Jeśli to nie spowoduje wyświetlenia niczego, plik nie zostanie zignorowany — dodaj go przed zatwierdzeniem.

Nie pakuj tego.winapp pack pakuje wszystko w katalogu wejściowym, więc devcert.pfx znajdujący się w folderze wyjściowym aplikacji trafia do dostarczanego pakietu MSIX. Wygeneruj certyfikat poza folderem, który pakujesz, jak pokazano w przewodniku dotyczącym pakowania pliku EXE/narzędzia CLI, i upewnij się przed jego rozpowszechnieniem, że go tam nie ma:

# Unpack the package and check that no certificate is inside
winapp tool makeappx unpack /p .\MyApp.msix /d .\inspect /o
Get-ChildItem .\inspect -Recurse -Include *.pfx, *.cer

Wskazówka

Jeśli element z prawdziwym kluczem .pfx prywatnym kiedykolwiek zostanie zatwierdzony lub opublikowany, obróć go: wygeneruj nowy certyfikat, ponownie podpisz i przestań ufać staremu, wykonując kroki opisane w temacie Usuwanie zaufanego certyfikatu. Usunięcie pliku z późniejszego zatwierdzenia nie powoduje usunięcia go z historii.

Jakie winapp cert install dotacje

winapp cert install dodaje certyfikat do magazynu LocalMachine\TrustedPeople. Wymaga to uprawnień administratora, ponieważ zmienia zaufanie dla każdego użytkownika na maszynie.

Gdy certyfikat znajdzie się w TrustedPeople, system Windows uzna dowolny pakiet MSIX podpisany tym certyfikatem za wystarczająco zaufany, aby go zainstalować — nie tylko pakiet, który testowano. W przypadku certyfikatu, którego klucz prywatny posiadasz i przechowujesz lokalnie, jest to dokładnie zamierzony efekt. Jest to również powód, dla którego należy się o tym zastanowić:

  • Ufaj certyfikatom wygenerowanymi samodzielnie lub pochodzą od kogoś, kogo pozwolisz zainstalować oprogramowanie na maszynie.
  • Nie instaluj certyfikatu programistycznego na współdzielonych komputerach, komputerach produkcyjnych ani maszynach kompilacyjnych, z których korzystają inne osoby.
  • Preferuj dystrybucję .cer (tylko klucz publiczny), a nie .pfx wtedy, gdy współpracownik musi zainstalować pakiet testowy. Mogą ufać Twoim kompilacjom, nie zyskując przy tym możliwości podpisywania się jako Ty.

Aby ufać elementowi .cer na innej maszynie testowej, uruchom na niej bezpośrednio polecenie winapp cert install — polecenie akceptuje zarówno .pfx, jak i wyłącznie publiczny .cer:

# Run as Administrator
winapp cert install .\devcert.cer

Odpowiednikiem używania tylko wbudowanych narzędzi Windows jest:

# Run as Administrator
Import-Certificate -FilePath .\devcert.cer -CertStoreLocation Cert:\LocalMachine\TrustedPeople

Usuwanie zaufanego certyfikatu

Certyfikaty deweloperskie domyślnie wygasają po roku, ale wygaśnięcie nie oznacza usunięcia. Gdy certyfikat nie jest już potrzebny — projekt został zakończony, maszyna otrzymuje nowe przeznaczenie lub klucz mógł wyciec — usuń go wprost.

Najpierw znajdź odcisk palca:

Get-ChildItem Cert:\LocalMachine\TrustedPeople |
    Where-Object { $_.Subject -like '*CN=Contoso*' } |
    Format-List Subject, Thumbprint, NotAfter

Następnie usuń go z magazynu zaufanych certyfikatów komputera. Ten krok wymaga podniesienia uprawnień:

# Run as Administrator. Replace with the thumbprint from the previous command.
$thumbprint = 'ABCD...'
Remove-Item -Path "Cert:\LocalMachine\TrustedPeople\$thumbprint"

cert generate dodał również certyfikat wraz z jego kluczem prywatnym do magazynu osobistego. Usuń to z zwykłego monitu bez podwyższonych uprawnień, po zalogowaniu na konto, z którego uruchomiono cert generate:

$thumbprint = 'ABCD...'
Remove-Item -Path "Cert:\CurrentUser\My\$thumbprint"

Important

Uruchom dwa powyższe polecenia w pokazanych kontekstach. Jeśli uruchomiono z podwyższonymi uprawnieniami przy użyciu innego konta administratora, Cert:\CurrentUser w tej sesji z podwyższonymi uprawnieniami jest magazynem tego administratora — a nie Twoim — więc klucz prywatny pozostałby w magazynie użytkownika, który go wygenerował.

Na koniec usuń .pfx oraz wszelkie kopie .cer, które rozdano, i wyrejestruj pakiety zainstalowane za jego pomocą metodą sideloadingu:

winapp unregister

Note

Usunięcie certyfikatu nie powoduje odinstalowania pakietów, które zostały już zainstalowane. Odinstaluj je oddzielnie w obszarze Ustawienia > Aplikacje > Zainstalowane aplikacje lub za pomocą winapp unregister w przypadku pakietów zarejestrowanych w trybie deweloperskim.

Tryb programisty

Windows wymaga, aby tryb dewelopera zarejestrował pakiet aplikacji bezpośrednio z folderu na dysku — luźny układ — zamiast instalować skompilowany podpisany plik MSIX. Polecenia, takie jak winapp run i create-debug-identity, zależą od tego i bez tego nie działają, a winapp init oferuje włączenie tego za Ciebie.

Co zmienia jego włączenie

CLI włącza Tryb dewelopera, zapisując dwie wartości DWORD pod HKEY_LOCAL_MACHINE:

HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\AppModelUnlock
    AllowDevelopmentWithoutDevLicense = 1
    AllowAllTrustedApps               = 1

Ponieważ są to ustawienia dla całego systemu, CLI uruchamia pomocniczy proces z podwyższonymi uprawnieniami, a system Windows wyświetla monit Kontrola konta użytkownika. Nic się nie zmieni, jeśli odrzucisz monit.

Praktycznie oznacza to, że maszyna będzie:

  • Rejestrować pakiety aplikacji bezpośrednio z folderu na dysku, bez konieczności kompilowania ich do formatu MSIX ani ich podpisywania (AllowDevelopmentWithoutDevLicense).
  • Instaluj pakiety aplikacji spoza sklepu Microsoft Store, o ile są podpisane certyfikatem, któremu ufa urządzenie — w tym dowolnym certyfikatem deweloperskim w TrustedPeople (AllowAllTrustedApps).

Important

Tryb dewelopera i zaufany certyfikat dewelopera to celowe złagodzenie domyślnych ograniczeń instalacji. Ta kombinacja jest odpowiednia dla maszyn deweloperskich i testowych. Pozostaw ją wyłączoną na maszynach produkcyjnych, kioskach i udostępnionej infrastrukturze.

Kontrolowanie po włączeniu

winapp init zadaje pytanie przed zmianą i --use-defaults pomija pytanie całkowicie, pozostawiając tryb dewelopera nietknięty. Dzięki temu uruchomienia skryptowe i uruchomienia CI są bezpieczne domyślnie:

winapp init --use-defaults

Jeśli wolisz zarządzać ustawieniem samodzielnie, włącz je raz za pomocą > ustawienia System > dla deweloperów Tryb dewelopera>, a interfejs wiersza polecenia wykryje je i przejdzie dalej.

Wyłączanie

Przejdź do Ustawień > System > Dla deweloperów i wyłącz Tryb dewelopera. Jest to zalecane rozwiązanie, ponieważ Ustawienia również czyszczą powiązany stan systemu operacyjnego. Aby następnie potwierdzić wartość rejestru:

Get-ItemProperty -Path 'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\AppModelUnlock' `
    -Name AllowDevelopmentWithoutDevLicense, AllowAllTrustedApps

Wyłączenie trybu dewelopera nie powoduje usunięcia zaufanych certyfikatów ani już zainstalowanych pakietów — zobacz Usuwanie zaufanego certyfikatu.

Podpisywanie dla środowiska produkcyjnego

Certyfikat dewelopera działa tylko dla osób, które jawnie je zaufały. Aby udostępnić aplikację, podpisz ją tożsamością, której system Windows już ufa.

Wybierz tożsamość do podpisywania

  • Azure Trusted Signing — usługa podpisywania zarządzanego przez chmurę. Klucz prywatny nigdy nie znajduje się na maszynie kompilującej, więc nie ma .pfx czego chronić, ujawnić ani ręcznie wymieniać. Użyj metody winapp az-sign, która uwierzytelnia się przy użyciu standardowego łańcucha poświadczeń Azure i współpracuje z GitHub Actions OIDC lub tożsamością zarządzaną.

    winapp az-sign .\MyApp.msix

  • Certyfikat do podpisywania kodu od zaufanego urzędu certyfikacji — przekaż go do winapp sign jako drugi argument pozycyjny, a jego hasło podaj w --password. Następnie odpowiadasz za bezpieczne przechowywanie materiału klucza; przechowuj go w tokenie sprzętowym, magazynie kluczy lub magazynie sekretów dostawcy CI i nigdy nie przechowuj go w repozytorium.

  • Microsoft Store — jeśli rozpowszechniasz wyłącznie za pośrednictwem Sklepu, podpisze on pakiet dla Ciebie i nie musisz podpisać przed przesłaniem.

W każdym przypadku podmiot certyfikatu musi być zgodny z wartością Publisher w manifeście, w tym w przypadku pakietów rozrzednych.

Nie przechowuj w repozytorium sekretów używanych do podpisywania

Hasła certyfikatów powinny być przechowywane w magazynie sekretów CI, a nie w pliku konfiguracyjnym. Odczytaj je ze środowiska zamiast kodować je na stałe:

winapp sign .\MyApp.msix $env:SIGNING_CERT_PATH --password $env:SIGNING_CERT_PASSWORD

To samo dotyczy konfiguracji kompilacji przechowywanej w systemie kontroli wersji, takiej jak konfiguracja Electron Forge — zobacz Pakowanie aplikacji Electron. winapp az-sign całkowicie eliminuje ten problem, ponieważ nie trzeba przekazywać hasła.

Przed opublikowaniem

Krótka lista kontrolna dotycząca przejścia z testowania lokalnego do dystrybucji:

  • Pakiet jest podpisany przy użyciu certyfikatu wystawionego przez urząd certyfikacji, usługi Azure Trusted Signing lub przesłany do Sklepu — a nie za pomocą devcert.pfx.
  • W spakowanych danych wyjściowych nie ma pliku .pfx ani .cer.
  • Hasło certyfikatu nie znajduje się w plikach zatwierdzonych w repozytorium, skryptach budowania ani logach CI.
  • Podmiot certyfikatu pasuje do manifestu Publisher.
  • Certyfikaty programistyczne i tryb dewelopera nie są włączone na maszynach, które muszą tylko uruchamiać aplikację.

Zgłaszanie problemu z zabezpieczeniami

Aby zgłosić podatność bezpieczeństwa w samym CLI winapp, postępuj zgodnie z procedurą opisaną w SECURITY.md. Prosimy nie otwierać publicznego zgłoszenia w serwisie GitHub do zgłaszania problemów związanych z bezpieczeństwem.

  • Last updated on