Acelere su implementación SASE con la serie Backstage de SASE Week . Sesiones de exploración

cerrar
cerrar
  • Por qué Netskope chevron

    Cambiar la forma en que las redes y la seguridad trabajan juntas.

  • Nuestros clientes chevron

    Netskope atiende a más de 3.400 clientes en todo el mundo, incluidos más de 30 de las 100 empresas más importantes de Fortune

  • Nuestros Partners chevron

    Nos asociamos con líderes en seguridad para ayudarlo a asegurar su viaje a la nube.

Un Líder en SSE.
Y ahora Líder en SASE Single-Vendor.

Descubre por qué Netskope debutó como Líder en el Cuadrante Mágico de Gartner® 2024 para Secure Access Service Edge (SASE) de Proveedor Único.

Obtenga el informe
Visionarios del cliente en primer plano

Lea cómo los clientes innovadores navegan con éxito por el cambiante panorama actual de las redes y la seguridad a través de la Plataforma Netskope One.

Obtenga el eBook
Visionarios del cliente en primer plano
La estrategia de venta centrada en el partner de Netskope permite a nuestros canales maximizar su expansión y rentabilidad y, al mismo tiempo, transformar la seguridad de su empresa.

Más información sobre los socios de Netskope
Grupo de jóvenes profesionales diversos sonriendo
Tu red del mañana

Planifique su camino hacia una red más rápida, más segura y más resistente diseñada para las aplicaciones y los usuarios a los que da soporte.

Obtenga el whitepaper
Tu red del mañana
Presentamos la Netskope One Plataforma

Netskope One es una Plataforma nativa en la nube que ofrece servicios convergentes de seguridad y redes para hacer posible su transformación SASE y de confianza cero.

Más información sobre Netskope One
Abstracto con iluminación azul
Adopte una arquitectura de borde de servicio de acceso seguro (SASE)

Netskope NewEdge es la nube privada de seguridad más grande y de mayor rendimiento del mundo y ofrece a los clientes una cobertura de servicio, un rendimiento y una resiliencia incomparables.

Más información sobre NewEdge
NewEdge
Netskope Cloud Exchange

Cloud Exchange (CE) de Netskope ofrece a sus clientes herramientas de integración eficaces para que saquen partido a su inversión en estrategias de seguridad.

Más información sobre Cloud Exchange
Vista aérea de una ciudad
  • Servicio de seguridad Productos Edge chevron

    Protéjase contra las amenazas avanzadas y en la nube y salvaguarde los datos en todos los vectores.

  • Borderless SD-WAN chevron

    Proporcione con confianza un acceso seguro y de alto rendimiento a cada usuario remoto, dispositivo, sitio y nube.

  • Secure Access Service Edge chevron

    Netskope One SASE proporciona una solución SASE nativa en la nube, totalmente convergente y de un único proveedor.

La plataforma del futuro es Netskope

Intelligent Security Service Edge (SSE), Cloud Access Security Broker (CASB), Cloud Firewall, Next Generation Secure Web Gateway (SWG) y Private Access for ZTNA integrados de forma nativa en una única solución para ayudar a todas las empresas en su camino hacia el Servicio de acceso seguro Arquitectura perimetral (SASE).

Todos los productos
Vídeo de Netskope
Next Gen SASE Branch es híbrida: conectada, segura y automatizada

Netskope Next Gen SASE Branch converge Context-Aware SASE Fabric, Zero-Trust Hybrid Security y SkopeAI-Powered Cloud Orchestrator en una oferta de nube unificada, marcando el comienzo de una experiencia de sucursal completamente modernizada para la empresa sin fronteras.

Obtenga más información sobre Next Gen SASE Branch
Personas en la oficina de espacios abiertos.
Diseño de una arquitectura SASE para Dummies

Obtenga un ejemplar gratuito del único manual que necesitará sobre diseño de una arquitectura SASE.

Obtenga el eBook
Cambie a los servicios de seguridad en la nube líderes del mercado con una latencia mínima y una alta fiabilidad.

Más información sobre NewEdge
Autopista iluminada a través de las curvas de la ladera de la montaña
Habilite de forma segura el uso de aplicaciones de IA generativa con control de acceso a aplicaciones, capacitación de usuarios en tiempo real y la mejor protección de datos de su clase.

Descubra cómo aseguramos el uso generativo de IA
Habilite de forma segura ChatGPT y IA generativa
Soluciones de confianza cero para implementaciones de SSE y SASE

