AWS Resource Tagging

After a successful masking run against an AWS target, DataMasque tags the masked resource with a standard set of protection tags. These provide a machine-readable "Protected by DataMasque" governance signal: proof that a resource holds masked data.

This page covers the tags applied, the IAM permissions required, how to preserve the tags through RDS snapshot and restore, and how to find masked resources with AWS Config.

The protection tag set
The tag_aws_resources global setting
Required IAM permissions
- Tagging a resource in another AWS account
Preserving tags through RDS snapshot and restore
Finding masked resources with AWS Config

The protection tag set

When tagging is enabled and DataMasque is running on AWS, a successful masking run applies the following tags to the masked resource:

Tag	Example value	Purpose
`datamasque:masked`	`true`	Customer-facing governance signal: this resource holds masked data.
`datamasque:masked-date`	`2026-05-25T10:30:00+00:00`	The ISO 8601 timestamp the masking run completed.
`datamasque:run-id`	`42`	The DataMasque run ID that produced the masked data.
`aws-apn-id`	`pc:<product-code>`	The product ID of the DataMasque product that performed the masking, used for auditing with AWS.

A discovery run (which profiles data without masking it) applies a parallel marker set instead:

Tag	Example value	Purpose
`datamasque:discovered`	`true`	Governance signal: this resource has been profiled by a DataMasque discovery run.
`datamasque:discovered-date`	`2026-05-25T10:30:00+00:00`	The ISO 8601 timestamp the discovery run completed.
`datamasque:run-id`	`42`	The DataMasque run ID that profiled the resource.

A discovery run never applies datamasque:masked or aws-apn-id, since it reads but does not mask data.

The resource tagged depends on the target type:

RDS instances (matched by an *.rds.amazonaws.com instance endpoint) are tagged on the instance, and CopyTagsToSnapshot is enabled so the tags propagate to snapshots automatically.
Aurora clusters (matched by an *.rds.amazonaws.com cluster endpoint) are tagged on the cluster, and CopyTagsToSnapshot is enabled on the cluster so the tags propagate to snapshots automatically. Aurora custom endpoints, RDS Proxy, Aurora global, and Aurora Limitless endpoints are not tagged.
Redshift clusters are tagged on the cluster.
DynamoDB tables are tagged on each masked table.
S3 objects are tagged inline as they are written.

Tagging is best-effort. If a tagging API call fails (for example, because of a missing IAM permission), the masking run still completes successfully and a WARNING is logged with the underlying error and a remediation message. Tagging never blocks or fails a masking run.

Unlike the other resource types, which are tagged once on completion, S3 objects are tagged inline as each object is written. If a run fails partway through, objects already written carry the datamasque:masked tag even though the run did not complete, and the datamasque:masked-date value reflects the run start rather than its completion.

The `tag_aws_resources` global setting

Tagging is controlled by the Tag AWS resources as masked after a successful run checkbox on the global settings page. It defaults to on. The setting is only visible when DataMasque is running on AWS; on non-AWS installs no tagging UI or behaviour is present. To opt out, an administrator can clear the checkbox and save.

Required IAM permissions

Grant the DataMasque instance role the following permissions for the resource types you mask. The policy below avoids Resource: "*"; narrow the Resource ARNs further to the specific regions, accounts, tables, clusters, instances, and buckets you mask where possible.

Note that s3:PutObjectTagging is required even though S3 tags are supplied inline via the PutObject Tagging parameter, because IAM evaluates the tagging action independently of s3:PutObject.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DataMasqueDynamoDbTagging",
      "Effect": "Allow",
      "Action": [
        "dynamodb:DescribeTable",
        "dynamodb:TagResource"
      ],
      "Resource": "arn:aws:dynamodb:*:<account-id>:table/*"
    },
    {
      "Sid": "DataMasqueRdsTagging",
      "Effect": "Allow",
      "Action": [
        "rds:DescribeDBInstances",
        "rds:AddTagsToResource",
        "rds:ModifyDBInstance"
      ],
      "Resource": "arn:aws:rds:*:<account-id>:db:*"
    },
    {
      "Sid": "DataMasqueAuroraTagging",
      "Effect": "Allow",
      "Action": [
        "rds:DescribeDBClusters",
        "rds:AddTagsToResource",
        "rds:ModifyDBCluster"
      ],
      "Resource": "arn:aws:rds:*:<account-id>:cluster:*"
    },
    {
      "Sid": "DataMasqueRedshiftTagging",
      "Effect": "Allow",
      "Action": [
        "redshift:DescribeClusters",
        "redshift:CreateTags"
      ],
      "Resource": "arn:aws:redshift:*:<account-id>:cluster:*"
    },
    {
      "Sid": "DataMasqueS3Tagging",
      "Effect": "Allow",
      "Action": [
        "s3:PutObjectTagging"
      ],
      "Resource": "arn:aws:s3:::<bucket-name>/*"
    }
  ]
}

