Osvědčené postupy zabezpečení v Tvůrci rozhraní Data API

Diagram aktuálního umístění ('Optimalizace') v sekvenci průvodce nasazením

Tento článek obsahuje aktuální doporučené osvědčené postupy pro zabezpečení v Tvůrci rozhraní Data API. Tento článek neobsahuje úplný seznam všech aspektů zabezpečení pro vaše řešení tvůrce rozhraní DATA API.

Zakázání starších verzí protokolu TLS na úrovni serveru

Data odesílaná mezi klientem a tvůrcem rozhraní Data API by měla probíhat přes zabezpečené připojení, aby se chránily citlivé nebo cenné informace. Zabezpečené připojení se obvykle vytváří pomocí protokolů TLS (Transport Layer Security).

Jak je podrobně popsáno v pokynech k ochraně transportní vrstvy OWASP , poskytuje protokol TLS při správné implementaci řadu výhod zabezpečení:

  • Důvěrnost – ochrana před tím, aby útočník četl obsah datového provozu.
  • Integrita – ochrana před útočníkem, který upravuje provoz.
  • Zabránění opakování – ochrana před útočníkem, který opakuje požadavky na server.
  • Ověřování – umožňuje klientovi ověřit, že je připojený k skutečnému serveru (mějte na paměti, že identita klienta není ověřená, pokud se nepoužívají klientské certifikáty).

Doporučení

Jedním ze způsobů, jak bezpečně nakonfigurovat protokol TLS, je zakázat použití starších verzí protokolu TLS na úrovni serveru. Tvůrce rozhraní DATA API je založený na Kestrelu, multiplatformním webovém serveru pro ASP.NET Core a je standardně nakonfigurovaný tak, aby odkazoval konfiguraci verze protokolu TLS operačního systému. Osvědčené postupy protokolu TLS od Microsoftu pro pokyny k .NET popisují motivaci za takovým chováním:

Poznámka:

TLS 1.2 je standard, který poskytuje vylepšení zabezpečení oproti předchozím verzím. Nejnovější vydaný standard TLS 1.3, který je rychlejší a bezpečnější, nakonec nahradí protokol TLS 1.2.

Aby aplikace rozhraní .NET Framework zůstaly zabezpečené, verze protokolu TLS by neměla být pevně zakódovaná. Aplikace rozhraní .NET Framework by měly používat verzi protokolu TLS, která operační systém podporuje.

I když se podporují explicitní definování podporovaných verzí protokolu TLS pro Kestrel, nedoporučuje se to. Tyto definice se překládají na seznam povolených, což brání podpoře budoucích verzí protokolu TLS, jakmile budou k dispozici. Další informace o chování výchozí verze protokolu TLS společnosti Kestrel najdete tady.

Podpora TLS

Protokol TLS 1.2 je ve výchozím nastavení povolený v nejnovějších verzích .NET a mnoha nejnovějších verzích operačního systému.

Konfigurace ověřování pro produkční prostředí

Počínaje jazykem DAB 2.0, který je aktuálně ve verzi Preview, je Unauthenticatedvýchozím zprostředkovatelem ověřování . To znamená, že DAB nekontroluje ani neověřuje žádný webový token JSON (JWT) a všechny požadavky se spouštějí jako anonymous. Jiná služba před DAB může ověřovat volající nebo omezit přístup, ale DAB stále autorizuje pouze jako anonymous.

Důležité

Pokud DAB vystavujete přímo klientům, nakonfigurujte poskytovatele ověřování na úrovni produkce (například EntraID nebo Custom), protože byste se neměli spoléhat na Unauthenticated. Pokud je Unauthenticated aktivní, authenticated a vlastní role definované v oprávněních entity se nikdy neaktivují.

Další informace najdete v tématu Konfigurace neověřeného zprostředkovatele a konfigurace ověřování za běhu.

Ověřování "jménem uživatele" (OBO) delegované zadavatelem

Pro nasazení SQL Serveru a Azure SQL, která vyžadují zabezpečení na úrovni řádků se skutečnou identitou uživatele, zvažte povolit ověřování On-Behalf-Of (OBO). OBO vymění příchozí uživatelský token za podřízený token SQL, aby se databáze ověřila jako skutečný volající uživatel. Další informace najdete v tématu ověřování delegované uživatelem.

  • Last updated on