Storage Security (part 2)

By Ashwin Venugopal -



To read part 1 please click here

Shared Access Signatures

For untrusted clients you can use a Shared Access Signature (SAS) which is a string that contains a security token that can be attached to a URI as well as delegate access to storage objects and specified constraints, such as the permissions and the time range of access. 

Types of SAS

  • You can use a service-level SAS to allow access to specific resources in a storage account. You'd use this type of SAS, for example, to allow an app to retrieve a list of files in a file system or to download a file.

  • Use an account-level SAS to allow access to anything that a service-level SAS can allow, plus additional resources and abilities. For example, you can use an account-level SAS to allow the ability to create file systems.

  • A user delegation SAS, introduced with version 2018-11-09, is secured with Azure AD credentials. This type of SAS is supported for the Blob service only and can be used to grant access to containers and blobs. 

Additionally, a service SAS can reference a stored access policy that provides an additional level of control over a set of signatures, including the ability to modify or revoke access to the resource if necessary.

Azure AD Storage Authentication

In addition to the shared key and SAS, Azure Blob and Queue storage supports using Azure AD to authorize storage requests. The security principle is authenticated by Azure AD to return an OAuth 2.0 token. The token can then be used to authorize a request against Blob or Queue storage.

  • Authorization with Azure AD is available for all general-purpose and Blob storage accounts in all the public regions as well as national clouds.

  • Built-in storage roles are provided including Owner, Contributor, and Reader.

  • The role can be scoped from Management Group to individual blob or queue. Best practices dictate granting only the narrowest possible scope. 

  • RBAC role assignments may take up to five minutes to propagate. 

When a security principle attempts to access a blob or queue resource, the request must be authorized, unless it is a blob available for anonymous access.

Storage Service Encryption

Azure Storage security

Azure Storage provides a comprehensive set of security capabilities that together enable developers to build secure applications:

  • All data written to Azure Storage is automatically encrypted using Storage Service Encryption (SSE).
  • Azure AD and RBAC are supported for Azure Storage for both resource management operations and data operations.
  • Data can be stored in transit between an application and Azure by using Client-Side Encryption, HTTPS, or SMB 3.0.
  • OS and data disks used by Azure virtual machines can be encrypted using Azure Disk Encryption.
  • Delegated access to the data objects in Azure Storage can be granted using a shared access signature. 

Encryption Key Management

You can rely either on Microsoft-managed keys for the encryption of your storage account, or you can manage encryption with your own keys that has two options:

  • You can specify a customer-managed key to use for encrypting and decrypting all data in the storage account. It is used to encrypt all data in all services in your storage account.
  • You can specify a customer-provided key on Blob storage operations. A client making a read or write request against Blob storage can include an encryption key on the request for granular control over how blob data is encrypted and decrypted.

Blob Data Retention Policies

Time-based vs Legal hold policies

  • Time-based retention policy support- When a time-based retention policy is set, blobs can be created and read, but not modified or deleted but when this policy is applied on a container, all the blobs in the container will stay in the immutable state for the duration of the effective retention period and as users can extend the retention interval, immutable storage uses the most recent value of the user-specified retention interval to calculate the effective retention period.

  • Legal hold policy support- When a legal hold policy is set, blobs can be created and read, but not modified or deleted. The legal holds are temporary holds that can be used for legal investigation purposes or general protection policies and each of them are used to be associated with one or more tags which are used as a name identifier, such as a case ID or event, to categorize and describe the purpose of the hold. 

Azure Files Authentication

Azure Files supports identity-based authentication over Server Message Block (SMB) through on-premises AD Domain Services and Azure AD Domain Services and allows you to replace existing file servers with Azure file shares without replacing your existing directive service, maintaining seamless user access to shares.

Azure files also enforces authorization on user access to both the share and the directory/file levels and at the directory/file level, Azure files supports preserving, inheriting, and enforcing Windows DACLs just like any Windows file servers. Whether you plan to enforce authorization or not, you can use Azure file shares to back up DACLs along with your data.

