BACKGROUND IMAGE: iSTOCK/GETTY IMAGES
IT professionals have dealt with the trio of governance, risk and compliance for decades. But for most of that period, they've had two major pillars to build on. One was the idea that data center security could be presumed effective with the right setup. The other was that GRC could be effectively applied at the application level. Cloud, service-composed and microservice-composed applications have knocked both of these pillars down.
IT departments have to respond appropriately. This can be accomplished by architecting the GRC system holistically, harnessing enterprise architecture (EA) and application lifecycle management (ALM) practices, and applying governance and risk management when a "preferred state" isn't met.
New GRC challenges
The challenges created by new applications are easily illustrated with the example of payroll. In the past, this application was run in the most secure facility available, execution and access were tightly controlled, and the databases used were separated from mainstream repositories. Security and compliance in the past was based on the "barrier model" that controlled the corporate perimeter and put only public web servers outside. Services and microservices encourage free composition of applications that could bypass traditional controls. Creating access to a simple list of employees could end up providing full database access, potentially compromising personnel and payroll data.
Even with service- and microservice-based applications, it's still possible to create virtual private networks to contain applications and data that are subject to GRC. The payroll example is one such case, since personnel and payroll data isn't normally widely accessed. Network-based segregation of services and microservices won't work for mission-critical applications, though. With these applications, the need to access data and compose applications from services is almost unbounded. You need a holistic mechanism.
Implementing holistic GRC
A holistic GRC system doesn't depend on barrier security of segregation and authentication at the application edge. Instead it depends on what some call "defense in depth," a model where all service requests are authenticated by validating the credentials of the calling element when the request is made. Every service then has to maintain knowledge of the applications and processes allowed to invoke it. That way, a spurious call to a service will be immediately recognized and then rejected -- or redirected to a sandbox where the intruder can be trapped.
The difficulty with per-service GRC enforcement lies in enforcing the validation requirements at each service point. The more agile a business is -- and the more it relies on ad hoc application composition -- the greater the pressure to relax service-level security in favor of easy application composition. One response to this is to simplify the service-level security processes.
SOA, with features from WS-Security, can provide explicit validation of all service exchanges. It can even be applied to RESTful microservices. However, some IT organizations find the overhead of the various WS-specifications excessive. One alternative approach is to use an API key, and in particular a hash-based message authentication code that combines hashing of timestamps, caller ID and other information with encryption. The most modern approach is to use a blockchain technique that makes key control fully distributed. Note that with all these techniques, it's important not only to validate the calling module, but also to ensure no parameter values have been altered. Otherwise, the result is unlikely to pass a compliance audit.
Leveraging EA and ALM
WS-Security, WS-Trust and the API key systems presume that only authorized interactions will be validated. Unfortunately, too many service and microservice developers fail to secure the authorization processes. This is where EA and ALM practices can combine to enhance the effectiveness and efficiency of the GRC system at the same time.
Nobody in a business should be composing applications or changing component relationships without involving EA, ALM or both. It's good practice to assume that valid new applications or workflow relationships could arise from a business need and be passed through EA modeling to establish the scope and benefits. New applications or major application changes should follow this path. So it's at the handoff between EA and the development or operations groups where security changes should be made to service or microservice components.
Minor changes in applications often bypass the EA process. Here the goal should be to enforce GRC in the ALM flow. To do this, it is absolutely critical that every application description includes a list of the services or microservices it references. It's also important that any change to a service be used as a trigger to activate ALM on all the applications where that service is used. Microservice evolution in application development sometimes skips this service-driven-ALM approach, and this can result a major security and compliance blunder.
Extensive use of microservices and "compositional development" by assembling services rather than low-level programming can eventually leave IT with a collection of microservices and not really a collection of applications. To avoid this, a business can use both EA and ALM to look at possible service combinations and their GRC implications as opposed to testing static sets of service-to-application relationships.
Managing this open-microservice future can be easier if you define a series of preferred states. These are states where most or even all service combinations are secure and compliant. Changes to services should then revalidate the GRC status of each of these states. As long as a new microservice or application relationship fits within the preferred states, it is assured of GRC support. That focuses both EA and ALM on recognizing a service combination that doesn't fit and validating a new preferred state to match it.
Microservices are likely to become, in effect, a high-level development language. That will have profound impacts on everything an IT organization does and how it does it. With microservices becoming mainstream, now is the time to get control of your own microservice GRC system and stay ahead of any potential issues.
What do microservices and containers mean for your enterprise architecture?
Learn what causes cloud microservice performance issues
Discover how to use microservices for effective IoT