Ramka zabezpieczeń: kryptografia | Łagodzenia

Produkt/usługa	Artykuł
Aplikacja internetowa	Używaj tylko zatwierdzonych szyfrów bloków symetrycznych i długości kluczy Używanie zatwierdzonych trybów szyfrowania blokowego i wektorów inicjowania dla szyfrów symetrycznych Używanie zatwierdzonych algorytmów asymetrycznych, długości kluczy i wypełnienia Używanie zatwierdzonych generatorów liczb losowych Nie używaj szyfrów strumienia symetrycznego Użyj zatwierdzonych algorytmów skrótów MAC/HMAC/z kluczem Używanie tylko zatwierdzonych funkcji skrótów kryptograficznych
Baza danych	Używanie algorytmów silnego szyfrowania do szyfrowania danych w bazie danych Pakiety usług SSIS powinny być szyfrowane i podpisane cyfrowo Dodawanie podpisu cyfrowego do zabezpieczanych krytycznych baz danych Ochrona kluczy szyfrowania za pomocą programu SQL Server EKM Użyj funkcji AlwaysEncrypted, jeśli klucze szyfrowania nie powinny być ujawniane aparatowi bazy danych
Urządzenie IoT	Bezpieczne przechowywanie kluczy kryptograficznych na urządzeniu IoT
Bramka chmury IoT	Generowanie losowego klucza symetrycznego o wystarczającej długości do uwierzytelniania w usłudze IoT Hub
Klient mobilny Dynamics CRM	Upewnij się, że obowiązują zasady zarządzania urządzeniami, które wymagają użycia numeru PIN i umożliwiają zdalne wyczyszczenie
Klient programu Outlook programu Dynamics CRM	Upewnij się, że zasady zarządzania urządzeniami są spełnione, które wymagają numeru PIN/hasła/automatycznego blokowania i szyfrują wszystkie dane (np. funkcja BitLocker)
Serwer tożsamości	Upewnij się, że klucze do podpisywania są odświeżane podczas korzystania z Identity Serwera Upewnij się, że kryptograficznie silny identyfikator klienta, klucz tajny klienta jest używany w programie Identity Server

Używaj tylko zatwierdzonych szyfrów bloków symetrycznych i długości kluczy

