Cloud security refers to a set of standards, methodologies, and technology for managing and securing cloud environments. Cloud encryption can reduce the risks associated with transitioning to a cloud network by using stringent access restrictions, server checks, commitment to global security frameworks, and other steps.
For anyone planning to use one of the world’s leading cloud providers (Google Cloud, Microsoft Azure, or Amazon Web Services), cloud protection is less about building up a secure cloud and more about using it efficiently, as we discussed earlier. After all, these businesses had now spent a significant amount of money to secure their infrastructure. Anyone building up their own cloud, on the other hand, has a lot more to think about, including security engineering, securing physical resources, disaster recovery, repair, and connectivity continuity
Cloud encryption also aids organisations in adhering to international legal guidelines such as the GDPR, as well as preparing them for potential prohibitions – which are constantly being addressed. To comply with the GDPR, for example, businesses must ensure that their cloud was designed with appropriate infrastructure and that protection and privacy is included during the design process, otherwise regulators may levy hefty penalties if a violation occurs.
Cloud Deployment Models
There are several different types of cloud models, and their structures are grouped into the following categories depending on who owns them or where they are hosted:
Some cloud services are provided by CSPs (cloud service providers), but these cloud servers are accessible to the public through the internet. The benefit is that users are only paying for the time they use the service. However, since resources are shared, there is a security risk.
Companies that need more protection prefer this model because one cannot access it directly through the internet. Instead, they must use a VPN file to access the resources. This model is adopted by the banking, government, and healthcare industries, all of which rely heavily on data.
This model is used when a couple of companies want to pool resources for common concerns like setting the same security policies.
Securing the Application on Cloud
The preservation of cloud deployment becomes increasingly important as more applications migrate to the cloud to centralize access and management.
Using Active Directory (AD)
On the cloud, too, an active directory simplifies authentication and authorization processes. It’s a “centralized repository” for managing credentials. If an organization has many employees, adding, updating, or removing any policy becomes very easy after implementing an active directory.
We can see how the active directory operates in the picture above and some applications that are already integrated with AD.
- Users first type their credentials into the application.
- Those credentials are sent to the backend database (AD) via the AD API and are matched.
- If the credentials are correct, AD will provide you with a token to continue, but if the credentials are incorrect, the user will be prompted on the UI with the message “Credentials are incorrect”.
The Azure cloud provider has a feature called “Simple Auth” that is part of its AD. Users do not need to write any code, and only minor functionality upgrades are needed to access the application on the cloud.
If it’s a house or the cloud, keys are always the entry point. If we have authentication keys, accessing data on the cloud is a breeze. It makes no difference if the data is encrypted or in plaintext; if a hacker has those keys, they can access and steal sensitive data.
How to protect?
- Regularly rotate the keys.
b) Have a backup key on hand in case the user locks himself out of all your files.
If a company only has 4-5 or maybe 10 API keys, managing them is easy, but it becomes more challenging if a company has thousands of API keys. They may also use key management systems (KMS) to support them.
The data is protected by a “customer master key” (CMK) in the KMS, and the key never leaves the KMS. So there are various models for managing the CMK; it is up to the company to decide which one they will use. These are:
a) Cloud managed key/bring your own key: The user manages the key, but cloud services such as AWS may use it.
b) Cloud provider manages the key: It is here that the cloud provider maintains and stores the key for future tasks.
c) Customer manages the key: The user manages the key. Cloud services such as AWS do not use those keys and are unaware of the encrypted file contents.
Note: Companies almost always tend to keep keys separate from data.
Restrict Source IP Address
We can protect our cloud-based application/infrastructure by limiting the source IP address. Attackers also use OSINT and other information collection techniques to look for available ports on the network and collect other useful information. As a result, they can access internal resources through the internet. Port opening without restrictions exposes your network to such malicious behavior. You can restrict internet access to open ports to a collection of predefined or whitelisted IP addresses.
How can we implement it?
AWS: If a request arrives from beyond the designated IP range, the IAM policy refuses access to all AWS services. This may be applied to a collection of IP addresses or a single IP address.
In the screenshot below, we can see how we can limit the subnet of a certain IP address using IAM policy.
Azure: We can use “Azure Front Door”. We may use it on a single IP address or a group of IP addresses, much like AWS. The firewall administrator must first identify the address set he needs to whitelist. Azure works on two types of IP addresses: “RemoteAddr” and “SocketAddr”.
- “RemoteAddr”: This is a client IP address by default.
- “SocketAddr”: WAF identifies this IP address.
Note: Use caution when implementing this function. When an administrator grants authorization to the entire subnet, unauthorized users may access the data. They have not only access to the data but also the ability to change it.
Network traffic & access log
Determine the traffic and access patterns that can pose a security risk to cloud applications using network logs. Users and employees have access to those files at all times and for any reason. Since users invest in these archives, they clearly understand the system’s access history and what data is being exchanged?
We have “VPC flow logs” in AWS that can be used to track performance, log firewall incidents, and many other things. We can export logs from it and review them against company policies.
Multi-factor authentication (MFA)
Multi-factor authentication can still be used to access cloud services because it improves the protection of data and applications in the cloud. We must enter passwords at the first layer of authentication in MFA. The cloud will lead you to the second layer if the user enters the correct credentials. There may be a variety of choices for the second layer depending on the form of MFA used, such as:
- You can remember (secret questions)
- You can carry (credit cards or RSA token)
- Something you have (voiceprint, fingerprint)
MFA can be divided into the following two categories.
Hard Token: Organizations have small hardware, such as RSA tokens with a random digit code, as part of it. The code must be at least six characters long.
Soft Token: This token can be sent to the user’s registered cell phone number, or they can use Google Authenticator to get the code.
To extract application data from the cloud infrastructure, attackers must breach second layers.