The Memora security review: answers to the questions reviewers ask

Cloud Certainty Memora reads and changes the data in your Amazon ElastiCache caches, and changes the caches themselves. Before it goes near production, someone will review it. These are the questions that come up, with plain answers.

#Where does our data go?

Nowhere outside your AWS account. Memora runs as one CloudFormation stack in your account: a serverless API, a web portal on AWS Amplify Hosting, Amazon Cognito for sign-in, DynamoDB tables and a connector in the VPC of your caches. There is no vendor service in the data path and nothing phones home. The only call to the vendor is an optional daily read of a public file that announces new releases.

#Does Memora store cache values?

No. Values travel from the cache to the connector, from the connector to the API, and from the API to the browser that asked, and are then dropped. They are never written to DynamoDB, the cache table or logs. The command history keeps command names, classes and up to three keys per command; the full command text only if an administrator turns on recording values. Memory analyses keep key names, types, sizes and TTLs, never values.

#How does Memora reach caches in private subnets?

Through the connector: two small Lambda functions, one for reads and one for writes, in subnets you choose in the caches' VPC. Their security group has no inbound rules and allows outbound only to the cache ports and HTTPS. The connector connects only to ElastiCache endpoint names, and the API builds every endpoint from ElastiCache's own description of the cache, never from the browser. Nobody needs a VPN or a bastion host.

#What credentials does it use for the data?

Preferably none that can leak. With IAM authentication (Valkey 7.2 or later, Redis OSS 7.0 or later, encryption in transit and a user group), Memora can create two ElastiCache users, memora-read and memora-write. The connector signs a 15-minute token for each connection with its own role, which may connect only as its own user. For older engines, the connector reads Secrets Manager secrets tagged for its side. Only the matching connector role can read a secret; the API, the browser and the tables never see it.

#How do you stop someone without write access changing data?

Three independent layers:

1. Memora classifies every command (read, write, admin, flush or blocked) and refuses it if the person lacks the permission.
2. IAM. Every request runs with a session policy built from that person's grants. Without write, the session can invoke the read function and nothing else.
3. The cache. The read function signs in as memora-read, whose access string only allows read commands.

A bug in any one layer is caught by the next.

#Can people be limited to some keys?

Yes, on the Business plan: a grant can carry key patterns such as cart:*. Scans only return matching keys, every key a command names must match, and commands that can reach keys they don't name (EVAL, KEYS, SORT ... BY, Pub/Sub, FLUSHDB) are refused. Key patterns are enforced by Memora's API and again by the connector. They are not enforced by the cache's ACL, because everyone using Memora on a cache shares the two cache users; if a team must be kept out of keys by the cache itself, give it its own cache or narrow those users' access strings.

#What about dangerous commands?

Commands that block the engine or hold a connection (MONITOR, BLPOP, WAIT), and commands ElastiCache restricts (CONFIG, DEBUG, SHUTDOWN, REPLICAOF), never run through Memora. KEYS needs the cache's name typed to confirm. FLUSHDB and FLUSHALL are off by default; when an administrator allows them they also need write, access to every key and the cache's name typed.

#What can Memora do to the caches themselves?

What the account owner allows. Each account's role has an access level chosen when it is deployed: Read (see caches and read data), Operate (plus data changes, backups, scaling, reboots, failover tests and service updates) or Full (plus creating and deleting caches, engines, parameter groups and users). Grants narrow that per person; they never widen it. The roles have no IAM, CloudFormation, DynamoDB, S3 or Lambda change permissions, so Memora cannot change itself.

#How do we know who did what?

Every assumed-role session carries the person's email as its source identity, so CloudTrail in each account names the person behind every ElastiCache call and connector invocation. Memora's audit log records administrative changes, cache changes and every data write with command names and keys, and refused requests too. The command history shows who ran which commands on which cache.

#How do people sign in?

Through Amazon Cognito federated with IAM Identity Center, any SAML provider or OIDC. Memora only trusts email addresses the user can't choose, and binds the bootstrap administrator to an immutable identity on first sign-in. An IP allowlist on every API call is available on the Business plan.

#What is left to us?

• Keep connection roles at Read or Operate unless a team really creates and deletes caches from Memora.
• Prefer IAM data access, and keep the memora-read access string read-only.
• Put connectors in private subnets and allow them only into the caches they serve.
• Grant to groups by cache name prefix, and give write only to people who may change production data.
• Leave flush and value recording off unless you need them, and forward CloudTrail and Memora's logs to your SIEM.

The full security overview, with a summary of every role's permissions, is in the Memora documentation (opens in a new tab).