Nazwa	Szczegóły
Składnik	Aplikacja internetowa
Faza SDL	Zbuduj
Zastosowalne technologie	Generyczny
atrybutów	N/A
Dokumentacja	N/A
Etapy	Produkty muszą używać tylko tych symetrycznych szyfrów bloków i skojarzonych długości kluczy, które zostały jawnie zatwierdzone przez doradcę kryptograficznego w organizacji. Zatwierdzone algorytmy symetryczne w firmie Microsoft obejmują następujące szyfry blokowe: W przypadku nowego kodu AES-128, AES-192 i AES-256 są dopuszczalne Aby uzyskać zgodność z poprzednim kodem, trójkluczowe 3DES jest dopuszczalne W przypadku produktów korzystających z szyfrów bloków symetrycznych: Usługa Advanced Encryption Standard (AES) jest wymagana dla nowego kodu Potrójny standard szyfrowania danych z użyciem trzech kluczy (3DES) jest dopuszczalny w istniejącym kodzie w celu zachowania zgodności wstecznej. Wszystkie inne szyfry blokowe, w tym RC2, DES, 2 Key 3DES, DESX i Skipjack, mogą być używane tylko do odszyfrowywania starych danych i muszą zostać zastąpione w przypadku użycia szyfrowania W przypadku algorytmów szyfrowania bloków symetrycznych wymagana jest minimalna długość klucza wynosząca 128 bitów. Jedynym algorytmem szyfrowania bloku zalecanym dla nowego kodu jest AES-128, AES-192 i AES-256 są dopuszczalne) Funkcja 3DES z trzema kluczami jest obecnie akceptowalna, jeśli jest już używana w istniejącym kodzie; zalecane jest przejście do AES. DES, DESX, RC2 i Skipjack nie są już uważane za bezpieczne. Te algorytmy mogą być używane tylko do odszyfrowywania istniejących danych ze względu na zgodność z poprzednimi wersjami, a dane powinny być ponownie szyfrowane przy użyciu zalecanego szyfrowania blokowego Należy pamiętać, że wszystkie symetryczne szyfry bloków muszą być używane z zatwierdzonym trybem szyfrowania, który wymaga użycia odpowiedniego wektora inicjalizacji (IV). Odpowiednie IV zazwyczaj jest losowym numerem i nigdy stałą wartością. Użycie starszych lub w inny sposób niezatwierdzonych algorytmów kryptograficznych i mniejszych długości kluczy do odczytywania istniejących danych (w przeciwieństwie do zapisywania nowych danych) może być dozwolone po przejrzeniu tablicy kryptograficznej organizacji. Należy jednak zgłosić wyjątek w odniesieniu do tego wymagania. Produkty powinny ostrzegać administratorów w przypadku wdrożeń w przedsiębiorstwie, gdy słabe szyfrowanie jest używane do odczytywania danych. Takie ostrzeżenia powinny być objaśniające i możliwe do działania. W niektórych przypadkach właściwe może być, aby zasady grupy kontrolowały użycie słabej kryptografii. Dozwolone algorytmy platformy .NET na potrzeby zarządzanej elastyczności kryptograficznej (w kolejności preferencji) AesCng (zgodne ze standardem FIPS) AuthenticatedAesCng (zgodne ze standardem FIPS) AESCryptoServiceProvider (zgodne ze standardem FIPS) AESManaged (niezgodne ze standardem FIPS) Należy pamiętać, że żaden z tych algorytmów nie można określić za pomocą SymmetricAlgorithm.Create metod lub CryptoConfig.CreateFromName bez wprowadzania zmian w pliku machine.config. Należy również pamiętać, że AES w wersjach platformy .NET wcześniejszych niż .NET 3.5 ma nazwę RijndaelManaged, a AesCng i AuthenticatedAesCng są > dostępne za pośrednictwem programu CodePlex i wymagają CNG w podstawowym systemie operacyjnym.

Używanie zatwierdzonych trybów szyfrowania blokowego i wektorów inicjowania dla szyfrów symetrycznych

Nazwa	Szczegóły
Składnik	Aplikacja internetowa
Faza SDL	Zbuduj
Zastosowalne technologie	Generyczny
atrybutów	N/A
Dokumentacja	N/A
Etapy	Wszystkie symetryczne szyfry bloków muszą być używane z zatwierdzonym trybem szyfrowania symetrycznego. Jedynymi zatwierdzonymi trybami są CBC i CTS. W szczególności należy unikać trybu działania elektronicznej książki kodowej (ECB); korzystanie z ECB wymaga przeglądu Komisji ds. kryptografii organizacji. Wszystkie zastosowania OFB, CFB, CTR, CCM i GCM lub dowolnego innego trybu szyfrowania muszą być przeglądane przez organizację Crypto Board. Ponowne użycie tego samego wektora inicjowania (IV) przy użyciu szyfrów blokowych w trybach "szyfrowania przesyłania strumieniowego", takich jak CTR, może spowodować ujawnienie zaszyfrowanych danych. Wszystkie szyfry bloków symetrycznych muszą być również używane z odpowiednim wektorem inicjalizacji (IV). Właściwy IV to kryptograficznie silna, losowa liczba i nigdy stała wartość.

Używanie zatwierdzonych algorytmów asymetrycznych, długości kluczy i wypełnienia

