Playbook pro adresování běžných požadavků na zabezpečení pomocí Azure SQL Database a spravované Instance Azure SQL

  • Článek
  • 38 min ke čtení

PLATÍ PRO: Azure SQL Database Azure SQL Managed Instance

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

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

tento dokument poskytuje pokyny, jak řešit běžné požadavky na zabezpečení pro nové nebo existující aplikace pomocí Azure SQL Database a spravované Instance Azure SQL. Je uspořádána podle oblastí zabezpečení vysoké úrovně. Informace o konkrétních hrozbách najdete v části běžné bezpečnostní hrozby a potenciální rizika . I když jsou při migraci aplikací z místního prostředí do Azure k dispozici některá z uvedených doporučení, scénáře migrace nejsou zaměřeny na tento dokument.

nabídky nasazení Azure SQL Database zahrnuté v této příručce

Nabídky nasazení, které nejsou zahrnuté v tomto průvodci

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

Cílová skupina

V této příručce jsou zamýšlení zákazníci, kteří čelí dotazům k zabezpečení Azure SQL Database. Role, které mají zájem v tomto článku o osvědčených postupech, zahrnují, ale ne omezení na:

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

Pomocí této příručky

tento dokument je určený jako doprovodný průvodce pro naši stávající dokumentaci k zabezpečení Azure SQL Database .

Pokud není uvedeno jinak, doporučujeme, abyste provedli všechny osvědčené postupy uvedené v jednotlivých částech, 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 v části požadavky nebo cíle uvedeny důležité kontroly dodržování předpisů, ať už je to možné. Jedná se o standardy zabezpečení a předpisy, na které se odkazuje v tomto dokumentu:

Chystáme se dál aktualizovat doporučení a osvědčené postupy, které jsou tady uvedené. Zadáním odkazu na zpětnou vazbu na konci tohoto článku zadejte nebo opravte tento dokument.

Authentication

Ověřování je proces, který označuje, že uživatel vyžádá. spravovaná Instance Azure SQL Database a SQL podporuje dva typy ověřování:

  • Ověřování SQL
  • Ověřování služby Azure Active Directory

Poznámka

pro všechny nástroje a aplikace třetích stran nemusí být ověřování Azure Active Directory podporováno.

Centrální Správa identit

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

  • Spravujte účty skupin a řízení uživatelských oprávnění bez duplikování přihlašovacích údajů 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.

Jak implementovat:

  • použijte ověřování pomocí Azure Active Directory (Azure AD) pro centralizovanou správu identit.

Osvědčené postupy:

  • Vytvořte tenanta Azure AD a Vytvořte uživatele, kteří budou představovat lidské uživatele, a vytvořit instanční objekty , které budou představovat aplikace, služby a nástroje pro automatizaci. instanční objekty jsou stejné jako účty služeb v Windows a Linux.

  • Přiřazení přístupových práv k prostředkům k objektům zabezpečení Azure AD prostřednictvím přiřazení skupiny: Vytvoření skupin Azure AD, udělení přístupu ke skupinám a přidání jednotlivých členů do skupin. V databázi vytvořte uživatele databáze s omezením, kteří mapují vaše skupiny Azure AD. Pokud chcete přiřadit oprávnění v rámci databáze, uveďte uživatele přidružené ke skupinám Azure AD v databázových rolích s příslušnými oprávněními.

    Poznámka

    v SQL spravovaná Instance můžete také vytvořit přihlašovací údaje, které se mapují na objekty zabezpečení Azure AD v hlavní databázi. Viz Create Login (Transact-SQL).

  • Použití skupin Azure AD zjednodušuje správu oprávnění a vlastníka skupiny a vlastník prostředku může přidat nebo odebrat členy do/ze skupiny.

  • Pro všechny servery nebo spravované instance Vytvořte samostatnou skupinu pro správce Azure AD.

  • Sledujte změny členství ve skupinách Azure AD pomocí sestav aktivit auditu Azure AD.

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

Poznámka

  • ověřování azure ad se zaznamenává v protokolech auditu azure SQL, ale ne v protokolech přihlášení služby azure ad.
  • oprávnění azure RBAC udělená v Azure se nevztahují na Azure SQL Database nebo SQL oprávnění ke správě instancí. taková oprávnění musí být vytvořena nebo mapována ručně pomocí stávajících oprávnění SQL.
  • Na straně klienta potřebuje ověřování Azure AD přístup k Internetu nebo prostřednictvím uživatelsky definované trasy (UDR) do virtuální sítě.
  • Přístupový token Azure AD je uložený v mezipaměti na straně klienta a jeho životnost závisí na konfiguraci tokenu. Viz článek, konfigurovatelné životnosti tokenů v Azure Active Directory
  • Pokyny k řešení potíží s ověřováním Azure AD najdete na následujícím blogu: řešení potíží s Azure AD.

Vícefaktorové ověřování Azure AD

Zmíněné v: #2 praxe metody OSA, ISO Access Control (AC)

Služba Azure AD Multi-Factor Authentication pomáhá zvýšit zabezpečení tím, že vyžaduje více než jednu formu ověřování.

