Little Security. Big Problems.
Redis is designed (as most early NoSQL products) as a product that should be used in secured environment (meaning little security measures are built in).
The only security measure Redis supports is authentication that is passed as clear text (definitely not a best security best practice).
UPDATE: Itamar Haber from RedisLabs referred me to an SSL communication encryption using stunnel or spiped.
Big Problems. Great Solutions
If you love Redis (and w/ 60K Set and Get Ops/Sec on commodity hardware there is no reason you won't love it), and if you must have an enterprise grade solution, you can take one of the following approaches:
- Implement a web layer in front of it (that can support SSL, encrypted authentication, logging and all other fancy stuff). A great example for this is Webdis with a built in solution. Off course, there is a performance penalty stick to the extra layer (and some issues as Redis still can be accessed directly).
- Save the data encrypted in Redis (encrypt data before the SET operation by the app servers, and decrypt it after the GET operation by consumers). This way, communication is not needed to be encrypted and hackers or malicious users can do little harm, even they are access the Redis directly as the Redis data store is encrypted.
Bottom Line
Even sensitive products that lack of basic security measurements, can be brought to enterprise level with the right design in mind.
Keep Performing,
Moshe Kaplan
It is a common question these days how one should design their next system to support elastic and growth requirements in the cloud era.
As I got this specific query today, I would like to share with you my answer based on various materials I created in the last few years:
1. Avoid File Storage SPOF: Use AWS S3 or its equivalent open source OpenStack Swift as a central file server repository when needed
How to use OpenStack Swift for your business case
2. Avoid Data Store SPOF: Use clustered data store that recovers automatically w/o a DBA or an operator intervention. Fine examples are AWS MySQL RDS, MongoDB and Cassandra
MongoDB HA concepts
3. Avoid Static Servers: Leverage Autoscale features or customize it for your needs
How to implement your application logic to auto scale your app
4. Avoid Messing with Cache: Use a central sharded cache to avoid cache revocation and reduce data stores load using MongoDB, CouchBase or Redis.
5. Offload your servers sessions: in order to avoid users log off and lost transactions:
How to implement a session offloading using a central store
6. Avoid Service Downtime due to Servers Downtime: More issues that can be found in my extensive presentation:
- Use DNS Load Balancing for Geo LB and DRP (Slide 10)
- Use CDN to offload network traffic (Slides 16-19)
- Perform Session Offloading by cookies or a central store (Slides 62-65)
Bottom Line
You can scale your app! just follow the right recommendations
Keep Performing,
Moshe Kaplan
