Twenty years ago, organizations discovered the magic of server virtualization. Among the many benefits of virtualization, it heralded the end of the need for one physical server per application and the beginning of managing software-defined infrastructure. It helped automate building and installing systems, and it helped lay foundations for today’s Continuous Integration/Continuous Delivery mechanisms and DevOps practices. However, the adoption of virtualization was not always smooth and several hurdles stood in its path. Today’s organizations are facing similar obstacles in their journey to the cloud.

Organizations that wanted to virtualize their server environment two decades ago faced a significant challenge that was neither technical nor budgetary, but organizational, stretching across IT teams and beyond. The first team to be concerned about virtualization was the one in charge of installing the physical servers in the racks of the datacenter, managing the physical network connections and operating environmental controls, such as HVAC and power systems. These tasks were drastically reduced, if not outright eliminated.

The second team affected by this shift in technology was the one responsible for installing the operating system and running the post-install procedures. Their job almost completely disappeared as most virtual machines were automatically instantiated from templates.

As a result, successful adoption relied on the ability to smooth these organizational changes. Along the way, training the staff and making sure they acquire the new skills necessary to operate the virtualization infrastructure was critical. And usually, the affected teams eventually found that their new responsibilities were different but still essential to the organization, and perhaps even more appealing.

Virtualizations lessons for cloud transformation regulators

Discussions on virtualization didn’t end with these internal changes when organizations were operating in a regulated environment. They needed to engage closely with their regulators. Regulated organizations often considered the hypervisor solely as an additional layer of software with potential vulnerabilities.

This viewpoint raised risks (such as virtual machine escape) that didn’t exist with physical servers. Even if this is taken into account and the risks mitigated, it should have been considered in balance with all the benefits of machine virtualization, including security benefits such as asset identification, harmonization, and smoother patch management.

While the relevance and benefits of virtualization are now widely accepted, history has repeated itself as similar issues have arisen for organizations facing cloud migrations. When large cloud service providers (CSP) began supporting critical workloads for their customers, regulators increased their oversight over CSPs and issued guidance concerning cloud adoption. This happened in the European financial sector, with guidelines from the European Supervisory Authorities (European Banking Authority, European Securities and Market Authority and European Insurance and Occupational Pensions Authority,) and the coming Digital Operational Resilience Act regulation.

These regulations can help establish trust between providers and customers. As regulator decisions are vital for organizations, there is an opportunity now with cloud technology to balance the risks with the benefits and take into consideration all the ways CSPs can help organizations improve their overall security and compliance levels.

Cultural transformation can drive cloud transformation

Another similarity between cloud transformation and the journey to virtualization is the required internal transformation. When an organization decides to start its journey to the cloud, training its staff with the new technology and tools is a necessary step, but probably not the first nor the most arduous to make. A change of mindset is paramount to fully incorporate all the cloud benefits, in particular regarding security.

This new approach begins with a deep transformation at the organizational level. Organizations should avoid viewing the cloud as a datacenter because there’s so much more potential to cloud technology. This new approach and its accompanying organizational transformation is driven by two factors: The burdens that the CSP removes from the customer, and the new flexibility that software-defined infrastructure brings to the table.

The CSP directly manages several tasks and services, and their security, which means that they’re no longer a direct concern for the customer. These responsibilities include data center management, security-hardened hardware, default encryption for data at rest and data in transit, and resilient network management.

Since all the infrastructure used by the organization to manage its workloads is software defined, it brings much more flexibility to what can be done with it. Software-defined infrastructure can more easily enable security guardrails and continuous compliance that weren’t possible before.

While there’s a temptation to approach an organization’s cloud transformation as merely a “lift and shift” operation from on-premises infrastructure, the reality is that approach reduces the potential gains a cloud transformation can bring to an organization. Moving systems to the cloud accounts for a small portion of the potential impact, while updating the mindset can be truly transformational. Development, architecture and security processes need to be rebuilt; this inevitably requires a deeper transformation of the organization.

The next step is to transform the operations, to align them with the overall organization and the new defined processes, operationalize CI/CD and build DevOps practices. After that, the technological gap will be adjusted, moving the new tools and teaching teams how to best use them.

