Šifrování na straně klienta a Azure Key Vault pro Microsoft Azure StorageClient-Side Encryption and Azure Key Vault for Microsoft Azure Storage

PřehledOverview

Klientská knihovna Azure Storage pro .NET podporuje šifrování dat v rámci klientských aplikací před odesláním do Azure Storage a dešifrování dat při stahování do klienta.The Azure Storage Client Library for .NET supports encrypting data within client applications before uploading to Azure Storage, and decrypting data while downloading to the client. Knihovna také podporuje integraci s Azure Key Vault pro správu klíčů účtu úložiště.The library also supports integration with Azure Key Vault for storage account key management.

Podrobný kurz, který vás provede procesem šifrování objektů BLOB pomocí šifrování na straně klienta a Azure Key Vault, najdete v tématu šifrování a dešifrování objektů BLOB v Microsoft Azure Storage pomocí Azure Key Vault.For a step-by-step tutorial that leads you through the process of encrypting blobs using client-side encryption and Azure Key Vault, see Encrypt and decrypt blobs in Microsoft Azure Storage using Azure Key Vault.

Šifrování na straně klienta pomocí Java najdete v tématu šifrování na straně klienta pomocí Java pro Microsoft Azure Storage.For client-side encryption with Java, see Client-Side Encryption with Java for Microsoft Azure Storage.

Šifrování a dešifrování prostřednictvím techniky obálekEncryption and decryption via the envelope technique

Procesy šifrování a dešifrování se řídí způsobem obálky.The processes of encryption and decryption follow the envelope technique.

Šifrování prostřednictvím techniky obálekEncryption via the envelope technique

Šifrování prostřednictvím techniky obálek funguje následujícím způsobem:Encryption via the envelope technique works in the following way:

  1. Klientská knihovna pro úložiště Azure vygeneruje šifrovací klíč obsahu (CEK), což je symetrický klíč založený na jednorázovém použití.The Azure storage client library generates a content encryption key (CEK), which is a one-time-use symmetric key.

  2. Uživatelská data se šifrují pomocí tohoto CEK.User data is encrypted using this CEK.

  3. CEK se pak zabalí (zašifruje) pomocí klíčového šifrovacího klíče (KEK).The CEK is then wrapped (encrypted) using the key encryption key (KEK). KEK je identifikován identifikátorem klíče a může se jednat o asymetrický klíč nebo symetrický klíč a dá se spravovat místně nebo uložit v trezorech klíčů Azure.The KEK is identified by a key identifier and can be an asymmetric key pair or a symmetric key and can be managed locally or stored in Azure Key Vaults.

    Klientská knihovna pro úložiště nemá nikdy přístup k KEK.The storage client library itself never has access to KEK. Knihovna vyvolá algoritmus pro zabalení klíče, který je k dispozici v Key Vault.The library invokes the key wrapping algorithm that is provided by Key Vault. V případě potřeby mohou uživatelé používat vlastní poskytovatele pro zalamování a rozbalení klíče.Users can choose to use custom providers for key wrapping/unwrapping if desired.

  4. Šifrovaná data se pak nahrají do služby Azure Storage.The encrypted data is then uploaded to the Azure Storage service. Zabalené klíče spolu s dalšími metadaty šifrování se ukládají jako metadata (v objektu BLOB) nebo interpolovaná pomocí šifrovaných dat (zprávy fronty a entity tabulky).The wrapped key along with some additional encryption metadata is either stored as metadata (on a blob) or interpolated with the encrypted data (queue messages and table entities).

Dešifrování prostřednictvím techniky obálekDecryption via the envelope technique