Nazwa	Szczegóły
Składnik	Aplikacja internetowa
Faza SDL	Zbuduj
Zastosowalne technologie	Generyczny
atrybutów	N/A
Dokumentacja	N/A
Etapy	Stosowanie zakazanych algorytmów kryptograficznych powoduje znaczne ryzyko bezpieczeństwa produktów i należy go unikać. Produkty muszą używać tylko tych algorytmów kryptograficznych oraz skojarzonych długości kluczy i wypełnień, które zostały jawnie zatwierdzone przez Zespół ds. Kryptografii twojej organizacji. RSA — może służyć do szyfrowania, wymiany kluczy i podpisu. Szyfrowanie RSA musi używać tylko trybów dopełniania OAEP lub RSA-KEM. Istniejący kod może używać trybu uzupełniania PKCS #1 w wersji 1.5 tylko w celu zapewnienia zgodności. Używanie zero uzupełnień jest jawnie zakazane. Klucze >= 2048 bitów są wymagane dla nowego kodu. Istniejący kod może obsługiwać klucze < 2048 bitów jedynie w ramach zgodności z poprzednimi wersjami, po przeprowadzeniu przeglądu przez Radę Kryptograficzną Twojej organizacji. Klucze < 1024 bitów mogą być używane tylko do odszyfrowywania/weryfikowania starych danych i muszą zostać zastąpione, jeśli są używane do operacji szyfrowania lub podpisywania ECDSA — może być używany tylko do obsługi podpisu. Usługa ECDSA z kluczami >=256-bitowymi jest wymagana dla nowego kodu. Podpisy oparte na ECDSA muszą używać jednej z trzech zatwierdzonych krzywych NIST (P-256, P-384 lub P521). Krzywe, które zostały dokładnie przeanalizowane, mogą być używane dopiero po przeglądzie przez Crypto Board w Twojej organizacji. ECDH — może być używany tylko do wymiany kluczy. Usługa ECDH z kluczami >=256-bitowymi jest wymagana dla nowego kodu. Wymiana kluczy oparta na ECDH musi używać jednej z trzech zatwierdzonych krzywych NIST (P-256, P-384 lub P521). Krzywe, które zostały dokładnie przeanalizowane, mogą być używane dopiero po przeglądzie przez Crypto Board w Twojej organizacji. DSA — może być akceptowalna po przejrzeniu i zatwierdzeniu przez Radę ds. Kryptografii. Skontaktuj się z doradcą ds. zabezpieczeń, aby zaplanować przegląd rady kryptograficznej organizacji. Jeśli użycie DSA jest zatwierdzone, należy pamiętać, że należy zakazać używania kluczy mniejszych niż 2048 bitów długości. CNG obsługuje 2048-bitowe i większe długości kluczy począwszy od systemu Windows 8. Diffie-Hellman — może być używany tylko do zarządzania kluczami sesji. Długość >klucza = 2048 bitów jest wymagana dla nowego kodu. Istniejący kod może obsługiwać długości kluczy < 2048 bitów tylko w przypadku zgodności wstecznej po przejrzeniu przez Komisję ds. Kryptografii w Twojej organizacji. Klucze < 1024-bitowe mogą nie być używane.

Używanie zatwierdzonych generatorów liczb losowych

Nazwa	Szczegóły
Składnik	Aplikacja internetowa
Faza SDL	Zbuduj
Zastosowalne technologie	Generyczny
atrybutów	N/A
Dokumentacja	N/A
Etapy	Produkty muszą używać zatwierdzonych generatorów liczb losowych. Funkcje pseudolosowe, takie jak funkcja środowiska uruchomieniowego języka C rand, klasa System.Random w .NET Framework lub funkcje systemowe, takie jak GetTickCount, nie mogą być używane w takim kodzie. Stosowanie algorytmu generatora liczb losowych z podwójną krzywą wielokropkową (DUAL_EC_DRBG) jest zabronione CNG — BCryptGenRandom (zaleca się użycie flagi BCRYPT_USE_SYSTEM_PREFERRED_RNG, chyba że wywołujący może działać na dowolnym poziomie IRQL większym niż 0 [czyli PASSIVE_LEVEL]) CAPI — cryptGenRandom Win32/64- RtlGenRandom (nowe implementacje powinny używać BCryptGenRandom lub CryptGenRandom) * rand_s * SystemPrng (dla trybu jądra) . NET — RNGCryptoServiceProvider lub RNGCng Aplikacje ze Sklepu Windows — Windows.Security.Cryptography.CryptographicBuffer.GenerateRandom lub . GenerateRandomNumber Apple OS X (10.7+)/iOS(2.0+)- int SecRandomCopyBytes (SecRandomRef losowy, liczba size_t, uint8_t *bajty ) Apple OS X (<10.7) — użyj /dev/random, aby pobrać losowe liczby Java(w tym kod Java systemu Google Android) — klasa java.security.SecureRandom. Należy pamiętać, że w przypadku systemu Android 4.3 (Jelly Bean), programiści muszą postępować zgodnie z zalecanym obejściem dla systemu Android i zaktualizować swoje aplikacje, aby jawnie zainicjować PRNG z wykorzystaniem entropii z /dev/urandom lub /dev/random.

