Security management has historically been focused on the User attempting to access a resource. But in the increasingly complex world of CI/CD methodologies and microservices, it’s no longer “Users” and “Resources” we need to secure. Applications need to talk to each other, resources need to move from development through production and be managed by automated systems, and the systems themselves have become consumers and contributors.
We tend to think of “Identity” as a static thing. I’m “me” and I can prove it! Only my “identity” is extremely fluid. Identity, in the IAM world of Identity Access Management, isn’t just me proving I’m Michael Bissell, but it’s me proving that I’m allowed to do things, and therein lies the challenge.
To be honest, most companies still use their IdP (Identity Provider) as a way to login with AuthN, plain old Authentication. They think they’re doing AuthZ (Authorization), but in reality, you have a fractured Identity strategy any time you have a system that has to make a second call to a database after I log in, just to figure out what I get to do.
I started my career back in the days when we hosted servers in the basement of the office. At the time, we never really thought much about security until we deployed the code (which pretty much meant FTPing a bunch of files to a server). Security was handled at the router first – block malicious traffic from getting in the door. Then we locked down the firewall on the server itself (no, you can’t telnet from outside the building).
Skip forward 15-20 years. We like to think in the days of solid development cycles and continuous integration/continuous deployment we have this whole security thing nailed. But to be honest, we, as an industry, still pretty much treat security as the thing you do in Production. We treat our dev boxes an awfully lot like my team treated servers back in the day – it’s okay, it’s inside the firewall.
Only it’s not okay.