Cloud Consulting Services: What Data Can Leave Your Account?

Cloud consulting services arrive with an access review. Every engagement we take over has one in the folder, and it asks a single question: what can these people change? Roles instead of users, a boundary, an approval on production applies. Useful work. It almost never asks what they can copy, and the answer is usually the whole customer database, in one API call, with a permission nobody would call excessive.

Our position: an engagement that touches a production account needs an egress list in the statement of work, the way it needs an access model. Three of the paths out read as ordinary work in CloudTrail. The fourth is not recorded at all unless you turned something on.

September's post asked what should be in your name on the last day. This is the other half: what left the account while they were on it. No handover checklist catches it, because nothing is missing afterwards.

Why do cloud consulting services get access before anyone asks what they can copy?

Because the first week is an assessment, and an assessment needs read access to a lot. Reasonable ask; we make it ourselves. The managed read-only job function policy is the usual shortcut, and it reads the objects, not just the resource list, which is the finding in the post on what a cost tool is really asking for when it asks for read-only. Then the role grows with the build: RDS to move a database, EC2 to bake an image, KMS so any of it works.

What follows is not malice, it is a debugging habit. A migration needs testing against real data, a sandbox account is the convenient place, and a snapshot share is two minutes of work against a fortnight of generating synthetic data. We have watched careful engineers reach for it. It is the most common way customer records end up in an account you do not own and will never get a log out of.

Can your production database leave in one API call?

It can, and the mechanism is boring. AWS's documentation on sharing a DB snapshot is matter of fact about it: "You can share a manual snapshot with up to 20 other AWS accounts", encrypted or not. One ModifyDBSnapshotAttribute call with an account id in it. Pass the value all instead and an unencrypted snapshot becomes restorable by any AWS account anywhere.

Encryption is a partial lock, and most teams hold it by accident rather than by design. The page on sharing encrypted snapshots sets out two limits: "You can't share encrypted snapshots as public" and "You can't share a snapshot that has been encrypted using the default KMS key of the AWS account that shared the snapshot."

Read that second line twice if you are part way through a compliance programme. A database on the default key cannot have its snapshots shared at all. Move it to a customer managed key, which an auditor will ask for eventually, and sharing becomes possible. The key policy is the lock, not the encryption. If one of yours lists an account nobody recognises, you have found your Monday.

Does blocking public snapshots stop any of this?

No, and the documentation says so in one line. Block public access for snapshots is worth switching on, but AWS's page for it states that it "does not prevent private snapshot sharing". Private sharing is the vendor path. Public sharing is the accident.

Two more properties. It is "a Regional setting", so enabling it in ap-south-1 does nothing about the test volumes left in us-east-1. And it does not cover images: "Block public access for snapshots does not prevent the public sharing of EBS-backed AMIs". That has its own switch, and an AMI baked from a production instance carries whatever was on the root volume.

Who can use a presigned URL, and for how long?

Anybody holding the link, for as long as the credentials behind it live. AWS's guidance on presigned URLs is unusually direct: "presigned URLs are bearer tokens that grant access to those who possess them", and the credentials they carry "are those of the AWS Identity and Access Management (IAM) principal who generated the URL".

The expiry is where the access model earns its keep. From the CLI the window "can be set as high as 7 days", but with temporary credentials the page is clear: "The presigned URL expires when the role session expires, even if you specify a longer expiration time." A consultancy arriving through a role, as we argued in the post on how an outside team should get into your account, cannot hand out a link that outlives its session. One holding an IAM user's access key can mint a seven-day bearer token. Better argument against vendor IAM users than the ones we usually make.

So cap how old a presigned signature may be on your sensitive buckets, with the s3:signatureAge condition that page documents. A ten-minute ceiling makes a shared link useless and changes nothing about how your applications sign their own requests.

What should you deny outright, and what should only page you?

AWS's data perimeter whitepaper puts the goal in one sentence: "access can only be allowed if the identity is trusted, the resource is trusted, and the network is expected". The whole perimeter is a programme of work. The sharing APIs are an afternoon, and nothing routine calls these four. Deny them, keep one break-glass role for the quarter you do need to send a snapshot somewhere, and make its use loud:

