I’ve been thinking for some months (years, maybe) about how to properly implement a zone taxonomy/hierarchy for a global policy security configuration. Perhaps because I’ve never really had the time to sit down and focus on the problem, it has always proven elusive. I can see what I want to accomplish, but it requires just a little more thought than I’ve been able to devote to it. Which is unfortunate. I think this taxonomy/hierarchy combination could greatly simplify some of what I do.
Recently I’ve had an opportunity (scantily disguised as a shitload of work and frustration) to focus on this, think it through, and see if it actually has the potential to prove beneficial. That’s what I’ve spent this afternoon doing, and it’s time to start making some notes on my thoughts and analyzing the conclusions therefrom to see if this is actually a workable idea or if it’s something that’s been nagging at me for years with no viable solution, or at least none that I can see clear.
For the reader, I’m writing this primarily to clarify and focus my own thought process, so I won’t go into any detail on concepts that are already clear in my mind. I will define all zones with the prefix “Zone” to describe the type of element it is (since there are many possible elements in networking – lists, subnets, zones, services, etc.). From there, I will append consecutively more specific elements to describe the particular zone. This yields a few questions, and a few things that will require further thought. I will immediately note the ones that come to mind to prevent their loss as my mind wanders.
Question: Should zones become so specific as to be itemized down to a specific host, or even a specific service?
Implementation Thought: Zone permissions should be configured in a top-down list from the most granular to the most generic. This is in line with traditional list-based access control methodologies.
