Skip to content

3.Network & Security

Authorization & Authentication

Data Plane

  • 5 features available:

    1. Shared key
    2. Shared Access Signature
    3. AAD
    4. Anonymous
    5. Storage Local users (only for SFTP)

    Shared Account Key

    • Use the storage account key
    • Provide full access to the storage account
    • Not recommended
    • Possible to disallow the Account Key to prevent usage

    Shared Access Signature

    • Provide limited access to container/blob
    • Limited in time
    • Limited permissions
    • SAS is signed with the Account Key (or by AAD with user delegation SAS)

    Azure AD

    • Use Azure AD credentials to access resources
    • Based on Azure RBAC
    • Can be completed by Attribute-Based Access Control (ABAC)

    Anonymous

    • Provide read access to blobs
    • Not recommended

    Local Users

    • Used when SFTP is enabled

Control Plane

Data Protection

Storage Account Lock

  • Protect the storage account from deletion & config changes
  • = first level of protection to avoid losing data

Soft Delete

  • A deleted container and its contents / or deleted blob version may be restored within the retention period
  • Retention Period between 1 and 365 days, default is 7
  • Microsoft recommends using a short retention period to better understand how the feature will affect your bill
  • Deletion happen at the expiration of the retention period that was in effect at the time that the object was deleted
  • An updated retention period applies only to data that was deleted after the retention period was changed
  • After disabling soft delete you can still access and recover soft-deleted objects in your storage account until the soft delete retention period has elapsed.

  • Soft-deleted objects are invisible unless they are explicitly displayed or listed

    For Blob

    • protects an individual blob, snapshot, or version from accidental deletes or overwrites
    • maintaining the deleted data in the system for a specified period of time
    • The clock starts on the retention period as soon as an object is deleted or overwritten.
    • you can restore a deleted blob (with its snapshots) or a deleted version
    • When you delete a blob and its snapshots, both the blob and snapshots are marked as soft-deleted
    • Deleting one or more active snapshots without deleting the base blob will soft-deleted the snapshot
    • Overwriting a blob automatically creates a soft-deleted snapshot of the blob's state prior to the write operation
    • Soft-deleted snapshots are invisible unless soft-deleted objects are explicitly displayed or listed
    • The Undelete Blob operation restores a blob and any soft-deleted snapshots associated with it
    • Overwriting a blob automatically creates a new version if versionning is enabled
    • When you delete a blob, the current version of the blob becomes a previous version
    • Restore always returns all soft-deleted versions, it's not possible to restore only a single soft-deleted version

    For Container

    • Maintain the deleted data in the system for a specified period of time (= Retention period)
    • Restore the whole container at the time of deletion
    • After the retention period has expired, the container and its contents are permanently deleted
    • During the restore the container's blobs and any blob versions and snapshots are also restored
    • The container should be restored with the same name: beware to not reuse it for another container

Change feed

  • Provide transaction log of changes on blob and blob metadata
  • Capture Create, Update and Delete actions
  • Is Ordered, durable immutable and read-only
  • Each change is one entry to the log
  • Storage of change feed:
    • When enabled, applies for all the storage account
    • Push entries into special container: $blobchangefeed
    • Change log file is under Apache Avro format
    • No SLA regarding the available time of a change once its performed
    • Changes are stored as hourly segment (updated every minute) (= aka 1 file per hour)
    • Segment are created only when there are blob change events that occur in that hour

Blob Snapshot

  • A blob may be restored from a snapshot if the blob is overwritten
  • Recommended as an alternative to blob versioning
  • Data in a snapshot is billed based on unique blocks or pages => differentiel

Blob Versioning

  • Every blob write operation creates a new version
  • A blob version is billed based on unique blocks or pages => différentiel

Immutable storage

  • Prevent a container and its contents / or a blob version (& metadata) from being deleted or overwritten

    For Blob

    For Container

Point in time restore

  • Provides protection against accidental deletion or corruption
  • Enabling point-in-time restore also enables blob versioning, soft delete, and change feed
  • A set of block blobs may be reverted to their state at a specific point in the past:
    • One or more containers or blob ranges is restored to its state n days ago
    • Where n is less than or equal to the retention period defined for point-in-time restore
    • The effect is to revert write and delete operations that happened during the retention period
  • Azure Storage blocks data operations on the blobs in the ranges being restored for the duration of the operation
    • In the primary location
  • You cannot restore blobs to a state prior to the beginning of the retention period
  • Retention period must be at least one day less than the retention period specified for soft delete

Encryption at rest

  • Service-side encryption (SSE) used to encrypt the data at rest:
    • 256b AES
    • is FIPS 140-2 compliant
    • cannot be disabled
    • all object's metadata are also encrypted
  • Client-side encryption:
    • Possible through SDK for Blob & Queue
    • .NET, Java, Python
  • Encryption scope:
    • cover all the storage account by default
    • possible to scope at container or blob level

Key Management for encryption at rest

  • 3 options:

    Microsoft Managed Key (MMK)

    • Key rotation managed by Microsoft
    • Scopable to container and/or blob

    Customer Managed Key (CMK)

    • Behavior:
      • Storage account root key remains the same and is used to encrypt the datas
      • This key is encrypted with the customer managed key
      • Any access to the root key needs first to decrypt the key with the CMK
    • Keys should be stored in Azure Key Vault
      • can be in different AAD tenants
      • can be in different regions
      • and can be in different subscriptions.
    • When using BLob API, the storage account rely on a managed identities to read the key from KV
    • Key rotation managed by customer
    • Scopable to container and/or blob

    Customer Provided Key (CPK)

    • Behavior:
      • The key is provided when calling blob operations (read, write..)
      • Azure storage calculate the SHA 256 hash and write it alongside the object
      • This verify the next request can provide the same key
      • The key is never stored on Azure
      • Is MMK/CMK is also activated and CPK is provided, only CPK mechanism is used
    • Keys are store by the customer
    • Key rotation managed by customer
    • Cannot be scoped
    • Key rotation for CPK:
      • download the object with the current CPK
      • re upload the object by using the new CPK

Encryption scope

  • full first month of usage is billed then on hourly basis
  • scope by default: overall storage account instance
  • scope a key to a container or individual blob:
    • for blob: encrypted with the key
    • for containers:
      • it serves as the default "encrypt all blob in it"
      • = all blobs (and new) are encryped with the key
      • the container by itself is not encrypted ?
  • possible to have different scope usage on the same storage account