Cloud Infrastructure Security
This is a guide on cloud infrastructure security.
Design and Plan Security Controls
In order to provide adequate protection of our resources, network resources, data at rest, data at transit, data in use, we need to have confidentiality, integrity and availability. Confidentiality involves using techniques and mechanisms that allow only authorized users the ability to view information that we deem sensitive.
Integrity is making sure that we have controls in place that make certain only authorized subjects can modify or change information. This might also include affirming the identity of a communication peer. In other words, identity mechanisms are often combined with origin authentication mechanisms. For example, with a hashed visit authentication code from the SHA-2 family.
And then availability. Availability of systems, application and data, offering uninterrupted access to authorized users to important computing resources. We also have three categories, general categories of controls, administrative, technical, and physical.
[Video description begins] Screen title: Control Category Examples [Video description ends]
The best way to explain these is to look at some examples. And realize however there maybe some carry over. For instance, if you look at technical, and you go down about three quarters of the way. It says intrusion detection systems. An IDS can be a technical control, for example, an appliance or a module on a router or a firewall. It could be running on a Linux server for example, or an IDS could be a physical intrusion detection system like a motion detector or a camera.
But for the most part, administrative which are also called managerial would be hiring and firing practices, classifying data, supervising employees. Security awareness training, implementing principles like separation of duties and rotation of duties, at least privilege. It'll involve the security policy, the written or public security policy. And the most important aspect of that policy, the AUP, the Acceptable Use Policy.
Technical controls are things we put in place, they're hardware, they're software, controlled user interfaces, multi-factor authentication, firewalls, firewall routers. Anti-virus and anti-malware software, access control list and firewall rules, smart cards, biometrics, IDS and IPS systems.
And then physical would be an armed or unarmed guard, fencing, motion detectors, locks, badges, dogs, cameras, alarms, sensors. Anything protecting the campus or the facility or the sensitive areas of the organization.
[Video description begins] A table displays with the following three columns: Administrative, Technical, and Physical. Administrative controls also includes tracking of employee activity, separation of duties. A note displays below the table. It reads: some controls fit into multiple categories based on the context. [Video description ends]
We also have security control types, preventative, basically stops the attacker from performing the attack. Detective, identifies an attack that's happening, corrective restores a system to a particular state before the attack. Deterrent, discourages the attacker from performing attacks and compensating or recovery controls. This will assist controls that are already in place.
The CIS, the center for information security or Internet security has several basic controls which you might make part of your basic security architecture. Inventory and control of hardware assets, inventory and control of software assets, continuous vulnerability management. Controlled administrative privileges, secure device configuration, and log monitoring and analysis. By implementing these top controls, these six controls, you can mitigate over 85% of the vulnerabilities in your organization. They also have some foundational controls and you can see them here.
Email and web browser protections, controlling ports, protocols, and services, secure configuration of devices, protecting data in transit, data in storage, data in use. Controlling your wireless access network, putting in malware defenses, data recovery capabilities, boundary defense, controlled access on need to know or least privilege, account monitoring and control.
[Video description begins] Secure configuration for network devices, such as firewalls, routers, and switches. [Video description ends]
And implementing a security awareness and training program. Incident response and management, application software security, and finally the 20th control, penetration tests, and red team exercises. Here's their website, center for internet security. I highly suggest you add this to your favorites, CIsecurity.org/controls and you can download all the CIS controls in PDF or Excel format. Again, as I showed you these were the basic controls, these six.
And like I said, just implementing those are going to protect you from 85% or more of the attacks. And then you have foundational controls, I showed you those 16. And then the last four are organizational CIS controls. Check out this website and download the PDF file.
Secure the Root Account
Okay, it's time to finally get into the practical aspects of dealing with a Cloud service provider. And the first thing you're going to do is you're going to open up an account.
[Video description begins] Screen title: Securing the Root Account [Video description ends]
What we're looking at here is creating an AWS account. But if you go up to Google Cloud Platform you can do the same thing, for example. Now, this is going to be called the root account at AWS, it's called the billing account at Google Cloud Platform. So for example, here's what it looks like if you go to GCP to create your Google account.
[Video description begins] The AWS Console - Signup web page displays. On the left side of the web page, the text reads - AWS Accounts Include 12 Months of Free Tier Accounts. On the right, a box titled - Create an AWS account, displays. Within the box, the following fields are present: Email address, Password, Confirm password, and AWS account name. A button, Continue, displays below the fields. A hyperlink - Sign in to an existing AWS account - displays below the Continue button. [Video description ends]
Now realize, that either Amazon or Google and others, you can give them a credit card or a debit card, that's going to be tied to your billing account or your root account.
[Video description begins] Screen title: Securing the Billing Account An account creation page displays. It is titled: Create your Google Account to continue to Google Cloud Platform. Below the title, the following fields appear: First name, Last name, and Your email address. Below the fields, a hyperlink - Create a Gmail account instead - displays followed by two fields, Password and Confirm. At the bottom, a hyperlink - Sign in instead , and a button titled Next display. [Video description ends]
Now, you might be asking what if you are a large organization, a large enterprise. Can you do direct billing? In other words, not giving them a credit card where they actually send you a monthly invoice, and then you pay them directly.
Yes, you can do that. But realize with either Amazon or Google, you're going to have to go through very stringent financial questioning and investigation to be able to meet the standards of being directly billed. So for most of us, even a startup company or a small to medium-sized business, we're probably going to give them a corporate credit card. But realize you can do direct billing.
And even though Amazon offers a wide variety of free tier options, and Google gives you $300 of credit, both for the first year, they still have to have some way to bill you. Now, the one thing about Amazon is, once you start incurring charges, they'll start charging you immediately. So you can get a bill if you use something that's not free within 30 days.
Google however, after you use up the $300 of free access, they will not bill you until they contact you and you permit them to continue the relationship. So they both work differently. But realize, you have to protect this root account or this billing accounts.
So often what you'll do is, you will initially create these accounts and then you'll use the IAM feature, identity and access management, to create a highly privileged administrative user. Either way for example with Amazon, the root account, there's still certain things that could only be done by the root account, even if you create that god-like administrative user in IAM. For example, if you want to change the root user details, like the password or change your support plan.
[Video description begins] Screen title: Securing the Root Account [Video description ends]
For example, from developer to business, or business to enterprise. If you want to close out the AWS account, or you want to sign up for AWS GovCloud. There's just certain things that only the root account or the billing account can do. So notice when I go to the IAM area in AWS, it's going to give me some security status.
And notice that it says, first off, you might want to delete your root access keys. This is recommended by AWS. They recommend that you delete these root access keys. Because if somebody can compromise those keys and get access, then you're in trouble, okay? So you can delete those then you would activate multi factor authentication on the root account. So that that way you would use a Gemalto fob or a Gemalto card or you could use software based TOTP compliant. For example, Google Authenticator on your iPhone to do multi-factor authentication, when and if you rarely log into the root account.
And then the next thing would be to create individual IAM users. And the first user or in Google, the first service account you would create would be the most highly privileged administrator, and that's what you would use. That would be the context of managing at the highest privilege level going forward, and then only using the root account for just rare purposes. And we will talk more about IAM coming up.
[Video description begins] The IAM Management Console web page for an AWS account displays. On the top, there are drop-down menus titled Services, Resource Groups, account name, Global, and Support. On the left is a navigator pane containing a Search IAM field and menus such as Dashboard, Groups, Users, and Roles. Dashboard is active now. Next to the navigator pane, the dashboard interface displays. It is titled - Welcome to Identity and Access Management- followed by IAM users sign-in link and two more hyperlinks - Customize and Copy Link. Next, is a section titled IAM Resources that displays the following information: Users, Groups, Roles, Identity Providers, and Customer Managed Policies. All these are set to 0. Next, is a section titled Security Status and it contains a status bar showing 1 out of 5 complete. It also displays drop-down menus for options such as Delete your root access keys, Activate MFA on your root account, and Create individual IAM users. The Delete your root access keys drop-down menu has a green checkmark on its left and the remaining options have a warning icon. On the extreme right side of the web page, the Feature Spotlight section displays a video. Below this, a section titled Additional Information displays and it contains hyperlinks such as IAM best practices and IAM documentation. [Video description ends]
So some best practices to secure the root account, protect your root account access key, if you have one. Treat it like a credit card number, okay? If you do have an access key, consider deleting it and using some other method, like the IAM administrator or the GCP service account. Rotate keys or use the key management service from the service provider.
[Video description begins] Key Management Service is abbreviated to: KMS. [Video description ends]
Use strong and long passwords whenever you use passwords. And enable muti-factor authentication for your root and billing account and for any of your IAM users, especially the ones that have high level privileges.
[Video description begins] Multi-factor authentication is abbreviated to: MFA. [Video description ends]
And so MFA provides a six digit single code in addition to your standard credentials for accessing the AWS. For example, account settings or AWS services and resources. And MFA supports the use of both hardware tokens, and virtual MFA devices.
Now, I've already mentioned identity and access management, and both Amazon, and Google, and other Cloud providers offer this service. That's what we're going to look at in greater detail in the next lesson.
Identity and Access Management Groups and Users
Let's talk about identity and access management, and we're going to be focusing on groups and users. And this is really the same type of approach that you would take in your network operating system, for example, Windows Server 20, whatever. Maybe you're going to get into 2019 coming up. And you've got your Active Directory, you create your global groups, and you place your users in those global groups, and you apply policies to those groups. It could be some other directory service.
Now, realize what I'm probably going to do first is if I'm going to have a relatively large number of administrative users. I'll probably create a group first called administrators or admins. And then I'll apply a policy, which in AWS is just a set of JSON documents, managed policies, or permissions to that group. And then whenever I add a new administrator, I'll just create that user, as we see here, we'll add the user and then we'll just put the user into that group.
Now, let me just say this. What if you're planning on having quite a few, 12, 20, or more different types of users that need permissions to do services, and products, and different virtual private clouds up at your cloud provider?
In that case, it's probably better to just have your root account or your billing account, maybe create one highest privilege administrative user, and then use single sign-on, okay? So if you're using Microsoft Azure, a single sign-on from Active Directory is extremely easy to set up. But there's also services at Amazon, and Google, and others that allow you to do single sign-on from your Active Directory or some other LDAP type directory. You can use SAML 2.0, you can use Open ID, you can use several different topologies.
So the point I want to make here is that rather than creating a huge number of groups and users in IM, it may be better for you to do single sign-on from your own existing directory service. Now that being said, obviously, what we're going to do here is we are going to create that first administrative user.
[Video description begins] The IAM Management Console web page for an AWS account displays. In the navigator pane, Users menu is active and highlighted. On the right, there are two buttons titled Add user and Delete user. The Add user button is enabled and highlighted. In the right corner of the page, there are three icons: Refresh, Settings, and Help. Below the buttons, a Search field and a table display. The table has the following columns: User name, Groups, Access key age, Password age, Last activity, and MFA. The table is blank and a line of text displays there. It reads - There are no IAM users. A Learn more hyperlink also displays. [Video description ends]
So I'm going to call this user administrator. Now, notice at AWS, I have the choice to either give them programmatic access and/or management console access.
[Video description begins] Screen title: Identity and Access Management Groups and Users [Video description ends]
Let's say I do not give them programmatic access, just the console access. In that case, they're going to be sent a URL and they will get a password. And they will log in with that username and password on the URL that gets sent to them in their email. And they'll just have management console access. And then by the way, I can control what type of access and what services they can access using the managed policies or the permissions.
[Video description begins] When he clicks Users, a new webpage displays. It has 2 sections titled: Set user details and Select AWS access type. The Set user details section contains a User name field with the value Administrator. The field is highlighted. Below it, a hyperlink - Add another user- displays. The Select AWS access type section contains 2 fields: Access type and Console password. Both are highlighted. The Access type field has two check boxes - Programmatic access and AWS Management Console access. Both are checked. The Console password field has two radio buttons - Autogenerated password and Custom password. The Custom password radio button is selected and an encrypted password displays in the field. There is a check box titled Show password checkbox and it is unchecked. [Video description ends]
But if I give them programmatic access, that means they're a developer or a high level administrator. In that case, they're going to get an access key ID and a secret access key. And they'll use that for API calls, for the command line interface, using the console on their workstation, software development kits, and other tools.
Now, an access key ID, just think of that as a really long pseudo-random username, okay? So that's what the key ID is. Then of course, they're going to get a private key associated with that and they will configure that, for example, in their CLI or their SDK. \
Now, if you're going to do this with Google Cloud Platform, they highly recommend that you download the Google Cloud SDK and you create a service account. And you use the service account with the higher privileges or whatever privileges they need. And that service account will log in through the SDK and the command line, and use tools like gcloud, gsutil for Google Cloud Storage and bq for BigQuery. Either way, I'm going to give this administrator both types of access, and I'm going to go ahead and create a custom password.
And I could also allow them to change that password, okay? So you can see I can require them to reset the password at the next sign-in, right? So I can give them a password or auto generate a password then they have to create their own the next time they sign in. Notice, by the way, that this particular user will have a policy automatically attached to them. It's called IAMUserChangePassword. And you can view that in a graphical interface, you can view it in JSON format, you can view it in YAML format.
And basically, that's what we see when we go and click on Next at the bottom permissions. Permissions is where we're going to apply the managed policies. I don't want to get into the policies yet, okay? We're going to look at password policies and applying policies and permissions in the next lesson. For this lesson, though, here's the big takeaway, that you'll create groups and users in IM. But if it's a large enough set of users, you might want to consider single sign-on.
IAM Policies and Permissions
One of the first things you're going to want to do before you actually start creating IAM groups and users is to implement a password policy. Which is a set of rules that defines the type of passwords that the IAM user can set.
And this would be available to you in any cloud service provider. Now, realize that these password policies are not going to apply to the AWS root account. So we're looking at AWS here so keep that in mind.
[Video description begins] Screen title: Applying Password Policies [Video description ends]
If I say, minimum password length of 13. It will apply to any subsequent IAM user that I create, but it will not apply to the root account. But these are the attributes that we typically see in our network operating systems historically. Let's say working with Microsoft Windows and Active Directory. Where we have to have at least one uppercase letter, at least one lowercase letter, require at least one number. At least one non-alphanumeric character, okay? So a strong complex password of usually 10 to 13 characters. Are we going to allow users to change their own password? Then we have the password expiration, which is really the validity time.
So typically it's 30 to 45 to 60 days. The prevent password reuse, we call that password history. So for example, if I'm going to change my password every 30 days, now I'm going to have the number of passwords to remember would be 12. Then after a year, they can start reusing previous passwords.
And then we notice that we have the final password encryption requires administrator reset. Something else you can do with the cloud provider, if you notice on the left-hand side, is generate a credential report.
[Video description begins] The IAM Management Console web page displays. In the navigator pane, Account settings is active. On the right, a section titled Password Policy displays. It contains the definition of password policy and a Managing Passwords hyperlink. Next, there is a field titled Minimum password length that displays the value 6. A number of check boxes display such as Require at least one uppercase letter; Require at least one number; and Enable password expiration. The check box, Allow users to change their own password, is checked. At the page bottom, 2 buttons, Apply password policy and Delete password policy, display. [Video description ends]
So once you've implemented your password policies, you created your groups and users. And we're going to talk here about applying the managed policies, we can also generate a report, we can have that printed out, as well. Typically, to be scalable, you're going to apply the managed policies permission set to a group. So for example, here I've decided to create a group called admins, and so I'm going to apply the policy to that group.
[Video description begins] A dialog box titled Create group displays. At the top is a field titled Group name with the value Admins. The field is highlighted. There are two buttons - Create policy and Refresh- below the field. Below the buttons, is a drop-down field titled Filter and it is set to Policy type. Next to it is a Search field. A table with the following columns displays: Policy name, Type, Attachments, and Description. The first row in the table is highlighted. The value in the Policy name column is AdministratorAccess, Type is Job function, Attachments is 0, and Description is Provides full access to AWS services and resources. 311 policies display in the table. At the page bottom, are 2 buttons titled Cancel and Create group. The Create group button is highlighted. [Video description ends]
Now in Amazon Web Services, the managed policy that basically relates to kind of the, you would call it the highest privilege user. Would be the AdministratorAccess policy. And so if you were to look at that policy, let's say in JSON, it would basically say all services, all actions, you could do it all. However, remember, even if I apply this policy to the admins group, and I start putting users in that group. There're still certain things that only the root account can do. Now if I were to scroll down here, I would see alphabetically all these different services and products that AWS offers.
And each one of those has their different policy sets, from full access, to read-only access, to administrative access, to auditing, to monitoring. And so you can go on and you can apply multiple policies. And what you're actually doing to this group is you're applying the stacks of JSON documents. And they'll get the subsequent or cumulative access to those products and resources. Now here's Google Cloud Platform, and here's the same type of thing.
[Video description begins] Screen title: IAM Policies and Permissions. The Google Cloud Platform window displays and a dialog box titled - Add permissions - displays on the right side of the screen. In the Google Cloud Platform window, there is a navigator pane on the left with menu menu options. 2 menus - IAM & admin and Roles - are highlighted. On the right side, are many fields about the newly-created role such as: Create Role, Title with the value Custom Role, and ADD PERMISSIONS- and they are all highlighted. [Video description ends]
They call them permissions, they're in alphabetical order of the different services. So we're seeing here App Engine. You can see there's ten rows per page and there's a bunch of these permissions. And really if you break it down, whether it's Google or Amazon or someone else. These are just basically API calls that are being made to services.
And these are permission sets that dictate what can be done in the API call. Now in this particular example in this screenshot, I am adding permissions to a role. And we'll talk more about roles as we progress through this training.
[Video description begins] The host zooms in to the Add permissions dialog box and then zooms out of it. The box displays a drop-down field containing the text- Filter permissions by role. Below this is a table with 2 columns titled Permission and Status. Many permissions are listed in the table and all have the Status as Supported. CANCEL and ADD buttons appear at the bottom. [Video description ends]
Let's go up to Amazon Web Services and take a look at their AWS policy simulator. Which is a really good tool to kind of get a understanding about how these permission sets work. Okay, let's go up to the Services area.
[Video description begins] The AWS Management Console web page displays. He clicks the Services tab. [Video description ends]
And if I go down to Security, Identity, and Compliance, I'll see IAM.
[Video description begins] He scrolls down to the Security, Identity, & Compliance section and clicks the IAM hyperlink. [Video description ends]
And we saw a screenshot of this earlier.
[Video description begins] The Welcome to Identity and Access Management page displays again. The values in Users field is now 1, Roles is 3, and Security Status now says 2 out of 5 complete. The Create individual IAM users item is checked now. In the Additional Information section, the host clicks the Policy Simulator hyperlink. [Video description ends]
If I go over here to Policy Simulator on the right-hand side, what I'm going to see is a tool where I can go in. And I can choose either my users or my groups. And at this point, that's all we've really talked about. We haven't really talked about roles. We will talk about roles in a little bit. But, I don't have any groups, but let's say, if I did have the admins group or some other group, or some users, I could select them.
[Video description begins] The IAM Policy Simulator web page displays. There is a panel on the left titled Policies, and a Back button to go back to the console. The following line of text displayselected user : Administrator. A section titled IAM Policies displays below. It has a Filter field. There are 2 more sections there titled: AdministratorAccess and IAMUserChangePassword. The host hovers over them. The drop-down field has three options: Users, Groups, and Roles. The host points to the Users and Groups options. [Video description ends]
If I choose Administrator user, you can see they have that AdministratorAccess and if they have the IAMUserChangePassword. So this is two different JSON permission sets that have been applied to this user.
[Video description begins] On the right-hand side, a section titled Policy Simulator displays. It has many drop-down fields such as Select service, Select actions, Select All, Deselect All, Reset Contexts, Clear Results, and Run Simulation. It also has a section titled Global Settings which displays a sub-section titled Action Settings and Results. [Video description ends]
And then I could say, well, based on different services at AWS, for example, like Glacier, okay?
[Video description begins] The host clicks the Select service drop-down arrow and a list of services displays. He selects Amazon Glacier. [Video description ends]
What actions do I want to simulate? There's a lot of different actions here that can be done on Amazon Glacier, which is their long-term archival storage. Or I could say let's just choose all the actions, okay?
[Video description begins] Next, he clicks the Select actions drop-down arrow and a list of actions displays. He points to the different actions such as ListParts and UploadArchive. Then, he clicks the Select All button. The Select actions drop-down field shows the value, 33 Action(s) selected. The Action Settings and Results section displays all the actions selected for the specified service. Next, he clicks the Run Simulation button. [Video description ends]
33 actions, then you can come down here, then you just simply say, look, I want to run a simulation. And it's going to show you that the Administrator user is allowed to do all 33 of those actions.
[Video description begins] In the Action Settings and Results section, the Permission column displays the text-allowed - for all the actions. The host scrolls down the web page to display all the actions and their permissions. [Video description ends]
And so this is a tool that you can use, obviously, before you start creating your groups and your users. To get an understanding of what policies you might want to apply to those groups or users or roles. Or you can do it after the fact and you can find out subsequently what types of permissions are they allowed to do.
And you can modify these accordingly, okay? Remember, you can always apply the managed permissions that they have, for example, AdministratorAccess. And you can see, by the way, this is showing you the JSON, okay? So in this statement, the Effect is Allow, the Action is all or asterisk to all resources.
[Video description begins] In the navigator, he clicks AdministratorAccess. A code displays in a section titled AWS Managed Policy. He highlights lines in the code. [Video description ends]
So you could obviously take a policy, you could clone it or copy it, and then you could modify it yourself. And it can be modified either in JSON or you could actually modify it in a graphical user interface. So if I go back here to the Management Console and go to Policies.
[Video description begins] Then, the host clicks the back arrow in the browser window. [Video description ends]
You can see that if I choose a particular policy. Let me scroll down and find something that's kind of common, like here's Redshift, their cluster service. Okay, if I click on that, you can see here's the permissions that they have and other services.
[Video description begins] Next, he clicks Policies in the navigator. On the right, all the policies display in a table format that has the following columns: Policy name, Type, Used as, and Description. At the top, 2 buttons titled - Create policy button and Policy actions- display. From the policy list, he clicks the policy titled AmazonRedshiftFullAccess. A section titled Summary displays. It has four tabs titled Permissions, Policy usage, Policy versions, and Access Advisor. The Policy ARN and Description of the selected policy displays above. [Video description ends]
[Video description begins] He clicks Permissions. It has two buttons titled Policy summary and JSON. JSON is enabled now. A table with the following four columns displays: Service, Access level, Resource, and Request condition. 5 out of 172 services display in the table. [Video description ends]
Okay, CloudWatch, EC2, and IAM, okay? And then you can see it in JSON here, right?
[Video description begins] The Services such as CloudWatch, EC2, and IAM display with their respective access level, resource, and request condition. He clicks the JSON button and a code displays. [Video description ends]
So you can always attach the policy if you want to. So these are the way we apply permissions to groups, users, and roles at our cloud service provider.
IAM Roles
Okay, this lesson is going to be entirely a demonstration. And what I want to talk about is a concept known as roles. And they're actually quite different between Amazon Web Services and Google Cloud Platform.
[Video description begins] The IAM Management Console web page displays. In the navigator, Roles is active. On the right side, a section titled Roles displays. It contains the description of IAM roles, Additional resources, and 2 buttons titled- Create role and Delete role. [Video description ends]
And they may even be different in Microsoft Azure or IBM Cloud or Oracle Cloud. But I'm just going to focus on the two biggest players in the CSP market, AWS and GCP. Let's start with Amazon Web Services. In AWS A role is a way to grant permissions to an entity. So when you have a role it doesn't actually have credentials, doesn't have a username and password, it basically has permissions assigned to that role. Then you can use that role and you can apply it to let's say an IAM user in a different account.
So let's say for example a company has a development account where they do their programming and their development. And a production account where everything that's released to their customers or the consumers is part of that account. Well, if you have a user or a group of users in a development account, you might want to grant some permissions to do some things to resources. In the production account, you don't have to go into IAM of the production account and create a new group or a new set of users.
Now, if you're using single sign on, you can get around this all together. However, I may want to use a role to assign permissions, manage permissions, to users in a different account, okay? So that is kind of the first main reason that we do this. Also, you can have application code running on an EC2 instance, that's to perform actions. And this is a common thing, for example, if you have a bastion host or a jump host, okay? Here you can see that I've got a roll called bastion.
[Video description begins] The host clicks Roles. On the right side, a table with the following columns displays: Role name, Description, and Trusted entities. Three different roles display in the table. The host clicks the role, Bastion. The Summary section displays the role summary and the following five tabs: Permissions, Trust relationships, Tags, Access Advisor, and Revoke sessions. By default, the Permissions tab is open. It displays a table with the following 2 columns: Policy name and Policy type. One row of data displays in the table and it has AmazonEC2FullAccess in the Policy name column, and AWS managed policy in the Policy type column. The host clicks AmazonEC2FullAccess. [Video description ends]
So what does this roll do? Well, I assigned permissions to it, and you can see EC2FullAccess, right? And these are the permissions that have been assigned. Here's the JSON of it. Here's the policy summary of it and it's been applied to this particular role. So if I were to go up to Services and go to EC2, I could spin up an instance.
[Video description begins] The Summary section displays. Two more tabs appear, Policy summary and JSON. The host points to the JSON code and then clicks the Policy summary tab. A table with the following 4 columns display: Service, Access level, Resource, and Request condition. Many services are listed in the table. He scrolls down to show the list of services. [Video description ends]
[Video description begins] The host clicks the Services tab in the AWS management console and selects EC2 from the Compute category of services. The EC2 Dashboard displays sections titled Resources and Create Instance. The host clicks the Launch Instance button in the Create Instance section. [Video description ends]
Let's say Launch an instance and we'll say it's going to be just this t2.micro, okay?
[Video description begins] The Launch instance wizard starts. There are 7 steps in this, denoted by the 7 tabs on the top: Choose AMI, Choose Instance Type, Configure Instance, Add Storage, Add Tags, Configure Security Group, and Review. The first tab is active now. The text- Step 1: Choose an Amazon Machine Image (AMI) - displays on the top and displays a list of AMIs. The host points to the Amazon Linux 2 AMI (HVM), SSD Volume Type with the 64-bit configuration and clicks the Select button next to the option. The next step gets loaded. The text- Step 2: Choose an Instance Type - displays on the top, and the page contains a table of different instances with columns titled Family, Type, vCPUs, Memory, and Instance Storage. The second row that has t2 micro instance in the Type column is selected. The host clicks the button titled Next: Configure Instance Details, at the page bottom. [Video description ends]
We'll go to Configure Instance Details. It'll be one instance but if I come down here, notice I can assign a role to this instance called Bastion.
[Video description begins] The text- Step 3: Configure Instance Details- displays at the top, and various fields such as Number of instances, Purchasing option, Network, and Subnet display below. The host points to the Number of instances field, which is set to 1. Then, he scrolls down the page and clicks the IAM role drop-down arrow. The list displays two options, None and Bastion. The host selects Bastion. [Video description ends]
So now somebody can connect using secure shell to this Linux instance. And then they have the permission to go and access other resources in other public or private subnets. And so what they're allowed to do are the permissions based on the role, okay? So that's the way that roles work in Amazon Web Services. And again, Amazon Web Services allows us to apply permissions, okay, or policies, JSON policy sets.
[Video description begins] The host clicks the AWS icon on the top leftcorner just below the toolbar. The AWS Management Console web page displays. It contains sections such as AWS services, Find Services, and Recently visited services. The Recently visited services section contains hyperlinks for services such as EC2 and IAM. The host clicks IAM. The Welcome to Identity and Access Management section displays and the host clicks Policies in the navigator. [Video description ends]
We can apply these policies to groups, we can apply them to users, and as we just saw, we can apply them to roles.
[Video description begins] A list of policies displays in the table on the right in a table format with table such as Policy name, Type, Used as, and Description. The host points to the Groups, Users, and Roles options in the navigator. [Video description ends]
Now in Google Cloud Platform, roles are different, okay? In Google Cloud Platform a role is actually what they call the policy, okay? So let's say an identity calls up an api on Google Cloud platform. IAM requires that the identity has the right permissions to use that resource, to make that api call. Well, in Google Cloud Platform, you grant permissions by granting roles to a user or to a group or to a service account, a special type of account for management purposes.
And there's three types of roles in cloud IAM in Google Cloud Platform. Primitive roles, those are things like owner, editor, and viewer that basically are legacy that have been around before IAM, then predefined roles, okay? So predefined roles are what we would call Managed Policies in Amazon Web Services. So the Managed Policies of AWS is the same thing as the predefined role of Google Cloud Platform, okay?
And then they have custom roles and both of these have custom roles. In Google, they're called custom roles. In Amazon Web Services, they're called customer managed policies, okay? So hopefully that gives you an idea of how we can use roles, and the differences between Amazon and Google Cloud Platform.
Secure Management Access
In this lesson, we're going to talk about Secure Management Access. One of the main ways to access instances is to use a form of PKI with an access key ID plus a secure access key. This is public key cryptography. For example, EC2 uses public key cryptography to encrypt and decrypt the login information. So the public key is used to encrypt the piece of data, such as the password. Then the recipient uses the private key to decrypt the data. These public and private keys are known as a key pair.
So, let's say you're in AWS, and you want to login to your instance. You have to create a key pair, you have to specify the name of the key pair when you launch the instance. And provide the private key when you connect to the instance.
Now, we know there's two really different types of instances, there's Linux and there's Windows. Now, Linux instances don't have a password. So you use a key pair to login using SecureShell. With Windows instances, you use a key pair to get an administrator password. Then you login using remote desktop protocol, RDP. The traffic is encrypted. Data integrity is authenticated, and the client browser will authenticate the identity of the console service end point using an X509V3 certificate. After the TLS session's established between the client browser and the console service inpoint. All subsequent traffic, specifically HDP traffic, is protected in the TLS session. Also, all API calls are digitally signed for integrity and non-repudiation.
Now, if you use the AWS SDK, or you use the Google Cloud SDK to generate request. The digital signature calculation will be done for you. Otherwise, you have to have your application calculate it. And include it in your REST, R-E-S-T, or query request by following the documentation instructions.
Now, not only does the signing process help protect message integrity by stopping any tampering with the request while it's in transit. But it also helps protect against potential replay attacks. In AWS, the request must reach within 15 minutes of the timestamp of the request. Otherwise, it'll be denied.
Management users should be controlled using strict least privilege principles of IAM policies and roles. If you have a large number of management users, you might want to consider Single-Sign-On. CLI and SDK access is protected with access keys. And, all web-based logins are protected with TLS 1.1 or higher. Even though it might mention protection using SSL TLS, it's actually using transport layer security. Now for AWS, you're going to go to this link, aws.amazon.com/cli. And you'll download the AWS command line interface which is their unified tool, okay?
[Video description begins] The AWS Command Line Interface page displays. The following link also displays: https://aws.amazon.com/cli/. It contains a description of the AWS Command Line Interface abbreviated as CLI. It contains hyperlinks for Getting Started, CLI Reference, GitHub Project, and Community Forum. The Windows, Mac, and Linux download details are highlighted. [Video description ends]
One tool to download and configure. And then you can do a wide variety of activities in a secure way. As you can see there's a downloader for Windows, for a Mac and Linux. Mac and Linux will require Python 2.65 or higher, and you install using pip. pip install awscli. So let's say I do this on my Windows 10 machine. If I'm going to access with the root account, I'm going to use the root account access key ID, and the root account secret access key.
[Video description begins] The AWS command prompt window displays. The command prompt reads as: C:\Windows\System32. Here, he types the following line of code:aws configure. 4 lines of output display. The first line of output reads as: AWS Access Key ID [ None ] :. The second line of output reads as: AWS Secret Access Key [ None ] :. The third line of output reads as: Default region name [ None ] :. The fourth line of output reads as: Default output format [ None ]:. [Video description ends]
More likely than not, this is going to be an administrative IAM user. So as I showed you earlier, you create that administrator user. And of course, you're going to send to the email address of that administrator, maybe it's yourself. Since you gave that account programmatic access, you're going to have a access key ID. Which as I mentioned is like a username, but it's a long string of characters. You'll choose a default region, and then a default output format. And it could be in a table format, it could be text format, it could be in JSON format. For Google Cloud, you want to download the Google Cloud SDK.
[Video description begins] Screen title: Google Cloud SDK [Video description ends]
And this is going to give you the gcloud command line tool. Managing authentication, local configuration, developer workflow, interacting with platform APIs. The gsutil tool, which is to manage your cloud storage buckets, your object storage. You have PowerShell cmdlets for Windows. You have the bq, BigQuery tool to run queries, manipulate databases, tables and entities. And the kubectl tool which orchestrates the deployment and management of Kubernetes container clusters on the gcloud CLI.
[Video description begins] The Google Cloud tools display with their descriptions. The Windows PowerShell cmdlets is a tool for managing Google Cloud Platform resources within the Windows PowerShell environment. The bq tool allows you to run queries, manipulate datasets, tables, and entities in BigQuery through the command line. [Video description ends]
Here you can see, for example of the gcloud command, where you manage Google Cloud Platform resources and developer workflow.
[Video description begins] The Google cloud command prompt window displays. At the command prompt, he types the following line of code: gcloud -- help. The output displays information organized in the following sections: NAME, SYNOPSIS, DESCRIPTION, and GLOBAL FLAGS. The link for downloading the google cloud SDK displays. It is: https://cloud.google.com/sdk/docs/initializing. [Video description ends]
Now, a best practice that you're going to use Google Cloud SDK is look at the link at the bottom here on the slide. If you follow that link, it's going to show you how to install the Cloud SDK under the context of a service account. So you're going to have a service account, you're going to assign it a role, which is Google's managed permission.
So once you assign that role to that service account, you will then install the SDK and run it under the service account context. You may also want to consider using a Bastion or a jump host. I showed you that earlier when you looked at AWS roles, remember we had a Bastion role and we assigned it to an instance that we spun up.
[Video description begins] A diagram of the AWS environment displays. Within the AWS environment, there is the VPC environment, which consists of three subnets: DMZ public subnet; Front-end private subnet, denoted by a lock icon; and Back-end private subnet, also denoted by a lock icon. In the DMZ public subnet, an Administrator connects to SSH bastion in the Amazon EC2 security group with TCP: 22 and users connect to Elastic Load Balancing (ELB) Security group with TCP: 443. The SSH bastion and the ELB Security group connect to the Web app server in the Amazon EC2 security group in the Front-end private subnet with TCP: 22 and TCP: 8080, respectively. The Web app server connects to MySQL in the MySQLdatabase security group in the Back-end private subnet with TCP: 3306. The Web app server and MySQL connect to the NAT security group with TCP: Outbound. The NAT security group connects to the Internet. [Video description ends]
So in the DMZ public subnet, you're going to most likely have a Secure Shell Bastion host. You may also have a Windows RDP Bastion host. The public users will hit the elastic load balancer. And you'll have a NAT gateway, and that's for the internal servers like you're MySQL servers and your web servers. To go out to the Internet and get their updates and their upgrades, and their service packs in a secure way without exposing them to the public. So using a bastion host is highly recommended for management of Secure Shell.
And using RDP to manage devices in the public subnet or the private subnets. And using a gateway, a NAT gateway for your internal servers to go out and get their updates in a secure fashion, is also highly recommended.
In AWS, if you want to use a bastion solution, you could use AppStream 2.0. This lets administrators manage their environment without giving them a full jump host. So you don't have to spin up a dedicated and self-hardened jump host. You can basically spin up a fresh instance each time a user requests access.
So it's basically going to dynamically automatically spin up an AppStream instance for you that only last for the session duration. As soon as the user closes their session and the disconnect time-out period is reached, AppStream will automatically terminate the instance. Keep in mind, to use AppStream 2.0 in AWS, you need to be using Single-Sign-On.
Network Access Control Lists
Next I want to talk about a possible control you might have at a cloud provider known as a network access control list. So, this is an ACL. And it applies to a network, so you may have this at some of your providers, this is not something that you would have at Google cloud platform. But Amazon web services for example offers this as a another defense and depth mechanism. So, what a NACL does it applies to a subnet, either a public subnet or a private subnet. So if you have one, four, ten, or more, whatever, how many instances spun up in that subnet either public or private. This network access control list, is going to apply to all of the instances in that subnetwork.
And notice that you have an inbound rule. And you have an outbound rule. So a NACL is what we call a stateless or a static traffic filtering tool. To help you manage IP version 4 and IP version 6 traffic entering and exiting a subnetwork and it applies to all inbound traffic or outbound traffic. But there's two separate rules, okay? An inbound and outbound rule. So, what you're doing is you are setting up an ordered list of entries, aces with numbers. So for example, you would have number 100 and then most likely you would skip and go from 100 to 105 or 110.
[Video description begins] The Subnets | VPC Management Console web page displays. The VPC Dashboard is open. In the left pane, several options such as Your VPCs, Subnets, and Route Tables display. The Subnets option is active. On the right, the Create Subnet button and Subnet Actions drop-down button display at the top. Below these buttons, a table displays with the list of private and public subnets with details such as Name, Subnet ID, State, and VPC. The Public subnet and its details are highlighted. At the bottom, another table displays a Network ACL acl-c37eddabwith details such as Role, Type, Protocol, and Source. The Network ACL table is also highlighted. [Video description ends]
The problem with numbering your rules incrementally by one is that if you want to add a rule later on, you have to renumber all of them. So typically, when you create your access control entries, you're going to have them be 100, 105, or 100 then 110. So it's easy to insert a rule in there.
And so you can see here that as we add this inbound traffic rule what we're going to say is we're going to give it a rule number. And then we're going to go, we're going to choose a particular service. And you can see different service ports here. For example, a lot of standard ports.
Now, HTTPS is 443. We see, RDP 3389. That's an important one to remember because typically you're going to open up RDP traffic for management purposes. But there's some others like Oracle 1521, PostgreSQL is 5432. And then some proprietary ones, like here's Amazon Web Service's Data Warehousing Cluster Service Redshift on port 5439. And so you can permit or deny based on a range of ports or a protocol or service and then you can have the source IP version 4 or IP version 6 address.
And again, the options you have are to allow or to deny. So keep in mind, NACLs are agnostic of the TCP and UDP session so it basically just looks at the packets one at a time. Or atomically, it makes a decision. So this is not a stateful packet filtering firewall, like the security group of AWS or the firewall of Google Cloud Platform.
Stateful Firewalls in the Cloud
The most common type of firewall that you would find in a cloud provider is a stateful firewall that operates at layer three and four. Here we see a security group at Amazon Web Services and the Security group is applied directly to the instance. In fact, it operates at the hypervisor level and its applied when you instantiate or spin up the machine image.
[Video description begins] The Security Groups VPC Management Console web page displays. In the left pane, in the Security section, the Security Groups option is active and highlighted. On the right, the Create Security Group button and Security Group Actions drop-down button display. Below these buttons, the Filter option is set to All security groups. A table displays with the following details: Name tag, Group ID, Group Name, VPC, and Description. The second row in the table, with the Group ID: sg-ea4cab81, is selected and highlighted . At the bottom, four tabs display: Summary, Inbound Rules, Outbound Rules, and Tags. The Inbound Rules tab is open. For the selected security group, it displays a list of protocols with the following details: Type, Protocol, Port Range, Source, and Description. [Video description ends]
Technically it's applied to the elastic or logical network interface of the Windows or Linux or Mac OS instance. It has inbound rules and it has outbound rules, but it's an allow only firewall at AWS. It's a safe list as opposed to the access control list. It doesn't have numbered entries, it basically just says a list of the safe protocols and services. Ports and source IP address. Also there's no allow or permit or deny rules. Everything on the list is allowed. There are no explicit deny rules, and if it's not on the list, it's not allowed.
Here we can see an inbound rule going to a web server where we're allowing HTTP on port 80 and HTTPS or TLS on port 443 for both IP version 4 and IP version 6. We're also allowing secure shell on Port 22 and RDP remote desktop protocol on Port 3389. All cloud providers offer a stateful firewall and it's stateful because if this instance is the source of a connection to the Internet, the traffic coming back is allowed back in automatically subject to inspection.
But you don't need to have a specific inbound rule here we see outbound rules from the web servers going to another subnet where the back end database servers are. [Video description begins] The Outbound Rules tab opens. It displays a list of protocols with the following details: Type, Protocol, Port Range, Destination, and Description. [Video description ends] So the outbound rules have the same destination, a database server and allowing only Microsoft SQL on TCP Port 1433 and the Aurora service on TCP Port 3306 for MySQL.
Here's a nice table that describes the differences between the network ACL that we talked about in the previous lesson and the stateful security group firewall. Not all cloud providers will have both types of layer 3,4 firewalls. However, they all have a stateful firewall like the AWS security group. Notice in the last row that the network ACL applies automatically to all of the instances in the subnet and the security group firewall functioning at the instance level applies to the instance only.
Web Application Firewalls
Okay, in this lesson, I'm going to demonstrate an overview of the web application firewall or the layer 5 through 7 firewall that can be used for HTTP and HTTPS. And this is going to be something that's also referred to as deep packet inspection. It's called an application layer gateway.
You may hear it called advanced inspection and control or advanced visibility and control, a layer 5, 7 firewall. It has all different types of names. But I'm here at AWS, I'm going to go down to the Security, Identity, & Compliance area. I'm looking for WAF & Shield.
[Video description begins] The AWS Management Console web page displays. In the left pane, it displays options such as History, Console Home, IAM, and EC2. On the right, various sections such as Compute, Robotics, Analytics, and Business Applications display. The host scrolls down the page and points to the Security, Identity, & Compliance section. He then points to the WAF & Shield hyperlink. [Video description ends]
Now when I go here, I want to talk about this right off the bat. AWS Shield is a service that you get automatically when you have a VPC, a virtual private cloud. So it gives you basic anti-denial of service and anti-distributed denial of service protection. Okay, if you want to pay about $3,000 or more a year, you can get AWS Shield advanced.
And that gives you advanced protection, 24/7 support from their response team and enhanced visibility into DDoS events and botnets and things like that. They also have a firewall manager. So if you have a lot of devices, a lot of instances across a lot of accounts and resources, you can organize them into one administrative console, okay? What we're looking at here is WAF. The Web Application Firewall, which ultimately is going to generate what are known as Web ACLs, or web access control lists. So let's just go there.
[Video description begins] The AWS WAF & Shield web page displays. It has three areas: AWS WAF, AWS Shield, and AWS Firewall Manager. The host clicks the Go to AWS WAF button. [Video description ends]
And it tells you what's going to happen here, okay? You're going to be creating web access control list. So basically, you are protecting HTTP and HTTPS traffic at higher layers of the OSI model, okay, the application layer.
So it actually allows you to match on information in the HTTP request header response headers, okay? So this is beyond just saying, I'm going to allow or deny HTTP on port 80 or whatever, okay? This is up there with the behavior of the actual web service.
[Video description begins] The AWS WAF page opens. In the left pane, it displays options in different sections such as AWS WAF, Conditions, and AWS Shield. On the right, it displays the explanation for AWS WAF and the Configure web ACL button. At the bottom, it displays three areas: Web traffic filtering with custom rules, Block malicious requests, and Tune your rules and monitor traffic. The host clicks the Configure web ACL button. [Video description ends]
So to configure this, the first thing you have to do is understand conditions. And so you're going to create condition sets. Organize these into either IP addresses, for example, that are suspicious and other IP addresses that maybe you want to allow. It just depends upon your approach. You may want to deny everything, but only allow a few things or allow everything and only deny a few things, so a restrictive firewall or a permissive firewall.
You can also match on string conditions like things that are in the response header and request header. You can also look for certain aspects of SQL injection attacks or cross site scripting or you can look for cross site request forgery. Okay, so basically you create these condition sets. And then your rules are going to contain conditions. So I've got a rule that is going to be called Bad User-Agents. And it's going to be matching suspicious IP addresses and what are called bots. And I've got a rule called Detect SQLi, okay?
And then once you create your rules, those rules go in to the Web ACL. And again, you're going to process this top down, just like you would a network ACL, or a NACL. You look at Rule 1, is there a match? Okay, no, then go to Rule 2. Is there a match there, yes or no? If there's not, you're going to determine a default action.
Okay, so you can say, if nothing matches Rule 1, or Rule 2, then by default, I'm going to allow requests or by default, I'm going to block everything. When you understand a WAF, you have to understand that it's made of conditions. Conditions go into the rules, and Web ACLs contain rules, and there's a default action at the end.
[Video description begins] The Set up a web access control list (web ACL) page displays. In the left pane, the Concepts overview option is active. On the right, the Concepts overview explanation displays followed by three areas: Conditions, Rules contain conditions, and Web ACLs contain rules. The Conditions area displays some examples, such as IP match condition example and String match condition example. The Rules contain conditions area displays some examples, such as Rules example and Detect SQLI. The Web ACLs contain rules area displays the Web ACL example. The host scrolls down the page to point to all examples. [Video description ends]
So notice here you're going to name it, give it a unique name. In Amazon Web Services, you can apply the Web ACL to their CloudFront distribution, which is their content delivery network. Okay, that's kind of like what Netflix and Hulu uses to get their content close to the customers, let's say in Dallas-Fort Worth, Texas, okay? So I could apply that to a CloudFront distribution, or I could apply it to an application load balancer in one of these regions, okay? So those are my two options.
[Video description begins] The Name Web ACL page displays. In the left pane, the Step 1: Name web ACL option is active. The host points to the Web ACL name field and the Region option, which is set to Global (CloudFront). He clicks the Region drop-down arrow. A list of regions displays such as US East (N. Virginia) and US West (N. California). [Video description ends]
And then what you'll simply do is you'll walk through the process. I'll just call this Test and go to Next.
[Video description begins] The host types Test in the Web ACL name field. The CloudWatch metric name field also displays Test. Then, he clicks Next. [Video description ends]
And you'll go through the process of first creating your conditions. And let me just show you here as I wrap up what you can match on, okay? So what are the things the web application firewall can match and then take actions on? Permit, deny or count, those are the three actions, or you can match on cross-site scripting conditions, okay?
And by the way, you can create these conditions by going to OWASP.org, O-W-A-S-P, and get their cheat sheets. Or if you want to pay extra money, for example, to do AWS Shield advanced, you can get predefined templates. You can even pay for their Guard-Duty feature to get even more managed security. But the matter of the fact is if you have somebody who's good at scripting languages like Pearl, or Ruby or, Python, they can create their own cross-site match conditions. Or they can match geographically, right? So you can match on geographic regions.
And you could say I only want to allow certain regions and deny the others, or I want to allow all the regions and only deny a few. Same thing with IP match, you can do IP version 4 or IP version 6 conditions. And you would create different separate condition sets for IP addresses you want to allow and IP addresses or prefixes you want to deny. You can also do size constraints.
So these are the headers in the HTTP request and response headers. You can control the size. So that is a countermeasure against certain buffer overflow attacks. And then SQL injection attacks, okay? If you're using SQL as your backend to your web services as opposed to NoSQL, you could have conditions for SQL injection. And you can create these yourself or you can go to OWASP.org and get their cheat sheets.
Or you could get predefined templates from Shield Advanced and GuardDuty. And then you can create your own strings and regular expressions to match on. And this is typically what next generation upper layer firewalls do, is they create complex condition sets of regular expressions to match certain behaviors in request headers and response headers. And often, you'll have to come in here and do these for zero-day attacks, okay?
So once you finish that, you create your conditions, then you'll go create your rules, right? And then your rules will make up your Web ACL. And of course, the Web ACL will have a default action. And then the web ACL can be applied in Amazon Web Services to a CloudFront CDN distribution, or it can be applied to a application elastic load balancer.
Best Practices for Hardening VMs
Let's look at some best practices for securing and hardening those virtual machine instances that you spin up in your virtual private Clouds, whether it'd be a Microsoft or Google or Amazon Web Services.
[Video description begins] Virtual Machines is abbreviated to: VMs. [Video description ends]
First, you want to make sure that you have the least access principle, okay? And least access also ties into least privilege. So those servers, those Linux servers, those Windows servers, need to have restricted access from both the network and within the VPC itself, using for example, single sign on or identity and access management. Consider installing only the necessary operating system components and applications necessary and leverage in a host-based protection that Microsoft or Linux provides.
Now this is a more managed situation where you're dealing with managed databases, you're dealing with managed directory services. Well in that shared responsibility, some of that will be taken over by the Cloud provider. You want to tightly control and monitor any interactive access to those EC2 instances. Also be aware of any of your emergency only kind of break glass scenarios on those instances. And of course with least privilege that single sign-on user, that IAM user, should only be given the policy or the role to do exactly what they need and no more. And if they need more, you'll rely on other tools and other life cycle processes like configuration management and change management.
Now remember, the key difference between configuration management and change management is typically configuration management comes first. In other words, you have to create a baseline configuration before you can really have any changes made. So configuration management comes first. This is going to be relying upon operating system baselines, application baselines, security baselines, and using any manage tools.
For example, you can use Amazon Inspector to go and test out your configurations against best practices from organizations like NIST and ISO/IEC. Configuration management will also tie into your compliance or your governance. For example, HIPAA, Sarbanes-Oxley, PCI DSS, GDPR.
And then of course change management, the goal is maintaining the secure life cycle and getting continual improvement, also tied into that is patch management. So service packs updates, software upgrades, file updates, all of those things, will tie into change management. It will also include your upgrade deployments like a blue green deployment where it's kind of an in place upgrade where you have parallel systems.
And then of course auditing, auditing access and all changes to your EC2 instances, maintaining integrity, using third party tools and manage tools like AWS Cloud trail. Stackdriver, for example. Consider dedicating instances to specific roles. So as you know, a Windows server whether it's 2012, 2016, 2019, can actually have a bunch of applications and roles. It could be an email exchange server, it could be a directory controller, it could be a SharePoint server, on and on.
So what they recommend at Amazon and Google is to have multiple instances and dedicate those VMs or instances to specific roles. So dedicated email servers, dedicated collaboration services and the like. Don't forget to configure your security groups in your firewalls. Depending upon the Cloud provider, there'll be different rules there. Optional ACLs when available, configure minimal network routes. Use the route table to determine if your subnets are public or private subnets, make sure you're aware of all connectivity methods. Both secured and unsecured to your VPC, your Virtual Private Clouds.
And when possible, take advantage and leverage the automated visibility tools, and even machine learning tools that are available from the Cloud provider.