4.1.1. Storage - Azure Storage - Security.md

Azure Storage Account Security

Management vs Data Plane

• Handled with RBAC in Azure AD
  • Can see storage keys: Owner, Contributor & Storage Account,Virtual Machine Contributor, Storage Account Key Operator Service
    • Reader cannot see storage keys

Management Plane

• Administrative tasks e.g.
  • Viewing properties of storage account.
  • Deleting storage account.
  • Assigning roles to other users.
  • Modifying the configuration.

Data Plane

• Requires access to storage account keys.
• On blobs you can set access level to public access.

Storage Account Keys**

• Provides full access to the storage
• 💡 Best practice: Give all admins and apps same key.
  • Enables you to:
    • Regenerate secondary key.
    • Update apps to use secondary key
    • Regenerate primary key
• Can be managed by Azure Key Vault using Powershell
  • Storage account keys are stored as Key vault secrets.
  • Azure Key Vault syncs keys with storage Account
  • Storage account keys never returned to caller.

Shared Access Signatures (SAS tokens)

• 💡 Better as it follows principle of the least privilege.

• Contains permissions and start & end validity period.

  • Set read and/or write permissions.
  • Grant permissions to access only partition + row key ranges.
  • You can restrict access to IP Address(es)
  • Enforce HTTPS

• Two types:

  • Service Level SAS: Only to a single blob/file/table or queue storage.
  • Account Level SAS: Applies to multiple services

• ❗ It's generated by client and is not tracked by Microsoft.

  • Signature is signed with account key and ensures none of the parameters are tempered.
  • To invalidate, you'll need to regenerate storage account key used to sign SAS.
  • 💡 Better way: Storage Access Policies
    • Defined on container level.
      • In portal: Containers → Right click on container → Access policy
    • Permissions + validity period is on server side.
    • Service level SAS only.
    • Easy to revoke by deleting the policy or changing its validity period.

• Example url:

  URL part	Description
  https://myacount.blob.core.windows.net/container1/file1.pdf	URL to endpoint
  ?sv=2017-07-29	Rest API version
  &st=2018-04-30T19%3A19%3A19Z	Validity start time
  &se=2018-05-01T19%3A19%#A19Z	Validity end time
  &sr=b	Type of resource
  &sp=r	Permissions
  &sip=168.1.5.60-168.1.5.70	IP Address / range (optional)
  &spr=https	Protocol (optional)
  &sig=pk9oGEPqYyu0K4Gutfreq9n0CJqgnjYgkEwcIEL8I0%3D	Signature

Azure AD authentication with RBAC

• Available for Blob and Queue services.
• Azure AD provides OAuth 2.0 token
• E.g. Storage Blob Data Contributor, Storage Blob Data Reader, Storage Queue Data Contributor, Storage Queue Data Reader
• Subscription level (for all Storage Accounts), Resource group level, Storage level or Blob container/queue level.
• For users, groups, applications, managed service identities.
• You register your application in AD (App Registrations)
  • You can then assign roles to your application.
  • Roles can also be assigned to Managed Service Identity (MSI)
    • Can set up with Azure VMs, Function Apps, VM Scale Sets
    • Credentials are injected into service instance (e.g. client id and certificate)
    • Code calls local MSI endpoint to authenticate to the resource (e.g. storage)
• Easier management, no need to handle SAS tokens or manage keys.

Encrypt data in transit

• Enforced by enabling Secure Transfer
  • Requires HTTPS for REST API
  • Requires SMB 3.0 for Azure file service
• When moving data e.g. between
  • Azure regions
  • On-prem to Azure storage
    • You can use Site-to-Site VPN, Point-to-Site VPN or Azure ExpressRoute.
• The data is moved across internet.
• 💡 Vulnerable to Azure, good to encrypt data.
  • Configuration from outside Storage Account always requires SMB 3.0
  • SMB 2.1 does not have encryption so it's only allowed between different Azure regions.
  • Secure transfer required option is disabled by default.
• SAS tokens can specify only HTTPS can be used.
• You can also use client side encryption
  • Encrypt data within the application.
  • Double encrypted as Azure storage encrypts data as default.
  • Still good idea to enforce HTTPS
    • HTTPS has built-in integrity checks to avoid network data loss
  • There are SDKS for e.g. C#, JAVA.
  • Can leverage Azure Key vault to generate and/or store keys.

Encrypt data in rest

• Every storage account has encryption enabled by default and cannot be disabled.
• Required for many compliances e.g. privacy.

Storage Service Encryption (SSE)

• Encrypts data before it's written
• Decrypts data before it's read
• Allows you to get encryption without any code
• Applies to Standard and Premium.
• Uses 256 bit AES.
• Keys are managed by Microsoft by default.
• Allows you to use your own encryption keys.
  • ❗ Blobs and files only.
  • ❗ Can only enable after the account is created.
  • ❗ Key vault and storage account must be in same region
    • Can be in different subscriptions

Azure Disk Encryption

• Encrypts data disks (VHD) of VMs.
• Handles both managed & unmanaged disks.
• Windows VMs: BitLocker encryption
• Linux VMs: DM-crypt
• Integrates with Key Vault to manage keys.
  • ❗ Key Vault must reside in same region and subscription
  • When uploading encrypted VM, you can upload encryption keys to Azure Key Vault first.
    • Good for migrating as you can use same keys as on-premises.

Configure network

• By default, storage accounts are accessible by all networks including internet
• Allows you to create trust boundaries
• Setting up networking/firewall rule
  • ❗ Denies all traffic by default unless any connection are explicitly opened
• In portal: Settings → Firewalls and Virtual Networks →Select Network
• You can have VNets from the same region as storage account or in a paired region.
• Firewall allows you to choose IP addresses that can access VMs
  • E.g. you can set up only ExpressRoute access.
• When you configure Azure Storage firewalls and virtual networks