Overview
  • 20 Aug 2024
  • 2 Minutes to read
  • Contributors
  • Dark
    Light

Overview

  • Dark
    Light

Article summary

Darwinium can be configured to store event data on your own infrastructure using Amazon S3.

Sensitive Personally Identifiable Information (PII) is encrypted by the edge worker, and is stored directly onto your S3 bucket, without the clear-text data touching Darwinium’s SaaS services. See Attribute Reference for those that are treated as PII.

This pattern permits those important but personal identifiers (Email, phone, address..) to be considered in the risk assessment, while preserving your privacy and data residency obligations for that data. It also removes risk of data exposure were Darwinium to be breached, as only truly anonymised forms are stored.

The use case for this S3 bucket is not for data analysis

The S3 bucket stores encrypted personal information. The format is in a blob format that is not suitable for analysis.
The use case is to instead address data residency and privacy concerns, while still permitting risk assessments and investigations considering that important data.
The bucket is tunneled into behind your instance of the Darwinium Portal to present your analysts and Portal users the decrypted values for investigations.

Technical Architecture Overview

Writing data to your S3 bucket

  1. An end user device makes a HTTP request to an endpoint on your infrastructure. If this endpoint is mapped to a journey step,  a Darwinium worker is invoked on your CDN infrastructure (Cloudflare, Cloudfront)

  2. In parallel:  

    1. Darwinium worker uses customer public key to encrypt sensitive data, and sends this to your s3 bucket using write-only credentials

    2. Data is anonymized using a 1-way elliptic hashing function, and sent to the Darwinium node. This provides indexing capabilities for future forensic searches and event lookups.

  3. Darwinium writes non-sensitive attributes from Darwinium node to your S3 bucket using write-only credentials.

Reading data from your S3 bucket

  1. A fraud/security analyst makes a query to your Darwinium node- eg: identity['ACCOUNT'].username.username = 'janedoe@example.com'
    When this happens, a request is sent from the analysts browser to Darwinium's data services, containing a cryptographically signed JSON Web Token (JWT) bound to the querying user

  2. JWT claim is used by Darwinium data services to unlock read-only S3 credentials from our secure vault

  3. Data services make a request to your S3 bucket to retrieve encrypted/hashed event data blob(s).

  4. Darwinium data services unlock PII private key for decryption (if this is permitted for the user)

  5. Blobs are decrypted

  6. Event data is returned to the analyst

Two roles are used: Read-only and Write-only

By design, Darwinium has delineated bucket access into read-only and write-only roles in order to prevent automated processes from reading data from the bucket if they were compromised by an attack upon Darwinium's services. Reading from your bucket is only possible using credentials that can be unlocked by a user (not a process).



Was this article helpful?

What's Next
Changing your password will log you out immediately. Use the new password to log back in.
First name must have atleast 2 characters. Numbers and special characters are not allowed.
Last name must have atleast 1 characters. Numbers and special characters are not allowed.
Enter a valid email
Enter a valid password
Your profile has been successfully updated.
ESC

Eddy AI, facilitating knowledge discovery through conversational intelligence