# Tags for data security, risk management, and access control
Organizations have varying needs and obligations to meet regarding the appropriate handling of data storage and processing. Data classification is an important precursor for several use cases, such as access control, data retention, data analysis, and compliance.
# Data security and risk management
Within an AWS environment, you will probably have accounts with differing compliance and security requirements. For example, you might have a developer sandbox, and an account hosting the production environment for a highly regulated workload, such as processing payments. By isolating them into different accounts, you can [apply distinct security controls](https://docs.aws.amazon.com/whitepapers/latest/organizing-your-aws-environment/benefits-of-using-multiple-aws-accounts.html#apply-distinct-security-controls-by-environment), [constrain access to sensitive data](https://docs.aws.amazon.com/whitepapers/latest/organizing-your-aws-environment/benefits-of-using-multiple-aws-accounts.html#constrain-access-to-sensitive-data), and reduce the scope of audit for regulated workloads.
Adopting a single standard for all workloads can lead to challenges. While many controls apply equally across an environment, some controls are excessive or irrelevant for accounts that don't need to meet specific regulatory frameworks, and accounts where no personal identifiable data will ever be present (for example, a developer sandbox, or workload development accounts). This typically leads to false positive security findings that must be triaged and closed with no action, which takes effort away from findings that should be investigated.
*Table 11 – Example data security and risk management tags*
| Use case | Tag Key | Rationale | Example Values |
| --- | --- | --- | --- |
| Incident management | example-inc:incident- management:escalationlog | The system in use by the supporting team to log incidents | jira, servicenow, zendesk |
| Incident management | example-inc:incident- management:escalationpath | Path of escalation | ops-center, dev-ops, app-team |
| Data classification | example-inc:data:classification | Classify data for compliance and governance | Public, Private, Confidential, Restricted |
| Compliance | example-inc:compliance:framework | Identifies the compliance framework the workload is subject to | PCI-DSS, HIPAA |
Manually managing different controls across an AWS environment is both time consuming and error prone. The next step is to automate the deployment of appropriate security controls, and configure inspection of resources, based on the classification of that account. By applying tags to the accounts and the resources within them, the deployment of controls can be automated and configured appropriately for the workload.
**Example: **
A workload includes an Amazon S3 bucket with the tag `example-inc:data:classification` with the value `Private`. The security tooling automation deploys AWS Config rule `s3-bucket-public-read-prohibited`, which checks the Amazon S3 bucket’s Block Public Access settings, the bucket policy, and the bucket access control list (ACL), confirming the bucket’s configuration is appropriate for its data classification. To ensure the content of the bucket is consistent with the classification, [Amazon Macie can be configured to check for personal identifiable information (PII)](https://aws.amazon.com/about-aws/whats-new/2021/05/amazon-macie-supports-criteria-based-bucket-selection-sensitive-data-discovery-jobs/). The blog [Using Amazon Macie to Validate S3 Bucket Data Classification](https://aws.amazon.com/blogs/architecture/using-amazon-macie-to-validate-s3-bucket-data-classification/) explores this pattern in greater depth.
Certain regulatory environments, such as insurance and healthcare, might be subject to mandatory data retention policies. Data retention using tags, combined with Amazon S3 Lifecycle policies, can be an effective and simple way to scope object transitions to a different storage tier. Amazon S3 Lifecycle rules can also be used to expire objects for data deletion after the mandatory hold period expires. Refer to [Simplify your data lifecycle by using object tags with Amazon S3 Lifecycle](https://aws.amazon.com/blogs/storage/simplify-your-data-lifecycle-by-using-object-tags-with-amazon-s3-lifecycle/) for an in-depth guide to this process.
Additionally, when triaging or addressing security finding, tags can provide the investigator with important context that helps qualify the risk, and aids in engaging the appropriate teams to investigate or mitigate the finding.
# Tags for identity management and access control
When managing access control across an AWS environment with AWS IAM Identity Center, tags can enable several patterns for scaling. There are several delegation patterns that can be applied, some are based on tagging. We’ll address them individually and provide links to further reading on each.
# ABAC for individual resources
IAM Identity Center users and IAM roles support attribute-based access control (ABAC), which allows you to define access to operations and resources based on tags. ABAC helps reduce the need to update permission policies and helps you to base access off of employee attributes from your corporate directory. If you are already using a multi-account strategy, ABAC can be used in addition to role-based access control (RBAC) to provide multiple teams operating in the same account granular access to different resources. For example, IAM Identity Center users or IAM roles can include conditions to limit access to specific Amazon EC2 instances which otherwise would have to be explicitly listed in each policy in order to access them.
Since an ABAC authorization model depends on tags for access to operations and resources, it is important to provide guardrails to prevent unintended access. SCPs can be used to protect tags across your organization by only allowing tags to be modified under certain conditions. The blogs [Securing resource tags used for authorization using a service control policy in AWS Organizations](https://aws.amazon.com/blogs/security/securing-resource-tags-used-for-authorization-using-service-control-policy-in-aws-organizations/) and [Permissions boundaries for IAM entities](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_boundaries.html) provide information on how to implement this.
Where long-lived Amazon EC2 instances are being used to support more traditional operations practices then this approach can be utilized, the blog [Configure IAM Identity Center ABAC for Amazon EC2 instances and Systems Manager Session Manager](https://aws.amazon.com/blogs/security/configure-aws-sso-abac-for-ec2-instances-and-systems-manager-session-manager/) discusses this form of attribute based access control in more detail. As mentioned earlier, not all resource types support tagging, and of those that do, not all support enforcement using tag policies, so it’s a good idea to evaluate this prior to starting to implement this strategy on an AWS account.
To learn about services that support ABAC, see [AWS services that work with IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html).