Jak implementovat:

  • Povolte Multi-Factor Authentication ve službě Azure AD pomocí podmíněného přístupu a použijte interaktivní ověřování.

  • Alternativou je povolení Multi-Factor Authentication pro celou doménu služby Azure AD nebo AD.

Osvědčené postupy:

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

Zmíněno 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 je možné ohrozit nebo omylem prozrazeny.

Jak implementovat:

  • Použijte integrované ověřování Azure AD, které eliminuje používání hesel.

Osvědčené postupy:

  • Použijte ověřování pomocí jednotného přihlašování pomocí Windows přihlašovacích údajů. Federovat místní doménu AD s Azure AD a používat integrované ověřování Windows (pro počítače připojené k doméně s Azure AD).

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

Zmíněno v: OSA Practice č. 4, ISO Access Control (AC)

Jak implementovat:

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

Osvědčené postupy:

Ochrana hesel a tajných kódů

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

Jak implementovat:

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

Osvědčené postupy:

  • Pokud se vyhnete možným hesly nebo tajným kódům, uložte si uživatelská hesla a tajné kódy aplikací do Azure Key Vault a spravujte přístup prostřednictvím zásad Key Vault přístupu.

  • Různá rozhraní pro vývoj aplikací mohou také nabízet mechanismy pro ochranu tajných kódů v aplikaci specifické pro jednotlivé architektury. Příklad: ASP.NET aplikace.

Použití SQL pro starší verze aplikací

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

Jak implementovat:

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

Osvědčené postupy:

Správa přístupu

Správa přístupu (také nazývaná autorizace) je proces řízení a správy přístupu a oprávnění autorizovaných uživatelů pro Azure SQL Database nebo SQL spravované instance.

Implementace principu nejmenších oprávnění

Zmíněno v: Ovládací prvky FedRamp AC-06, NIST: AC-6, OSA Practice č. 3

Princip nejmenší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í svých úkolů. Další informace najdete v článku Just enough administration.

Jak implementovat:

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

Osvědčené postupy:

Následující osvědčené postupy jsou volitelné, ale mají 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 nejmenšími možnými sadami oprávnění a začněte přidávat oprávnění jednu po druhé, pokud existuje skutečná nutnost (a odůvodnění) – na rozdíl od opačného přístupu: odčítá oprávnění krok za krokem.

  • Nepřiřazování oprávnění jednotlivým uživatelům Místo toho používejte role (databázové nebo serverové role) konzistentně. Role velmi pomáhají s vytvářením sestav a s oprávněními pro řešení potíží. (Azure RBAC podporuje přiřazení oprávnění pouze 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í přesně odpovídají 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 je možné použít v následujících oborech (menší obor, tím menší je dopad udělených oprávnění):

    Poznámka

    Nedoporučujeme 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 sloupce, která jsou ještě méně doporučovatelná ze stejných důvodů. Uvědomte si také, že ve výchozím nastavení odepření přístupu na úrovni tabulky nepřepisuje grant na úrovni sloupce. To by vyžadovalo aktivaci běžných kritérií dodržování předpisů Konfigurace serveru.

  • Pomocí posouzení ohrožení zabezpečení (VA) pravidelně testujte příliš mnoho oprávnění.

Implementace oddělení povinností

Zmíněno v: FedRamp: AC-04, NIST: AC-5, ISO: A.6.1.2, PCI 6.4.2, SOC: CM-3, SDL-3

Rozdělení povinností, nazývané také oddělení povinností, popisuje požadavek na rozdělení citlivých úloh do několika úkolů přiřazených různým uživatelům. Oddělení povinností pomáhá předcházet únikům dat.

Jak implementovat:

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

    • Mezi vývojovou/testovací a produkční prostředí
    • Citlivé úlohy na úrovni zabezpečení vs. Správci databáze na úrovni správy (DBA) vs. vývojářské úlohy.
      • Příklady: Auditor, vytváření zásad zabezpečení pro zabezpečení na úrovni role (RLS), implementace SQL Database objektů s oprávněními DDL.

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

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

    • Pro úlohy na úrovni správy v Azure Portal nebo prostřednictvím automatizace PowerShellu použijte role Azure. Vyhledejte předdefinovou roli, která odpovídá požadavku, nebo vytvořte vlastní roli Azure s využitím dostupných oprávnění.
    • Vytvořte role serveru pro úlohy na úrovni serveru (vytváření nových přihlášení, databází) ve spravované instanci.
    • Vytvář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 pro provádění úloh 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ě odstraní.

  • Implementujte transparentní šifrování dat (TDE) s klíči spravovanými zákazníkem v 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 mohou stále provádět úlohy DBA, můžete použít Always Encrypted s oddělením rolí.

  • V případech, kdy použití Always Encrypted není proveditelné nebo alespoň ne bez velkých nákladů a úsilí, které by mohlo dokonce způsobit, že systém bude blízko nepoužitelné, je možné ohrožení zabezpečení udělat a zmírnit pomocí kompenzační kontroly, jako jsou:

Osvědčené postupy:

  • Ujistěte se, že se pro vývojová/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řazování oprávnění jednotlivým uživatelům Místo toho používejte role (databázové nebo serverové role) konzistentně. Role vám velmi pomohou s vytvářením sestav a s oprávněními pro řešení potíží.

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

  • Vytváření a používání uživatelem definovaných rolí, když předdefinované role udělují příliš mnoho oprávnění nebo nedostatečná oprávnění.

  • Přiřazení rolí je také možné provést dočasně, označované také jako dynamické oddělení povinností (DSD), a to buď v rámci kroků úlohy agenta SQL v krocích 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šťm klíčů a že správci zabezpečení s přístupem k klíčům nemají k databázi přístup. Použití EKM (Extensible Key Management) může toto oddělení usnadnit. Azure Key Vault je možné použít k implementaci EKM.

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

  • Pomocí PowerShellu můžete načíst definici předdefinované role Azure a zobrazit použitá oprávnění a vytvořit vlastní roli na základě výňatků a kumulace těchto rolí.

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

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

Poznámka

Dosažení oddělení povinností (SoD) je náročné pro úlohy související se zabezpečením nebo odstraňování potíží. Jiné oblasti, jako je vývoj a role koncových uživatelů, se snadněji od sebe odchýlit. 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í, když jiná řešení nejsou praktická.

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

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

Zmíněno 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 nezbytné zkontrolovat, co se nasazovat.

Jak implementovat:

  • 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 tím, než se osoba (jiná než autor samotného kódu) za účelem ochrany před podvody a podvodným přístupem musí v kódu zkontrolovat potenciální zvýšení rizika zvýšení oprávnění a také škodlivé úpravy dat. 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á kontroluly nadměrná oprávnění, používání starých šifrovacích algoritmů a další problémy se zabezpečením ve schématu databáze.

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

  • Příklady toho, na co se dívat:

    • Vytvoření uživatele nebo změna nastavení zabezpečení z automatizovaného nasazení SQL-code-update.
    • Uložená procedura, která v závislosti na poskytnutých parametrech aktualizuje peněžní hodnotu v buňce nevyhovujícím způsobem.

  • Ujistěte se, že osoba, která provádí revize, je jinou osobou než autorem původního kódu a znalostmi v oblasti revize kódu a zabezpečeného 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 jít o ad hoc příkazy, které se mají spouštět nebo nasazovat ve formě zobrazení, funkcí, triggerů a uložených procedur. Může být součástí definice SQL agentů (kroky). Můžete ho také spustit z balíčků SSIS, Azure Data Factory a dalších služeb.

Ochrana dat

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

Poznámka

Microsoft potvrzuje, že Azure SQL Database a SQL Managed Instance jako vyhovující standardu FIPS 140-2 Level 1. To se provádí po ověření striktního použití přijatelných algoritmů FIPS 140-2 Level 1 a instancí těchto algoritmů ověřených podle normy FIPS 140-2 Level 1, včetně konzistence s požadovanými délkami klíčů, správy klíčů, generování klíčů a ukládání klíčů. Toto ověření má zákazníkům umožnit 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 "kompatibilita se standardem FIPS 140-2 Level 1" a "dodržování standardu FIPS 140-2 Level 1" používanými ve výše uvedeném prohlášení k předvedení jejich zamýšlené použitelnosti pro použití v usa a kanadské vládě s jiným termínem "ověřený standard FIPS 140-2 Level 1".

Šifrování dat během přenosu

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

Chrání vaše data při přesouvání dat mezi klientem a serverem. Přečtěte si článek 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í v klidových klidech je kryptografická ochrana dat, pokud jsou uložená v databázi, protokolu a záložních souborech.

Jak implementovat:

  • Transparentní šifrování databáze (TDE) s klíči spravovanými službou je ve výchozím nastavení povolené pro všechny databáze vytvořené po roce 2017 ve službě Azure SQL Database a SQL Managed Instance.
  • Pokud se ve spravované instanci vytvoří databáze z operace obnovení pomocí místního serveru, bude se respektovat nastavení TDE původní databáze. Pokud původní databáze nemá povolené TDE, doporučujeme, aby se pro spravovanou instanci zapnulo TDE ručně.

Osvědčené postupy:

  • Neukládejte data, která vyžadují šifrování v klidových uloženích, do hlavní databáze. Hlavní databázi není možné šifrovat pomocí TDE.

  • Pokud potřebujete větší transparentnost a podrobnou kontrolu nad ochranou transparentním Azure Key Vault klíčů spravovaných zákazníkem, použijte je v nástroji . Azure Key Vault umožňuje kdykoli odvolat oprávnění pro vykreslování databáze jako nedostupné. Ochranu TDE můžete centrálně spravovat společně s ostatními klíči, nebo můžete TDE ochranu pomocí Azure Key Vault sami otočit podle vlastního plánu.

  • Pokud používáte klíče spravované zákazníkem v Azure Key Vault, postupujte podle článků, pokyny pro konfiguraci TDE s Azure Key Vault a Postup konfigurace geografického Dr s Azure Key Vault.

Chránit citlivá data při použití z vysoce privilegovaných nebo neautorizovaných uživatelů

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 uchovává citlivá data, může být vaše organizace nutná k tomu, aby se uživatelům s vysokým oprávněním zabránilo v prohlížení citlivých dat ve vaší databázi. uživatelé s vysokou úrovní oprávnění, jako jsou například operátoři microsoftu nebo specializující ve vaší organizaci, by měli mít přístup k databázi, ale nemusejí zobrazovat a potenciálně staly všudypřítomnými citlivá data z paměti procesu SQL nebo pomocí dotazování databáze.

Zásady, které určují, která data jsou citlivá a zda musí být citlivá data šifrována 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 dodržování předpisů, které je třeba dodržovat. Podívejte se prosím na související požadavky: identifikace a označení citlivých dat.

Jak implementovat:

  • pomocí Always Encrypted zajistěte, aby citlivá data nebyla vystavená ve formátu prostého textu v Azure SQL Database nebo SQL spravované instanci, i v paměti nebo v používání. Always Encrypted chrání data od správců databází (specializující) a cloudových správců (nebo špatných aktérů, které mohou zosobnit vysoce privilegovaných uživatelů) a poskytují 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 zašifrování dat v klidovém režimu (TDE) nebo při přenosu (SSL/TLS). Always Encrypted by se neměla používat pro data, která nejsou citlivá, aby se minimalizoval dopad na výkon a funkčnost. Použití Always Encrypted ve spojení s TDE a protokolem TLS (Transport Layer Security) se doporučuje pro komplexní ochranu neaktivních dat, přenosů a používání.

  • Než nasadíte Always Encrypted do provozní databáze, posuďte dopad šifrování identifikovaných sloupců s citlivými daty. Obecně Always Encrypted snižuje funkčnost dotazů v šifrovaných sloupcích a má další omezení uvedená v podrobnostech o Always Encryptedch funkcích. Proto může být nutné změnit architekt vaší aplikace, aby znovu implementovala funkčnost, dotaz nepodporuje, na straně klienta nebo v refaktorování schématu databáze, včetně definic uložených procedur, funkcí, zobrazení a triggerů. Pokud nedodržují omezení a omezení Always Encrypted, existující aplikace nemusí fungovat s šifrovanými sloupci. I když ekosystém nástrojů, produktů a služeb Microsoftu, které podporují Always Encrypted, roste, mnoho z nich nefunguje s šifrovanými sloupci. Šifrování sloupce může také ovlivnit výkon dotazů v závislosti na charakteristikách vaší úlohy.

  • Pokud používáte Always Encrypted k ochraně dat před škodlivými specializující, spravujte Always Encrypted klíče pomocí oddělování rolí. Při oddělování rolí vytvoří Správce zabezpečení fyzické klíče. Správce databáze vytvoří objekty metadat hlavního klíče sloupce a š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 nebude potřebovat přístup k fyzickým klíčům ve formátu prostého textu.

  • Uložte hlavní klíče sloupců do Azure Key Vault pro usnadnění správy. vyhněte se použití Windowsho úložiště certifikátů (a obecně distribuovaných řešení úložiště klíčů, jako u řešení pro správu nenáročného centra), které provádí správu klíčů pevně.

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

  • Otočí hlavní klíče sloupce podle vašich požadavků na dodržování předpisů. Pokud potřebujete také přetočit šifrovací klíče sloupce, zvažte použití online šifrování k minimalizaci výpadku aplikace.

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

  • pokud máte obavy, že třetí strany přistupují k vašim datům právně bez vašeho souhlasu, zajistěte, aby všechny aplikace a nástroje, které mají přístup k klíčům a datům v prostém textu, běžely mimo Microsoft Azure Cloud. Bez přístupu k klíčům nebude mít třetí strana možnost dešifrovat data, pokud obcházejí šifrování.

  • Always Encrypted neumožňuje snadno udělit dočasný přístup k klíčům (a chráněným datům). Pokud například potřebujete sdílet klíče se službou DBA a povolit tak nástroji DBA některé operace čištění citlivých a šifrovaných dat. Jediným způsobem, jak spolehlivost odvolat přístup k datům z databáze DBA, je použít k otočení šifrovacích klíčů sloupce a hlavních klíčů sloupce pro ochranu dat, což je náročná operace.

  • Aby bylo možné získat přístup k hodnotám v podobě prostého textu v šifrovaných sloupcích, musí mít uživatel přístup k hlavnímu klíči sloupce (CMK), který chrání sloupce, který je nakonfigurovaný v úložišti klíčů obsahujícím CMK. Uživatel musí také mít k dispozici definici hlavního klíče sloupce a zobrazení všech oprávnění pro databázi definic š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 mohla zobrazit nebo aktualizovat pouze konkrétní uživatelé aplikace, kteří mají přístup k kryptografickým klíčům.

Jak implementovat:

  • Použijte šifrování na úrovni buňky (CLE). Podrobnosti najdete v článku o šifrování sloupce dat .
  • Používejte Always Encrypted, ale mějte na paměti omezení. Omezení jsou uvedena níže.

Osvědčené postupy

Při použití CLE:

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

  • Pro šifrování dat použijte AES (doporučeno AES 256). Algoritmy, jako ŠIFRy, 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 pomocí asymetrických klíčů/certifikátů (nikoli hesel), abyste se vyhnuli používání algoritmu 3DES.

  • Při migraci databáze pomocí Cell-Levelho šifrování prostřednictvím exportu/importu (soubory BacPac) Buďte opatrní.

mějte na paměti, že Always Encrypted je primárně navržená tak, aby chránila citlivá data při použití od uživatelů s vysokou úrovní oprávnění Azure SQL Database (specializující) – viz chránit citlivá data při použití z vysoce privilegovaných nebo neautorizovaných uživatelů. Při použití Always Encrypted k ochraně dat před uživateli aplikace Pamatujte na následující problémy:

  • Ve výchozím nastavení všechny ovladače klienta Microsoftu podporující Always Encrypted udržují globální mezipaměť (jedna na každou aplikaci) pro šifrovací klíče sloupce. Když ovladač klienta získá šifrovací klíč sloupce se prostým textem, kontaktujte úložiště klíčů obsahující hlavní klíč sloupce. šifrovací klíč sloupce ve formátu prostého textu se uloží do mezipaměti. Díky tomu jsou izolována data uživatelů aplikace s více uživateli náročné. Pokud se vaše aplikace při interakci s úložištěm klíčů (například Azure Key Vault) zosobňuje koncovým uživatelům, poté, co dotaz uživatele naplní mezipaměť pomocí šifrovacího klíče sloupce, bude následující dotaz, který vyžaduje stejný klíč, spuštěný jiným uživatelem, použít klíč uložený v mezipaměti. Ovladač nebude volat úložiště klíčů a nebude kontrolovat, zda má druhý uživatel oprávnění pro přístup k šifrovacímu klíči sloupce. V důsledku toho uživatel uvidí šifrovaná data i v případě, že uživatel nemá přístup k klíčům. Pro zajištění izolace uživatelů v rámci aplikace pro více uživatelů můžete zakázat ukládání šifrovacích klíčů sloupce do mezipaměti. Zakázání ukládání do mezipaměti způsobí zvýšení výkonu, protože ovladač bude potřebovat pro každou operaci šifrování nebo dešifrování dat kontaktovat úložiště klíčů.

Ochrana dat před neoprávněným zobrazením uživateli aplikace při zachování formátu dat

Další způsob, jak zabránit neautorizovaným uživatelům v zobrazení dat, je zakrýt nebo maskovat data při zachování datových typů a formátů, abyste zajistili, že uživatelské aplikace budou moci pokračovat v manipulaci a zobrazovat data.

Jak implementovat:

Poznámka

Always Encrypted nepracuje s dynamickým maskování dat. Nelze zašifrovat a maskovat stejný sloupec, což znamená, že je třeba nastavit prioritu ochrany dat při použití vs. maskování dat pro uživatele aplikace pomocí 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 vysokou úrovní oprávnění. Zásady maskování se nevztahují na uživatele s přístupem správce, jako je db_owner.

  • Nepovolte uživatelům aplikace spouštění dotazů ad hoc (protože můžou pracovat s maskou dynamických dat).

  • použijte správné zásady řízení přístupu (prostřednictvím SQL oprávnění, rolí, RLS) k omezení uživatelských oprávnění k provádění aktualizací v maskovaných sloupcích. Vytvořením masky u sloupce se nebrání aktualizace tohoto sloupce. Uživatelé, kteří přijímají maskovaná data při dotazování maskovaného sloupce, mohou data aktualizovat, pokud mají oprávnění k zápisu.

  • Dynamické maskování dat nezachovává 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í s maskovánými daty).

