Azure Storage-beveiligings handleidingAzure Storage security guide

Azure Storage biedt een uitgebreide reeks beveiligings mogelijkheden die ontwikkel aars in staat stellen om veilige toepassingen te bouwen:Azure Storage provides a comprehensive set of security capabilities that together enable developers to build secure applications:

Dit artikel bevat een overzicht van elk van deze beveiligings functies die kunnen worden gebruikt met Azure Storage.This article provides an overview of each of these security features that can be used with Azure Storage. Koppelingen worden verstrekt aan artikelen die informatie geven over elke functie, zodat u gemakkelijk verder kunt onderzoeken op elk onderwerp.Links are provided to articles that will give details of each feature so you can easily do further investigation on each topic.

Hier volgen de onderwerpen die in dit artikel worden behandeld:Here are the topics to be covered in this article:

  • Beveiliging van het beheer vlak : uw opslag account beveiligenManagement Plane Security – Securing your Storage Account

    Het beheer vlak bestaat uit de resources die worden gebruikt voor het beheren van uw opslag account.The management plane consists of the resources used to manage your storage account. In deze sectie wordt het Azure Resource Manager-implementatie model beschreven en wordt uitgelegd hoe u op rollen gebaseerde Access Control (RBAC) kunt gebruiken om de toegang tot uw opslag accounts te beheren.This section covers the Azure Resource Manager deployment model and how to use Role-Based Access Control (RBAC) to control access to your storage accounts. Het adres bevat ook informatie over het beheren van de sleutels van uw opslag account en hoe u deze opnieuw genereert.It also addresses managing your storage account keys and how to regenerate them.

  • Beveiliging van gegevens vlak : de toegang tot uw gegevens beveiligenData Plane Security – Securing Access to Your Data

    In deze sectie kijken we naar het toestaan van toegang tot de daad werkelijke gegevens objecten in uw opslag account, zoals blobs, bestanden, wacht rijen en tabellen, met behulp van hand tekeningen voor gedeelde toegang en opgeslagen toegangs beleid.In this section, we'll look at allowing access to the actual data objects in your Storage account, such as blobs, files, queues, and tables, using Shared Access Signatures and Stored Access Policies. We behandelen zowel SAS op service niveau als SAS op account niveau.We will cover both service-level SAS and account-level SAS. U ziet ook hoe u de toegang tot een specifiek IP-adres (of een bereik van IP-adressen) kunt beperken, hoe u het protocol dat wordt gebruikt voor HTTPS kunt beperken en hoe u een Shared Access Signature intrekt zonder te wachten totdat het verloopt.We'll also see how to limit access to a specific IP address (or range of IP addresses), how to limit the protocol used to HTTPS, and how to revoke a Shared Access Signature without waiting for it to expire.

  • Versleuteling 'in transit'Encryption in Transit

    In deze sectie wordt beschreven hoe u gegevens kunt beveiligen wanneer u deze overbrengt naar of uit Azure Storage.This section discusses how to secure data when you transfer it into or out of Azure Storage. Er wordt gecommuniceerd over het aanbevolen gebruik van HTTPS en de versleuteling die wordt gebruikt door SMB 3,0 voor Azure-bestands shares.We'll talk about the recommended use of HTTPS and the encryption used by SMB 3.0 for Azure file shares. We gaan ook kijken naar client-side Encryption, waarmee u de gegevens kunt versleutelen voordat ze worden overgebracht naar de opslag in een client toepassing, en om de gegevens te ontsleutelen nadat deze buiten de opslag zijn overgedragen.We will also take a look at Client-side Encryption, which enables you to encrypt the data before it is transferred into Storage in a client application, and to decrypt the data after it is transferred out of Storage.

  • Versleuteling 'at rest'Encryption at Rest

    We spreken over Storage Service Encryption (SSE). dit wordt nu automatisch ingeschakeld voor nieuwe en bestaande opslag accounts.We will talk about Storage Service Encryption (SSE), which is now automatically enabled for new and existing storage accounts. We gaan ook kijken hoe u Azure Disk Encryption kunt gebruiken en de belangrijkste verschillen en gevallen van schijf versleuteling versus SSE versus versleuteling aan de client zijde te verkennen.We will also look at how you can use Azure Disk Encryption and explore the basic differences and cases of Disk Encryption versus SSE versus Client-Side Encryption. We kijken kort naar FIPS-naleving voor de V.S. Overheids computers.We will briefly look at FIPS compliance for U.S. Government computers.

  • Opslaganalyse gebruiken om de toegang van Azure Storage te controlerenUsing Storage Analytics to audit access of Azure Storage

    In deze sectie wordt beschreven hoe u informatie kunt vinden in de logboeken van de opslag analyse voor een aanvraag.This section discusses how to find information in the storage analytics logs for a request. We nemen een kijkje in de werkelijke opslag analyse-logboek gegevens en zien hoe u kunt onderscheiden of een aanvraag wordt gedaan met de sleutel van het opslag account, met een gedeelde toegangs handtekening of anoniem, en of deze is geslaagd of mislukt.We'll take a look at real storage analytics log data and see how to discern whether a request is made with the Storage account key, with a Shared Access signature, or anonymously, and whether it succeeded or failed.

  • Clients op basis van een browser inschakelen met CORSEnabling Browser-Based Clients using CORS

    In deze sectie wordt uitgelegd hoe u het delen van cross-Origin-resources (CORS) toestaat.This section talks about how to allow cross-origin resource sharing (CORS). We praten over de toegang tussen domeinen en hoe u deze kunt afhandelen met de CORS-mogelijkheden die zijn ingebouwd in Azure Storage.We'll talk about cross-domain access, and how to handle it with the CORS capabilities built into Azure Storage.

Beveiliging van het beheer vlakManagement Plane Security

Het beheer vlak bestaat uit bewerkingen die van invloed zijn op het opslag account zelf.The management plane consists of operations that affect the storage account itself. U kunt bijvoorbeeld een opslag account maken of verwijderen, een lijst met opslag accounts in een abonnement ophalen, de sleutel van het opslag account ophalen of de sleutel van het opslag account opnieuw genereren.For example, you can create or delete a storage account, get a list of storage accounts in a subscription, retrieve the storage account keys, or regenerate the storage account keys.

Wanneer u een nieuw opslag account maakt, selecteert u een implementatie model van klassiek of Resource Manager.When you create a new storage account, you select a deployment model of Classic or Resource Manager. Het klassieke model voor het maken van resources in azure staat alleen de toegang tot het abonnement toe, en is op zijn beurt het opslag account.The Classic model of creating resources in Azure only allows all-or-nothing access to the subscription, and in turn, the storage account.

Deze hand leiding is gericht op het Resource Manager-model dat de aanbevolen manier is voor het maken van opslag accounts.This guide focuses on the Resource Manager model that is the recommended means for creating storage accounts. Met de Resource Manager-opslag accounts kunt u, in plaats van toegang tot het hele abonnement te geven, de toegang op een meer beperkt niveau beheren op het beheer vlak met behulp van op rollen gebaseerde Access Control (RBAC).With the Resource Manager storage accounts, rather than giving access to the entire subscription, you can control access on a more finite level to the management plane using Role-Based Access Control (RBAC).

Uw opslag account beveiligen met Access Control op basis van rollen (RBAC)How to secure your storage account with Role-Based Access Control (RBAC)

Laten we weten wat RBAC is en hoe u het kunt gebruiken.Let's talk about what RBAC is, and how you can use it. Elk Azure-abonnement heeft een Azure Active Directory.Each Azure subscription has an Azure Active Directory. Gebruikers, groepen en toepassingen van die Directory kunnen toegang krijgen om resources te beheren in het Azure-abonnement dat gebruikmaakt van het Resource Manager-implementatie model.Users, groups, and applications from that directory can be granted access to manage resources in the Azure subscription that use the Resource Manager deployment model. Dit type beveiliging wordt aangeduid als op rollen gebaseerd Access Control (RBAC).This type of security is referred to as Role-Based Access Control (RBAC). Als u deze toegang wilt beheren, kunt u de Azure Portal, de Azure cli-hulpprogram ma's, Power shellof de rest-api's van de Azure Storage Resource providergebruiken.To manage this access, you can use the Azure portal, the Azure CLI tools, PowerShell, or the Azure Storage Resource Provider REST APIs.

Met het Resource Manager-model plaatst u het opslag account in een resource groep en beheert u de toegang tot het beheer vlak van dat specifieke opslag account met behulp van Azure Active Directory.With the Resource Manager model, you put the storage account in a resource group and control access to the management plane of that specific storage account using Azure Active Directory. U kunt bijvoorbeeld specifieke gebruikers de mogelijkheid geven om toegang te krijgen tot de sleutels van het opslag account, terwijl andere gebruikers informatie over het opslag account kunnen bekijken, maar geen toegang hebben tot de sleutel van het opslag account.For example, you can give specific users the ability to access the storage account keys, while other users can view information about the storage account, but cannot access the storage account keys.

Toegang verlenenGranting Access

Toegang wordt verleend door de juiste RBAC-rol toe te wijzen aan gebruikers, groepen en toepassingen, aan het juiste bereik.Access is granted by assigning the appropriate RBAC role to users, groups, and applications, at the right scope. Als u toegang wilt verlenen aan het hele abonnement, wijst u een rol toe op het abonnements niveau.To grant access to the entire subscription, you assign a role at the subscription level. U kunt toegang verlenen aan alle resources in een resource groep door machtigingen te verlenen aan de resource groep zelf.You can grant access to all of the resources in a resource group by granting permissions to the resource group itself. U kunt ook specifieke rollen toewijzen aan specifieke resources, zoals opslag accounts.You can also assign specific roles to specific resources, such as storage accounts.

