Zabezpečte své sdílené složky Azure

Tento článek poskytuje bezpečnostní pokyny pro Azure Files, včetně klasických sdílení souborů vytvořených pomocí Microsoft.Storage a sdílení souborů vytvořených pomocí Microsoft.FileShares. Zahrnuje zdroje, v nichž jsou uchovávány vaše podíly, přístup klientů, ochranu dat a provozní kontrolu.

Bezpečnostní mechanismy závisí na poskytovateli zdrojů a protokolu. Pro srovnání podporovaných funkcí viz koncepty správy Azure Files.

Izolace prostředků

  • Považujte účet úložiště za hranici důvěry: Vytvoření samostatných klasických sdílených složek ve stejném účtu úložiště neizoluje jejich síťová pravidla, zdroj identity SMB ani konfiguraci šifrovacího klíče. Změny těchto nastavení na úrovni účtu ovlivňují všechny sdílené položky v účtu. Klasické sdílené položky seskupte pouze tehdy, když mohou sdílet tyto ovládací prvky. Microsoft.FileShares se této sdílené hranici na úrovni účtu vyhýbá tím, že poskytuje nezávislou síťovou a bezpečnostní konfiguraci pro každou sdílenou složku.

  • Chránit klientské systémy: Klient s přístupem k zápisu může upravovat nebo mazat data souboru. Udržujte klientské operační systémy aktuální a omezte místní administrátorský přístup. Používejte ochranu koncových zařízení odpovídající klientskému prostředí. Izolace sítě a šifrování nebrání autorizovanému klientovi provádět destruktivní změny.

Zabezpečení sítě

Příchozí přístup a odchozí filtrování

  • Omezte příchozí přístup pro klienty, kteří jej potřebují: Oba poskytovatelé zdrojů podporují privátní koncové body a koncové body služby s omezeními virtuální sítě. Přístup ke sdíleným složkám Azure NFS vyžaduje jednu z těchto cest. Klasické SMB a FileREST klienty mohou také používat veřejné endpointy s pravidly IP adres. U klasických sdílených souborů standardní koncový bod služby umožňuje, aby jedno pravidlo IP adresy zahrnovalo více podsítí pro SMB, NFS a FileREST. Pokyny ke konfiguraci najdete v článku Konfigurace síťových koncových bodů pro sdílené složky Azure.

  • Vypněte veřejný přístup, když není potřeba: Veřejné koncové body lze bezpečně používat s kontrolou přístupu do sítě, autentizací a šifrováním odpovídajícím protokolu. Udržujte veřejný přístup zapnutý, když to vaše pracovní zátěže vyžadují a váš bezpečnostní model to umožňuje, včetně připojení přes servisní endpointy. Vytvoření soukromého endpointu automaticky nezakáže veřejný přístup. U klasických sdílení si prohlédněte případné výjimky důvěryhodných služeb nebo instancí prostředků, které mohou zůstat platné i po deaktivaci veřejného přístupu. Pro více informací viz Omezit přístup k veřejnému koncovému bodu.

  • Povolit přístup k důvěryhodným službám pouze tehdy, když je to potřeba: Dostupné pouze pro klasické sdílení souborů, nastavení důvěryhodných služeb umožňuje podporovaným službám Azure obejít síťová pravidla úložného účtu. Povolte ho pouze tehdy, když integrace vyžaduje tento přístup. Tyto služby musí být stále autorizovány k přístupu k vašim souborovým datům.

  • Volitelné filtrování provozu koncových bodů služby: Když klienti používají servisní koncové body k přístupu ke klasickým sdíleným souborům, můžete volitelně aplikovat politiku servisních koncových bodů na jejich podsíť. Politika omezuje, ke kterým úložným účtům mohou tito klienti přistupovat prostřednictvím koncových bodů služby, kde provoz obchází Azure Firewall a síťová virtuální zařízení. Platí pouze pro provoz servisních koncových bodů a nefiltruje provoz privátního koncového bodu ani jiné odchozí cesty. Pravidla sítě a požadavky na autorizaci v cílové destinaci stále platí. Microsoft.FileShares tyto politiky momentálně nepodporuje. Klienti v podsíti se zásadou musí pro přístup ke sdíleným složkám Microsoft.FileShares používat privátní koncový bod. Další informace najdete v článku Zásady koncových bodů služby.

  • Před použitím perimetru zabezpečení sítě zkontrolujte podporu protokolu: Perimetry zabezpečení sítě jsou dostupné pouze pro klasické sdílení souborů. U klasických sdílení se podpora perimetru liší podle protokolu a autentizačního způsobu. V režimu Enforced se klienti SMB a NFS ve virtuálních sítích Azure musí připojit přes privátní koncový bod nebo přes standardní servisní endpoint s pravidlem příchozího přístupu pro jeho IP adresu. Perimetr znemožňuje SMB a NFS provoz přes koncové body služeb, které nemají přiřazenou IP adresu. SMB a NFS nepodporují přístup mezi prostředky mezi členy perimetru ani pravidla přístupu založená na předplatném. Provoz privátního koncového bodu nepodléhá vynucování na úrovni perimetru. Před aplikací perimetru zkontrolujte omezení pro Azure Backup a Synchronizace souborů Azure. Pro více informací viz Perimetr bezpečnosti sítě.