Zabezpečení sítě

Zabezpečení sítě odkazuje na řízení přístupu a osvědčené postupy pro zabezpečení vašich dat při přenosu do Azure SQL Database.

konfigurace klienta pro zabezpečené připojení k SQL Database/SQL spravované instanci

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

Jak implementovat:

Osvědčené postupy:

  • vyvynuťte minimální verzi tls na úrovni serveru SQL Database nebo SQL spravované Instance pomocí nastavení minimální verze protokolu tls. Doporučujeme nastavit minimální verzi TLS na 1,2, po otestování a ověření, že je vaše aplikace podporuje. TLS 1,2 obsahuje opravy chyb zabezpečení nalezené v předchozích verzích.

  • konfigurace všech aplikací a nástrojů pro připojení k SQL Database se zapnutým šifrováním

    • Encrypt = on, TrustServerCertificate = off (nebo ekvivalent u ovladačů od jiných výrobců než od Microsoftu).

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

Minimalizace možného útoku

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

Zmíněno v: OSA Practice č. 5

Jak implementovat:

V SQL Database:

  • Možnost Povolit přístup ke službám Azure nastavte na vypnuto na úrovni serveru.
  • Použijte koncové body služeb virtuální sítě a pravidla brány firewall virtuální sítě.
  • Použijte Private Link.

