# Shared access

> Source: Courseiva IT Certification Glossary — https://courseiva.com/glossary/shared-access

## Quick definition

Shared access means giving multiple people or systems permission to use the same resource, like a folder on a network or a cloud storage bucket. It often involves managing who can read, write, or delete files. Proper shared access controls help prevent data leaks and unauthorized changes. It is a fundamental concept in IT security and cloud administration.

## Simple meaning

Imagine you live in a house with several roommates. You all share the living room, kitchen, and bathroom. Each of you can use these spaces, but you probably have rules about who can move your stuff or when the TV is on. Shared access in IT is very similar. It is about allowing more than one person or computer to use a specific file, folder, database, or cloud resource. But just like in a house, you need rules to keep things organized and safe. In the digital world, those rules are called permissions. For example, you might let everyone in a team read a project document, but only the project lead can edit it. You might allow all employees to view a company calendar, but only HR can add or remove events. Shared access is everywhere in IT. It powers shared network drives at work, cloud storage like Google Drive or OneDrive, databases that many apps connect to, and even shared folders on your home network. The key challenge is balancing convenience with security. If you give everyone full access, it is easy to work together, but someone might accidentally delete important files. If you restrict access too much, people cannot do their jobs efficiently. That is why IT professionals need to understand shared access deeply. It is not just about saying yes or no. It is about choosing the right type of access for each person or system. Some systems use Access Control Lists (ACLs) to define exactly who can do what. Others use role-based access control (RBAC), where people get permissions based on their job role. There are also shared access signatures (SAS) used in cloud platforms like Azure, which give temporary, limited access to a resource without sharing your main password. Think of shared access like giving a friend a key to your house but only for a specific time and only to the guest room. That is the idea behind many secure shared access models. When you study for IT certifications, you will see shared access pop up in many contexts: network file permissions, cloud storage policies, database user roles, and even Wi-Fi network sharing. Understanding it well helps you design systems that are both collaborative and secure. In short, shared access is a foundational idea that connects teamwork with digital safety.

## Technical definition

Shared access in information technology refers to the practice of granting multiple principals-users, groups, services, or applications-the ability to interact with a single resource, such as a file, folder, database table, storage container, or network endpoint. The implementation of shared access varies depending on the resource type, the operating system, the cloud platform, and the security model in use. At its core, shared access is governed by an access control mechanism that defines who can perform which actions on a resource. The most common models include Discretionary Access Control (DAC), Mandatory Access Control (MAC), and Role-Based Access Control (RBAC). In Windows environments, shared access to files and folders is managed through NTFS permissions and share permissions. NTFS permissions are more granular and apply locally, while share permissions apply when accessing the resource over the network. The effective permission is the most restrictive combination of both. For example, if NTFS permissions allow Read and Write but share permissions only allow Read, the effective permission is Read. In Linux and Unix-like systems, shared access is managed through file permission bits (read, write, execute) for the owner, group, and others, and more granularly through Access Control Lists (ACLs) using tools like setfacl and getfacl. ACLs allow specifying permissions for multiple users or groups beyond the traditional three-tier model. In cloud environments, shared access takes on additional complexity. On Amazon Web Services (AWS), shared access to S3 buckets is controlled through bucket policies, Identity and Access Management (IAM) policies, and Access Control Lists. AWS also supports presigned URLs that grant temporary shared access to specific objects without requiring AWS credentials. On Microsoft Azure, shared access is implemented via Shared Access Signatures (SAS) for Azure Storage accounts. A SAS token can be scoped to a specific service (blob, queue, table, file), a specific resource, a set of permissions (read, write, delete, list), and a validity period. This allows a user or application to access the resource without exposing the storage account key. Azure also supports shared access at the network level through Azure Firewall rules and Network Security Groups (NSGs). In database systems, shared access is crucial for multi-user concurrency. Relational databases like SQL Server, MySQL, and PostgreSQL use roles, schemas, and GRANT/REVOKE statements to control what each user or application can access. Shared access here also involves transaction isolation levels to prevent conflicts like dirty reads or lost updates. In networking, shared access refers to multiple devices using the same network medium, such as in a shared Ethernet segment (though this is now rare due to switching) or in Wi-Fi networks with shared security keys. In modern enterprise environments, shared access is often managed through identity providers like Azure Active Directory (now Microsoft Entra ID) or AWS IAM Identity Center. These systems enable single sign-on (SSO) and conditional access policies that dynamically grant or deny shared access based on user location, device compliance, and risk level. Protocols like OAuth 2.0 and SAML 2.0 facilitate secure delegated access, allowing third-party applications to access resources on behalf of a user without sharing the user’s credentials. Security considerations for shared access include the principle of least privilege-granting only the minimum permissions necessary. Audit logging is essential to track who accessed what and when. Shared access also introduces risks such as unintended data exposure, privilege escalation, and compliance violations. Therefore, IT professionals must regularly review shared access permissions and implement rotation or expiry policies for shared credentials or tokens. Shared access is a multi-faceted concept that spans operating systems, cloud platforms, databases, and networks. Its correct implementation is critical for both collaboration and security in any IT environment.

## Real-life example