Nie używaj szyfrów strumienia symetrycznego

Nazwa	Szczegóły
Składnik	Aplikacja internetowa
Faza SDL	Zbuduj
Zastosowalne technologie	Generyczny
atrybutów	N/A
Dokumentacja	N/A
Etapy	Szyfry strumieni symetrycznych, takie jak RC4, nie mogą być używane. Zamiast szyfrów strumienia symetrycznego produkty powinny używać szyfru blokowego, w szczególności AES o długości klucza co najmniej 128 bitów.

Użyj zatwierdzonych algorytmów MAC/HMAC/skróty z kluczem

Nazwa	Szczegóły
Składnik	Aplikacja internetowa
Faza SDL	Zbuduj
Zastosowalne technologie	Generyczny
atrybutów	N/A
Dokumentacja	N/A
Etapy	Produkty muszą używać tylko zatwierdzonego kodu uwierzytelniania komunikatów (MAC) lub algorytmów uwierzytelniania komunikatów opartych na skrótach (HMAC). Kod uwierzytelniania komunikatów (MAC) jest elementem informacji dołączonym do wiadomości, która umożliwia odbiorcy zweryfikowanie zarówno autentyczności nadawcy, jak i integralności wiadomości przy użyciu klucza tajnego. Korzystanie z MAC opartego na skrótach (HMAC) lub MAC opartego na szyfrach blokowych jest dopuszczalne, o ile wszystkie podstawowe algorytmy kryptograficzne oparte na skrótach lub szyfrowaniu symetrycznym są również zatwierdzone do użycia; obecnie obejmuje to funkcje HMAC-SHA2 (HMAC-SHA256, HMAC-SHA384 i HMAC-SHA512) oraz kody MAC CMAC/OMAC1 i OMAC2 oparte na szyfrach blokowych, które są oparte na AES. Korzystanie z HMAC-SHA1 może być dopuszczalne w celu zachowania zgodności platformy, ale konieczne będzie zgłoszenie wyjątku do tej procedury i poddanie się przeglądowi kryptograficznemu organizacji. Skracanie HMAC do mniej niż 128 bitów nie jest dozwolone. Użycie metod klienta do wyznaczania wartości skrótu klucza i danych nie jest zatwierdzane i musi przejść przegląd Crypto Board organizacji przed użyciem.

Używanie tylko zatwierdzonych funkcji skrótów kryptograficznych