V SQL managed instance:

Osvědčené postupy:

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

    • Spravovaná instance může být izolovaná 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, mohly 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 pomocí skupin zabezpečení sítě (NSG) omezit přístup přes port 1433 jenom na prostředky, které vyžadují přístup ke spravované instanci.
    • Pro SQL Database použijte funkci Private Link, která poskytuje vyhrazenou privátní IP adresu pro server uvnitř vaší virtuální sítě. Můžete také použít koncové body služby pro virtuální síť s pravidly brány firewall virtuální sítě a omezit tak přístup k vašim serverům.
    • Mobilní uživatelé by měli používat připojení VPN point-to-site pro připojení přes cestu k datům.
    • Uživatelé připojení ke své místní síti by měli site-to-site VPN připojení nebo ExpressRoute pro připojení přes cestu k datům.

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

Poznámka

Veřejný SQL spravované instance není ve výchozím nastavení povolený a musí být explicitně povolený. Pokud zásady společnosti nepovolují používání veřejných koncových bodů, Azure Policy, abyste zabránili prvnímu povolení veřejných koncových bodů.

  • Nastavení Sítě Azure komponent:
    • Při zabezpečení sítě dodržujte osvědčené postupy Azure.
    • Naplánujte Virtual Network konfigurace podle osvědčených postupů uvedených v Virtual Network nejčastějších dotazech a plánování Azure.
    • Segmentace virtuální sítě do několika podsítí a přiřazení prostředků pro podobnou roli stejné podsíti (například front-end a back-endové prostředky).
    • Skupiny zabezpečení sítě (NSG) slouží k řízení provozu mezi podsítěmi uvnitř hranice virtuální sítě Azure.
    • Povolte azure Network Watcher pro vaše předplatné a monitorujte příchozí a odchozí síťový provoz.