Imagine you are organizing a large community potluck dinner in your neighborhood. You have a big community kitchen that everyone can use, but you need to coordinate access so that food is prepared safely and no one gets in each other's way. Shared access in this scenario works like this: You decide who can enter the kitchen (the users), what they can use (the resources), and what they are allowed to do there (the permissions). Let us say you have three types of volunteers: chefs, helpers, and cleaners. Chefs are allowed to use the stove, ovens, and knives. Helpers can wash vegetables and set tables, but they are not allowed to touch the stove. Cleaners can use the sinks and cleaning supplies, but they cannot touch the food prep areas. If you gave everyone full access to everything, the kitchen would be chaotic. A helper might accidentally burn a dish, or a cleaner might knock over a pot of soup. That is why you need a shared access plan. You might give each volunteer a key card that opens only the doors they need. The chefs' key cards open the pantry, the stove area, and the refrigerator. Helpers' cards open the prep area and the dining room. Cleaners' cards open the storage closet and the dishwashing area. This is exactly how shared access works in IT. On a computer network, a folder might be accessible to the marketing team but not to finance. Within that folder, certain files might be read-only for most people but editable for the team lead. In the cloud, you might create a shared storage container and give your partners a special token (like a temporary access code) that lets them upload files for only one week. That token is like giving a neighbor a one-time code to enter your community garden. They can enter the garden, water the plants (upload), but they cannot lock the gate (change permissions). This real-life analogy helps to understand that shared access is about defining boundaries and rules. It is not about locking everything down, but about enabling collaboration in a controlled way. Just as you would not give a stranger full run of your kitchen, you should not give a user full access to a sensitive server. By thinking of shared access as managing keys and permissions in a physical space, you can more easily grasp why IT administrators put so much effort into setting up user roles, groups, and policies. It is all about letting the right people do the right things at the right time.

## Why it matters

Shared access is not just a technical checkbox; it is a fundamental operational and security concern for any organization that uses digital resources. In practice, nearly every IT environment involves shared access to some degree. Employees need to collaborate on documents, systems need to exchange data, and external partners may require temporary access to specific resources. Without a well-designed shared access model, organizations face several serious risks. The most immediate risk is data breach. If a user has broader permissions than necessary, they might accidentally expose sensitive information. For example, a shared folder containing customer payment details should never be writable by the entire company. Similarly, if shared access tokens or keys are not rotated regularly, they can be stolen and used by attackers. The 2021 Microsoft Exchange breach, for instance, exploited shared access configurations that were too permissive. Another practical concern is operational inefficiency. When shared access is too restrictive, employees cannot do their jobs. They might be unable to access a critical file or database, leading to delays and frustration. On the other hand, when access is too open, the risk of accidental deletion or modification increases. Many IT administrators have dealt with a user who accidentally deleted an entire shared folder because they had full control permissions. In regulated industries like healthcare (HIPAA) or finance (PCI DSS), shared access must be carefully controlled and audited. Compliance frameworks require that organizations maintain a clear record of who has access to what, and that shared access is revoked when no longer needed. Failure to do so can result in hefty fines and legal consequences. From a career perspective, understanding shared access is essential for passing several IT certifications, including AWS SAA, Security+, CISSP, Azure AZ-104, and others. These exams test not only the theory but also practical scenarios where you must choose the correct access control method. For example, you might be asked to design a solution that allows a third-party vendor to upload reports to an S3 bucket for only 24 hours. That requires knowledge of presigned URLs or temporary credentials. Overall, shared access matters because it directly impacts security, productivity, and compliance. IT professionals who master this concept can design systems that are both secure and user-friendly, which is exactly what employers and certification boards look for.

## Why it matters in exams

Shared access is a recurring theme across many IT certification exams, and it often appears in scenario-based questions that test your ability to apply the right access control model. In the AWS Solutions Architect Associate (SAA-C03) exam, shared access is central to topics like S3 bucket policies, IAM roles, and presigned URLs. You may be asked to grant a user temporary write access to an S3 object without creating a new IAM user. The correct answer would involve a presigned URL. Another typical question asks how to securely share an S3 bucket with another AWS account. The solution is to use a bucket policy that grants cross-account access, not to share the root credentials. In the CompTIA Security+ exam, shared access appears under domain 3.0 (Implementation) and domain 4.0 (Operations and Incident Response). Questions often focus on the principle of least privilege, access control lists (ACLs), and group-based permissions. You might be given a scenario where a user has more access than needed to perform their job, and you must recommend a solution. Security+ also tests your understanding of shared access in the context of cloud storage and network shares. For the (ISC)² CISSP exam, shared access is part of the Identity and Access Management (IAM) domain. You need to understand DAC, MAC, RBAC, and attribute-based access control (ABAC). Questions can be complex, requiring you to analyze a scenario and determine which access control model best meets security and business requirements. For example, a question might describe a government agency needing mandatory access labels and ask you to pick MAC. In the Microsoft Azure exams (AZ-104, SC-900, MD-102, MS-102), shared access is heavily focused on Azure Storage shared access signatures (SAS), Azure RBAC, and Azure Active Directory. You will need to know how to create a SAS token, the difference between user delegation SAS and account SAS, and how to assign roles to security groups. A common question on AZ-104 asks you to provide a partner with limited-time access to a blob container. The correct answer is to generate a SAS token with appropriate permissions and expiry. For MD-102 (Managing Modern Desktops), shared access relates to shared PC configurations and OneDrive sharing settings. In CySA+, questions may involve analyzing log files to detect anomalies in shared access patterns, such as a user accessing a resource at an unusual time or from an unusual location. Understanding shared access helps you interpret these events correctly. Shared access appears in multiple forms across different exams, from storage and networking to identity management and compliance. Knowing the specific implementation of shared access on each platform is key to scoring well. The most common question types are scenario-based and configuration-based, where you choose the correct method to grant access securely. Always remember the principle of least privilege and the importance of temporary, scoped access.

