Sdílet prostřednictvím

Playbook pro řešení běžných požadavků na zabezpečení se službou Azure SQL Database a azure SQL Managed Instance

Platí pro:Azure SQL DatabaseAzure SQL Managed Instance

Tento článek obsahuje osvědčené postupy pro řešení běžných požadavků na zabezpečení. Ne všechny požadavky platí pro všechna prostředí a měli byste se obrátit na tým databáze a zabezpečení, na které funkce se mají implementovat.

Poznámka:

ID Microsoft Entra se dříve označovalo jako Azure Active Directory (Azure AD).

Řešení běžných požadavků na zabezpečení

Tento dokument obsahuje pokyny k řešení běžných požadavků na zabezpečení pro nové nebo existující aplikace pomocí Azure SQL Database a azure SQL Managed Instance. Je uspořádaná podle oblastí zabezpečení vysoké úrovně. Informace o řešení konkrétních hrozeb najdete v části Běžné bezpečnostní hrozby a potenciální omezení rizik . I když některá z uvedených doporučení platí pro migraci aplikací z místního prostředí do Azure, scénáře migrace se nezaměřují na tento dokument.

Nabídky nasazení azure SQL Database popsané v této příručce

Nabídky nasazení, které nejsou popsané v této příručce

  • Azure Synapse Analytics
  • Virtuální počítače Azure SQL (IaaS)
  • SQL Server

Cílová skupina

Zamýšlená cílová skupina pro tuto příručku jsou zákazníky, kteří se ptají, jak zabezpečit službu Azure SQL Database. Mezi role, které se zajímají o tento článek osvědčených postupů, patří mimo jiné:

  • Architekti zabezpečení
  • Správci zabezpečení
  • Pracovníci pro dodržování předpisů
  • Strážníci ochrany osobních údajů
  • Technici zabezpečení

Jak používat tohoto průvodce

Tento dokument je určený jako doplněk k našemu stávajícímu přehledu možností zabezpečení služby Azure SQL Database a služby SQL Managed Instance.

Pokud není uvedeno jinak, doporučujeme postupovat podle všech osvědčených postupů uvedených v každé části, abyste dosáhli příslušného cíle nebo požadavku. Pro splnění konkrétních standardů dodržování předpisů zabezpečení nebo osvědčených postupů jsou důležité kontrolní mechanismy dodržování právních předpisů uvedené v části Požadavky nebo cíle, kdykoli je to možné. Toto jsou standardy zabezpečení a předpisy, na které se odkazuje v tomto dokumentu:

Plánujeme pokračovat v aktualizaci doporučení a osvědčených postupů uvedených zde. Pomocí odkazu Zpětná vazba v dolní části tohoto článku můžete zadat vstup nebo jakékoli opravy tohoto dokumentu.

Ověřování

Ověřování je proces prokazování, že je uživatel tím, za koho se vydává. Azure SQL Database a SQL Managed Instance podporují dva typy ověřování:

  • Ověřování SQL
  • Ověřování Microsoft Entra

Poznámka:

Ověřování Microsoft Entra nemusí být podporováno pro všechny nástroje a aplikace třetích stran.

Centrální správa identit

Centrální správa identit nabízí následující výhody:

  • Správa skupinových účtů a řízení uživatelských oprávnění bez duplikování přihlášení mezi servery, databázemi a spravovanými instancemi
  • Zjednodušená a flexibilní správa oprávnění
  • Správa aplikací ve velkém měřítku

Implementace

  • Pro centralizovanou správu identit použijte ověřování Microsoft Entra.

Osvědčené postupy

  • Vytvořte tenanta Microsoft Entra a vytvořte uživatele , kteří představují lidské uživatele, a vytvořte instanční objekty , které představují aplikace, služby a automatizační nástroje. Instanční objekty jsou ekvivalentní účtům služeb ve Windows a Linuxu.

  • Přiřaďte přístupová práva k prostředkům objektům zabezpečení Microsoft Entra pomocí přiřazení ke skupině: Vytvořte skupiny Microsoft Entra, udělte přístup skupinám a přidejte do skupin členy. V databázi vytvořte uživatele databáze s omezením, kteří jsou namapovaní na skupiny Microsoft Entra. Pokud chcete přiřadit oprávnění v databázi, přidejte uživatele obsažené databáze představující skupiny k databázovým rolím nebo jim udělte oprávnění přímo.

    Poznámka:

    Ve službě SQL Managed Instance můžete také vytvořit přihlášení, která se mapují na objekty zabezpečení Microsoft Entra v master databázi. Viz CREATE LOGIN (Transact-SQL).

  • Použití skupin Microsoft Entra zjednodušuje správu oprávnění a jak vlastník skupiny, tak vlastník prostředku mohou přidávat nebo odebírat členy do skupiny a ze skupiny.

  • Vytvořte samostatnou skupinu pro správce Microsoft Entra pro každý server nebo spravovanou instanci.

  • Monitorujte změny členství ve skupinách Microsoft Entra prostřednictvím auditních zpráv aktivity Microsoft Entra ID.

  • Pro spravovanou instanci se k vytvoření správce Microsoft Entra vyžaduje samostatný krok.

Poznámka:

  • Ověřování Microsoft Entra se zaznamenává v protokolech auditu Azure SQL, ale ne v protokolech přihlašování Microsoft Entra.
  • Oprávnění Azure RBAC udělená v Azure se nevztahují na oprávnění služby Azure SQL Database nebo sql Managed Instance. Tato oprávnění se musí vytvořit nebo namapovat ručně pomocí existujících oprávnění SQL.
  • Na straně klienta potřebuje ověřování Microsoft Entra přístup k internetu nebo přes trasu definovanou uživatelem (UDR) do virtuální sítě.
  • Přístupový token Microsoft Entra je uložen v mezipaměti na straně klienta a jeho životnost závisí na konfiguraci tokenu. Přečtěte si článek o konfigurovatelných životnostech tokenů v ID Microsoft Entra.
  • Pokyny k řešení potíží s ověřováním Microsoft Entra najdete na následujícím blogu: Řešení potíží s ID Microsoft Entra.

Vícefaktorové ověřování Microsoft Entra

Uvedeno v: OSA Practice #2, ISO Access Control (AC)

Vícefaktorové ověřování Microsoft Entra poskytuje další zabezpečení tím, že vyžaduje více než jednu formu ověřování.

Implementace

  • Povolte vícefaktorové ověřování v Microsoft Entra ID pomocí podmíněného přístupu a použijte interaktivní ověřování.

  • Alternativou je povolení vícefaktorového ověřování pro celého tenanta Microsoft Entra nebo domény Active Directory.

