Cloud Identity

Setting Up a Cloud Identity and Admin Account
After you’ve scrolled through the various pages of sales pitches telling you why you should try out the GCP, you can begin the process of setting up a Cloud Identity and signing up for an administrator account. You’ll be required to agree to a few click-through agreements.
Click-through agreements are legally enforceable online contracts that indicate user consent; you’ve likely encountered many of these, because every time you sign up for a new service or a privacy policy is updated, you have to agree to abide by or acknowledge certain requirements in click-through agreements. Whether or not you decide to read the many pages of click-through agreements, you should understand their importance and your organization’s stance on your entering into a contract in this way. Some companies, such as highly regulated companies, will require that legal counsel review any contracts, including click-through agreements, before you agree to them. In addition, a ton of legal and contracting work goes into a sales deal before a customer can launch the GCP environment.

Compliance Requirement Scenarios and the Exam
You’ll see scenario-based questions about compliance requirements on the exam. Here’s an example of a scenario where understanding agreements is important in your role as a cloud architect: A question may describe a scenario in which you’re an enterprise architect for a healthcare company, and you are required to abide by the European Union General Data Protection Regulation (EU GDPR). The GDPR dictates how data must be protected and how data privacy must be ensured. One of its requirements states that personal data within the European Union cannot leave the European Union.
In the scenario, you’re required to use a tool to perform message queueing and delivery, but you’ll also be required to ensure that data can persist in its region no matter what, even if there is a service outage (to meet GDPR requirements). The question then asks you to choose between the Apache Kafka or Pub/Sub messaging systems. What architecture do you design?
For this question, you’ll need to know that Pub/Sub is a global service, and its contract agreements state that, because of its global availability, if a region goes down, Pub/Sub will route data through other regions to maintain its high availability. This conflicts with your GDPR compliance requirements, so you may want to choose Kafka in this case, which offers you more control over the architecture versus a managed service. (Note that I threw a curveball here, because Pub/Sub now supports controlling where your message data is stored.)

TIP: You will see questions about general compliance requirements, so it’s a good idea to brush up on the top compliance frameworks in the industry, such as the European Union General Data Protection Regulation (EU GDPR) and others.
Cloud Identity is an Identity as a Service (IDaaS) solution that provides a unified identity, access, application, and endpoint management platform. It offers a variety of avenues to enable various users consuming GCP to connect and access resources. When you sign up for GCP, you’ll create an administrator account that will have access and ownership of your Cloud Identity, and you’ll have to set up a billing account. For a single user or small company, this is pretty straightforward. For an enterprise, the process can get pretty complex. You can create multiple billing accounts, depending on the size of your organization. For a huge, multinational company, with dozens of subsidiaries under its umbrella, for example, it would not make sense for one administrator to be responsible for paying all the bills for all the subsidiaries. Your organization’s Cloud Billing account pays for Google Cloud projects and Google Maps Platform projects, and it can be linked to one or more projects.
During the Cloud Identity setup process, you’ll be asked to add your domain, verify your domain with Domain Name System (DNS) records, and then create your Cloud Identity users. Typically, a text (TXT) record will be automatically generated in your DNS records to verify your domain, but you may sometimes have to do this manually. You may be working at an enterprise that is spinning out new organizations, for example, or that has not yet adopted GCP, so you’ll need to enter a vast amount of information.

TIP: The Google certification exams are typically not updated every time a new feature is released, because cloud computing evolves so quickly. Be aware that you may see questions on an exam that may no longer be entirely accurate because of the rapid feature releases of the cloud products. The likelihood of seeing an exam question about a deprecated or changed feature is pretty slim, however. But you’ll need to choose the right answer no matter what.