## How it appears in exam questions

Exam questions about shared access generally fall into three categories: scenario-based, configuration-based, and troubleshooting-based. In scenario-based questions, you are given a situation and must choose the best way to implement shared access. For example, on the AWS SAA exam, a question might read: 'A company needs to allow a third-party vendor to upload log files to an S3 bucket. The vendor should not have permanent access and should only be able to upload, not read or delete existing files. What should the solution architect do?' The answer involves creating a bucket policy that allows upload only, and using a presigned URL or temporary credentials from AWS STS. On the Azure AZ-104 exam, a scenario might ask: 'Your organization wants to share a large file with a client for 48 hours. The file is stored in Azure Blob Storage. You need to ensure the client does not need an Azure account. What should you create?' The answer is an SAS (shared access signature) with read permission and an expiry time of 48 hours. In configuration-based questions, you might be shown a snippet of JSON policy or a PowerShell command and asked to identify what access it grants. For example, an AWS IAM policy that allows 's3:GetObject' on a specific bucket for a specific IP range. You need to interpret that the user can only read objects from that bucket from the allowed IP addresses. On the Security+ exam, you might see a question about NTFS vs share permissions. 'A user is trying to access a shared folder from a remote computer. The NTFS permissions allow Full Control, but the share permissions only allow Read. What is the user's effective permission?' The correct answer is Read, because effective permission is the most restrictive. Troubleshooting-based questions test your ability to diagnose why a user cannot access a shared resource. For example, a user reports they cannot access a network drive. You might need to check group membership, share permissions, NTFS permissions, and firewall rules. On the CySA+ exam, a prompt might give you a log entry showing an access attempt denied and ask you to identify the likely cause-maybe the user's IP is not in the allowed list, or the SAS token has expired. In all these cases, the key is to think in terms of identity, resource, permission, and scope. Remember that shared access always involves a balancing act: you want to enable collaboration but limit exposure. Always look for keywords like 'temporary', 'least privilege', 'expiration', 'read-only', and 'specific user' because they hint at the correct answer.

## Example scenario

A small marketing agency, CreativeAds, uses Google Workspace for collaboration. They have a shared Google Drive folder called 'Client Campaigns' that all employees can access. The folder contains subfolders for each client. The agency recently hired a freelance graphic designer, Sarah, to work on a banner for Client X. They want Sarah to be able to upload her design files to the Client X subfolder, but she should not see any other client folders or modify existing files. How do they set up shared access? The IT admin goes to the Google Drive settings and creates a new folder called 'Client X - Banners'. They share this specific folder with Sarah using her email address. They set the permissions to 'Editor' (which allows upload, edit, and delete) because she needs to upload and possibly delete old drafts. However, they do NOT give her access to the parent 'Client Campaigns' folder or any other client folder. Sarah receives an email invitation. She clicks the link and can now see only the 'Client X - Banners' folder. She can upload her files, but she cannot see any other folders in the agency’s shared drive. This is a clean example of shared access with least privilege. The agency provided exactly the access needed-no more, no less. If Sarah later needs access to another client's folder, the admin can share that specific folder separately. After the project ends, the admin can remove Sarah's permissions entirely. This scenario mirrors what you might face on a certification exam. For instance, on the AZ-104 exam, you might use Azure Blob Storage and create a container with an SAS token that only allows write access to a specific blob path. Or on AWS SAA, you would use an S3 bucket policy with a condition that limits access to a specific prefix. The underlying principle is always the same: grant access only to the necessary resource with only the necessary permissions, and limit the duration if possible.

## Shared Access Fundamentals and Exam Context

Shared access is a foundational security and resource management model in cloud computing, heavily tested across AWS, Azure, and CompTIA exams. At its core, shared access refers to the practice of granting multiple entities-users, applications, services, or external partners-permissions to use a single resource or set of resources without requiring dedicated ownership or full administrative control. This model underpins the principle of least privilege, as shared access is typically scoped to specific actions, timeframes, and conditions. In AWS, shared access manifests through IAM roles, resource-based policies, and presigned URLs for S3 objects. Azure implements it via Shared Access Signatures (SAS) and Azure AD conditional access policies. For the Security+ and CySA+ exams, shared access is tied to identity federation, federated trust, and delegation of permissions. On the CISSP, shared access is a key component of the Identity and Access Management (IAM) domain, emphasizing the need for accountability and audit trails when multiple principals access the same data plane. Understanding the difference between user-based and resource-based policies is critical: user-based policies attach permissions directly to an identity, while resource-based policies attach permissions to the resource itself, allowing cross-account access. Another crucial nuance is that shared access should always be temporary and revocable-never permanent. Exam questions frequently test your ability to identify when a SAS token or an IAM role trust policy violates the principle of least privilege by granting overly broad permissions, such as full control instead of read-only or write-only scopes. Shared access often integrates with encryption keys, logging via CloudTrail or Azure Monitor, and monitoring for anomalous usage patterns. In the MD-102 and MS-102 exams, shared access models for Microsoft Endpoint Manager and Intune allow delegated administration for device management without granting full global admin rights. The SC-900 exam focuses on the shared responsibility model, where shared access must be governed by Microsoft Entra ID policies like Conditional Access and Identity Protection. Overall, mastery of shared access requires being able to articulate exactly what permissions are granted, to whom, for how long, under what conditions, and how to audit that access effectively.

## How Shared Access Affects Cost and Billing in Cloud Exams

