Tag: security

Overview of Customer Identity and Access Management (CIAM)

chdelay

This article is a brief informal introduction to CIAM. This article is intended to level set a deeper and broader discussion on CIAM which will take place in future blog articles.

CIAM differs in many ways from an organizations IAM systems. A subset of these differences are explained below. These differences are mandated by the different requirements for each system. IAM supports an organizations systems and workforce.

Whereas CIAM supports the organization’s customers or clients. IAM is used to control access to internal systems and data much of which is typically sensitive. Therefore, the users that have Identities in IAM must be more thoroughly vetted and inspected. In addition, the users of the internal IAM system rely on access to perform their job functions therefore the process can have more friction then a customer-based system. This is not to say that customers also do not need to be vetted. Customers often need to be vetted for risk or to prove who their actual identity is. However, with CIAM the goal is to remove as much friction as possible and make user actions be as simple as possible. The reason is that with customers you are usually in a state of either maintaining a relationship or in the customer acquisition phase. And any friction especially in the sign-up process can result in customer’s potentially seeking to do business with someone else. In addition, any complicated actions the user must take has the potential to either make them want to do business elsewhere or will require additional support from you, which is typically costly.

There are many other differences between CIAM and IAM. IAM usually needs to support a limited number of users. Even in a large organization the number of users is going to be in the thousands, tens of thousands, or hundreds of thousands. Where the number of customers can potentially be in the millions, the tens of millions, or more. In addition, a company’s application or website is potentially the main way that the customer interacts with the business. Therefore, ensuring customer satisfaction with their interaction with the application including logging-in is of critical importance. CIAM is also a valuable tool for compliance with customer related laws and regulations such as privacy, whereas IAM systems are important for corporate and industry regulation such as SOX or PCI. In addition, due to the nature of the systems the type of authenticators may be more restrictive with IAM to ensure security while with CIAM there may be more flexibility to meet the customer’s needs such as supporting federation with Facebook or Google for AuthN.

CIAM requirements and capabilities 

At its core CIAM is responsible for assigning a digital identity for a customer. CIAM is responsible for providing a reasonably secure way for that customer to authenticate as this identity. And also, of importance is reducing the likelihood that the customer’s credentials can be compromised and protecting the customer’s identity from impersonation attacks.

Also, as part of the primary security responsibilities of CIAM is to protect the customer’s privacy and data. In banking there are some additional responsibilities that may not either be present in other industries or of less significance. These includes going to great lengths to know your customer to comply with financial regulation. Also, since CIAM gates access to a customers finances it is extremely important to inspect in detail the customers interaction with the company’s systems through CIAM to detect attempts to impersonate the user, fraudulent behavior, and the risk level of the customer or potential customer.

Therefore, in banking CIAM should either handle these activities or securely connect to systems that can. Then depending on the feedback from these systems be able to gate access.

In addition, CIAM is going to perform authentication and potentially maintain state for other resources that may be called when the customer is interacting with the company’s systems. This includes pulling account information from a database, feeding, or receiving information from CRM, notification systems, and any other systems that the user will directly or indirectly come in contact while interacting with the company’s systems.

Then there are customer journeys that are primarily driven through CIAM. These includes tasks such as resetting a password, attaching an authenticator such as a passkey, updating the user’s email, updating the user’s profile, alerting customer of potentially fraudulent behavior taken on their accounts, and letting the customer flag fraudulent behavior. Many of these more identity related tasks should be native to the CIAM, others such as notifications, or updating profiles may require integration with other systems.

In many ways CIAM is the glue that pieces all of the systems that a user may interact with together. Because typically all experiences are essentially going to begin with a login and potentially end with a logout. So, not only should CIAM be fully capable as an Identity Provider but also be intuitive to use and can interact with disparate systems. Friction should be reduced with CIAM systems. Making it simple for the user to create and maintain an identity. Using authenticators that the customer is familiar with whether that be passkeys, or federation with a 3rd party IDP such as Facebook, Google, Microsoft, or Apple. User Identity related actions such as adding passkey, MFA, or resetting a password should be simple and easily understandable to even the most non-technical customer.

Specific requirements 

So, I have spoken in more conceptual way about CIAM. To help you understand actual requirements for CIAM in a more deliberate and detailed way here is a detailed list of common requirements that are often required of CIAM.

  •   Centralize authentication, authorization, identity, and credential management for customers
  •   Support of modern AuthN and AuthZ protocols including SAML, OIDC, and Auth 2.
  •   Ability to perform fraud, risk, and threat analysis or the capability to hand the necessary data to 3rd party systems to perform this analysis and act based on the output of this analysis.
  •   The ability to support federation via OpenD or SAML.
  •   The ability to work with a variety of 3rd party IDPs including Microsoft, Google, Facebook, and Apple.
  •   Support customer journeys either natively or by passing key information to 3rd party apps that can implement the customer journeys.
  •   Support of more advanced authentication options including Passkeys, MFA, and passwordless.
  •   Ability to acquire, store, and retrieve key profile information that is required for authentication as well as threat, risk, and fraud analysis. This includes information such as keystrokes, mouse movements, page scrolling, email address, phone number, First and Last Name, address, social security number, and any other pertinent information
  • Support collection, retrieval, and retention for data used to comply with Know your customer (KYC) regulations
  • Ability to store and ask for consent.
  • Ability to store and ask for login and other authentication preferences
  • Ability to manage and secure PIl
  • Support APls wherever possible instead of proprietary code such as SDKs
  • Ability to be hosted in AWS
  • Ability to support multiple regions and multiple availability zones in AWS or Azure