{
  "Version": "2012-10-17",
  "Statement": [{
    "Sid": "DenySnapshotAndImageSharing",
    "Effect": "Deny",
    "Action": [
      "rds:ModifyDBSnapshotAttribute",
      "rds:ModifyDBClusterSnapshotAttribute",
      "ec2:ModifySnapshotAttribute",
      "ec2:ModifyImageAttribute"
    ],
    "Resource": "*",
    "Condition": {
      "ArnNotLike": {
        "aws:PrincipalArn": "arn:aws:iam::*:role/BreakGlassDataShare"
      }
    }
  }]
}

Attach it to the organisational unit holding production. Two caveats, both of which have caught us out: a service control policy does not apply to the management account, and the break-glass role has to exist before the policy is attached, or the next legitimate copy becomes an incident at the wrong hour.

Then alert, rather than deny, where there are honest uses: a KMS key policy or bucket policy that gains an external principal, a new cross-account role. EventBridge rules over management events you already collect.

What do the RBI directions expect you to have written down?

More than most contracts carry. The RBI's Cybersecurity, Technology: Risk, Resilience and Assurance Framework Directions, 2026 put it in one sentence at paragraph 114: the NBFC "shall closely supervise personnel with elevated system access entitlements with all their system activities logged and periodically reviewed." A consultant holding a production role is that person, and that is a hard claim to make while object reads go unrecorded.

The outsourcing chapter is where the contract sits. Paragraph 62(2)(i) requires that "requisite audit trails and logs for administrative activities shall be retained by the service provider and the same shall be accessible to the NBFC based on approved requests". Once a snapshot is restored inside their account, that clause is the only thing that gets you a log of what happened next. The rest is in the post on what the RBI expects a DevOps outsourcing contract to say.

There is a residency consequence, too. A snapshot shared with an account in another region, and copied there, is a copy of that data outside ap-south-1 whatever the reason. Same quiet exit as in the post on where payment data leaves India without anyone deciding it should.

What can you run on Monday?

Twenty minutes with read access to a production account. First, what is shared:

for s in $(aws rds describe-db-snapshots --snapshot-type manual \
             --query 'DBSnapshots[].DBSnapshotIdentifier' --output text); do
  echo "$s -> $(aws rds describe-db-snapshot-attributes --db-snapshot-identifier "$s" \
    --query "DBSnapshotAttributesResult.DBSnapshotAttributes[?AttributeName=='restore'].AttributeValues[]" \
    --output text)"
done

aws ec2 get-snapshot-block-public-access-state
aws ec2 describe-images --owners self \
  --query 'Images[?Public==`true`].[ImageId,Name]' --output table

Any account id in the first output that is not one of yours is the conversation. Run it in every region anyone has launched anything in, because snapshots and that block setting are both regional. Then, whether a download would be visible at all:

aws cloudtrail get-event-selectors --trail-name YOUR_TRAIL_NAME

If nothing in the output mentions AWS::S3::Object, no object reads are recorded anywhere. CloudTrail's data events documentation says "By default, trails and event data stores do not log data events", and warns they are "often high-volume activities", so turn them on for the buckets holding customer data and leave the rest.

Last, three lines for the next statement of work: which datasets a consultant may restore, into which account, and who approves it.

When is none of this worth doing?

When there is nothing in the account worth copying. A pre-revenue product with synthetic data and no customers needs the product, not a perimeter, and a week of egress work instead of the thing you hired for is a real cost. We have been on the wrong side of that trade.

There is also a better control than any policy here: do not keep the data within reach. A restore pipeline that masks the columns nobody needs removes the argument entirely, and every test environment afterwards reuses it.

And the honest note, since we sell this work: we are one of the vendors this post is about. The list above is what we would want asked of us.

The short version

Run the snapshot and image checks this week, in every region, and look for an account id nobody recognises. One person, an afternoon.

Attach the deny policy to the organisational unit holding production, break-glass role created first. Turn data events on for the buckets with customer data and cap the signature age there. Then find out whether any vendor still holds an IAM user's access key.

Then write three lines into the next statement of work: which data may be restored, into which account, and who signs it off. The access review answered what they can change. Answer the other question before the engagement starts, not when somebody asks you for the log.

This is engineering guidance, not legal advice. Regulations and their annexures are amended over time; read the current text and take your compliance position from counsel.