Security Principles in the Cloud
With the advent of cloud computing comes a new paradigm for how enterprises build and manage their technology stack. In the pre-cloud, traditional computing world, we thought about computing as a multitiered, or n-tiered, architecture, where the frontend served content, the middle tier handled application logic, and the backend was typically reserved for the database or data stores.
In the traditional monolithic application model, identity and access management (IAM) was typically brokered within the application. If a malicious user gained access to an application, he would have full access to everything within the monolith. With the rise of service-to-service communications is a reinvigorated emphasis on following the principles of least privilege and separation of duties, as applications are broken down into microservices. While this may increase the complexity of the enterprise architecture in some ways, it minimizes the threat surface, because authorization is required to grant access to services. Because these services are divided into smaller, loosely coupled chunks of work, or microservices, they hold fewer responsibilities. The same security principles apply in the cloud and are, at the core, the most important security controls for preventing malicious activity. As you design solutions for the cloud, think about how a hostile actor may gain access to a service, and think about how you could minimize the impact if a service were compromised.

The AAA Security Model
Authentication, authorization, and accounting (AAA) security is one of the core principles of security in the cloud:
- Authentication: The act of proving your identity; this is often referred to as identity assertion.
- Authorization: A set of privileges (known as permissions in GCP) that grants a user access to certain resources. I refer to this as “access management” in this book.
- Accounting: A process (typically referred to as auditing in GCP) that ensures that a digital log accounts for every user’s access and that these logs are immutable, or unable to be tampered with. These GCP resource access logs are typically stored in Cloud Audit Logs at the platform level, but applications also have their own form of audit trails that could be stored in system logs, application logs, and more.

Sn example of how AAA works. Suppose, for example, that you walk into your office wearing your employee ID badge that your company gave you. You walk to the kitchen, only to find that the snack cabinet is empty, but you know that the management team has secret snack room. You use your badge to try to get in to grab a snack, but you can’t, because you’re not authorized to enter the room because you’re not part of the management team, darn it. Unfortunately, the security team now knows that your badge was used to attempt to open a door you weren’t authorized to use.

Later, after you’ve had one too many drinks at a happy hour after work, you’re still wearing your badge, and you’re bragging about the unreleased Banana Phone X under your desk to your teammates. John the Ripper, a cyber criminal, overhears your conversation and realizes how much money he could make if he could get his hands on the unreleased Banana Phone X. He slips your badge into his pocket with a simple sleight of hand and walks out of the bar. He now holds your ID badge, and all the privileges associated with it, and plans to go to your office, find your desk, and steal the Banana Phone X to resell it on the black market. But when John the Ripper tries to badge in, he is prompted to authenticate his identity with a fingerprint scan. Now he’s out of luck. He has encountered multifactor authentication (MFA), which is known as 2-Step Verification (2SV) in GCP. In this type of authentication, the factors could be a combination of two of more of the following: something you know (such as a password or PIN), something you have (such as your badge), or something you are (such as your fingerprint). MFA security increases the confidence that a user is who he says he is.

In this case, when John the Ripper unsuccessfully attempts to access your office, the badge reader logs that attempt (accounting). When you report to your security team that your badge was stolen, and they look through their audit logs at the login attempts, they see an unsuccessful attempt with your badge on Tuesday at 7:43 A.M. So they look through the video footage and put together a story to report to law enforcement. This is the concept of nonrepudiation, which assures that someone cannot deny something. With the video recording of his face and the audit log of his access attempt, John the Ripper cannot deny that he attempted to enter the building with a stolen badge.

Now imagine you’re a multinational and multiorganizational company with offices all over the world with varying levels of requirements of who can access what, when, and how. How exactly do you ensure you’ve implemented a unified and secure authentication and access management system across the globe? Now consider designing a robust, centrally enforceable, secure, and unified identity and access management system for all of the digital assets your enterprise has that probably go ten layers deeper than the physical access they need to manage. This is the most important security aspect of the cloud and at the core of the defense-in-depth security model that we’ll discuss in depth later.