Nazwa	Szczegóły
Składnik	Aplikacja internetowa
Faza SDL	Zbuduj
Zastosowalne technologie	Generyczny
atrybutów	N/A
Dokumentacja	N/A
Etapy	Produkty muszą używać rodziny algorytmów wyznaczania wartości skrótu SHA-2 (SHA256, SHA384 i SHA512). Jeśli potrzebny jest krótszy skrót, taki jak 128-bitowa długość danych wyjściowych, aby dopasować strukturę danych zaprojektowaną z krótszym skrótem MD5, zespoły produktów mogą obcinać jeden z skrótów SHA2 (zazwyczaj SHA256). Należy pamiętać, że SHA384 jest obciętą wersją SHA512. Skracanie skrótów kryptograficznych w celach bezpieczeństwa do mniej niż 128 bitów nie jest dozwolone. Nowy kod nie może używać algorytmów wyznaczania wartości skrótu MD2, MD4, MD5, SHA-0, SHA-1 lub RIPEMD. Kolizje skrótów są wykonalne obliczeniowo dla tych algorytmów, co skutecznie je łamie. Dozwolone algorytmy skrótów platformy .NET dla zarządzanej elastyczności kryptograficznej (w kolejności preferencji): SHA512Cng (zgodne ze standardem FIPS) SHA384Cng (zgodne ze standardem FIPS) SHA256Cng (zgodne ze standardem FIPS) SHA512Managed (niezgodne ze standardem FIPS) (użyj algorytmu SHA512 jako nazwy algorytmu w wywołaniach metody HashAlgorithm.Create lub CryptoConfig.CreateFromName) SHA384Managed (niezgodne ze standardem FIPS) (użyj algorytmu SHA384 jako nazwy algorytmu w wywołaniach metody HashAlgorithm.Create lub CryptoConfig.CreateFromName) SHA256Managed (niezgodne ze standardem FIPS) (użyj algorytmu SHA256 jako nazwy algorytmu w wywołaniach metody HashAlgorithm.Create lub CryptoConfig.CreateFromName) SHA512CryptoServiceProvider (zgodne ze standardem FIPS) SHA256CryptoServiceProvider (zgodne ze standardem FIPS) SHA384CryptoServiceProvider (zgodne ze standardem FIPS)

Używanie algorytmów silnego szyfrowania do szyfrowania danych w bazie danych

Nazwa	Szczegóły
Składnik	Baza danych
Faza SDL	Zbuduj
Zastosowalne technologie	Generyczny
atrybutów	N/A
Dokumentacja	Wybieranie algorytmu szyfrowania
Etapy	Algorytmy szyfrowania definiują przekształcenia danych, których nie można łatwo odwrócić przez nieautoryzowanych użytkowników. SQL Server umożliwia administratorom i programistom wybór spośród kilku algorytmów, w tym DES, Triple DES, TRIPLE_DES_3KEY, RC2, RC4 o długości 128 bitów, DESX, AES o długości 128 bitów, AES o długości 192 bitów oraz AES o długości 256 bitów.

Pakiety usług SSIS powinny być szyfrowane i podpisane cyfrowo

Nazwa	Szczegóły
Składnik	Baza danych
Faza SDL	Zbuduj
Zastosowalne technologie	Generyczny
atrybutów	N/A
Dokumentacja	Identyfikowanie źródła pakietów za pomocą podpisów cyfrowych, Łagodzenie zagrożeń i luk w zabezpieczeniach (Integration Services)
Etapy	Źródłem pakietu jest osoba lub organizacja, która utworzyła pakiet. Uruchomienie pakietu z nieznanego lub niezaufanego źródła może być ryzykowne. Aby zapobiec nieautoryzowanemu manipulowaniu pakietami usług SSIS, należy używać podpisów cyfrowych. Ponadto, aby zapewnić poufność pakietów podczas magazynowania/przesyłania, pakiety usług SSIS muszą być szyfrowane

Dodawanie podpisu cyfrowego do zabezpieczanych krytycznych baz danych

Nazwa	Szczegóły
Składnik	Baza danych
Faza SDL	Zbuduj
Zastosowalne technologie	Generyczny
atrybutów	N/A
Dokumentacja	DODAJ PODPIS (Transact-SQL)
Etapy	W przypadkach, gdy należy zweryfikować integralność krytycznej bazy danych zabezpieczanej, należy użyć podpisów cyfrowych. Elementy zabezpieczeń baz danych, takie jak procedura składowana, funkcja, zestawienie czy wyzwalacz, mogą być podpisane cyfrowo. Poniżej przedstawiono przykład, kiedy może to być przydatne: Załóżmy, że niezależny dostawca oprogramowania udzielił pomocy technicznej dla oprogramowania dostarczonego do jednego z ich klientów. Przed udzieleniem wsparcia, niezależny dostawca oprogramowania chciałby upewnić się, że baza danych, którą można zabezpieczyć w oprogramowaniu, nie została naruszona ani przez pomyłkę, ani przez złośliwą próbę. Jeśli obiekt zabezpieczany jest podpisany cyfrowo, niezależny dostawca oprogramowania może zweryfikować jego podpis cyfrowy i potwierdzić jego integralność.