Dešifrování prostřednictvím techniky obálek funguje následujícím způsobem:Decryption via the envelope technique works in the following way:

  1. Klientská knihovna předpokládá, že uživatel spravuje klíč šifrovacího klíče (KEK) buď místně, nebo v trezorech klíčů Azure.The client library assumes that the user is managing the key encryption key (KEK) either locally or in Azure Key Vaults. Uživatel nemusí znát konkrétní klíč, který se použil pro šifrování.The user does not need to know the specific key that was used for encryption. Místo toho je možné nastavit a použít překladač klíčů, který překládá různé identifikátory klíčů na klíče.Instead, a key resolver which resolves different key identifiers to keys can be set up and used.
  2. Klientská knihovna stáhne zašifrovaná data spolu s jakýmkoli šifrovacím materiálem uloženým ve službě.The client library downloads the encrypted data along with any encryption material that is stored on the service.
  3. Nezabalený šifrovací klíč obsahu (CEK) se pak nebalí (dešifruje) pomocí klíčového šifrovacího klíče (KEK).The wrapped content encryption key (CEK) is then unwrapped (decrypted) using the key encryption key (KEK). V takovém případě knihovna klienta nemá přístup k KEK.Here again, the client library does not have access to KEK. Jednoduše vyvolá algoritmus rozbalení vlastního nebo Key Vaultho poskytovatele.It simply invokes the custom or Key Vault provider's unwrapping algorithm.
  4. Šifrovací klíč obsahu (CEK) se pak použije k dešifrování šifrovaných uživatelských dat.The content encryption key (CEK) is then used to decrypt the encrypted user data.

Šifrovací mechanismusEncryption Mechanism

Klientská knihovna pro úložiště používá algoritmus AES , aby se šifroval data uživatelů.The storage client library uses AES in order to encrypt user data. Konkrétně režim řetězení bloků šifry (CBC) s AES.Specifically, Cipher Block Chaining (CBC) mode with AES. Každá služba funguje trochu jinak, takže se na ně podíváme každý z nich.Each service works somewhat differently, so we will discuss each of them here.

Objekty blobBlobs

Klientská knihovna aktuálně podporuje pouze šifrování celých objektů BLOB.The client library currently supports encryption of whole blobs only. Šifrování je konkrétně podporováno, pokud uživatelé používají metody UploadFrom nebo metodu OpenWrite .Specifically, encryption is supported when users use the UploadFrom methods or the OpenWrite method. V případě souborů ke stažení jsou podporovány obě položky pro stahování dokončených i rozsahů.For downloads, both complete and range downloads are supported.

Při šifrování vygeneruje Klientská knihovna náhodný vektor inicializace (IV) o 16 bajtech, společně s náhodným šifrovacím klíčem obsahu (CEK) 32 bajtů a provede šifrování obálky dat objektů BLOB pomocí těchto informací.During encryption, the client library will generate a random Initialization Vector (IV) of 16 bytes, together with a random content encryption key (CEK) of 32 bytes, and perform envelope encryption of the blob data using this information. Zabalené CEK a některá další šifrovací metadata se pak ukládají jako metadata objektů BLOB společně s šifrovaným objektem BLOB ve službě.The wrapped CEK and some additional encryption metadata are then stored as blob metadata along with the encrypted blob on the service.

Varování

Pokud upravujete nebo ukládáte vlastní metadata pro objekt blob, musíte zajistit, aby byla tato metadata zachovaná.If you are editing or uploading your own metadata for the blob, you need to ensure that this metadata is preserved. Pokud nahrajete nová metadata bez těchto metadat, zabalené CEK, IV a další metadata budou ztraceny a obsah objektu BLOB nebude nikdy možné znovu získat.If you upload new metadata without this metadata, the wrapped CEK, IV, and other metadata will be lost and the blob content will never be retrievable again.

Stažení šifrovaného objektu BLOB zahrnuje načtení obsahu celého objektu BLOB s využitím metod DownloadTo/BlobReadStream pohodlí.Downloading an encrypted blob involves retrieving the content of the entire blob using the DownloadTo/BlobReadStream convenience methods. Zabalená CEK se nebalí a používá společně s IV (uloženými jako metadata objektů BLOB v tomto případě) k vrácení dešifrovaných dat uživatelům.The wrapped CEK is unwrapped and used together with the IV (stored as blob metadata in this case) to return the decrypted data to the users.

Stahování libovolného rozsahu (DownloadRange metod) v zašifrovaném objektu BLOB zahrnuje úpravu rozsahu poskytnutého uživateli, aby bylo možné získat malé množství dalších dat, která lze použít k úspěšnému dešifrování požadovaného rozsahu.Downloading an arbitrary range (DownloadRange methods) in the encrypted blob involves adjusting the range provided by users in order to get a small amount of additional data that can be used to successfully decrypt the requested range.

