Azure Storage inaktív adatok titkosítása

Azure Storage szolgáltatásoldali titkosítással (SSE) automatikusan titkosítja az adatokat, amikor azokat a felhőben megőrzi. Azure Storage titkosítás védi az adatokat, és segít megfelelni a szervezeti biztonsági és megfelelőségi követelményeknek.

Microsoft szolgáltatásoldali titkosítás használatát javasolja az adatok védelméhez a legtöbb forgatókönyv esetében. Az Azure Storage Blob Storage és Queue Storage ügyfélkönyvtárai azonban ügyféloldali titkosítást is biztosítanak az adatok ügyféloldali titkosítására. További információkért tekintse meg a blobok és üzenetsorok ügyféloldali titkosítását.

Tudnivalók Azure Storage szolgáltatásoldali titkosításról

Az Azure Storage adatai transzparensen, 256 bites AES titkosítással vannak titkosítva és visszafejtve. Ez a módszer az egyik legerősebb rendelkezésre álló blokkos rejtjel, és megfelel a FIPS 140-2 szabványnak. Az Azure Storage titkosítása hasonló a Windows rendszerű BitLocker-titkosításhoz.

Azure Storage kiszolgálóoldali titkosítás 256 bites AES Galois/Counter mode (AES-GCM) használatával titkosítja a feltöltött objektumokat. Az Azure Storage titkosítása minden tárolófiókhoz engedélyezett. Az Azure Storage titkosítása nem lehet kikapcsolni. Mivel az adatok alapértelmezés szerint védettek, nem kell módosítania a kódot vagy az alkalmazásokat, hogy kihasználhassa Azure Storage titkosítás előnyeit.

A tárolófiókban lévő adatok titkosítva vannak, függetlenül a teljesítményszinttől (standard vagy premium), vagy hozzáférési szinttől (hot vagy cool). Minden új és meglévő blokkblob, hozzáfűző blob és lapblob titkosítva van, beleértve az archív rétegbeli blobokat is. Minden Azure Storage redundancia-beállítás támogatja a titkosítást, és a georeplikálás engedélyezésekor az elsődleges és a másodlagos régió összes adata titkosítva van. Minden Azure Storage erőforrás titkosítva van, beleértve a blobokat, lemezeket, fájlokat, üzenetsorokat és táblákat. Az objektum metaadatai is titkosítva lesznek.

Az Azure Storage titkosítása nem jár további költséggel.

Az Azure Storage titkosítás alapjául szolgáló titkosítási modulokkal kapcsolatos további információkért lásd: Cryptography API: Next Generation.

A Azure felügyelt lemezek titkosításával és kulcskezelésével kapcsolatos információkért lásd: Kiszolgálóoldali titkosítás Azure felügyelt lemezek.

Tudnivalók a titkosítási kulcsok kezeléséről

Az új tárfiók adatai alapértelmezés szerint Microsoft által felügyelt kulcsokkal lesznek titkosítva. Továbbra is támaszkodhat Microsoft által felügyelt kulcsokra az adatok titkosításához, vagy kezelheti a titkosítást saját kulcsaival. Ha úgy dönt, hogy saját kulcsokkal kezeli a titkosítást, két lehetősége van. Használhatja a kulcskezelés egyik típusát, vagy mindkettőt:

  • Megadhat egy ügyfél által felügyelt kulcsot a Blob Storage és az Azure Files adatainak titkosításához és visszafejtéséhez.1,2 Az ügyfél által felügyelt kulcsokat az Azure Key Vaultban vagy az Azure Key Vault által felügyelt hardveres biztonsági modulban (HSM) kell tárolni. További információ az ügyfél által felügyelt kulcsokról: Az ügyfél által felügyelt kulcsok használata Azure Storage titkosításhoz.
  • A Blob Storage műveletekhez megadhat egy customer által biztosított kulcsot. A Blob Storage olvasási vagy írási kérést küldő ügyfél tartalmazhat egy titkosítási kulcsot a blobadatok titkosításának és visszafejtési módjának részletes szabályozására vonatkozó kéréshez. További információ az ügyfél által megadott kulcsokról: Titkosítási kulcs kérése Blob Storage.