Hier volgen de belangrijkste punten die u moet weten over het gebruik van RBAC voor toegang tot de beheer bewerkingen van een Azure Storage account:Here are the main points that you need to know about using RBAC to access the management operations of an Azure Storage account:

  • Wanneer u toegang toewijst, wijst u in principe een rol toe aan het account dat u toegang wilt geven.When you assign access, you basically assign a role to the account that you want to have access. U kunt de toegang beheren tot de bewerkingen die worden gebruikt voor het beheer van dat opslag account, maar niet voor de gegevens objecten in het account.You can control access to the operations used to manage that storage account, but not to the data objects in the account. U kunt bijvoorbeeld machtigingen verlenen om de eigenschappen van het opslag account (zoals redundantie) op te halen, maar niet naar een container of gegevens binnen een container in Blob Storage.For example, you can grant permission to retrieve the properties of the storage account (such as redundancy), but not to a container or data within a container inside Blob Storage.

  • Als iemand toestemming heeft om toegang te krijgen tot de gegevens objecten in het opslag account, kunt u hen toestemming geven om de sleutel van het opslag account te lezen. deze gebruiker kan vervolgens deze sleutels gebruiken voor toegang tot de blobs, wacht rijen, tabellen en bestanden.For someone to have permission to access the data objects in the storage account, you can give them permission to read the storage account keys, and that user can then use those keys to access the blobs, queues, tables, and files.

  • Rollen kunnen worden toegewezen aan een specifiek gebruikers account, een groep gebruikers of aan een specifieke toepassing.Roles can be assigned to a specific user account, a group of users, or to a specific application.

  • Elke rol heeft een lijst met acties en niet de acties.Each role has a list of Actions and Not Actions. De rol Inzender voor virtuele machines heeft bijvoorbeeld de actie ' Listkeys ophalen ', waarmee de sleutels van het opslag account kunnen worden gelezen.For example, the Virtual Machine Contributor role has an Action of "listKeys" that allows the storage account keys to be read. De Inzender heeft ' not Actions ', zoals het bijwerken van de toegang voor gebruikers in de Active Directory.The Contributor has "Not Actions" such as updating the access for users in the Active Directory.

  • Rollen voor opslag zijn onder andere (maar zijn niet beperkt tot) de volgende rollen:Roles for storage include (but are not limited to) the following roles:

    • Eigenaar: ze kunnen alles beheren, met inbegrip van toegang.Owner – They can manage everything, including access.

    • Inzender: ze kunnen alles doen wat de eigenaar kan doen, met uitzonde ring van toegang toewijzen.Contributor – They can do anything the owner can do except assign access. Iemand met deze rol kan de sleutels voor het opslag account weer geven en opnieuw genereren.Someone with this role can view and regenerate the storage account keys. Met de sleutels voor het opslag account hebben ze toegang tot de gegevens objecten.With the storage account keys, they can access the data objects.

    • Lezer: ze kunnen informatie weer geven over het opslag account, met uitzonde ring van geheimen.Reader – They can view information about the storage account, except secrets. Als u bijvoorbeeld een rol met lezers machtigingen voor het opslag account aan iemand toewijst, kunnen ze de eigenschappen van het opslag account weer geven, maar kunnen ze geen wijzigingen aanbrengen in de eigenschappen of de sleutels van het opslag account weer geven.For example, if you assign a role with reader permissions on the storage account to someone, they can view the properties of the storage account, but they can't make any changes to the properties or view the storage account keys.

    • Inzender voor opslag accounts: ze kunnen het opslag account beheren: ze kunnen de resource groepen en-resources van het abonnement lezen en implementaties van de abonnements resource groep maken en beheren.Storage Account Contributor – They can manage the storage account – they can read the subscription's resource groups and resources, and create and manage subscription resource group deployments. Ze hebben ook toegang tot de sleutel van het opslag account, die op zijn beurt de toegang tot het gegevens vlak kan krijgen.They can also access the storage account keys, which in turn means they can access the data plane.

    • Beheerder van gebruikers toegang: ze kunnen gebruikers toegang tot het opslag account beheren.User Access Administrator – They can manage user access to the storage account. Ze kunnen bijvoorbeeld lezers toegang verlenen tot een specifieke gebruiker.For example, they can grant Reader access to a specific user.

    • Inzender voor virtuele machines: ze kunnen virtuele machines beheren, maar niet het opslag account waarmee ze zijn verbonden.Virtual Machine Contributor – They can manage virtual machines but not the storage account to which they are connected. Met deze rol kan de sleutel van het opslag account worden weer gegeven. Dit betekent dat de gebruiker aan wie u deze rol toewijst, het gegevens vlak kan bijwerken.This role can list the storage account keys, which means that the user to whom you assign this role can update the data plane.

      Om een gebruiker een virtuele machine te laten maken, moeten ze het bijbehorende VHD-bestand in een opslag account kunnen maken.In order for a user to create a virtual machine, they have to be able to create the corresponding VHD file in a storage account. Hiervoor moeten ze de sleutel van het opslag account kunnen ophalen en door geven aan de API die de VM maakt.To do that, they need to be able to retrieve the storage account key and pass it to the API creating the VM. Daarom moeten ze deze machtiging hebben, zodat ze de sleutels van het opslag account kunnen weer geven.Therefore, they must have this permission so they can list the storage account keys.

  • De mogelijkheid om aangepaste rollen te definiëren is een functie waarmee u een reeks acties kunt samen stellen uit een lijst met beschik bare acties die kunnen worden uitgevoerd op Azure-resources.The ability to define custom roles is a feature that allows you to compose a set of actions from a list of available actions that can be performed on Azure resources.

  • U moet de gebruiker in uw Azure Active Directory instellen voordat u hieraan een rol kunt toewijzen.The user must be set up in your Azure Active Directory before you can assign a role to them.

  • U kunt een rapport maken met wie u hebt toegewezen/ingetrokken wat voor soort toegang tot/waar en op welk bereik u Power shell of de Azure CLI wilt gebruiken.You can create a report of who granted/revoked what kind of access to/from whom and on what scope using PowerShell or the Azure CLI.

ResourcesResources

De sleutels van uw opslag account beherenManaging Your Storage Account Keys

Sleutels voor opslag accounts zijn 512-bits teken reeksen die door Azure worden gemaakt en die samen met de naam van het opslag account kunnen worden gebruikt voor toegang tot de gegevens objecten die zijn opgeslagen in het opslag account, bijvoorbeeld blobs, entiteiten in een tabel, wachtrij berichten en bestanden op een Azure-bestands share.Storage account keys are 512-bit strings created by Azure that, along with the storage account name, can be used to access the data objects stored in the storage account, for example, blobs, entities within a table, queue messages, and files on an Azure file share. De toegang tot de sleutel van het opslag account beheren beheert de toegang tot het gegevens vlak voor dat opslag account.Controlling access to the storage account keys controls access to the data plane for that storage account.

Elk opslag account heeft twee sleutels waarnaar wordt verwezen als "sleutel 1" en "sleutel 2" in de Azure Portal en in de Power shell-cmdlets.Each storage account has two keys referred to as "Key 1" and "Key 2" in the Azure portal and in the PowerShell cmdlets. Deze kunnen hand matig worden gegenereerd met een van de volgende methoden, waaronder, maar niet beperkt tot het gebruik van de Azure Portal, Power shell, de Azure CLI of programmatisch met behulp van de client bibliotheek voor .net-opslag of de Azure Storage Services-rest API.These can be regenerated manually using one of several methods, including, but not limited to using the Azure portal, PowerShell, the Azure CLI, or programmatically using the .NET Storage Client Library or the Azure Storage Services REST API.

Er zijn een aantal redenen om de sleutels van uw opslag account opnieuw te genereren.There are any number of reasons to regenerate your storage account keys.

  • U kunt deze mogelijk op regel matige basis opnieuw genereren om veiligheids redenen.You might regenerate them on a regular basis for security reasons.
  • U kunt de sleutels van uw opslag account opnieuw genereren als iemand in een toepassing wordt beheerd naar Hack en de sleutel ophaalt die is opgeslagen in een configuratie bestand, zodat deze volledige toegang geeft tot uw opslag account.You would regenerate your storage account keys if someone managed to hack into an application and retrieve the key that was hardcoded or saved in a configuration file, giving them full access to your storage account.
  • Een andere case voor het opnieuw genereren van sleutels is als uw team gebruikmaakt van een Storage Explorer toepassing die de sleutel van het opslag account behoudt en een van de team leden verlaat.Another case for key regeneration is if your team is using a Storage Explorer application that retains the storage account key, and one of the team members leaves. De toepassing blijft werken, waardoor ze toegang hebben tot uw opslag account nadat ze zijn verdwenen.The application would continue to work, giving them access to your storage account after they're gone. Dit is in feite de belangrijkste reden voor het maken van gedeelde toegangs handtekeningen op account niveau: u kunt een SAS op account niveau gebruiken in plaats van de toegangs sleutels in een configuratie bestand op te slaan.This is actually the primary reason they created account-level Shared Access Signatures – you can use an account-level SAS instead of storing the access keys in a configuration file.

Sleutel regeneratie planKey regeneration plan

U wilt niet alleen de sleutel die u gebruikt zonder een planning opnieuw genereren.You don't want to just regenerate the key you are using without some planning. Als u dat doet, kunt u alle toegang tot dat opslag account afmelden, wat kan leiden tot grote onderbrekingen.If you do that, you could cut off all access to that storage account, which can cause major disruption. Daarom zijn er twee sleutels.This is why there are two keys. Genereer één sleutel per keer.You should regenerate one key at a time.

Voordat u de sleutels opnieuw genereert, moet u een lijst hebben van alle toepassingen die afhankelijk zijn van het opslag account, evenals andere services die u gebruikt in Azure.Before you regenerate your keys, be sure you have a list of all of your applications that are dependent on the storage account, as well as any other services you are using in Azure. Als u bijvoorbeeld Azure Media Services gebruikt die afhankelijk zijn van uw opslag account, moet u de toegangs sleutels opnieuw synchroniseren met uw media service nadat u de sleutel opnieuw hebt gegenereerd.For example, if you are using Azure Media Services that are dependent on your storage account, you must resync the access keys with your media service after you regenerate the key. Als u toepassingen gebruikt, zoals een opslag Verkenner, moet u ook de nieuwe sleutels voor deze toepassingen opgeven.If you are using any applications such as a storage explorer, you will need to provide the new keys to those applications as well. Als u virtuele machines hebt waarvan de VHD-bestanden worden opgeslagen in het opslag account, worden deze niet beïnvloed door het opnieuw genereren van de sleutel van het opslag account.If you have VMs whose VHD files are stored in the storage account, they will not be affected by regenerating the storage account keys.

U kunt uw sleutels opnieuw genereren in de Azure Portal.You can regenerate your keys in the Azure portal. Wanneer de sleutels opnieuw worden gegenereerd, kan het tot tien minuten duren voordat deze worden gesynchroniseerd tussen opslag Services.Once keys are regenerated, they can take up to 10 minutes to be synchronized across Storage Services.

Wanneer u klaar bent, ziet u hier het algemene proces waarin wordt uitgelegd hoe u uw sleutel moet wijzigen.When you're ready, here's the general process detailing how you should change your key. In dit geval is de veronderstelling dat u momenteel sleutel 1 gebruikt en gaat u alles wijzigen voor het gebruik van sleutel 2.In this case, the assumption is that you are currently using Key 1 and you are going to change everything to use Key 2 instead.

  1. Genereer sleutel 2 opnieuw om er zeker van te zijn dat het veilig is.Regenerate Key 2 to ensure that it is secure. U kunt dit doen in de Azure Portal.You can do this in the Azure portal.
  2. In alle toepassingen waar de opslag sleutel is opgeslagen, wijzigt u de opslag sleutel zodat de nieuwe waarde van sleutel 2 wordt gebruikt.In all of the applications where the storage key is stored, change the storage key to use Key 2's new value. De toepassing testen en publiceren.Test and publish the application.
  3. Genereer de sleutel 1 opnieuw nadat alle toepassingen en services actief zijn en correct zijn uitgevoerd.After all of the applications and services are up and running successfully, regenerate Key 1. Dit zorgt ervoor dat iedereen met wie u de nieuwe sleutel niet uitdrukkelijk hebt opgegeven, geen toegang meer heeft tot het opslag account.This ensures that anybody to whom you have not expressly given the new key will no longer have access to the storage account.

Als u momenteel sleutel 2 gebruikt, kunt u hetzelfde proces gebruiken, maar de sleutel namen vervolgens terugdraaien.If you are currently using Key 2, you can use the same process, but reverse the key names.

