The fourth pillar to well-architected AWS cloud security – Data Protection

Print Friendly, PDF & Email

This is the fifth in a series of seven on the five pillars for well-architected AWS security.  For the entire series, visit the Five pillars – AWS blog page here.  

Data protection for the network is often equated to backup, but the two functions are actually somewhat different.  Data backup is a snapshot in time of selected, any, or all data in a cloud infrastructure.  This is data at rest, and as such, it is only accurate to the point of the backup.  When backups are deployed to rectify a compromise, i.e., a data restore, significant time may have elapsed between the date of the most recent backup and the data restoration is initiated.

Recent legislation such as GDPR has caused security professionals to look beyond the protection of data at rest and address the much more difficult task of protecting data in motion (i.e., data in transit).  Data in motion is very often data moving out of the network, or between nodes, i.e. and can be vulnerable to malicious activity as a part of transport. 

Encryption is the most popular method of protecting data both at rest and in transit, but it is not a total solution.  Network security controls add another layer of protection, as do data policies.  Data that has been classified as at-risk can have specific policies applied to it whenever such data is accessed or moved, ranging from alerts to full blocks against access or transit.

There are other data conditions that need to be considered as part of data protection as well.  One of these is archiving.  Even though archived email is clearly data-at-rest, it still needs to be considered within the overall protection scheme.  Another consideration is ongoing threat scanning.  Scans need to look at all data, not simply data in motion.  It is very common to find emails with latent threats in S3 Buckets, often in the trash or spam folders; recognizing that these contain latent threats is important to ensure that someone doesn’t inadvertently open them and trigger malware.

Data that has been classified as at-risk can have specific policies applied to it whenever such data is accessed or moved, ranging from alerts to full blocks against access or transit.  Going further, data classification can be leveraged as a way to organize data based on self-described levels of sensitivity, and ultimately automating encryption tools and access.

To develop a well-architected Data Protection pillar, customers must:

  • Have complete visibility of information and data stored in AWS
  • Controlled versioning of data
  • Protect data at all times
  • Encrypt your data at all times

There are multiple means to encrypt data at rest and in transit in AWS.  There is service-side encryption, as well as HTTPS encryption or SSL termination that can be handled by Elastic Load Balancing (ELB).

When developing their data protection pillar, customers need to consider the following:

  • How they will classify data and automate security such as encryption
  • How they will protect data at rest, as well as data in transit

Visit the Well-Architected Labs documentation in AWS to read more about Classification and Encryption, Protecting Data at Rest, and Protecting Data in Transit.

In our next blog, we’ll dive deeper into the 5th Pillar, IR (Incident Response).   To follow this series in its entirety, visit the Five Pillars – AWS blog page here.

 

Barracuda Cloud Security Guardian secures your cloud infrastructure with an easy-to-use, highly automated solution that helps keep you secure in an era of increasing complexity and multiplying compliance mandates.  For a free scan, visit our website here.

 

 

Leave a Reply

Your email address will not be published. Required fields are marked *

Scroll to top
Tweet
Share
Share