Deploying onto the CDN is a novel technique for fraud prevention. This article covers common questions about deploying to the Edge.
Q: How is deployment performed?
The Darwinium Deployment manager is the easiest way to deploy. See Deployment.
A deploy is initiated for a specific commit, which deploys the compiled Edge artifacts. A key benefit is making sure the places Darwinium is invoked and the risk assessments deployed there can be readily adjusted to respond to threats.
There are safeguards in place as part of deployment manager to make sure deployment is done in way that does not impact your existing workers and allows those to operate as if not there.
Q. We are not comfortable with the privileges that Darwinium is asking to deploy using Darwinium Deployment Manager.
The permissions required are outlined on each specific CDNs deployment guide and have been tested to be as minimal as possible to operate. They broadly split into permissions needed to deploy the edge artifacts and permissions to run them.
The Darwinium build process can instead trigger a webhook that will notify your existing deployment tool whenever there is a new Darwinium build. See Controlling Darwinium's deployment.
That webhook contains a URL to pull down the built artifacts. This way no direct CDN deployment permissions need to be granted to Darwinium, but with trade-off of adding a step in internal processes and CI/CD.
Q. We already have edge functions in place. We don’t want Darwinium to overwrite these
Darwinium does take the place as the primary worker invoked on a route, but does not impact the running of any logic or functions already there.
Darwinium’s deployment tool will automatically detect which workers/lambdas would have run before the deployment, by matching the paths following the same rules as the CDN evaluations behavior/routes.
It will assign them upstream to ensure it still runs. When removing a Darwinium route it will restore the route to prevent changes.
On CloudFront, any existing lambda functions are loaded at cold-start and run inside Darwinium lambda function.
On Cloudflare, existing worker is added as a service binding to Darwinium’s worker.
Q. Will we need to change any settings on our CDN?
You may need to check and update your relevant worker plans directly with your CDN based on expected traffic covered by Darwinium.
For example:
- upgrading to Workers Unbound plan on Cloudflare
- requesting behaviour number increase on AWS Cloudfront
Q. Our requests can contain sensitive data. We don't want Darwinium seeing that.
Darwinium by default does not see or extract anything in the request.
It only will extract explicitly what is instructed in the Darwinium journey configuration file.
To facilitate privacy preserving risk assessment, there are attributes in schema designated as PII attributes (see Attribute Reference). For example for: Email, Phone number, name.
Those are handled differently; they are pre-encrypted on the Edge from within your CDN. Darwinium only needs to store the truly anonymised form, with option to store encrypted form in S3 bucket you host. See BYO S3 Event Storage
Note that this S3 bucket approach is for storage and facilitation of decrypting PII to benefit investigations in Darwinium Portal. It is not suited for analytics, as it is stored in protobuf blob format.
Care is needed to maintain and keep the bucket available, as it will be used ongoing to decrypt PII and render it to the Darwinium Portal.