My next blog posting will be more technical where I will discuss CIAM Architecture.

-Christopher

Azure Key Vault, Part 1: What is Azure Key Vault

chdelay

Azure Key Vault Overview

Hello, this blog posting is a high-level description of Azure Key Vault for those looking to sort out exactly what AKV is. This will be followed by postings providing a more detailed description and walk throughs on how to use Azure Key Vault. This blog posting will most likely evolve over time to include updated an expanded information.

What is Azure Key Vaults Purpose?

To increase security you need to limit who knows the private key for a key or certificate, or who knows the secret. Azure Key Vault is the tool used to limit who can access and hence gain knowledge of the keys or secret. Also, since Azure Key Vault lives in Azure it can be accessed over the Azure network which means those keys and secrets can be secured and used across Azure. So, my definition of Azure Key Vault is: A security service that allows secrets, keys, or certificates to be securely access and managed in Azure.

Azure Key Vault Common Uses

What are some common uses for Azure Key Vault? Common scenarios include encryption for Storage Accounts, Azure Disk Encryption, SQL Server Always Encrypted, secrets store for Azure Kubernetes Service. Also, securely storing and accessing keys, certificates, and secrets for Azure App Service. You can also code your application to use Key Vault to secure and securely access keys, secrets, and certificates that are utilized by said application.

Azure Key Vault Standard vs Azure Key Vault Premium

This website has more information on Azure Key Vault and other Microsoft key management solutions: How to choose the right key management solution – How to choose between Azure Key Vault, Azure Managed HSM, Azure Dedicated HSM, and Azure Payment HSM | Microsoft Learn

The main differences between Standard and Premium is higher level of FIPS compliance with Premium and that Premium uses an HSM to protect keys.

Keys, Certificates, and Secrets

Many services leverage keys, certificates, or secrets for security. Keys and certificates can be used for authentication or encryption.

Secrets

Secrets can be leveraged for authentication. A secret is just a string of characters that is kept private or secret.  One example of a secret is a password. An application or identity provider knows the secret that is used to authenticate a user, unlock an application, or decrypt data. And that secret is inputted into the application and if it matches the secret the application or identity provider is expecting you get authenticated or unencrypt the data. A secret can be thought of as a symmetric key.

Keys

Keys and certificates are kinda similar in that a certificate has keys, it’s just the public key and hence the private key are bound to a digital document called a certificate. The certificate includes additional information used for a number of purposes, but the main purpose of the certificate is to include a digital identity such as a person, services, computer, and so on. In that way the keys can be used as proof of ownership of that identity. So, keys and certificate in terms of Azure Key Vault are a asymmetric keys. Meaning there is a public/private key pair. And hence Keys are going to use Public Key Algorithms such as RSA.

Certificates

Certificates are a digital document that binds and identity to a public key. So, certificates have keys, asymmetric keys. So, like keys which is covered above, the private key needs to be protected. That means that the key must not only be protected from export, but also that processes that use that key are protected so that the keys are protected. Such operations are encryption and signing.

Secrets, Keys, and Certificates Summary

So, to summarize the previous paragraph keys, certificates, and secrets can be used to access an application, service, or data.

Azure Key Vault Access

Permissions

Access to Secrets, Keys, and Certificates are restricted by permissions on the Key Vault and the Keys, Secrets, and Certificates themselves. This permissioning can follow and RBAC model or more of an ad hoc model where individual permissions are given. There are a number of pre-defined RBAC roles that can be used to provision access.

Network Security

Network Access to the key vault can be restricted. You can have access wide open, disable network access, or restrict what networks have access to the key vault.  You can also restrict access to Private Endpoints.

Summary of Access

So, at the Key Vault level you can protect the key vault by restricting what networks have access to the Key Vault. Also, at the Key Vault you can use access control to limit who has access to the Key Vault. At the Secret, Key, or Certificate level you can use access control to limit access. Role assignments are inherited from the Key Vault level to the Secrets, Keys, and Certificates level.

Monitoring

Alerts

You can setup alerts so that when certain thresholds are reached or certain events happen that an action is taken such as an email alert or app notification.

Metrics

Similar to performance monitor in Windows you can setup monitors to view when certain thresholds are reached via a graph that is generated.

Diagnostic Settings

You can configure where you want the logs generated by AKV to be sent for collection.

Logs

Logs are sent to Log Analytics, however, this must be configured. Once logs are sent to Log Analytics you can use tools like KQL and Workbooks to report on the collected data.

Insights

Insights are pre-defined graphs and tables. These are data sets that Microsoft feels are important and relevant in terms of monitoring AKV and AKV usage.

Workbooks

Workbooks are used to summarize and report on logs sent to Log Analytics.

Conclusion

This posting was a high-level definition of Azure Key Vault. Next blog posting will be a more in-depth description of Azure Key Vault for those looking for more technical details.