Upewnij się, że pliki binarne są zaciemnione, jeśli zawierają poufne informacje
Stanowisko
Szczegóły
Składnik
Granica zaufania maszyny
Faza SDL
Wdrażanie
Odpowiednie technologie
Ogólny element
Atrybuty
Nie dotyczy
Dokumentacja
Nie dotyczy
Kroki
Upewnij się, że pliki binarne są zaciemnione, jeśli zawierają poufne informacje, takie jak tajemnice handlowe, wrażliwą logikę biznesową, która nie powinna zostać odwrócona. Ma to na celu zatrzymanie odwrotnej inżynierii zestawów. Narzędzia takie jak CryptoObfuscator mogą być używane w tym celu.
Rozważ użycie szyfrowanego systemu plików (EFS) w celu ochrony poufnych danych specyficznych dla użytkownika
Stanowisko
Szczegóły
Składnik
Granica zaufania maszyny
Faza SDL
Kompilacja
Odpowiednie technologie
Ogólny element
Atrybuty
Nie dotyczy
Dokumentacja
Nie dotyczy
Kroki
Rozważ użycie szyfrowanego systemu plików (EFS) w celu ochrony poufnych danych specyficznych dla użytkownika przed przeciwnikami z fizycznym dostępem do komputera.
Upewnij się, że poufne dane przechowywane przez aplikację w systemie plików są szyfrowane
Stanowisko
Szczegóły
Składnik
Granica zaufania maszyny
Faza SDL
Wdrażanie
Odpowiednie technologie
Ogólny element
Atrybuty
Nie dotyczy
Dokumentacja
Nie dotyczy
Kroki
Upewnij się, że poufne dane przechowywane przez aplikację w systemie plików są szyfrowane (np. przy użyciu interfejsu DPAPI), jeśli nie można wymusić szyfrowania plików
Upewnij się, że zawartość wrażliwa nie jest buforowana w przeglądarce
Stanowisko
Szczegóły
Składnik
Aplikacja internetowa
Faza SDL
Kompilacja
Odpowiednie technologie
Generic, Web Forms, MVC5, MVC6
Atrybuty
Nie dotyczy
Dokumentacja
Nie dotyczy
Kroki
Przeglądarki mogą przechowywać informacje na potrzeby buforowania i historii. Te buforowane pliki są przechowywane w folderze, na przykład w folderze Tymczasowe pliki internetowe w przypadku programu Internet Explorer. Po ponownym odwołyniu się do tych stron przeglądarka wyświetla je z pamięci podręcznej. Jeśli informacje poufne są wyświetlane użytkownikowi (takie jak jego adres, szczegóły karty kredytowej, numer ubezpieczenia społecznego lub nazwa użytkownika), te informacje mogą być przechowywane w pamięci podręcznej przeglądarki, a w związku z tym można je pobrać, sprawdzając pamięć podręczną przeglądarki lub po prostu naciskając przycisk "Wstecz". Ustaw wartość nagłówka odpowiedzi kontroli pamięci podręcznej na wartość "no-store" dla wszystkich stron.
Można to zaimplementować za pomocą filtru. Można użyć następującego przykładu:
public override void OnActionExecuting(ActionExecutingContext filterContext)
{
if (filterContext == null || (filterContext.HttpContext != null && filterContext.HttpContext.Response != null && filterContext.HttpContext.Response.IsRequestBeingRedirected))
{
//// Since this is MVC pipeline, this should never be null.
return;
}
var attributes = filterContext.ActionDescriptor.GetCustomAttributes(typeof(System.Web.Mvc.OutputCacheAttribute), false);
if (attributes == null || **Attributes**.Count() == 0)
{
filterContext.HttpContext.Response.Cache.SetNoStore();
filterContext.HttpContext.Response.Cache.SetCacheability(HttpCacheability.NoCache);
filterContext.HttpContext.Response.Cache.SetExpires(DateTime.UtcNow.AddHours(-1));
if (!filterContext.IsChildAction)
{
filterContext.HttpContext.Response.AppendHeader("Pragma", "no-cache");
}
}
base.OnActionExecuting(filterContext);
}
Szyfrowanie sekcji plików konfiguracji aplikacji internetowej zawierających poufne dane
Pliki konfiguracji, takie jak Web.config, appsettings.json są często używane do przechowywania poufnych informacji, w tym nazw użytkowników, haseł, parametry połączenia bazy danych i kluczy szyfrowania. Jeśli te informacje nie są chronione, aplikacja jest podatna na ataki lub złośliwych użytkowników uzyskujących poufne informacje, takie jak nazwy użytkowników konta i hasła, nazwy baz danych i nazwy serwerów. Na podstawie typu wdrożenia (azure/on-prem) szyfruj poufne sekcje plików konfiguracji przy użyciu interfejsu DPAPI lub usług, takich jak Azure Key Vault.
Jawne wyłączenie atrybutu HTML autouzupełniania w poufnych formularzach i danych wejściowych
Atrybut autouzupełniania określa, czy formularz powinien mieć autouzupełnianie włączone, czy wyłączone. Gdy funkcja autouzupełniania jest włączona, przeglądarka automatycznie wypełnia wartości na podstawie wartości, które użytkownik wprowadził wcześniej. Na przykład po wprowadzeniu nowej nazwy i hasła w formularzu i przesłaniu formularza przeglądarka pyta, czy hasło powinno zostać zapisane. Po wyświetleniu formularza nazwa i hasło są wypełniane automatycznie lub są wypełniane w miarę wprowadzania nazwy. Osoba atakująca z dostępem lokalnym może uzyskać hasło w postaci zwykłego tekstu z pamięci podręcznej przeglądarki. Domyślnie funkcja autouzupełniania jest włączona i musi być jawnie wyłączona.
Upewnij się, że dane poufne wyświetlane na ekranie użytkownika są maskowane
Stanowisko
Szczegóły
Składnik
Aplikacja internetowa
Faza SDL
Kompilacja
Odpowiednie technologie
Ogólny element
Atrybuty
Nie dotyczy
Dokumentacja
Nie dotyczy
Kroki
Dane poufne, takie jak hasła, numery kart kredytowych, numer SSN itp., powinny być maskowane po wyświetleniu na ekranie. Ma to na celu uniemożliwienie nieautoryzowanemu personelowi dostępu do danych (np. hasła do surfowania po ramieniu, personel pomocy technicznej wyświetlający numery użytkowników SSN). Upewnij się, że te elementy danych nie są widoczne w postaci zwykłego tekstu i są odpowiednio maskowane. Należy zachować ostrożność podczas akceptowania ich jako danych wejściowych (np. input type="password"), a także wyświetlania z powrotem na ekranie (np. wyświetlać tylko 4 ostatnie cyfry numeru karty kredytowej).
Implementowanie dynamicznego maskowania danych w celu ograniczenia nieuprzywilejowanych użytkowników narażonych na poufne dane
Celem dynamicznego maskowania danych jest ograniczenie ujawnienia poufnych danych, co uniemożliwia użytkownikom, którzy nie powinni mieć dostępu do danych. Dynamiczne maskowanie danych nie ma na celu uniemożliwienia użytkownikom bazy danych bezpośredniego łączenia się z bazą danych i uruchamiania wyczerpujących zapytań, które uwidaczniają fragmenty poufnych danych. Dynamiczne maskowanie danych stanowi uzupełnienie innych funkcji zabezpieczeń programu SQL Server (inspekcja, szyfrowanie, zabezpieczenia na poziomie wiersza...) i zdecydowanie zaleca się używanie tej funkcji w połączeniu z nimi, aby lepiej chronić poufne dane w bazie danych. Należy pamiętać, że ta funkcja jest obsługiwana tylko przez program SQL Server, począwszy od wersji 2016 i usługi Azure SQL Database.
Upewnij się, że hasła są przechowywane w formacie skrótu solnego
Hasła nie powinny być przechowywane w niestandardowych bazach danych magazynu użytkowników. Zamiast tego skróty haseł powinny być przechowywane z wartościami soli. Przed zapisaniem hasła upewnij się, że sól dla użytkownika jest zawsze unikatowa i stosujesz pętle b-crypt, s-crypt lub PBKDF2, z minimalną liczbą iteracji współczynnika pracy wynoszącą 150 000 pętli, aby wyeliminować możliwość wymuszania ataków siłowych.
Upewnij się, że poufne dane w kolumnach bazy danych są szyfrowane
Dane poufne, takie jak numery kart kredytowych, muszą być szyfrowane w bazie danych. Dane mogą być szyfrowane przy użyciu szyfrowania na poziomie kolumny lub funkcji aplikacji przy użyciu funkcji szyfrowania.
Upewnij się, że włączono szyfrowanie na poziomie bazy danych (TDE)
Funkcja Transparent Data Encryption (TDE) w programie SQL Server ułatwia szyfrowanie poufnych danych w bazie danych i ochronę kluczy używanych do szyfrowania danych przy użyciu certyfikatu. Zapobiega to używaniu danych przez nikogo, kto nie ma kluczy. Funkcja TDE chroni dane "magazynowane", co oznacza pliki danych i dzienników. Zapewnia możliwość przestrzegania wielu przepisów, przepisów i wytycznych ustanowionych w różnych branżach.
Upewnij się, że kopie zapasowe bazy danych są szyfrowane
Program SQL Server ma możliwość szyfrowania danych podczas tworzenia kopii zapasowej. Określając algorytm szyfrowania i szyfrujący (certyfikat lub klucz asymetryczny) podczas tworzenia kopii zapasowej, można utworzyć zaszyfrowany plik kopii zapasowej.
Upewnij się, że poufne dane istotne dla internetowego interfejsu API nie są przechowywane w magazynie przeglądarki
Stanowisko
Szczegóły
Składnik
Internetowy interfejs API
Faza SDL
Kompilacja
Odpowiednie technologie
MVC 5, MVC 6
Atrybuty
Dostawca tożsamości — ADFS, dostawca tożsamości — identyfikator entra firmy Microsoft
Dokumentacja
Nie dotyczy
Kroki
W niektórych implementacjach poufne artefakty istotne dla uwierzytelniania internetowego interfejsu API są przechowywane w magazynie lokalnym przeglądarki. Np. artefakty uwierzytelniania entra firmy Microsoft, takie jak adal.idtoken, adal.nonce.idtoken, adal.access.token.key, adal.token.keys, adal.state.login, adal.session.state, adal.expiration.key itp.
Wszystkie te artefakty są dostępne nawet po zamknięciu wylogowania lub przeglądarki. Jeśli przeciwnik uzyskuje dostęp do tych artefaktów, może użyć ich ponownie w celu uzyskania dostępu do chronionych zasobów (API). Upewnij się, że wszystkie poufne artefakty związane z internetowym interfejsem API nie są przechowywane w magazynie przeglądarki. W przypadkach, gdy magazyn po stronie klienta jest nieunikniony (np. aplikacje jednostronicowe (SPA), które korzystają z niejawnych przepływów OpenId Połączenie/OAuth, muszą przechowywać tokeny dostępu lokalnie), użyj opcji magazynu bez trwałości. np. preferuj sesjęStorage do elementu LocalStorage.
Przykład
Poniższy fragment kodu JavaScript pochodzi z niestandardowej biblioteki uwierzytelniania, która przechowuje artefakty uwierzytelniania w magazynie lokalnym. Takie implementacje należy unikać.
ns.AuthHelper.Authenticate = function () {
window.config = {
instance: 'https://login.microsoftonline.com/',
tenant: ns.Configurations.Tenant,
clientId: ns.Configurations.AADApplicationClientID,
postLogoutRedirectUri: window.location.origin,
cacheLocation: 'localStorage', // enable this for Internet Explorer, as sessionStorage does not work for localhost.
};
Szyfrowanie poufnych danych przechowywanych w usłudze Azure Cosmos DB
Stanowisko
Szczegóły
Składnik
Azure Document DB
Faza SDL
Kompilacja
Odpowiednie technologie
Ogólny element
Atrybuty
Nie dotyczy
Dokumentacja
Nie dotyczy
Kroki
Szyfrowanie poufnych danych na poziomie aplikacji przed zapisaniem w bazie danych dokumentów lub przechowywaniem poufnych danych w innych rozwiązaniach magazynu, takich jak Azure Storage lub Azure SQL
Szyfrowanie dysków używanych przez maszyny wirtualne przy użyciu usługi Azure Disk Encryption
Stanowisko
Szczegóły
Składnik
Granica zaufania maszyn wirtualnych IaaS platformy Azure
Usługa Azure Disk Encryption to nowa funkcja, która jest obecnie dostępna w wersji zapoznawczej. Ta funkcja umożliwia szyfrowanie dysków systemu operacyjnego i dysków danych używanych przez maszynę wirtualną IaaS. W przypadku systemu Windows dyski są szyfrowane przy użyciu standardowej technologii szyfrowania funkcją BitLocker w branży. W przypadku systemu Linux dyski są szyfrowane przy użyciu technologii DM-Crypt. Jest to zintegrowane z usługą Azure Key Vault, aby umożliwić kontrolowanie kluczy szyfrowania dysków i zarządzanie nimi. Rozwiązanie Azure Disk Encryption obsługuje następujące trzy scenariusze szyfrowania klienta:
Włącz szyfrowanie na nowych maszynach wirtualnych IaaS utworzonych na podstawie plików VHD zaszyfrowanych przez klienta i kluczy szyfrowania dostarczonych przez klienta, które są przechowywane w usłudze Azure Key Vault.
Włącz szyfrowanie na nowych maszynach wirtualnych IaaS utworzonych w witrynie Azure Marketplace.
Włącz szyfrowanie na istniejących maszynach wirtualnych IaaS już uruchomionych na platformie Azure.
Szyfrowanie wpisów tajnych w aplikacjach usługi Service Fabric
Wpisy tajne mogą być informacjami poufnymi, takimi jak parametry połączenia magazynu, hasła lub inne wartości, które nie powinny być obsługiwane w postaci zwykłego tekstu. Usługa Azure Key Vault umożliwia zarządzanie kluczami i wpisami tajnymi w aplikacjach usługi Service Fabric.
Wykonywanie modelowania zabezpieczeń i używanie jednostek biznesowych/zespołów, jeśli jest to wymagane
Stanowisko
Szczegóły
Składnik
Dynamics CRM
Faza SDL
Kompilacja
Odpowiednie technologie
Ogólny element
Atrybuty
Nie dotyczy
Dokumentacja
Nie dotyczy
Kroki
Wykonywanie modelowania zabezpieczeń i używanie jednostek biznesowych/zespołów, jeśli jest to wymagane
Minimalizowanie dostępu do funkcji udostępniania w jednostkach krytycznych
Stanowisko
Szczegóły
Składnik
Dynamics CRM
Faza SDL
Wdrażanie
Odpowiednie technologie
Ogólny element
Atrybuty
Nie dotyczy
Dokumentacja
Nie dotyczy
Kroki
Minimalizowanie dostępu do funkcji udostępniania w jednostkach krytycznych
Szkolenie użytkowników na temat czynników ryzyka związanych z funkcją dynamics CRM Share i dobrymi rozwiązaniami w zakresie zabezpieczeń
Stanowisko
Szczegóły
Składnik
Dynamics CRM
Faza SDL
Wdrażanie
Odpowiednie technologie
Ogólny element
Atrybuty
Nie dotyczy
Dokumentacja
Nie dotyczy
Kroki
Szkolenie użytkowników na temat czynników ryzyka związanych z funkcją dynamics CRM Share i dobrymi rozwiązaniami w zakresie zabezpieczeń
Uwzględnij regułę standardów programowania, która pokazuje szczegóły konfiguracji w zarządzaniu wyjątkami
Stanowisko
Szczegóły
Składnik
Dynamics CRM
Faza SDL
Wdrażanie
Odpowiednie technologie
Ogólny element
Atrybuty
Nie dotyczy
Dokumentacja
Nie dotyczy
Kroki
Dołącz regułę standardów programowania, która pokazuje szczegóły konfiguracji w zarządzaniu wyjątkami poza programowaniem. Przetestuj tę funkcję w ramach przeglądów kodu lub okresowej inspekcji.
Używanie szyfrowania usługi Azure Storage (SSE) dla danych magazynowanych (wersja zapoznawcza)
Szyfrowanie usługi Azure Storage (SSE) dla danych magazynowanych pomaga chronić i chronić dane w celu spełnienia zobowiązań organizacji w zakresie zabezpieczeń i zgodności. Przy użyciu tej funkcji usługa Azure Storage automatycznie szyfruje dane przed trwałym wprowadzeniem ich do magazynu i odszyfrowuje je przed pobraniem. Szyfrowanie, odszyfrowywanie i zarządzanie kluczami jest całkowicie niewidoczne dla użytkowników. Funkcja SSE ma zastosowanie tylko do blokowych obiektów blob, stronicowych obiektów blob i uzupełnialnych obiektów blob. Inne typy danych, w tym tabele, kolejki i pliki, nie będą szyfrowane.
Przepływ pracy szyfrowania i odszyfrowywania:
Klient włącza szyfrowanie na koncie magazynu
Gdy klient zapisuje nowe dane (PUT Blob, PUT Block, PUT Page itp.) do usługi Blob Storage; każdy zapis jest szyfrowany przy użyciu 256-bitowego szyfrowania AES, jednego z najsilniejszych dostępnych szyfrów blokowych
Gdy klient musi uzyskać dostęp do danych (GET Blob itp.), dane są automatycznie odszyfrowywane przed powrotem do użytkownika
Jeśli szyfrowanie jest wyłączone, nowe zapisy nie są już szyfrowane, a istniejące zaszyfrowane dane pozostają zaszyfrowane do czasu ponownego zapisania przez użytkownika. Gdy szyfrowanie jest włączone, zapisy w usłudze Blob Storage będą szyfrowane. Stan danych nie zmienia się, przełączając się między włączaniem/wyłączaniem szyfrowania dla konta magazynu
Wszystkie klucze szyfrowania są przechowywane, szyfrowane i zarządzane przez firmę Microsoft
Należy pamiętać, że w tej chwili klucze używane do szyfrowania są zarządzane przez firmę Microsoft. Firma Microsoft generuje klucze pierwotnie i zarządza bezpiecznym magazynem kluczy, a także regularną rotacją zdefiniowaną przez wewnętrzne zasady firmy Microsoft. W przyszłości klienci będą mogli zarządzać własnymi kluczami szyfrowania i udostępniać ścieżkę migracji z kluczy zarządzanych przez firmę Microsoft do kluczy zarządzanych przez klienta.
Używanie szyfrowania po stronie klienta do przechowywania poufnych danych w usłudze Azure Storage
Biblioteka klienta usługi Azure Storage dla pakietu Nuget platformy .NET obsługuje szyfrowanie danych w aplikacjach klienckich przed przekazaniem do usługi Azure Storage i odszyfrowywaniem danych podczas pobierania do klienta. Biblioteka obsługuje również integrację z magazynem kluczy Azure do zarządzania kluczami konta magazynu. Poniżej przedstawiono krótki opis działania szyfrowania po stronie klienta:
Zestaw SDK klienta usługi Azure Storage generuje klucz szyfrowania zawartości (CEK), który jest jednorazowym kluczem symetrycznym
Dane klienta są szyfrowane przy użyciu tego klucza CEK
Klucz CEK jest następnie opakowany (zaszyfrowany) przy użyciu klucza szyfrowania klucza (KEK). Klucz KEK jest identyfikowany przez identyfikator klucza i może być parą kluczy asymetrycznych lub kluczem symetrycznym i może być zarządzany lokalnie lub przechowywany w usłudze Azure Key Vault. Sam klient magazynu nigdy nie ma dostępu do klucza KEK. Po prostu wywołuje algorytm opakowujący klucze udostępniany przez usługę Key Vault. Klienci mogą zdecydować się na użycie dostawców niestandardowych do zawijania kluczy/rozpakuj, jeśli chcą
Zaszyfrowane dane są następnie przekazywane do usługi Azure Storage. Zapoznaj się z linkami w sekcji odwołania, aby uzyskać szczegółowe informacje o implementacji niskiego poziomu.
Szyfrowanie poufnych lub danych pii zapisanych w magazynie lokalnym na telefonach
Jeśli aplikacja zapisuje poufne informacje, takie jak dane osobowe użytkownika (adres e-mail, numer telefonu, imię, nazwisko, preferencje itp.) — w systemie plików dla urządzeń przenośnych należy go zaszyfrować przed zapisaniem w lokalnym systemie plików. Jeśli aplikacja jest aplikacją dla przedsiębiorstw, zapoznaj się z możliwością publikowania aplikacji przy użyciu usługi Windows Intune.
Przykład
Usługę Intune można skonfigurować przy użyciu następujących zasad zabezpieczeń w celu ochrony poufnych danych:
Require encryption on mobile device
Require encryption on storage cards
Allow screen capture
Przykład
Jeśli aplikacja nie jest aplikacją dla przedsiębiorstw, użyj udostępnionego przez platformę magazynu kluczy, pęku kluczy do przechowywania kluczy szyfrowania, przy użyciu których można wykonać operację kryptograficzną w systemie plików. Poniższy fragment kodu pokazuje, jak uzyskać dostęp do klucza z pęku kluczy przy użyciu platformy xamarin:
protected static string EncryptionKey
{
get
{
if (String.IsNullOrEmpty(_Key))
{
var query = new SecRecord(SecKind.GenericPassword);
query.Service = NSBundle.MainBundle.BundleIdentifier;
query.Account = "UniqueID";
NSData uniqueId = SecKeyChain.QueryAsData(query);
if (uniqueId == null)
{
query.ValueData = NSData.FromString(System.Guid.NewGuid().ToString());
var err = SecKeyChain.Add(query);
_Key = query.ValueData.ToString();
}
else
{
_Key = uniqueId.ToString();
}
}
return _Key;
}
}
Zaciemniaj wygenerowane pliki binarne przed dystrybucją do użytkowników końcowych
Wygenerowane pliki binarne (zestawy w pliku apk) powinny być zaciemnione, aby zatrzymać odwrotną inżynierię zestawów. Narzędzia takie jak CryptoObfuscator mogą być używane w tym celu.
Ustaw wartość clientCredentialType na certyfikat lub system Windows
Użycie tokenu UsernameToken z hasłem w postaci zwykłego tekstu za pośrednictwem niezaszyfrowanego kanału uwidacznia hasło osobom atakującym, którzy mogą wąchać komunikaty PROTOKOŁU SOAP. Dostawcy usług korzystający z elementu UsernameToken mogą akceptować hasła wysyłane w postaci zwykłego tekstu. Wysyłanie haseł w postaci zwykłego tekstu za pośrednictwem niezaszyfrowanego kanału może uwidocznić poświadczenia osobom atakującym, którzy mogą wąchać komunikat PROTOKOŁU SOAP.
Przykład
Następująca konfiguracja dostawcy usług WCF używa tokenu UsernameToken:
Ustaw wartość clientCredentialType na certyfikat lub system Windows.
Tryb zabezpieczeń WCF nie jest włączony
Stanowisko
Szczegóły
Składnik
WCF
Faza SDL
Kompilacja
Odpowiednie technologie
Generic, .NET Framework 3
Atrybuty
Tryb zabezpieczeń — transport, tryb zabezpieczeń — komunikat
Dokumentacja
MSDN, Fortify Kingdom, Fundamentals of WCF Security CoDe Magazine
Kroki
Nie zdefiniowano zabezpieczeń transportu ani wiadomości. Aplikacje, które przesyłają komunikaty bez zabezpieczeń transportu lub wiadomości, nie mogą zagwarantować integralności ani poufności komunikatów. Gdy powiązanie zabezpieczeń programu WCF jest ustawione na Wartość Brak, zabezpieczenia transportu i komunikatów są wyłączone.
Przykład
Poniższa konfiguracja ustawia tryb zabezpieczeń na Wartość Brak.
Tryb zabezpieczeń we wszystkich powiązaniach usługi istnieje pięć możliwych trybów zabezpieczeń:
Brak. Wyłącza zabezpieczenia.
Transportu. Używa zabezpieczeń transportu do wzajemnego uwierzytelniania i ochrony komunikatów.
Wiadomość. Używa zabezpieczeń komunikatów do wzajemnego uwierzytelniania i ochrony komunikatów.
Zarówno. Umożliwia podawanie ustawień zabezpieczeń na poziomie transportu i komunikatów (obsługuje to tylko msMQ).
Transportwithmessagecredential. Poświadczenia są przekazywane za pomocą komunikatu, ochrony komunikatów i uwierzytelniania serwera są dostarczane przez warstwę transportu.
TransportCredentialOnly. Poświadczenia klienta są przekazywane z warstwą transportu i nie są stosowane żadne zabezpieczenia komunikatów. Użyj zabezpieczeń transportu i wiadomości, aby chronić integralność i poufność wiadomości. Poniższa konfiguracja informuje usługę o użyciu zabezpieczeń transportu z poświadczeniami komunikatu.