Osvědčené postupy

  • Aktivace podmíněného přístupu v Microsoft Entra ID (vyžaduje předplatné Premium).

  • Vytvořte skupiny Microsoft Entra a povolte pro vybrané skupiny zásady vícefaktorového ověřování pomocí podmíněného přístupu Microsoft Entra.

    • Viz článek „Plán nasazení podmíněného přístupu“.

  • Vícefaktorové ověřování je možné povolit pro celého tenanta Microsoft Entra nebo pro Službu Active Directory federované s ID Microsoft Entra.

  • Pro Azure SQL Database a Azure SQL Managed Instance použijte interaktivní režim ověřování Microsoft Entra, kde se interaktivně požaduje heslo a následně vícefaktorové ověřování:

  • Implementujte aplikace pro připojení ke službě Azure SQL Database nebo azure SQL Managed Instance pomocí interaktivního ověřování s podporou vícefaktorového ověřování.

    Poznámka:

    Tento režim ověřování vyžaduje identity založené na uživatelích. V případech, kdy se používá model důvěryhodné identity, který obchází individuální ověřování uživatelů Microsoft Entra (například použití spravované identity pro prostředky Azure), vícefaktorové ověřování se nevztahuje.

Minimalizace použití ověřování založeného na heslech pro uživatele

Uvedeno v: OSA Practice #4, ISO Access Control (AC)

Metody ověřování založené na heslech jsou slabší formou ověřování. Přihlašovací údaje mohou být ohroženy nebo omylem předány.

Implementace

  • Používejte integrované ověřování Microsoft Entra, které eliminuje použití hesel.

Osvědčené postupy

  • Použijte ověřování pomocí jednotného přihlašování pomocí přihlašovacích údajů systému Windows. Federujte místní Active Directory doménu s ID Microsoft Entra a použijte integrované ověřování systému Windows (pro počítače připojené k doméně s Microsoft Entra ID).

Minimalizace použití ověřování založeného na heslech pro aplikace

Uvedeno v: OSA Practice #4, ISO Access Control (AC)

Implementace

  • Povolte spravovanou identitu Azure. Můžete také použít integrované ověřování nebo ověřování založené na certifikátech.

Osvědčené postupy

Ochrana hesel a tajných kódů

V případech, kdy se hesla nedají vyhnout, se ujistěte, že jsou zabezpečená.

Implementace

  • K ukládání hesel a tajných kódů použijte Azure Key Vault. Kdykoli je to možné, použijte vícefaktorové ověřování pro Azure SQL Database s uživateli Microsoft Entra.

Osvědčené postupy

  • Pokud se nelze vyhnout použití hesel nebo tajných kódů, ukládejte uživatelská hesla a tajné kódy aplikací ve službě Azure Key Vault a spravujte přístup prostřednictvím zásad přístupu Azure Key Vault.

  • Různé architektury pro vývoj aplikací můžou také nabízet mechanismy specifické pro architekturu pro ochranu tajných kódů v aplikaci. Příklad: ASP.NET základní aplikace.

Použití ověřování SQL pro starší verze aplikací

Ověřování SQL odkazuje na ověřování uživatele při připojování ke službě Azure SQL Database nebo spravované instanci SQL pomocí uživatelského jména a hesla. V každém serveru nebo spravované instanci bude potřeba vytvořit přihlášení a uživatel vytvořený v každé databázi.

Implementace

  • Použijte ověřování SQL.

Osvědčené postupy

Správa přístupu

Správa přístupu (označovaná také jako autorizace) je proces řízení a správy přístupu a oprávnění autorizovaných uživatelů ke službě Azure SQL Database nebo spravované instanci SQL.

Implementace principu nejnižšího oprávnění

Uvedené v: FedRamp řídí AC-06, NIST: AC-6, OSA Practice #3

Princip nejnižších oprávnění uvádí, že uživatelé by neměli mít více oprávnění, než je potřeba k dokončení úkolů. Další informace najdete v tématu Pouze dostatek správy.

Implementace

Přiřaďte pouze potřebná oprávnění k dokončení požadovaných úkolů:

Osvědčené postupy

Následující osvědčené postupy jsou volitelné, ale budou mít za následek lepší možnosti správy a možnosti podpory vaší strategie zabezpečení:

  • Pokud je to možné, začněte s nejnižší možnou sadou oprávnění a začněte přidávat oprávnění o jednu po druhé, pokud existuje skutečná nutnost (a odůvodnění) – na rozdíl od opačného přístupu: oddělte oprávnění krok za krokem.

  • Nepřiřazujte oprávnění jednotlivým uživatelům. Místo toho používejte role (databázové nebo serverové role). Role výrazně pomáhají s vytvářením sestav a odstraňováním potíží s oprávněními. (Azure RBAC podporuje pouze přiřazení oprávnění prostřednictvím rolí.)

  • Vytvářejte a používejte vlastní role s přesnými potřebnými oprávněními. Typické role, které se používají v praxi:

    • Nasazení zabezpečení
    • Aministrátoři
    • Developer
    • Pracovníci podpory
    • Auditoři
    • Automatizované procesy
    • Koncový uživatel

  • Předdefinované role používejte jenom v případě, že oprávnění rolí odpovídají přesně potřebným oprávněním pro uživatele. Uživatele můžete přiřadit k více rolím.

  • Mějte na paměti, že oprávnění v databázovém stroji se dají použít v následujících oborech (menší rozsah, menší dopad udělených oprávnění):

    • Server (speciální role v databázi) v master Azure
    • Databáze
    • Schéma
      • Osvědčeným postupem je použít schémata k udělení oprávnění v databázi.
    • Objekt (tabulka, zobrazení, procedura atd.)

    Poznámka:

    Nedoporučuje se používat oprávnění na úrovni objektu, protože tato úroveň zvyšuje zbytečnou složitost celkové implementace. Pokud se rozhodnete použít oprávnění na úrovni objektu, měli byste je jasně zdokumentovat. Totéž platí pro oprávnění na úrovni sloupců, která jsou dokonce méně doporučená ze stejných důvodů. Mějte také na paměti, že ve výchozím nastavení DENY na úrovni tabulky nepřebíjí GRANT na úrovni sloupce. Vyžadovalo by to aktivaci konfigurace serveru souladu s běžnými kritérii.

  • Proveďte pravidelné kontroly pomocí posouzení zranitelnosti (VA) a otestujte, zda nejsou uděleny příliš mnoho oprávnění.

Implementace oddělení povinností

Uvedeno v: FedRamp: AC-04, NIST: AC-5, ISO: A.6.1.2, PCI 6.4.2, SOC: CM-3, SDL-3

Oddělení povinností, označované také jako Oddělení povinností, popisuje požadavek rozdělení citlivých úkolů na více úkolů, které jsou přiřazeny různým uživatelům. Oddělení povinností pomáhá předcházet porušením zabezpečení dat.

