With the rapid developments in the field of cloud, cloud environments are becoming increasingly complex. To ensure that your cloud environment remains compliant, you need guardrails that define the boundaries within which end users/developers are allowed to move. The right policies on your cloud platform facilitate your end users and support the auditors in determining the compliance level for certain guidelines such as ISO 27001, CIS and NEN 7510. But how do you keep a grip on your cloud environment when governance can no longer be achieved manually?
With all the changes in the Azure platform, it has become difficult to manually check for governance. Therefore, about 800 predefined policies already exist in the Azure environment. In addition, there are 2,360 additional policies available that have been provided by the community. All these policies form a good basis to start setting up your cloud environment. But because every cloud environment is unique, additional policies are needed that better fit your organisation's governance.
Definition Azure policy
What is an Azure policy?
An Azure policy is a mechanism in Azure with which rules for implementation can be tested and possibly enforced.
Auditing of these rules can also be performed across the Azure platform. You can also combine different policies into a group, also called a policy initiative. An example of such a policy initiative is NEN 7510. To simplify the management of the policies for these regulations, they are grouped to a policy initiative that supports the interpretation of the compliance to such regulations.
The principle behind the policy
In the world of compliancy, the comply-or-explain principle applies. Based on this philosophy, a set of policies puts the right guardrails in place that give the end user and developer the freedom to determine how to do something. The policies thus define the size of the playing field. Whereas policies have traditionally been used to state "you may only do this", today they state "you may only not do that". By shifting policies to an enabler function from compliance perspective, you give the end user and developer much more freedom.
Definitie Comply or Explain
What is Comply or Explain?
Comply or Explain is an approach whereby organisations can decide for themselves whether they comply with a certain code or policy.
If an organisation decides not to comply, an explanation is required. The way and extent to which this explanation is required depends on the framework that you establish as an organisation.
Different shapes and sizes
In a running cloud environment, nothing changes when you assign a new policy. This policy only becomes active when you roll out a new deployment, regardless of the type of policy. This makes the application of a policy low threshold. Each type of policy has its own advantages and disadvantages. Which type you roll out depends on the governance of your organisation's cloud environment.
Deny
With a deny policy you specify what a user is not allowed to do within the IT environment. This way, you determine the playing field for the user, without taking away his freedom. Take Prevent Public IP-based Services as an example. Here, you indicate that developers are not allowed to access certain services from the Internet. If developers do so anyway, they are stopped by the deny policy.
A disadvantage of using deny policies is that you can blindly take over the existing set of policies. Without an evaluation of the existing policies, you run the risk of knocking down your production environment during the next deployment. In this case, the existing deny policies block the newly deployed policies.
Allow
The allow policy is the more traditional type of policy and specifies what is allowed. It is, as it were, the opposite of a deny policy. An example of this is Allowed Locations. With this policy you indicate in which Azure regions a developer is allowed to roll out something. Hereby, you can make sure that all resources are deployed within Europe, or deliberately not because of contingency. This way, you can determine regionally what is allowed or not.
Whereas policies have traditionally been used to state 'you may only do this', today they state 'you may only not do that'.
Audit
An audit policy is used when you only monitor whether something is allowed or not. Things that are not allowed are marked as non-compliant. However, the responsibility for modification lies with the user rather than with compliance. This type of policy is normally only used in test environments, to see whether the solution is compliant or not. In the production environment, these audit policies are converted to deny policies, blocking the rollout.
With audit policies it is important to check the status of non-compliant items. If these items are not remedied, this will work against them later in the process. The responsibilities for this must be clear within the organisation, so that non-compliancies are picked up in time. This responsibility often lies with the development team that deals with the roll out. After all, working in the cloud involves joint responsibility for cloud governance.
Deploy if not exist (DINE)
With a DINE policy, you exercise control, whereby, unlike audit policies, you do make the necessary adjustments from a compliance perspective. When the user does not set a certain setting, value, or configuration, it is done for him because it is mandatory. Think, for example, of policies around logging.
The danger in using DINE policies is that your solution unintentionally changes completely into another type of solution. The cloud architect designs environment A and after deployment of all DINE policies eventually gets environment B. A DINE policy can also undermine your architecture itself. For example, you can force an http environment to automatically become an https environment, although this does change your website. When a policy makes such a change and a problem arises in your environment, the policy is often the first to be blamed for the undesirable situation. So, if you want to prevent your solution from being changed, a DINE policy is not an appropriate choice.
Working in the cloud involves joint responsibility for cloud governance.
Exemption to the rule
As mentioned earlier, the comply or explain principle applies in the world of compliancy. The policies you roll out in your cloud environment fall under comply. The exemptions you make to your policies fall under explain. It is possible to make an exception to a policy for a certain period of time, or even indefinitely. For example, you can make an exception for one year if the website runs on http instead of https. The developer must then pay attention to the expiry of this exception and resolve the non-compliance before that time.
Policy driven cloud governance
Policies therefore ensure that you keep control of your cloud environment, even in an increasingly complex IT landscape. With the right set of policies that suits your organisation, you set the framework in which users can move, without limiting their freedom. The different types of policies also give you the possibility of spreading the compliance responsibility throughout the organisation. This way, you turn compliance into a business enabler!