Más información sobre Confianza Cero
Conducción en barco en mar abierto
Netskope logra la alta autorización FedRAMP

Elija Netskope GovCloud para acelerar la transformación de su agencia.

Más información sobre Netskope GovCloud
Netskope GovCloud
  • Recursos chevron

    Obtenga más información sobre cómo Netskope puede ayudarle a proteger su viaje hacia la nube.

  • Blog chevron

    Descubra cómo Netskope permite la transformación de la seguridad y las redes a través del perímetro de servicio de acceso seguro (SASE)

  • Eventos y Talleres chevron

    Manténgase a la vanguardia de las últimas tendencias de seguridad y conéctese con sus pares.

  • Seguridad definida chevron

    Todo lo que necesitas saber en nuestra enciclopedia de ciberseguridad.

Podcast Security Visionaries

El futuro de la seguridad: cuántica, IA y cambio macropolítico
Emily Wearmouth y Max Havey hablan con el CEO de Netskope, Sanjay Beri, y el CTO, Krishna Narayanaswamy, sobre el futuro de la seguridad.

Reproducir el pódcast Ver todos los podcasts
El futuro de la seguridad: cuántica, IA y cambio macropolítico
Últimos blogs

Lea cómo Netskope puede habilitar el viaje hacia Zero Trust y SASE a través de las capacidades de perímetro de servicio de acceso seguro (SASE).

Lea el blog
Amanecer y cielo nublado
SASE Week 2024 bajo demanda

Aprenda a navegar por los últimos avances en SASE y Zero Trust y explore cómo estos marcos se están adaptando para abordar los desafíos de ciberseguridad e infraestructura

Explorar sesiones
SASE Week 2024
¿Qué es SASE?

Infórmese sobre la futura convergencia de las herramientas de red y seguridad en el modelo de negocio actual de la nube.

Conozca el SASE
  • Empresa chevron

    Le ayudamos a mantenerse a la vanguardia de los desafíos de seguridad de la nube, los datos y la red.

  • Ofertas de Trabajo chevron

    Join Netskope's 3,000+ amazing team members building the industry’s leading cloud-native security platform.

  • Soluciones para clientes chevron

    Le apoyamos en cada paso del camino, garantizando su éxito con Netskope.

  • Formación y Acreditaciones chevron

    La formación de Netskope le ayudará a convertirse en un experto en seguridad en la nube.

Apoyar la sostenibilidad a través de la seguridad de los datos

Netskope se enorgullece de participar en Vision 2045: una iniciativa destinada a crear conciencia sobre el papel de la industria privada en la sostenibilidad.

Descubra más
Apoyando la sustentabilidad a través de la seguridad de los datos
Ayude a dar forma al futuro de la seguridad en la nube

At Netskope, founders and leaders work shoulder-to-shoulder with their colleagues, even the most renowned experts check their egos at the door, and the best ideas win.

Únete al equipo
Empleo en Netskope
El talentoso y experimentado equipo de servicios profesionales de Netskope proporciona un enfoque prescriptivo para su exitosa implementación.

Más información sobre servicios profesionales
Servicios profesionales de Netskope
Asegure su viaje de transformación digital y aproveche al máximo sus aplicaciones en la nube, web y privadas con la capacitación de Netskope.

Infórmese sobre Capacitaciones y Certificaciones
Grupo de jóvenes profesionales que trabajan

Permission Isolation in GCP

Aug 09 2019

When Identity and Access Management (IAM) permissions are not sufficiently isolated using the structure provided by the Google Cloud Platform (GCP), the results could be disastrous. Ideally, if you must provide a service account with permissions at a Folder or Organization level, the service account should be created in its own project, which is well insulated from external traffic and contains multiple layers of protection.

For example, a GCP project that contains externally exposed workloads and also has a service account with permissions at the Organization level is something that should never occur in your environment. This situation could allow an attacker to tear down security controls, establish persistence, and expose data. This post will go into more detail about how someone could effectively exploit this type of configuration, specifically looking at GCP’s Compute Engine.

The content in this post is based upon a presentation I did at DEFCON 27. For more information about a specific scenario that eliminated a service perimeter and exposed data, refer to the slides from my DEFCON talk available here.

Assigning Permissions in GCP

Identity types in GCP include users, groups, domains, and service accounts. They are all assigned permissions in GCP the same way, by assigning them roles at various levels of the GCP Organization structure. When permissions are assigned to an identity, it’s called an IAM binding. As you can see in the diagram below (from Google’s documentation), bindings can be applied at every point of the hierarchy, and the permissions are inherited down:

The roles are actually just a collection of permitted API calls. The roles in the diagram above are called predefined roles, which are provided by Google. The predefined roles are based on certain job functions. Google also supplies primitive roles by default, which are not recommended for use. The primitive roles are fairly permissive, they are the following:

  • Viewer – read-only permissions to view resources or data 
  • Editor – permissions to modify existing resources (as well as create / delete in most services)
  • Owner – permissions to modify resources, as well as manage permissions and billing

Once these primitive roles are assigned at the project level, the identity has the permissions for all the resources in that project. Keep the Project Editor role in mind, as we will come back to it.

Service Accounts and Impersonation

A service account in GCP is an identity that is provided to allow applications to authenticate and make calls to the GCP APIs. It does not use passwords, but uses RSA keys to authenticate. If you are familiar with IAM roles in AWS, this is the same concept for GCP. When you assign a service account to a resource, Google automatically rotates the keys for you. This is better than having to store static credentials in your code.  

One important concept to keep in mind for GCP is that a service account must be created in a project. However, a service account could be given bindings at a level higher than a project, such as permissions at the Folder or even Organization levels. I will refer to these types of permissions as “elevated bindings.” These are dangerous, because the permissions at higher levels could give you access to other security controls, and all the projects under that structure will inherit the permissions.

Resources, applications, users, and even service accounts can all impersonate a service account. Impersonating a service account means that you are able to authenticate as the service account, and now have whatever permissions were granted to it. Logs will show any actions as being performed by the service account. It’s important to understand impersonation, because it could be used in unexpected ways in your environment to escalate privileges.

The Default Service Account

When you first enable the Google Compute Engine, it automatically creates a “Default Service Account.” If you don’t make any custom changes while launching a new virtual machine, it will automatically use the default service account. This means that your virtual machine will authenticate as the service account, so it can make any GCP API calls as that service account. If a user were to SSH into the virtual machine and start running “gcloud” commands, it would utilize those service account credentials to interact with GCP.

Google recommends that you immediately remove the default service account. They recommend that instead you create your own service account and assign it only the permissions required.  Why would that be the case? Well, the default service account contains a lot of permissions.

The default service account from Compute Engine is automatically given the Project Editor role. This role contains more than 1890 permitted API calls at the time that this post was written, including permissions to impersonate other service accounts. If your virtual machine is compromised and  running the default service account, that could open you up to privilege escalation and further compromise.

Access Scopes

The only thing stopping the default service account from being able to utilize all of its permissions are the “access scopes” assigned to the virtual machine. This is a control that dictates which APIs the service account is able to access. So, if the service account is granted access to the Storage API in the IAM policy, the account still cannot access the Storage API if the access scopes do not include the Storage API. Here is an example the access scope options available in the GCP console:

If you have “Allow full access to all Cloud APIs” selected, then the service account can use all of its permitted API calls. This is configured per virtual machine, so your environment could have varied levels of access for its virtual machines.

Compromise

If one of your workloads has been compromised while running the default service account and it also has full scopes enabled, then it could easily enumerate other service accounts in the same project, and even impersonate those service accounts. This is because the default service account has project editor permissions.  Those permissions include the ability to impersonate other service accounts in that project.

If the same project contains service accounts with elevated bindings (permissions at the Folder or Organization levels), then that service account can be easily impersonated by the compromised workload. Once the workload is used to impersonate it, that account is now only limited by the permissions granted to the service account with elevated bindings. This could include adding new users, tearing down VPC Service Controls (or other security controls), and launching its own workloads.

Recommendations

Due to the dangerous nature of the default service account running with full scopes assigned, we recommend doing the following in your GCP environment:

  1. Designate a project that will be used for any accounts that require elevated bindings. Keep that project as secure as possible and do not populate it with any public workloads.
  2. Keep track of who or what can impersonate service accounts. If you lose track of this, privilege escalation becomes a much larger risk.
  3. Don’t use the default service accounts for your workloads. If your workload does not need to access GCP APIs, then remove the service account all together.
  4. Don’t create bindings that include primitive roles whenever possible. These are broad, and permissions should be more granular.
author image
Colin Estep
Colin Estep has 16 years of experience in software, with 11 years focused on information security. He's a researcher at Netskope, where he focuses on security for AWS and GCP.

Stay informed!

Suscríbase para recibir lo último del blog de Netskope