Implementace

  • Určete požadovanou úroveň rozdělení povinností. Příklady:

    • Mezi vývojovými/testovacími a produkčními prostředími
    • Úlohy citlivé na zabezpečení vs. úlohy na úrovni správy dbA (Database Administrator) vs. vývojářské úlohy.
      • Příklady: Auditor, vytvoření zásad zabezpečení pro zabezpečení na úrovni role (RLS), implementace objektů SQL Database s oprávněními DDL.

  • Identifikujte komplexní hierarchii uživatelů (a automatizovaných procesů), která přistupuje k systému.

  • Vytvořte role podle potřebných skupin uživatelů a přiřaďte oprávnění k rolím.

    • Pro úlohy na úrovni správy na webu Azure Portal nebo prostřednictvím automatizace PowerShellu použijte role Azure. Vyhledejte předdefinované role odpovídající požadavkům, nebo vytvořte vlastní roli Azure pomocí dostupných oprávnění.
    • Vytvořte role serveru pro úlohy na úrovni celého serveru (vytváření nových přihlášení, databází) ve spravované instanci.
    • Vytvoření databázových rolí pro úlohy na úrovni databáze

  • U některých citlivých úloh zvažte vytvoření speciálních uložených procedur podepsaných certifikátem, aby se úlohy spouštěly jménem uživatelů. Jednou z důležitých výhod digitálně podepsaných uložených procedur je, že pokud se procedura změní, oprávnění udělená předchozí verzi procedury se okamžitě odeberou.

  • Implementujte transparentní šifrování dat (TDE) s klíči spravovanými zákazníkem ve službě Azure Key Vault, abyste umožnili oddělení povinností mezi vlastníkem dat a vlastníkem zabezpečení.

  • Pokud chcete zajistit, aby správce databáze neviděl data, která jsou považována za vysoce citlivá, a přesto může provádět úlohy DBA, můžete použít funkci Always Encrypted s oddělením rolí.

  • V případech, kdy použití funkce Always Encrypted není možné nebo alespoň bez velkých nákladů a úsilí, které by mohly dokonce způsobit, že by systém byl téměř nepoužitelný, je možné kompromisy provést a zmírnit pomocí kompenzačních ovládacích prvků, jako jsou:

Osvědčené postupy

  • Ujistěte se, že se pro vývojová a testovací a produkční prostředí používají různé účty. Různé účty pomáhají dodržovat oddělení testovacích a produkčních systémů.

  • Nepřiřazujte oprávnění jednotlivým uživatelům. Místo toho používejte role (databázové nebo serverové role). Určování rolí výrazně pomáhá při vykazování a odstraňování potíží s oprávněními.

  • Předdefinované role použijte, když oprávnění přesně odpovídají potřebným oprávněním – pokud sjednocení všech oprávnění z více předdefinovaných rolí vede ke 100% shodě, můžete současně přiřadit i více rolí.

  • Vytvořte a používejte uživatelsky definované role, když vestavěné role udělují příliš mnoho nebo nedostatečná oprávnění.

  • Přiřazení rolí je také možné dočasně provést, označované také jako dynamické oddělení povinností (DSD), a to buď v rámci kroků úlohy agenta SQL v T-SQL, nebo pomocí Azure PIM pro role Azure.

  • Ujistěte se, že správci dba nemají přístup k šifrovacím klíčům nebo úložištím klíčů a že správci zabezpečení s přístupem ke klíčům nemají přístup k databázi. Použití funkce EKM (Extensible Key Management) může usnadnit dosažení tohoto oddělení. Azure Key Vault se dá použít k implementaci EKM.

  • Vždy se ujistěte, že máte záznam auditu pro akce související se zabezpečením.

  • Definici předdefinovaných rolí Azure můžete načíst, abyste viděli použitá oprávnění a vytvořili vlastní roli na základě výňatek a kumulace těchto rolí prostřednictvím PowerShellu.

  • Vzhledem k tomu, že každý člen role databáze db_owner může změnit nastavení zabezpečení, jako je transparentní šifrování dat (TDE) nebo změnit cíl úrovně služby( SLO), mělo by být toto členství uděleno s opatrností. Existuje však mnoho úloh, které vyžadují oprávnění db_owner. Úloha jako změna libovolného nastavení databáze, jako je změna možností databáze Auditování hraje klíčovou roli v jakémkoli řešení.

  • Oprávnění db_owner není možné omezit, a proto zabránit účtu správce v zobrazení uživatelských dat. Pokud databáze obsahuje vysoce citlivá data, můžete funkci Always Encrypted použít k bezpečnému zabránění db_owners nebo jinému dbA v zobrazení.

Poznámka:

Dosažení oddělení povinností (SoD) je náročné na úlohy související se zabezpečením nebo řešení potíží. Další oblasti, jako je vývoj a role koncových uživatelů, se snadněji oddělují. Většina ovládacích prvků souvisejících s dodržováním předpisů umožňuje používat alternativní řídicí funkce, jako je auditování, pokud jiná řešení nejsou praktická.

Pro čtenáře, kteří se chtějí ponořit hlouběji do SoD, doporučujeme následující zdroje informací:

Provádění pravidelných kontrol kódu

Uvedeno v: PCI: 6.3.2, SOC: SDL-3

Oddělení povinností není omezeno na data v databázi, ale zahrnuje kód aplikace. Škodlivý kód může potenciálně obejít bezpečnostní prvky. Před nasazením vlastního kódu do produkčního prostředí je důležité zkontrolovat, co se nasazuje.

Implementace

  • Použijte databázový nástroj, jako je Azure Data Studio, který podporuje správu zdrojového kódu.

  • Implementujte proces nasazení odděleného kódu.

  • Před potvrzením do hlavní větve musí osoba (kromě autora samotného kódu) zkontrolovat kód pro riziko zvýšení oprávnění i škodlivé úpravy dat, aby se zabránilo podvodům a neoprávněnému přístupu. To lze provést pomocí mechanismů správy zdrojového kódu.

Osvědčené postupy

  • Standardizace: Pomáhá implementovat standardní postup, který se má dodržovat pro všechny aktualizace kódu.

  • Posouzení ohrožení zabezpečení obsahuje pravidla, která kontrolují nadměrná oprávnění, použití starých šifrovacích algoritmů a další problémy se zabezpečením v rámci schématu databáze.

  • Další kontroly je možné provést v prostředí pro kontrolu kvality nebo testování pomocí služby Advanced Threat Protection, která kontroluje kód, který je zranitelný vůči injektáži SQL.

  • Příklady toho, co je potřeba hledat:

    • Vytvoření uživatele nebo změna nastavení zabezpečení z automatizovaného nasazení aktualizace kódu SQL
    • Uložená procedura, která v závislosti na zadaných parametrech aktualizuje peněžní hodnotu v buňce způsobem, který nevyhovuje.

  • Ujistěte se, že osoba, která provádí kontrolu, je jiná než autor původního kódu a že je znalá v kontrolách kódu a zabezpečeném kódování.

  • Nezapomeňte znát všechny zdroje změn kódu. Kód může být ve skriptech T-SQL. Může se jednat o ad hoc příkazy ke spuštění nebo nasazení ve formě zobrazení, funkcí, triggerů a uložených procedur. Může být součástí definic úloh agenta SQL (kroky). Dá se také spustit z balíčků SSIS, Azure Data Factory a dalších služeb.