Least Privilege and Separation of Duties
Least privilege and separation (or segregation) of duties are two of the building blocks of security for computing systems (it also applies to physical security) focused on access management. The principle of least privilege states that we should provision an individual user or a system account with the least amount of privileges needed to perform their job functions so that we minimize the threat surface. Separation of duties is the idea that you should separate all of the duties needed to perform a critical business function across multiple users so that in the event one user is compromised, a whole system or process is not compromised.

These principles are why role-based access control (RBAC) has become the standard for IAM over the last 15 years or so. In the RBAC model, you define roles for your organization and your users, whether they are individuals, groups, or service accounts, and for each of these roles, you define the least amount of permissions necessary to enable the user to do their job.

Attribute-based access control (ABAC) is becoming more prevalent in the cloud, offering users the ability to allow or deny authorization to a resource based on certain conditions—such as blocking a user from accessing an application outside of work hours, or blocking access from a user in another country. You won’t see this on the exam, but leveraging ABAC will continue improving the layers of defense for your enterprise and should be considered for your most critical applications.

There are many examples of incidents happening in the world because of improper security access management principles. Every so often, they are significant enough to make the news. As a cloud architect, it’s important that you are also a security professional. Your role is to design an architecture that is safe from harm. Far too often, cloud architects are focused on performance, functionality, and reliability, while overlooking security.

Defense-in-depth requires security controls that work together to amplify protective measures to prevent unauthorized access to resources. Unfortunately, security measures are only as good as the weakest link. As companies look to leverage infrastructure as code (IaC) tools such as Terraform, Ansible, and others, they often need to grant powerful roles to the virtual machines (VMs) running those orchestration engines. Then the playbooks/modules are able to provision and configure anything and everything on the cloud that those roles allow. That may seem great from a high-velocity IaC business-value perspective, but that VM is the weakest link. Think about that for a second. If someone can gain access to the operating system (OS) on that VM, they can do almost anything on any cloud resource within its purview. The ability to access the shell of the OS gives them all they need to command the cloud resources because of the software development kit (SDK) software installed on the machine. As a result, all of the cloud service provider’s protections have been downgraded to the quality of the OS’s protective controls. That’s not a good design choice.

There are many better ways to secure such an environment, from changing the OS access approach, to avoiding super admin–like roles, to not making the VM accessible indirectly from the Internet. Implementing all of these factors in your design is a lot easier said than done, however. It’s not often that cloud architects are taught to think like an attacker, but as you read through this book and/or design architecture, you should try to think from a hacker’s point of view. The ultimate goal of designing secure systems is to assume that things can and will go wrong and then manage your risk accordingly. Although plenty of risk management books and certifications go into the formulas for effective risk management, I focus on the overall concept of minimizing risk for the intents and purposes of this book.

Here are a couple of terms you should know about in your day-to-day work, though you’re unlikely to see any questions about these in your exam: 
Entitlements refers to the process of granting users privileges and the scope of the privileges that are granted. 
Privilege creep occurs when a user accumulates too many privileges over time, which violates the principle of least privilege. 
Privilege creep can result from a user’s various promotions, job transitions, or requests for one-time access privileges that are not removed.

Cloud Identity Overview
As mentioned, Cloud Identity is an IDaaS solution that provides a unified identity, access, application, and endpoint management platform. Cloud Identity is an identity provider (IdP) that leverages the same identities used to power Google Workspace, and it integrates with various third-party applications. Cloud Identity supports Security Assertion Markup Language (SAML) and Lightweight Directory Access Protocol (LDAP) applications. SAML provides an open standard for exchanging authentication and authorization data between parties, commonly between an identity provider (Cloud Identity) and a service provider (third-party application). LDAP is an open cross-platform protocol that is commonly used for directory services authentication, such as Active Directory.

Cloud Identity includes two editions: a Free tier and Premium tier. In the Free tier, you can perform user security management via 2SV, perform basic mobile device management, leverage Google Cloud Directory Sync, and gather audit logs from the admin console. In the Premium tier, you get access to advanced mobile device management, secure LDAP, Google Security Center, BigQuery log exports, and a 99.9-percent service level agreement (SLA). Many companies already have third-party tooling that performs a lot of the Premium tier’s functionality, so they may elect to leverage the Free tier.

