This post was originally published by the Cloud Security Alliance.
When we are talking about building new systems, in the context of privacy or data protection, we often hear two concepts – Privacy by Design (PbD) and Privacy by Default.
Dealing with human privacy is not something new.
We build applications that store and process personal data – from e-commerce sites, banking, healthcare, advertisement, and more.
The concept of Privacy by Design (PbD) was embraced by the GDPR (General Data Protection Regulation) in Article 5 and Article 25, the CCPA (California Consumer Protection Act) in W410-1, the LGPD (Brazilian Data Protection Law) in Article 46 and the Canadian PIPEDA (Personal Information Protection and Electronic Documents Act) in Recommendation 14.
When designing systems in the cloud, we must remember the Shared Responsibility Model.
The cloud provider is responsible for the underlining infrastructure layers and offers us many built-in security controls, but it is our responsibility as companies developing systems in the cloud, to use the security controls and design applications to meet all privacy requirements.
In this blog post, I will provide insights about how to implement those concepts when building new systems in the cloud.
What is Privacy by Design?
Privacy by Design (PbD) is based on seven "foundational principles":
Principle 1: Proactive not reactive; preventive not remedial
To achieve this principle, we need to implement proactive security controls.
Examples of security controls:
- Identity and Access Management – Enforce authentication (who the persona claims to be) and authorization (what actions can be done by authenticated identity).
Example of service: AWS Identity and Access Management (IAM).
- Network Protection – Enforce inbound/outbound access to services using access control mechanisms.
Example of service: AWS Security groups.
- Data Encryption – Enforce confidentiality by encrypting data in transit and at rest.
Example of services AWS Key Management Service (AWS KMS).
Principle 2: Privacy as the default setting
To achieve this principle, we need to implement default settings at the application level and on the infrastructure level.
- Data minimization – When designing an application, we need to decide what is the minimum number of fields that will be stored (and perhaps processed) on data subjects in the application.
- Data location – When designing an application, we need to take into consideration data residency, by selecting the target region to store data according to relevant laws and regulations.
- Data retention – We need to set our application to keep data for as long as it is required and either delete or archive data when it is no longer needed (according to application/service capabilities).
Examples: Amazon S3 lifecycle management and Amazon EFS lifecycle management.
- Keeping Audit Trail – By default administrative actions (usually using APIs) are logged by all major cloud providers. If we want to increase log retention or include data actions (what identity did with the data), we need to manually enable it.
Example of service: AWS CloudTrail.
- Data Encryption – Enforce confidentiality by encrypting data in transit and at rest.
Principle 3: Privacy Embedded into Design
To achieve this principle, we need to embed privacy safeguards as part of the design.
Most data protection or data privacy regulations offers the data subjects the following rights:
- The right to be informed about the collection and use of their data.
- The right to view and request copies of their data.
- The right to request inaccurate or outdated personal information be updated or corrected.
- The right to request their data be deleted.
- The right to ask for their data to be transferred to another controller or provided to them.
When we design an application, we need to develop it to support the above data subject rights from day one, so once we need to use those functionalities, we will have them prepared, even before collecting information about the first data subject.
Principle 4: Full functionality – positive-sum, not zero-sum
To achieve this principle, we need to look at the bigger picture.
Privacy safeguards should be embedded as part of the application design, without affecting security controls or without causing performance impact on other services.
An example can be the security requirement to audit all actions in the system (for the incident response process) while keeping data privacy requirement to keep only a minimum amount of information about data subjects, not to mention the cost of keeping long-term audit log storage.
In the case of audit logs, we need to find the balance between having logs for investigation, while removing unnecessary information about data subjects, and perhaps moving old logs to an archive tier to save costs.
Principle 5: End-to-end security – full lifecycle protection
To achieve this principle, we need to make sure data is kept private throughout its entire lifecycle, from collection, storage, retirement, and disposal (when not required anymore).
When talking about data security, we must always remember to follow the CIA triad: Confidentiality, Integrity, and Availability.
The data lifecycle management contains the following:
- Data generation of the collection – We need to take into consideration automatic data classification.
- Storage – We need to take into consideration data retention and archiving, including storage capacity and archiving capabilities.
- Data use and sharing – We need to implement strong authentication and authorization processes to protect the data we store and process.
- Data archive – We should take advantage of built-in storage archive capabilities that exist with all major cloud providers.
- Data disposal – We should design mechanisms to allow us to destroy data no longer needed.
Principle 6: Visibility and transparency – keep it open
To achieve this principle, we need to create and publish a privacy policy, that will be available for our customers, per application or per website we publicly expose to the Internet.
The privacy policy should contain information about:
- The data we collect.
- The purpose for collecting data from our customers.
- If we share private data with third parties, the privacy policy should indicate it.
- The data subject rights (such as viewing which data is been collected, the right to update data subjects' data or delete data subject data).
- How can data subjects contact us (to view data, update it, delete it, or export it)?
Visibility and transparency are crucial, and as such, the privacy policy must be kept up to date.
Principle 7: Respect for user privacy – keep it user-centric
To achieve this principle, we need to put our customers (or data subjects) first.
User experience is an important factor – how will our customers know that we are collecting private data? How will they be able to consent to data collection, view the data we are collecting, or ask us to delete it?
We need to configure our application with privacy settings enabled by default and allow our customers an easy way to opt-in (subscribe) or opt out (unsubscribe) from our service.
We need to design our system to allow customers an easy way to export their private data and support the portability of the data we collect to another third-party system in a standard readable format.
Summary
When designing applications that will store or process private data in the cloud, we should remember the shared responsibility model, together with the seven principles of privacy by design.
Some of the principles can be achieved using services offered by cloud providers, for some, we can use third-party solutions and for some we are responsible for the implementation, to comply with privacy laws or regulations and to keep our customers' private data safe.
For any organization designing new applications in the cloud, I recommend creating teams containing representatives of both the technology department (such as DevOps, architects, and security personnel) and legal department (such as Lawyers, data privacy, compliance, and risk), to be able to design an end-to-end solution.
I invite anyone designing new applications, to read and get more information about the privacy law and regulations affecting their customers.
Disclaimer – This blog post contains my opinion. It does not replace any legal advice for complying with privacy obligations or regulations.
About the Author
Eyal Estrin is a cloud and information security architect, the owner of the blog Security & Cloud 24/7 and the author of the book Cloud Security Handbook, with more than 20 years in the IT industry.
Eyal is an AWS Community Builder since 2020.
You can connect with him on Twitter and LinkedIn.
Top comments (0)