Ochrana dat

Ochrana dat je sada možností pro ochranu důležitých informací před ohrožením šifrováním nebo obfuskací.

Poznámka:

Microsoft ověřuje službu Azure SQL Database a Azure SQL Managed Instance jako vyhovující standardu FIPS 140–2 level 1. To se provádí po ověření přísného použití přijatelných algoritmů FIPS 140-2 úroveň 1 a ověřených instancí těchto algoritmů na úrovni 1, včetně konzistence s požadovanými délkami klíčů, správou klíčů, generováním klíčů a ukládáním klíčů. Toto ověření identity má umožnit našim zákazníkům reagovat na potřebu nebo požadavek na použití ověřených instancí FIPS 140-2 level 1 při zpracování dat nebo doručování systémů nebo aplikací. Definujeme termíny "FIPS 140-2 Level 1 vyhovující" a "shoda s FIPS 140-2 Level 1" použité ve výše uvedeném prohlášení, abychom ukázali jejich zamýšlenou použitelnost pro vládu USA a Kanady při použití odlišného výrazu "FIPS 140-2 Level 1 ověřeno".

Šifrování přenášených dat

Zmíněno v: OSA Practice #6, ISO Control Family: Cryptography

Chrání vaše data při přesouvání dat mezi vaším klientem a serverem. Přečtěte si o zabezpečení sítě.

Šifrování neaktivních uložených dat

Zmíněno v: OSA Practice #6, ISO Control Family: Cryptography

Šifrování dat v klidu je kryptografickou ochranou dat, když jsou trvale uložené v databázích, logech a záložních souborech.

Implementace

  • Transparentní šifrování dat (TDE) se spravovanými klíči služby je ve výchozím nastavení povolené pro všechny databáze vytvořené po roce 2017 ve službě Azure SQL Database a ve spravované instanci SQL.
  • Ve spravované instanci, pokud je databáze vytvořena z operace obnovení pomocí místního serveru, bude dodrženo nastavení TDE (Transparent Data Encryption) původní databáze. Pokud původní databáze nemá povolené transparentní šifrování dat, doporučujeme zapnout transparentní šifrování dat pro spravovanou instanci ručně.

Osvědčené postupy

  • Neukládejte v databázi master data, která vyžadují šifrování při uložení. Databázi master nelze zašifrovat pomocí TDE.

  • Pokud potřebujete větší transparentnost a podrobnou kontrolu nad ochranou TDE, použijte klíče spravované zákazníkem ve službě Azure Key Vault. Azure Key Vault umožňuje kdykoli odvolat oprávnění, aby byla databáze nepřístupná. Pomocí služby Azure Key Vault můžete centrálně spravovat ochránce TDE spolu s dalšími klíči nebo rotovat ochránce TDE podle vlastního plánu.

  • Pokud ve službě Azure Key Vault používáte klíče spravované zákazníkem, přečtěte si články Pokyny pro konfiguraci šifrování dat s Azure Key Vault a Jak nakonfigurovat geografické zotavení s Azure Key Vault.

Poznámka:

Některé položky považované za zákaznický obsah, jako jsou názvy tabulek, názvy objektů a názvy indexů, se můžou přenášet v souborech protokolů pro podporu a řešení potíží od Microsoftu.

Ochrana citlivých dat při použití před vysoce privilegovanými neoprávněnými uživateli

Použitá data jsou data uložená v paměti databázového systému během provádění dotazů SQL. Pokud vaše databáze ukládá citlivá data, může být vaše organizace nutná k tomu, aby uživatelé s vysokou úrovní oprávnění nemohli prohlížet citlivá data ve vaší databázi. Uživatelé s vysokými oprávněními, jako jsou operátoři Microsoftu nebo DBA ve vaší organizaci, by měli mít možnost spravovat databázi, ale zabránili jim v prohlížení a potenciálním exfiltrování citlivých dat z paměti procesu SQL nebo dotazováním databáze.

Zásady, které určují, která data jsou citlivá a jestli se citlivá data musí šifrovat v paměti a nejsou přístupná správcům ve formátu prostého textu, jsou specifické pro vaši organizaci a předpisy týkající se dodržování předpisů, které potřebujete dodržovat. Projděte si související požadavek: Identifikace a označení citlivých dat.

Implementace

  • Pomocí Always Encrypted zajistěte, aby se citlivá data nezpřístupňovala ve formátu prostého textu ve službě Azure SQL Database nebo ve spravované instanci SQL, ani když jsou v paměti nebo při použití. Funkce Always Encrypted chrání data před správci databáze (DBA) a cloudovými správci (nebo špatnými aktéry, kteří můžou zosobnit vysoce privilegované, ale neautorizované uživatele) a poskytuje větší kontrolu nad tím, kdo má přístup k vašim datům.

