A shared access signature is generated on the client side. Azure Storage does not track the resulting token, and Microsoft says token generation itself cannot be audited through the service. A principal with the relevant signing authority can generate a token without the storage account owner’s knowledge.
\nStorage also does not track how many SAS tokens were generated, and no API supplies that count. Microsoft says organizations that need the number must maintain their own tracking. Microsoft Learn.
\nIdentify the approved issuing applications, signing permissions and storage accounts. Keep issuance, observed use and current validity as separate questions rather than assuming one record answers all three.
\nDSE recommends an issuance register containing the accountable owner, intended resource scope, permissions, expiry and approval reference. Avoid placing usable bearer tokens in ordinary logs or tickets. Review identities that can bypass the approved issuer and label that limitation in any reported token count. Do not present the application’s ledger as complete evidence of every token another authorized principal might have created.
\nGenerate a narrowly scoped test signature through the approved workflow and confirm its metadata is recorded without exposing the token. Compare the record with the intended access and expiry. Review signing authority separately to identify issuers outside that workflow. Report known issued tokens and the tracking boundary explicitly; an empty service search is not evidence that no signatures exist.
\nMicrosoft Learn: Grant limited access to data with shared access signatures (SAS). Source retrieved September 9, 2026.
", "content_text": "Source facts\nA shared access signature is generated on the client side. Azure Storage does not track the resulting token, and Microsoft says token generation itself cannot be audited through the service. A principal with the relevant signing authority can generate a token without the storage account owner’s knowledge.\nStorage also does not track how many SAS tokens were generated, and no API supplies that count. Microsoft says organizations that need the number must maintain their own tracking. Microsoft Learn.\nApplicability\nIdentify the approved issuing applications, signing permissions and storage accounts. Keep issuance, observed use and current validity as separate questions rather than assuming one record answers all three.\nDSE recommendation\nDSE recommends an issuance register containing the accountable owner, intended resource scope, permissions, expiry and approval reference. Avoid placing usable bearer tokens in ordinary logs or tickets. Review identities that can bypass the approved issuer and label that limitation in any reported token count. Do not present the application’s ledger as complete evidence of every token another authorized principal might have created.\nVerification\nGenerate a narrowly scoped test signature through the approved workflow and confirm its metadata is recorded without exposing the token. Compare the record with the intended access and expiry. Review signing authority separately to identify issuers outside that workflow. Report known issued tokens and the tracking boundary explicitly; an empty service search is not evidence that no signatures exist.\nOfficial references\nMicrosoft Learn: Grant limited access to data with shared access signatures (SAS). Source retrieved September 9, 2026.", "content_markdown": "## Source facts\n\nA shared access signature is generated on the client side. Azure Storage does not track the resulting token, and Microsoft says token generation itself cannot be audited through the service. A principal with the relevant signing authority can generate a token without the storage account owner’s knowledge.\n\nStorage also does not track how many SAS tokens were generated, and no API supplies that count. Microsoft says organizations that need the number must maintain their own tracking. [Microsoft Learn](https://learn.microsoft.com/en-us/azure/storage/common/storage-sas-overview).\n\n## Applicability\n\nIdentify the approved issuing applications, signing permissions and storage accounts. Keep issuance, observed use and current validity as separate questions rather than assuming one record answers all three.\n\n## DSE recommendation\n\nDSE recommends an issuance register containing the accountable owner, intended resource scope, permissions, expiry and approval reference. Avoid placing usable bearer tokens in ordinary logs or tickets. Review identities that can bypass the approved issuer and label that limitation in any reported token count. Do not present the application’s ledger as complete evidence of every token another authorized principal might have created.\n\n## Verification\n\nGenerate a narrowly scoped test signature through the approved workflow and confirm its metadata is recorded without exposing the token. Compare the record with the intended access and expiry. Review signing authority separately to identify issuers outside that workflow. Report known issued tokens and the tracking boundary explicitly; an empty service search is not evidence that no signatures exist.\n\n## Official references\n\n[Microsoft Learn: Grant limited access to data with shared access signatures (SAS)](https://learn.microsoft.com/en-us/azure/storage/common/storage-sas-overview). Source retrieved September 9, 2026." }, "json_ld": { "@context": "https://schema.org", "@graph": [ { "@type": "Organization", "@id": "https://dsesecurity.com/#organization", "name": "Detection Systems & Engineering", "alternateName": "DSE Security", "url": "https://dsesecurity.com/", "logo": { "@type": "ImageObject", "url": "https://update.dsesecurity.com/assets/dse-logo-20260812.png?v=1.8.20" } }, { "@type": "Organization", "@id": "https://update.dsesecurity.com/#editorial-team", "name": "DSE Security Editorial Team", "url": "https://update.dsesecurity.com/", "parentOrganization": { "@id": "https://dsesecurity.com/#organization" } }, { "@type": "WebSite", "@id": "https://update.dsesecurity.com/#website", "name": "DSE Updates", "alternateName": "DSE Security Knowledge Hub", "url": "https://update.dsesecurity.com/", "inLanguage": "en-US", "publisher": { "@id": "https://dsesecurity.com/#organization" }, "potentialAction": { "@type": "SearchAction", "target": { "@type": "EntryPoint", "urlTemplate": "https://update.dsesecurity.com/?q={search_term_string}" }, "query-input": "required name=search_term_string" } }, { "@type": "WebPage", "@id": "https://update.dsesecurity.com/updates/dse-20260909-294-keep-sas-issuance-records-outside-azure-storage-s-token-inventory/", "url": "https://update.dsesecurity.com/updates/dse-20260909-294-keep-sas-issuance-records-outside-azure-storage-s-token-inventory/", "isPartOf": { "@id": "https://update.dsesecurity.com/#website" }, "lastReviewed": "2026-09-09" }, { "@type": "BreadcrumbList", "@id": "https://update.dsesecurity.com/updates/dse-20260909-294-keep-sas-issuance-records-outside-azure-storage-s-token-inventory/#breadcrumbs", "itemListElement": [ { "@type": "ListItem", "position": 1, "name": "DSE Updates", "item": "https://update.dsesecurity.com/" }, { "@type": "ListItem", "position": 2, "name": "Keep SAS issuance records outside Azure Storage's token inventory", "item": "https://update.dsesecurity.com/updates/dse-20260909-294-keep-sas-issuance-records-outside-azure-storage-s-token-inventory/" } ] }, { "@type": [ "Article", "TechArticle" ], "@id": "https://update.dsesecurity.com/updates/dse-20260909-294-keep-sas-issuance-records-outside-azure-storage-s-token-inventory/#article", "identifier": "https://update.dsesecurity.com/updates/dse-20260909-294-keep-sas-issuance-records-outside-azure-storage-s-token-inventory/", "url": "https://update.dsesecurity.com/updates/dse-20260909-294-keep-sas-issuance-records-outside-azure-storage-s-token-inventory/", "headline": "Keep SAS issuance records outside Azure Storage's token inventory", "description": "Azure Storage does not keep a count or inventory of client-generated SAS tokens, so an issuance register must come from the issuing process.", "abstract": "Azure Storage does not keep a count or inventory of client-generated SAS tokens, so an issuance register must come from the issuing process.", "articleBody": "Source facts\nA shared access signature is generated on the client side. Azure Storage does not track the resulting token, and Microsoft says token generation itself cannot be audited through the service. A principal with the relevant signing authority can generate a token without the storage account owner’s knowledge.\nStorage also does not track how many SAS tokens were generated, and no API supplies that count. Microsoft says organizations that need the number must maintain their own tracking. Microsoft Learn.\nApplicability\nIdentify the approved issuing applications, signing permissions and storage accounts. Keep issuance, observed use and current validity as separate questions rather than assuming one record answers all three.\nDSE recommendation\nDSE recommends an issuance register containing the accountable owner, intended resource scope, permissions, expiry and approval reference. Avoid placing usable bearer tokens in ordinary logs or tickets. Review identities that can bypass the approved issuer and label that limitation in any reported token count. Do not present the application’s ledger as complete evidence of every token another authorized principal might have created.\nVerification\nGenerate a narrowly scoped test signature through the approved workflow and confirm its metadata is recorded without exposing the token. Compare the record with the intended access and expiry. Review signing authority separately to identify issuers outside that workflow. Report known issued tokens and the tracking boundary explicitly; an empty service search is not evidence that no signatures exist.\nOfficial references\nMicrosoft Learn: Grant limited access to data with shared access signatures (SAS). Source retrieved September 9, 2026.", "datePublished": "2026-09-10T00:27:02+00:00", "dateModified": "2026-09-10T01:23:49+00:00", "mainEntityOfPage": { "@id": "https://update.dsesecurity.com/updates/dse-20260909-294-keep-sas-issuance-records-outside-azure-storage-s-token-inventory/" }, "inLanguage": "en-US", "isAccessibleForFree": true, "author": { "@type": "Organization", "name": "DSE Security Editorial Team", "url": "https://update.dsesecurity.com/#editorial-team" }, "publisher": { "@id": "https://dsesecurity.com/#organization" }, "image": { "@type": "ImageObject", "@id": "https://update.dsesecurity.com/updates/dse-20260909-294-keep-sas-issuance-records-outside-azure-storage-s-token-inventory/#primaryimage", "url": "https://update.dsesecurity.com/assets/editorial/network-infrastructure-social-v2.jpg?v=1.8.20", "contentUrl": "https://update.dsesecurity.com/assets/editorial/network-infrastructure-social-v2.jpg?v=1.8.20", "width": 1200, "height": 630, "caption": "Keep SAS issuance records outside Azure Storage's token inventory" }, "articleSection": [ "Cybersecurity", "Networks & Infrastructure" ], "keywords": [ "Cybersecurity", "Networks & Infrastructure", "Guide", "Information priority" ], "genre": "Guide", "about": [ { "@type": "Thing", "name": "Cybersecurity", "url": "https://update.dsesecurity.com/topic/cybersecurity/" }, { "@type": "Thing", "name": "Networks & Infrastructure", "url": "https://update.dsesecurity.com/topic/networks-infrastructure/" } ], "wordCount": 250, "timeRequired": "PT2M", "publishingPrinciples": "https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/", "usageInfo": "https://update.dsesecurity.com/usage/", "copyrightHolder": { "@id": "https://dsesecurity.com/#organization" }, "copyrightNotice": "Copyright © 2026 Detection Systems & Engineering. All rights reserved.", "citation": { "@type": "CreativeWork", "name": "Grant limited access to data with shared access signatures (SAS) - Azure Storage | Microsoft Learn", "url": "https://learn.microsoft.com/en-us/azure/storage/common/storage-sas-overview" } } ] } }