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

  • Článek

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ší stávající dokumentaci zabezpečení azure SQL Database.

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 k objektům zabezpečení Microsoft Entra prostřednictvím přiřazení skupiny: Vytvořte skupiny Microsoft Entra, udělte přístup ke skupinám a přidejte do skupin jednotlivé č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 vlastníka skupiny a vlastník prostředku může přidávat nebo odebírat členy do/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 pomocí sestav aktivit auditu 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ánová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 není možné se vyhnout heslům nebo tajným kódům tajných kódů, ukládejte hesla uživatelů a tajné kódy aplikací ve službě Azure Key Vault a spravujte přístup prostřednictvím zásad přístupu ke službě 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 článku Stačí 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 pomáhají výrazně 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í
    • Správce
    • Vývojář
    • Pracovníci podpory
    • Auditor
    • 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ématu
      • 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řepíše GRANT na úrovni sloupce. To by vyžadovalo aktivaci konfigurace serveru dodržování běžných kritérií.

  • Proveďte pravidelné kontroly pomocí posouzení ohrožení zabezpečení (VA) a otestujte 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 databázového Správa istratoru (DBA) 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 způsobit, že by systém mohl být 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). Vytváření rolí pomáhá výrazně s vytvářením sestav a odstraňováním 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í.

  • Vytváření a používání uživatelem definovaných rolí při udělení příliš velkého počtu oprávnění nebo nedostatečných 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 dbA nemají přístup k šifrovacím klíčům nebo úložištím klíčů a že bezpečnostní Správa istrátory 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 potenciální zvýšení rizik oprávnění a také úpravy škodlivých dat, které chrání před podvodem a neoprávněným přístupem. 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 osoba, která provádí kontrolu, jinou osobou, než je 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 spravovanou instanci SQL 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 Level 1 a ověřených instancí úrovně 1 FIPS 140-2 úrovně 1, včetně konzistence s požadovanými délkami klíčů, správou klíčů, generováním klíčů a úložiště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 "dodržování předpisů FIPS 140-2 level 1" použité ve výše uvedeném prohlášení k předvedení jejich zamýšlené použitelnosti pro usa a kanadskou vládu použití jiné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í neaktivních uložených dat je kryptografickou ochranou dat, když je trvale uložená v databázi, protokolu 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.
  • Pokud se ve spravované instanci vytvoří databáze z operace obnovení pomocí místního serveru, bude respektovat nastavení transparentního šifrování dat 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 data, která vyžadují šifrování neaktivních uložených dat v master databázi. Databázi master nejde zašifrovat pomocí transparentního šifrování dat.

  • Pokud potřebujete větší transparentnost a podrobnou kontrolu nad ochranou transparentního šifrování dat, 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 ochranu transparentním šifrováním dat spolu s dalšími klíči nebo obměňovat ochranu transparentním šifrováním dat podle vlastního plánu.

  • Pokud ve službě Azure Key Vault používáte klíče spravované zákazníkem, postupujte podle článků, pokynů ke konfiguraci transparentního šifrování dat se službou Azure Key Vault a postupu konfigurace geografického zotavení po havárii se službou Azure Key Vault.

Poznámka:

Některé položky, které se považují za obsah zákazníka, 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í funkce 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, a to i v paměti nebo používaném prostředí. Funkce Always Encrypted chrání data před databázovými Správa istrátory (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

  • Funkce Always Encrypted není náhradou za šifrování neaktivních uložených dat ani přenášených dat (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í funkce Always Encrypted ve spojení s transparentním šifrováním dat a protokolem TLS (Transport Layer Security) se doporučuje pro komplexní ochranu neaktivních uložených dat, přenosu a 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 změnit architekturu aplikace, aby znovu zkompilovala funkčnost, dotaz nepodporuje na straně klienta nebo/a refaktoruje schéma databáze, včetně definic 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 mít vliv také na výkon dotazů v závislosti na charakteristikách 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. DbA vytvoří hlavní klíč sloupce a objekty metadat šifrovacího klíče sloupce popisující 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í DATABÁZE VIEW ANY COLUMN MASTER KEY DEFINITION a ZOBRAZIT VŠECHNA OPRÁVNĚNÍ DEFINICE ŠIFROVACÍHO KLÍČE SLOUPCE.

Ří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žená tak, aby chránila citlivá data užitá před uživateli azure SQL Database s vysokými oprávněními (cloudoví operátoři, DBA) – viz 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 zosobní koncové uživatele při interakci s úložištěm klíčů (jako je Azure Key Vault), po naplnění dotazu uživatelem šifrovacím klíčem sloupce bude následující dotaz, který vyžaduje stejný klíč, ale aktivuje ho jiný uživatel, 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.

  • Nepovolujte uživatelům aplikace spouštět ad hoc dotazy (protože můžou fungovat s dynamickým maskováním dat).

  • 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 dotazů (například dotazy obsahující predikáty filtrování nebo spojení maskovaných dat).

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

  • Pomocí minimálního nastavení verze protokolu TLS vynucujte minimální verzi protokolu TLS na serveru SLUŽBY SQL Database nebo na úrovni spravované instance SQL. 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í.

    • Omezte vektory útoku prostřednictvím ohrožení zabezpečení v SSL 2.0, SSL 3.0, TLS 1.0 a TLS 1.1 tak, že je zakážete na klientských počítačích připojujících se ke službě Azure SQL Database na nastavení registru TLS (Transport Layer Security).
    • Zkontrolujte šifrovací sady dostupné na klientovi: Šifrovací sady v TLS/SSL (Schannel SSP) Konkrétně zakažte 3DES na konfiguraci pořadí šifrovací sady TLS.

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ě SQL Database:

  • Nastavte možnost Povolit přístup ke službám Azure na úrovni serveru na vypnuto.
  • Použijte koncové body služby virtuální sítě a pravidla brány firewall virtuální sítě.
  • 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é oblasti, můžou k navázání připojení použít připojení typu virtual-network-to-virtual-network nebo partnerský vztah 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 službu SQL Database použijte funkci Private Link , která poskytuje vyhrazenou privátní IP adresu serveru ve vaší virtuální síti. K omezení přístupu k vašim serverům můžete také použít koncové body služby virtuální sítě s pravidly brány firewall 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:

    • Pro server ve službě SQL Database použijte pravidla brány firewall protokolu IP k omezení přístupu jenom na autorizované IP adresy.
    • Pro službu SQL Managed Instance použijte skupiny zabezpečení sítě (NSG) k omezení přístupu přes port 3342 jenom na požadované prostředky. Další informace najdete v tématu Bezpečné použití spravované instance s veřejnými koncovými body.

    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 místnímu prostředí, 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.

  • Koncové body služby virtuální sítě slouží k zabezpečení přístupu 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ží uživatel se zlými úmysly odeslat do služby Azure SQL Database záplavu síťového provozu s cílem zahlcení infrastruktury Azure a jeho příčinou zamítnutí platných přihlášení a úloh.

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 části Minimalizovat útok surface pomáhá minimalizovat hrozby útoku DDoS.

  • Upozornění na přihlašovací údaje SQL služby Advanced Threat Protection hrubou silou 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í služby 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 SQL Database nebo auditování spravované 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í služby SQL Database na serveru nebo auditování spravované 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 účtují náklady na základě míry příjmu dat. 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ě tak, aby podporoval oddělení povinností 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

  • Povolte posouzení ohrožení zabezpečení SQL (VA) a vyhledejte v databázi problémy se zabezpečením a pravidelně je spouštět v databázích.

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 standardní hodnoty pro přijatelné konfigurace, dokud se kontrola nevyčistí, nebo neproběhne 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í ohrožení sítě po každé týdenní kontrole. 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.

  • V případě potřeby vyřešte kontroly a směrné plány aktualizací. Vytvořte položky lístku pro řešení akcí a sledujte je, dokud se nevyřeší.

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 SQL 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 definici exfiltrace dat na Wikipedii.

Připojení na server přes veřejný koncový bod představuje riziko exfiltrace dat, protože vyžaduje, aby zákazníci otevřeli 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: Podvodná databáze Tento scénář často vyvolává zákazníci citlivé na zabezpečení z regulovaných odvětví. 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ízí následující techniky pro zmírnění hrozeb exfiltrace dat:

  • Pomocí kombinace pravidel povolit a odepřít skupiny zabezpečení sítě 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.
  • 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 ve výchozím nastavení používá privátní IP adresa první problém s exfiltrací dat neautorného virtuálního počítače. 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 rogue DBA je u služby SQL Managed Instance více vystavený, protože má větší prostor a požadavky na síť jsou viditelné pro zákazníky. Nejlepší zmírnění tohoto rizika spočívá v použití všech postupů v tomto průvodci zabezpečením, aby se zabránilo scénáři Rogue DBA na prvním místě (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šinastandardůch 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ší kroky