Shared access has a direct and often underestimated impact on cloud cost management. Exam questions in the AWS SAA, AZ-104, and MS-102 frequently test your ability to distinguish between cost allocation and authorization. Shared access itself does not incur direct billing-charges are always linked to the underlying resource owner's account-but improper configuration can lead to data transfer egress costs, storage retrieval charges, and compute cycles triggered by unintended usage. For example, generating a highly permissive shared access signature (SAS) for an Azure Blob Storage container can allow an external application to download terabytes of data, incurring substantial egress fees. Similarly, an AWS presigned URL for an S3 object with no expiration can become a data leak vector, generating bandwidth costs from relentless scraping. The cost dimension is especially critical when shared access crosses cloud regions or cloud providers. AWS data transfer out to the internet costs between $0.05 and $0.09 per GB, while Azure egress is around $0.087 per GB. If a shared access link allows an unauthorized external party to stream data, the monthly bill can skyrocket overnight. In the AZ-104 exam, you may be asked to recommend a lifecycle management policy or a storage tier that reduces cost when shared access triggers frequent reads. For the AWS SAA, you must know that S3 Object Lock and versioning do not affect shared access costs directly, but enabling them increases storage costs per object. In the MS-102 exam, shared access to Microsoft 365 resources, such as sharing a Power BI dashboard or a SharePoint site externally, can cause licensing surprises if external users need a paid license to view premium content. Cost allocation tags are essential to track which teams or projects are using shared access. The exam clue is that shared access cost is not a separate line item; it must be inferred through monitoring data transfer, request rates, and storage usage. Another exam point is the use of policy conditions to restrict IP addresses or time windows for shared access, which directly limits cost exposure. For instance, an Azure SAS token with a start time and end time prevents indefinite egress. In cost optimization scenarios, shared access should be replaced with managed identities or service principals where possible, to centralize auditing and reduce the need for shared keys. Finally, remember that shared access for cross-account roles in AWS (using IAM roles) incurs no additional cost, but the role itself must be regularly reviewed to avoid idle resource consumption. By understanding these cost implications, you can answer exam questions about cost control without losing sight of security.

## Shared Access States, Permissions, and Revocation Patterns

Shared access exists in multiple states that determine the lifecycle and risk level of a permission grant. Understanding these states is vital for the AWS SAA, CISSP, Security+, and MS-102 exams because they directly test your ability to audit, manage, and revoke access. The primary states are: pending, active, expired, revoked, and suspended. Some platforms like Azure also have a delegated state when permissions are inherited from a parent scope. In AWS, a shared access state is typically derived from the policy evaluation logic: a resource-based policy is in an active state from the moment it is attached, unless it contains a Deny condition. Revocation in AWS requires either deleting the policy, removing the principal, or using a Service Control Policy (SCP) at the organization account level. In Azure, SAS tokens have an explicit startup time (st) and expiry time (se), so their state transitions from pending to active to expired automatically. Revocation of a SAS token before its expiry requires regenerating the storage account key or modifying the stored access policy that controls it-an action that can break all active shared access for that service. This nuance is a favorite exam trap: regenerating a key invalidates all SAS tokens signed with that key. Therefore, Azure recommends using user-delegated SAS with managed identities or stored access policies for granular revocation without affecting other access. Another state specific to shared access is the 'delegated' state in Azure RBAC where a user grants permission to a service principal via a built-in role assignment-this can be active indefinitely if not patrolled. In the CISSP, shared access states are part of the identity lifecycle management domain, where a 'suspended' state may occur when an account is disabled but the shared access token remains valid. This is a security concern and explains why periodic reviews (attestations) are mandatory. The CompTIA Security+ exam tests the concept that shared access tokens should have a maximum lifetime (e.g., 1 hour for administrative operations) and that manual revocation should always be possible. In the MS-102 exam, managing shared access states involves the Microsoft Entra admin center, where you can disable a user's shared access to SharePoint or Teams sites without deleting the site itself. Another key concept is the 'orphaned' state, where a shared access permission tied to a deleted user or service principal still exists. This is a major security gap and is often tested in scenario-based questions where you must identify the correct order of steps to remove the orphaned permission. To sum up, shared access states are not just theoretical-they appear in exam questions as lifecycle scenarios where you choose the correct method to terminate or modify access without causing downtime.

## Shared Access Audit, Monitoring, and Alerting for the Cloud