Managing Users in Cloud Identity: As a cloud architect, it’s important that you understand the following with regard to Cloud Identity:
- How to create or import user accounts into your Cloud Identity directory
- How to manage your user life cycle, including when users are onboarded, when they switch to new roles, and when they leave the organization
- How to leverage 2SV mechanisms to give you more confidence in nonrepudiation of your user identities
- Whether you’ll use single sign-on (SSO) and whether Cloud Identity or a third party will provide your identity

Creating Users and Groups
Users and groups are created in Cloud Identity, which is managed from the admin.google.com page rather than the GCP console. The users and groups that you create receive Google identities that can be consumed by Cloud IAM for role/permission management from the GCP console. You can create identities in many ways: by bulk uploading them, importing them, or manually creating them. Think of Cloud Identity as one layer of abstraction higher than Cloud IAM.
You first create users and groups that authenticate to the cloud in the admin page (admin.google.com) via whatever mechanism you choose. Then, when you launch the GCP console to access Cloud IAM, you can manage authorizations for these users and groups, assigning them roles that manage permissions to cloud resources. Cloud Identity roles are focused solely on managing authentication and information of users/groups in the admin page. GCP roles are provisioned and managed via the GCP console and enable access to cloud resources.

Cloud Identity is focused on user and group authentication and is administered via the admin console (admin.google.com). Cloud IAM is focused on user and group authorization, managing GCP roles that provide permissions to cloud resources via the GCP console (console.google.cloud.com).

Provisioning Users with GCDS
It’s recommended to use Google Cloud Directory Sync (GCDS) to provision users. This integrates with LDAP and requires minimal effort. Users can also be provisioned via bulk uploads, by manually creating them in Cloud Identity, by using Okta or another third-party tool, or by programming them in the Directory API within the Admin SDK. GCDS provides a one-way directory sync from Microsoft Active Directory or your LDAP server to synchronize your users, groups, organizational units (OUs), aliases, profiles, and shared contacts to match the information in your LDAP server. In addition, the LDAP server is never updated or altered. You can use custom mapping rules, and GCDS offers a simple user interface that enables you to simulate your configuration before you run it.
TIP: Many users have Google accounts that have access to consumer products such as YouTube, Google AdWords, and so on. However, it’s not recommended that these accounts be used in GCP. Users should be provisioned separately with a Cloud Identity–managed account.

Super Administrator and Organization Administrator Roles
In Google Cloud, the super administrator role can be a super admin in Cloud Identity, and the super admin is granted the GCP organization admin role by default. Super admin users manage the user and group account life cycle as well as the security settings of the organization from the Admin console. Super admins have full visibility of Cloud Identity and the GCP environments, and in a multiorganization setup, the super admin has full visibility of all the organization’s GCP environments. Organization admins have the ability to define IAM policies, grant other users IAM roles, determine the structure of the resource hierarchy, and delegate key cloud responsibilities to other users via roles. Organization admins cannot perform other actions, such as creating folders, unless they grant themselves the appropriate role.

CAUTION: Super admins are users in Cloud Identity who are managed via the Admin console, and they are granted the organization admin role in the environments that are created under that domain. They are not the same as organization admins that are created solely in GCP, although they get that organization admin role by default.
Hardware Security Keys: It’s very important that you secure your super admin accounts, usually with hardware security keys. Super admin users will always bypass SSO and can authenticate with Google. They have the most powerful permissions that don’t typically need to be leveraged daily, so it is important that you limit these users to three or four accounts and provide rigorous protection and monitoring to prevent malicious activity. You should also do the following:
- Keep a backup security key in case your super admin user loses a security key.
- Have proper recovery options in place and protect backup e-mails with 2SV.
- Ensure that there is more than one super admin user to avoid a single point of failure, but don’t provision too many.
- Separate duties by delegating the roles of the super admins and the organization admins.