Osvědčené postupy

  • Always Encrypted není náhradou za šifrování dat v klidu (TDE) ani při přenosu (SSL/TLS). Funkce Always Encrypted by se neměla používat pro necitlivá data, aby se minimalizoval dopad na výkon a funkčnost. Použití Always Encrypted ve spojení s Transparent Data Encryption (TDE) a protokolem Transport Layer Security (TLS) se doporučuje pro komplexní ochranu dat v klidovém stavu, při přenosu a při použití.

  • Před nasazením funkce Always Encrypted do produkční databáze vyhodnoťte dopad šifrování identifikovaných sloupců citlivých dat. Funkce Always Encrypted obecně snižuje funkčnost dotazů na šifrované sloupce a má další omezení uvedená v části Always Encrypted – Podrobnosti o funkcích. Proto možná budete muset přepracovat architekturu aplikace, abyste znovu implementovali funkčnosti, které dotaz nepodporuje, na straně klienta, a/nebo refaktorovali schéma databáze, což zahrnuje definice uložených procedur, funkcí, zobrazení a triggerů. Stávající aplikace nemusí pracovat se šifrovanými sloupci, pokud nedodržují omezení a omezení funkce Always Encrypted. Zatímco ekosystém nástrojů Microsoftu, produktů a služeb podporujících funkci Always Encrypted roste, řada z nich nefunguje se šifrovanými sloupci. Šifrování sloupce může také ovlivnit výkon dotazů v závislosti na vlastnostech vaší úlohy.

  • Správa klíčů Always Encrypted s oddělením rolí, pokud k ochraně dat před škodlivými databázemi používáte funkci Always Encrypted. Při oddělení rolí vytvoří správce zabezpečení fyzické klíče. Správce databáze vytvoří hlavní klíč sloupce a objekty metadat šifrovacího klíče sloupce, které popisují fyzické klíče v databázi. Během tohoto procesu správce zabezpečení nepotřebuje přístup k databázi a dbA nepotřebuje přístup k fyzickým klíčům v prostém textu.

  • Ukládejte hlavní klíče sloupců ve službě Azure Key Vault, abyste usnadnili správu. Vyhněte se používání úložiště certifikátů systému Windows (a obecně řešení distribuovaného úložiště klíčů, na rozdíl od řešení pro správu centrálních klíčů), která ztěžují správu klíčů.

  • Pečlivě si promyslete kompromisy při používání více klíčů (hlavní klíč sloupce nebo šifrovací klíče sloupců). Udržujte malý počet klíčů, abyste snížili náklady na správu klíčů. Jeden hlavní klíč sloupce a jeden šifrovací klíč sloupce na databázi je obvykle dostatečný v prostředích s stabilním stavem (ne uprostřed obměně klíčů). Pokud máte různé skupiny uživatelů, budete možná potřebovat další klíče, z nichž každý používá různé klíče a přistupuje k různým datům.

  • Otočte hlavní klíče sloupců podle požadavků na dodržování předpisů. Pokud potřebujete také otočit šifrovací klíče sloupců, zvažte použití online šifrování, abyste minimalizovali výpadky aplikací.

  • Pokud je potřeba podporovat výpočty (rovnost) dat, použijte deterministické šifrování. V opačném případě použijte náhodné šifrování. Nepoužívejte deterministické šifrování pro datové sady s nízkou entropií nebo datové sady s veřejně známou distribucí.

  • Pokud máte obavy, že třetí strany přistupují k datům z právních předpisů bez vašeho souhlasu, ujistěte se, že všechny aplikace a nástroje, které mají přístup ke klíčům a datům v prostém textu, běží mimo Microsoft Azure Cloud. Bez přístupu ke klíčům nebude mít třetí strana žádný způsob dešifrování dat, pokud šifrování nepoužijí.

  • Funkce Always Encrypted nepodporuje snadné udělení dočasného přístupu ke klíčům (a chráněným datům). Pokud například potřebujete klíče sdílet s DBA, aby dbA mohla provádět některé operace čištění citlivých a šifrovaných dat. Jediným způsobem, jak spolehlivě odvolat přístup k datům z DBA, bude obměna šifrovacích klíčů sloupců i hlavních klíčů sloupců, které chrání data, což je náročná operace.

  • Aby mohl uživatel přistupovat k hodnotám prostého textu v šifrovaných sloupcích, musí mít přístup k hlavnímu klíči sloupce (CMK), který chrání sloupce, které jsou nakonfigurované v úložišti klíčů, ve kterém je uložen klíč CMK. Uživatel musí mít také oprávnění VIEW ANY COLUMN MASTER KEY DEFINITION a VIEW ANY COLUMN ENCRYPTION KEY DEFINITION.

Řízení přístupu uživatelů aplikací k citlivým datům prostřednictvím šifrování

Šifrování lze použít jako způsob, jak zajistit, aby data mohli zobrazit nebo aktualizovat jenom konkrétní uživatelé aplikace, kteří mají přístup k kryptografickým klíčům.

Implementace

  • Použijte šifrování na úrovni buněk (CLE). Podrobnosti najdete v článku Šifrování sloupce dat .
  • Použijte funkci Always Encrypted, ale mějte na paměti její omezení. Omezení jsou uvedená níže.

Osvědčené postupy:

Při použití CLE:

  • Řízení přístupu ke klíčům prostřednictvím oprávnění a rolí SQL

  • K šifrování dat použijte AES (doporučeno AES 256). Algoritmy, jako jsou RC4, DES a TripleDES, jsou zastaralé a neměly by se používat kvůli známým chybám zabezpečení.

  • Chraňte symetrické klíče asymetrickými klíči nebo certifikáty (ne hesly), abyste se vyhnuli používání 3DES.

  • Při migraci databáze pomocí šifrování na úrovni buňky buďte opatrní při exportu a importu (soubory bacpac).

    • Přečtěte si článek Doporučení pro použití šifrování na úrovni buněk ve službě Azure SQL Database, kde se dozvíte, jak zabránit ztrátě klíčů při migraci dat a další pokyny k osvědčeným postupům.

Mějte na paměti, že funkce Always Encrypted je primárně navržena tak, aby chránila citlivá data v průběhu zpracování před uživateli Azure SQL Database s vysokými oprávněními (cloudovými operátory, DBAs). Další informace naleznete v tématu Ochrana citlivých dat při použití před vysoce privilegovanými neoprávněnými uživateli. Mějte na paměti následující výzvy při použití funkce Always Encrypted k ochraně dat před uživateli aplikací:

  • Ve výchozím nastavení všechny klientské ovladače Microsoftu podporující funkci Always Encrypted udržují globální mezipaměť (jednu na aplikaci) šifrovacích klíčů sloupců. Jakmile klientský ovladač získá šifrovací klíč sloupce ve formátu prostého textu tím, že kontaktuje úložiště klíčů s hlavním klíčem sloupce, uloží se šifrovací klíč sloupce ve formátu prostého textu do mezipaměti. Díky tomu je izolace dat od uživatelů víceuživatelné aplikace náročná. Pokud vaše aplikace zosobňuje koncové uživatele při interakci s úložištěm klíčů (například Azure Key Vault), po provedení uživatelského dotazu, který naplní mezipaměť šifrovacím klíčem sloupce, další dotaz požadující stejný klíč aktivovaný jiným uživatelem použije klíč uložený v mezipaměti. Ovladač nezavolá úložiště klíčů a nezkontroluje, jestli má druhý uživatel oprávnění pro přístup k šifrovacímu klíči sloupce. V důsledku toho může uživatel zobrazit šifrovaná data, i když uživatel nemá přístup ke klíčům. Pokud chcete dosáhnout izolace uživatelů v rámci aplikace s více uživateli, můžete zakázat ukládání šifrovacích klíčů sloupců do mezipaměti. Zakázání ukládání do mezipaměti způsobí další režijní náklady na výkon, protože ovladač bude muset kontaktovat úložiště klíčů pro každou operaci šifrování nebo dešifrování dat.

Ochrana dat před neoprávněným prohlížením uživatelů aplikací při zachování formátu dat

Další technikou, jak zabránit neoprávněným uživatelům v zobrazování dat, je obfuskat nebo maskovat data při zachování datových typů a formátů, aby aplikace uživatelů mohly pokračovat v zpracování a zobrazení dat.

