DLP for data in motion: the cases CASB never covered

Corporate DLP was built for the laptop and the SaaS browser session. Production data no longer lives there. It moves as an S3 PUT from a job, a replica into another cloud, a support engineer’s kubectl cp, and a log pipeline that was pointed at a personal bucket “just for debugging.” If your DLP program cannot see those paths, you are protecting the copy of the data that is already the least interesting to steal.

Instrument the production egress

CloudTrail data events, VPC flow logs with S3 and DNS, and Kubernetes audit logs for exec/portforward/cp are the minimum. You do not need to inspect payload on day one. You need to know that a principal in namespace payments wrote 40 GB to a bucket that is not in the approved prefix list. Payload inspection comes after that graph is boring.

{
  "Effect": "Deny",
  "Action": ["s3:PutObject", "s3:ReplicateObject"],
  "Resource": "*",
  "Condition": {
    "StringNotLike": {
      "s3:x-amz-copy-source": "",
      "aws:RequestedRegion": "us-west-2"
    },
    "ForAllValues:StringNotEquals": {
      "aws:ResourceAccount": ["${ProductionAccount}"]
    }
  }
}

Give operations a legal path

If support needs a dump, ship a signed, time-boxed job that writes to a reviewed bucket with object lock. If you only block, someone will use their laptop. Design the allowed path in the same sprint as the deny. That is DLP that people will not route around.

CASB still has a job for SaaS. It is not the control plane for the cluster. Stop asking it to be.