Konfigurace Power BI zabezpečených připojení ke spravované instanci SQL Database nebo SQL instance

Osvědčené postupy:

  • Pokud Power BI Desktop, používejte privátní cestu k datům.

  • Ujistěte se Power BI Desktop že se připojuje pomocí protokolu TLS 1.2, nastavením klíče registru na klientském počítači podle nastavení registru TLS (Transport Layer Security).

  • Omezení přístupu k datům pro konkrétní uživatele prostřednictvím zabezpečení na úrovni řádků (RLS) pomocí Power BI.

  • Pro Power BI Service použijte místníbránu dat s ohledem na omezení a důležité informace.

Konfigurace App Service zabezpečených připojení ke spravované instanci SQL Database/SQL

Osvědčené postupy:

  • Pro jednoduchou webovou aplikaci vyžaduje připojení přes veřejný koncový bod nastavení Povolit službám Azure nastavit na HODNOTU ON (Povolit služby Azure) hodnotu ON (On).

  • Integrujte svou aplikaci se službou Azure Virtual Network pro připojení privátní cesty k datům ke spravované instanci. Volitelně můžete také nasadit webovou aplikaci s App Service Environments (ASE).

  • Pro webovou aplikaci s ASE nebo integrovanou webovou aplikací virtuální sítě, která se připojuje k databázi v SQL Database, můžete použít koncové body služeb virtuální sítě a pravidla brány firewall virtuální sítě k omezení přístupu z konkrétní virtuální sítě a podsítě. Pak nastavte Povolit službám Azure hodnotu VYPNUTO. Ase můžete také připojit ke spravované instanci ve spravované instanci SQL prostřednictvím cesty k privátním datům.

  • Ujistěte se, že je vaše webová aplikace nakonfigurovaná podle článku Osvědčené postupy pro zabezpečení webových a mobilních aplikací PaaS (platformajako služba) pomocí Azure App Service .

  • Nainstalujte Web Application Firewall (WAF), abyste webovou aplikaci ochránili před běžným zneužitím a ohrožením zabezpečení.

Konfigurace hostování virtuálních počítačů Azure pro zabezpečená připojení SQL Database nebo SQL spravované instanci

Osvědčené postupy:

  • Pokud chcete řídit, ke kterým oblastem je možné získat přístup z virtuálního počítače, použijte kombinaci pravidel Povolit a Odepřít u NSG virtuálních počítačů Azure.

  • Ujistěte se, že je váš virtuální počítač nakonfigurovaný podle článku Osvědčené postupy 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.

  • Podle pokynů v článku o vynuceném tunelování vyhodnoťte, jestli potřebujete výchozí trasu0.0.0.0/Internet.

    • Pokud ano – například front-endová podsíť – podržte výchozí trasu.
    • Pokud ne – například střední vrstva nebo back-endová podsíť – povolte vynucené tunelování, aby se žádný provoz přes internet nedosáhne do místního prostředí (nebo mezi místními).

  • Pokud používáte partnerský vztah nebo se připojujete k místnímu prostředí, implementujte volitelné výchozí trasy.

  • Pokud potřebujete odesílat 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.

  • Pro zabezpečený přístup ke službám PaaS, jako je Azure Storage přes páteřní síť Azure, použijte koncové body služby pro virtuální síť.

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