Zpevnění protokolů SMB

Tato doporučení platí pro klasické SMB sdílení souborů.

  • Vyžadujte šifrování SMB kanálu: Používejte šifrovaná SMB 3.x připojení. SMB 2.1 nepodporuje šifrování kanálů. Požadavek na HTTPS pro FileREST nenahrazuje konfiguraci šifrování SMB. Pro více informací viz nastavení šifrování a zabezpečení SMB.

  • Omezte verze protokolů a algoritmy na ty, které vaši klienti potřebují: Používejte nejbezpečnější SMB profil kompatibilní s vašimi pracovními zátěžemi. Před požadavkem SMB 3.1.1 nebo AES-256-GCM ověřte podporu klientů, protože nekompatibilní klienti se nemohou připojit. Šifrování kanálu SMB a šifrování lístků Kerberos jsou samostatná nastavení. Pro více informací viz nastavení bezpečnosti SMB.

  • Omezte metody ověřování SMB: Používejte Kerberos pro přístup založený na identitě. Pokud žádní klienti nepotřebují autentizaci klíče k úložišti přes SMB, po testování odstraňte NTLMv2 z povolených metod autentizace SMB. Tato kontrola platí pro SMB; nezakazuje přístup k FileREST založený na klíčích.

  • Udržujte přihlašovací údaje AD DS, kde je to relevantní: Pro autentizaci AD DS spravujte heslo adresářového principálu, který představuje úložný účet, podle vaší adresářové politiky. Dodržujte zdokumentovaný postup rotace, abyste udržovali synchronizované heslo adresáře a klíč Kerberos účtu úložiště. Pro více informací viz Aktualizujte heslo identity účtu úložiště v AD DS.

NFS 4.1 sdílené soubory

Tato doporučení platí pro sdílené složky NFS u kteréhokoli poskytovatele prostředků. NFS používá autentizaci založenou na síti a oprávnění POSIX, nikoli autentizaci založenou na identitě SMB.

  • Omezte přístup k důvěryhodným sítím: Povolte pouze podsítě a privátní připojení potřebná pro pracovní zátěž. NFS spoléhá na identity prezentované klientem, proto určete, které systémy a administrátoři mohou tato připojení využívat.

  • Spravujte oprávnění POSIX a identity klientů: Používejte konzistentní uživatelská ID a skupinová ID napříč klienty. Omezte oprávnění k souborům a adresářům na uživatele a skupiny, které přístup potřebují. Oprávnění Azure RBAC pro správu prostředku Azure neposkytují přístup k souborům přes NFS. Pro více informací viz ověřování NFS a přístup k síti.

  • Konfigurujte root squash tam, kde je to kompatibilní s danou zátěží: Root squash mapuje požadavky z UID/GID 0 na anonymní identitu. Neomezuje jiné identity ani nedělá sdílení pouze pro čtení. Pro nastavení a konfigurační kroky pro oba poskytovatele prostředků viz Root squashing pro sdílené složky Azure NFS.

  • Vyžaduje šifrování během přenosu: Oba poskytovatelé zdrojů podporují TLS prostřednictvím AZNFS mount helper. Microsoft.FileShares ve výchozím nastavení vyžaduje šifrování při přenosu. Klasické sdílené složky mají nastavení šifrování NFS na úrovni účtu úložiště. Pro výchozí nastavení a konfigurační odkazy viz NFS šifrování.