Všechny typy objektů BLOB (objekty blob bloku, objekty blob stránky a doplňovací objekty BLOB) se dají šifrovat nebo dešifrovat pomocí tohoto schématu.All blob types (block blobs, page blobs, and append blobs) can be encrypted/decrypted using this scheme.

FrontyQueues

Vzhledem k tomu, že zprávy fronty mohou být libovolného formátu, knihovna klienta definuje vlastní formát, který obsahuje inicializační vektor (IV) a šifrovaný šifrovací klíč (CEK) šifrovaného obsahu () v textu zprávy.Since queue messages can be of any format, the client library defines a custom format that includes the Initialization Vector (IV) and the encrypted content encryption key (CEK) in the message text.

Při šifrování generuje Klientská knihovna náhodnou hodnotu IV z 16 bajtů spolu s náhodným CEK 32 bajtů a pomocí těchto informací provádí šifrování obálky textu zprávy fronty.During encryption, the client library generates a random IV of 16 bytes along with a random CEK of 32 bytes and performs envelope encryption of the queue message text using this information. Zabalené CEK a některá další šifrovací metadata se pak přidají do zprávy zašifrované fronty.The wrapped CEK and some additional encryption metadata are then added to the encrypted queue message. Tato upravená zpráva (uvedená níže) je uložena ve službě.This modified message (shown below) is stored on the service.

<MessageText>{"EncryptedMessageContents":"6kOu8Rq1C3+M1QO4alKLmWthWXSmHV3mEfxBAgP9QGTU++MKn2uPq3t2UjF1DO6w","EncryptionData":{…}}</MessageText>

Během dešifrování je zabalený klíč extrahován ze zprávy fronty a rozbalením.During decryption, the wrapped key is extracted from the queue message and unwrapped. Rozhraní IV je také extrahováno ze zprávy fronty a použito společně s nezabaleným klíčem k dešifrování dat zprávy ve frontě.The IV is also extracted from the queue message and used along with the unwrapped key to decrypt the queue message data. Všimněte si, že metadata šifrování jsou malá (pod 500 bajtů), takže pokud se počítá s limitem 64KB pro zprávu fronty, měl by být dopad spravovatelný.Note that the encryption metadata is small (under 500 bytes), so while it does count toward the 64KB limit for a queue message, the impact should be manageable.

TabulkyTables

Klientská knihovna podporuje šifrování vlastností entit pro operace INSERT a nahrazování.The client library supports encryption of entity properties for insert and replace operations.

Poznámka

Sloučení se momentálně nepodporuje.Merge is not currently supported. Protože podmnožinu vlastností mohou byla zašifrována pomocí dříve za jiný klíč, jednoduše slučování nové vlastnosti a metadata aktualizace způsobí ztrátu dat.Since a subset of properties may have been encrypted previously using a different key, simply merging the new properties and updating the metadata will result in data loss. Slučují se buď vyžaduje, aby volání další služby do existující entity načíst ze služby nebo pomocí nového klíče pro jednu vlastnost, které nejsou vhodné z důvodů výkonu.Merging either requires making extra service calls to read the pre-existing entity from the service, or using a new key per property, both of which are not suitable for performance reasons.