A tárfiókok alapértelmezés szerint egy olyan kulccsal lesznek titkosítva, amely a teljes tárfiókra kiterjed. A titkosítási hatókörök lehetővé teszik a titkosítás kezelését egy tárolóra vagy egy adott blobra hatókörrel rendelkező kulccsal. Titkosítási hatókörökkel biztonságos határokat hozhat létre az ugyanazon tárfiókban található, de különböző ügyfelekhez tartozó adatok között. A titkosítási hatókörök Microsoft felügyelt vagy ügyfél által felügyelt kulcsokat használhatnak. A titkosítási hatókörökről további információt a Blob Storage titkosítási hatókörei című témakörben talál.

Az alábbi táblázat a Azure Storage titkosítás kulcskezelési beállításait hasonlítja össze.

Kulcskezelési paraméter Microsoft által felügyelt kulcsok Felhasználó által kezelt kulcsok Ügyfél által megadott kulcsok
Titkosítási/visszafejtési műveletek Azure Azure Azure
támogatott Azure Storage szolgáltatások Összes Blob Storage, Azure Files 1,2 Blob Storage
Kulcstároló Microsoft kulcstároló Azure Key Vault vagy Key Vault HSM Az ügyfél saját kulcstárolója
Kulcsforgatási felelősség Microsoft Vevő Vevő
Kulcskezelés Microsoft Vevő Vevő
Kulcs hatóköre Fiók (alapértelmezett), konténer vagy blob Fiók (alapértelmezett), konténer vagy blob n/a

1 Az ügyfél által felügyelt kulcsok Queue Storage-beli használatát támogató fiók létrehozásáról további információt az üzenetsorok ügyfél által felügyelt kulcsait támogató fiók létrehozása című témakörben talál.
2 Az ügyfél által felügyelt kulcsok Table Storage-beli használatát támogató fiók létrehozásáról további információt a táblák ügyfél által felügyelt kulcsait támogató fiók létrehozása című témakörben talál.

Megjegyzés

Microsoft felügyelt kulcsok a megfelelőségi követelményeknek megfelelően vannak elforgatva. Ha konkrét kulcsrotációs követelményekkel rendelkezik, a Microsoft azt javasolja, hogy lépjen az ügyfél által kezelt kulcsokra, hogy önmaga felügyelhesse és naplózhassa a rotációt.

Adatok kétszeres titkosítása infrastruktúra-titkosítással

Azok az ügyfelek, akik magas szintű biztonságot igényelnek az adataik biztonságossá tételéhez, 256 bites AES-titkosítást is engedélyezhetik Azure Storage infrastruktúra szintjén. Ha az infrastruktúra-titkosítás engedélyezve van, a tárfiókban lévő adatok két különböző titkosítási algoritmussal és két különböző kulcssal kétszer – egyszer a szolgáltatás szintjén, egyszer pedig az infrastruktúra szintjén – titkosítva lesznek. A Azure Storage adatok dupla titkosítása védelmet nyújt olyan forgatókönyvekkel szemben, amikor az egyik titkosítási algoritmus vagy kulcs megsérülhet. Ebben a forgatókönyvben a további titkosítási réteg továbbra is védi az adatokat.

A szolgáltatásszintű titkosítás Microsoft felügyelt kulcsok vagy ügyfél által felügyelt kulcsok használatát támogatja Azure Key Vault. Az infrastruktúraszintű titkosítás Microsoft felügyelt kulcsokra támaszkodik, és mindig külön kulcsot használ.

További információ az infrastruktúra-titkosítást lehetővé tevő tárfiókok létrehozásáról: Tárfiók létrehozása az adatok dupla titkosításához engedélyezett infrastruktúra-titkosítással.

Ügyféloldali titkosítás blobokhoz és üzenetsorokhoz

A .NET, Java és Python Azure Blob Storage ügyfélkódtárai támogatják az ügyfélalkalmazásokban lévő adatok titkosítását a Azure Storage való feltöltés előtt, valamint az adatok visszafejtését az ügyfélre való letöltés közben. A Queue Storage-ügyfélkódtárak .NET és Python is támogatják az ügyféloldali titkosítást.

