In classical IT, we must first differentiate between infrastructure security and application security, at AWS, it is up to the provider to manage this infrastructure security.
Cloud computing makes it easy to adapt products to demand, but the security of these products is critical and should not be overlooked. To do this, public cloud providers offer a fairly complete range of tools that can be used.
Depending on your choice of provider, you will have more or less IaaS (Infrastructure as a Service), PaaS (Platform as a Service) or SaaS (Software as a Service) services.
The shared responsibility model differs by type of service, however. There are three categories of service types: infrastructure services, container services, and abstract services. Let’s compare the three categories of service type and how the security and compliance property varies between them
Infrastructure services
An infrastructure service is a type of IT service where the infrastructure that traditionally exists in a local data center is hosted by a provider (in this case, AWS) in the cloud.
For infrastructure services, AWS is responsible for:
- Basic services (network, storage, processing)
- AWS global infrastructure
- AWS Identity and Access Management
- AWS API endpoints
For infrastructure services, the customer is responsible for:
- Customer data
- Client applications
- Operating system
- Network and firewall
- Identity and client access management
- High availability
- Scaling
- Instance management
- Data protection (transit, rest and backup)
Container services
Multiple applications to share resources running on the same operating system.
For container services, AWS is responsible for:
- Basic services (network, storage, processing)
- AWS global infrastructure
- AWS Identity and Access Management
- AWS API endpoints
- Operating system
- Platform / application
For container services, the customer is responsible for data
- Firewall (virtual private cloud)
- Client identity and access management (database users, table permissions)
- High availability/scaling
- Data protection (in transit, at rest and backup)
Abstract services
Storage, database or messaging service are the abstract service.
For abstract services, AWS is responsible for:
- Basic services (network, storage, computation)
- AWS, global infrastructure
- AWS Identity and Access Management
- AWS API endpoints
- Operating system
- Platform / application
- Data protection (at rest – SSE, in transit)
- High availability / scaling for abstract services, the customer is responsible for:
¬ Customer details
¬ Data protection (at rest – CSE)
Although AWS has very strict security and compliance standards, always remember that security and compliance are shared between AWS and the customer.
Your content goes here. Edit or remove this text inline or in the module Content settings. You can also style every aspect of this content in the module Design settings and even apply custom CSS to this text in the module Advanced settings.
Principles of application security and their implementation in the cloud
Shared responsibility, therefore, requires us to apply basic principles that will influence the architecture of our new application. These components allow for increased security and better risk management.
Control flows
We must take into account the connection flows between our current information system and the cloud, in both directions of traffic, this is an additional risk in the functioning of our applications vice-versa traditional IT.
By default, all flows must be closed, and in the case of a potentially more exposed development environment, attention must be paid to inter-environment flows to limit the risks of leaking production information. Therefore, we ensure that any open flow is subject to an in-depth audit.
Purpose: To prevent the entry and spread of malicious information and the escape of information by compromising a system.
Services to use:
AWS VPC, Security groups, Endpoint Services, Network ACLs, Route Tables, AWS WAF.
Protect data
In the context of the new laws on the General Data Protection Regulation (GDPR), data protection has returned to the center of considerations, so we have to think about encryption.
Encryption yes, but how? There are two methods of encrypting files, encryption at rest which protects the stored data and encryption in transit. We can go further by applying a second, finer encryption to protect sensitive data. By default, all data must be encrypted.
Also, it is recommended to use versioning to store the data with, in the best of cases, replication between different regions. These security measures harden tolerance for data loss in the event of improper handling.
Purpose: To prevent data exploitation in the event of a data leak due to an intrusion.
Services to use:
AWS KMS, EBS volume encryption, S3 data encryption, EFS encryption, RDS instance encryption, DynamoDB table encryption, EMR cluster encryption on server side and in transit, AWS Redshift instance encryption, TLS / SSL encryption in transit via AWS Certificate manager or by importing proprietary certificates, AWS S3 Cross-Region Replication, AWS S3 versioning, AWS S3 Glacier Vault-lock.
Secret Management
Any encryption involves encryption / decryption keys. To do this, a secret management policy must be applied. This procedure should also apply to authentication systems between application bricks, API keys, user names, and passwords. To simplify this task, AWS offers services that handle this by default or as an option.
The best option is to store this critical information in a safe that manages the rotation of access keys or has IAM control.
Purpose: To prevent the extrusion of system access and authentication data.
Services to use:
AWS KMS, AWS CloudHSM, AWS SSM Parameter Store, AWS Secret Manager.
Identity and Access Management (IAM)
To allow interconnection between the application bricks and access to the AWS platform itself, AWS IAM provides a mechanism for limiting access and internal identity to AWS. This brick includes both user access by group and access by application.
The management of these access policies must be reviewed before allocation; by default, the minimum access policy is recommended.
For example, if you give a user the right to attach an IAM role to a service, you must specify the resource in question in the rights policy; otherwise, he will have the ability to assign himself the administrator role and therefore modify his policy.
Purpose: To prevent any alteration of the existing infrastructure, improper handling or malicious action.
In the case of a company with a large number of users, the management of these rights policies can quickly prove to be chaotic, AWS facilitates the federation of accesses to their platform via the Active Directory or AWS Organization.
Services to use:
AWS IAM, IAM groups, IAM roles, IAM policy, IAM permission boundaries, AWS SSO, AWS STS.
Traceability of actions
To allow maximum audibility, we must apply a strong categorization of resources, a centralization of technical and application logs.
For the categorization, it is recommended to apply a nomenclature of naming sufficiently explicit to be able to carry out an inventory of the services by their name. Then, a tag policy is necessary to be able to more easily follow the invoicing of each service and to be able to detect any abnormal increase in load.
When we think about the traceability of actions and resources, once the naming conventions are applied, we must focus on the centralization of the data linked to these actions. Ingestion, storage, and interrogation system must be set up to allow effective monitoring.
To effectively trace information, two components must be taken into account, the traceability of applications which allow us to understand errors and the traceability of network movements (VPC and API). Therefore, the use of a SIEM (Security information and event management) is recommended.
Goal: be master of events and be able to justify any activity on the platform.
Services to use:
AWS Cloudtrail, AWS Config, AWS VPC FlowLogs, AWS SNS, AWS Cloudwatch, AWS Elasticsearch.
Conclusion
AWS Shared Security Model is a powerful and particularly useful platform that builds the capacity of IT departments and application groups. Properly administered, it can be a safe and efficient tool for storing data and serving as a basis for more complex applications. customer service ensures you the best end-to-end solutions, including practical technical assistance in managing organizational change.
Understanding The AWS Shared Security Model