Effective audit and monitoring of shared access is a critical capability tested in every related exam, including AWS SAA, AZ-104, MS-102, CySA+, Security+, CISSP, and SC-900. Shared access generates logs whenever a resource is accessed using a shared identity or token. These logs must be collected, analyzed, and alerted upon to detect misuse, data exfiltration, or policy violations. In the AWS cloud, CloudTrail records all S3 bucket-level actions (like PutObject, GetObject) along with the source IP, user agent, and whether the request was made via a presigned URL. However, CloudTrail does not reveal the presigned URL itself-only the signature version and key ID. This is a common trick question: you cannot retrieve the actual token from CloudTrail. In Azure, Storage Analytics logs capture SAS token usage, including the signed service, signed resource type, and expiry time. The SC-900 exam emphasizes that Azure Monitor can trigger an alert when a SAS token is used from an anonymous IP range. In CySA+, the focus is on anomaly detection: if a shared access token is used from a geographic location different from the owner's usual region, that is a red flag. The CISSP exam tests the principle of non-repudiation in shared access contexts-meaning logs must be immutable and time-stamped to serve as evidence. For Azure, this means enabling log storage in a Log Analytics workspace with a retention policy of at least 365 days for compliance. In the MS-102 exam, monitoring shared access to Microsoft 365 resources requires the use of Microsoft Purview compliance portal, specifically the Audit (Premium) logs, which record when an externally shared link is created, accessed, or modified. A crucial exam clue is the existence of 'shadow permissions'-shared access that was granted via a direct email link without going through proper approval workflow. This is detected by auditing creation of sharing invitations and comparing them against policy. In AWS, you can use IAM Access Analyzer to find resources shared externally via resource-based policies (e.g., S3 bucket policies that allow anonymous access). Access Analyzer generates findings when it detects such policies, and it must be enabled at the organization level. For the AZ-104 exam, you must remember that shared access monitoring also covers Azure Key Vault, where SAS tokens might be stored. If a key vault stores an SAS token, and that vault's access policy allows broad access, it becomes a point of escalation. Therefore, monitoring must include queries for resources that reference shared access tokens in key vault secrets. Another less obvious monitoring point is the 'user-agent' field in logs-common tools used by attackers (e.g., curl, Python requests) often have distinctive user-agent strings. Sharing access audit logs should be inspected for unusual user-agent patterns. Finally, all exams stress that alerting must be proactive: configure a metric filter for 'SAS token used after expiry' in AWS CloudWatch or Azure Alerts, because an expired token indicates a clock skew or a potential replay attempt. By understanding these monitoring specifics, you will be prepared to answer questions about detection, response, and remediation of shared access risks.

## Common mistakes

- **Mistake:** Granting full control permissions (like Full Control in NTFS or * in S3 bucket policies) when read-only is sufficient.
  - Why it is wrong: Full control allows users to modify, delete, or change permissions on resources. This increases the risk of accidental data loss or unauthorized changes. It violates the principle of least privilege.
  - Fix: Always start with the minimum permissions needed. For example, if users only need to view files, grant read permission. Only escalate if a clear business need exists.
- **Mistake:** Sharing storage account keys (e.g., Azure Storage account key or AWS access keys) instead of using shared access signatures or IAM roles.
  - Why it is wrong: Storage account keys grant full administrative access to all data in the storage account. If shared, the key could be leaked and used by an attacker to access, modify, or delete all blobs, queues, or tables.
  - Fix: Use SAS tokens with limited permissions and expiry times for temporary access. For applications, use managed identities or IAM roles instead of keys.
- **Mistake:** Forgetting to set an expiration time when granting temporary shared access (e.g., SAS token or presigned URL).
  - Why it is wrong: Without an expiration, the access token remains valid indefinitely. If the token is exposed, an attacker could use it at any time to access resources. This is a common security oversight.
  - Fix: Always set a reasonable expiry, such as 24 hours or 7 days. For long-term access, use proper IAM roles with periodic reviews rather than tokens.
- **Mistake:** Confusing NTFS permissions with share permissions when troubleshooting network folder access.
  - Why it is wrong: When accessing a folder over the network, both NTFS and share permissions apply. The effective permission is the most restrictive of the two. Many beginners only check one set and assume the user can access.
  - Fix: When troubleshooting, check both NTFS and share permissions. Remember that the more restrictive permission wins. Use the Effective Permissions tab in Windows to see the combined result.
- **Mistake:** Using a public ACL (e.g., S3 bucket ACL set to public-read) to share files with specific individuals instead of using IAM or presigned URLs.
  - Why it is wrong: Making a bucket or object publicly accessible means anyone on the internet can read or write to it, not just the intended person. This is a major security risk and can lead to data exposure or high costs.
  - Fix: Use IAM policies for users within your organization, or use presigned URLs for external sharing. Public ACLs should only be used for static websites or truly public content.

## Exam trap

{"trap":"In AWS SAA, a question asks you to share an S3 bucket with another AWS account. The trap option is to create a new IAM user in your account and give the other account the access key and secret key.","why_learners_choose_it":"Learners think that creating a user and sharing credentials is the easiest way. They may not understand that sharing keys is insecure and violates best practices. They also might not be aware of cross-account IAM roles or bucket policies.","how_to_avoid_it":"Remember that you should never share your own IAM user credentials with another account. Instead, use a bucket policy with a Principal that specifies the other account's root user or an IAM role in that account. Alternatively, use an IAM role in your account that grants cross-account access. Always choose the option that does not involve sharing secrets."}

## Commonly confused with

- **Shared access vs Shared access vs. Public access:** Shared access grants permissions to specific users, groups, or applications, while public access allows anyone on the internet to perform actions (e.g., read a file). Shared access is controlled and logged; public access is open and often anonymous. For example, an Azure Blob container with public access allows anyone to view its contents, whereas a container with a shared access signature only allows users with the SAS token. (Example: Your cloud storage folder: public access means anyone with the link can view files; shared access means only people you invite can view them.)
- **Shared access vs Shared access vs. Role-Based Access Control (RBAC):** Shared access is a broad concept that describes any mechanism allowing multiple principals to use a resource. RBAC is a specific model where permissions are assigned to roles, and users are assigned to roles. Shared access can be implemented via ACLs, tokens, or policies; RBAC is more structured and scalable. For example, in Azure, RBAC assigns roles like Contributor or Reader to users, while an SAS token gives shared access without requiring a role assignment. (Example: RBAC is like giving employees keys based on their job title; shared access is like giving a visitor a temporary keycard to a specific room.)
- **Shared access vs Shared access vs. Delegated access:** Delegated access is a subtype of shared access where a user or service grants permissions to another entity to act on their behalf, often using OAuth 2.0. Shared access can be direct (e.g., I give you read permission) or delegated (e.g., I allow an app to read my calendar). Delegated access involves tokens that represent the user's consent, while direct shared access is permission granted by an administrator. (Example: Shared access is like lending your friend your house key; delegated access is like allowing a dog walker to enter only the living room using a smart lock code you set.)
- **Shared access vs Shared access vs. Single sign-on (SSO):** SSO is an authentication mechanism that allows users to log in once and access multiple applications without re-entering credentials. Shared access is about authorization-what resources a user can access after authentication. You can have SSO without shared access (user can only see their own files) and shared access without SSO (each app requires login but grants access to shared resources). (Example: SSO is like a master key that opens many doors; shared access is the permission to enter a specific room in a building.)