Šifrování dat v tabulce funguje takto:Table data encryption works as follows:

  1. Uživatelé určují vlastnosti, které mají být zašifrovány.Users specify the properties to be encrypted.
  2. Klientská knihovna generuje náhodný vektor inicializace (IV) o 16 bajtech spolu s náhodným šifrovacím klíčem obsahu (CEK) o 32 bajtech pro každou entitu a provede šifrování obálky u jednotlivých vlastností, které se zašifrují, a to odvozením nové IV na vlastnost.The client library generates a random Initialization Vector (IV) of 16 bytes along with a random content encryption key (CEK) of 32 bytes for every entity, and performs envelope encryption on the individual properties to be encrypted by deriving a new IV per property. Šifrovaná vlastnost se ukládá jako binární data.The encrypted property is stored as binary data.
  3. Zabalené CEK a některá další šifrovací metadata se pak uloží jako dvě další rezervované vlastnosti.The wrapped CEK and some additional encryption metadata are then stored as two additional reserved properties. První vyhrazená vlastnost (_ClientEncryptionMetadata1) je řetězcová vlastnost, která obsahuje informace o IV, verzi a zabaleném klíči.The first reserved property (_ClientEncryptionMetadata1) is a string property that holds the information about IV, version, and wrapped key. Druhá rezervovaná vlastnost (_ClientEncryptionMetadata2) je binární vlastnost, která obsahuje informace o vlastnostech, které jsou zašifrovány.The second reserved property (_ClientEncryptionMetadata2) is a binary property that holds the information about the properties that are encrypted. Informace v této druhé vlastnosti (_ClientEncryptionMetadata2) jsou zašifrované.The information in this second property (_ClientEncryptionMetadata2) is itself encrypted.
  4. Vzhledem k těmto dalším rezervovaným vlastnostem vyžadovaným pro šifrování mohou uživatelé nyní mít pouze 250 vlastních vlastností místo 252.Due to these additional reserved properties required for encryption, users may now have only 250 custom properties instead of 252. Celková velikost entity musí být menší než 1 MB.The total size of the entity must be less than 1 MB.

Všimněte si, že lze šifrovat pouze vlastnosti řetězce.Note that only string properties can be encrypted. Pokud mají být zašifrovány jiné typy vlastností, je nutné je převést na řetězce.If other types of properties are to be encrypted, they must be converted to strings. Šifrované řetězce jsou uložené ve službě jako binární vlastnosti a jsou převedeny na řetězce zpět po dešifrování.The encrypted strings are stored on the service as binary properties, and they are converted back to strings after decryption.

Pro tabulky, vedle zásady šifrování musí uživatelé zadat vlastnosti, které mají být šifrována.For tables, in addition to the encryption policy, users must specify the properties to be encrypted. To lze provést zadáním buď atribut [EncryptProperty] (pro entity objektů POCO, které jsou odvozeny od TableEntity) nebo šifrování překladač v žádosti o možnostech.This can be done by either specifying an [EncryptProperty] attribute (for POCO entities that derive from TableEntity) or an encryption resolver in request options. Překladač šifrování je delegát, který má klíč oddílu, klíč řádku a název vlastnosti a vrátí logickou hodnotu, která určuje, jestli by měl být šifrovaná tuto vlastnost.An encryption resolver is a delegate that takes a partition key, row key, and property name and returns a Boolean that indicates whether that property should be encrypted. Při šifrování klientské knihovny použije tyto informace se rozhodnout, zda vlastnost by se měla šifrovat během zápisu lince.During encryption, the client library will use this information to decide whether a property should be encrypted while writing to the wire. Delegát také poskytuje možnost logiky po tom, jak jsou zašifrované vlastnosti.The delegate also provides for the possibility of logic around how properties are encrypted. (Například, pokud X, pak šifrování vlastnost A; v opačném případě šifrování vlastnosti A a B.) Všimněte si, že při čtení nebo dotazování entit není nutné tyto informace zadávat.(For example, if X, then encrypt property A; otherwise encrypt properties A and B.) Note that it is not necessary to provide this information while reading or querying entities.

Dávkové operaceBatch Operations

V dávkových operacích se stejné KEK budou používat ve všech řádcích této dávkové operace, protože Klientská knihovna pro každou dávkovou operaci povoluje pouze jeden objekt Options (a tedy jednu zásadu/KEK).In batch operations, the same KEK will be used across all the rows in that batch operation because the client library only allows one options object (and hence one policy/KEK) per batch operation. Knihovna klienta ale interně vygeneruje v dávce nový náhodný a náhodný CEK na řádek.However, the client library will internally generate a new random IV and random CEK per row in the batch. Uživatelé také mohou zvolit šifrování různých vlastností každé operace v dávce definováním tohoto chování v překladači šifrování.Users can also choose to encrypt different properties for every operation in the batch by defining this behavior in the encryption resolver.

DotazyQueries

Poznámka

Vzhledem k tomu, že jsou entity zašifrované, nemůžete spouštět dotazy, které filtrují na zašifrovanou vlastnost.Because the entities are encrypted, you cannot run queries that filter on an encrypted property. Pokud se pokusíte, výsledky budou nesprávné, protože se služba snaží porovnat zašifrovaná data s nezašifrovanými daty.If you try, results will be incorrect, because the service would be trying to compare encrypted data with unencrypted data.