Ochrona kluczy szyfrowania za pomocą programu SQL Server EKM

Nazwa	Szczegóły
Składnik	Baza danych
Faza SDL	Zbuduj
Zastosowalne technologie	Generyczny
atrybutów	N/A
Dokumentacja	Rozszerzone zarządzanie kluczami programu SQL Server (EKM),rozszerzone zarządzanie kluczami przy użyciu usługi Azure Key Vault (SQL Server)
Etapy	Zarządzanie kluczami rozszerzalnymi programu SQL Server umożliwia przechowywanie kluczy szyfrowania, które chronią pliki bazy danych w urządzeniu poza urządzeniem, takim jak karta inteligentna, urządzenie USB lub moduł EKM/HSM. Umożliwia to również ochronę danych od administratorów bazy danych (z wyjątkiem członków grupy sysadmin). Dane mogą być szyfrowane przy użyciu kluczy szyfrowania, do których dostęp ma tylko użytkownik bazy danych w zewnętrznym module EKM/HSM.

Użyj funkcji AlwaysEncrypted, jeśli klucze szyfrowania nie powinny być ujawniane aparatowi bazy danych

Nazwa	Szczegóły
Składnik	Baza danych
Faza SDL	Zbuduj
Zastosowalne technologie	SQL Azure, On-Prem
atrybutów	Wersja SQL — wersja 12, MsSQL2016
Dokumentacja	Always Encrypted (Silnik bazy danych)
Etapy	Funkcja Always Encrypted to funkcja przeznaczona do ochrony poufnych danych, takich jak numery kart kredytowych lub numery identyfikacyjne krajowe/regionalne (np. numery ubezpieczenia społecznego w USA), przechowywane w bazach danych usługi Azure SQL Database lub sql Server. Funkcja Always Encrypted umożliwia klientom szyfrowanie poufnych danych wewnątrz aplikacji klienckich i nigdy nie ujawnia kluczy szyfrowania aparatowi bazy danych (baza danych SQL lub program SQL Server). W rezultacie funkcja Always Encrypted zapewnia separację między tymi, którzy są właścicielami danych (i mogą je wyświetlać) oraz tymi, którzy zarządzają danymi (ale nie powinni mieć dostępu)

Bezpieczne przechowywanie kluczy kryptograficznych na urządzeniu IoT

Nazwa	Szczegóły
Składnik	Urządzenie IoT
Faza SDL	Zbuduj
Zastosowalne technologie	Generyczny
atrybutów	System operacyjny urządzenia — Windows IoT Core, łączność urządzeń — zestawy SDK urządzeń Azure IoT
Dokumentacja	TPM w systemie Windows IoT Core, Konfigurowanie TPM w systemie Windows IoT Core, SDK urządzeń IoT Azure TPM
Etapy	Klucze prywatne symetryczne lub certyfikatów przechowuj bezpiecznie w magazynie chronionym sprzętowo, takim jak moduł TPM lub mikroukład karty chipowej. System Windows 10 IoT Core obsługuje użytkownika modułu TPM i istnieje kilka zgodnych modułów TPM, których można użyć: dyskretny moduł TPM (dTPM). Zaleca się używanie oprogramowania układowego lub dyskretnego modułu TPM. Programowy moduł TPM powinien być używany tylko do celów programistycznych i testowych. Po udostępnieniu modułu TPM i aprowizowaniu w nim kluczy kod, który generuje token, powinien zostać zapisany bez konieczności kodowania w nim żadnych poufnych informacji.

Przykład

TpmDevice myDevice = new TpmDevice(0);
// Use logical device 0 on the TPM 
string hubUri = myDevice.GetHostName(); 
string deviceId = myDevice.GetDeviceId(); 
string sasToken = myDevice.GetSASToken(); 

