Auditing does the accounting of user activity on data. Here, we log all the activity of users including login time, session duration, and all the activities that they perform.
The cloud offers multiple options to implement the security, but it solely depends upon the security requirement and our expertise to implement it.
One thing we need to understand is that implementing security in the cloud is a bit different from what we have been practicing with on-premise or traditional infrastructures.
We learned previously that the cloud runs on top of physical boxes, such as storage, servers, and networking equipment. All these resources are controlled by a layer of abstraction that we call a hypervisor or virtualization layer. Further, all the aggregated resources are being controlled and managed by an orchestration. Internally, all these layers communicate with each other through an application program interface (API).
In the cloud we can also start implementing security with CIA and AAA models. Here, we have the following services in the cloud to implement CIA and AAA models:
- Confidentiality: Here, we use Identity and Access Management (IAM) to define the resource accessibility permissions. In IAM, we can define users, groups, roles, and policies. IAM also helps to manage the API access using access keys and secret keys. Similarly, we have a keystone in OpenStack to define users, groups, roles, and policies. You can define policies to access the other OpenStack services and APIs.
- Integrity: For integrity, we have multiple types of encryption for the storage where data is stored and for data in transit we can use SSL. If we want to implement an additional layer of security, we can use the AWS CloudHSM module as well. In OpenStack, we have the following process to manage integrity. It starts from the bootstrap level and goes up until the file level. (We've studied this process in detail in the Private cloud section.)
- Availability: For availability, AWS offers you many services that ensure the service availability at different layers. We have Route 53 as DNS, Elastic Load Balancing (ELB), and autoscaling. All three services ensure that you have the service available in case of DDoS attacks as well. Availability of the application or solution also depends on how it is designed and deployed. Let's take an example of a web application; here, in order to ensure maximum availability of the application, we should always design the solution in such a way that there is no single point of failure. For this, we must consider high availability (HA), autoscaling, and also try to decouple the resources (using message queuing) so that it can be fault tolerant as well.
Now, let's map the AAA model in the cloud:
- Authentication: In AWS, we have IAM for user identity. Here, we can define users and groups. IAM enables you to define the password-based authentication and key-based authentication for users. Apart from this, for the application, we can use the AWS Directory Service and Cognito (token-based authentication) for user authentication. For console users, we can also enable multi-factor authentication (MFA) as well. In OpenStack, we have a keystone, which provides user and service authentication. Here, we also create users and groups and define password-based and key-based authentication for users. Apart from this, we can use SAML-based authentication, OAuth, and OpenID-based authentication.
It's always advisable to access the public cloud service using access keys. Do not access the console using root account credentials, and also make sure that you have enabled MFA for user accounts.
- Authorization: For authorization, AWS uses IAM roles and policies. There are many predefined user roles for different services. Apart from this, we can define custom roles. For example, suppose we have an EC2 instance, that needs to access the Simple Storage Service (S3) resource and CloudWatch Logs. Here we can also define a custom role of an EC2 instance which grants access to the S3 bucket and CloudWatch Logs and binds that role with the EC2 instances. There is no need to store the access keys in text format on EC2 instances, but you will find that people are not practicing this. In the same way, if you need to manage multiple or linked accounts then you should define the role for cross-account access and use it instead of logging in using the root account. Similarly, in OpenStack, we have a keystone where we can define different roles and policies for users and groups. For each service, there is an associated access policy file defined in JSON format.
In OpenStack, it is always advisable to use TLS-based authentication and also define formal access control policies.
- Auditing: AWS provides CloudTrail to log all the action or activity for AWS services. Apart from this, we have Virtual Private Cloud (VPC) logs and ELB logs, which can be stored in the S3 bucket or can be transferred to CloudWatch Logs. For analysis, we can use the Elasticsearch service or query it using Athena. For solution auditing, you can use AWS Config and Trusted Advisor. Now we are moving toward machine learning and Internet of Things (IoT). For this, AWS started a new service called Macie, which uses machine learning to identify the accessibility of data and services. In OpenStack, we have a telemetry service called Ceilometer to store and manage logs. Apart from this, you can use custom monitoring solutions called New Relic.