Chcete-li provést operace s dotazem, je nutné zadat překladač klíčů, který dokáže vyřešit všechny klíče v sadě výsledků dotazu.To perform query operations, you must specify a key resolver that is able to resolve all the keys in the result set. Pokud entitu obsaženou ve výsledku dotazu nelze přeložit na zprostředkovatele, bude vyvolána chyba klientské knihovny.If an entity contained in the query result cannot be resolved to a provider, the client library will throw an error. Pro všechny dotazy, které provádějí projekce na straně serveru, knihovna klienta ve výchozím nastavení přidá do vybraných sloupců speciální vlastnosti šifrovacích metadat (_ClientEncryptionMetadata1 a _ClientEncryptionMetadata2).For any query that performs server-side projections, the client library will add the special encryption metadata properties (_ClientEncryptionMetadata1 and _ClientEncryptionMetadata2) by default to the selected columns.

Azure Key VaultAzure Key Vault

Azure Key Vault pomáhá chránit kryptografické klíče a tajné klíče používané cloudovými aplikacemi a službami.Azure Key Vault helps safeguard cryptographic keys and secrets used by cloud applications and services. Pomocí Azure Key Vault můžou uživatelé šifrovat klíče a tajné klíče (například ověřovací klíče, klíče účtu úložiště, šifrovací klíče dat,. Soubory PFX a hesla) pomocí klíčů chráněných moduly hardwarového zabezpečení (HSM).By using Azure Key Vault, users can encrypt keys and secrets (such as authentication keys, storage account keys, data encryption keys, .PFX files, and passwords) by using keys that are protected by hardware security modules (HSMs). Další informace najdete v tématu co je Azure Key Vault?.For more information, see What is Azure Key Vault?.

Klientská knihovna pro úložiště používá základní knihovnu Key Vault, aby poskytovala společné rozhraní napříč Azure pro správu klíčů.The storage client library uses the Key Vault core library in order to provide a common framework across Azure for managing keys. Uživatelé také získají další výhody použití knihovny rozšíření Key Vault.Users also get the additional benefit of using the Key Vault extensions library. Knihovna rozšíření poskytuje užitečné funkce kolem jednoduchých a bezproblémového místního a cloudového poskytovatele RSA a také s možností agregace a ukládání do mezipaměti.The extensions library provides useful functionality around simple and seamless Symmetric/RSA local and cloud key providers as well as with aggregation and caching.

Rozhraní a závislostiInterface and dependencies

Existují tři Key Vault balíčky:There are three Key Vault packages:

  • Microsoft. Azure. webtrezor. Core obsahuje rozhraní IKey a IKeyResolver.Microsoft.Azure.KeyVault.Core contains the IKey and IKeyResolver. Jedná se o malý balíček bez závislostí.It is a small package with no dependencies. Klientská knihovna pro úložiště pro .NET definuje jako závislost.The storage client library for .NET defines it as a dependency.
  • Microsoft. Azure. webtrezor obsahuje klienta služby Key Vault REST.Microsoft.Azure.KeyVault contains the Key Vault REST client.
  • Microsoft. Azure. webtrezor. Extensions obsahuje kód rozšíření, který zahrnuje implementace kryptografických algoritmů a RSAKey a SymmetricKey.Microsoft.Azure.KeyVault.Extensions contains extension code that includes implementations of cryptographic algorithms and an RSAKey and a SymmetricKey. Závisí na oborech názvů základní a trezoru klíčů a poskytuje funkce pro definování agregovaného překladače (když uživatelé chtějí používat víc zprostředkovatelů klíčů) a překladač klíčů pro ukládání do mezipaměti.It depends on the Core and KeyVault namespaces and provides functionality to define an aggregate resolver (when users want to use multiple key providers) and a caching key resolver. I když klientská knihovna pro úložiště nezávisí přímo na tomto balíčku, pokud uživatelé chtějí použít Azure Key Vault k ukládání klíčů nebo k používání rozšíření Key Vault ke využívání místních a cloudových zprostředkovatelů kryptografických služeb, bude tento balíček potřebovat.Although the storage client library does not directly depend on this package, if users wish to use Azure Key Vault to store their keys or to use the Key Vault extensions to consume the local and cloud cryptographic providers, they will need this package.

