By Joe Merces
So you’ve moved your infrastructure to the Amazon Web Services cloud. What a relief, right? No more worries about the security of your critical applications and data. And disaster recovery should be a (relative) breeze.
Unfortunately, that’s not the case.
The world was different only 10 years ago. Back then, disaster recovery usually meant recovering from natural disasters, not man-made ones. In today’s world, however, cybercrime and cyber threats are the pressing problems. Ransomware can cause a cyber-disaster at any time. And migrating your infrastructure to AWS doesn’t necessarily mean you’re more secure. In fact, you’re still equally responsible for securing your AWS environment as you would be in your own datacenter – according to AWS itself.
In the Compliance portion of its web site, AWS specifically calls out a “Shared Responsibility Model” for security (https://aws.amazon.com/compliance/shared-responsibility-model/). Under these shared responsibilities, AWS is only responsible for security “of” the cloud; you, the customer, are responsible for security “in” the cloud.
What does that mean, exactly? Among other things, you’re still responsible for updating and patching operating systems – and the same goes for all of your application software, too. But that’s not all. You’re also responsible for the configuration of network and firewall on all of your AWS instances. You’re on the hook for encryption, authentication and security awareness and training for your staff too, no different than you are now.
The three pillars of backup, security and infrastructure management, which are still the responsibility of AWS customers, have come together under the holistic title of “data protection.” Not to be confused with the current EU General Data Protection Regulation (GDPR), data protection in this case is about rebounding from network intrusion, getting back up and running as quickly as possible, making sure critical information is OK, and doing what you can to make sure the same problem doesn’t happen again.
Enterprise IT departments historically silo backup, security and infrastructure management as three separate functions of responsibility, but today’s cloud world has been transformative and requires these three functions be unified in a holistic way ensuring true data protection. Keeping the blinders on and simply performing backup is not “data protection.” And if that was indeed enough, you wouldn’t hear news of organizations around the world being crippled by cyber disasters.
Of course, there are many applications available for backup and recovery, as well as the other aspects of this shared responsibility. As businesses continually push into a hybrid world of cloud and on-premises IT infrastructure, however, it’s becoming clear that legacy applications don’t really hack it anymore.
Especially in this shared responsibility model, it’s important to have a complete view of your infrastructure for effective data protection. That means not only backup and recovery, but also advanced security features and infrastructure management tracking to make it easier to work with AWS.
To make ensuring security easier, you should consider adopting a holistic data protection strategy that looks across your complete hybrid network – particularly if that strategy lets you work natively with AWS and follows AWS best practices. And along the way, you may be able to drop your legacy applications and save money besides.
Of the cloud, in the cloud
In terms of sheer word count on the Amazon compliance page, the security responsibilities for customers outweigh AWS’ responsibilities by a hefty margin. Make no mistake, they’re both big jobs; the customer’s job, however, just has many more moving parts.
To be specific, AWS outlines its responsibility as “protecting the infrastructure that runs all of the services offered in the AWS cloud.” That covers “the hardware, software, networking, and facilities that run AWS Cloud services.”
For customers, responsibility depends on the cloud services each customer uses. The different services offered by AWS have their own required configurations for security, and those configurations are up to the customer to make happen.
To put a finer point on it, Amazon’s category of Infrastructure as a Service includes Amazon Elastic Compute Cloud (Amazon EC2), Amazon Virtual Private Cloud (Amazon VPC), and Amazon S3. The tasks related to security and management are the customer’s responsibility.
Using Amazon’s example, if you are on EC2, you’re responsible for “management of the guest operating system (including updates and security patches), any application software or utilities installed by the customer on the instances, and the configuration of the AWS-provided firewall (called a security group) on each instance.”
IT controls are also part of the equation. AWS says it can relieve customer burden of the need to maintain controls related to the physical infrastructure. Customers can have AWS start managing IT controls, which creates a new “distributed control environment.” After that, customers are expected to use the available AWS control and compliance documentation to handle their own control evaluation and verification.
The shared model, AWS notes, “can help relieve customer’s operational burden as AWS operates, manages and controls the components from the host operating system and virtualization layer down to the physical security of the facilities in which the service operates.” If you consider everything that goes into procuring, racking, stacking, installing, configuring and protecting all of that infrastructure, that’s a really heavy lift from several perspectives that can truly benefit AWS customers.
However, and as mentioned earlier, that does not mean AWS will “assume responsibility and management of the guest operating system (including updates and security patches), other associated application software as well as the configuration of the AWS provided security group firewall.”
The cloud hasn’t reached a state of utopia where everything is perfect and there’s a solution in place to alleviate your every need and desire. There’s still a lot of effort here for customers to secure whatever they’re putting “in” AWS and ensuring they’re taking the same steps to secure what they’re putting “in” AWS, no differently than if it were placed within their own datacenters. For AWS, the answer is to be smart about how you use your network and the things you put into your infrastructure.
“Customers should carefully consider the services they choose,” AWS writes, “as their responsibilities vary depending on the services used, the integration of those services into their IT environment, and applicable laws and regulations.”
What you need to know about data protection and shared responsibility
So how does the AWS shared responsibility model tie back to your organization’s need for data protection – backup, security and infrastructure management?
A sustainable data protection regimen that also ensures compliance with AWS’ shared responsibility requirement has numerous elements. You must have a solution to manage your infrastructure within the cloud environment to schedule and perform backups, implement retention policies, and replicate cross-region and cross-account for additional layers of disaster recovery protection. Restores need to be performed from the granularity of a single file up to an entire instance.
Other important elements include the capability of incorporating the AWS web application firewall, creating security groups and integrating from a comprehensive view across your hybrid (or cloud-based) network. Ideally, there should be some type of rules templates to streamline the process.
Across the enterprise, you need to easily manage, organize and backup AWS instances, Volumes, RDS databases, Aurora and RedShift Clusters. To make it easier to search, manage and filter resources and to manage backup, consider a way to create custom AWS tags based on the purpose, environment or other criteria. This is important for both AWS accounts and the users of those accounts.
From the standpoint of advanced security and data protection, don’t get rid of any of the cybersecurity protections you’ve previously purchased and use, but be prepared to quickly create firewall rules for any instance. There is no “silver bullet” in handling cybersecurity and the general rule of thumb is, the more layers of protection you have in place, the more secure you’ll be.
Bearing this in mind, you’ll also need to be able to create security groups that can be applied to any AWS instances, cross-account firewalling, and (perhaps more importantly) AWS Web Application Firewall (WAF) rules management. These integrated security countermeasures provide additional layers to bolster data protection overall and in addition to anything you already have in place.
As mentioned from the beginning, the ideal data protection strategy that addresses AWS’ shared responsibility model should be able to backup natively within the elastic cloud environment of AWS. That way you’ve eliminated the need for on-premises backup media and offsite storage locations as well as additional bandwidth, and other considerations.
Working within the cloud allows you to backup and replicate cross-account and cross-region to multiple geographic regions, even elsewhere around the world. That’s important in today’s decentralized business world and provides an overall disaster recovery capability that not too long ago, was only possible in very large multi-national enterprises. Today, it’s available to any enterprise of any size using AWS.
Since AWS provides multiple regions across many geographic areas as well as availability zones, there’s no excuse for not performing periodic recovery testing as a best practice. With AWS, customers can easily get into the habit of periodically testing their backup as a means of kicking the tires to ensure they actually work and can quickly recover from a disastrous event, whenever it might happen.
Switching your infrastructure to the cloud is not the end of your security concerns – but it takes most of the pressure off of having to deal with all of the actual physical hardware and network part of the security concerns. The rest is up to you. It makes no sense to take the time and money you save by not having to deal with physical hardware and network concerns and then squander it by continuing with silos of responsibility for backup and recovery, security and infrastructure management – as has been done historically before the advent of elastic cloud.
In the long run, you need a holistic approach that combines those elements into a true data protection strategy that holds up your end of the bargain you’ve struck in the AWS shared responsibility model.
A Joe Merces is the former CIO of the New York City Law Department, and CEO of Cloud Daddy/