Správa identit a přístupu

Správa prostředků Azure

  • Používejte princip nejnižších oprávnění pro přístup ke správě: Udělte oprávnění Azure RBAC v nejmenším rozsahu potřebném k vytvoření, konfiguraci nebo odstranění prostředků. U klasických sdílení mohou oprávnění na úrovni účtu ovlivnit každé sdílení v účtu. Můžete spravovat prostředky Microsoft.FileShares nezávisle. Manažerské role a oprávnění k přístupu k datům mají různé účely. Další informace najdete v tématu Řídicí rovina a datová rovina Azure.

  • Omezte trvalý správcovský přístup: Používejte Microsoft Entra Privileged Identity Management tam, kde je to vhodné pro privilegované Azure role. Vyžadujte schválení a vícefaktorovou autentizaci pro administrativní aktivaci podle politiky vaší organizace. Další informace najdete v tématu Privileged Identity Management.

Autentizace založená na identitě pro SMB sdílené soubory

Přístup založený na identitě SMB je dostupný pro klasické sdílení souborů. Klíč úložného účtu poskytuje široký přístup k datům napříč sdílenými složkami účtu a neidentifikuje konkrétního uživatele.

  • Používejte zdroj identity podporovaný vašimi klienty: Azure Files podporuje AD DS, Microsoft Entra Doménové služby a Microsoft Entra Kerberos. Jejich požadavky na klienta a identitu se liší. Pro podporované scénáře a návody k nastavení viz Ověřování na základě identity pro Azure Files.

  • Používejte spravované identity pro podporované aplikační zátěže: Spravované identity mohou poskytovat přístup SMB bez distribuce klíčů úložného účtu. Ověřte požadavky na výpočetní prostředky, klienta a ověřování pro vaše nasazení. Další informace najdete v tématu Přístup ke sdíleným složkám SMB pomocí spravovaných identit.

  • Chraňte klíče účtu, pokud jsou vyžadovány: Omezte povolení k získávání nebo opětovnému generování klíčů. Požadované klíče ukládejte v Azure Key Vault a po kompromitaci je střídejte nebo podle vaší politiky přihlašovacích údajů. Naplánujte rotaci s ohledem na klienty a integrace, které stále používají klíče. Další informace najdete v tématu Správa přístupových klíčů účtu úložiště.

Oprávnění na úrovni sdílení a NTFS

Tato oprávnění platí pro klasické sdílené složky SMB.

  • Přiřaďte role na úrovni sdílení v požadovaném rozsahu: Udělujte oprávnění ke čtení, zápisu nebo správě pouze identitám, které je potřebují. Přiřazení rolí na úrovni sdílení se vyhýbají udělování přístupu k nesouvisejícím sdílením ve stejném úložném účtu. Další informace najdete v tématu Přiřazení oprávnění na úrovni sdílené složky.

  • Aplikujte oprávnění pro adresáře a soubory: Použijte Windows ACL, včetně kořenového adresáře sdílené složky, kde je to potřeba, k ovládání přístupu v rámci sdílené složky. Použijte dědičnost, abyste udrželi oprávnění zvládnutelná. Jsou vynucovány jak oprávnění na úrovni sdílení, tak Windows ACL. Další informace najdete v tématu Konfigurace oprávnění na úrovni adresáře a na úrovni souborů.

  • Omezit správu oprávnění: Omezit přidělení zvýšených rolí a práva na úpravu ACL na identity odpovědné za správu oprávnění. Při změně požadavků na přístup zkontrolujte jak přiřazení rolí, tak zděděné ACL.

Přístup FileREST a SAS