Key Vault je navržená pro hlavní klíče s vysokou hodnotou a omezení omezování na Key Vault jsou navržená s ohledem na to.Key Vault is designed for high-value master keys, and throttling limits per Key Vault are designed with this in mind. Při provádění šifrování na straně klienta s Key Vault je upřednostňovaným modelem použití symetrických hlavních klíčů uložených jako tajné klíče v Key Vault a v mezipaměti místně.When performing client-side encryption with Key Vault, the preferred model is to use symmetric master keys stored as secrets in Key Vault and cached locally. Uživatelé musí provést následující akce:Users must do the following:

  1. Vytvořte tajný kód offline a nahrajte ho do Key Vault.Create a secret offline and upload it to Key Vault.
  2. Použijte základní identifikátor tajného klíče jako parametr k vyřešení aktuální verze tajného klíče pro šifrování a místní ukládání těchto informací do mezipaměti.Use the secret's base identifier as a parameter to resolve the current version of the secret for encryption and cache this information locally. Použít CachingKeyResolver pro ukládání do mezipaměti; pro uživatele není očekávána implementace vlastní logiky ukládání do mezipaměti.Use CachingKeyResolver for caching; users are not expected to implement their own caching logic.
  3. Při vytváření zásad šifrování používejte překladač mezipaměti jako vstup.Use the caching resolver as an input while creating the encryption policy.

Další informace o využití Key Vault najdete v ukázkách šifrovacího kódu.More information regarding Key Vault usage can be found in the encryption code samples.

Osvědčené postupyBest practices

Podpora šifrování je k dispozici pouze v klientské knihovně pro úložiště pro .NET.Encryption support is available only in the storage client library for .NET. Windows Phone a prostředí Windows Runtime aktuálně nepodporují šifrování.Windows Phone and Windows Runtime do not currently support encryption.

Důležité

Pamatujte na tyto důležité body při použití šifrování na straně klienta:Be aware of these important points when using client-side encryption:

  • Při čtení nebo zápisu do šifrovaného objektu BLOB použijte úplné příkazy pro nahrání objektů BLOB a rozsah nebo celé objekty pro stažení objektů BLOB.When reading from or writing to an encrypted blob, use whole blob upload commands and range/whole blob download commands. Vyhněte se zápisu do zašifrovaného objektu BLOB pomocí operací protokolu, jako je blok vložení, seznam blokovaných objektů, zápis stránek, vymazat stránky nebo připojit blok; v opačném případě může dojít k poškození šifrovaného objektu BLOB a zpřístupnění ho nečitelným.Avoid writing to an encrypted blob using protocol operations such as Put Block, Put Block List, Write Pages, Clear Pages, or Append Block; otherwise you may corrupt the encrypted blob and make it unreadable.
  • V případě tabulek existuje podobné omezení.For tables, a similar constraint exists. Nezapomeňte neaktualizovat šifrované vlastnosti bez aktualizace metadat šifrování.Be careful to not update encrypted properties without updating the encryption metadata.
  • Pokud nastavíte metadata pro zašifrovaný objekt blob, můžete přepsat metadata týkající se šifrování, která jsou nutná k dešifrování, protože nastavení metadat není aditivní.If you set metadata on the encrypted blob, you may overwrite the encryption-related metadata required for decryption, since setting metadata is not additive. To platí také pro snímky; Vyhněte se zadávání metadat při vytváření snímku šifrovaného objektu BLOB.This is also true for snapshots; avoid specifying metadata while creating a snapshot of an encrypted blob. Pokud musí být nastavena metadata, nezapomeňte nejprve zavolat metodu FetchAttributes a získat aktuální šifrovací metadata a vyhnout se souběžným zápisům při nastavování metadat.If metadata must be set, be sure to call the FetchAttributes method first to get the current encryption metadata, and avoid concurrent writes while metadata is being set.
  • Povolte vlastnost RequireEncryption ve výchozích možnostech žádosti pro uživatele, kteří by měli pracovat pouze se zašifrovanými daty.Enable the RequireEncryption property in the default request options for users that should work only with encrypted data. Další informace najdete níže.See below for more info.

