One of the hardest parts about writing a user-facing app or service is controlling access to resources. Decisions about access control are some of the earliest to be made and can make or break an entire platform. It’s usually a trade-off between granularity and speed. Let’s explore how to leverage Redis to get granular control and speed at the same time.
One approach is to set up “user levels,” typically numbers or roles such as “admin,” “regular user,” “privileged user,” etc. This approach alone is usually not a very viable path as you run into a never-ending additive process (“super-super-admin” or “disabled-regular-user,” etc.) or create a mess of widely spaced user levels and hope for the best.
I’ve stopped covering breaches. First, because clouds are nowhere to be found among them. (The focus of this blog is advice to enterprises that are moving, or have moved, to cloud computing.) Second, because it just seems like piling on a company that’s already in distress.
However, breaches are on the minds of enterprises on the move, due to the latest breach at Equifax.[ The cloud storage security gap—and how to close it. | Stay up on the cloud with InfoWorld’s Cloud Computing Report newsletter. ]
What we know now about Equifax is that Equifax was aware of the breach well before it announced that hackers had gained access.Hackers made off with Social Security numbers, birth dates, and addresses of 143 million people. That’s enough to steal your identity. A few Equifax people resigned, but that does not fix anything.
Here we go again. Another terrifying breach of data, of trust, and more concretely, of a mission-critical application that manages sensitive data. Attorneys general, Congress, the FBI, the Associated Press, the intergalactic cyber task force, and everyone else are now investigating what went wrong at Equifax. Almost certainly, the board of every company that deals with sensitive data held their emergency meeting last week to get a sense of their own security posture and issue an urgent action plan to find and remediate any security gaps that may bear a resemblance to this exploit.
It’s never good news when your workloads, data, or both get hacked in a public cloud. Fortunately, it’s something that rarely occurs. But as workloads and data sets on the public clouds become more numerous, such a hack could occur.
The best way to recover from an attack, aka a hack, is to remain calm and follow these simple rules.[ What is cloud computing? Everything you need to know now. | Also: InfoWorld’s David Linthicum explains how to move into a cloud career from traditional IT. ] What do if your public cloud is hacked
- Do shut down the machine instances as quickly as you can. I’m often taken aback by the number of admins who keep compromised systems up and running. Chances are that the hackers have not yet culled all your data, so you can stop further damage by taking those systems down quickly.
- Do contact your provider right away. It typically has automated procedures to lock things down for you, and even locate the source of the attack.
- Do review your security policies and security tools, at your first opportunity. Something fell through the cracks, and most breaches that I see are due to human error. While it’s fresh in your mind, it’s time to do some self-discovery to ensure something like this does not happen again. Even if this specific breach was the cloud provider’s fault, the next time it could be your fault—so use the incident to review what you control.
- Do contact those whose information may have been compromised. The days of keeping breaches to yourself are long over. If Social Security numbers or credit card data has been compromised, the owners need to be contacted so they can watch for fraud. If it’s personally identifiable information (PII) or other protected data, you need to contact your regulatory authority as well.
- Don’t try to combat the hackers with a counterattack. Shut the systems down first, remove the IP addresses, and then figure out what happened. Retaliation is a macho thing that I’ve seen occur in the last few years—don’t go there. It’s not a street fight. I’ve even seen companies that were attacked launch counter-DDOS attacks at the offending IP addresses. Not smart. In the long run, you’ll just waste more time and money, and possibly open yourself to a full-on vendetta attack.
- Don’t make rash decisions about rehosting. These days, many companies move to the cloud because their on-premises systems got hacked. If cloud-based systems are hacked, I suspect we’ll hear a lot of people say, “We’re heading back to the enterprise data center.” The grass is always greener, and you need to thoroughly think through such a move. Huge and expensive rehosting decisions could turn into huge and expensive mistakes.
- Don’t play the blame game. Although it’s tempting to call people out who you view as responsible, that almost never delivers the outcome you’re seeking.
- Don’t overexplain. Among the great many mistakes I’ve seen included a company sending out press releases, where one would have done the trick. The public will view such overexplaining as a weakness, and many will assume you’re hiding something in the deluge of explanations—that you’re fast-talking. Make your points and be done with it.