U kunt migreren over een paar dagen, waarbij u elke toepassing wijzigt om de nieuwe sleutel te gebruiken en deze te publiceren.You can migrate over a couple of days, changing each application to use the new key and publishing it. Nadat alle zijn voltooid, moet u teruggaan en de oude sleutel opnieuw genereren, zodat deze niet meer werkt.After all of them are done, you should then go back and regenerate the old key so it no longer works.

Een andere mogelijkheid is om de sleutel van het opslag account in een Azure Key Vault als geheim te plaatsen en de sleutel van de toepassing op te halen.Another option is to put the storage account key in an Azure Key Vault as a secret and have your applications retrieve the key from there. Wanneer u de sleutel opnieuw genereert en de Azure Key Vault bijwerkt, hoeven de toepassingen niet opnieuw te worden geïmplementeerd omdat deze automatisch de nieuwe sleutel van de Azure Key Vault ophalen.Then when you regenerate the key and update the Azure Key Vault, the applications will not need to be redeployed because they will pick up the new key from the Azure Key Vault automatically. Houd er rekening mee dat u de toepassing de sleutel kunt laten lezen telkens wanneer u deze nodig hebt, of u kunt deze in de cache opslaan en als deze niet kan worden gebruikt, haalt u de sleutel opnieuw op uit het Azure Key Vault.Note that you can have the application read the key each time you need it, or you can cache it in memory and if it fails when using it, retrieve the key again from the Azure Key Vault.

Met Azure Key Vault wordt ook een ander beveiligings niveau voor uw opslag sleutels toegevoegd.Using Azure Key Vault also adds another level of security for your storage keys. Als u deze methode gebruikt, hebt u nooit de opslag sleutel vastgelegd in een configuratie bestand. Dit betekent dat de toegang tot de sleutels zonder specifieke machtigingen wordt verwijderd.If you use this method, you will never have the storage key hardcoded in a configuration file, which removes that avenue of somebody getting access to the keys without specific permission.

Een ander voor deel van het gebruik van Azure Key Vault is dat u ook de toegang tot uw sleutels kunt controleren met behulp van Azure Active Directory.Another advantage of using Azure Key Vault is you can also control access to your keys using Azure Active Directory. Dit betekent dat u toegang kunt verlenen tot de toepassingen die de sleutels moeten ophalen van Azure Key Vault en dat andere toepassingen geen toegang hebben tot de sleutels zonder dat ze hiervoor toestemming geven.This means you can grant access to the handful of applications that need to retrieve the keys from Azure Key Vault, and know that other applications will not be able to access the keys without granting them permission specifically.

Notitie

Micro soft raadt u aan om op hetzelfde moment slechts één van de sleutels in al uw toepassingen te gebruiken.Microsoft recommends using only one of the keys in all of your applications at the same time. Als u Key 1 op sommige locaties en sleutel 2 in andere gebruikt, kunt u de sleutels niet draaien zonder dat de toepassing de toegang verliest.If you use Key 1 in some places and Key 2 in others, you will not be able to rotate your keys without some application losing access.

ResourcesResources

Beveiliging van gegevens vlakData Plane Security

Beveiliging van het gegevens vlak verwijst naar de methoden die worden gebruikt voor het beveiligen van de gegevens objecten die zijn opgeslagen in Azure Storage: de blobs, wacht rijen, tabellen en bestanden.Data Plane Security refers to the methods used to secure the data objects stored in Azure Storage – the blobs, queues, tables, and files. We hebben methoden gezien voor het versleutelen van de gegevens en beveiliging tijdens de door Voer van de gegevens, maar hoe gaat u verder met het beheren van de toegang tot de objecten?We've seen methods to encrypt the data and security during transit of the data, but how do you go about controlling access to the objects?

Er zijn drie opties voor het autoriseren van toegang tot gegevens objecten in Azure Storage, waaronder:You have three options for authorizing access to data objects in Azure Storage, including:

  • Azure AD gebruiken om toegang te verlenen aan containers en wacht rijen.Using Azure AD to authorize access to containers and queues. Azure AD biedt voor delen ten opzichte van andere methoden voor verificatie, waaronder het verwijderen van geheimen in uw code.Azure AD provides advantages over other approaches to authorization, including removing the need to store secrets in your code. Zie toegang tot Azure Storage verifiëren met behulp van Azure Active Directoryvoor meer informatie.For more information, see Authenticate access to Azure Storage using Azure Active Directory.
  • De sleutels van uw opslag account gebruiken om toegang te verlenen via een gedeelde sleutel.Using your storage account keys to authorize access via Shared Key. Voor autorisatie via een gedeelde sleutel moet u de sleutels van uw opslag account opslaan in uw toepassing. Daarom raadt micro soft aan om in plaats daarvan Azure AD te gebruiken.Authorizing via Shared Key requires storing your storage account keys in your application, so Microsoft recommends using Azure AD instead where possible.
  • Shared Access Signatures gebruiken om beheerde machtigingen te verlenen aan specifieke gegevens objecten voor een specifieke tijds duur.Using Shared Access Signatures to grant controlled permissions to specific data objects for a specific amount of time.

Daarnaast kunt u voor Blob Storage open bare toegang tot uw blobs toestaan door het toegangs niveau in te stellen voor de container die de blobs dienovereenkomstig bevat.In addition, for Blob Storage, you can allow public access to your blobs by setting the access level for the container that holds the blobs accordingly. Als u de toegang voor een container instelt op BLOB of container, wordt open bare Lees toegang voor de blobs in die container toegestaan.If you set access for a container to Blob or Container, it will allow public read access for the blobs in that container. Dit betekent dat iedereen met een URL die verwijst naar een BLOB in die container deze kan openen in een browser zonder gebruik te maken van een Shared Access Signature of de sleutels voor het opslag account.This means anyone with a URL pointing to a blob in that container can open it in a browser without using a Shared Access Signature or having the storage account keys.

Naast het beperken van de toegang via autorisatie, kunt u ook firewalls en virtuele netwerken gebruiken om de toegang tot het opslag account te beperken op basis van netwerk regels.In addition to limiting access through authorization, you can also use Firewalls and Virtual Networks to limit access to the storage account based on network rules. Met deze aanpak kunt u de toegang weigeren voor openbaar Internet verkeer en alleen toegang verlenen aan specifieke Azure Virtual Networks of open bare IP-adresbereiken voor Internet.This approach enables you deny access to public internet traffic, and to grant access only to specific Azure Virtual Networks or public internet IP address ranges.

OpslagaccountsleutelsStorage Account Keys

Sleutels voor opslag accounts zijn 512-bits teken reeksen die zijn gemaakt door Azure en die samen met de naam van het opslag account kunnen worden gebruikt voor toegang tot de gegevens objecten die zijn opgeslagen in het opslag account.Storage account keys are 512-bit strings created by Azure that, along with the storage account name, can be used to access the data objects stored in the storage account.

U kunt bijvoorbeeld blobs lezen, schrijven naar wacht rijen, tabellen maken en bestanden wijzigen.For example, you can read blobs, write to queues, create tables, and modify files. Veel van deze acties kunnen worden uitgevoerd via de Azure Portal, of een van de vele Storage Explorer toepassingen gebruiken.Many of these actions can be performed through the Azure portal, or using one of many Storage Explorer applications. U kunt ook code schrijven om de REST API of een van de opslag-client bibliotheken te gebruiken om deze bewerkingen uit te voeren.You can also write code to use the REST API or one of the Storage Client Libraries to perform these operations.

Zoals besproken in de sectie over de beveiliging van het beheer vlak, kan toegang tot de opslag sleutels voor een klassiek opslag account worden verleend door volledige toegang te geven tot het Azure-abonnement.As discussed in the section on the Management Plane Security, access to the storage keys for a Classic storage account can be granted by giving full access to the Azure subscription. Toegang tot de opslag sleutels voor een opslag account met behulp van het Azure Resource Manager model kan worden beheerd via op rollen gebaseerde Access Control (RBAC).Access to the storage keys for a storage account using the Azure Resource Manager model can be controlled through Role-Based Access Control (RBAC).

Toegang tot objecten in uw account delegeren met behulp van hand tekeningen voor gedeelde toegang en opgeslagen toegangs beleidHow to delegate access to objects in your account using Shared Access Signatures and Stored Access Policies

Een Shared Access Signature is een teken reeks met een beveiligings token dat kan worden gekoppeld aan een URI, waarmee u de toegang tot opslag objecten kunt delegeren en beperkingen kunt opgeven, zoals de machtigingen en het datum-en tijd bereik van de toegang.A Shared Access Signature is a string containing a security token that can be attached to a URI that allows you to delegate access to storage objects and specify constraints such as the permissions and the date/time range of access.

U kunt toegang verlenen tot blobs, containers, wachtrij berichten, bestanden en tabellen.You can grant access to blobs, containers, queue messages, files, and tables. Met tabellen kunt u daad werkelijk toegangs rechten verlenen voor een bereik van entiteiten in de tabel door de partitie en het bereik van de rij op te geven waartoe u wilt dat de gebruiker toegang heeft.With tables, you can actually grant permission to access a range of entities in the table by specifying the partition and row key ranges to which you want the user to have access. Als u bijvoorbeeld gegevens hebt opgeslagen met een partitie sleutel van een geografische status, kunt u iemand toegang geven tot alleen de gegevens voor Californië.For example, if you have data stored with a partition key of geographical state, you could give someone access to just the data for California.

In een ander voor beeld kunt u een webtoepassing een SAS-token geven waarmee gegevens naar een wachtrij kunnen worden geschreven, en waarmee een rol van werk rollen een SAS-token kan geven om berichten uit de wachtrij op te halen en te verwerken.In another example, you might give a web application a SAS token that enables it to write entries to a queue, and give a worker role application a SAS token to get messages from the queue and process them. Of u kunt een klant een SAS-token geven waarmee ze afbeeldingen kunnen uploaden naar een container in Blob Storage en een webtoepassing machtigen om deze afbeeldingen te lezen.Or you could give one customer a SAS token they can use to upload pictures to a container in Blob Storage, and give a web application permission to read those pictures. In beide gevallen is er sprake van een schei ding van de bezorgdheid: elke toepassing kan alleen de toegang krijgen die ze nodig hebben om hun taak uit te voeren.In both cases, there is a separation of concerns – each application can be given just the access that they require in order to perform their task. Dit is mogelijk via het gebruik van hand tekeningen voor gedeelde toegang.This is possible through the use of Shared Access Signatures.

Waarom u gedeelde toegangs handtekeningen wilt gebruikenWhy you want to use Shared Access Signatures

Waarom zou u een SAS wilt gebruiken in plaats van de sleutel van uw opslag account, wat zo veel eenvoudiger is?Why would you want to use an SAS instead of just giving out your storage account key, which is so much easier? Het geven van de sleutel van uw opslag account is hetzelfde als het delen van de sleutels van uw opslag-Konink rijk.Giving out your storage account key is like sharing the keys of your storage kingdom. Hiermee wordt volledige toegang verleend.It grants complete access. Iemand kan uw sleutels gebruiken en hun hele muziek bibliotheek uploaden naar uw opslag account.Someone could use your keys and upload their entire music library to your storage account. Ze kunnen uw bestanden ook vervangen door virussen geïnfecteerde versies of uw gegevens stelen.They could also replace your files with virus-infected versions, or steal your data. Het is niet nodig om onbeperkte toegang te geven tot uw opslag account.Giving away unlimited access to your storage account is something that should not be taken lightly.

