Hello, and welcome to our course summary. This lecture provides a summary of what we've covered in our previous lectures. In our first lecture, we outlined the shared security model. We learned that a simple way to think about the shared security model is that AWS manages the security of the cloud, while we, the customer, are responsible for everything we do in the AWS cloud. AWS responsibilities are the global infrastructure elements, regions, availability service and edge locations and also the infrastructure elements of their compute, storage, database and network services. AWS owns and controls physical access to their data centers, where your data resides. This covers physical access to all hardware and networking components and any additional data center facilities. As the customer, we're responsible for anything in the cloud. This includes both client and server side encryption and network traffic protection, all the way up to the security of the operating system, network and firewall configuration, followed by application security and identity and access management. Access management is an important distinction. While AWS manages access to physical resources, access to amy virtual services you run in AWS is controlled by you. Then we looked at identity and access management, or IAM. We learned that the root user is the most powerful access credential in an AWS account. The root user is associated and unique to the account record and it cannot be restricted in any way. Second, we learned that IAM users are persistent identities controlled via IAM. This means you can associate roles and policies to an IAM user, thereby restricting or allowing access to services or resources. We learned IAM groups simplify the management of IAM users. We can assign permissions to a group, instead of assigning it to an individual user and insert that user into a group. Roles provide temporary access with different credentials. Roles are, in essence, identities. They're similar to users, in that you can assign policies to them to specify the permissions, that they might have. However, roles were designed to be used by more than one entity. It means that many entities can assume a role and IAM user a service, such as EC2, or even users outside your AWS account can assume a role. Policies are the way to define the permissions and rights that an identity will have. You can associate policies with users, groups or roles. The standard rule gives an identity no rights at all, so you need to explicitly declare the rights of an identity through a policy. Then we looked at the AWS Directory Services. We learned that AWS provides two suites of directory services. First, we have the Amazon Cloud Directory. The Amazon Cloud Directory is a highly available multi-tenant directory-based store in AWS. It suits applications such as Internet of Things, IoT applications, device registries, social networks, network configurations and user directories. Second, we have the AWS Directory Service. The AWS Directory Service is built round the Microsoft Directory Service and suits users looking to run and connect to Microsoft-based directories. The AWS Directory Service offers three services, Microsoft AD, Simple AD and the AD Connector. We then explored Amazon Inspector. We learned that Amazon Inspector is an automated security assessment service, that can be set up to run within your AWS account. Inspector can assess security vulnerabilities and compliance issues in applications you have installed on EC2 instances, which collectively are called an assessment target. Inspector requires you to install an agent onto any EC2 instances you have, which you want to include as a target in your monitoring. Instances need to be tagged to be included in assessment. Assessments are comprised of rules. Assessments create findings. Each finding will be displayed relative to a rule. Each rule has a severity level associated with it. Groups of rules are called rule packages. Rule packages include common vulnerabilities, exposures and security best practices. The Inspector service, combined with these libraries provide significant benefit to us as users as it helps us keep our environment secure and compliant. Next we looked at the Web Application Firewall. We learned that the Web Application Firewall provides a flexible, managed service, to protect your websites and applications. The Web Application Firewall works with Amazon CloudFront and other services, such as Amazon Application Load Balancer to filter both HTTP and HTTPS traffic by distinguishing between legitimate and harmful inbound requests, that will then either be allowed or blocked. When an incoming HTTP request comes into the Web Application Firewall, it'll be matched against a rule base in order that they appear. Conditions allow you to specify what elements of the incoming HTTP or HTTP request you want the Web Application Firewall to be monitoring for. Rules are combinations of conditions. You can associate many conditions to be evaluated during requests and how the conditions will relate with each other. In closing, let's just run through some of the general security principles, that are important for managing services in AWS with the shared security model. First is the general security principle of least privilege. This principle basically states that you should only grant the permissions that users need in order to complete a task and no more. AWS works with this principle in mind, as we've seen examples of that during this course. Remember the role that we created in order to let the Inspectorate do its work? Well, that's an example of AWS putting this principle to practice. They could simply allow the agents running in your instances to communicate with the Inspector service by default. However, they prefer having you grant permissions explicitly. IAM best practices are crucial to managing a secure infrastructure. You need to ensure you have secured your root account, which means three things. First, enable MFA, Multi-Factor Authentication for your root account. Second, lock it down and reduce the use of this account to root-specific tasks only. You should not use your root account for day to day admin tasks. You can perform any action you want using an IAM user instead. Third, never share your root account, no matter what. You should use groups to assign permissions, instead of granting permissions directly to your IAM users. Enable MFA for all privileged users in your account. Rotate your credentials, not only the passwords, but also the access keys. And last, use IAM roles whenever possible. Security groups are also something to consider. First of all, you should use the principle of least privilege to configure the roles. A good way to grant permissions only for the right resources is by configuring the inbound rules to accept only requests coming from resources in another security group. For example, you might have a web application with a web server running on an EC2 instance and an RDS instance. In the security group of the web server, you should only open the ports, that your application needs, in this case port 80. However, in the security group of RDS instance, you can choose to accept only connections coming from resources in the web server security group, by simply entering the security group ID, where you would normally enter the IP range of your web instances. Note that this can further restrict requests to include only data-related ports as well. For networking, you should consider using network ACLs, which, because they work at the subnet level, add an additional layer of security above and beyond security groups, that work in the instance level. By using network ACLs on top of security groups, you can block unwanted access, that you may have neglected to block in the security groups. You could, for example, block all the traffic coming from a suspicious IP address to your public subnet, because unlike security groups, you can define deny rules in your network ACLs. To provide even more protection for your resources, you should segment your VPC into public and private subnets. The resources in the private subnet cannot be accessed directly from the internet. Sometimes you may have resources in a private subnet, that you need to access on rare occasions. To solve this, you can deploy something called a Bastion host. A Bastion host is an instance that you place in a public subnet and give permissions to access your resources in the private subnets. As a best practice, you should allow access to it only for connections coming from a secure IP address. Also, you should only start the Bastion host instance when it is actually needed and stop it when you're done using it. It's your responsibility to manage access to your resources. So for instance, when you're setting up S3 access, you should work with tools like object ACLs and Bucket Policies, always keeping in mind the principle of least privilege. That completes the AWS security fundamentals course. We hope that you've enjoyed this course and please feel free to contact us at support@cloudacademy.com with any questions, comments or feedback. Thank you.

Lectures:

• AWS Security Fundamentals
• AWS Shared Responsibility Model
• Identity and Access Management
• Amazon Cloud Directory
• Inspector
• Web Application Firewall
• Security Overview

0