Why centralization in a multi-cloud security strategy is key
When moving to a multi-cloud infrastructure, there are a few strategies to keep in mind. Learn how centralization will limit the challenges of fragmented security access and monitor controls.
Centralization is one of the most critical areas on which security teams should focus when their organization creates a multi-cloud security strategy. With a multi-cloud system, operations and security teams potentially face a fragmented set of security access controls and monitoring tools. This presents a challenge if they are designed and implemented uniquely in each separate provider environment.
Some cloud operations teams look to multi-cloud brokers to centralize and integrate all cloud management into one place. Others select a single product or platform that can integrate into all the necessary provider environments, enabling central control of security policy and access management regardless of the underlying cloud infrastructure.
Before deploying a multi-cloud security strategy, security teams should evaluate all current controls for cloud and determine whether they are centralized, including:
- Endpoint security tools: Many of the modern antimalware and endpoint detection and response tools can work across multiple cloud environments.
- Configuration and patching tools: Building cloud workload images should be centralized if possible, which may rely more on infrastructure as code definitions than traditional imaging tools. Configuration management automation platforms like Puppet, Chef and Ansible can be used to maintain configuration consistency for all deployed instances.
- Vulnerability scanning: Most enterprise vulnerability scanners have successfully integrated into major cloud provider environments today, so it is unlikely you will need to adopt a fragmented approach for this type of control. Cloud "control plane" scanning and evaluation tools like RedLock, DivvyCloud and CloudCheckr can report on the configuration of the cloud accounts and environments themselves, which should be evaluated for their cloud coverage.
- Event collection and SIEM/analytics: Getting all logs out of cloud environments to a central source for evaluation has gotten easier as the major SIEM players have worked to integrate with most cloud providers. There are new security-as-a-service offerings in this space, too.
- Template-based infrastructure as code: Cloud operations teams should use infrastructure as code tools like Terraform. These tools can integrate with cloud-native template technology like AWS CloudFormation and Azure Resource Manager templates for defining infrastructure configurations and other elements of cloud accounts. Many security controls -- such as identity policies, network configuration and image templates -- can be defined in this way, too.
Some controls will not be easy to centralize, including:
- Encryption -- Most organizations will end up using key management tools within a particular cloud provider.
- All identity and access management.
- Automation -- Often API and scripting-specific in one environment.
Be sure to look for vendors that are cross-platform. Ideally, if you have a selection between vendors that are mostly equal in capability and cost, prioritize the one that has better coverage across multiple cloud environments. This is also the case for forensics and response tools that are in use by incident response, forensics and SOC teams. They will need to streamline their processes and playbooks as much as possible to use a unified evidence collection and investigation strategy.
Focus areas for a multi-cloud security strategy
Centralization should not be the only focus when moving to multi-cloud architecture. Security teams should also implement controls on multiple layers and consider how they apply in each environment. There are more options for implementing a defense-in-depth control architecture in multiple clouds -- as well as on-premises environments -- than ever before. Security and operations teams should really focus on a few things.
The first is the tools that can be implemented centrally for policy creation and overall management. The easier they are to manage operationally, the more successful the network design outcome will be.
Security and operations teams should also prioritize the use of infrastructure as code tools like Terraform.
Finally, they should consider the implementation of a multilayered network segmentation strategy. Traditional firewalls still have their place for enabling network connectivity between on-premises and cloud environments. They may also provide intrusion prevention and other controls that many enterprises need today. Cloud-native access control and segmentation controls should still be implemented.
For large cloud deployments, a base implementation of some cloud-native controls may prove valuable, but a multi-cloud design with numerous assets can really benefit from deeper application visibility that is enforced similarly in all cloud environments. This can also aid in centralization of monitoring and reporting. No cloud-native tools provide this level of introspection and dynamic policy evaluation today. This means that additional tools will be needed in order to accurately map out what types of application traffic are being seen, and to apply a centralized policy to workloads communicating across numerous clouds and within the on-premises data center. This will often require endpoint agents of some type to provide the necessary introspection and enforcement.
While it is the trend among large enterprises to move to a multi-cloud environment, there is still debate over the pros and cons of centralizing. It is documented that a centralized system results in coordination and communication efficiency and ensures uniformity. This is in contrast to a decentralized, nonhierarchical system in which inconsistencies exist that make it hard to implement and maintain in large organizations.