var deviceClient = DeviceClient.Create( hubUri, AuthenticationMethodFactory. CreateAuthenticationWithToken(deviceId, sasToken), TransportType.Amqp); 

Jak widać, klucz podstawowy urządzenia nie jest obecny w kodzie. Zamiast tego jest przechowywany w module TPM w gnieździe 0. Urządzenie TPM generuje krótkotrwały token SAS, który jest następnie używany do nawiązywania połączenia z usługą IoT Hub.

Generowanie losowego klucza symetrycznego o wystarczającej długości do uwierzytelniania w usłudze IoT Hub

Nazwa	Szczegóły
Składnik	Bramka chmurowa IoT
Faza SDL	Zbuduj
Zastosowalne technologie	Generyczny
atrybutów	Wybór bramy — Azure IoT Hub
Dokumentacja	N/A
Etapy	Usługa IoT Hub zawiera rejestr tożsamości urządzenia i podczas aprowizowania urządzenia automatycznie generuje losowy klucz symetryczny. Zaleca się użycie tej funkcji rejestru tożsamości usługi Azure IoT Hub w celu wygenerowania klucza używanego do uwierzytelniania. Usługa IoT Hub umożliwia również określenie klucza podczas tworzenia urządzenia. Jeśli klucz jest generowany poza usługą IoT Hub podczas aprowizacji urządzeń, zaleca się utworzenie losowego klucza symetrycznego lub co najmniej 256 bitów.

Upewnij się, że obowiązują zasady zarządzania urządzeniami, które wymagają użycia numeru PIN i umożliwiają zdalne wyczyszczenie

Nazwa	Szczegóły
Składnik	Klient mobilny Dynamics CRM
Faza SDL	Wdrożenie
Zastosowalne technologie	Generyczny
atrybutów	N/A
Dokumentacja	N/A
Etapy	Upewnij się, że obowiązują zasady zarządzania urządzeniami, które wymagają użycia numeru PIN i umożliwiają zdalne wyczyszczenie

Upewnij się, że zasady zarządzania urządzeniami są spełnione, które wymagają numeru PIN/hasła/automatycznego blokowania i szyfrują wszystkie dane (np. funkcja BitLocker)

Nazwa	Szczegóły
Składnik	Klient programu Outlook programu Dynamics CRM
Faza SDL	Zbuduj
Zastosowalne technologie	Generyczny
atrybutów	N/A
Dokumentacja	N/A
Etapy	Upewnij się, że zasady zarządzania urządzeniami są spełnione, które wymagają numeru PIN/hasła/automatycznego blokowania i szyfrują wszystkie dane (np. funkcja BitLocker)

Upewnij się, że klucze podpisywania są przerzucane podczas korzystania z programu Identity Server

Nazwa	Szczegóły
Składnik	Serwer tożsamości
Faza SDL	Wdrożenie
Zastosowalne technologie	Generyczny
atrybutów	N/A
Dokumentacja	N/A
Etapy	Upewnij się, że klucze podpisujące są wymieniane podczas korzystania z Identity Server. Link w sekcji referencyjnej wyjaśnia, jak należy to zaplanować bez powodowania awarii aplikacji korzystających z usługi Identity Server.

Upewnij się, że kryptograficznie silny identyfikator klienta, klucz tajny klienta jest używany w programie Identity Server

Nazwa	Szczegóły
Składnik	Serwer tożsamości
Faza SDL	Zbuduj
Zastosowalne technologie	Generyczny
atrybutów	N/A
Dokumentacja	N/A
Etapy	Upewnij się, że kryptograficznie silny identyfikator klienta klucz tajny klienta jest używany w programie Identity Server. Podczas generowania identyfikatora klienta i wpisu tajnego należy użyć następujących wskazówek: Generowanie losowego identyfikatora GUID jako identyfikatora klienta Wygeneruj kryptograficznie losowy klucz 256-bitowy jako tajny ключ