## Step-by-step breakdown

1. **Identify the resource to be shared** — Determine exactly what resource needs shared access: a file, folder, database, storage container, API endpoint, etc. The type of resource dictates the access control mechanisms available. For example, an S3 bucket has bucket policies and ACLs, whereas a SQL database uses GRANT statements.
2. **Identify who needs access** — Define the principal(s) requiring access. They could be individual users, groups, applications (service principals), or entire external organizations. In Azure, this means specifying users in Azure AD or security groups. In AWS, it means IAM users, roles, or federated identities.
3. **Define the required permissions** — Specify exactly what actions the principal needs to perform: read, write, delete, list, execute. Use the principle of least privilege. For example, if they only need to view a file, grant read permission, not full control. Over-granting is a common mistake.
4. **Choose the access control method** — Select the appropriate mechanism for the platform. Options include IAM policies (AWS), RBAC roles (Azure), SAS tokens (Azure), presigned URLs (AWS), ACLs (both), or share permissions (Windows). The method should align with security requirements and the type of sharing (internal vs external, temporary vs permanent).
5. **Implement the access control configuration** — Write the policy, create the role, generate the token, or set the permissions. For example, in AWS you might attach a bucket policy that allows s3:PutObject for a specific IAM role. In Windows, you set NTFS and share permissions via the folder properties. In Azure, you generate an SAS token with appropriate settings.
6. **Test the shared access** — Verify that the intended user or system can access the resource with the expected permissions. Try performing allowed actions (read, write) and disallowed actions (delete if not permitted). Ensure there are no unintended side effects, like the user seeing other resources they should not see.
7. **Set expiry and rotation policies** — For temporary access, set an expiration time on the token or policy. For long-term access, schedule periodic reviews of permissions. Implement credential rotation for keys and tokens. For example, Azure SAS tokens should have a reasonable expiry time, and AWS IAM keys should be rotated every 90 days.
8. **Audit and monitor access** — Enable logging to track who accessed what resource, when, and from where. Use tools like AWS CloudTrail, Azure Monitor, or Windows Event Viewer. Monitor for unusual patterns, such as access from unexpected IP addresses or at unusual times. This helps detect misuse or compromised credentials.

## Practical mini-lesson

As an IT professional, understanding shared access in practice means you can both enable collaboration and enforce security. Let us walk through a real-world implementation on Microsoft Azure, which is commonly tested in AZ-104 and SC-900. Imagine you work for a company that stores customer onboarding documents in Azure Blob Storage. The sales team needs to upload documents to a container called 'onboarding', but only for their own customer folder (e.g., 'onboarding/customer123'). The legal team needs read-only access to all documents. You must implement shared access without exposing the storage account key. Step one: Create a storage account and a container named 'onboarding'. Step two: Create two Azure AD groups: 'SalesTeam' and 'LegalTeam'. Step three: Assign RBAC roles. For the SalesTeam, you assign the 'Storage Blob Data Contributor' role, but you scope it to the container level. However, SalesTeam should only write to their own customer folder. The Contributor role at container level allows them to write anywhere in the container. To restrict further, you need to use a custom role or use Azure Storage ACLs at the blob level (which is limited). A better approach is to use a Shared Access Signature (SAS) for each salesperson's customer folder. You generate a user delegation SAS (which uses Azure AD credentials) for the specific path 'customer123' with write permission and a 24-hour expiry. The salesperson uses that SAS URI to upload files. For legal team, you assign the 'Storage Blob Data Reader' role at the container level, granting read access to all blobs in the container. This is simpler because they need broad access. Now, what can go wrong? First, if the SAS token expiry is too long (e.g., one year), a leaked token could be used by an attacker for months. Always set the shortest practical expiry. Second, if you accidentally give the SalesTeam the 'Storage Blob Data Owner' role, they can delete or modify permissions. Third, if the legal team's role is applied at the storage account level instead of container level, they would have read access to all containers, not just 'onboarding'. Always scope roles precisely. In exam questions, you will be asked to choose between RBAC and SAS. For internal users with ongoing needs, use RBAC. For external partners or temporary scenarios, use SAS. For fine-grained control over individual blobs, consider using Azure Blob Storage ACLs (which support limited permissions) or a custom solution. Remember that shared access is not a one-time setup; it requires ongoing management and review. Regularly audit who has access to what using tools like Azure AD access reviews or AWS IAM Access Analyzer. This practical approach reflects what administrators do daily and what certification exams expect you to know.

## Commands

```
az storage container generate-sas --account-name mystorage --name mycontainer --permissions rl --expiry 2025-01-01T00:00:00Z --https-only
```
Generates a read-and-list shared access signature (SAS) token for an Azure Blob Storage container, restricted to HTTPS and with a defined expiration.

