The Cloud is a new playground that changes the rules and organization of the CIO, including security. Public cloud providers offer a shared responsibility model. In this model, the provider manages cloud security, and where cloud security is the responsibility of the customer. However, this is a very different security model from the one we apply on premise. Here we propose to discover the principles and good practices for cloud security.
On premise security: what to forget
Many security practices become obsolete by the cloud and its native services. Continuing to apply them can even be counter-productive, without providing the expected security.
We have often found that CIOs have created unsuitable procedures for the cloud. That is because they are trying to replicate security practices applied internally in the cloud. The consequence of losing the expected benefits of the cloud, such as the acceleration of time to market, or scalability.
If the security is too restrictive, users will try to find ways to bypass! To be effective on the cloud, you need to keep the fundamentals of security. But change the implementation methods to adapt to the new requirements of DevOps teams. This involves:
- Replace traditional tools with security features already embedded by default on the Cloud
- Leverage the flexibility of the Cloud and DevOps & Agile principles to move from manual right-side logic to shift-based logic.
Secure access to the cloud environment
In the on-premise world, the trend is to control access to administrative infrastructures by centralizing flows through a bastion, via Citrix for example. This can have a big impact on productivity in a cloud environment, without the environment being really secure.
For a Cloud environment, we will use either a VPN, a bastion, or both, respecting the principle that the machines must not be accessible externally. Bastion allows a rebound to another instance, by communicating the private IP address of the machine and the SSH key. The bastion then allows the connection only to this machine.
Attention: Bastion is good practice for accessing machines. But security must be particularly strong given its strategic position in the network.
Network filtering
Managing security on each on premise machine was complex, which is why a central access point was set up with a DMZ. On the cloud, on the other hand, it is very easy to manage security rules by machine or by project. Security becomes distributed, it is no longer centralized in one point.
The cloud nevertheless implies thinking upstream of each application’s security. Even before the development of the application, it is necessary to define what it will operate: which ports, which communications to which IP, for example.
With every project and application being different, the security parameters have to adapt according to the needs. In fact, it is not possible to be limited to an infrastructure model with pre-established rules.
We recommend maximizing the use of cloud security as the first layer of security. Many services offer by default a very high level of security and far superior to what can be achieved internally. But it is up to the user to configure the security rules to restrict access to the bare necessities.
We will also choose the cloud services most suited to the needs of the application, such as an ALB (application load balancer) to filter and accept only certain ports, with a certificate SSL to do HTTPS. This does not exempt to correct the flaws of the application itself, but allows to protect against port scans.
Point of vigilance: Outside the experimental phases, we also recommend using a tool to scan its configuration and check that nothing has been forgotten. Despite good intentions, it is always possible to forget to close ports that have been opened.
Access Management
The management of identities and access remains a fundamental security to guard against the risk of mishandling or forgetting.
In an on-premise environment, we aimed at deploying a management based on central and unique repositories. In the cloud world, we must consider a new layer that is the management of access to the cloud infrastructure itself.
As a good practice, it will be necessary to define in advance the most appropriate access architecture for the cloud. Also ensure the mesh between cloud account, cloud users and application access, master and secondary accounts, accounts dedicated to transverse activities. Don’t forget to revise this architecture regularly to remain consistent with the new uses of the organization.
Attention: Rights attribution procedures must be adapted from the outset to maintain control over the uncontrolled expansion of accounts. This ensures that the most critical actions can only be assigned to a select group of administrators.
Encryption
In an environment where most of it is accessible only internally, the requirement for encryption seems less important. Especially since not all organizations have a suitable infrastructure and are reluctant to assume the costs and operating rules that come with a PKI device.
In the cloud there are default features that make it easy to practice. Suddenly, there is no excuse, you must encrypt everything… or almost: databases, S3, communications between instances, including log escalation…
It is necessary to encrypt the data at rest and in transit, but still think about what needs to be protected. For example on a website, we will encrypt the database, but not the logo. Also note that encrypted communication takes longer, and therefore it has an impact on performance.
Securing the CI/CD chain internally
If we must obviously secure the front and the network, we will not forget to secure each of the machines: we have probably seen a lot of security on the front, with insecure machines with powerful roles, and it is a practice strongly discouraged.
Attention: do not focus solely on the external danger and forget the one coming from the internal.
In the case of the CI/CD pipeline, for example, the machines that carry the pipelines have strong rights, such as the updating of a service, or certain important information such as the identifiers of the databases. It is therefore important to detect any illegal action on these machines, and just as important to partition projects to avoid sharing information from a project to a another, especially when freelance providers get access to CI/CD.
This problem didn’t exist before the generalization of the CI/CD: the Ops managed the setting in production. In this new paradigm, the challenge of security in the cloud is to segment applications and adapt to new development and deployment methods. It also requires to accompany the change of mentalities, since the tendency to “do it as before” remains very strong.
New applications
For Cloud Native applications, include security when designing applications. Also think about the life cycle of the application, including the CI/CD where it will avoid showing passwords.
Among the important reflections:
- Identify the ports used by the application (internal/external), the applications with which it interacts, and choose which ports and IPs to open accordingly.
- Configure Load Balancer to first filter ports and URLs.
- Precisely define the roles to give to each type of machine, to associate them with standard predefined security parameters.
- Use a secret manager, such as Vault, to manage passwords and tokens, and avoid revealing sensitive information. Developers can deploy in production without knowing the passwords of databases. It is also possible to generate time-limited token, just the time of deployment. The token is buzzy for a very limited time.
The Controls
In a relatively linear development environment, the general trend is to position security checkpoints at one time, before production and often manually. In an agile environment that relies on a CI/CD chain, this is no longer possible.
It is necessary to define general control rules, whatever the project is, to supplement if necessary with rules specific to each project. So, define warning thresholds according to the criticality of the environment and the application. We apply these controls to both the cloud infrastructure, the CI/CD chain, and the developed code.
Vigilance point: set up continuous and other controls in “spot check” mode, and automate monitoring, raising alerts and remediation. As a first step, we will use the compliance features in the Cloud environment, before acquiring or developing tools with wider coverage.
Cooperation and training for security for all
With the Cloud’s arrival, the main principles of security have not fundamentally changed, but they now apply differently. Security, which was the business of a few specialists, and concentrated in single points of the infrastructure, became distributed.
The identification, the deployment of security measures and the carrying out of controls are no longer the pre-square of the experts. We will still need security specialists, but there has been a transfer of skills to DevOps: some of the security tasks now have to be handled by these teams. This requires training security teams in the Cloud and DevOps, and vice versa to disseminate security best practices in DevOps teams, so that security teams understand the needs and ways of IT teams, and that they can integrate the security concepts as soon as possible in partnership with the security teams.