The important point here is the order of the transformation to manage: organization, operations and technologies (O-O-T) and not the other way round (T-O-O). Of course, these three steps should not be considered completely sequential, as technology plays an important role in the organization and the operations. However, it is essential to support the development of personnel and frameworks to take full advantage of the transformation opportunity, rather than primarily focusing on the tooling.

In addition, at Google Cloud, we believe in a shared fate that goes far beyond the usual shared responsibility model. We think it is part of our duty to help our customers to achieve their goals in their scope of responsibility. We prepare secure landing zones and guide the customers, we bring transparency to security controls and help them with cyber-insurance.

Our shared objective with our customers is to continuously improve security. Our Google Cybersecurity Action Team initiative helps us to be engaged alongside our customers, provide them with necessary guidance, support them in their security and compliance strategies, and assist their organizational and operational transformation in their cloud journey.

• Listen to a related podcast “How to Apply Lessons from Virtualization Transition to Make Cloud Transformation Better”
• Listen to “Preparing for Cloud Migrations from a CISO Perspective, Part 1”
• Read “The journey to the cloud mitigates enterprise risk”
• Also, review “Megatrends drive cloud adoption—and improve security for all”
• Visit Google Cybersecurity Action Team website

We created Traffic Director to bring to you a fully managed service mesh product that includes load balancing, traffic management and service discovery. And now, we’re happy to announce the availability of a fully-managed zero-trust security solution using Traffic Director with Google Kubernetes Engine (GKE) and Certificate Authority (CA) Service.

When platform administrators and security professionals think about modernizing their applications with a forward-looking security posture, they look for “zero-trust” security. This security posture is based on few fundamental blocks:

1. A means of allocating and asserting service identity (for example, using X.509 certificates)
2. Mutual authentication (mTLS) or server authentication (TLS)
3. Encryption for all traffic flows (TLS encryption)
4. Authorization checks and minimal privileges
5. Infrastructure to make all of the above manageable and reliable

Traffic Director does this by integrating with CA Service, a highly available private CA which issues private certificates expressing service identities, and provides a managed mTLS certificate infrastructure with full certificate lifecycle management. Together, these solve both certificate issuance and CA rotation complexities. 

With Traffic Director managing your service-to-service security, you can now enjoy end-to-end encryption, service-level authentication and granular authorization policies for your service mesh.

With this new capability, you can now:

• Implement mutual TLS (mTLS) and TLS between your services, including certificate lifecycle management. Communications within your mesh are authenticated and encrypted.
• Enable identity-based authorization, as well as authorization based on other parameters (such as the request method). These concepts underpin role-based access controls (RBAC) and enable you to take a “least privileges” stance where only authorized services can communicate with each other based on ALLOW/DENY rules.

mTLS is supported whether you’re using Envoy or proxyless gRPC for your service mesh. Authorization support for proxyless gRPC is coming later this year. Check out our documentation to learn more and get started with Envoy or proxyless gRPC.

Last week, the European Commission and U.S. Government agreed on a new E.U.-U.S. data transfer framework. Earlier today, Google shared that it welcomes these efforts by the U.S. government to enhance privacy protections for E.U. data and facilitate trusted transatlantic data flows. For our Google Cloud customers, we intend to make the protections offered by this new framework available once it is implemented.

Last year, we reaffirmed our commitment to E.U. businesses after the European Data Protection Board (EDPB) issued its Recommendations on Supplementary Measures, following Europe’s top court ruling invalidating the E.U.-U.S. Privacy Shield Framework and upholding the E.U. Standard Contractual Clauses (SCCs).

Since then, we’ve continued to help our customers meet stringent data protection requirements by offering industry-leading technical controls, contractual commitments, and risk assessment resources. We’ve also continued our advocacy to create more legal certainty around transatlantic data flows.

Today, we would like to provide an update to our customers on this work.

A customer-controlled cloud

Google Cloud1 continues to be a leading provider of technical and security controls to help meet customers’ data protection requirements, as well as their increasing data sovereignty expectations.

We are committed to building our Cloud on Europe’s terms, including by offering customer-managed encryption and data localization for a growing list of key products and collaborating with local partners to provide the highest levels of sovereignty, all while enabling the next wave of growth and transformation for Europe’s businesses and organizations.