Implementace

Poznámka:

Funkce Always Encrypted nefunguje s dynamickým maskováním dat. Není možné šifrovat a maskovat stejný sloupec, což znamená, že potřebujete určit prioritu ochrany dat, která se používají, a maskování dat pro uživatele aplikace prostřednictvím dynamického maskování dat.

Osvědčené postupy

Poznámka:

Dynamické maskování dat nelze použít k ochraně dat před uživateli s vysokými oprávněními. Zásady maskování se nevztahují na uživatele s přístupem pro správu, jako je db_owner.

  • Neumožňujte uživatelům aplikace spouštět ad hoc dotazy (protože by mohli obejít dynamické maskování dat). Další informace najdete v tématu Obejití maskování pomocí odvození nebo technik hrubou silou.

  • Pomocí správné zásady řízení přístupu (prostřednictvím oprávnění SQL, rolí, zabezpečení na úrovni řádků) omezte uživatelská oprávnění k provádění aktualizací v maskovaných sloupcích. Vytvoření masky ve sloupci nebrání aktualizacím daného sloupce. Uživatelé, kteří obdrží maskovaná data při dotazování na maskovaný sloupec, mohou aktualizovat data, pokud mají oprávnění k zápisu.

  • Dynamické maskování dat nezachová statistické vlastnosti maskovaných hodnot. To může mít vliv na výsledky dotazu (například dotazy obsahující predikáty filtrování nebo spojení na maskovaných datech).

Zabezpečení sítě

Zabezpečení sítě se týká řízení přístupu a osvědčených postupů pro zabezpečení přenášených dat do služby Azure SQL Database.

Konfigurace klienta pro zabezpečené připojení ke službě SQL Database nebo spravované instanci SQL

Osvědčené postupy, jak zabránit klientským počítačům a aplikacím s dobře známými ohroženími zabezpečení (například pomocí starších protokolů TLS a šifrovacích sad) z připojení ke službě Azure SQL Database a spravované instanci SQL.

Implementace

Osvědčené postupy

  • Vynucujte minimální verzi protokolu TLS na logickém serveru ve službě Azure SQL Database nebo ve službě Azure SQL Managed Instance pomocí minimálního nastavení verze protokolu TLS. Po testování doporučujeme nastavit minimální verzi protokolu TLS na verzi 1.2, abyste potvrdili, že ji vaše aplikace podporují. Protokol TLS 1.2 obsahuje opravy chyb zabezpečení nalezených v předchozích verzích.

  • Konfigurace všech aplikací a nástrojů pro připojení ke službě SQL Database s povoleným šifrováním

    • Encrypt = On, TrustServerCertificate = Off (nebo ekvivalentní s ovladači jiných výrobců než Microsoft).

  • Pokud vaše aplikace používá ovladač, který nepodporuje protokol TLS nebo podporuje starší verzi protokolu TLS, nahraďte ovladač, pokud je to možné. Pokud to není možné, pečlivě vyhodnoťte rizika zabezpečení.

Minimalizace prostoru pro útoky

Minimalizujte počet funkcí, které může uživatel se zlými úmysly napadnout. Implementujte řízení přístupu k síti pro Azure SQL Database.

Zmíněno v: OSA Practice #5

Implementace

Ve službě Azure SQL Database:

  • Nastavte možnost Povolit přístup ke službám Azure na úrovni serveru na vypnuto.
  • Použijte koncové body služby VNet a pravidla brány firewall VNet.
  • Použijte Službu Private Link.

Ve službě SQL Managed Instance:

Osvědčené postupy

  • Omezení přístupu ke službě Azure SQL Database a spravované instanci SQL připojením k privátnímu koncovému bodu (například pomocí privátní cesty k datům):

    • Spravovanou instanci je možné izolovat uvnitř virtuální sítě, aby se zabránilo externímu přístupu. Aplikace a nástroje, které jsou ve stejné nebo partnerské virtuální síti ve stejné oblasti, k ní mají přímý přístup. Aplikace a nástroje, které jsou v jiném regionu, můžou k navázání připojení použít připojení typu virtual-network-to-virtual-network nebo propojení okruhu ExpressRoute. Zákazník by měl použít skupiny zabezpečení sítě (NSG) k omezení přístupu přes port 1433 jenom k prostředkům, které vyžadují přístup ke spravované instanci.
    • Pro Azure SQL Database použijte službu Private Link, která poskytuje vyhrazenou privátní IP adresu pro server uvnitř vaší virtuální sítě. K omezení přístupu k logickým serverům můžete použít také koncové body služby virtuální sítě .
    • Mobilní uživatelé by měli pro připojení přes datovou cestu použít připojení VPN typu point-to-site.
    • Uživatelé připojení ke své místní síti by měli k připojení přes datovou cestu použít připojení VPN typu site-to-site nebo ExpressRoute.

  • Ke službě Azure SQL Database a sql Managed Instance se dostanete tak, že se připojíte k veřejnému koncovému bodu (například pomocí cesty k veřejným datům). Měli byste zvážit následující osvědčené postupy:

    Poznámka:

    Veřejný koncový bod služby SQL Managed Instance není ve výchozím nastavení povolený a musí být explicitně povolený. Pokud zásady společnosti nepovolují použití veřejných koncových bodů, použijte Azure Policy , abyste zabránili povolení veřejných koncových bodů na prvním místě.

  • Nastavení síťových komponent Azure:

Konfigurace Power BI pro zabezpečená připojení ke službě SQL Database nebo sql Managed Instance

Osvědčené postupy

Konfigurace služby App Service pro zabezpečená připojení ke službě SQL Database nebo sql Managed Instance

Osvědčené postupy

Konfigurace hostování virtuálních počítačů Azure pro zabezpečená připojení ke službě SQL Database nebo SQL Managed Instance

Osvědčené postupy

  • Pomocí kombinace pravidel Povolit a Odepřít na NSG virtuálních počítačů Azure můžete řídit, ke kterým oblastem je možné z virtuálního počítače přistupovat.

  • Ujistěte se, že je váš virtuální počítač nakonfigurovaný podle článku, osvědčených postupů zabezpečení pro úlohy IaaS v Azure.

  • Ujistěte se, že jsou všechny virtuální počítače přidružené ke konkrétní virtuální síti a podsíti.

  • Vyhodnoťte, jestli potřebujete výchozí trasu 0.0.0.0/Internet podle pokynů k vynucenému tunelování.

    • Pokud ano – například front-endová podsíť – ponechte výchozí trasu.
    • Pokud ne – například střední nebo back-endová podsíť – povolte vynucené tunelování, aby se žádný provoz nepřesměrovává přes internet, aby se dostal do místního prostředí (a.k.a mezi místy).

  • Pokud používáte peering nebo se připojujete k lokálním systémům, implementujte volitelné výchozí trasy.

  • Pokud potřebujete odeslat veškerý provoz ve virtuální síti do síťového virtuálního zařízení pro kontrolu paketů, implementujte trasy definované uživatelem.

  • Použijte koncové body virtuální sítě pro zabezpečený přístup ke službám PaaS, jako je Azure Storage, prostřednictvím páteřní sítě Azure.

