Storage
Mobility
Protection
Analysis and control
TOPICShare
As a storage administrator, or storage system architect, your past involvement regarding security and compliance programs was probably described as supplemental. You may have received compliance requirements that likely addressed storage admin topics such as encryption protocols or retention periods, which would be added to storage architecture after the fact.
Life was easier in those days. With today’s cloud data storage standards, cloud compliance and regulation are changing to focus on privacy and security. New privacy-focused regulation like the EU’s GDPR and California’s CCPA underscore the need for technical architects to be engaged earlier and with more focus on compliance. This discussion will examine some of the reasons for that change, and how you, as a cloud data storage professional, can address them.
The Cloud Compliance Point of View
Because technology in the cloud has evolved to replace the traditional data center, it’s not surprising that security compliance entered the cloud as well. Most point to the fact that security in the cloud did not evolve smoothly—but this was probably inevitable. News of data loss in the cloud typically highlights how unaware organizations can be of threats and vulnerabilities in complex systems. Cloud compliance has therefore meant trying to apply security requirements to new or repurposed technologies in a new environment.
The question for technical leaders is how new cloud compliance requirements are going to impact the operations and cloud data privacy. Similar to agile techniques in system development, participants must be highly aware of complex environmental needs, aware of the interconnectedness of systems, and multiple other requirements. As a technical architect, your awareness of cloud data storage protection is critical to compliance in the cloud.
For example, recent security and privacy compliance regulations such as GDPR are difficult to deploy from a management and technical perspective, and impact different parts of the company in different ways. It is worth examining the obvious points of view for typical stakeholders:
- For the management of the company, data privacy regulation has broad and wide-reaching effects. It means the company must process data in a manner differently than it has in the past—this presents a strategic problem that will possibly impact business processes, sales, marketing, and, definitely, costs.
- For the security team, it is challenging to consider newly envisioned security measures for risks that may not be well understood. To maintain security and be relevant, the security team must quickly analyze the security requirements and prioritize the controls that may have to change.
- For a compliance team, the work to meet GDPR and laws like it may require a number of new positions. For instance, the mandated Chief Privacy Officer (CPO) or Data Protection Officer (DPO) could be a highly technical person or a high-level representative asked to coordinate the efforts of technical and legal resources. It will depend on the organization, but there are a lot of requirements for the compliance function, including the creation and maintenance of a report—the Data Protection Impact Assessment (DPIA), that requires input from possible stakeholders and data participants.
This review of the perspective and responsibilities of these teams highlights the possibility that they may remain far away from the specific implementation specifics of the regulation. It’s easy to see that these groups will need involvement from the technical leaders within the organization. For instance, the level of effort to understand where all data resides within a system is not going to magically appear for most security or compliance personnel and the management is going to want to see where costs can be reduced or revenue (or value) improved. As a technical systems architect, know that you are likely to become involved.
The Proactive Stance
For the technical architects of systems, hiding in an office or dreading the discussion about new compliance requirements is certainly not the best plan of action. Like many changes, it will benefit you to get ahead of this challenge. An early suggestion and recommendation: read and familiarize yourself with the regulation you must comply with. Assume that PCI compliance or HIPAA compliance in the cloud is part of your responsibility even if they don’t necessarily apply to your industry.
Getting better awareness of the regulation will actually give you a better chance to present to the rest of the organization your ability to see the bigger picture of systems. It will guarantee your ability to listen more acutely and ask deeper questions when the call from management finally occurs.
Most likely the call from the front office will be for assistance with the DPIA. This is called a report, but actually it is an ongoing assessment and describes practices as part of system administration. It is a compliance document, but it is expected to provide technical assurance that controls are in place and operating effectively. This is not a challenge that the business management, security, and compliance teams will be able to perform without technical assistance. The best solution may be automation to support reporting, but you know this type of automation must be designed and implemented to meet the requirements to be effective.
The next step is to refine your awareness of automation technologies in support of the regulation. Specifically, you have the knowledge of how data moves within your organization, from active and deep storage to backup, and other system requirements. But by knowing compliance requirements of the data may change the flow of that information. For instance, backup and recovery (DR) requirements may inform you of SLA, RTO, and RPO levels that have to be addressed using higher speed systems for recovery.
Using Cloud Automation Tools for Compliance
Automation that is aware of data and regulatory requirements is helpful for the architect to help make the data flow report on compliance requirements. For instance, as data passes from active to deep storage, automation can examine records for end of life, trigger encryption or report on the location of special types of privacy data. These abilities can be examined along with other capabilities such as data tiering and building automation to reduce costs of operations.
It is also important for solutions that enhance compliance not to require retooling the entire legacy system. Maintaining a complex application if the data layer must be rearchitected for compliance is a crisis many organizations are facing. The better solution is to find cloud compliance automation tools that work within the storage and data tiers to address requirements with flexible reporting options.
NetApp Cloud Compliance for NetApp Cloud Volumes ONTAP, Azure NetApp Files, and Amazon S3 buckets offers a number of built-in abilities for the storage team to help improve security and maintain a compliance profile. These abilities will make creation and maintenance of the DPIA more successful, and include:
- Ability to search data sets for specific data for retraction activities
- Provide a view into your privacy posture and share with security, risk and compliance teams.
- Maintain visibility of all sensitive data or systems to reduce the risk of privacy breaches.
- Enforce restrictions for sensitive data migration.
Conclusion
Your skills and technical knowledge of cloud data storage technology are going to be critical for the organization to meet security and privacy compliance in the cloud. Both new and legacy programs are going to be under scrutiny by regulators that will need evidence that the data flow of a system is well understood and does not put data at risk. Your abilities to understand the legacy flow will make the use of data aware tools to perform cloud compliance automation, and without having to redesign the system to meet the compliance regulations. Cloud Compliance gives you an easy way to do that with all your cloud data.