Rozhraní API klienta/rozhraníClient API / Interface

Při vytváření objektu EncryptionPolicy můžou uživatelé zadat jenom klíč (implementující IKey), jenom překladač (implementující IKeyResolver) nebo obojí.While creating an EncryptionPolicy object, users can provide only a Key (implementing IKey), only a resolver (implementing IKeyResolver), or both. IKey je základní typ klíče, který je identifikován pomocí identifikátoru klíče a poskytuje logiku pro balení a rozbalení.IKey is the basic key type that is identified using a key identifier and that provides the logic for wrapping/unwrapping. IKeyResolver se používá k překladu klíče během dešifrovacího procesu.IKeyResolver is used to resolve a key during the decryption process. Definuje metodu ResolveKey, která vrací IKey pro daný identifikátor klíče.It defines a ResolveKey method that returns an IKey given a key identifier. To umožňuje uživatelům volit mezi několika klíči, které jsou spravovány ve více umístěních.This provides users the ability to choose between multiple keys that are managed in multiple locations.

  • Pro šifrování se klíč použije vždycky a absence klíče bude mít za následek chybu.For encryption, the key is used always and the absence of a key will result in an error.
  • Pro dešifrování:For decryption:
    • Překladač klíčů je vyvolán, pokud je zadán pro získání klíče.The key resolver is invoked if specified to get the key. Pokud je překladač zadán, ale nemá mapování pro identifikátor klíče, je vyvolána chyba.If the resolver is specified but does not have a mapping for the key identifier, an error is thrown.
    • Pokud není překladač zadán, ale je zadán klíč, použije se klíč, pokud jeho identifikátor odpovídá požadovanému identifikátoru klíče.If resolver is not specified but a key is specified, the key is used if its identifier matches the required key identifier. Pokud identifikátor neodpovídá, je vyvolána chyba.If the identifier does not match, an error is thrown.

Příklady kódů v tomto článku ukazují, jak nastavit zásady šifrování a pracovat s šifrovanými daty, ale nemonstrují práci s Azure Key Vault.The code examples in this article demonstrate setting an encryption policy and working with encrypted data, but do not demonstrate working with Azure Key Vault. Ukázky šifrování na GitHubu ukazují podrobnější scénář pro objekty blob, fronty a tabulky společně s Key Vault integrací.The encryption samples on GitHub demonstrate a more detailed end-to-end scenario for blobs, queues and tables, along with Key Vault integration.

RequireEncryption režimRequireEncryption mode

Uživatelé mohou volitelně povolit režim operace, kde všechna nahraná a stažená soubory musí být zašifrovaná.Users can optionally enable a mode of operation where all uploads and downloads must be encrypted. V tomto režimu se pokusy o nahrání dat bez zásad šifrování nebo stažení dat, která nejsou ve službě zašifrovaná, selžou na klientovi.In this mode, attempts to upload data without an encryption policy or download data that is not encrypted on the service will fail on the client. Toto chování řídí vlastnost RequireEncryption objektu možností žádosti.The RequireEncryption property of the request options object controls this behavior. Pokud aplikace zašifruje všechny objekty uložené v Azure Storage, můžete nastavit vlastnost RequireEncryption na výchozí možnosti požadavku pro objekt klienta služby.If your application will encrypt all objects stored in Azure Storage, then you can set the RequireEncryption property on the default request options for the service client object. Například nastavte CloudBlobClient. DefaultRequestOptions. RequireEncryption na true , aby se vyžadovalo šifrování pro všechny operace objektů BLOB provedené prostřednictvím tohoto objektu klienta.For example, set CloudBlobClient.DefaultRequestOptions.RequireEncryption to true to require encryption for all blob operations performed through that client object.

Blob service šifrováníBlob service encryption

Vytvořte objekt BlobEncryptionPolicy a nastavte ho v možnostech žádosti (na rozhraní API nebo na úrovni klienta pomocí DefaultRequestOptions).Create a BlobEncryptionPolicy object and set it in the request options (per API or at a client level by using DefaultRequestOptions). Všechny ostatní budou zpracovávány v interní knihovně klienta.Everything else will be handled by the client library internally.