Útoky DDoS (Distributed Denial of Service) jsou pokusy uživatele se zlými úmysly odeslat do služby Azure SQL Database záplavu síťového provozu s cílem zahltit infrastrukturu Azure a způsobit, že odmítne platná přihlášení a úlohy.

Zmíněno v: OSA Practice č. 9

Jak implementovat:

Ochrana před DDoS se automaticky povolí jako součást platformy Azure. Zahrnuje monitorování provozu v reálném čase a omezení rizik útoků na úrovni sítě na veřejné koncové body.

Osvědčené postupy:

  • Postupujte podle postupů popsaných v části Minimalizace útočných ploch a minimalizujte hrozby útoků DDoS.

  • Výstraha Advanced Threat Protection hrubou silou SQL přihlašovací údaje pomáhá detekovat útoky hrubou silou. V některých případech může upozornění dokonce rozlišit úlohy penetračního testování.

  • Virtuální počítač Azure hostující aplikace, které se připojují k SQL Database:

    • Postupujte podle doporučení k omezení přístupu prostřednictvím internetových koncových bodů v Microsoft Defenderu pro cloud.
    • Pomocí škálovací sady virtuálních počítačů můžete spouštět více instancí vaší aplikace na virtuálních počítači Azure.
    • Zakažte RDP a SSH z internetu, abyste zabránili útoku hrubou silou.

Monitorování, protokolování a auditování

Tato část obsahuje informace o možnostech, které vám pomůžou detekovat neobvyklé aktivity, které můžou 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 hrozbami umožňuje detekovat potenciální hrozby a reagovat na ně tak, že poskytuje výstrahy zabezpečení pro neobvyklé aktivity.

Jak implementovat:

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

Osvědčené postupy:

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

  • Pokud chcete provést úplné prověřování, doporučuje se povolit SQL Database auditování. Pomocí auditování můžete sledovat databázové události a zapisovat je do protokolu auditu v účtu služby Azure Storage nebo pracovním prostoru Služby Azure Log Analytics.

Auditovat kritické události 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é by mohly značit obchodní obavy nebo podezření na narušení zabezpečení. Umožňuje také a usnadňuje dodržování standardů dodržování předpisů.

Jak implementovat:

  • Povolte SQL Database auditování spravované instance, abyste sledovali databázové události a zapisili je do protokolu auditu ve vašem účtu Azure Storage, pracovním prostoru služby Log Analytics (Preview) nebo Event Hubs (Preview).

  • Protokoly auditu je možné zapisovat do účtu služby Azure Storage, do pracovního prostoru služby Log Analytics, aby je bylo možné Azure Monitor protokoly událostí, nebo do centra událostí k využití pomocí centra událostí. Můžete nakonfigurovat libovolnou kombinaci těchto možností a do každé z nich se zapisou protokoly auditu.

Osvědčené postupy:

  • Když na SQL Database nebo auditování spravované instance nakonfigurujete auditování událostí, auditují se 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 vysoké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 vám pomůže řídit počet auditovaných akcí a minimalizovat riziko ztráty událostí. Vlastní konfigurace auditu umožňují zákazníkům zachytávání jenom potřebných dat auditu.
  • Protokoly auditu je možné využívat přímo v Azure Portal neboz nakonfigurovaného umístění úložiště.

Poznámka

Za povolení auditování do Log Analytics se budou na základě rychlosti příjmu dat účtut náklady. Mějte na paměti náklady spojené s použitím této možnostinebo zvažte uložení protokolů auditu v účtu úložiště Azure.

Další zdroje informací:

Zabezpečení protokolů auditu

Omezte přístup k účtu úložiště, abyste podpořili oddělení povinností a oddělení DBA od auditorů.

Jak implementovat:

  • Při ukládání protokolů auditu do Azure Storage se ujistěte, že přístup k účtu Storage je omezený na minimální principy zabezpečení. Řídit, kdo má přístup k účtu úložiště.
  • Další informace najdete v tématu o povolení přístupu k Azure Storage.

Osvědčené postupy:

Správa zabezpečení

Tato část popisuje různé aspekty a osvědčené postupy pro správu 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 v 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 opravou potenciálních ohrožení zabezpečení databáze.

Jak implementovat:

Osvědčené postupy:

  • Na začátku spusťte v databázích nástroj VA a iterace napravte neúspěšné kontroly, které nejsou v souladu s osvědčenými postupy zabezpečení. Nastavte směrné plány pro přijatelné konfigurace, dokud kontrola nevyjde z čistého stavu nebo dokud neprojde všemi kontrolami.

  • Nakonfigurujte pravidelné opakované kontroly tak, aby se spouštěla jednou týdně, a nakonfigurujte relevantní osobu na příjem souhrnných e-mailů.

  • Po každé týdenní proskenování si prohlédněte souhrn VA. V případě nalezených ohrožení zabezpečení vyhodnoťte odchylku od předchozího výsledku kontroly a určete, jestli se má kontrola vyřešit. Zkontrolujte, jestli neexistuje legitimní důvod pro změnu konfigurace.

  • Vyřešte kontroly a tam, kde je to relevantní, aktualizujte směrné plány. Vytvořte položky lístku pro řešení akcí a sledujte je, dokud se nevyřeší.