Přístup k datům FileREST je dostupný pro klasická sdílení. Microsoft. FileShares momentálně nepodporuje přístup k datům FileREST.

  • Použijte OAuth pro podporovaný přístup k administrátorským datům: Identity Microsoft Entra, včetně spravovaných identit, mohou přistupovat ke klasickým sdíleným složkám přes FileREST. Privilegované role používané touto metodou přístupu mohou obejít oprávnění k souborům a adresářům, proto je udělujte pouze tam, kde je tento přístup vyžadován. Pro více informací viz Azure Files OAuth over REST.

  • Omezte oprávnění SAS a dobu jejich platnosti: Když podporovaný nástroj vyžaduje podpis sdíleného přístupu (SAS), omezte jeho rozsah, oprávnění a dobu platnosti a vyžadujte HTTPS. Chraňte SAS jako přihlašovací údaj. Tokeny SAS se nepoužívají k připojení sdílených složek přes SMB nebo NFS. Další informace najdete v tématu sdílené přístupové podpisy (SAS).

  • Vyžadujte HTTPS pro FileREST: HTTPS chrání REST požadavky během přenosu. Šifrování SMB kanálů a NFS TLS tunelování jsou oddělené od požadavku na HTTPS. Konfigurační kroky najdete v článku Šifrování FileREST při přenosu.

Ochrana dat

  • Pochopte šifrování v klidu: Oba poskytovatelé zdrojů šifrují data souborů v klidu pomocí klíčů spravovaných Microsoft ve výchozím nastavení. Šifrování v klidu chrání uložená data; nebrání oprávněným klientům ve čtení nebo změně souborů.

  • Používejte klíče spravované zákazníkem, když je to potřeba: Klasické sdílené položky podporují klíče spravované zákazníkem v Azure Key Vault nebo Managed HSM. Microsoft. FileShares momentálně nepodporuje klíče spravované zákazníkem. Chraňte klíčové úložiště, plánujte rotaci klíčů a pochopte, že ztráta přístupu ke klíči může učinit data nedostupnými. Pro více informací viz Customer-managed keys for Azure Files.

  • Vyhodnoťte šifrování infrastruktury pro relevantní klasická nasazení: Klasické úložné účty mohou mít další šifrovací vrstvu, pokud to vyžaduje vaše compliance politika. Tato možnost se vybírá při vytváření účtu a nelze ji později změnit. Pro více informací viz šifrování infrastruktury.

  • Používejte zámky zdrojů k ochraně správcovských operací: Zámek CanNotDelete na příslušném Azure zdroji nebo mateřském rozsahu může zabránit smazání prostřednictvím Azure Resource Manager. Zámky nebrání klientům v úpravě nebo mazání souborových dat. U klasických sdílených složek také nebrání mazání prostřednictvím rozhraní FileREST API pro datovou vrstvu. Pro chování zámků a provozní efekty viz Uzamčení prostředků Azure.

Zálohování a obnovování

  • Pořizujte snímky sdílených složek podle potřeb obnovy: Oba poskytovatelé prostředků podporují snímky sdílených složek pro obnovu starších verzí souborů. Stanovte si harmonogram a zásady uchovávání, které odpovídají vašim cílům zotavení. Snímky sdílené složky zůstávají spojeny se zdrojovou sdílenou složkou, takže neposkytují nezávislou zálohu, pokud je tato sdílená složka trvale odstraněna. Pro více informací viz Sdílení snapshotů pro Azure Files.

  • Povolte soft delete u klasických sdílení: Soft delete zachová odstraněná sdílení po nastavenou dobu. Neobnovuje jednotlivé soubory ani jednotlivě smazané snímky. Microsoft. FileShares momentálně nepodporuje soft delete. Další informace najdete v tématu Zabránění náhodnému odstranění sdílených složek Azure.

  • Vyberte si zálohovací řešení podporované protokolem: Azure Backup podporuje klasické sdílené složky SMB, s možnostmi snapshotů a záloh v trezoru. V současnosti nepodporuje sdílené složky NFS u žádného z obou poskytovatelů prostředků. Pro NFS zvolte zálohovací řešení, které protokol podporuje a splňuje vaše požadavky na retenci a izolaci. Pro pokrytí Azure Backup viz podpora zálohování sdílených složek Azure.

  • Oddělená správa záloh a testování obnovení: Omezte, kdo může smazat body obnovení nebo změnit uchovávání. Testujte obnovy souborů, oprávnění a úplné úlohy. Ověřte, že obnova je stále možná, pokud jsou kompromitovány produkční přihlašovací údaje nebo zdrojové sdílení.

  • Plánujte řešení selhání infrastruktury odděleně od obnovy dat: Redundance zvyšuje odolnost vůči selháním infrastruktury, ale také replikuje změny dat. Nenahrazuje zálohování při nechtěných změnách nebo smazání. Dostupné možnosti redundance se liší podle úrovně média a poskytovatele zdroje. Další informace najdete v tématu Redundance služby Azure Files.