// Create the IKey used for encryption.
 RsaKey key = new RsaKey("private:key1" /* key identifier */);

 // Create the encryption policy to be used for upload and download.
 BlobEncryptionPolicy policy = new BlobEncryptionPolicy(key, null);

 // Set the encryption policy on the request options.
 BlobRequestOptions options = new BlobRequestOptions() { EncryptionPolicy = policy };

 // Upload the encrypted contents to the blob.
 blob.UploadFromStream(stream, size, null, options, null);

 // Download and decrypt the encrypted contents from the blob.
 MemoryStream outputStream = new MemoryStream();
 blob.DownloadToStream(outputStream, null, options, null);

Služba front šifrováníQueue service encryption

Vytvořte objekt QueueEncryptionPolicy a nastavte ho v možnostech žádosti (na rozhraní API nebo na úrovni klienta pomocí DefaultRequestOptions).Create a QueueEncryptionPolicy object and set it in the request options (per API or at a client level by using DefaultRequestOptions). Všechny ostatní budou zpracovávány v interní knihovně klienta.Everything else will be handled by the client library internally.

// Create the IKey used for encryption.
 RsaKey key = new RsaKey("private:key1" /* key identifier */);

 // Create the encryption policy to be used for upload and download.
 QueueEncryptionPolicy policy = new QueueEncryptionPolicy(key, null);

 // Add message
 QueueRequestOptions options = new QueueRequestOptions() { EncryptionPolicy = policy };
 queue.AddMessage(message, null, null, options, null);

 // Retrieve message
 CloudQueueMessage retrMessage = queue.GetMessage(null, options, null);

Table service šifrováníTable service encryption

Kromě vytváření zásad šifrování a jejich nastavení v možnostech žádosti musíte buď zadat EncryptionResolver v TableRequestOptions, nebo pro entitu nastavit atribut [EncryptProperty].In addition to creating an encryption policy and setting it on request options, you must either specify an EncryptionResolver in TableRequestOptions, or set the [EncryptProperty] attribute on the entity.

Použití překladačeUsing the resolver

// Create the IKey used for encryption.
 RsaKey key = new RsaKey("private:key1" /* key identifier */);

 // Create the encryption policy to be used for upload and download.
 TableEncryptionPolicy policy = new TableEncryptionPolicy(key, null);

 TableRequestOptions options = new TableRequestOptions()
 {
    EncryptionResolver = (pk, rk, propName) =>
     {
        if (propName == "foo")
         {
            return true;
         }
         return false;
     },
     EncryptionPolicy = policy
 };

 // Insert Entity
 currentTable.Execute(TableOperation.Insert(ent), options, null);

 // Retrieve Entity
 // No need to specify an encryption resolver for retrieve
 TableRequestOptions retrieveOptions = new TableRequestOptions()
 {
    EncryptionPolicy = policy
 };

 TableOperation operation = TableOperation.Retrieve(ent.PartitionKey, ent.RowKey);
 TableResult result = currentTable.Execute(operation, retrieveOptions, null);

Použití atributůUsing attributes

Jak je uvedeno výše, pokud entita implementuje TableEntity, pak lze vlastnosti dekorovat pomocí atributu [EncryptProperty] namísto zadání EncryptionResolver.As mentioned above, if the entity implements TableEntity, then the properties can be decorated with the [EncryptProperty] attribute instead of specifying the EncryptionResolver.

[EncryptProperty]
 public string EncryptedProperty1 { get; set; }

Šifrování a výkonEncryption and performance

Všimněte si, že šifrování dat úložiště má za následek zvýšené nároky na výkon.Note that encrypting your storage data results in additional performance overhead. Klíč obsahu a IV se musí vygenerovat, samotný obsah musí být zašifrovaný a další metadata musí být naformátovaná a nahraná.The content key and IV must be generated, the content itself must be encrypted, and additional meta-data must be formatted and uploaded. Tato režie se bude lišit v závislosti na množství šifrovaných dat.This overhead will vary depending on the quantity of data being encrypted. Zákazníkům doporučujeme, aby při vývoji vždy otestovali své aplikace na výkon.We recommend that customers always test their applications for performance during development.

Další krokyNext steps