Ochrana před útoky DDoS (Distributed Denial of Service)

Útoky DDoS (Distributed Denial of Service) se snaží škodlivý uživatel odeslat do služby Azure SQL Database záplavu síťového provozu s cílem přetížení infrastruktury Azure a způsobení, že Azure zamítne platná přihlášení a úlohy.

Zmínka v: OSA Practice #9

Implementace

Ochrana před útoky DDoS je automaticky povolená jako součást platformy Azure. Zahrnuje nepřetržité monitorování provozu a zmírnění útoků na úrovni sítě na veřejné koncové body v reálném čase.

Osvědčené postupy

  • Postupujte podle postupů popsaných v Minimalizovat útokovou plochu, aby se minimalizovaly hrozby útoku DDoS.

  • Upozornění služby Advanced Threat Protection brute force přihlašovací údaje SQL pomáhá zjišťovat útoky hrubou silou. V některých případech může výstraha dokonce rozlišovat úlohy penetračního testování.

  • Pro virtuální počítače Azure hostující aplikace připojující se ke službě SQL Database:

    • Pokud chcete omezit přístup prostřednictvím internetových koncových bodů v Programu Microsoft Defender for Cloud, postupujte podle doporučení.
    • Škálovací sady virtuálních počítačů můžete použít ke spouštění více instancí aplikace na virtuálních počítačích Azure.
    • Zakažte protokol RDP a SSH z internetu, abyste zabránili útoku hrubou silou.

Sledování, protokolování a auditování

Tato část se týká možností, které vám pomůžou odhalit neobvyklé aktivity, které značí neobvyklé a potenciálně škodlivé pokusy o přístup k databázím nebo jejich zneužití. Popisuje také osvědčené postupy konfigurace auditování databáze pro sledování a zachytávání databázových událostí.

Ochrana databází před útoky

Rozšířená ochrana před internetovými útoky umožňuje detekovat potenciální hrozby a reagovat na ně tak, že poskytuje výstrahy zabezpečení na neobvyklé aktivity.

Implementace

  • Pomocí služby Advanced Threat Protection pro SQL můžete detekovat neobvyklé a potenciálně škodlivé pokusy o přístup k databázím nebo jejich zneužití, mezi které patří:
    • Útok prostřednictvím injektáže SQL
    • Krádež nebo únik přihlašovacích údajů
    • Zneužití oprávnění
    • Exfiltrace dat.

Osvědčené postupy

  • Nakonfigurujte Microsoft Defender pro SQL pro konkrétní server nebo spravovanou instanci. Microsoft Defender pro SQL můžete také nakonfigurovat pro všechny servery a spravované instance v předplatném tak, že povolíte Microsoft Defender for Cloud.

  • Pro úplné šetření se doporučuje povolit auditování pro Azure SQL Database. Pomocí auditování můžete sledovat události databáze a zapisovat je do protokolu auditu v účtu azure Storage nebo pracovním prostoru Služby Azure Log Analytics.

Auditování kritických událostí zabezpečení

Sledování databázových událostí vám pomůže porozumět databázové aktivitě. Můžete získat přehled o nesrovnalostech a anomáliích, které můžou značit obchodní obavy nebo podezření na narušení zabezpečení. Také umožňuje a usnadňuje dodržování standardů dodržování předpisů.

Implementace

  • Povolte auditování služby Azure SQL Database nebo auditování služby SQL Managed Instance , abyste mohli sledovat události databáze a zapisovat je do protokolu auditu ve vašem účtu služby Azure Storage, pracovním prostoru služby Log Analytics (Preview) nebo ve službě Event Hubs (Preview).

  • Protokoly auditu je možné zapsat do účtu služby Azure Storage, do pracovního prostoru služby Log Analytics pro využití protokoly služby Azure Monitor nebo do centra událostí pro spotřebu pomocí centra událostí. Můžete nakonfigurovat libovolnou kombinaci těchto možností a protokoly auditu se zapíšou do každé z nich.

Osvědčené postupy

  • Konfigurací auditování pro Azure SQL Database nebo Azure SQL Managed Instance pro auditování událostí budou auditovány všechny existující a nově vytvořené databáze na tomto serveru.
  • Ve výchozím nastavení zásady auditování zahrnují všechny akce (dotazy, uložené procedury a úspěšná a neúspěšná přihlášení) vůči databázím, což může vést k velkému objemu protokolů auditu. Zákazníkům se doporučuje nakonfigurovat auditování pro různé typy akcí a skupin akcí pomocí PowerShellu. Tato konfigurace pomůže řídit počet auditovaných akcí a minimalizovat riziko ztráty událostí. Konfigurace vlastního auditu umožňují zákazníkům zaznamenávat jenom potřebná data auditu.
  • Protokoly auditu je možné využívat přímo na webu Azure Portal nebo z nakonfigurovaného umístění úložiště.

Poznámka:

Povolení auditování pro Log Analytics bude účtováno na základě míry příjmu. Mějte na paměti související náklady s použitím této možnosti nebo zvažte uložení protokolů auditu do účtu úložiště Azure.

Další zdroje informací

Zabezpečené protokoly auditu

Omezte přístup k účtu úložiště za účelem podpory segregace kompetencí a oddělení DBA od auditorů.

Implementace

  • Při ukládání protokolů auditu do Služby Azure Storage se ujistěte, že je přístup k účtu úložiště omezený na minimální zásady zabezpečení. Určete, kdo má přístup k účtu úložiště.
  • Další informace najdete v tématu Autorizace přístupu ke službě Azure Storage.

Osvědčené postupy

Správa zabezpečení

Tato část popisuje různé aspekty a osvědčené postupy pro správu stavu zabezpečení databází. Obsahuje osvědčené postupy pro zajištění, aby vaše databáze byly nakonfigurované tak, aby splňovaly standardy zabezpečení, pro zjišťování a klasifikaci a sledování přístupu k potenciálně citlivým datům ve vašich databázích.

Ujistěte se, že jsou databáze nakonfigurované tak, aby splňovaly osvědčené postupy zabezpečení.

Proaktivně vylepšete zabezpečení databáze zjišťováním a nápravou potenciálních ohrožení zabezpečení databáze.

Implementace

