No Details Left Behind: How Network Teams Can Audit Infrastructure Access Easily with Stateful Orchestration

One of the more interesting conversations I’ve had with multiple customers recently has been around auditing.

Today, it’s not enough to just show who/why/when you provisioned a firewall policy or security group. You must also answer the question: is that access or firewall policy still needed? Should it still be in place?

Today’s ITSM systems are great for processing change requests, but it is not easy to search through a pile of change requests to find what you want when you want to go back and audit what you’ve done in the past. Ideally, you’d like to have some sort of state about what you’ve done, when you did it and why you did it.

I’ve spoken with several customers who do things like validate that a given firewall rule has been used recently to determine if it’s needed. Many of them have processes to then remove unused entries. Of course, usage alone gets you only part of the way there. The reality is, you need more information to be able to determine if a rule should still be in place.

Given these requirements, it’s useful to have some way to track “state” when provisioning and managing infrastructure services so that a given service can be easily decommissioned.

In terms of state, it is useful to track not only what was provisioned (firewall rule, SSH access, Cloud Access) but who provisioned it and how long it’s needed so that the access can be removed after a specific amount of time. Maybe I’ll even want a process in place to validate functionality or even periodically verify the access/service with the originator.

Services are comprised of two or more IT resources that can cross different infrastructure domains. For instance, to provide a contract worker with access to a system, a service could be comprised of components that include VPN, firewall, cloud security, and more. Each of these resources comprise a whole service, and that service doesn’t exist until it’s needed, e.g. a new contractor is hired for a term and all these parts are allocated and put into service by all these different teams. This service instance is now associated with some new, non-technical data like the contractor’s name, company, start date, and maybe some other information like ServiceNow ticket IDs for the original request which helps tie who requested the service, when, and why.

If this contractor is on a 6 month term, they may need additional access to applications and servers after the start date, which would require additional updates to the infrastructure. These updates need to be tracked along with non-infrastructure details, because all these details will be required both for reporting and for turning access off when the contracting term is up.

Tracking this level of detail manually across multiple siloed groups is nearly impossible, which is why it’s rarely done. The problem is, this leads to a lot of pain. When you need those details (which happens more and more frequently in modern distributed network environments), it takes far too long to dig through different systems looking for all the independent details in order to reassemble and understand the whole. And if you miss a detail, you can end up with a ghost config that can lead to unauthorized access and unnecessary security risks.

This is where automation and orchestration come into the picture. Leveraging a solution that can do all of this impossible manual tracking allows teams to solve a common problem.

Using automation to make changes to the infrastructure is great, but you will also need to orchestrate those automations together in a way where you can intelligently gather and store the data for the service and associate information that isn’t normally stored together in a stateful way. This way, you can easily understand all the contextual information around any access services to determine if they are still needed.

Orchestration is critical not just for turning up services, but for modifying them over time as well. Things tend to change. When service details change, these details must also be tracked all the way to the time the service is removed. That also means orchestrating the removal of infrastructure configurations, and you can’t do that efficiently or completely without a fully documented list of details from a service’s beginning to end. With those details at hand (because they’ve been tracked through automation and orchestration), not only can you bring a service down quickly and return those resources — you can do it reliably, confident you haven’t missed anything due to manual oversight.

When you can accomplish that, you can get really clever take a lot of the work off your plate while giving more of the power to the end user requesting the service.

In the case of our contractor example, since we can track who requested the service and we also know the term of the contractor, we can orchestrate a scheduled process to contact the original requestor 30 or 60 days before the term date and allow them to renew the service through the appropriate systems (e.g. ServiceNow).

And if they fail to renew, the service can be removed automatically. And what if a renewal slips by unapproved? No worries — you have the last state details tracked before the removal so you can turn everything back up again like Day 0. If this starts to happen a little too often, you can institute a deactivated state in your system where the service is blocked for a time before configurations are actually removed from the infrastructure.

As IT leaders look at automation and orchestration to help them deliver infrastructure requests faster, they should also consider how they are tracking details and changes over time and how long it takes teams to collect these details when they are needed for changes, troubleshooting, or audits. When you uncover those details, you may be surprised at just how much more there can be to the story and how much the right solution can help deliver more efficiency and confidence to the entire organization.

This isn’t just a good idea, it’s reality. You can actually see how to use stateful orchestration yourself with the Itential platform. Check out this recent demo where I show how to use automations in orchestrated workflows to manage complex services over time and integrate with your current processes and IT systems.