Ensure Shared Access Signature Tokens Expire Within One Hour

Overview

In its original form, this control cannot be audited since SAS tokens are not stored in Azure. Cyscale checks the SAS expiration policy for each storage account.

Expire shared access signature tokens within an hour.

Rationale

A shared access signature (SAS) is a URI that grants restricted access rights to Azure Storage resources. It can be provided to clients who should not be trusted with the storage account key but for whom it may be necessary to delegate access to certain storage account resources. Providing a shared access signature URI to these clients allows them access to a resource for a specified period of time. This time should be set as low as possible, preferably no longer than an hour.

Default Value

By default, the expiration for shared access signature tokens is 8 hours.

Remediation guidance

There is no way to change existing SAS tokens since they are not stored in Azure.

We recommend setting a SAS expiration policy. While the policy does not enforce the upper expiration limit when creating tokens, this seems to be an upcoming feature. The policy helps you track the usage of SAS tokens valid over a longer interval than the SAS expiration policy recommends.

Multiple Remediation Paths

Azure

SERVICE-WIDE (RECOMMENDED when many resources are affected): Assign Azure Policy initiatives at management group/subscription scope and trigger remediation tasks.

az policy assignment create --name <assignment-name> --scope /subscriptions/<subscription-id> --policy-set-definition <initiative-id>
az policy remediation create --name <remediation-name> --policy-assignment <assignment-id>

ASSET-LEVEL: Apply the resource-specific remediation steps above to the listed non-compliant resources.

PREVENTIVE: Embed Azure Policy checks into landing zones and IaC workflows to block or auto-remediate drift.

References for Service-Wide Patterns

Azure Policy overview: https://learn.microsoft.com/en-us/azure/governance/policy/overview
Azure Policy remediation: https://learn.microsoft.com/en-us/azure/governance/policy/how-to/remediate-resources
Azure Policy initiative structure: https://learn.microsoft.com/en-us/azure/governance/policy/concepts/initiative-definition-structure

Operational Rollout Workflow

Use this sequence to reduce risk and avoid repeated drift.

1. Contain at Service-Wide Scope First (Recommended)

Azure: assign policy initiatives at management group/subscription scope and run remediation tasks.

az policy assignment create --name <assignment-name> --scope /subscriptions/<subscription-id> --policy-set-definition <initiative-id>
az policy remediation create --name <remediation-name> --policy-assignment <assignment-id>

2. Remediate Existing Affected Assets

Execute the control-specific Console/CLI steps documented above for each flagged resource.
Prioritize internet-exposed and production assets first.

3. Validate and Prevent Recurrence

Re-scan after each remediation batch.
Track exceptions with owner and expiry date.
Add preventive checks in IaC/CI pipelines.

Query logic

These are the stored checks tied to this control.

Azure Storage Accounts Without SAS Expiration Policy

Connectors

Microsoft Azure

Covered asset types

StorageAccount

Expected check: eq []

{
  storageAccounts(
    where: {
      OR: [
        { sasPolicyExpirationAction: "" }
        {
          AND: [
            { NOT: { sasPolicySasExpirationPeriod_STARTS_WITH: "0.00" } }
            { NOT: { sasPolicySasExpirationPeriod: "0.01:00:00" } }
          ]
        }
      ]
    }
  ) {
    ...AssetFragment
  }
}