Ujistěte se, že binární soubory jsou obfuskované, pokud obsahují citlivé informace.
Název
Detaily
Součást
Hranice důvěryhodnosti počítače
Fáze SDL
Nasazení
Použitelné technologie
Obecná
Atributy
–
Odkazy
–
Kroky
Zajistěte, aby binární soubory byly obfuskovány, pokud obsahují citlivé informace, jako jsou obchodní tajemství, citlivá obchodní logika, která by neměla být obrácena. Cílem je zastavit zpětnou přípravu sestavení. K tomuto účelu se dají použít nástroje, jako CryptoObfuscator je tento účel.
Zvažte použití systému souborů EFS (Encrypted File System) k ochraně důvěrných dat specifických pro uživatele.
Název
Detaily
Součást
Hranice důvěryhodnosti počítače
Fáze SDL
Build
Použitelné technologie
Obecná
Atributy
–
Odkazy
–
Kroky
Zvažte použití systému souborů EFS (Encrypted File System) k ochraně důvěrných dat specifických pro uživatele před nežádoucími osobami s fyzickým přístupem k počítači.
Ujistěte se, že jsou citlivá data uložená aplikací v systému souborů zašifrovaná.
Název
Detaily
Součást
Hranice důvěryhodnosti počítače
Fáze SDL
Nasazení
Použitelné technologie
Obecná
Atributy
–
Odkazy
–
Kroky
Zajistěte, aby citlivá data uložená aplikací v systému souborů byla šifrovaná (např. pomocí ROZHRANÍ DPAPI), pokud se systém souborů EFS nedá vynutit.
Ujistěte se, že citlivý obsah není uložený v mezipaměti v prohlížeči.
Název
Detaily
Součást
Webová aplikace
Fáze SDL
Build
Použitelné technologie
Obecné, Webové formuláře, MVC5, MVC6
Atributy
–
Odkazy
–
Kroky
Prohlížeče můžou ukládat informace pro účely ukládání do mezipaměti a historie. Tyto soubory uložené v mezipaměti jsou uložené ve složce, například ve složce Dočasné soubory Internetu v případě Aplikace Internet Explorer. Když se tyto stránky znovu odkazují, prohlížeč je zobrazí z mezipaměti. Pokud se uživateli zobrazí citlivé informace (například jeho adresa, podrobnosti o platební kartě, číslo sociálního pojištění nebo uživatelské jméno), můžou být tyto informace uložené v mezipaměti prohlížeče, a proto je možné je načíst prostřednictvím zkoumání mezipaměti prohlížeče nebo jednoduše stisknutím tlačítka Zpět prohlížeče. Nastavte hodnotu hlavičky odpovědi řízení mezipaměti na "no-store" pro všechny stránky.
To může být implementováno prostřednictvím filtru. Můžete použít následující příklad:
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);
}
Šifrování oddílů konfiguračních souborů webové aplikace obsahujících citlivá data
Konfigurační soubory, jako je Web.config, appsettings.json, se často používají k ukládání citlivých informací, včetně uživatelských jmen, hesel, databázových připojovací řetězec a šifrovacích klíčů. Pokud tyto informace nechráníte, je vaše aplikace zranitelná vůči útočníkům nebo uživatelům se zlými úmysly, kteří získávají citlivé informace, jako jsou uživatelská jména účtů a hesla, názvy databází a názvy serverů. Na základě typu nasazení (azure/místní prostředí) zašifrujte citlivé části konfiguračních souborů pomocí DPAPI nebo služeb, jako je Azure Key Vault.
Explicitní zakázání atributu HTML automatického dokončování v citlivých formulářích a vstupech
Atribut automatického dokončování určuje, jestli má formulář mít zapnuté nebo vypnuté automatické dokončování. Když je zapnuté automatické dokončování, prohlížeč automaticky dokončí hodnoty na základě hodnot, které uživatel zadal dříve. Když například do formuláře zadáte nové jméno a heslo a formulář se odešle, prohlížeč se zeptá, jestli se má heslo uložit. Po zobrazení formuláře se jméno a heslo vyplní automaticky nebo se vyplní při zadávání jména. Útočník s místním přístupem by mohl získat jasné textové heslo z mezipaměti prohlížeče. Ve výchozím nastavení je automatické dokončování povolené a musí být explicitně zakázané.
Ujistěte se, že jsou citlivá data zobrazená na obrazovce uživatele maskovaná.
Název
Detaily
Součást
Webová aplikace
Fáze SDL
Build
Použitelné technologie
Obecná
Atributy
–
Odkazy
–
Kroky
Citlivá data, jako jsou hesla, čísla platebních karet, SSN atd., by se při zobrazení na obrazovce měla maskovat. Tím zabráníte neoprávněným pracovníkům v přístupu k datům (např. hesla pro procházení ramenem, pracovníci podpory prohlížející počet uživatelů SSN). Ujistěte se, že tyto datové prvky nejsou viditelné ve formátu prostého textu a jsou správně maskované. Při jejich přijetí jako vstupu (např. type="heslo") a zobrazení zpět na obrazovce (např. zobrazení pouze posledních 4 číslic čísla platební karty) je potřeba věnovat pozornost.
Implementace dynamického maskování dat pro omezení ohrožení citlivých dat neprivilegovanými uživateli
Účelem dynamického maskování dat je omezit vystavení citlivých dat a zabránit uživatelům, kteří by k datům neměli mít přístup. Dynamické maskování dat nemá za cíl zabránit uživatelům databáze v přímém připojení k databázi a spouštění vyčerpávajících dotazů, které zpřístupňují části citlivých dat. Dynamické maskování dat doplňuje další funkce zabezpečení SQL Serveru (auditování, šifrování, zabezpečení na úrovni řádků...) a důrazně se doporučuje tuto funkci používat společně s nimi, aby bylo možné lépe chránit citlivá data v databázi. Upozorňujeme, že tuto funkci podporuje jenom SQL Server od verze 2016 a Azure SQL Database.
Ujistěte se, že hesla jsou uložená ve formátu slané hodnoty hash.
Hesla by neměla být uložena ve vlastních databázích úložiště uživatelů. Hodnoty hash hesel by měly být uloženy s hodnotami soli. Před uložením hesla se ujistěte, že je sůl uživatele vždy jedinečná a před uložením hesla použijete b-crypt, s-crypt nebo PBKDF2 s minimálním počtem iterací pracovního faktoru 150 000 smyček, abyste vyloučili možnost vynucení hrubou silou.
Ujistěte se, že jsou citlivá data v databázových sloupcích šifrovaná.
Citlivá data, jako jsou čísla platebních karet, musí být v databázi zašifrovaná. Data je možné šifrovat pomocí šifrování na úrovni sloupců nebo pomocí funkce aplikace pomocí šifrovacích funkcí.
Ujistěte se, že je povolené šifrování na úrovni databáze (TDE).
funkce transparentní šifrování dat (TDE) na SQL Serveru pomáhá šifrovat citlivá data v databázi a chránit klíče, které se používají k šifrování dat pomocí certifikátu. Tím zabráníte, aby data nepoužádá nikdo bez klíčů. Transparentní šifrování dat chrání neaktivní uložená data, což znamená soubory dat a protokolů. Poskytuje možnost dodržovat mnoho zákonů, předpisů a pokynů stanovených v různých odvětvích.
SQL Server má možnost šifrovat data při vytváření zálohy. Zadáním šifrovacího algoritmu a šifrovacího algoritmu (certifikátu nebo asymetrického klíče) při vytváření zálohy můžete vytvořit šifrovaný záložní soubor.
Ujistěte se, že citlivá data relevantní pro webové rozhraní API nejsou uložená v úložišti prohlížeče.
Název
Detaily
Součást
Webové rozhraní API
Fáze SDL
Build
Použitelné technologie
MVC 5, MVC 6
Atributy
Zprostředkovatel identity – ADFS, zprostředkovatel identity – Microsoft Entra ID
Odkazy
–
Kroky
V určitých implementacích se citlivé artefakty relevantní pro ověřování webového rozhraní API ukládají v místním úložišti prohlížeče. Například artefakty ověřování Microsoft Entra, jako jsou adal.idtoken, adal.nonce.idtoken, adal.access.token.key, adal.token.keys, adal.state.login, adal.session.state, adal.expiration.key atd.
Všechny tyto artefakty jsou k dispozici i po zavření odhlášení nebo prohlížeče. Pokud nežádoucí osoba získá přístup k těmto artefaktům, může je znovu použít pro přístup k chráněným prostředkům (API). Ujistěte se, že všechny citlivé artefakty související s webovým rozhraním API nejsou uložené v úložišti prohlížeče. V případech, kdy je úložiště na straně klienta nepoužitelné (např. jednostránkové aplikace (SPA), které využívají implicitní openid Připojení/OAuth, potřebují ukládat přístupové tokeny místně), použijte volby úložiště, které nemají trvalost. Například preferovat SessionStorage s localStorage.
Příklad
Následující fragment kódu JavaScriptu pochází z vlastní knihovny ověřování, která ukládá artefakty ověřování v místním úložišti. Takové implementace by se měly vyhnout.
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.
};
Šifrování citlivých dat uložených ve službě Azure Cosmos DB
Název
Detaily
Součást
Azure Document DB
Fáze SDL
Build
Použitelné technologie
Obecná
Atributy
–
Odkazy
–
Kroky
Šifrování citlivých dat na úrovni aplikace před uložením do databáze dokumentů nebo uložením citlivých dat v jiných řešeních úložiště, jako je Azure Storage nebo Azure SQL
Použití služby Azure Disk Encryption k šifrování disků používaných virtuálními počítači
Název
Detaily
Součást
Hranice důvěryhodnosti virtuálních počítačů Azure IaaS
Azure Disk Encryption je nová funkce, která je aktuálně ve verzi Preview. Tato funkce umožňuje šifrovat disky s operačním systémem a datové disky používané virtuálním počítačem IaaS. Pro Windows se jednotky šifrují pomocí standardní technologie šifrování BitLockeru. V případě Linuxu se disky šifrují pomocí technologie DM-Crypt. Tato funkce je integrovaná se službou Azure Key Vault, která umožňuje řídit a spravovat šifrovací klíče disku. Řešení Azure Disk Encryption podporuje následující tři scénáře šifrování zákazníků:
Povolte šifrování na nových virtuálních počítačích IaaS vytvořených ze souborů VHD šifrovaných zákazníkem a šifrovacích klíčů poskytovaných zákazníkem, které jsou uložené ve službě Azure Key Vault.
Povolte šifrování na nových virtuálních počítačích IaaS vytvořených z Azure Marketplace.
Povolte šifrování u existujících virtuálních počítačů IaaS, které už běží v Azure.
Šifrování tajných kódů v aplikacích Service Fabric
Tajné kódy můžou být jakékoli citlivé informace, jako jsou připojovací řetězec úložiště, hesla nebo jiné hodnoty, které by neměly být zpracovávány ve formátu prostého textu. Azure Key Vault slouží ke správě klíčů a tajných kódů v aplikacích Service Fabric.
Modelování zabezpečení a použití obchodních jednotek nebo týmů v případě potřeby
Název
Detaily
Součást
Dynamics CRM
Fáze SDL
Build
Použitelné technologie
Obecná
Atributy
–
Odkazy
–
Kroky
Modelování zabezpečení a použití obchodních jednotek nebo týmů v případě potřeby
Minimalizace přístupu ke sdílení funkce u důležitých entit
Název
Detaily
Součást
Dynamics CRM
Fáze SDL
Nasazení
Použitelné technologie
Obecná
Atributy
–
Odkazy
–
Kroky
Minimalizace přístupu ke sdílení funkce u důležitých entit
Trénujte uživatele na rizika spojená s funkcí Dynamics CRM Share a osvědčenými postupy zabezpečení
Název
Detaily
Součást
Dynamics CRM
Fáze SDL
Nasazení
Použitelné technologie
Obecná
Atributy
–
Odkazy
–
Kroky
Trénujte uživatele na rizika spojená s funkcí Dynamics CRM Share a osvědčenými postupy zabezpečení
Zahrnutí předplatného pravidla vývojových standardů zobrazující podrobnosti konfigurace ve správě výjimek
Název
Detaily
Součást
Dynamics CRM
Fáze SDL
Nasazení
Použitelné technologie
Obecná
Atributy
–
Odkazy
–
Kroky
Zahrňte propis pravidla vývojových standardů, které zobrazuje podrobnosti konfigurace ve správě výjimek mimo vývoj. Otestujte to jako součást kontrol kódu nebo pravidelné kontroly.
Použití šifrování služby Azure Storage (SSE) pro neaktivní uložená data (Preview)
Šifrování služby Azure Storage (SSE) pro neaktivní uložená data pomáhá chránit a chránit vaše data, aby splňovala závazky organizace týkající se zabezpečení a dodržování předpisů. Pomocí této funkce služba Azure Storage automaticky šifruje vaše data před zachováním v úložišti a dešifruje před jejich načtením. Šifrování, dešifrování a správa klíčů je pro uživatele zcela transparentní. SSE se vztahuje pouze na objekty blob bloku, objekty blob stránky a doplňovací objekty blob. Ostatní typy dat, včetně tabulek, front a souborů, nebudou šifrované.
Pracovní postup šifrování a dešifrování:
Zákazník povolí šifrování účtu úložiště.
Když zákazník zapíše nová data (PUT Blob, PUT Block, PUT Page atd.) do úložiště objektů blob; každý zápis je šifrovaný pomocí 256bitového šifrování AES, jednoho z nejsilnějších dostupných blokových šifer.
Když zákazník potřebuje získat přístup k datům (GET Blob atd.), data se před návratem k uživateli automaticky dešifrují.
Pokud je šifrování zakázané, nové zápisy se už nešifrují a stávající šifrovaná data zůstanou zašifrovaná, dokud uživatel nepřepíše. I když je šifrování povolené, zápisy do úložiště objektů blob se zašifrují. Stav dat se u uživatele, který přepíná mezi povolením nebo zakázáním šifrování účtu úložiště, se nezmění.
Všechny šifrovací klíče se ukládají, šifrují a spravují microsoftem.
Upozorňujeme, že v tuto chvíli spravuje Microsoft klíče používané k šifrování. Microsoft vygeneruje klíče původně a spravuje zabezpečené úložiště klíčů a také pravidelnou rotaci definovanou interními zásadami Microsoftu. V budoucnu zákazníci získají možnost spravovat vlastní šifrovací klíče a poskytovat cestu migrace z klíčů spravovaných Microsoftem na klíče spravované zákazníky.
Použití šifrování na straně klienta k ukládání citlivých dat ve službě Azure Storage
Balíček NuGet služby Azure Storage pro .NET podporuje šifrování dat v klientských aplikacích před nahráním do služby Azure Storage a dešifrováním dat při stahování do klienta. Knihovna také podporuje integraci se službou Azure Key Vault pro správu klíčů účtu úložiště. Tady je stručný popis fungování šifrování na straně klienta:
Klientská sada SDK služby Azure Storage generuje šifrovací klíč obsahu (CEK), což je jednorázový symetrický klíč.
Zákaznická data se šifrují pomocí tohoto klíče CEK.
Klíč CEK se pak zabalí (zašifruje) pomocí šifrovacího klíče klíče (KEK). Klíč KEK je identifikován identifikátorem klíče a může se jednat o asymetrický pár klíčů nebo symetrický klíč a dá se spravovat místně nebo ukládat ve službě Azure Key Vault. Samotný klient služby Storage nikdy nemá přístup k klíči KEK. Právě vyvolá algoritmus obtékání klíčů, který poskytuje Služba Key Vault. Zákazníci se můžou rozhodnout použít vlastní zprostředkovatele pro zabalení nebo rozbalení klíčů, pokud chtějí.
Šifrovaná data se pak nahrají do služby Azure Storage. Projděte si odkazy v části reference, kde najdete podrobnosti o implementaci nízké úrovně.
Šifrování citlivých dat nebo dat PII zapsaných do místního úložiště telefonů
Pokud aplikace zapisuje citlivé informace, jako jsou osobní údaje uživatele (e-mail, telefonní číslo, křestní jméno, příjmení, předvolby atd.). - v mobilním systému souborů, pak by měl být před zápisem do místního systému souborů zašifrován. Pokud se jedná o podnikovou aplikaci, prozkoumejte možnost publikování aplikace pomocí Windows Intune.
Příklad
Intune je možné nakonfigurovat pomocí následujících zásad zabezpečení, které chrání citlivá data:
Require encryption on mobile device
Require encryption on storage cards
Allow screen capture
Příklad
Pokud aplikace není podniková aplikace, použijte úložiště klíčů, klíčenky poskytované platformou k ukládání šifrovacích klíčů, pomocí kterých se v systému souborů může provádět kryptografická operace. Následující fragment kódu ukazuje, jak získat přístup k klíčence z řetězce klíčů pomocí xamarinu:
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;
}
}
Obfuscate vygenerované binární soubory před distribucí koncovým uživatelům
Vygenerované binární soubory (sestavení v souboru apk) by měly být obfuskovány, aby se zastavila zpětná analýza sestavení. K tomuto účelu se dají použít nástroje, jako CryptoObfuscator je tento účel.
Nastavení clientCredentialType na certifikát nebo Windows
Použití usernameToken s heslem prostého textu přes nešifrovaný kanál zveřejňuje heslo útočníkům, kteří můžou šifrovat zprávy SOAP. Poskytovatelé služeb, kteří používají uživatelské jménoToken, můžou přijímat hesla odeslaná ve formátu prostého textu. Odesílání hesel ve formátu prostého textu přes nešifrovaný kanál může vystavit přihlašovací údaje útočníkům, kteří můžou zprávu SOAP šifrovat.
Příklad
Následující konfigurace zprostředkovatele služeb WCF používá uživatelské jménoToken:
Nebylo definováno žádné zabezpečení přenosu nebo zpráv. Aplikace, které přenášejí zprávy bez přenosu nebo zabezpečení zpráv, nemohou zaručit integritu nebo důvěrnost zpráv. Pokud je vazba zabezpečení WCF nastavena na Žádné, přenos i zabezpečení zpráv jsou zakázány.
Příklad
Následující konfigurace nastaví režim zabezpečení na Žádné.
Režim zabezpečení ve všech vazbách služby existuje pět možných režimů zabezpečení:
Žádné Vypne zabezpečení.
Dopravy. Používá zabezpečení přenosu pro vzájemné ověřování a ochranu zpráv.
Message. Používá zabezpečení zpráv pro vzájemné ověřování a ochranu zpráv.
Oba. Umožňuje zadat nastavení pro přenos a zabezpečení na úrovni zpráv (to podporuje pouze MSMQ).
TransportWithMessageCredential. Přihlašovací údaje se předávají se zprávou a ochranou zpráv a ověřováním serveru prostřednictvím přenosové vrstvy.
TransportCredentialOnly. Přihlašovací údaje klienta se předávají s přenosovou vrstvou a nepoužije se žádná ochrana zpráv. Zabezpečení přenosu a zpráv slouží k ochraně integrity a důvěrnosti zpráv. Následující konfigurace informuje službu, aby používala zabezpečení přenosu s přihlašovacími údaji zpráv.
Připravujeme: V průběhu roku 2024 budeme postupně vyřazovat problémy z GitHub coby mechanismus zpětné vazby pro obsah a nahrazovat ho novým systémem zpětné vazby. Další informace naleznete v tématu: https://aka.ms/ContentUserFeedback.