Met Shared Access signatures kunt u een client alleen de machtigingen geven die vereist zijn voor een beperkte periode.With Shared Access Signatures, you can give a client just the permissions required for a limited amount of time. Als iemand bijvoorbeeld een BLOB uploadt naar uw account, kunt u hen schrijf toegang geven voor genoeg tijd om de BLOB te uploaden (afhankelijk van de grootte van de blob, natuurlijk).For example, if someone is uploading a blob to your account, you can grant them write access for just enough time to upload the blob (depending on the size of the blob, of course). En als u van gedachten verandert, kunt u die toegang intrekken.And if you change your mind, you can revoke that access.

Daarnaast kunt u opgeven dat aanvragen die worden gedaan met behulp van een SAS, beperkt zijn tot een bepaald IP-adres of IP-adres bereik dat extern is voor Azure.Additionally, you can specify that requests made using a SAS are restricted to a certain IP address or IP address range external to Azure. U kunt ook vereisen dat aanvragen worden gedaan met behulp van een specifiek protocol (HTTPS of HTTP/HTTPS).You can also require that requests are made using a specific protocol (HTTPS or HTTP/HTTPS). Dit betekent dat als u alleen HTTPS-verkeer wilt toestaan, u het vereiste protocol alleen op HTTPS kunt instellen en het HTTP-verkeer wordt geblokkeerd.This means if you only want to allow HTTPS traffic, you can set the required protocol to HTTPS only, and HTTP traffic will be blocked.

Definitie van een Shared Access SignatureDefinition of a Shared Access Signature

Een Shared Access Signature is een reeks query parameters die zijn toegevoegd aan de URL die op de resource is gerichtA Shared Access Signature is a set of query parameters appended to the URL pointing at the resource

Dit geeft informatie over de toegang die is toegestaan en de tijds duur waarvoor de toegang is toegestaan.that provides information about the access allowed and the length of time for which the access is permitted. Hier volgt een voor beeld. deze URI biedt vijf minuten Lees toegang tot een blob.Here is an example; this URI provides read access to a blob for five minutes. Houd er rekening mee dat SAS-query parameters een URL-code ring moeten hebben, zoals% 3A voor dubbele punt (:) of% 20 voor een spatie.Note that SAS query parameters must be URL Encoded, such as %3A for colon (:) or %20 for a space.

http://mystorage.blob.core.windows.net/mycontainer/myblob.txt (URL to the blob)
?sv=2015-04-05 (storage service version)
&st=2015-12-10T22%3A18%3A26Z (start time, in UTC time and URL encoded)
&se=2015-12-10T22%3A23%3A26Z (end time, in UTC time and URL encoded)
&sr=b (resource is a blob)
&sp=r (read access)
&sip=168.1.5.60-168.1.5.70 (requests can only come from this range of IP addresses)
&spr=https (only allow HTTPS requests)
&sig=Z%2FRHIX5Xcg0Mq2rqI3OlWTjEg2tYkboXr1P9ZUXDtkk%3D (signature used for the authentication of the SAS)

Hoe de Shared Access Signature wordt geautoriseerd door de Azure Storage-serviceHow the Shared Access Signature is authorized by the Azure Storage Service

Wanneer de opslag service de aanvraag ontvangt, worden de para meters voor invoer query's gebruikt en wordt er een hand tekening gemaakt met dezelfde methode als het aanroepende programma.When the storage service receives the request, it takes the input query parameters and creates a signature using the same method as the calling program. Vervolgens worden de twee hand tekeningen vergeleken.It then compares the two signatures. Als ze overeenkomen, kan de opslag service de versie van de opslag service controleren om ervoor te zorgen dat deze geldig is. Controleer of de huidige datum en tijd binnen het opgegeven venster vallen, Controleer of de toegang is aangevraagd met de aangevraagde aanvraag, enzovoort.If they agree, then the storage service can check the storage service version to make sure it's valid, verify that the current date and time are within the specified window, make sure the access requested corresponds to the request made, etc.

Als bijvoorbeeld met onze URL hierboven wordt verwezen naar een bestand in plaats van een blob, zou deze aanvraag mislukken omdat het Shared Access Signature is voor een blob.For example, with our URL above, if the URL was pointing to a file instead of a blob, this request would fail because it specifies that the Shared Access Signature is for a blob. Als de REST-opdracht die wordt aangeroepen om een BLOB bij te werken, mislukt dit omdat de Shared Access Signature opgeeft dat alleen lees toegang is toegestaan.If the REST command being called was to update a blob, it would fail because the Shared Access Signature specifies that only read access is permitted.

Typen Shared Access signaturesTypes of Shared Access Signatures

  • Een SAS op service niveau kan worden gebruikt om toegang te krijgen tot specifieke bronnen in een opslag account.A service-level SAS can be used to access specific resources in a storage account. Enkele voor beelden hiervan zijn het ophalen van een lijst met blobs in een container, het downloaden van een blob, het bijwerken van een entiteit in een tabel, het toevoegen van berichten aan een wachtrij of het uploaden van een bestand naar een bestands share.Some examples of this are retrieving a list of blobs in a container, downloading a blob, updating an entity in a table, adding messages to a queue, or uploading a file to a file share.
  • Een SAS op account niveau kan worden gebruikt om toegang te krijgen tot alles waar een SAS op service niveau kan worden gebruikt.An account-level SAS can be used to access anything that a service-level SAS can be used for. Daarnaast kan het opties bieden voor bronnen die niet zijn toegestaan met een SAS op service niveau, zoals de mogelijkheid om containers, tabellen, wacht rijen en bestands shares te maken.Additionally, it can give options to resources that are not permitted with a service-level SAS, such as the ability to create containers, tables, queues, and file shares. U kunt ook toegang tot meerdere services tegelijk opgeven.You can also specify access to multiple services at once. U kunt bijvoorbeeld iemand toegang geven tot blobs en bestanden in uw opslag account.For example, you might give someone access to both blobs and files in your storage account.

Een SAS-URI makenCreating a SAS URI

  1. U kunt op aanvraag een URI maken, waarbij alle query parameters elke keer worden gedefinieerd.You can create a URI on demand, defining all of the query parameters each time.

    Deze aanpak is flexibel, maar als u een logische set para meters hebt die vergelijkbaar zijn, is het gebruik van een opgeslagen toegangs beleid een beter idee.This approach is flexible, but if you have a logical set of parameters that are similar each time, using a Stored Access Policy is a better idea.

  2. U kunt een opgeslagen toegangs beleid maken voor een volledige container, een bestands share, een tabel of een wachtrij.You can create a Stored Access Policy for an entire container, file share, table, or queue. Vervolgens kunt u deze gebruiken als basis voor de SAS-Uri's die u maakt.Then you can use this as the basis for the SAS URIs you create. Machtigingen op basis van opgeslagen toegangs beleid kunnen eenvoudig worden ingetrokken.Permissions based on Stored Access Policies can be easily revoked. U kunt Maxi maal vijf beleids regels definiëren voor elke container, wachtrij, tabel of bestands share.You can have up to five policies defined on each container, queue, table, or file share.

    Als u bijvoorbeeld veel mensen de blobs in een specifieke container zou lezen, kunt u een opgeslagen toegangs beleid maken met de tekst ' Lees toegang geven ' en alle andere instellingen die elke keer hetzelfde zullen zijn.For example, if you were going to have many people read the blobs in a specific container, you could create a Stored Access Policy that says "give read access" and any other settings that will be the same each time. Vervolgens kunt u een SAS-URI maken met behulp van de instellingen van het beleid voor opgeslagen toegang en de verval datum/-tijd opgeven.Then you can create an SAS URI using the settings of the Stored Access Policy and specifying the expiration date/time. Het voor deel hiervan is dat u niet alle query parameters hoeft op te geven.The advantage of this is that you don't have to specify all of the query parameters every time.

IntrekkingsRevocation

Stel dat uw SAS heeft geknoeid of dat u deze wilt wijzigen vanwege de vereisten voor de beveiligings-of regelgeving van het bedrijf.Suppose your SAS has been compromised, or you want to change it because of corporate security or regulatory compliance requirements. Hoe trekt u de toegang tot een resource in met behulp van die SAS?How do you revoke access to a resource using that SAS? Dit is afhankelijk van hoe u de SAS-URI hebt gemaakt.It depends on how you created the SAS URI.

Als u ad hoc-Uri's gebruikt, hebt u drie opties.If you are using ad hoc URIs, you have three options. U kunt SAS-tokens met een kort verval beleid uitgeven en wachten tot de SA'S verlopen.You can issue SAS tokens with short expiration policies and wait for the SAS to expire. U kunt de naam van de resource wijzigen of verwijderen (ervan uitgaande dat het token aan een enkel object is toegewezen).You can rename or delete the resource (assuming the token was scoped to a single object). U kunt de sleutel van het opslag account wijzigen.You can change the storage account keys. Deze laatste optie kan aanzienlijke gevolgen hebben, afhankelijk van het aantal services dat het opslag account gebruikt en waarschijnlijk niet iets dat u wilt doen zonder enige planning.This last option can have a significant impact, depending on how many services are using that storage account, and probably isn't something you want to do without some planning.

Als u een SAS gebruikt die is afgeleid van een opgeslagen toegangs beleid, kunt u de toegang verwijderen door het opgeslagen toegangs beleid in te trekken. u kunt dit gewoon wijzigen zodat het al is verlopen of u kunt het helemaal verwijderen.If you are using a SAS derived from a Stored Access Policy, you can remove access by revoking the Stored Access Policy – you can just change it so it has already expired, or you can remove it altogether. Dit wordt onmiddellijk van kracht en alle SA'S die zijn gemaakt met behulp van het beleid voor opgeslagen toegang, worden ongeldig.This takes effect immediately, and invalidates every SAS created using that Stored Access Policy. Het bijwerken of verwijderen van het beleid voor opgeslagen toegang kan van invloed zijn op de toegang tot deze specifieke container, bestands share, tabel of wachtrij via SAS, maar als de clients zijn geschreven zodat ze een nieuwe SAS aanvragen wanneer de oude ongeldig wordt, werkt dit prima.Updating or removing the Stored Access Policy may impact people accessing that specific container, file share, table, or queue via SAS, but if the clients are written so they request a new SAS when the old one becomes invalid, this will work fine.

Omdat het gebruik van een SAS die is afgeleid van een opgeslagen toegangs beleid, u de mogelijkheid biedt om die SA'S onmiddellijk in te trekken, is het de aanbevolen best practice om altijd opgeslagen toegangs beleid te gebruiken wanneer dat mogelijk is.Because using a SAS derived from a Stored Access Policy gives you the ability to revoke that SAS immediately, it is the recommended best practice to always use Stored Access Policies when possible.

ResourcesResources

Raadpleeg de volgende artikelen voor meer informatie over het gebruik van hand tekeningen voor gedeelde toegang en opgeslagen toegangs beleid:For more detailed information on using Shared Access Signatures and Stored Access Policies, complete with examples, refer to the following articles:

Versleuteling in transitEncryption in Transit

Versleuteling op transport niveau: HTTPS gebruikenTransport-Level Encryption – Using HTTPS

Een andere stap die u moet uitvoeren om ervoor te zorgen dat uw Azure Storage gegevens worden beveiligd door de gegevens te versleutelen tussen de client en Azure Storage.Another step you should take to ensure the security of your Azure Storage data is to encrypt the data between the client and Azure Storage. De eerste aanbeveling is altijd het https -protocol te gebruiken. Dit zorgt voor beveiligde communicatie via het open bare Internet.The first recommendation is to always use the HTTPS protocol, which ensures secure communication over the public Internet.

Als u een beveiligd communicatie kanaal wilt, moet u altijd HTTPS gebruiken bij het aanroepen van de REST-Api's of het openen van objecten in de opslag.To have a secure communication channel, you should always use HTTPS when calling the REST APIs or accessing objects in storage. Ook gedeelde toegangs handtekeningen, die kunnen worden gebruikt voor het delegeren van toegang tot Azure Storage-objecten, bevatten een optie om op te geven dat alleen het HTTPS-protocol kan worden gebruikt bij het gebruik van hand tekeningen voor gedeelde toegang, zodat iedereen koppelingen met SAS-tokens kan verzenden maakt gebruik van het juiste protocol.Also, Shared Access Signatures, which can be used to delegate access to Azure Storage objects, include an option to specify that only the HTTPS protocol can be used when using Shared Access Signatures, ensuring that anybody sending out links with SAS tokens will use the proper protocol.

U kunt het gebruik van HTTPS afdwingen bij het aanroepen van de REST-Api's om toegang te krijgen tot objecten in opslag accounts door beveiligde overdracht in te scha kelen die vereist is voor het opslag account.You can enforce the use of HTTPS when calling the REST APIs to access objects in storage accounts by enabling Secure transfer required for the storage account. Verbindingen die gebruikmaken van HTTP, worden geweigerd als deze functie is ingeschakeld.Connections using HTTP will be refused once this is enabled.

Versleuteling gebruiken tijdens de overdracht met Azure-bestands sharesUsing encryption during transit with Azure file shares

Azure files ondersteunt VERSLEUTELING via SMB 3,0 en met https bij gebruik van de bestands rest API.Azure Files supports encryption via SMB 3.0 and with HTTPS when using the File REST API. Bij het koppelen buiten de Azure-regio is de Azure-bestands share aanwezig in, zoals on-premises of in een andere Azure-regio, SMB 3,0 met versleuteling altijd vereist.When mounting outside of the Azure region the Azure file share is located in, such as on-premises or in another Azure region, SMB 3.0 with encryption is always required. SMB 2,1 biedt geen ondersteuning voor versleuteling, daarom zijn standaard verbindingen alleen toegestaan binnen dezelfde regio in azure, maar SMB 3,0 met versleuteling kan worden afgedwongen door een veilige overdracht te vereisen voor het opslag account.SMB 2.1 does not support encryption, so by default connections are only allowed within the same region in Azure, but SMB 3.0 with encryption can be enforced by requiring secure transfer for the storage account.

SMB 3,0 met versleuteling is beschikbaar in alle ondersteunde Windows-en Windows Server-besturings systemen , met uitzonde ring van Windows 7 en windows server 2008 R2, die alleen ondersteuning bieden voor SMB 2,1.SMB 3.0 with encryption is available in all supported Windows and Windows Server operating systems except Windows 7 and Windows Server 2008 R2, which only support SMB 2.1. SMB 3,0 wordt ook ondersteund op macOS en distributies van Linux met Linux kernel 4,11 en hoger.SMB 3.0 is also supported on macOS and on distributions of Linux using Linux kernel 4.11 and above. De ondersteuning voor versleuteling voor SMB 3,0 is ook backported aan oudere versies van de Linux-kernel door diverse Linux-distributies. Raadpleeg de vereisten van SMB-clientsvoor meer informatie.Encryption support for SMB 3.0 has also been backported to older versions of the Linux kernel by several Linux distributions, consult Understanding SMB client requirements.

De beveiliging van gegevens die u naar de opslag stuurt, beveiligen met behulp van versleuteling aan de client zijdeUsing Client-side encryption to secure data that you send to storage

Een andere optie waarmee u ervoor kunt zorgen dat uw gegevens veilig zijn terwijl ze worden overgedragen tussen een client toepassing en opslag is versleuteling aan de client zijde.Another option that helps you ensure that your data is secure while being transferred between a client application and Storage is Client-side Encryption. De gegevens worden versleuteld voordat ze naar Azure Storage worden overgebracht.The data is encrypted before being transferred into Azure Storage. Bij het ophalen van de gegevens uit Azure Storage worden de gegevens ontsleuteld nadat deze zijn ontvangen aan de client zijde.When retrieving the data from Azure Storage, the data is decrypted after it is received on the client side. Hoewel de gegevens worden versleuteld over het hele netwerk, raden we u aan om ook HTTPS te gebruiken, aangezien er controles voor de integriteit van gegevens zijn ingebouwd, waardoor netwerk fouten die van invloed zijn op de integriteit van de gegevens worden verholpen.Even though the data is encrypted going across the wire, we recommend that you also use HTTPS, as it has data integrity checks built in which help mitigate network errors affecting the integrity of the data.

Versleuteling aan de client zijde is ook een methode voor het versleutelen van uw gegevens in rust tijd, omdat de gegevens worden opgeslagen in de versleutelde vorm.Client-side encryption is also a method for encrypting your data at rest, as the data is stored in its encrypted form. Verderop in dit onderwerp vindt u meer informatie over versleuteling in rust.We'll talk about this in more detail in the section on Encryption at Rest.

Versleuteling bij restEncryption at Rest

Er zijn drie Azure-functies die versleuteling bieden bij rest.There are three Azure features that provide encryption at rest. Azure Disk Encryption wordt gebruikt voor het versleutelen van het besturings systeem en de gegevens schijven in IaaS Virtual Machines.Azure Disk Encryption is used to encrypt the OS and data disks in IaaS Virtual Machines. Versleuteling aan client zijde en SSE worden beide gebruikt voor het versleutelen van gegevens in Azure Storage.Client-side Encryption and SSE are both used to encrypt data in Azure Storage.

Hoewel u versleuteling aan de client zijde kunt gebruiken voor het versleutelen van de gegevens die onderweg zijn (die ook in de versleutelde vorm worden opgeslagen in de opslag), kunt u de voor keur geven aan HTTPS tijdens de overdracht en een zekere manier hebben om de gegevens automatisch te versleutelen wanneer deze worden opgeslagen.While you can use Client-side Encryption to encrypt the data in transit (which is also stored in its encrypted form in Storage), you may prefer to use HTTPS during the transfer, and have some way for the data to be automatically encrypted when it is stored. Er zijn twee manieren om dit te doen: Azure Disk Encryption en SSE.There are two ways to do this -- Azure Disk Encryption and SSE. Er wordt een code ring gebruikt voor het rechtstreeks versleutelen van gegevens op besturings systeem en gegevens schijven die worden gebruikt door Vm's, en de andere wordt gebruikt voor het versleutelen van gegevens die zijn geschreven naar Azure Blob Storage.One is used to directly encrypt the data on OS and data disks used by VMs, and the other is used to encrypt data written to Azure Blob Storage.

Storage Service Encryption (SSE)Storage Service Encryption (SSE)

SSE is ingeschakeld voor alle opslag accounts en kan niet worden uitgeschakeld.SSE is enabled for all storage accounts and cannot be disabled. Met SSE worden uw gegevens automatisch versleuteld wanneer deze naar Azure Storage worden geschreven.SSE automatically encrypts your data when writing it to Azure Storage. Wanneer u gegevens uit Azure Storage leest, wordt deze door Azure Storage ontsleuteld voordat ze worden geretourneerd.When you read data from Azure Storage, it is decrypted by Azure Storage before being returned. Met SSE kunt u uw gegevens beveiligen zonder dat u code hoeft te wijzigen of code aan toepassingen hoeft toe te voegen.SSE enables you to secure your data without having to modify code or add code to any applications.

U kunt door micro soft beheerde sleutels of uw eigen aangepaste sleutels gebruiken.You can use either Microsoft-managed keys or your own custom keys. Micro soft genereert beheerde sleutels en verwerkt hun beveiligde opslag en de normale rotatie, zoals gedefinieerd door intern micro soft-beleid.Microsoft generates managed keys and handles their secure storage as well as their regular rotation, as defined by internal Microsoft policy. Zie Storage service Encryption het gebruik van door de klant beheerde sleutels in azure Key Vaultvoor meer informatie over het gebruik van aangepaste sleutels.For more information about using custom keys, see Storage Service Encryption using customer-managed keys in Azure Key Vault.

SSE versleutelt automatisch gegevens in alle prestatielagen (Standaard en Premium), alle implementatiemodellen (Azure Resource Manager en het klassieke model) en alle services van Azure Storage (Blob, Queue, Table en File).SSE automatically encrypts data in all performance tiers (Standard and Premium), all deployment models (Azure Resource Manager and Classic), and all of the Azure Storage services (Blob, Queue, Table, and File).

Versleuteling aan client zijdeClient-side Encryption

We hebben versleuteling aan de client zijde vermeld bij het bespreken van de versleuteling van de gegevens die onderweg zijn.We mentioned client-side encryption when discussing the encryption of the data in transit. Met deze functie kunt u uw gegevens in een client toepassing programmatisch versleutelen voordat u deze verzendt over de draden die moeten worden geschreven naar Azure Storage en kunt u uw gegevens programmatisch ontsleutelen nadat u deze hebt opgehaald van Azure Storage.This feature allows you to programmatically encrypt your data in a client application before sending it across the wire to be written to Azure Storage, and to programmatically decrypt your data after retrieving it from Azure Storage.

Dit voorziet in het door voeren van versleuteling, maar biedt ook de mogelijkheid om op rest te versleutelen.This does provide encryption in transit, but it also provides the feature of Encryption at Rest. Hoewel de gegevens tijdens de overdracht worden versleuteld, raden we u aan HTTPS te gebruiken om te profiteren van de ingebouwde gegevens integriteits controles die de netwerk fouten helpen beperken die van invloed zijn op de integriteit van de gegevens.Although the data is encrypted in transit, we still recommend using HTTPS to take advantage of the built-in data integrity checks that help mitigate network errors affecting the integrity of the data.

Een voor beeld van waar u dit kunt doen, is als u een webtoepassing hebt waarmee blobs worden opgeslagen en blobs worden opgehaald, en u de toepassing en gegevens zo veilig mogelijk wilt maken.An example of where you might use this is if you have a web application that stores blobs and retrieves blobs, and you want the application and data to be as secure as possible. In dat geval gebruikt u versleuteling aan de client zijde.In that case, you would use client-side encryption. Het verkeer tussen de client en de Azure Blob-service bevat de versleutelde resource en niemand kan de gegevens in de overdracht interpreteren en opnieuw samen brengen in uw persoonlijke blobs.The traffic between the client and the Azure Blob Service contains the encrypted resource, and nobody can interpret the data in transit and reconstitute it into your private blobs.

