Netskope est nommé leader dans le Magic Quadrant™ du Gartner 2022 dédié au Security Service Edge Recevoir le rapport

  • Produits de périphérie du service de sécurité

    Protégez-vous contre les menaces avancées et compatibles avec le cloud et protégez les données sur tous les vecteurs.

  • Borderless SD-WAN

    Fournissez en toute confiance un accès sécurisé et performant à chaque utilisateur, appareil, site et cloud distant.

  • Plateforme

    Une visibilité inégalée et une protection des données et des menaces en temps réel sur le plus grand cloud privé de sécurité au monde.

Netskope reconnu comme un des leaders dans le rapport du Magic Quadrant™ 2022 du Gartner dédié au SSE

Recevoir le rapport Présentation des produits
Netskope gartner mq 2022 leader sse

Réponse rapide de Gartner® : Quel est l'impact de l'acquisition d'Infiot par Netskope sur les projets SD-WAN, SASE et SSE ?

Recevoir le rapport
Réponse rapide : Quel est l’impact de l’acquisition d’Infiot par Netskope sur les projets SD-WAN, SASE et SSE ?

Netskope offre une solution moderne de sécurité du cloud, dotée de fonctions unifiées en matière de protection des données et de détection des menaces, et d'un accès privé sécurisé.

Découvrir notre plateforme
Vue aérienne d'une métropole

Optez pour les meilleurs services de sécurité cloud du marché, avec un temps de latence minimum et une fiabilité élevée.

Plus d'informations
Lighted highway through mountainside switchbacks

Neutralisez les menaces qui échappent souvent à d'autres solutions de sécurité à l'aide d'un framework SSE unifié.

Plus d'informations
Lighting storm over metropolitan area

Solutions Zero Trust pour les déploiements du SSE et du SASE

Plus d'informations
Boat driving through open sea

Netskope permet à toutes les entreprises d'adopter des services et des applications cloud ainsi que des infrastructures cloud publiques rapidement et en toute sécurité.

Plus d'informations
Wind turbines along cliffside
  • Nos clients

    Netskope sert plus de 2 000 clients dans le monde, dont plus de 25 des entreprises du classement Fortune 100

  • Solutions pour les clients

    Nous sommes là pour vous et avec vous à chaque étape, pour assurer votre succès avec Netskope.

  • Formation et certification

    Avec Netskope, devenez un expert de la sécurité du cloud.

Nous parons nos clients à l'avenir, quel qu'il soit

Voir nos clients
Woman smiling with glasses looking out window

L’équipe de services professionnels talentueuse et expérimentée de Netskope propose une approche prescriptive pour une mise en œuvre réussie.

Plus d'informations
Netskope Professional Services

Sécurisez votre parcours de transformation numérique et tirez le meilleur parti de vos applications cloud, Web et privées grâce à la formation Netskope.

Plus d'informations
Group of young professionals working
  • Ressources

    Découvrez comment Netskope peut vous aider à sécuriser votre migration vers le Cloud.

  • Blog

    Découvrez comment Netskope permet de transformer la sécurité et les réseaux à l'aide du Security Service Edge (SSE).

  • Événements et ateliers

    Restez à l'affût des dernières tendances en matière de sécurité et créez des liens avec vos pairs.

  • Définition de la sécurité

    Tout ce que vous devez savoir dans notre encyclopédie de la cybersécurité.

Podcast Security Visionaries

Episode 9: Empowering People to Be Security Champions
In this episode, Mike and Alvina Antar, CIO at Okta, discuss identity-first security, automating business processes through AI and ML, and leading by example to achieve a more diverse industry.

Écouter le podcast
Empowering People to Be Security Champions with Alvina Antar, CIO at Okta

Découvrez comment Netskope permet de passer au Zero Trust et au modèle SASE grâce aux fonctions du Security Service Edge (SSE).

Lire le blog
Sunrise and cloudy sky

SASE Week

Netskope is positioned to help you begin your journey and discover where Security, Networking, and Zero Trust fit in the SASE world.

Plus d'informations
SASE Week

Qu'est-ce que le Security Service Edge ?

Découvrez le côté sécurité de SASE, l'avenir du réseau et de la protection dans le cloud.

Plus d'informations
Four-way roundabout
  • Entreprise

    Nous vous aidons à conserver une longueur d'avance sur les défis posés par le cloud, les données et les réseaux en matière de sécurité.

  • Pourquoi Netskope

    La transformation du cloud et le travail à distance ont révolutionné le fonctionnement de la sécurité.

  • Équipe de direction

    Nos dirigeants sont déterminés à faciliter la réussite de nos clients.

  • Partenaires

    Nous collaborons avec des leaders de la sécurité pour vous aider à sécuriser votre transition vers le cloud.

Netskope permet l'avenir du travail.

En savoir plus
Curvy road through wooded area

Netskope redéfinit la sécurité du cloud, des données et des réseaux afin d'aider les entreprises à appliquer les principes Zero Trust pour protéger leurs données.

Plus d'informations
Switchback road atop a cliffside

Penseurs, concepteurs, rêveurs, innovateurs. Ensemble, nous fournissons le nec plus ultra des solutions de sécurité cloud afin d'aider nos clients à protéger leurs données et leurs collaborateurs.

Rencontrez notre équipe
Group of hikers scaling a snowy mountain

La stratégie de commercialisation de Netskope privilégie ses partenaires, ce qui leur permet de maximiser leur croissance et leur rentabilité, tout en transformant la sécurité des entreprises.

Plus d'informations
Group of diverse young professionals smiling

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 currently a researcher at Netskope, where he focuses on security for AWS and GCP.