How Users Authenticate to GCP
There are three primary ways for users to authenticate into Google Cloud:
- Via Google authentication without SSO
- Via SSO by using Google authentication and Cloud Identity as the IdP
- Via SSO by using an external IdP such as Okta, ADFS, or Ping Identity
The first option is most uncommon; most organizations prefer to leverage SSO for security and governance purposes. For organizations that strictly use GCP, the second option is more common as it doesn’t require any other vendors and has minimal overhead. Most enterprises use the third option, which offers the simplest onboarding and the most interoperability between cloud providers and on-premises environments. Enterprises often split several corporate applications between environments that have existing IdM solutions in place. This simplifies onboarding the same users into Google Cloud. Many third-party solutions such as Okta, Ping Identity, and ADFS already apply several security controls to users holistically across their enterprise.

2-Step Verification
It’s very important that you use 2SV—what Google Cloud calls multifactor authentication, across your enterprise. For privileged users, this should be mandatory, and you’ll have to perform a risk assessment for unprivileged users to determine the value of 2SV.
You can implement 2SV in several ways:
- SMS/voice This has its challenges, because it’s not a secure method of implementing 2SV. This method was actually removed from the National Institute of Standards and Technology (NIST) recommendation for MFA best practices because experienced hackers can exploit your phone number through various ways. It’s still better than nothing.
- Backup codes, authenticator app, or push notifications These solutions could be phished, but it’s significantly more secure than SMS.
- Hardware security keys Security keys are the most secure mechanism, although not all IdPs support security keys.

The mechanism by which hardware tokens are compliant is known as the FIDO U2F (Fast Identity Online Universal 2nd Factor) protocol that was defined by the FIDO Alliance. The alliance was founded by PayPal and other industry leaders to eliminate the world’s reliance on passwords and to promote strong authentication mechanisms. The FIDO Alliance has more than 260 members as of this writing, including Google, and its protocol is widely leveraged across most hardware tokens. Essentially, FIDO U2F is an open-authentication standard for a second factor of authentication that offers strong defense against phishing, session-hijacking, man-in-the-middle, and malware attacks. It does this by binding your physical hardware key to the IdP. So even if you tried logging in to a malicious website that looked exactly like your Google authentication page, it would not work, because the malicious website does not have your cryptographic binding to your physical hardware key. FIDO U2F–compliant tokens can be leveraged in Google Cloud. Google offers their own version of FIDO U2F–compliant hardware tokens, known as Titan Security Keys. Titan Security Keys are a FIDO U2F–compliant hardware token that is built with a secure element, the Titan chip, which verifies the integrity of the keys at the hardware level to make sure they are not tampered with. These are phishing-resistant keys and can also be leveraged across many services, including Facebook, Twitter, and more. Any FIDO U2F–compliant hardware key offers the highest level of security for 2SV.

Security Auditing
There are various ways to ensure that you’re adhering to the AAA security model best practices in Google Cloud, and security teams often leverage multiple elements of an audit trail to ensure they’re in the know.
In the Admin tab, you can review user settings and monitor user password strength. You can generate audit reports that provide some visibility into user logins and other audit logs across your services. You can set up custom alerts to be alerted about any suspicious user activity.
Use the Security Center (included in the Premium tier) to perform more advanced security threat detection. Your Cloud Identity Admin logs should be routed to your security operations team. We’ll dive into security auditing in more depth in Chapter 11. Auditing is a very important aspect of building a secure Cloud.

Additional References
If you’d like more information about the topics discussed in this chapter, check out these sources:
- Cloud Identity product overview https://cloud.google.com/identity
- Security Authentication vs Authorization: What You Need to Know https://towardsdatascience.com/security-authentication-vs-authorization-what-you-need-to-know-b8ed7e0eae74
- Single Sign-On Best Practices for Google Cloud https://www.youtube.com/watch?time_continue=20&v=9-GMVX_OOG0&feature=emb_title