Versleuteling aan client zijde is ingebouwd in de Java-en de .NET Storage-client Bibliotheken, die op hun beurt gebruikmaken van de Azure Key Vault Api's, zodat u deze eenvoudig kunt implementeren.Client-side encryption is built into the Java and the .NET storage client libraries, which in turn use the Azure Key Vault APIs, making it easy for you to implement. Het proces voor het versleutelen en ontsleutelen van de gegevens maakt gebruik van de envelop techniek en slaat meta gegevens op die worden gebruikt door de versleuteling in elk opslag object.The process of encrypting and decrypting the data uses the envelope technique, and stores metadata used by the encryption in each storage object. Voor blobs wordt deze bijvoorbeeld opgeslagen in de BLOB-meta gegevens, maar voor wacht rijen, wordt deze toegevoegd aan elk wachtrij bericht.For example, for blobs, it stores it in the blob metadata, while for queues, it adds it to each queue message.

Voor de versleuteling zelf kunt u uw eigen versleutelings sleutels genereren en beheren.For the encryption itself, you can generate and manage your own encryption keys. U kunt ook sleutels gebruiken die worden gegenereerd door de Azure Storage-client bibliotheek, of u kunt de sleutels laten genereren door de Azure Key Vault.You can also use keys generated by the Azure Storage Client Library, or you can have the Azure Key Vault generate the keys. U kunt uw versleutelings sleutels opslaan in uw on-premises sleutel opslag of u kunt deze opslaan in een Azure Key Vault.You can store your encryption keys in your on-premises key storage, or you can store them in an Azure Key Vault. Met Azure Key Vault kunt u toegang verlenen tot de geheimen in Azure Key Vault voor specifieke gebruikers die Azure Active Directory gebruiken.Azure Key Vault allows you to grant access to the secrets in Azure Key Vault to specific users using Azure Active Directory. Dit betekent dat niet alleen iedereen de Azure Key Vault kan lezen en de sleutels kan ophalen die u gebruikt voor versleuteling aan de client zijde.This means that not just anybody can read the Azure Key Vault and retrieve the keys you're using for client-side encryption.

ResourcesResources

Schijven die worden gebruikt door uw virtuele machines versleutelen met behulp van Azure Disk EncryptionUsing Azure Disk Encryption to encrypt disks used by your virtual machines

Met Azure Disk Encryption kunt u de stations van het besturings systeem en de gegevens schijven die worden gebruikt door een virtuele machine van IaaS versleutelen.Azure Disk Encryption allows you to encrypt the OS disks and Data disks used by an IaaS Virtual Machine. Voor Windows worden de stations versleuteld met de standaard BitLocker-versleutelings technologie.For Windows, the drives are encrypted using industry-standard BitLocker encryption technology. Voor Linux worden de schijven versleuteld met de DM-cryptografie technologie.For Linux, the disks are encrypted using the DM-Crypt technology. Dit is geïntegreerd met Azure Key Vault zodat u de schijf versleutelings sleutels kunt beheren en beheren.This is integrated with Azure Key Vault to allow you to control and manage the disk encryption keys.

De oplossing ondersteunt de volgende scenario's voor IaaS Vm's wanneer deze zijn ingeschakeld in Microsoft Azure:The solution supports the following scenarios for IaaS VMs when they are enabled in Microsoft Azure:

  • Integratie met Azure Key VaultIntegration with Azure Key Vault
  • Vm's van de Standard-laag: A, D, DS, G, GS, en dergelijke Series IaaS Vm'sStandard tier VMs: A, D, DS, G, GS, and so forth series IaaS VMs
  • Versleuteling inschakelen op Windows-en Linux IaaS-Vm'sEnabling encryption on Windows and Linux IaaS VMs
  • Versleuteling uitschakelen voor besturings systeem en gegevens stations voor Windows IaaS-Vm'sDisabling encryption on OS and data drives for Windows IaaS VMs
  • Versleuteling uitschakelen op gegevens stations voor Linux IaaS Vm'sDisabling encryption on data drives for Linux IaaS VMs
  • Versleuteling inschakelen voor IaaS-Vm's waarop Windows client-besturings systeem wordt uitgevoerdEnabling encryption on IaaS VMs that are running Windows client OS
  • Versleuteling inschakelen voor volumes met koppel padenEnabling encryption on volumes with mount paths
  • Versleuteling inschakelen voor Linux-Vm's die zijn geconfigureerd met schijf striping (RAID) met behulp van mdadmEnabling encryption on Linux VMs that are configured with disk striping (RAID) by using mdadm
  • Versleuteling inschakelen op virtuele Linux-machines met behulp van LVM voor gegevens schijvenEnabling encryption on Linux VMs by using LVM for data disks
  • Versleuteling inschakelen op Windows-Vm's die zijn geconfigureerd met behulp van opslag ruimtenEnabling encryption on Windows VMs that are configured by using storage spaces
  • Alle open bare Azure-regio's worden ondersteundAll Azure public regions are supported

De oplossing biedt geen ondersteuning voor de volgende scenario's, functies en technologie in de release:The solution does not support the following scenarios, features, and technology in the release:

  • IaaS-Vm's voor de Basic-laagBasic tier IaaS VMs
  • Versleuteling uitschakelen op een OS-station voor Linux IaaS Vm'sDisabling encryption on an OS drive for Linux IaaS VMs
  • IaaS-Vm's die worden gemaakt met behulp van de klassieke methode voor het maken van VM'SIaaS VMs that are created by using the classic VM creation method
  • Integratie met uw on-premises sleutel beheer serviceIntegration with your on-premises Key Management Service
  • Azure Files (gedeeld bestands systeem), NFS (Network File System), dynamische volumes en Windows-Vm's die zijn geconfigureerd met RAID-systemen op basis van softwareAzure Files (shared file system), Network File System (NFS), dynamic volumes, and Windows VMs that are configured with software-based RAID systems

Notitie

Versleuteling van Linux-besturingssysteem schijf wordt momenteel ondersteund in de volgende Linux-distributies: RHEL 7,2, CentOS 7,2 n en Ubuntu 16,04.Linux OS disk encryption is currently supported on the following Linux distributions: RHEL 7.2, CentOS 7.2n, and Ubuntu 16.04.

Deze functie zorgt ervoor dat alle gegevens op de schijven van de virtuele machine in de rest van Azure Storage zijn versleuteld.This feature ensures that all data on your virtual machine disks is encrypted at rest in Azure Storage.

ResourcesResources

Vergelijking van Azure Disk Encryption, SSE en versleuteling aan de client zijdeComparison of Azure Disk Encryption, SSE, and Client-Side Encryption

IaaS Vm's en hun VHD-bestandenIaaS VMs and their VHD files

Voor gegevens schijven die worden gebruikt door IaaS Vm's, wordt Azure Disk Encryption aanbevolen.For data disks used by IaaS VMs, Azure Disk Encryption is recommended. Als u een virtuele machine met onbeheerde schijven maakt met behulp van een installatie kopie van Azure Marketplace, voert Azure een beschik bare kopie van de installatie kopie naar uw opslag account in azure Storage en is deze niet versleuteld, zelfs als u SSE hebt ingeschakeld.If you create a VM with unmanaged disks using an image from the Azure Marketplace, Azure performs a shallow copy of the image to your storage account in Azure Storage, and it is not encrypted even if you have SSE enabled. Nadat de virtuele machine is gemaakt en de installatie kopie is bijgewerkt, begint SSE met het versleutelen van de gegevens.After it creates the VM and starts updating the image, SSE will start encrypting the data. Daarom kunt u het beste Azure Disk Encryption gebruiken op Vm's met niet-beheerde schijven die zijn gemaakt op basis van installatie kopieën in de Azure Marketplace als u deze volledig versleuteld wilt maken.For this reason, it's best to use Azure Disk Encryption on VMs with unmanaged disks created from images in the Azure Marketplace if you want them fully encrypted. Als u een virtuele machine met Managed Disks maakt, versleutelt SSE alle gegevens standaard met behulp van door het platform beheerde sleutels.If you create a VM with Managed Disks, SSE encrypts all the data by default using platform managed keys.

Als u van on-premises een vooraf versleutelde virtuele machine in azure brengt, kunt u de versleutelings sleutels naar Azure Key Vault uploaden en de versleuteling voor die virtuele machine die u on-premises gebruikt, blijven gebruiken.If you bring a pre-encrypted VM into Azure from on-premises, you will be able to upload the encryption keys to Azure Key Vault, and continue using the encryption for that VM that you were using on-premises. Azure Disk Encryption is ingeschakeld om dit scenario af te handelen.Azure Disk Encryption is enabled to handle this scenario.

Als u een niet-versleutelde VHD van on-premises hebt, kunt u deze uploaden naar de galerie als een aangepaste installatie kopie en hiervan een virtuele machine inrichten.If you have non-encrypted VHD from on-premises, you can upload it into the gallery as a custom image and provision a VM from it. Als u dit doet met behulp van de Resource Manager-sjablonen, kunt u deze vragen om Azure Disk Encryption in te scha kelen wanneer de virtuele machine wordt opgestart.If you do this using the Resource Manager templates, you can ask it to turn on Azure Disk Encryption when it boots up the VM.

Wanneer u een gegevens schijf toevoegt en koppelt aan de virtuele machine, kunt u Azure Disk Encryption op die gegevens schijf inschakelen.When you add a data disk and mount it on the VM, you can turn on Azure Disk Encryption on that data disk. De gegevens schijf wordt lokaal eerst versleuteld en vervolgens wordt de laag van het klassieke implementatie model een langzame schrijf bewerking voor de opslag, zodat de opslag inhoud wordt versleuteld.It will encrypt that data disk locally first, and then the classic deployment model layer will do a lazy write against storage so the storage content is encrypted.

ClientversleutelingClient-side encryption

Versleuteling aan de client zijde is de veiligste methode voor het versleutelen van uw gegevens, omdat deze gegevens versleutelt vóór de door voer.Client-side encryption is the most secure method of encrypting your data, because it encrypts data prior to transit. Hiervoor moet u echter wel code toevoegen aan uw toepassingen met behulp van opslag, wat u mogelijk niet wilt.However, it does require that you add code to your applications using storage, which you may not want to do. In dergelijke gevallen kunt u HTTPS gebruiken om uw gegevens in transit te beveiligen.In those cases, you can use HTTPS to secure your data in transit. Zodra de gegevens Azure Storage bereikt, wordt deze door SSE versleuteld.Once data reaches Azure Storage, it is encrypted by SSE.

Met versleuteling aan de client zijde kunt u tabel entiteiten, wachtrij berichten en blobs versleutelen.With client-side encryption, you can encrypt table entities, queue messages, and blobs.

Versleuteling aan de client zijde wordt volledig door de toepassing beheerd.Client-side encryption is managed entirely by the application. Dit is de veiligste benadering, maar u moet wel programmatisch wijzigingen aanbrengen in uw toepassing en de belangrijkste beheer processen plaatsen.This is the most secure approach, but does require you to make programmatic changes to your application and put key management processes in place. U gebruikt dit wanneer u de extra beveiliging tijdens de overdracht wilt gebruiken en u wilt dat de opgeslagen gegevens worden versleuteld.You would use this when you want the extra security during transit, and you want your stored data to be encrypted.