Další zdroje informací:

Identifikace a označení citlivých dat

Zjišťování sloupců, které potenciálně obsahují citlivá data To, co se považuje za citlivá data, do značné míry závisí na zákazníkovi, nařízení o dodržování předpisů atd., a uživatelé, kteří za tato data mají na starosti, musí je vyhodnotit. Klasifikujte sloupce, aby bylo možné využít pokročilé scénáře auditování a ochrany na základě citlivosti.

Jak implementovat:

  • Pomocí SQL zjišťování a klasifikace dat můžete zjišťovat, klasifikovat, označovat popisky a chránit citlivá data v databázích.
    • Podívejte se na doporučení klasifikace vytvořená automatizovaným zjišťováním na řídicím panelu SQL zjišťování a klasifikace dat. Přijměte příslušné klasifikace, aby vaše citlivá data byla trvale označena 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 SQL a klasifikace dat.

Osvědčené postupy:

  • Pravidelně monitorujte řídicí panel klasifikace, který umožňuje přesné vyhodnocení stavu klasifikace databáze. Pro účely dodržování předpisů a auditování je možné exportovat nebo vytisknout sestavu o stavu klasifikace databáze.

  • Průběžně monitorujte stav doporučených citlivých dat v SQL posouzení ohrožení zabezpečení. Sledujte pravidlo zjišťování citlivých dat a identifikujte všechny odchylky v doporučených sloupcích pro klasifikaci.

  • Používejte klasifikaci způsobem, který je přizpůsobený konkrétním potřebám vaší organizace. Přizpůsobte si Information Protection zabezpečení (popisky citlivosti, typy informací, logika zjišťování) v zásadách zjišťování SQL Information Protection v Microsoft Defenderu pro cloud.

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

Monitorujte, kdo přistupuje k citlivým datům, a zachyťte dotazy na citlivá data v protokolech auditu.

Jak implementovat:

  • Použijte kombinaci SQL Auditu a Klasifikace dat.

Osvědčené postupy:

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

Použijte jednotný systém správy zabezpečení infrastruktury, který posiluje postoj k zabezpečení vašich datových center (včetně databází v SQL Database). Zobrazte si seznam doporučení týkajících se zabezpečení databází a stavu dodržování předpisů.

Jak implementovat:

Běžné bezpečnostní hrozby a potenciální omezení 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 lze dosáhnout pomocí jednoho nebo více pokynů k zabezpečení uvedených výše.

Bezpečnostní hrozba: Exfiltrace dat

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

Připojení k serveru přes veřejný koncový bod představuje riziko exfiltrace dat, protože vyžaduje, aby zákazníci otevřeli brány firewall pro veřejné IP adresy.

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

Scénář 2: Správce databáze Tento scénář často vyvolali zákazníci citliví na zabezpečení z regulovaných odvětví. V tomto scénáři může uživatel s vysokým oprávněním kopírovat data z Azure SQL Database do jiného předplatného, které neřízeného vlastníkem dat.

Potenciální omezení rizik:

Spravovaná Azure SQL Database a SQL v současné době nabízí následující techniky pro zmírnění hrozeb před exfiltrací dat:

  • Pokud chcete řídit, ke kterým oblastem je možné získat přístup z virtuálního počítače, použijte kombinaci pravidel Povolit a Odepřít pro NSG virtuálních počítače Azure.
  • Pokud používáte server v SQL Database, nastavte následující možnosti:
    • Povolte službám Azure možnost VYPNUTO.
    • Nastavením pravidla brány firewall virtuální sítě povolte provoz pouze z podsítě, která obsahuje váš virtuální počítač Azure.
    • Použití Private Link
  • V SQL spravované instanci řeší použití přístupu k privátní IP adrese ve výchozím nastavení první problém s exfiltrací dat podvodného virtuálního počítače. zapněte funkci delegování podsítě v podsíti, aby se automaticky nastavila nejvíce omezující zásada v podsíti spravované Instance SQL.
  • obavy z neautorizovaných DBA je lepší vystavit SQL spravované Instance, protože má větší plochu a požadavky na síť jsou viditelné pro zákazníky. Nejlepší zmírnění tohoto postupu je použití všech postupů v tomto Průvodci zabezpečením, aby se zabránilo neoprávněnému scénáři DBA v prvním místě (nejen pro data exfiltrace). Always Encrypted je jedna z metod ochrany citlivých dat tím, že ji šifrujete a udržujete klíč nepřístupný ke službě DBA.

Aspekty zabezpečení při provozní kontinuitě a dostupnosti

Většina standardů zabezpečení řeší dostupnost dat v souvislosti s provozní kontinuitou, dosaženo implementací redundance a převzetím služeb při selhání, aby se předešlo jednomu bodu selhání. V případě scénářů pro havárie se jedná o běžný postup uchovávání záloh dat a souborů protokolů.V následující části najdete základní informace o funkcích, které jsou integrované v Azure. Poskytuje taky další možnosti, které je možné nakonfigurovat tak, aby splňovaly konkrétní potřeby:

Další kroky