The cloud introduces new security requirements for our enterprise networks. In this video, you’ll learn about HA across zones, resource policies, secrets management, and security auditing.
One of the key aspects of IT security is maintaining the uptime and availability of our applications. For cloud-based applications, we can organize areas where there would be availability into Availability Zones or AZ. These are commonly referred to as a region within the cloud services. So your cloud service provider might have an availability zone for North America, a different one for South America, one for Europe, and another for Asia-Pacific.
Each of these availability zones is effectively self-contained. Each one would have independent power, a separate HVAC system, separate networking configurations. And anything that happens in one availability zone has no effect on anything else that’s happening in another availability zone. We can take advantage of this availability when we’re building our applications. We might build the applications to already recognize what zone they may be working in and give them the ability to operate outside of the existing availability zone.
So we might configure an application to run as an active/standby or active/active. So it might be active in one AZ. And if anything happens to the connectivity or resources in that AZ, the application can automatically switch itself to run from a completely separate availability zone. We could also use a load balancer not only to distribute the load for the application but to provide additional high availability. If we lose one of the servers that’s being served as part of that load balancer, the load balancer will automatically recognize that server is not available and transfer the load to the remaining servers on that system.
One of the challenges in these cloud-based environments is making sure that the user and administrative access to these systems is properly managed. And you can do this by using Identity and Access Management or IAM. This determines who gets access to a particular cloud resource. And then within that resource, it determines what they get access to. This allows you to create different groups. And you can map different job functions to those individual groups.
There might be a group for administrators that provides full access to the cloud-based application and a different group for the users of that application. And since this is in the cloud, you can create some very granular controls based on a number of different criteria. For example, if someone’s connecting from a trusted IP address, they might have additional access to that particular application.
Or if it’s a particular time of the day, you may enable or disable different capabilities within that application. And of course, since this application can be used in many different cloud environments spanning many different availability zones, you can synchronize all of these user roles so that everyone is always up to date with the access that they need.
When you start configuring a lot of cloud-based systems and applications, you’re going to find yourself filling in a lot of areas where it’s asking for a secret key. This could be part of an API or Application Programming Interface. This might be associated with a shared passphrase between two devices. Or it may be associated with the certificates that you’re using for encryption. There are many different places where these secret keys and secret phrases are added into the configuration.
So it’s important that you’re able to manage this process and have some centralized form of secrets management. It’s not uncommon to have a separate service that manages all of these secrets for everyone in your organization. It’s common not only to allow or disallow access to the secret service so that someone can gain access to the secret information, but it’s also important to limit what type of secrets are available.
You may want to allow access for a user to secrets specific to the application that they’re managing but restrict access to secrets that are not associated with that app. And of course, you’ll need some type of audit trail and logging. So you’ll know exactly who accessed the secret service. You’ll know what secrets they accessed. And you’ll understand more about who has access to different secrets in your environment.
This auditing process isn’t specific to the secrets that you’re keeping because we have security that we’re maintaining across multiple operating systems and multiple applications. We need some way to consolidate and report on logs from all of these different devices. This might include firewalls, VPNs, routers, switches, servers, and anything else on our network that creates logs. We can centralize all of this to a Security Information and Event Management system or a SIEM.
This allows us to not only maintain a consolidated log storage, but we can also create reports from this information. We can keep constant checks on the security of our systems. We can audit them occasionally, make sure that nobody’s gaining access to something they shouldn’t have access to. And of course, we can create reports that shows that we’re in compliance with a series of laws or regulations.