Versleuteling aan de client zijde is meer belasting op de client en u moet hiervoor rekening met uw schaalbaarheids plannen, met name als u een grote hoeveelheid gegevens versleutelt en overdraagt.Client-side encryption is more load on the client, and you have to account for this in your scalability plans, especially if you are encrypting and transferring a large amount of data.

Storage Service Encryption (SSE)Storage Service Encryption (SSE)

SSE wordt beheerd door Azure Storage.SSE is managed by Azure Storage. SSE biedt geen beveiliging van de gegevens die onderweg zijn, maar versleutelt de gegevens die worden geschreven naar Azure Storage.SSE does not provide for the security of the data in transit, but it does encrypt the data as it is written to Azure Storage. SSE heeft geen invloed op de prestaties van Azure Storage.SSE does not affect Azure Storage performance.

U kunt elk soort gegevens van het opslag account versleutelen met behulp van SSE (blok-blobs, toevoeg-blobs, pagina-blobs, tabel gegevens, wachtrij gegevens en bestanden).You can encrypt any kind of data of the storage account using SSE (block blobs, append blobs, page blobs, table data, queue data, and files).

Als u een archief of bibliotheek van VHD-bestanden hebt die u gebruikt als basis voor het maken van nieuwe virtuele machines, kunt u een nieuw opslag account maken en vervolgens de VHD-bestanden uploaden naar dat account.If you have an archive or library of VHD files that you use as a basis for creating new virtual machines, you can create a new storage account and then upload the VHD files to that account. Deze VHD-bestanden worden versleuteld door Azure Storage.Those VHD files will be encrypted by Azure Storage.

Als u Azure Disk Encryption hebt ingeschakeld voor de schijven in een VM, worden nieuw geschreven gegevens versleuteld door SSE en door Azure Disk Encryption.If you have Azure Disk Encryption enabled for the disks in a VM, then any newly written data is encrypted both by SSE and by Azure Disk Encryption.

Storage AnalyticsStorage Analytics

Het verificatie type bewaken met behulp van OpslaganalyseUsing Storage Analytics to monitor authorization type

Voor elk opslag account kunt u Azure Opslaganalyse inschakelen voor het uitvoeren van logboek registratie en metrische gegevens voor opslag.For each storage account, you can enable Azure Storage Analytics to perform logging and store metrics data. Dit is een uitstekend hulp programma voor het controleren van de prestatie gegevens van een opslag account of het oplossen van problemen met een opslag account, omdat u prestatie problemen ondervindt.This is a great tool to use when you want to check the performance metrics of a storage account, or need to troubleshoot a storage account because you are having performance problems.

Een deel van de gegevens die u in de logboeken van de opslag analyse kunt zien, is de verificatie methode die door iemand wordt gebruikt bij de toegang tot opslag.Another piece of data you can see in the storage analytics logs is the authentication method used by someone when they access storage. Met Blob Storage kunt u bijvoorbeeld zien of ze een Shared Access Signature of de sleutels voor het opslag account hebben gebruikt of dat de BLOB openbaar was.For example, with Blob Storage, you can see if they used a Shared Access Signature or the storage account keys, or if the blob accessed was public.

Dit kan handig zijn als u de toegang tot opslag nauw keurig kunt beveiligen.This can be helpful if you are tightly guarding access to storage. In Blob Storage kunt u bijvoorbeeld alle containers instellen op privé en het gebruik van een SAS-service in uw toepassingen implementeren.For example, in Blob Storage you can set all of the containers to private and implement the use of an SAS service throughout your applications. Vervolgens kunt u de logboeken regel matig controleren om te zien of de blobs toegankelijk zijn via de sleutels voor het opslag account, die kunnen wijzen op een schending van de beveiliging, of als de blobs openbaar zijn, maar ze niet moeten worden gebruikt.Then you can check the logs regularly to see if your blobs are accessed using the storage account keys, which may indicate a breach of security, or if the blobs are public but they shouldn't be.

Hoe zien de logboeken eruitzien?What do the logs look like?

Nadat u de metrische gegevens van het opslag account en de logboek registratie via de Azure Portal hebt ingeschakeld, worden analytics data snel verzameld.After you enable the storage account metrics and logging through the Azure portal, analytics data will start to accumulate quickly. De logboek registratie en metrische gegevens voor elke service zijn gescheiden. de logboek registratie wordt alleen geschreven wanneer er sprake is van activiteit in dat opslag account, terwijl de metrische gegevens elke minuut, elk uur of elke dag worden geregistreerd, afhankelijk van de wijze waarop u deze configureert.The logging and metrics for each service is separate; the logging is only written when there is activity in that storage account, while the metrics will be logged every minute, every hour, or every day, depending on how you configure it.

De logboeken worden opgeslagen in blok-blobs in een container met de naam $logs in het opslag account.The logs are stored in block blobs in a container named $logs in the storage account. Deze container wordt automatisch gemaakt wanneer Opslaganalyse is ingeschakeld.This container is automatically created when Storage Analytics is enabled. Als deze container eenmaal is gemaakt, kunt u deze niet meer verwijderen.Once this container is created, you can't delete it, although you can delete its contents.

In de $logs container bevindt zich een map voor elke service en zijn er submappen voor het jaar/maand/dag/uur.Under the $logs container, there is a folder for each service, and then there are subfolders for the year/month/day/hour. Onder uur worden de logboeken genummerd.Under hour, the logs are numbered. De mapstructuur ziet er als volgt uit:This is what the directory structure will look like:

Weer gave van logboek bestanden

Elke aanvraag voor Azure Storage wordt geregistreerd.Every request to Azure Storage is logged. Hier volgt een moment opname van een logboek bestand, waarin de eerste velden worden weer gegeven.Here's a snapshot of a log file, showing the first few fields.

Moment opname van een logboek bestand

U kunt zien dat u de logboeken kunt gebruiken om een wille keurig soort aanroepen naar een opslag account bij te houden.You can see that you can use the logs to track any kind of calls to a storage account.

Wat zijn al deze velden voor?What are all of those fields for?

In de onderstaande bronnen vindt u een artikel met een lijst met veel velden in de logboeken en waarvoor ze worden gebruikt.There is an article listed in the resources below that provides the list of the many fields in the logs and what they are used for. Hier volgt de lijst met velden in de aangegeven volg orde:Here is the list of fields in order:

Moment opname van velden in een logboek bestand

We zijn geïnteresseerd in de vermeldingen voor GetBlob en hoe ze zijn geautoriseerd. Daarom moeten we zoeken naar vermeldingen met het Operation-type ' Get-BLOB ' en de aanvraag status (vierde kolom) en het autorisatie type (achtste kolom) controleren.We're interested in the entries for GetBlob, and how they are authorized, so we need to look for entries with operation-type "Get-Blob", and check the request-status (fourth column) and the authorization-type (eighth column).

In de eerste paar rijen in de bovenstaande vermelding is de aanvraag status "geslaagd" en het autorisatie type "Authenticated".For example, in the first few rows in the listing above, the request-status is "Success" and the authorization-type is "authenticated". Dit betekent dat de aanvraag is geautoriseerd met de sleutel van het opslag account.This means the request was authorized using the storage account key.

Hoe wordt toegang tot mijn blobs geautoriseerd?How is access to my blobs being authorized?

Er zijn drie gevallen waarin we geïnteresseerd zijn.We have three cases that we are interested in.

  1. De blob is openbaar en wordt geopend met behulp van een URL zonder Shared Access Signature.The blob is public and it is accessed using a URL without a Shared Access Signature. In dit geval is de aanvraag status ' AnonymousSuccess ' en is het autorisatie type ' anoniem '.In this case, the request-status is "AnonymousSuccess" and the authorization-type is "anonymous".

    1.0;2015-11-17T02:01:29.0488963Z;GetBlob;AnonymousSuccess;200;124;37;anonymous;;mystorage…1.0;2015-11-17T02:01:29.0488963Z;GetBlob;AnonymousSuccess;200;124;37;anonymous;;mystorage…

  2. De blob is persoonlijk en is gebruikt met een Shared Access Signature.The blob is private and was used with a Shared Access Signature. In dit geval is de aanvraag status "SASSuccess" en is het autorisatie type "SAS".In this case, the request-status is "SASSuccess" and the authorization-type is "sas".

    1.0;2015-11-16T18:30:05.6556115Z;GetBlob;SASSuccess;200;416;64;sas;;mystorage…1.0;2015-11-16T18:30:05.6556115Z;GetBlob;SASSuccess;200;416;64;sas;;mystorage…

  3. De blob is persoonlijk en de opslag sleutel is gebruikt om deze te openen.The blob is private and the storage key was used to access it. In dit geval is de aanvraag status "geslaagd" en is het autorisatie type "Authenticated".In this case, the request-status is "Success" and the authorization-type is "authenticated".

    1.0;2015-11-16T18:32:24.3174537Z;GetBlob;Success;206;59;22;authenticated;mystorage…1.0;2015-11-16T18:32:24.3174537Z;GetBlob;Success;206;59;22;authenticated;mystorage…

U kunt de micro soft Message Analyzer gebruiken om deze logboeken te bekijken en te analyseren.You can use the Microsoft Message Analyzer to view and analyze these logs. Het bevat Zoek-en filter mogelijkheden.It includes search and filter capabilities. U kunt bijvoorbeeld zoeken naar instanties van GetBlob om te zien of het gebruik overeenkomt met wat u verwacht, dat wil zeggen, om ervoor te zorgen dat iemand niet op de juiste wijze toegang krijgt tot uw opslag account.For example, you might want to search for instances of GetBlob to see if the usage is what you expect, that is, to make sure someone is not accessing your storage account inappropriately.

ResourcesResources

CORS (Cross-Origin Resource Sharing)Cross-Origin Resource Sharing (CORS)

Toegang tot meerdere domeinen van bronnenCross-domain access of resources

Wanneer een webbrowser die in het ene domein wordt uitgevoerd, een HTTP-aanvraag voor een bron van een ander domein maakt, wordt dit een cross-Origin HTTP-aanvraag genoemd.When a web browser running in one domain makes an HTTP request for a resource from a different domain, this is called a cross-origin HTTP request. Een HTML-pagina die wordt aangeboden vanuit contoso.com, maakt bijvoorbeeld een aanvraag voor een JPEG die wordt gehost op fabrikam.blob.core.windows.net.For example, an HTML page served from contoso.com makes a request for a jpeg hosted on fabrikam.blob.core.windows.net. Uit veiligheids overwegingen beperken browsers de cross-Origin HTTP-aanvragen die worden geïnitieerd vanuit scripts, zoals Java script.For security reasons, browsers restrict cross-origin HTTP requests initiated from within scripts, such as JavaScript. Dit betekent dat als sommige Java script-code op een webpagina op contoso.com, JPEG op fabrikam.blob.core.windows.net verzoekt, de browser de aanvraag niet toestaat.This means that when some JavaScript code on a web page on contoso.com requests that jpeg on fabrikam.blob.core.windows.net, the browser will not allow the request.

