Introducing IAM Deny: Harden Your Security Posture at Scale the Easy Way
2633
Of your peers have already read this article.
1:30 Minutes
The most insightful time you'll spend today!
At Google Cloud, we’re focused on making it easy for organizations to build solutions quickly and securely. Identity and Access Management (IAM) is the core security control for establishing who has access to which cloud resources and making sure access permissions are aligned to your company’s business and security policies.
We are excited to announce the general availability of IAM Deny policies. This new capability helps you easily create access guardrails for Google Cloud resources. With IAM Deny policies, you can create rules that broadly restrict resource access. It provides a powerful, coarse-grained access control to help implement security policies at scale.
Control with IAM Policy – Allow and Deny
IAM Deny policies complement IAM Allow policies as you define access to your resources. Google Cloud’s IAM Allow policy lets you grant granular access to Google Cloud resources. The more coarse-grained Deny policies let you explicitly prohibit access to certain resources regardless of existing Allow rules. IAM Deny policies always supersede IAM Allow policies and override conflicting IAM Allow rules.
IAM Deny policies can be applied across many Google Cloud resources, such as Compute Engine, Cloud Storage, and Google Cloud Kubernetes Engine. These policies can help reduce toil on administrators as they can set up deny rules that will be enforced at scale without requiring reviews and changes of existing access rules. This makes resource governance simpler.
How to strengthen your security posture with IAM Deny
There are multiple use cases where IAM Deny policies can be used to help strengthen posture. Some of these are:
- Establish a default security baseline: IAM Deny can be used to set base policies at the organization level, folder level, and project level to deny access to resources. For example, you can attach a deny policy at the organization level to deny all users access to sensitive data storage buckets, making an exception for a specific user group.
- Prevent backdoors: IAM Deny rules override any IAM Allow rules. This can help you ensure that no “backdoor” access can be granted. For example, an organization that wants to ensure only central-admin can create projects in a folder can add an IAM Deny policy that restricts all users from creating projects except central-admin. This can help ensure no backdoor users will be added using allow policy rules.
- Prevent data exfiltration: Controlling access to data is a key measure to prevent exfiltration. For example, an organization that wants to restrict access to their personally identifiable information (PII) can set an IAM Deny policy on resources containing PII that denies access to all users except those in a group called PII-admin.
- Demonstrate compliance: Many industry regulations and compliance frameworks require organizations to demonstrate least-privilege access to sensitive resources. IAM Deny policies can create a baseline access restriction that always takes precedence when applied to resources.
Simplify IAM administration
IAM Deny can also help simplify common administrative tasks. It provides a list of permissions for Google Cloud services that you can readily use in your deny policies. Here are a few common situations where you can use IAM Deny to help streamline your access management.
- Centralize administrative privileges: You can use deny policies to restrict certain types of administrative activities to specific users or user groups. For example, if you want to limit custom role management to a single central team, you can create a deny rule that denies the permissions required for custom role management to all users, except users in the central-admin group. This will only let members of the central-admin group manage custom roles, even if other users have the required permissions.
- Create exceptions to access grants: You can use deny policies to deny inherited permissions. For example, you can grant a role at a high level in the resource hierarchy, and then deny the role’s permissions on individual lower-level resources if necessary.
- Block access based on tags: Google Cloud supports key-value based tags and you can use deny policies to deny permissions based on tags without adding an IAM Condition to every role grant. For example, you can create a rule to deny delete permissions for resources tagged as “production” for everyone except project-admins.
IAM Deny in action
The following example illustrates how a deny policy can be used to block all users from deleting projects unless the user is a member of a project-admins group or the project being deleted is tagged as a “test” project. Without a deny policy, you would have to manually track all members who have the permission to delete projects, and ensure that no undesired user has access to this permission. The deny policy makes it easy for the administrator to build this guardrail.
The below deny rule denies permission to everyone except project-admins@example.com for projects not tagged as test. Add this deny rule to a deny policy and attach the policy at the org level. That’s it!
(Note that project-admins@example.com is a security group. Using security groups is a best practice that should be followed to help keep your resources secure.)
{
"name": "policies/cloudresourcemanager.googleapis.com%2Fprojects%2F253519172624/denypolicies/limit-project-deletion",
"uid": "06ccd2eb-d2a5-5dd1-a746-eaf4c6g3f816",
"kind": "DenyPolicy",
"displayName": "Only project admins can delete projects.",
"etag": "MTc1MTkzMjY0MjUyMTExODMxMDQ=",
"createTime": "2021-09-07T23:15:35.258319Z",
"updateTime": "2021-09-07T23:15:35.258319Z",
"rules": [
{
"denyRule": {
"deniedPrincipals": [
"principalSet://goog/public:all"
],
"exceptionPrincipals": [
"principalSet://goog/group/project-admins@example.com"
],
"deniedPermissions": [
"cloudresourcemanager.googleapis.com/projects.delete"
],
"denialCondition": {
"title": "Only for non-test projects",
"expression": "!resource.matchTag('12345678/env', 'test')"
}
}
}
]
}Getting started with IAM Deny Policies
With IAM Deny, you now have a powerful new capability to build security guardrails and more effectively control access to your Google Cloud resources. IAM Deny is now generally available for all customers through gCloud and APIs. We offer IAM Deny to Google Cloud customers at no additional cost. You can learn more about IAM Deny by visiting our documentation page.
VCP Peering and Private Endpoints on Vertex AI to Better Security and Predictions in Near Real-time
4472
Of your peers have already read this article.
2:00 Minutes
The most insightful time you'll spend today!
One of the biggest challenges when serving machine learning models is delivering predictions in near real-time. Whether you’re a retailer generating recommendations for users shopping on your site, or a food service company estimating delivery time, being able to serve results with low latency is crucial. That’s why we’re excited to announce Private Endpoints on Vertex AI, a new feature in Vertex Predictions. Through VPC Peering, you can set up a private connection to talk to your endpoint without your data ever traversing the public internet, resulting in increased security and lower latency for online predictions.
Configuring VPC Network Peering
Before you make use of a Private Endpoint, you’ll first need to create connections between your VPC (Virtual Private Cloud) network and Vertex AI. A VPC network is a global resource that consists of regional virtual subnetworks, known as subnets, in data centers, all connected by a global network. You can think of a VPC network the same way you’d think of a physical network, except that it’s virtualized within GCP. If you’re new to cloud networking and would like to learn more, check out this introductory video on VPCs.
With VPC Network Peering, you can connect internal IP addresses across two VPC networks, regardless of whether they belong to the same project or the same organization. As a result, all traffic stays within Google’s network.
Deploying Models with Vertex Predictions
Vertex Predictions is a serverless way to serve machine learning models. You can host your model in the cloud and make predictions through a REST API. If your use case requires online predictions, you’ll need to deploy your model to an endpoint. Deploying a model to an endpoint associates physical resources with the model so it can serve predictions with low latency.
When deploying a model to an endpoint, you can specify details such as the machine type, and parameters for autoscaling. Additionally, you now have the option to create a Private Endpoint. Because your data never traverses the public internet, Private Endpoints offer security benefits in addition to reducing the time your system takes to serve the prediction when it receives the request. The overhead introduced by Private Endpoints is minimal, achieving performance nearly identical to DIY serving on GKE or GCE. There is also no payload size limit for models deployed on the private endpoint.
Creating a Private Endpoint on Vertex AI is simple.
In the Models section of the Cloud console, select the model resource you want to deploy.
Next, select DEPLOY TO ENDPOINT
In the window on the right hand side of the console, navigate to the Access section and select Private. You’ll need to add the full name of the VPC network for which your deployment should be peered.
Note that many other managed services on GCP support VPC peering, such as Vertex Training, Cloud SQL, and Firestore. Endpoints is the latest to join that list.
What’s Next?
Now you know the basics of VPC Peering and how to use Private Endpoints on Vertex AI. If you want to learn more about configuring VPCs, check out this overview guide. And if you’re interested to learn more about how to use Vertex AI to support your ML workflow, check out this introductory video. Now it’s time for you to deploy your own ML model to a Private Endpoint for super speedy predictions!
3273
Of your peers have already watched this video.
4:43 Minutes
The most insightful time you'll spend today!
Beaconing Malware: How CISOs Can Catch it With Threat Analytics in Just a Few Clicks
Are you checking your network for beacon activity? If you aren’t you are risking your business’ reputation and customer data.
Beaconing is the practice of sending short and regular communications from an infected host to an attacker-controlled Command and Control server, compromising internal information.
These threats often go undetected but with Google’s Backstory you can store and continuously analyze petabytes of security telemetry. It ingests a large amount of telemetry data in just a few clicks, normalizes it, indexes it, correlates it with known threats, and makes it available for analysis.
This unmatched speed combined with UI responsiveness translates incident investigations and threat exploration into tasks that analysts can complete in seconds instead of hours.
Watch this four-minute video to find out how to focus on investigations to fight Malware Beaconing.
Embracing Confidential Computing: Secure Your Data in the Cloud
1216
Of your peers have already read this article.
1:30 Minutes
The most insightful time you'll spend today!
As one of the most trusted cloud platform providers, Google is committed to providing our clients secure and reliable environments for their workloads. Google believes the future of computing will increasingly shift to private, encrypted services where users can be confident that their data is not being exposed to cloud providers or their own insiders. Confidential Computing helps make this future possible by keeping data encrypted in memory, and elsewhere outside the CPU, while it is being processed.
Since our first Confidential Computing offering in 2018, Google has been a pioneer in making the technology widely available through our cloud, while also constantly adding new features that allow a wide range of organizations to benefit from it.
Expanding the Confidential Computing portfolio
Today at the RSA Conference 2023, we are announcing several exciting updates to our Confidential Computing portfolio.
We are expanding our portfolio with the next generation of our Confidential Computing VM instances that utilize AMD Infinity Guard technology, specifically AMD SEV-SNP (Secure Encrypted Virtualization-Secure Nested Paging). SEV-SNP adds additional new hardware-based security protections such as strong memory integrity protection and hardware rooted attestation. Confidential VMs on general purpose N2D VMs with SEV-SNP enabled are now in Private Preview. Learn more in our deep dive here.
“Advanced, hardware-based security features – such as AMD Infinity Guard built into AMD EPYC processors – are a crucial part of cloud offerings and the further expansion of cloud computing,” said Ram Peddibhotla, corporate vice president, Cloud Business, AMD. “Our work with Google Cloud delivers on the leadership security features our joint customers demand with nearly effortless implementation and minimal performance impact as more mission critical and business critical workloads move to the cloud.”
Google is committed to ensuring Confidential Computing technology is as secure as possible before releasing products to customers. We constantly evaluate various attack vectors to make certain that Google Cloud Confidential Computing environments are protected against a wide range of attacks.
Throughout last year, Google and Intel collaborated on a research project to identify potential security vulnerabilities in Intel’s new Confidential Computing technology, Trust Domain Extensions (TDX). We’ve recently released the full report and made it available in our blog here.
“We want to make it such that people don’t worry about the security and trustworthiness of their data,” said Anil Rao, vice president and general manager of systems architecture and engineering in the Office of the CTO at Intel. “Organizations use confidential computing to control their data and provide access to trusted parties in a manner that is verifiable, revocable and time sensitive – we have an obligation to make sure the technology is secure. Our early effort with Google solidifies our commitment to perform thorough analysis to address all potential vulnerabilities.”
Confidential Space is now in general availability. Confidential Space builds on Confidential Computing and provides a secure enclave, also known as a Trusted Execution Environment (TEE). Google Cloud customers can leverage the TEE for various privacy-focused use cases such as joint data analysis and machine learning (ML) model training, with trust guarantees that data can stay protected — including hardened protection against cloud service provider access.
Confidential Space allows for new privacy-preserving technologies to take shape, and one such technology is The Privacy Sandbox. This is a crucial step forward as Privacy Sandbox for the Web will phase out third-party cookies and limit covert tracking. By supporting a choice of trusted execution environments, including Confidential Space, the Privacy Sandbox will provide ad-techs with safer alternatives to existing technology, so they can continue building digital businesses while keeping user data private.
“Trusted Execution Environments (TEEs) are already in use across industries such as digital advertising to enable privacy preserving analytics, and we are excited to leverage Google Cloud’s built-in TEE called Confidential Space,” said Gaurav Bhaya, vice president and general manager, Google Ads Measurement.
Building on our history of innovation with Confidential Computing
Google has worked diligently with internal and external partners to validate, audit and publish the security assessment of the hardware, firmware, and software that underpins Confidential Computing.
Last year, a joint security effort between Google Project Zero, Google Cloud, and AMD led to more secure technology for the entire industry, regardless of what service provider you choose for your Confidential Computing deployment. You can learn more in our full report here.
Since then, we have continued to expand the portfolio of Confidential Computing products and services, including Confidential Virtual Machines (CVMs), Confidential GKE, Confidential Dataproc, and Confidential Space. These offerings give our customers more choice in their deployments.
Currently, our Confidential Computing services are widely available across 80% of Google Cloud regions and growing, and we recently added support for Compute-Optimized C2D VMs for Confidential GKE.
Organizations are now leveraging Confidential Computing for joint data analysis and machine learning (ML) model training with trust guarantees that the data they own stays protected and across various other industries by organizations, including AstraZeneca, Bullish, HashiCorp, Matrixx Software, MonetaGo and Yellowdog.
Confidential Computing has also proven to be a helpful additional control for organizations implementing digital sovereignty strategies, providing an encryption capability, and protection for data-in-use where encryption keys are not accessible by the cloud provider.
We can’t wait to see the possibilities this technology will open up for your organization. Check out our Confidential Computing page to learn more.
Gmail’s BIMI Increases Confidence about Security and Delivers Immersive Email Experiences
5442
Of your peers have already read this article.
3:00 Minutes
The most insightful time you'll spend today!
Creating a secure-by-default experience based on robust defenses has always been a core design principle for Gmail. That’s why we’ve established a strong baseline of security in Gmail, with built-in protections to help automatically filter out potentially malicious messages. While these defenses help keep Gmail users safe, email functions as part of a large, complex, interconnected ecosystem that we continually invest in and work to protect. After first announcing Gmail’s Brand Indicators for Message Identification (BIMI) pilot last year, today we’re announcing that over the coming weeks we’re rolling out Gmail’s general support of BIMI, an industry standard that aims to drive adoption of strong sender authentication for the entire email ecosystem. BIMI provides email recipients and email security systems increased confidence in the source of emails, and enables senders to provide their audience with a more immersive experience.
“Bank of America has a wide range of security measures in place to support our customers, and we constantly evolve our program to deliver best in class protection. Part of this effort is our partnership with Google on BIMI, which provides an easy way to validate if correspondence is from us.” — Bank of America
BIMI enables organizations that authenticate their emails using Domain-based Message Authentication, Reporting, and Conformance (DMARC)—a standard for providing strong sender authentication that allows security systems to perform better filtering, separating legitimate messages from potentially spoofed ones—to validate ownership of their logos and securely transmit them to Google. BIMI is designed to be easy: for organizations with DMARC in place, validated logos display on authenticated emails from their domains and subdomains.
Here’s how it works: Organizations who authenticate their emails using Sender Policy Framework (SPF) or Domain Keys Identified Mail (DKIM) and deploy DMARC can provide their validated trademarked logos to Google via a Verified Mark Certificate (VMC). BIMI leverages Mark Verifying Authorities, like Certification Authorities, to verify logo ownership and provide proof of verification in a VMC. Once these authenticated emails pass our other anti-abuse checks, Gmail will start displaying the logo in the existing avatar slot.
“Gmail’s support of BIMI is a win for email authentication, brand trust, and consumers alike. BIMI gives organizations the opportunity to provide their customers with a more immersive email experience, strengthening email sender authentication across the entire email ecosystem.” — Seth Blank, Chair of the AuthIndicators Working Group
This is just the start for BIMI. The standard expects to expand support across logo types and validators. For logo validation, BIMI is starting by supporting the validation of trademarked logos, since they are a common target of impersonation. Today, Entrust and DigiCert support BIMI as Certification Authorities, and in the future the BIMI working group expects this list of supporting validation authorities to expand further. To learn more about BIMI and see the latest news, visit the working group’s website.
To take advantage of BIMI, ensure that your organization has adopted DMARC, and that you have validated your logo with a VMC. For Gmail users, no action is required. We’re proud to be one of the leading members in both establishing and supporting the BIMI standard and will continue to support efforts that contribute to security for the entire email ecosystem.
Three Reasons Why Enterprises Must Think Next-gen Serverless
4909
Of your peers have already read this article.
2:00 Minutes
The most insightful time you'll spend today!
As we reflect on the past year, Heraclitus’ phrase “The only constant in life is change” has never rang more true. With the pandemic, companies had to shift operations, launch new products and adapt to extreme demand patterns, sometimes within a matter of weeks.
To respond to customer needs faster and more efficiently, many companies turned to serverless technology, designing applications with real-time signals and intelligence built in. From apps and sites for healthcare appointments and vaccinations, public-sector employment benefits, contact tracing, retail logistics, curbside delivery, hotel and travel booking—you name it, companies built it with serverless.
Redefining serverless
The world changed, the market changed, our lives changed and we here at Google Cloud also changed, introducing new products to meet our customers’ needs and grow with them.
Serverless technology, in particular, has changed a lot since it was first introduced. Google first launched serverless compute in 2008 with the launch of App Engine, helping customers scale their applications faster and seamlessly. We then added the ability to run Functions as a Service with Cloud Functions, giving customers a simple developer experience with integrated telemetry and observability. In parallel, we also introduced innovations to the container market with Kubernetes. Pretty soon, customers started asking us if we could combine the awesome serverless attributes of auto-scaling and developer experience with the flexibility of containers.
Enter Cloud Run, the next generation of serverless. Serverless is now no longer just about event-driven programming or microservices. It’s also about running complex workloads at scale while still preserving a delightful developer experience. In fact, serverless with Cloud Run is about having a true developer platform with the flexibility to run any language, any library, any binary.
There are three capabilities that make Cloud Run the next-generation of serverless, and not the same ‘serverless’ you find elsewhere:
- A great developer-centric experience
- Versatility: expanding to a broader set of containerized apps
- Built-in DevOps and security
Let’s take a look at the attributes in greater depth.
A great developer experience
Being developer-centric comes from having fully-managed self-operating infrastructure and a great developer experience. We want everyone to be able to develop smart applications and for that we have to make it easy. We also want to be sure we are bringing your technical talent closer to where you generate your business value.
To make things easy, last year we introduced buildpacks, which creates container images directly from source code. No need to learn Docker or containers. Although there are containers underneath, they’re transparent to the developer.
To simplify things further, we also introduced a single “gcloud run deploy” command to build and deploy code to Cloud Run. These types of features are some of the reasons why 98% of Cloud Run users deploy an application on their first try in less than 5 minutes.
In fact, in the past year alone, we added over 25 new features and services to our serverless stack, making development of complex apps easier. One of our main launches was Workflows, which lets you combine Cloud Run with any Google Cloud product or any HTTP-based API service. As a developer, this is very useful when automating complex processes, or integrating GCP’s analytic services across a variety of systems.
Taken together, all these new features make the Cloud Run developer experience far easier than its competitors’, according to a recent report by User Research International.
Versatility
Next-generation serverless is also about versatility. It supports a wider variety of applications and caters to enterprise requirements. Functions and web apps of course, but also heavyweight applications, and in the fullness of time, also brownfield and third-party containerized apps. This versatility is enabled by the container primitive, which removes restrictions on languages, run times, and hardware.
Being able to run a greater variety of apps on our serverless stack means you can optimize for predictable usage. Today, we announced new spend-based committed use discounts for Cloud Run. Enterprises with stable, steady-state, and predictable usage can now purchase committed use contracts directly in the billing UI. There are no upfront payments, so these discounts are a perfect way to reduce your spend by as much as 17%. RELATED ARTICLEMaximize your Cloud Run investments with new committed use discountsCommitted use discounts in Cloud Run enable predictable costs—and a substantial discount!
Another way we provide versatility is with support for WebSockets and gRPC in Cloud Run. With these new additions, you get the benefits of serverless infrastructure to build responsive, high-performance applications. We also added the use of min instances with Cloud Run. This feature allows you to cut cold-start times and run latency-sensitive applications on Cloud Run! At the same time, you can still scale to zero, or keep a minimum amount of compute available, for example when running brownfield Java applications.
Built-in DevOps
Serverless doesn’t just make it faster for developers to set up their apps—it also helps once the application is up and running, taking a big management load off of operations teams. Notably, serverless systems take care of “scaling” an application up or down. That means that if your application suddenly starts fielding a lot of traffic, the serverless platform automatically spins up more resources to handle the load. No more dreaded timeouts, wheels or hourglasses—or work for your operations team. Likewise, as soon as demand goes down, the platform takes care of decommissioning resources, i.e., scaling down, so that you’re not paying for resources that you no longer need. Want to run your service globally with low latency, without an operations team, and zero stranded costs? Cloud Run takes care of global load balancing and autoscaling to zero for you in every Google Cloud region.
Further, features like support for gradual rollouts and rollbacks allow developers to experiment and test ideas quickly, as well as sophisticated traffic management in Cloud Run. Likewise, Cloud Run provides access to distributed tracing with no setup or configuration, allowing developers to find performance bottlenecks in production.
Next up: serverless security
As part of DevOps best practices, we build in security for your serverless applications at every layer: deployment time, runtime and networking. For example, built-in vulnerability scanning ensures you only deploy artifacts you trust.
Today, we are announcing Cloud Run support for Google Secret Manager and customer-managed encryption keys (CMEK), making it easy to protect data at rest and store sensitive data. We’re also integrating Cloud Run with Binary Authorization, which lets you enforce specific policies to make sure only verified images make it to production. And finally, we added a new integration with Identity-Aware Proxy, support for VPC-SC, and egress controls that you can use to enforce a security perimeter, limiting both who can access specific services and what resources can be accessed when these services run in production. You can read more about these security enhancements here. RELATED ARTICLE4 new features to secure your Cloud Run servicesWe’re improving the security of your Cloud Run environment with things like support for Secret Manager and Binary Authorization.
In summary, the next generation of serverless combines the best of serverless with containers to run a broad spectrum of apps, with no language, networking or regional restrictions. The next generation of serverless will help developers build the modern applications of tomorrow—applications that adapt easily to change, scale as needed, respond to the needs of their customers faster and more efficiently, all while giving developers the best developer experience. Learn more by attending The Power of Serverless, a two-hour virtual event where we’ll lay out our vision for serverless compute, and where serverless subject matter experts will present on in-depth serverless development topics. Hope to see you there!
Want to learn even more about serverless and cloud-native application development? Check out the upcoming Modern App Dev & Delivery workshop, and our Ask the Experts roundtable.
More Relevant Stories for Your Company
Google Cloud & Siemplify Join Forces to Empower Companies to Manage Threat Responses Better
At Google Cloud, we are committed to advancing invisible security and democratizing security operations for every organization. Today, we’re proud to share the next step in this journey with the acquisition of Siemplify, a leading security orchestration, automation and response (SOAR) provider. Siemplify shares our vision in this space, and
Why Enterprises Should Choose Google Cloud for their SAP Workloads
Change is a constant for SAP customers. Now more than ever, SAP customers need solutions that provide them business agility, rock solid availability and security and true economic value. Learn how Google Cloud can guide your SAP journey to the cloud with simple and no cost migrations, powerful infrastructure and
How Firewall Insights can Simplify Corporate Firewall Rules
Corporate firewalls typically include a massive number of rules, which accumulate over time as new workloads are added. When rules stack up piecemeal like this, misconfigurations occur that, at best, create headaches for security administrators, and at worst, create vulnerabilities that lead to security breaches. To address this, we have
Google Products Helps HMH’s Healthcare Staff Work from Anywhere Efficiently and Securely!
Hackensack Meridian Health (HMH) executive Mark Eimer explains how an ambitiously-timed rollout of a comprehensive suite of Google products helped the entire organization—from doctors to IT staff—achieve better security, cultivate a more equitable work environment, and ultimately, improve patient outcomes. How does a recently merged, 17-hospital healthcare system fast-track a platform migration