Osvědčené postupy

  • Zpočátku na databázích spusťte VA a iterujte tím, že opravíte neúspěšné kontroly, které brání osvědčeným postupům zabezpečení. Nastavte základní hodnoty pro přijatelné konfigurace, dokud kontrola není čistá, nebo neproběhnou všechny kontroly.

  • Nakonfigurujte pravidelné opakované kontroly tak, aby běžely jednou týdně, a nakonfigurujte příslušnou osobu tak, aby dostávala souhrnné e-maily.

  • Projděte si souhrn posouzení zranitelnosti po každém týdenním skenu. U nalezených chyb zabezpečení vyhodnoťte odchylku od předchozího výsledku kontroly a určete, jestli se má kontrola vyřešit. Zkontrolujte, jestli existuje legitimní důvod ke změně konfigurace.

  • Vyřešte kontroly a aktualizujte základní linie, kde je to relevantní. Vytvořte položky tiketu pro vyřešení akcí a sledujte, dokud nebudou vyřešeny.

Další zdroje informací

Identifikace a označování citlivých dat

Objevte sloupce, které mohou obsahovat citlivá data. To, co se považuje za citlivá data, silně závisí na zákaznících, nařízení o dodržování předpisů atd., a musí je vyhodnotit uživatelé, kteří mají na starosti tato data. Klasifikujte sloupce tak, aby používaly pokročilé scénáře auditování a ochrany založené na citlivosti.

Implementace

  • Pomocí zjišťování a klasifikace dat můžete zjišťovat, klasifikovat, popisovat a chránit citlivá data v databázích.
    • Zobrazte doporučení klasifikace vytvořená automatizovaným zjišťováním na řídicím panelu zjišťování a klasifikace dat SQL. Přijměte příslušné klasifikace, aby vaše citlivá data byla trvale označená popisky klasifikace.
    • Ručně přidejte klasifikace pro všechna další citlivá datová pole, která nebyla zjištěna automatizovaným mechanismem.
  • Další informace najdete v tématu Zjišťování a klasifikace dat SQL.

Osvědčené postupy

  • Pravidelně monitorujte řídicí panel klasifikace, aby bylo možné přesně posoudit stav klasifikace databáze. Sestavu o stavu klasifikace databáze je možné exportovat nebo vytisknout, aby se sdílela pro účely dodržování předpisů a auditování.

  • Nepřetržitě monitorujte stav doporučených citlivých dat v posouzení ohrožení zabezpečení SQL. Sledujte pravidlo zjišťování citlivých dat a identifikujte případné odchylky v doporučených sloupcích pro klasifikaci.

  • Klasifikace se používá způsobem, který je přizpůsobený konkrétním potřebám vaší organizace. Přizpůsobte si zásady Information Protection (popisky citlivosti, typy informací, logika zjišťování) v zásadách služby SQL Information Protection v programu Microsoft Defender for Cloud.

Sledování přístupu k citlivým datům

Sledujte, kdo přistupuje k citlivým datům a zachytává dotazy na citlivá data v protokolech auditu.

Implementace

Osvědčené postupy

Vizualizace stavu zabezpečení a dodržování předpisů

Použijte jednotný systém pro správu zabezpečení infrastruktury, který posiluje stav zabezpečení datových center (včetně databází ve službě SQL Database). Prohlédněte si seznam doporučení týkajících se zabezpečení databází a stavu dodržování předpisů.

Implementace

Běžné bezpečnostní hrozby a potenciální zmírnění rizik

Tato část vám pomůže najít bezpečnostní opatření pro ochranu před určitými vektory útoku. Očekává se, že většinu omezení rizik je možné dosáhnout pomocí jednoho nebo několika výše uvedených pokynů zabezpečení.

Bezpečnostní hrozba: Exfiltrace dat

Exfiltrace dat je neoprávněné kopírování, přenos nebo načítání dat z počítače nebo serveru. Podívejte se na Wikipedii na definici exfiltrace dat.

Připojení k serveru prostřednictvím veřejného koncového bodu představuje riziko exfiltrace dat, protože zákazníci musí otevřít své brány firewall veřejným IP adresám.

Scénář 1: Aplikace na virtuálním počítači Azure se připojí k databázi ve službě Azure SQL Database. Podvodný herec získá přístup k virtuálnímu počítači a naruší ho. V tomto scénáři exfiltrace dat znamená, že externí entita používající podvodný virtuální počítač se připojí k databázi, zkopíruje osobní údaje a uloží je do úložiště objektů blob nebo jiné služby SQL Database v jiném předplatném.

Scénář 2: Nepoctivý správce databáze Tento scénář často zmiňují zákazníci z regulovaných odvětví, kteří jsou citliví na zabezpečení. V tomto scénáři může uživatel s vysokou úrovní oprávnění kopírovat data ze služby Azure SQL Database do jiného předplatného, které vlastník dat neřídí.

Potenciální zmírnění rizik

Azure SQL Database a SQL Managed Instance dnes nabízejí následující techniky pro zmírnění hrozeb exfiltrace dat:

  • Pomocí kombinace pravidel Povolit a Odepřít na skupinách zabezpečení sítě u virtuálních počítačů Azure můžete řídit, ke kterým oblastem může virtuální počítač přistupovat.
  • Pokud používáte server ve službě SQL Database, nastavte následující možnosti:
    • Povolit službám Azure vypnuto.
    • Povolte provoz jenom z podsítě obsahující virtuální počítač Azure nastavením pravidla brány firewall virtuální sítě.
    • Použití služby Private Link
  • U služby SQL Managed Instance řeší výchozí použití privátní IP adresy problém s exfiltrací dat VM, které by mohly být považovány za hrozbu. Zapněte funkci delegování podsítě v podsíti, aby se automaticky nastavily nejvíce omezující zásady v podsíti služby SQL Managed Instance.
  • Problém s neautorizovaným DBA je u služby SQL Managed Instance více zřetelný, protože má větší zranitelnou plochu a požadavky na síť jsou pro zákazníky viditelné. Nejlepší způsob, jak zmírnit toto riziko, je použití všech praktických postupů uvedených v tomto průvodci zabezpečením, aby se od samého začátku zabránilo scénáři Rogue DBA (nejen pro exfiltraci dat). Funkce Always Encrypted je jednou z metod ochrany citlivých dat tím, že je zašifruje a udržuje klíč nepřístupný pro DBA.

Aspekty zabezpečení provozní kontinuity a dostupnosti

Většina bezpečnostních standardů se zabývá dostupností dat z důvodu zajištění provozní kontinuity, což se dosahuje implementací redundance a možností přesunu provozu na záložní systémy, aby se předešlo jednotlivým bodům selhání. V případě scénářů havárie je běžné uchovávat zálohy souborů dat a protokolů. Následující část obsahuje základní přehled možností, které jsou integrované v Azure. Poskytuje také další možnosti, které je možné nakonfigurovat tak, aby splňovaly konkrétní potřeby:

Další krok

Přehled možností zabezpečení služby Azure SQL Database a SQL Managed Instance