Wat doet dit met Azure Storage?What does this have to do with Azure Storage? Als u statische assets zoals JSON-of XML-gegevens bestanden opslaat in Blob Storage met behulp van een opslag account met de naam Fabrikam, wordt het domein voor de assets fabrikam.blob.core.windows.net en kan de contoso.com-webtoepassing geen toegang krijgen tot deze met behulp van Java script omdat de domeinen verschillend zijn.Well, if you are storing static assets such as JSON or XML data files in Blob Storage using a storage account called Fabrikam, the domain for the assets will be fabrikam.blob.core.windows.net, and the contoso.com web application will not be able to access them using JavaScript because the domains are different. Dit geldt ook als u probeert een van de Azure Storage-services, zoals Table Storage, aan te roepen die de JSON-gegevens retour neren die moeten worden verwerkt door de Java script-client.This is also true if you're trying to call one of the Azure Storage Services – such as Table Storage – that return JSON data to be processed by the JavaScript client.

Mogelijke oplossingenPossible solutions

Een manier om dit op te lossen is het toewijzen van een aangepast domein, zoals ' storage.contoso.com ', aan fabrikam.blob.core.windows.net.One way to resolve this is to assign a custom domain like "storage.contoso.com" to fabrikam.blob.core.windows.net. Het probleem is dat u het aangepaste domein alleen aan één opslag account kunt toewijzen.The problem is that you can only assign that custom domain to one storage account. Wat gebeurt er als de assets worden opgeslagen in meerdere opslag accounts?What if the assets are stored in multiple storage accounts?

Een andere manier om dit op te lossen is dat de webtoepassing fungeert als een proxy voor de opslag aanroepen.Another way to resolve this is to have the web application act as a proxy for the storage calls. Dit betekent dat als u een bestand uploadt naar Blob Storage, de webtoepassing het lokaal schrijft en het vervolgens naar Blob Storage kopieert, of dat alles in het geheugen leest en het vervolgens naar Blob Storage schrijft.This means if you are uploading a file to Blob Storage, the web application would either write it locally and then copy it to Blob Storage, or it would read all of it into memory and then write it to Blob Storage. U kunt ook een speciale webtoepassing (zoals een web-API) schrijven die de bestanden lokaal uploadt en naar Blob Storage schrijft.Alternately, you could write a dedicated web application (such as a Web API) that uploads the files locally and writes them to Blob Storage. In beide gevallen hebt u de mogelijkheid om die functie te gebruiken bij het bepalen van de schaalbaarheids behoeften.Either way, you have to account for that function when determining the scalability needs.

Hoe kan CORS Help?How can CORS help?

Met Azure Storage kunt u CORS inschakelen: cross-Origin resource delen.Azure Storage allows you to enable CORS – Cross Origin Resource Sharing. Voor elk opslag account kunt u domeinen opgeven die toegang hebben tot de bronnen in dat opslag account.For each storage account, you can specify domains that can access the resources in that storage account. In ons geval zoals hierboven beschreven, kunnen we CORS inschakelen op het fabrikam.blob.core.windows.net-opslag account en zo configureren dat toegang tot contoso.com wordt toegestaan.For example, in our case outlined above, we can enable CORS on the fabrikam.blob.core.windows.net storage account and configure it to allow access to contoso.com. Vervolgens kan de webtoepassing contoso.com rechtstreeks toegang krijgen tot de resources in fabrikam.blob.core.windows.net.Then the web application contoso.com can directly access the resources in fabrikam.blob.core.windows.net.

Houd er rekening mee dat CORS toegang biedt, maar dat er geen verificatie wordt geboden, wat vereist is voor alle niet-open bare toegang tot opslag resources.One thing to note is that CORS allows access, but it does not provide authentication, which is required for all non-public access of storage resources. Dit betekent dat u alleen toegang kunt krijgen tot blobs als deze openbaar zijn of dat u een Shared Access Signature hebt die u de juiste machtigingen geeft.This means you can only access blobs if they are public or you include a Shared Access Signature giving you the appropriate permission. Tabellen, wacht rijen en bestanden hebben geen open bare toegang en vereisen een SAS.Tables, queues, and files have no public access, and require a SAS.

CORS is standaard uitgeschakeld voor alle services.By default, CORS is disabled on all services. U kunt CORS inschakelen met behulp van de REST API of de Storage-client bibliotheek om een van de methoden voor het instellen van het service beleid aan te roepen.You can enable CORS by using the REST API or the storage client library to call one of the methods to set the service policies. Wanneer u dat doet, neemt u een CORS-regel op, die in XML is.When you do that, you include a CORS rule, which is in XML. Hier volgt een voor beeld van een CORS-regel die is ingesteld met behulp van de bewerking service-eigenschappen instellen voor de BLOB-service voor een opslag account.Here's an example of a CORS rule that has been set using the Set Service Properties operation for the Blob Service for a storage account. U kunt deze bewerking uitvoeren met de Storage-client bibliotheek of de REST-Api's voor Azure Storage.You can perform that operation using the storage client library or the REST APIs for Azure Storage.

<Cors>    
    <CorsRule>
        <AllowedOrigins>http://www.contoso.com, http://www.fabrikam.com</AllowedOrigins>
        <AllowedMethods>PUT,GET</AllowedMethods>
        <AllowedHeaders>x-ms-meta-data*,x-ms-meta-target*,x-ms-meta-abc</AllowedHeaders>
        <ExposedHeaders>x-ms-meta-*</ExposedHeaders>
        <MaxAgeInSeconds>200</MaxAgeInSeconds>
    </CorsRule>
<Cors>

Wat betekent elke rij:Here's what each row means:

  • AllowedOrigins Zo weet u welke niet-overeenkomende domeinen gegevens van de opslag service kunnen aanvragen en ontvangen.AllowedOrigins This tells which non-matching domains can request and receive data from the storage service. Dit betekent dat zowel contoso.com als fabrikam.com gegevens kunnen aanvragen van Blob Storage voor een specifiek opslag account.This says that both contoso.com and fabrikam.com can request data from Blob Storage for a specific storage account. U kunt dit ook instellen op een Joker teken*(), zodat alle domeinen toegang hebben tot aanvragen.You can also set this to a wildcard (*) to allow all domains to access requests.
  • AllowedMethods Dit is de lijst met methoden (HTTP-aanvraag bewerkingen) die kunnen worden gebruikt bij het maken van de aanvraag.AllowedMethods This is the list of methods (HTTP request verbs) that can be used when making the request. In dit voor beeld zijn alleen PUT en GET toegestaan.In this example, only PUT and GET are allowed. U kunt dit instellen op een Joker teken*(), zodat alle methoden kunnen worden gebruikt.You can set this to a wildcard (*) to allow all methods to be used.
  • AllowedHeaders Dit zijn de aanvraag headers die in het bron domein kunnen worden opgegeven bij het maken van de aanvraag.AllowedHeaders This is the request headers that the origin domain can specify when making the request. In dit voor beeld zijn alle meta gegevens headers die beginnen met x-MS-meta gegevens, x-MS-meta doel en x-MS-meta-ABC toegestaan.In this example, all metadata headers starting with x-ms-meta-data, x-ms-meta-target, and x-ms-meta-abc are permitted. Het Joker teken (*) geeft aan dat elke header die begint met het opgegeven voor voegsel is toegestaan.The wildcard character (*) indicates that any header beginning with the specified prefix is allowed.
  • ExposedHeaders Hiermee wordt aangegeven welke antwoord headers door de browser moeten worden weer gegeven aan de aanvraag verlener.ExposedHeaders This tells which response headers should be exposed by the browser to the request issuer. In dit voor beeld wordt elke koptekst die begint met ' x-MS-meta-' weer gegeven.In this example, any header starting with "x-ms-meta-" will be exposed.
  • MaxAgeInSeconds Dit is de maximale hoeveelheid tijd die een browser de aanvraag voor Preflight-opties in de cache opslaat.MaxAgeInSeconds This is the maximum amount of time that a browser will cache the preflight OPTIONS request. (Zie het eerste artikel hieronder voor meer informatie over de Preflight-aanvraag.)(For more information about the preflight request, check the first article below.)

ResourcesResources

Bekijk deze bronnen voor meer informatie over CORS en hoe u deze inschakelt.For more information about CORS and how to enable it, check out these resources.

Veelgestelde vragen over Azure Storage beveiligingFrequently asked questions about Azure Storage security

  1. Hoe kan ik de integriteit verifiëren van de blobs die ik naar of van Azure Storage overdraagt als ik het HTTPS-protocol niet kan gebruiken?How can I verify the integrity of the blobs I'm transferring into or out of Azure Storage if I can't use the HTTPS protocol?

    Als u om een of andere reden HTTP in plaats van HTTPS moet gebruiken en u met blok-blobs werkt, kunt u MD5-controle gebruiken om te helpen bij het controleren van de integriteit van de overdracht van blobs.If for any reason you need to use HTTP instead of HTTPS and you are working with block blobs, you can use MD5 checking to help verify the integrity of the blobs being transferred. Dit helpt bij de beveiliging van netwerk/Trans Port-laag fouten, maar niet noodzakelijkerwijs met tussenliggende aanvallen.This will help with protection from network/transport layer errors, but not necessarily with intermediary attacks.

    Als u HTTPS kunt gebruiken, dat beveiliging op transport niveau biedt, is het gebruik van MD5-controle overbodig en onnodig.If you can use HTTPS, which provides transport level security, then using MD5 checking is redundant and unnecessary.

    Bekijk het overzicht van Azure Blob MD5voor meer informatie.For more information, please check out the Azure Blob MD5 Overview.

  2. Informatie over FIPS-naleving voor de Verenigde Staten Government?What about FIPS-Compliance for the U.S. Government?

    De Verenigde Staten Federal Information Processing Standard (FIPS) definieert cryptografische algoritmen die zijn goedgekeurd voor gebruik door de VS Computer systemen van de federale overheid voor de bescherming van gevoelige gegevens.The United States Federal Information Processing Standard (FIPS) defines cryptographic algorithms approved for use by U.S. Federal government computer systems for the protection of sensitive data. Het inschakelen van de FIPS-modus op een Windows-Server of-bureau blad vertelt u het besturings systeem dat alleen FIPS-gevalideerde cryptografische algoritmen moeten worden gebruikt.Enabling FIPS mode on a Windows server or desktop tells the OS that only FIPS-validated cryptographic algorithms should be used. Als een toepassing niet-compatibele algoritmen gebruikt, wordt de toepassing onderbroken.If an application uses non-compliant algorithms, the applications will break. With.NET Framework versie 4.5.2 of hoger, de toepassing schakelt automatisch de algoritmen voor crypto grafie in voor het gebruik van FIPS-compatibele algoritmen wanneer de computer zich in de FIPS-modus bevindt.With.NET Framework versions 4.5.2 or higher, the application automatically switches the cryptography algorithms to use FIPS-compliant algorithms when the computer is in FIPS mode.

    Micro soft laat elke klant weten of de FIPS-modus moet worden ingeschakeld.Microsoft leaves it up to each customer to decide whether to enable FIPS mode. We geloven dat er geen dwingende reden is voor klanten die geen wettelijke voor Schriften ondergaan om standaard de FIPS-modus in te scha kelen.We believe there is no compelling reason for customers who are not subject to government regulations to enable FIPS mode by default.

ResourcesResources