Security basics for the cloud

More and more companies are using public cloud computing resources for their IT requirements. Companies often test the water first with pilot projects to explore how cloud computing could work in their IT landscape but some, often based outside Germany, are already willing to take the risk of moving to the cloud and are already transferring significant parts of their IT infrastructure to Azure, AWS or Google Cloud. Whether this makes sense in terms of costs, data protection and intellectual property protection is a different matter, but that is what pilot tests are for. Cloud connections must be secured effectively. Although every organization needs an individual architecture and security concept, a few basic rules apply to all projects.

Credentials are an essential component for securing IT resources whether they are on-premise or in the cloud. If credentials, in the worst case privileged accounts, are compromised, this renders any technical security barriers useless whether they are on edge, perimeter, core or end devices. If an attacker gains root access to a server, the game is over and admins can only hope that sensible network segmentation can limit the damage until the attack is discovered. A nice example of this is the recently published incident at Tesla when an attacker hijacked resources in the Amazon cloud with the captured credentials of a DevOps developer to mine crypto currencies.

It is not without reason that the role-based access concept (RBAC) is one of Azure's most effective security measures. Taking the allocation of rights and access control seriously is therefore highly recommended. The first step is to use a common security model with appropriate roles and rights distribution for all resources. It is error-prone and simply unnecessary to separate cloud and on-premise in the security model. Compliance is compliance and this applies to all systems, no matter where they are physically located. Of course, there are aspects that differ between cloud and on-premise systems, especially as far as compliance is concerned. But the specifications are identical and they should also be mapped in a comprehensive security concept. In any case, this includes extending Active Directory to cloud resources and mapping a common rights and roles concept via AD. The cloud provider should not operate a separate identity and access management system for the cloud resources. If they do, it is important to secure the access via a Privileged Access Management (PAM) solution.

In general, it is best practice today not to use non-personalized accounts (NPA) like "root" for admin purposes. Administrators should always work with a personalized account so that activities in the logs can be audited more easily. If this cannot be implemented for technical or organizational reasons, or if compliance requirements require permanent monitoring, PAM solutions are the perfect answer. Vendors like CyberArk or BeyondTrust have products that work in cloud environments.

Before personalized accounts and suitable log products can be used effectively, the assigned rights should be considered carefully and critically. Often administrators accumulate rights, which are no longer needed but not returned. At least for cloud resources, it is important to assign rights granularly. Cloud management consoles offer many ways to delegate rights on a role basis so that admins only have the rights they really need. Last but not least, another well-known recommendation for cloud environments is an absolute must: All administrative credentials must have two- or multi-factor authentication enabled.  Although 2FA and MFA do not make stolen credentials completely useless, it does mean that attackers have to work harder to gain the extra authentication factors to access the system. If you want to move to the cloud, you need to be thinking about rights management and multi-factor authentication.