Google Cloud Platform

We recently announced the general availability of Assured Workloads for the E.U. This product helps Google Cloud Platform (GCP) customers protect their data by allowing them to:

• Store their data in their choice of E.U. Google Cloud region(s)
• Ensure that only E.U. persons – located in the E.U. – have access to the data and provide customer support
• Deploy cryptographic control for data access, including customer-managed encryption keys

Cloud External Key Manager (EKM) enables customers to encrypt data in a variety of services with keys that are stored and managed in a third-party key management system deployed outside of Google’s infrastructure. Google Cloud continues to be the only cloud provider to enable customers to store and manage encryption keys for cloud-resident data outside the provider’s infrastructure with customer’s control over decryption based on specific justifications, including government access requests.

Key Access Justifications greatly advances the control that GCP customers have over their data by giving customers a justification every time their externally hosted keys have to be used to decrypt data. Signed Access Approval (SAA) adds a layer of extra assurance that requires explicit customer consent for any administrative access to customer data or configurations.

Google Cloud’s Confidential Computing portfolio is a breakthrough technology that allows customers to encrypt their most sensitive data in the cloud while in-use. Ubiquitous Data Encryption further extends data protection by providing cryptographic protection for this data at-rest, in-transit, and in-use. The keys used to encrypt customer data outside of GCP using Cloud EKM are securely shared with applications operating within Confidential environments.

Google Workspace

Our Google Workspace (including Workspace for Education) customers can choose to store their covered data in Europe. Additionally, with Client-Side Encryption, we offer customers direct control of encryption keys and the identity service they choose to access those keys. With Client-Side Encryption, customer data is indecipherable to Google, while users can continue to take advantage of Google’s native web-based collaboration, access content on mobile devices, and share encrypted files externally. Client-Side Encryption is currently available in Public Beta for Google Drive, Docs, Sheets, and Slides, and we plan to extend it to Gmail, Calendar and Meet. Additionally, customers can also benefit by choosing third party solutions that offer similar encryption capabilities with select Google Workspace services.

Legal Basis for International Data Transfers

We updated our data processing terms for GCP and Google Workspace and Cloud Identity to reflect various modules of the new E.U. Standard Contractual Clauses (SCCs) approved by the European Commission on June 4, 2021, as well as separate U.K. SCCs.

Google Cloud plans to adopt the new E.U.-U.S. data transfer framework and offer it as a transfer solution to our cloud customers, as further detailed in our data processing terms.

Advocacy and Additional Helpful Resources

We have adopted the Trusted Cloud Principles with industry peers to demonstrate our commitments to protect the rights of our Google Cloud customers. We will continue to support the ongoing work of the Organisation for Economic Co-operation and Development on government access to data and the negotiation of CLOUD Act Agreements — including between the U.S. and E.U. — as vehicles for surveillance reform.

We will continue to publish additional materials on our Cloud Privacy Resource Center, such as our whitepaper on safeguards for international data transfers with Google Cloud.

Millions of organizations with users in Europe rely on our cloud services to run their businesses every day, and we remain steadfastly committed to helping them meet their regulatory requirements by maintaining a diverse set of compliance tools.

reCAPTCHA Enterprise is Google’s online fraud detection service that leverages more than a decade of experience defending the internet. reCAPTCHA Enterprise can be used to prevent fraud and attacks perpetrated by scripts, bot software, and humans. When installed inside a mobile app at the point of action, such as login, purchase, or account creation, reCAPTCHA Enterprise can block fake users and bots while allowing legitimate users to proceed.

To provide more complete coverage for native mobile iOS and Android applications, we’re announcing the general availability of the reCAPTCHA Enterprise Mobile SDK. Designed with digital-first and mobile-first organizations in mind, the new Mobile SDK fully integrates reCAPTCHA Enterprise’s frictionless experience on end-users’ mobile devices.

Why should I use the Mobile SDK?

Unlike most web applications, iOS and Android apps run on physical devices that can provide a wealth of device telemetry to help identify fraud and bot activity. By combining both device and network signals, the new mobile SDK can better protect native mobile applications from bot attacks while unlocking the full potential of reCAPTCHA Enterprise. It provides:

