The acceleration of digital transformation and cloud migration over the last year and a half has brought to the forefront the importance of protecting data, irrespective of where they are used, the device used to access them, or the place where they are stored. In that sense, data security must be contemplated from the app design stage.
When working in the cloud, there are two aspects that have to be closely watched: firstly, at the infrastructure and application level and, secondly, at the user and development team member level.
As regards infrastructure, cloud providers themselves usually offer some type of role-based access. This means that whoever is in charge of monitoring infrastructure will be able to use, create or destroy cloud resources as required by the project. At the same time –save for exceptional cases– developers will only be able to interact with what they need to complete their work.
Additionally, other than the role-based restriction, other tools are provided to mitigate and protect against attacks, such as the case of WAFs (Web Application Firewalls), Threat Detection Services and logging tools to trace calls to the cloud API, incoming/outgoing network traffic, metrics monitoring (resources and software) and alarms to detect anomalies both in the infrastructure and in the apps that reside there.
Infrastructure and application level
Also, from the point of view of infrastructure, the idea is that each resource should have a very limited scope. During the project, work is done in various environments: development, testing, quality assurance, preproduction, and production. To limit any exposure to vulnerabilities, the process is granular. The development environment server has no access to the services used by the production server or any other server in the ecosystem.
What about the application level? As it runs on the infrastructure, it inherits its services: if the server reaches the database or a specific type of storage, the application will also do it.
On the other hand, serverless technologies and containers limit the interactions that can occur with the applications and the operating system running in the background. This makes it more difficult to exploit vulnerabilities of the environment where the applications are running.
User-level
User-level security must be set in the application itself. Suppose the app requires some type of login. Regular users typically have access to data that have to do with themselves and the transactions they have to complete. In that case, the measure is to establish an access control module to determine the app segments and data that administrators will visualize – they usually have access to all the information. Finally, the control module will determine which steps will be taken when a non-registered user requests access, from denying movement and defining alerts to showing a preview if the app wants to “seduce” new users with that strategy.
Integrated security
Additionally, methods can also be created to restrict the point where access requests originate. For instance, a web application can be set so that the only point from which to make requests to the backend is the website itself and that any attempt made from another site or local computer is blocked. Cross-Origin Resource Sharing (CORS) makes sure the operation is transparent: in general, when a website is accessed, the browser downloads it and keeps it temporally in the disk, from where the requests are sent to the backend. CORS itself makes sure that all the necessary precautions are taken.
One of the most common threat formats is “Distributed Denial of Service” (DDoS), which prevents genuine users from accessing services. In general, each cloud has specific tools to mitigate this situation. In the same way, cloud providers set up certain protection levels for elastic load balancing models that automatically distribute incoming traffic to different destinations, optimize workloads and adapt to changes or support scale differences.
More specifically, additional control mechanisms have to be incorporated when dealing with mobile applications in the production stage. As they are not hosted in the company’s cloud, but rather in stores (e.g., Android or Apple), validations will have to be added, such as tokens or API Keys (in the event the user is trying to access an API).
The critical point in terms of cloud security in particular and security of information, in general, is truly dizzying. Threats are constantly increasing; they change and improve every minute so that any strategy to mitigate them must be equally effective and dynamic.
Any communication between the client (website, mobile app) and a server must be secure. For that purpose, encryption is applied through TLS/SSL (referred to as encryption in transit) to protect the information and the data stored. In the event of a security breach, they are kept in encrypted storage units. Cloud providers offer mechanisms to conduct such operations, including handling keys to encrypt/decrypt data. However, it is possible to provide security keys instead of having the supplier as the exclusive manager. This protection mechanism is called encryption at rest.