Protokolování a monitorování

  • Auditování změn správy u obou poskytovatelů prostředků: Použijte Azure Activity Log ke sledování odstranění prostředků, změn konfigurace a přiřazení rolí. Prohlédněte si změny ve veřejném přístupu, síťových pravidlech, požadavcích na šifrování a kontrolách obnovy. Další informace najdete v protokolu aktivit Azure.

  • Shromažďujte dostupné protokoly přístupu k datům: Pro klasický přístup SMB a FileREST použijte protokoly prostředků služby Soubory k přezkoumání volajících, autorizačních metod, neúspěšných požadavků a aktivit odstraňování. Shromáždujte logy požadované vaší politikou uchovávání v Log Analytics nebo jiném podporovaném místě. Nepředpokládejte stejné pokrytí protokolování požadavků pro NFS nebo Microsoft.FileShares. Pro podporované operace a pole viz Azure Files monitoring data reference.

  • Korelace upozornění s klientskými a identitními logy: Vyšetřujte neočekávané použití klíčů, neúspěšnou autentizaci, odstranění sdílení a změny v bezpečnostní konfiguraci. Používejte klientské a adresářové záznamy, pokud dojde k selhání autentizace dříve, než požadavek dorazí do Azure Files. Posílejte upozornění týmu odpovědnému za úlohu.

  • Vyhodnoťte Defender for Storage pro klasická nasazení: Defender for Storage poskytuje detekci hrozeb pro podporované úložné účty. Ověřte pokrytí funkcí a protokolů pro vaše nasazení; ochrana účtu neznamená, že každá operace se souborem je prohledána na malware. Pro více informací viz Microsoft Defender for Storage.

Dodržování předpisů a zásady správného řízení

  • Aplikujte zásady, které odpovídají poskytovateli prostředků: Použijte Azure Policy k auditu nebo vynucení požadavků vaší organizace tam, kde jsou typy prostředků a vlastnosti podporovány. Zkontrolujte rozsah a dopady každé definice. Politika zaměřená na účty úložiště Microsoft.Storage automaticky nevyhodnocuje prostředky Microsoft.FileShares. Další informace najdete v tématu definice Azure Policy.

  • Vlastnictví záznamů a požadavky na data: Použijte štítky zdrojů k identifikaci odpovědného týmu, prostředí a klasifikace dat. U klasických akcií se kontroly na úrovni účtu týkají všech akcií na účtu. Zaznamenávejte výjimky a zkontrolujte je, když se změní vlastnictví pracovní zátěže.

  • Ověřte soulad nasazení: Ověřte, že vybraná služba, oblast, protokol a funkce ochrany splňují vaše požadavky. Použijte Microsoft cloud security benchmark k organizaci revizí opatření. Pro informace o certifikaci viz nabídky souladu s Azure Storage.

Synchronizace souborů Azure

Synchronizace souborů Azure podporuje klasické SMB sdílení. Nepodporuje NFS ani Microsoft.FileShares. Zabezpečte jak cloudové sdílení, tak Windows Server endpointy.

  • Používejte spravované identity pro podporovaná nasazení File Sync: Postupujte podle konfigurace spravované identity pro Storage Sync Service a registrované servery, abyste odstranili závislost na sdílených klíčích. Pro více informací viz Použití spravovaných identit s Synchronizace souborů Azure.

  • Omezte administrátorský přístup k synchronizačním prostředkům a serverům: Používejte požadované role Storage Sync v odpovídajícím rozsahu. Chraňte místní oprávnění k souborům a správu serveru, protože změny provedené přes serverový endpoint lze synchronizovat s cloudovým sdílením. Pro více informací viz Plan an Synchronizace souborů Azure deployment.

Další kroky