• Frictionless customer experience — no picking fire hydrants from a grid
• Easy integration to your native mobile app with support for popular frameworks like Cocoa Pods and Swift Package Manager
• A regularly-updated device threat model to help stay ahead of attack evolution

Protecting against fraud across all your channels

Customers will be able to leverage the new mobile SDK to implement native iOS and Android protection against the OWASP Top 10 automated attacks common on the internet, which include fraudulent account creation, financial hijacking, and credential stuffing. This is particularly important for mobile workforces and end users who use a mobile app to access products and services. Since mobile traffic surpasses web traffic in many industries, it’s even more important to implement a comprehensive mobile app protection strategy to protect against the most prevalent attacks.

Integrating the new Mobile SDK

If you’re interested in learning more about how to integrate the new Mobile SDK, check out the documentation for iOS and Android. Mobile and Web integrations leverage the same easy to understand pricing for Assessments, found here.

Setting up your new cloud infrastructure is scary. Extra scary when you realize that someone (is it gonna be you?) gets to have phenomenal cosmic power over the whole thing. 

Yes, I’m talking about the admin account, and today we’ll dig into why they are important, dangerous and different.

When the team at pistach.io got their nuts-as-a-service business growing fruitfully, they knew they needed to think carefully about admin accounts. These people would have tremendous control over their use of Google Cloud, and they could potentially cause very big problems if any were compromised. Definitely resources that require a protective shell.

Early in pistach.io’s development, an employee named Walter Nutt wanted to play a prank by changing his co-worker’s profile photo from an almond to a peanut (pretty devious, since a peanut is actually a legume). He didn’t have access to his friend’s computer, but he did have access to the company’s Cloud Storage bucket. While searching for the profile photo in question, Wally inadvertently deleted the entire contents of the bucket! 

As he searched for ways to restore its contents, Wally modified access to two other pistach.io buckets.  The company was ground to a halt for a week while teams worked to crack through the permissions issues.

Time to rethink permissions a bit, so this couldn’t spoil their buttery smooth operations in the future.

Following the resource manager guide, the team made a super admin email address that wasn’t tied to a particular individual or Workspace account, and secured it with strong multi-factor authentication. This would be their backup in case an admin account were to be compromised, so they could recover and repair.

The team already uses Google Workspace, so they have an organization set up already. That creation process established initial super administrators, allowing them to create and modify all other resources inside the organization. As they looked toward using Google Cloud, the super administrators could:

1. Give the admin role to people, for Cloud
2. Act as a point of contact for account recovery
3. Modify or delete the organization if needed

Making admin users for the organization allows other people to then flesh out the resources and policies for pistach.io, before they go nuts and give everyone all the permissions. While that would speed things up, it would make it easy for an attacker to crack through the security shell because any account compromise could give ousize access. Yikes!

Instead, the IT leads specified certain people to act as organization admins, and then gave them permissions to:

1. Define Identity and Access Management policies
2. Structure the Resource Hierarchy
3. Delegate control of specific Cloud elements to others on the team

Once those organization admins were set up, they could give management and oversight of Compute, Storage, Networking and other resource types to the relevant leads, making sure each person had just the right amount of permission for the role they needed to perform. The organization admins don’t have permissions themselves to make these resources. They just delegate. 

Now each person can accomplish the job they’re responsible for, but doesn’t have overly permissive access. Delegating like this keeps the entire organization safer, and limits the blast radius if someone does manage to break in.

You can go through these steps yourself with this tutorial.

By default the creation of an organization resource for the domain gives everyone the ability to create projects and billing accounts. Once they set up their Organization Admin at pistach.io they decided to remove some of these wide permissions and, in a nutshell, bring everything down to a much finer control. So people could get permissions for a folder or a project, but not the entire organization!

Remember to take care of your admin roles, as they have the power, and responsibility, to cause serious harm if not used safely. Be safe with your Identity and Access Management. And keep your data yours! 

Next time we join you we’ll take a crack at creating and provisioning an app to run inside the policies and resource management frameworks created today.