rds:ModifyDBInstance (RDS instances) and rds:ModifyDBCluster (Aurora clusters) are used only to enable CopyTagsToSnapshot on the masked resource, so that the protection tags propagate to snapshots automatically (see below).

Tagging a resource in another AWS account

The permissions above are granted to the DataMasque instance role, which can only see resources in DataMasque's own account. If the database you are masking lives in a different account, grant the permissions above to a role in that account, and set that role's ARN as the IAM Role ARN on the connection. DataMasque then assumes the role for the tagging calls. The DataMasque instance role still needs sts:AssumeRole on that role, and the role's trust policy must allow DataMasque's account to assume it.

On a database connection (PostgreSQL, MySQL, MariaDB, Oracle, SQL Server, IBM Db2 LUW or Amazon Redshift), the role is used only for tagging. Masking still reaches the database over its own port with the database credentials on the connection, so a missing or wrong role costs you the tags and nothing else. The role only has any effect when the host is an RDS instance, Aurora cluster or provisioned Redshift cluster endpoint; on a self-managed database, or on the endpoint types listed above as untaggable, it is silently unused.

On a DynamoDB or S3 connection the same field is the role DataMasque assumes to read and write the data itself, so it is required for the masking run, not just for the tags.

For RDS instances, Aurora clusters and Redshift clusters, a cross-account attempt without the ARN typically fails with a message reporting that the resource was not found in the account DataMasque reached, because the resource genuinely does not exist there. A policy that denies the lookup outright reports missing permissions instead. See Cross Account Functionality for AWS for the trust policy and the connection setup.

Preserving tags through RDS snapshot and restore

DataMasque tags the RDS instance (not the snapshot) and sets CopyTagsToSnapshot=true. With this in place, tags copy automatically from the instance to its snapshots, and from a snapshot to an instance restored from it, as long as no explicit tags are supplied on the snapshot or restore operation.

Note: Amazon Aurora manages snapshot tag copying at the cluster level, so DataMasque tags the Aurora cluster and sets CopyTagsToSnapshot=true on it. The tags then propagate to cluster snapshots automatically, as long as no explicit tags are supplied on the snapshot or restore operation.

Do not pass explicit `--tags` on snapshot or restore

Supplying explicit --tags on create-db-snapshot or restore-db-instance-from-db-snapshot overrides AWS tag inheritance and drops the inherited protection tags. When using the AWS CLI, omit --tags so the tags inherit:

# Inherits the instance tags (including the DataMasque protection tags).
aws rds create-db-snapshot \
  --db-instance-identifier my-masked-instance \
  --db-snapshot-identifier my-masked-snapshot

aws rds restore-db-instance-from-db-snapshot \
  --db-instance-identifier my-restored-instance \
  --db-snapshot-identifier my-masked-snapshot

CloudFormation and Terraform always send an explicit tag set on the restored resource, so tag inheritance does not apply to IaC restores. To keep the masked-data signal on resources restored via IaC, include the protection tags in the restore template, as shown below. If your organisation manages snapshot and restore pipelines entirely through its own templates, see Tagging AWS resources with your own CloudFormation or Terraform for a fuller guide. The snippets carry only datamasque:masked and aws-apn-id; datamasque:masked-date and datamasque:run-id describe the original masking run and are intentionally omitted, so they will not be present on resources restored this way.

CloudFormation restore snippet

Resources:
  RestoredInstance:
    Type: AWS::RDS::DBInstance
    Properties:
      DBSnapshotIdentifier: my-masked-snapshot
      DBInstanceClass: db.t3.medium
      Tags:
        - Key: "datamasque:masked"
          Value: "true"
        - Key: "aws-apn-id"
          # Replace with the value from the masked instance's `aws-apn-id` tag.
          Value: "pc:<product-code>"

Terraform restore snippet

resource "aws_db_instance" "restored" {
  snapshot_identifier = "my-masked-snapshot"
  instance_class      = "db.t3.medium"

  tags = {
    "datamasque:masked" = "true"
    # Replace with the value from the masked instance's `aws-apn-id` tag.
    "aws-apn-id" = "pc:<product-code>"
  }
}

Finding masked resources with AWS Config

If AWS Config is recording resource configurations, you can query for all resources DataMasque has marked as masked using an advanced query:

SELECT
  resourceId,
  resourceType,
  accountId,
  awsRegion
WHERE
  tags.key = 'datamasque:masked'
  AND tags.value = 'true'

Run it from the AWS Config console under Advanced queries, or with the CLI:

aws configservice select-resource-config \
  --expression "SELECT resourceId, resourceType, accountId, awsRegion WHERE tags.key = 'datamasque:masked' AND tags.value = 'true'"