*Exam note: Tests understanding of SAS token scoping, permission flags (r=read, l=list), and the --https-only flag required for secure access.*

```
aws s3 presign s3://mybucket/myfile.txt --expires-in 3600
```
Creates a presigned URL for an S3 object that grants temporary access for 3600 seconds (1 hour).

*Exam note: Exam questions often focus on the default expiration and the fact that presigned URLs inherit the requester's IAM permissions, not the bucket policy.*

```
New-AzStorageContext -StorageAccountName 'mystorage' -UseConnectedAccount; New-AzStorageAccountSASToken -Service Blob -ResourceType Service,Container,Object -Permission 'r' -ExpiryTime (Get-Date).AddHours(2)
```
Creates a user-delegated SAS token for an Azure Storage account using the caller's Azure AD identity, valid for 2 hours.

*Exam note: Tests the concept of delegation versus key-based SAS; the user-delegated SAS avoids sharing the storage account key and is revocable via Azure AD.*

```
aws iam create-role --role-name ExternalAccessRole --assume-role-policy-document file://trust-policy.json
```
Creates an IAM role with a trust policy that allows cross-account access (the trust policy file specifies the external account ID and conditions).

*Exam note: Exams test the trust policy condition elements (e.g., aws:SourceArn) to prevent the confused deputy problem when sharing access across accounts.*

```
Set-AzStorageAccount -ResourceGroupName 'myRG' -Name 'mystorage' -MinTlsVersion TLS1_2 -AllowBlobPublicAccess $false
```
Updates an Azure Storage account to require TLS 1.2 and disable anonymous Blob public access, enforcing shared access only through SAS or Azure AD.

*Exam note: Tests the knowledge that disabling public access is a prerequisite for secure shared access; exam scenarios often contrast anonymous access vs. SAS-only access.*

```
aws s3api put-bucket-policy --bucket mybucket --policy file://policy.json
```
Applies a resource-based policy to an S3 bucket that grants specific cross-account access (e.g., allowing an AWS account ID to list objects).

*Exam note: This command is used to implement shared access via bucket policies; exams test the difference between bucket policies and IAM policies for cross-account scenarios.*

```
az role assignment create --assignee 'user@contoso.com' --role 'Storage Blob Data Reader' --scope '/subscriptions/.../resourceGroups/myRG/providers/Microsoft.Storage/storageAccounts/mystorage'
```
Assigns the Storage Blob Data Reader role to a user for a specific storage account, granting shared read access via Azure RBAC.

*Exam note: Tests the concept of Azure RBAC for shared access; the question may ask which role provides least privilege for reading blobs without write permissions.*

```
Get-AzStorageAccessPolicy -ContainerName 'mycontainer' -ResourceGroupName 'myRG' -StorageAccountName 'mystorage'
```
Lists all stored access policies for an Azure Blob Storage container, which are used to control SAS tokens.

*Exam note: Exam questions often ask how to revoke a SAS token without regenerating the account key; the correct method is to modify or delete the stored access policy on the container.*

## Troubleshooting clues

- **Expired SAS token still accepting requests** — symptom: Users can still download files using a token that should have expired, generating unexpected billing and security concerns.. Clock skew between the client and server, or the SAS token was generated without an end time or with a very long expiry. Azure and AWS both use UTC with tolerance for skew, but if the client clock is significantly behind, the token may still be considered valid by the server within the clock skew window (typically 15 minutes). (Exam clue: Exam questions might present a scenario where an admin creates a SAS token with a 1-hour expiry but sees usage after 1 hour and 10 minutes; the answer is clock skew tolerance.)
- **Presigned URL not working from a different IP address** — symptom: An AWS presigned URL works from the developer's IP but fails when sent to a customer in a different geographic region.. The presigned URL inherits the IAM conditions of the creator. If the IAM user has an IP address condition that restricts access to a specific IP range, the presigned URL will only work from that range, even if the URL itself contains no IP restriction. The URL is not a separate identity; it is a signed request with the same permissions. (Exam clue: This is a common exam trick: a presigned URL is not a free pass-it carries the same constraints as the issuing IAM user's policy.)
- **Shared access link works for read but fails for write operations** — symptom: A user can download files from a shared folder but cannot upload or modify them, even though the token was supposed to grant write permissions.. The SAS token or presigned URL may have been generated with read-only permissions (e.g., 'r' instead of 'rw'), or the underlying resource policy denies write access. In Azure, if the container-level stored access policy assigns only read, the token cannot override that with write. (Exam clue: Exam questions test the hierarchy of permissions: stored access policies override SAS token permissions. The token cannot grant more than the policy allows.)
- **Cross-account IAM role unable to assume the role in target account** — symptom: A user in Account A tries to switch to a role in Account B but receives an 'AccessDenied' error.. The trust policy in Account B's role must explicitly list Account A's account ID as a trusted entity. Account A's IAM user must have permission to call sts:AssumeRole. Both policies must be correctly configured, and the role name must be specified exactly. (Exam clue: This tests the two-part permission: the trusting account's role policy and the trusted account's user policy. Both must be present.)
- **Azure SAS token appears valid but returns 403 (Forbidden)** — symptom: An application receives a 403 error when trying to access a blob using a SAS token that was generated moments ago.. The SAS token may be using the wrong service (e.g., generated for Table but used on Blob), or the resource type in the token does not match (e.g., container-level token used on a specific blob). Also, check if the storage account firewall blocks the request or if the SAS token is over HTTP instead of HTTPS. (Exam clue: Common exam scenario: the token works on one blob but not on another; the answer is to check the signed resource type (srt) in the SAS token string.)
- **Shared access via bucket policy for anonymous user does not work even after setting policy** — symptom: An admin sets an S3 bucket policy to allow PublicRead, but anonymous users still get AccessDenied.. For anonymous access, the bucket policy itself is not enough if the bucket's Block Public Access settings (at account or bucket level) are enabled. Those settings override any policy that grants public access. The admin must disable any Block Public Access settings that apply to the bucket. (Exam clue: This is a classic exam pitfall: Block Public Access settings are a higher-level guard that can silently disable resource-based policies.)
- **Generated SAS token is too long and exceeds URL length limit** — symptom: The application fails because the complete URL with SAS token is truncated by the client or a proxy.. SAS tokens (especially Azure Service SAS) contain many query parameters (sig, se, sv, sp, sig, etc.) and can exceed 2000 characters. Azure does not impose a limit per se, but HTTP clients and proxies may truncate URLs longer than 2048 characters. Using a stored access policy reduces the token length and adds control. (Exam clue: An exam question may ask what happens if the SAS token is extremely long; the correct answer is that proxies may drop the request or truncate the signature, causing authentication failure.)
- **Revoking a user's Azure AD access does not invalidate their shared access tokens** — symptom: After deactivating a user account, the user can still access shared resources using previously generated URLs or tokens.. SAS tokens (including user-delegated SAS) are cryptographically signed and are not tied to a user session. Revoking the user's Azure AD account does not automatically invalidate tokens already in circulation or cached. To revoke, you must regenerate the storage account key (for key-based SAS) or change the stored access policy (for service SAS). (Exam clue: This is a key distinction for the CISSP and Security+ exams: token revocation is separate from identity revocation. Always regenerate the key or modify the policy.)

