I’m often taken aback by the lack of granularity when it comes to security identity management. Although most security approaches and tools have the capability to partition security domains by people, roles, locations, devices, and parts of databases, most people set up cloud security with only a few domains.
For those of you who don’t deal with security operations, or secops, we can create groups using any number of dimensions or domains. An “identity” needs to belong to at least one domain, but it can belong to all or most domains as well.
This slicing and dicing of security domains means you have better control over security management, such as disallowing those using mobile devices, those who work for devops, those who are outside the United States, or those who have access to a cloud-based storage system for whatever reason that may be needed.
The trouble is that once you’ve launched with too few domains, it’s tough to get the toothpaste back in the tube. Hitting reset on your security design means major disruption, and not a good disruption. You’ll have to re-evaluate security policies from the ground up, and I’ve yet to see any enterprise do that without missing something. Get a few things wrong and you could be on the morning news with the word “hacked” next to your company’s logo.
The good news is that best practices are emerging, and the value of very fine-grained security domains for identities seems to be understood better. That said, I’m seeing more retroactive fixing of security domain issues, which puts the companies in a state of vulnerability, not to mention the user frustration as people have to learn a new set of security procedures.
The solution is that old, annoying advice: A bit of upfront planning goes a long way when it comes to security. Many doing cloud—and cloud security—think that you can iterate your way through this process, but getting it wrong over and over before you get it right once will cost you dearly.