2

Excerpt from Redis' security article:

Redis is designed to be accessed by trusted clients inside trusted environments. This means that usually it is not a good idea to expose the Redis instance directly to the internet or, in general, to an environment where untrusted clients can directly access the Redis TCP port or UNIX socket.

AUTH command aside for a minute, I think this makes sense--if your program is only designed to operate under trusted conditions, why bother adding authentication to it? I believe this is the route micro services typically take. Each service is free to communicate with other services in the same network.

But are databases (MySQL and the like) a different story? Typically, I will configure multiple user accounts, one for each micro service that only has access to its own database (under the entire database server). However with the route Redis is taking, is this still necessary?

Are access controls redundant, or is Redis less secure than classic databases?

Chris Smith
  • 222
  • 2
  • 9

2 Answers2

5

Yeah, "designed to operate in a trusted environment" is a fairly common thing for backend servers, though you usually see it as justification for not using TLS between services, or for new nodes to join the cluster with no auth. In the Redis case, they are using it to justify a port with no auth by claiming that an attacker would need to be able to ping the port directly to do any damage. Basically, this is a way of shunting responsibility for security away from the software and onto the network engineers. Maybe you're comfortable with that and maybe you're not, but Redis is being up-front about it so you can decide whether Redis is an appropriate technology for your security goals.

With databases an attacker can sometimes attack the db through your app (for example if you have an SQL Injection vulnerability), so we talk about the Principle of Least Privilege; ie each node has has only the minimum amount of read/write access that it needs to do its job to limit the damage that a compromised node can cause. So do your due diligence and see if the "designed to operate in a trusted environment" argument applies to your scenario, but if I was the appsec engineer responsible for your product, you'd have have a hard time convincing me that it's safe to ignore the Principle of Least Privilege here.

Mike Ounsworth
  • 59,005
  • 21
  • 158
  • 212
1

Trusted how? Can you guarantee that an attacker will never get inside your network? No So while it may be trusted within your network you still should implement controls within a trusted network.

10 years ago this was the approach - today the best approach is, nothing is trusted until proven otherwise.

McMatty
  • 3,270
  • 1
  • 9
  • 16