## Memory tip

LASER: Least privilege, Appropriate method, Scope correctly, Expire tokens, Review regularly.

## FAQ

**What is the difference between a shared access signature (SAS) and a storage account key?**

A storage account key grants full administrative access to everything in the storage account, while a SAS token grants limited, scoped, and time-bound access to specific resources. You should never share a storage account key; use SAS for temporary or restricted access.

**Can I revoke a shared access signature before it expires?**

For a user delegation SAS, you can revoke it by rotating the user delegation key or deleting the user identity. For a service SAS or account SAS, you can revoke it by regenerating the storage account key or by using a stored access policy with a short expiry. Without a stored access policy, revoking a SAS is not possible until it expires.

**What is the principle of least privilege and how does it apply to shared access?**

The principle of least privilege means granting only the minimum permissions necessary for a user or system to perform their tasks. For shared access, this means giving read-only if write is not needed, scoping access to specific folders, and setting short expiry times on tokens.

**Why can't a user access a shared folder even though their name is in the permissions?**

This is often due to the interaction between share permissions and NTFS permissions on Windows. The effective permission is the more restrictive of the two. Also, check if the user is accessing from an unauthorized network location or if the folder is hidden. Use the Effective Permissions tool to diagnose.

**What is a stored access policy in Azure?**

A stored access policy is an Azure feature that allows you to define a set of permissions and expiry settings that can be assigned to multiple SAS tokens. It gives you additional control because you can modify or revoke the policy, which affects all SAS tokens associated with it.

**Is it safe to use a presigned URL in AWS S3?**

Yes, as long as you set a short expiration time and restrict the permissions to only necessary actions (e.g., putObject, getObject). A presigned URL is secure because you do not expose your AWS credentials. However, anyone with the URL can use it until it expires, so protect the URL like a password.

**How does shared access differ in Linux compared to Windows?**

In Linux, traditional file permissions are limited to owner, group, and others (rwx). To grant shared access to multiple specific users, you use POSIX Access Control Lists (ACLs) via setfacl and getfacl. Linux also supports network file sharing via NFS with export options, which are analogous to Windows share permissions.

## Summary

Shared access is a fundamental concept in IT that governs how multiple users, systems, or applications interact with the same resource. It is not simply about turning permissions on or off; it involves carefully determining who needs access, what they should be allowed to do, and for how long. Throughout this glossary page, we explored the plain English meaning, the technical depths, and the practical reality of shared access. We saw that shared access can be implemented using various mechanisms: Windows NTFS and share permissions, Linux ACLs, cloud-specific tools like AWS IAM policies and presigned URLs, Azure RBAC roles and SAS tokens, and database user roles. Each platform has its own best practices, but the core principles remain the same: least privilege, scoping, expiration, and regular auditing. Why did this matter for certification exams? Because you will encounter shared access in almost every domain-storage, networking, identity, compliance, and security. Whether you are taking AWS SAA, Security+, CISSP, or Azure exams, questions will test your ability to choose the correct configuration to grant access securely and efficiently. Common mistakes include over-permissioning, sharing account keys, forgetting to set expirations, and confusing permission layers. The key takeaways for exam success are: always apply the principle of least privilege, use temporary credentials for external sharing, understand the effective permission model, and never share permanent keys or passwords. By mastering shared access, you not only improve your exam scores but also become a more capable IT professional who can design and maintain secure collaborative environments. Remember the LASER memory tip: Least privilege, Appropriate method, Scope correctly, Expire tokens, Review regularly. This will guide you through both real-world administration and exam questions.

---

Practice questions and the full interactive page: https://courseiva.com/glossary/shared-access