Hello and welcome to this lecture, where I shall be discussing some of the security points. This lecture won't detail how to implement security controls, but simply offer considerations when thinking about your security strategy.

One of the biggest and most critical errors within your cloud migration strategy plan would be surrounding security. No matter the size of the migration or deployment, small or large, security must play a part of your design considerations. Remember, using a public cloud, you are handing over your data and additional responsibility to a third party. And as this information is typically accessed over the Internet, it opens it up to a potentially whole new world of malicious attackers.

Security's a huge topic and one that we could talk about for hours, however, there are a few key points to consider.

What layers should security be applied to? For example, the network layer, user, application, service, et cetera.Adding security to multiple layers of your architecture makes it harder for an intruder to penetrate deeper into your environment. Consider what security configurations you could add to each layer to prevent unauthorized access to your data.

Who needs access to the service and application and data you're storing? Identify who or what needs access to which resource. This could be a single user, a group of users, or a resource, or a group of resources. Identifying who or what requires access allows you to add fine-grain control to those services. You can then explicitly deny everyone and anything else should your security controls allow you to do so.

How will access be granted? What will your access methods be to gain access to resources? Will you use username and passwords, or perhaps federated access for a active directory, leveraging your existing user accounts on premise? Look at where you should add additional of access security, such as adding multi-factual authentication for power users or admins. It's recommended for these users as if their accounts are breached, they could cause havoc within your environment. Also, from an API perspective, will you be using access keys for resources to call upon other resources. It's important to consider how you'll be accessing your objects within your environment, so you must maintain policies around this control.

How much access do you need and to what level? You must define the required level of permissions for the user or resource to perform the functions required. Only allow the access needed and refine this access as much as possible, as it reduces the potential of unauthorized breaches and what can be done once breached.

What other services require access to the service, application, or data and over which ports? Again, when resources are talking to other resources, specify only the ports needed. Do not open up access to all TCP ports, for example, when only Port 22 is required.

Does the data need to be encrypted at rest and in transit? Depending on the sensitivity of your data, you may wish to encrypt your data when it rests and when in transit. This may be required from security compliance reasons, and so you must identify what data is affected by this and ensure that the correct level of encryption is applied.

How will encryption be managed? Will you manage the encryption methods for all your data, including management of encryption keys, or will you look to your cloud vendor to manage this aspect for you via one of their service offerings?

What logging can be enabled? Activating logging for your services allows you to monitor, analyze, and inspect authorized and unauthorized activity, allowing you to increase your security as and where required. This also allows you to identify consistent attackers and block specific requests within your security controls.

Security is typically a shared responsibility between you and the vendor. The vendor will manage security of the cloud and its global architecture. And you must architect and be responsible for security within the cloud. The vendor will not perform the security for you, but they will offer services and tools to allow you to implement and architect it.

Bear in mind any data laws that you might have to abide by, ensuring that the infrastructure you are using adheres to any governance controls relating to these requirements. Certain data may need to remain within a certain location or it might have to ensure it has a specified retention period applied. This can affect how you architect your environment and could impact where you physically store data within the cloud.

I recommend you refer to your internal information security management system document. This document is a set of controls and policies that dictates the security requirements within your organization. It will also identify what risks you have to consider, along with your data protection controls needed. Often, it will also identify what encryption methods should be used and to what extent. Any policies will also be included, such as password requirements.

This has taken us to the end of this lecture and so coming up next we'll discuss the points surrounding your vendor choice.