Advantages of identity-based authentication

Identity-based authentication for Azure Files offers several benefits over using Shared Key authentication:
  • Extend the traditional identity-based file share access experience to the cloud with on-premises AD DS and Azure AD DS. Azure files supports using both on-premises AD DS or Azure AD DS credentials to access Azure file shares over SMB from either on-premises AD DS or Azure AD DS domain-joined VMs.

  • Enforce granular access control on Azure file shares. You can grant permissions to a specific identity at the share, directory, or file level. You can also grant all teams access to non-sensitive directories, while limiting access to directories containing sensitive financial data to your Finance team only.

  • Back up Windows ACLs (also known as NTFS) along with your data. Azure files preserves your ACLs along with your data when you back up a file share to Azure file shares over SMB. 

  Secure Transfer Required

When a secure transfer is required, a call to an Azure Storage REST API operation must be made over HTTPS. Any request made over HTTP is rejected. Connecting to an Azure file share over SMB without encryption fails when secure transfer is required for the storage account. By default, the secure transfer required property is enabled when you create a storage account. Azure Storage doesn't support HTTPS for custom domain names, this option is not applied when you are using a custom domain name. 



To read part 1 please click here





Comments

Post a Comment

Popular posts from this blog

Deployment (Part 3)

By Ashwin Venugopal -
Image
  To read part 1, please click  here To read part 2, please click  here Microsoft Monitoring Agent (MMA) MMA is used across multiple Microsoft solutions and has undergone a few name changes as its features and functionality have evolved. If it is being considered to be used, then following areas should be covered during a Microsoft Sentinel deployment project: Consider the timelines and the strategy for a migration to AMA (Azure Monitor Agent) before the MMA end-of-life.  Consider the central deployment and management methodology for MMA. Determine which endpoints are in scope for deployment as these affect the log ingestion volume significantly.  Azure Monitor Agent (AMA) Organizations with MMA as the main Microsoft Sentinel agent should start planning the migration to AMA as soon as possible to avoid a rushed migration. One of the main advantages of AMA is the ability to control the log collection policy centrally and apply different policies against different...
Read more

Deployment (Part 1)

By Ashwin Venugopal -
Image
  To read part 2, please click  here To read part 3, please click  here Azure Resources Microsoft Sentinel needs following resources to be created: Subscription (if a dedicated subscription(s) will be used) Resource group(s) Log Analytics workspace(s) Automation rules/playbook Alert rules Workbooks Microsoft Sentinel offers hundreds of alert rules, workbooks, and automation playbook templates along with hunting scripts. The templates can be used to activate/deploy schedule alerts, create customized dashboards, create automation playbooks and perform threat-hunting activities. Generally, once deployed, the resources created have to be adjusted to match the existing environment, configure local credentials, etc. Methods of deployment: Manual- Administrator can manually configures the Microsoft Sentinel resources with the help of Azure portal. Any manual process has the inherent risks of human operator error, lack of compliance with potential change control procedures, and u...
Read more

Project Resourcing (Part 2)

By Ashwin Venugopal -
Image
  To read part 1, please click  here Engineering - SIEM The SIEM engineers configures Microsoft Sentinel, including Log Analytics, Logic Apps, workbooks, and playbooks. They are also responsible for the following high-level tasks: Initial configuration of Azure tenant, including provisioning required resources, assigning access roles, and configuring workspace parameters like log retention, resource tagging, and blueprints.  Deployment and configuration of syslog/CEF log collection agents in appropriate locations to collect logs from on-premises devices. Generally, it will be joint effort of both system engineer and SIEM engineer, involving configuration and potential troubleshooting.  Working with system owners to enable log forwarding and configuring any required parsing of log data in Log Analytics.  Working with security operations to create and deploy KQL analytic rules to offer detections for SOC/Computer Security Incident Response Team (CSRIT) use. Tuning...
Read more