Megjegyzés

Fontolja meg az Azure Storage által biztosított szolgáltatásoldali titkosítási funkciók használatát az adatok védelme érdekében az ügyféloldali titkosítás helyett.

A Blob Storage és a Queue Storage ügyfélkódtárak AES használnak a felhasználói adatok titkosításához. Az ügyféloldali titkosításnak két verziója érhető el az ügyfélkódtárakban:

  • A 2. verzió Galois/Counter Mode (GCM) módot használ az AES-sel. A Blob Storage és a Queue Storage SDK-k támogatják az ügyféloldali titkosítást a v2-vel.
  • Az 1. verzió az AES-sel titkosítási blokkláncolási (CBC) módot használ. A Blob Storage, a Queue Storage és a Table Storage SDK-k támogatják az ügyféloldali titkosítást az 1. verzióval.

Figyelmeztetés

Az ügyféloldali titkosítás v1 használata már nem ajánlott az ügyfélkódtár CBC módbeli implementációjának biztonsági rése miatt. A biztonsági résről további információ a következő forrásban érhető el: Az Azure Storage frissíti az ügyféloldali titkosítást az SDK-ban a biztonsági rés kezelésére. Ha jelenleg 1-et használ, javasoljuk, hogy frissítse az alkalmazást az ügyféloldali titkosítás v2 használatára, és migrálja az adatokat.

A Azure Table Storage SDK csak az ügyféloldali titkosítást támogatja 1. Nem ajánlott ügyféloldali titkosítást használni a Table Storage használatával.

Az alábbi táblázat azt mutatja be, hogy mely ügyfélkódtárak támogatják az ügyféloldali titkosítás mely verzióit, és útmutatást nyújt az ügyféloldali titkosítás v2-re való migráláshoz.

Ügyfélkódtár Az ügyféloldali titkosítás támogatott verziója Javasolt migrálás További útmutatás
Blob Storage ügyfélkódtárak .NET (12.13.0-s vagy újabb verzió), Java (12.18.0-s vagy újabb verzió) és Python (12.13.0-s vagy újabb verzió) 2,0

1.0 (csak visszamenőleges kompatibilitás esetén)		 Frissítse a kódot az ügyféloldali titkosítás v2 használatára.

Töltse le a titkosított adatokat, fejtse vissza, majd v2 ügyféloldali titkosítással titkosítsa újra azokat.		 Ügyféloldali titkosítás blobokhoz
Blob Storage ügyfélkódtár .NET (12.12.0-s és újabb verzió), Java (12.17.0-s és újabb verziók) és Python (12.12.0-s és újabb verziók) 1.0 (nem ajánlott) Frissítse az alkalmazást az ügyféloldali titkosítást támogató Blob Storage SDK 2-es verziójára. Részletekért tekintse meg az ügyféloldali titkosítás SDK-támogatási mátrixát.

Frissítse a kódot az ügyféloldali titkosítás v2 használatára.

Töltse le a titkosított adatokat, fejtse vissza, majd v2 ügyféloldali titkosítással titkosítsa újra azokat.		 Ügyféloldali titkosítás blobokhoz
Queue Storage ügyfélkönyvtár a .NET (12.11.0-s vagy újabb verzió) és Python (12.4-es vagy újabb verzió) számára 2,0

1.0 (csak visszamenőleges kompatibilitás esetén)		 Frissítse a kódot az ügyféloldali titkosítás v2 használatára. Sorok ügyféloldali titkosítása
Queue Storage ügyfélkönyvtár a .NET (legfeljebb 12.10.0-s verzió) és Python (legfeljebb 12.3.0-s verzió) számára 1.0 (nem ajánlott) Frissítse az alkalmazást az ügyféloldali titkosítást támogató Queue Storage SDK-verzió 2-es verziójára. Az ügyféloldali titkosítás SDK-támogatási mátrixának megtekintése

Frissítse a kódot az ügyféloldali titkosítás v2 használatára.		 Sorok ügyféloldali titkosítása
Table Storage-ügyfélkódtár .NET, Java és Python 1.0 (nem ajánlott) Nem érhető el. n/a

Következő lépések

  • Last updated on