Chapter 5: Effective Strategies to Implement IAM Solutions

From Chapter 2, Securing Compute Services, to Chapter 4, Securing Network Services, we covered the fundamental building blocks of cloud services (from compute and storage to networking services).

However, we cannot talk about cloud services without also discussing identity management.

In this chapter, we will cover various concepts of identity management – from traditional directory services (based on the Kerberos protocol in the Microsoft environment, LDAP-based directory services, popular in non-Microsoft environments, and even Linux-based directory services) to modern directory services (based on the SAML or OAuth protocols) – and, finally, we will understand how to secure authentication mechanisms based on Multi-Factor Authentication (MFA).

In this chapter, we will cover the following topics:

  • Introduction to IAM
  • Failing to manage identities
  • Securing cloud-based IAM services
  • Securing directory services
  • Configuring MFA

Technical requirements

For this chapter, you are required to have a solid understanding of identity management and concepts such as Active Directory (AD), the Kerberos protocol, SAML versus OAuth 2.0, and MFA.

Following is a sample diagram which depicts the SAML authentication flow:

Figure 5.1 – Example of the SAML authentication flow to the Office 365 service

Figure 5.1 – Example of the SAML authentication flow to the Office 365 service

Now that you are aware of the basic concepts needed for the chapter, let's dive into the details.

Introduction to IAM

Identity and Access Management (IAM) refers to the concept of managing the entire user life cycle, including provisioning (that is, account creation), assigning permissions, and, finally, account deprovisioning (that is, when a person leaves the organization, or the account is no longer necessary).

Access management is made up of the following main concepts:

  • Identity: This indicates a user, computer, service, or role that wishes to access a system or application and take actions (from accessing shared storage to querying a database and pulling information).
  • Authentication: This is the process of proving that a specific identity (such as a user) is who they claim to be (for example, providing a username and password that match the user's records on a central user repository).
  • Authorization: This is the process of granting an authenticated identity (such as a user) the permissions to take actions on a resource (such as allowing a user to upload a file to shared storage).

Cloud providers take a different approach to IAM:

  • AWS IAM: By default, all requests are implicitly denied.
  • Azure Active Directory (Azure AD): By default, users have a minimal set of permissions in which to access resources.
  • GCP: By default, service accounts have permission to call Google Cloud APIs.

The most common directory service deployed on most organizations' on-premises data centers is Microsoft AD. This is a central repository for storing objects such as user accounts, computer accounts, groups, and more.

The most used protocol when working on-premises on traditional Windows applications or services is the Kerberos protocol.

For more information, please refer to the following resources:

  • AWS IAM – Determining whether a request is allowed or denied within an account:

https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_evaluation-logic.html#policy-eval-denyallow

  • What are the default user permissions in Azure Active Directory?:

https://docs.microsoft.com/en-us/azure/active-directory/fundamentals/users-default-permissions

  • GCP's default service accounts:

https://cloud.google.com/iam/docs/service-accounts#default

  • What Active Directory is:

https://en.wikipedia.org/wiki/Active_Directory

  • What the Kerberos protocol is:

https://en.wikipedia.org/wiki/Kerberos_(protocol)

Failing to manage identities

Before we move on to Identity Management (IdM), let's look at a few examples of failing to manage identities:

  • A new employee has joined the organization. Since we do not have a documented and automated IdM workflow, the employee's permissions were copied from a system administrator's profile. The new employee was not aware of which sites they should browse on the internet, and, as result, they were infected by ransomware. This, in turn, infected the sales database, which was encrypted, and caused downtime for the sales division.
  • An employee was able to create an easy-to-guess password (because a complex password policy was not enforced at the organization level), and, as a result, a hacker was able to guess the employee's password and gain access to a confidential financial report.
  • An employee has changed their role in the organization, from IT to the development team, and we forgot to update their privileges on the production servers. As a result, the employee is now over-privileged, and they can access and make changes to the production system.
  • An employee has left the organization, and we forgot to disable their account. As a result, the employee had access to the corporate CRM system through a VPN, which he used to export the contact details of customers so that he could sell the products of his new employer.

Securing cloud-based IAM services

Each cloud provider has its own implementation of managed IAM services, in other words, a service for managing authentication and authorization requests.

Here is a list of AWS IAM terminology:

  • IAM user: This is a person or application with permission to access AWS resources. An IAM user has credentials (such as a password, access keys, and MFA).
  • IAM group: This refers to a group of IAM users to make the permissions management task easier.
  • IAM role: This indicates an identity that has permission to access resources without any credentials. Usually, you assign an IAM role to an IAM group, IAM user, or a service account that requires temporary permissions.
  • Service account: This refers to a special type of IAM user, and its purpose is to allow applications to have access to resources.
  • IAM policy: This is a JSON-based definition that sets the permissions for accessing AWS resources. There are two types of IAM policies:
    • Identity-based policies: This is attached to a user, group, or role.
    • Resource-based policies: This is attached to the AWS resource (for example, the Amazon S3 bucket).
  • Identity provider: This refers to the ability to manage identities outside of AWS while still being able to grant access to AWS resources to the external identities (such as a federation between AWS and Azure AD).
  • AWS IAM policy evaluation logic:
    • Identity-based policies with resource-based policies: The result of both policies is the total permissions for both policies.
    • Identity-based policies with permissions boundaries: The result of identity-based policies with the restrictions from permissions boundaries becomes the effective permissions.
    • Identity-based policies with AWS Organizations service control policies: The result of both policies (for the account member of the organization) becomes the effective permissions.

Securing AWS IAM

AWS IAM is the Amazon-managed IAM service.

Best practices for securing AWS IAM

The following is a list of best practices:

  • Disable and remove all access keys and secret access keys from the AWS account root user.
  • Configure a strong password for the AWS account root user.
  • Enable MFA for the AWS account root user.
  • Avoid using the AWS account root user. Instead, create a random password for the AWS root account, and in the rare scenarios where a root account is required, reset the root account password.
  • Create an IAM user with a full IAM admin role to only the AWS console, to manage the AWS account.
  • Enable MFA for any IAM user with a full IAM admin role.
  • Avoid creating access keys and secret access keys for an IAM user with a full IAM admin role.
  • Create IAM users with IAM policies according to the principle of least privilege.
  • Create IAM groups, assign permissions to the groups, and add IAM users to those groups for easier account and permission management.
  • For limited user access, create custom-managed policies and assign the custom policies to a group of users.
  • Configure a password policy (which includes the minimum and maximum password age, the minimum password length, and enforces the use of password history and complex passwords).
  • Use IAM roles to allow applications that are deploying on EC2 instances access to AWS resources.
  • Use IAM roles instead of creating access keys and secret access keys to allow temporary access to resources rather than permanent access.
  • Avoid embedding access keys and secret access keys inside your code. Instead, use secret management solutions such as AWS Secrets Manager to store and retrieve access keys.
  • Rotate access keys periodically to avoid key abuse by malicious internal or external users.
  • For highly sensitive environments or resources, set an IAM policy to restrict access based on conditions such as data, time, MFA, and more.
  • For highly sensitive environments or resources, set an IAM policy to only allow access to users with MFA enabled.
  • Use the AWS IAM AssumeRole capability to switch between multiple AWS accounts using the same IAM identity.
  • Use IAM permissions boundaries to restrict IAM user access to specific AWS resources.

For more information, please refer to the following resources:

Security best practices in IAM:

https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html

Best practices for managing AWS access keys:

https://docs.aws.amazon.com/general/latest/gr/aws-access-keys-best-practices.html

AWS: Allows access based on date and time:

https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_examples_aws-dates.html

AssumeRole:

https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html

Permissions boundaries for IAM entities:

https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_boundaries.html

Policy evaluation logic:

https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_evaluation-logic.html#policy-eval-basics

Auditing AWS IAM

AWS allows you to monitor the AWS IAM using the following built-in services:

  • Amazon CloudWatch: This is a service that allows you to have AWS CloudTrail audit logs and create alarms when a log passes a certain threshold; for example, after multiple failed logins.
  • AWS CloudTrail: This is a service that allows you to audit actions done by either the AWS account root user or by any IAM user.
  • Amazon GuardDuty: This is a service that uses machine learning to detect and alert you about identity misuse (based on the AWS CloudTrail logs).

Best practices for auditing AWS IAM

The following is a list of best practices:

  • Enable AWS CloudTrail on all AWS regions.
  • Limit the level of access to the CloudTrail logs to a minimum number of employees – preferably to those with an AWS management account, outside the scope of your end users (including outside the scope of your IAM users), to avoid possible deletion or changes to the audit logs.
  • Use Amazon GuardDuty to audit the AWS account root user activity.
  • Use AWS CloudTrail to audit IAM user activities.
  • Use IAM credential reports to locate users that haven't logged in for a long period of time.
  • Use an IAM policy simulator to check what the effective permissions for a specific IAM user are (that is, whether they are allowed or denied access to resources).
  • Use AWS IAM Access Analyzer to detect unused permissions (from both your AWS account and cross-accounts) and fine-tune the permissions to your AWS resources.
  • Use AWS IAM Access Analyzer to detect secrets that can be accessed from outside your AWS account and are stored inside the AWS Secrets Manager service.
  • Use the IAMCTL tool to compare IAM policies between IAM user accounts to detect any changes (for example, by comparing template IAM user policies with one of your other IAM users).

For more information, please refer to the following resources:

AWS security audit guidelines:

https://docs.aws.amazon.com/general/latest/gr/aws-security-audit-guide.html

Logging IAM and AWS STS API calls with AWS CloudTrail:

https://docs.aws.amazon.com/IAM/latest/UserGuide/cloudtrail-integration.html

Monitor and control actions taken with assumed roles:

https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp_control-access_monitor.html

GuardDuty IAM finding types:

https://docs.aws.amazon.com/guardduty/latest/ug/guardduty_finding-types-iam.html

AWS IAM access analysis features:

https://aws.amazon.com/iam/features/analyze-access/

Automate resolution for IAM Access Analyzer cross-account access findings on IAM roles:

https://aws.amazon.com/blogs/security/automate-resolution-for-iam-access-analyzer-cross-account-access-findings-on-iam-roles/

Discover, review, and remediate unintended access to Secrets Manager secrets using IAM Access Analyzer:

https://aws.amazon.com/about-aws/whats-new/2021/01/discover-review-remediate-unintended-access-secrets-manager-iam-access-analyzer/

Getting credential reports for your AWS account:

https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_getting-report.html

Testing IAM policies with the IAM policy simulator:

https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_testing-policies.html

New IAMCTL tool compares multiple IAM roles and policies:

https://aws.amazon.com/blogs/security/new-iamctl-tool-compares-multiple-iam-roles-and-policies/

Summary

In this section, we learned how to secure Amazon IAM based on the AWS infrastructure. We examined how to protect the AWS account root user, access keys management, set password policies, audit user activities, and detect unused or over-privileged accounts.

Securing Azure AD

Azure AD is the Azure-managed directory service.

Azure AD supports the following types of identity models:

  • Cloud-only identity: The user account is created inside the Azure AD tenant and only exists in the cloud (where access to on-premises is not required).
  • Hybrid identity: The user account exists in both the Azure AD tenant and on-premises.

Here is a list of Azure AD terminology:

  • User: This is a person or application with permission to access Azure resources. A user has credentials (such as a password or MFA).
  • Group: This is a group of users to make the permissions management task easier.
  • Azure role-based access control (RBAC): This is an authorization system with built-in permissions to access Azure resources (for example, Owner, Contributor, Reader, and more).

Best practices for securing Azure AD

The following is a list of best practices:

  • Configure a strong password for the original Azure AD global administrator account.
  • Enable MFA for the original Azure AD global administrator account.
  • Avoid using the original Azure AD global administrator account – keep the user's password in a secured location.
  • Create an Azure AD user with a global administrator role for the purpose of managing the Azure AD.
  • Enable MFA for any user in your Azure AD (such as a global administrator role).
  • Limit the number of global administrators to less than five.
  • Use Azure RBAC to grant minimal permissions required for users to be able to access and use Azure resources.
  • Enable the Azure AD Privileged Identity Management (PIM) service in your Azure AD to control just-in-time access to manage Azure AD resources.
  • Create Azure AD groups, assign permissions to the groups, and add users to those groups for easier account and permission management.
  • Configure a password policy (which includes the minimum and maximum password age, the minimum password length, and enforces the use of password history and complex passwords).
  • Create an emergency account (these are special user accounts that shouldn't be used daily, have MFA enabled, and are a member of the global administrator role) to avoid getting locked out of your Azure AD.
  • Use a conditional access policy to enforce the use of MFA and enforce the location from which a global administrator can have access to log in and manage your Azure AD (such as your office network).

For more information refer to the following resources:

  • Microsoft 365 identity models and Azure Active Directory:

https://docs.microsoft.com/en-us/microsoft-365/enterprise/about-microsoft-365-identity?view=o365-worldwide

  • Classic subscription administrator roles, Azure roles, and Azure AD roles:

https://docs.microsoft.com/en-us/azure/role-based-access-control/rbac-and-directory-admin-roles#azure-roles

  • Elevate access to manage all Azure subscriptions and management groups:

https://docs.microsoft.com/en-us/azure/role-based-access-control/elevate-access-global-admin

  • What is Azure AD Privileged Identity Management?:

https://docs.microsoft.com/en-us/azure/active-directory/privileged-identity-management/pim-configure

  • Overview of role-based access control in Azure Active Directory:

https://docs.microsoft.com/en-us/azure/active-directory/roles/custom-overview

  • Best practices for Azure AD roles:

https://docs.microsoft.com/en-us/azure/active-directory/roles/best-practices

  • Password policies and account restrictions in Azure Active Directory:

https://docs.microsoft.com/en-us/azure/active-directory/authentication/concept-sspr-policy

  • Manage emergency access accounts in Azure AD:

https://docs.microsoft.com/en-us/azure/active-directory/roles/security-emergency-access

  • Plan an Azure Active Directory Multi-Factor Authentication deployment:

https://docs.microsoft.com/en-us/azure/active-directory/authentication/howto-mfa-getstarted

Auditing Azure AD

Azure AD has audit logs which can provide an overview of different system activities to ensure compliance.

Best practices for auditing Azure AD

Here are the best practices for auditing Azure AD:

  • Use Azure AD Identity Protection to detect any potential vulnerability activities of your Azure AD users and send the audit logs to your SIEM system.
  • Use Azure AD reports to detect risky users or risky sign-in events.
  • Use Azure AD audit logs to review and detect events in your Azure AD (such as changes to users or groups, sign-in events, and more).
  • Send your Azure AD activity logs to the Azure Monitor service for further analysis.
  • Limit the level of access to Azure Monitor service data to a minimum number of employees, to avoid possible deletion or changes to the audit logs.
  • If you use the Azure AD PIM service in your Azure AD, create access reviews to detect who used PIM to request high privilege to carry out actions.
  • For hybrid environments (that is, an on-premises Active Directory connected to Azure AD), use Microsoft Defender for Identity to detect suspicious activities in your on-premises Active Directory.

For more information refer to the following resources:

What is Identity Protection?:

https://docs.microsoft.com/en-us/azure/active-directory/identity-protection/overview-identity-protection

What is Microsoft Defender for Identity?:

https://docs.microsoft.com/en-us/defender-for-identity/what-is

What are Azure Active Directory reports?:

https://docs.microsoft.com/en-us/azure/active-directory/reports-monitoring/overview-reports

Audit logs in Azure Active Directory:

https://docs.microsoft.com/en-us/azure/active-directory/reports-monitoring/concept-audit-logs

Analyze Azure AD activity logs with Azure Monitor logs:

https://docs.microsoft.com/en-us/azure/active-directory/reports-monitoring/howto-analyze-activity-logs-log-analytics

Create an access review of Azure resource and Azure AD roles in PIM:

https://docs.microsoft.com/en-us/azure/active-directory/privileged-identity-management/pim-how-to-start-security-review

Summary

In this section, we learned how to secure Azure AD based on the Azure infrastructure. We examined how to protect privileged accounts, set password policies, and audit user activities to detect suspicious user behavior.

Securing Google Cloud IAM

Google Cloud IAM is the Google-managed IAM service.

Here is a list of Google Cloud IAM terminology:

  • Member: This is a Google account (for example, a user), a service account (for applications and virtual machines), or Cloud Identity with access to GCP resources.
  • User: This is a person or application (a service account) with permissions to access GCP resources. A user has credentials (such as a password and MFA).
  • Group: This is a group of users to make the permissions management task easier.
  • Role: This refers to a collection of permissions to access resources.
  • Service account: This is a special type of IAM user to allow applications access to resources.
  • IAM policy: This is a JSON-based definition that sets the permissions for accessing GCP resources.

The GCP policy evaluation entails the following:

  • No organization policy set: The default access to resources is enforced.
  • Inheritance: If a resource node has set inheritFromParent = true, then the effective policy of the parent resource is inherited.
  • Disallow inheritance: If a resource hierarchy node has a policy that includes inheritFromParent = false, it doesn't inherit the organization policy from its parent.
  • Reconciling policy conflicts: By default, policies are inherited and merged; however, DENY values always take precedence.

Best practices for securing Google Cloud IAM

Here are the best practices for securing Google Cloud IAM:

  • Use Google Workspace to create and manage user accounts.
  • Configure a password policy (which includes the minimum and maximum password age, the minimum password length, and enforces the use of password history and complex passwords) from within your Google Workspace admin console.
  • Enable MFA for any user with high privileges in your Google Cloud (such as the GCP project owner role).
  • Create IAM groups, assign permissions to the groups, and add users to those groups for easier account and permission management.
  • Use service accounts to grant applications minimal access to Google Cloud resources.
  • Create a dedicated service account for each application.
  • For scenarios where you only need an application to access resources for a short amount of time, use short-lived service account credentials.
  • Disable unused service accounts.
  • Use Google Managed Service accounts for services (such as Google Compute Engine) that require access to Google resources (such as Google Cloud Storage).
  • Use role recommendations using IAM Recommender to enforce minimal permissions to Google resources.
  • Limit the use of service account keys, or avoid them completely, to avoid having to expose access to your Google Cloud resources from outside your GCP environment.
  • Use IAM conditions to enforce the location from which a user can access resources in your Google Cloud environment (such as your office network).
  • Use the policy simulator to determine the effect of a policy on your users.

For more information, please refer to the following resources:

An overview of Google Cloud IAM:

https://cloud.google.com/iam/docs/overview#concepts_related_identity

Understanding hierarchy evaluation:

https://cloud.google.com/resource-manager/docs/organization-policy/understanding-hierarchy#hierarchy_evaluation_rules

Enforce and monitor password requirements for users:

https://support.google.com/a/answer/139399

Using IAM securely:

https://cloud.google.com/iam/docs/using-iam-securely

Achieve least privilege with less effort using IAM Recommender:

https://cloud.google.com/blog/products/identity-security/achieve-least-privilege-with-less-effort-using-iam-recommender

Policy Simulator:

https://cloud.google.com/iam/docs/understanding-simulator

Best practices for securing service accounts:

https://cloud.google.com/iam/docs/best-practices-for-securing-service-accounts

Restricting service account usage:

https://cloud.google.com/resource-manager/docs/organization-policy/restricting-service-accounts

Creating short-lived service account credentials:

https://cloud.google.com/iam/docs/creating-short-lived-service-account-credentials

Overview of IAM Conditions:

https://cloud.google.com/iam/docs/conditions-overview

Google-managed service accounts:

https://cloud.google.com/compute/docs/access/service-accounts#google-managed_service_accounts

Auditing Google Cloud IAM

Google allows you to monitor the Google Cloud IAM using Google Cloud Logging.

Best practices for auditing Google Cloud IAM

Here are the best practices for auditing Google Cloud IAM:

  • Enable Cloud IAM audit logs for further log analysis, such as tracking failed Active Directory logins.
  • Admin activity audit logs are enabled by default and cannot be disabled.
  • Explicitly enable Data access audit logs to log activities performed on Google Cloud IAM.
  • Limit the level of access to the audit logs to a minimum number of employees, to avoid possible deletion or changes to the audit logs using IAM roles.
  • Use Policy Analyzer to determine which identity (for example, a user or a service account) has access to which Google Cloud resource and the type of access.
  • Use service account insights to identify unused service accounts and service account keys.

For more information, please refer to the following resources:

IAM audit logging:

https://cloud.google.com/iam/docs/audit-logging

Analyzing IAM policies:

https://cloud.google.com/asset-inventory/docs/analyzing-iam-policy

Monitoring usage patterns for service accounts and keys:

https://cloud.google.com/iam/docs/service-account-monitoring

Manage service account insights:

https://cloud.google.com/iam/docs/manage-service-account-insights

Summary

In this section, we learned how to secure Google Cloud IAM based on the GCP infrastructure. We examined how to protect privileged accounts, set password policies, manage and work with service accounts, and audit user and service account activities.

Securing directory services

Each cloud provider has its own implementation of a managed Active Directory service. This service allows you to centrally manage your user and computer identities, join Windows machines to the Active Directory domain, set password policies (such as the password length, password complexity, and more), and control access to traditional resources (such as Windows file shares, SQL servers, IIS servers, and more).

It is important to note that as a customer, you always have the option to deploy Active Directory domain controllers based on virtual machines and maintain them yourself, as organizations are doing on-premises (this is also known as a self-hosted solution). However, the goal of this book is to show you how things are done using managed services, where, as a customer, you can focus on consuming the IAM service (that is, authenticate and create identities and then grant them permissions) without having to maintain servers (such as availability, patch management, backups, and more).

In the next section, we are going to examine what the best practices are for securing managed directory services from AWS, Azure, and GCP.

Securing AWS Directory Service

AWS Directory Service is the Amazon-managed Active Directory service.

Best practices for securing AWS Directory Service

The following is a list of best practices:

  • Configure a password policy (which includes the minimum and maximum password age, the minimum password length, and enforces the use of password history and complex passwords).
  • Configure an account lockout policy (including the number of failed login attempts, the account lockout duration, and whether to allow a reset of the account lockout after a certain amount of time).
  • To avoid using a privileged account for a password reset, use the AWS Delegated Fine Grained Password Policy Administrators group to allow your support team permission to reset passwords.
  • Use MFA for accounts with high privileges to manage the AWS Directory Service using a RADIUS server.
  • Create Active Directory groups, add users to the groups, and grant permissions over resources (such as access to files servers, login servers, and more) to groups instead of granting permissions to specific users.
  • Use VPC security groups to restrict access from your EC2 instances to your AWS Directory Service domain controllers.
  • Use a complex password for the built-in admin account of your AWS Directory Service.

For more information, please refer to the following resources:

Secure your AWS Managed Microsoft AD directory:

https://docs.aws.amazon.com/directoryservice/latest/admin-guide/ms_ad_security.html

Best practices for AWS Managed Microsoft AD:

https://docs.aws.amazon.com/directoryservice/latest/admin-guide/ms_ad_best_practices.html

Security in AWS Directory Service:

https://docs.aws.amazon.com/directoryservice/latest/admin-guide/security.html

New whitepaper – Active Directory Domain Services on AWS:

https://d1.awsstatic.com/whitepapers/adds-on-aws.pdf

Best practices for monitoring AWS Directory Service

AWS allows you to monitor AWS Directory Service using the following built-in services:

  • Amazon CloudWatch: This service allows you to monitor your AWS Directory Service logs.
  • AWS CloudTrail: This service allows you to audit API actions done through the AWS Directory Service console, SDK, or command line interface (CLI).

Here are the best practices:

  • Enable AWS Directory Service log forwarding and forward the Active Directory logs to Amazon CloudWatch for further Active Directory log analysis, such as tracking failed Active Directory logins.
  • Use AWS CloudTrail to audit a user's activity inside the AWS Directory Service using an API.

For more information, please refer to the following resources:

Enable log forwarding:

https://docs.aws.amazon.com/directoryservice/latest/admin-guide/ms_ad_enable_log_forwarding.html

How to monitor and track failed logins for your AWS Managed Microsoft AD:

https://aws.amazon.com/blogs/security/how-to-monitor-and-track-failed-logins-for-your-aws-managed-microsoft-ad/

Logging AWS Directory Service API Calls with CloudTrail:

https://docs.aws.amazon.com/directoryservice/latest/devguide/cloudtrail_logging.html

Summary

In this section, we learned how to secure AWS Directory Service based on the AWS infrastructure. We examined how to set password policies, configure permissions, network access, and, finally, monitor and audit Active Directory.

Securing Azure Active Directory Domain Services (Azure AD DS)

Azure AD DS is the Azure-managed Active Directory service.

Best practices for securing Azure AD DS

The following is a list of best practices:

  • Configure a password policy (which includes the minimum and maximum password age, the minimum password length, and enforces the use of password history and complex passwords).
  • Configure an account lockout policy (including the number of failed login attempts, the account lockout duration, and whether to allow a reset of the account lockout after a certain amount of time).
  • Disable the use of vulnerable protocols such as Windows New Technology LAN Manager (NTLM).
  • Disable the use of weak password encryption using the RC4 algorithm.
  • Enforce the use of TLS 1.2 transport encryption.
  • Enable the use of the Kerberos armoring capability to protect the traffic flowing between the client and the domain controllers.
  • If you have a requirement to allow impersonation on behalf of another user to access resources (for example, an application that needs access to a file server), enable the use of Kerberos constrained delegation (KCD).
  • Use Azure network security groups to restrict access from your virtual machines to your Azure AD DS.
  • Use MFA for accounts with high privileges to manage the Azure AD DS service.
  • Use a complex password for the built-in global administrator account of your Azure AD.
  • If you have a requirement to allow access to legacy applications deployed on-premises from the internet, use Azure AD Application Proxy together with Azure AD DS.

For more information, please refer to the following resources:

Harden an Azure Active Directory Domain Services managed domain:

https://docs.microsoft.com/en-us/azure/active-directory-domain-services/secure-your-domain

Configure Kerberos constrained delegation (KCD) in Azure Active Directory Domain Services:

https://docs.microsoft.com/en-us/azure/active-directory-domain-services/deploy-kcd

Azure security baseline for Azure Active Directory Domain Services:

https://docs.microsoft.com/en-us/security/benchmark/azure/baselines/aad-ds-security-baseline

Deploy Azure AD Application Proxy for secure access to internal applications in an Azure Active Directory Domain Services managed domain:

https://docs.microsoft.com/en-us/azure/active-directory-domain-services/deploy-azure-app-proxy

Best practices for monitoring Azure AD DS

Azure allows you to send Azure AD DS audit logs to the following destinations:

  • Azure Storage: This is for archive purposes only.
  • Azure Event Hubs: This is for sending audit logs to an external SIEM system for further analysis.
  • Azure Log Analytics Workspace: This is for further analysis from within the Azure portal.

Here are the best practices:

  • Enable Azure AD DS auditing and select where to store the audit logs (for example, Azure Storage, Azure Event Hubs, or the Azure Log Analytics Workspace).
  • If you chose to send Azure AD DS audit logs to the Azure Log Analytics Workspace, use the Azure Monitor service to query the logs (such as failed logins, account lockouts, and more).

For more information, please refer to the following resource:

Enable security audits for Azure Active Directory Domain Services:

https://docs.microsoft.com/en-us/azure/active-directory-domain-services/security-audit-events

Summary

In this section, we learned how to secure Azure AD DS, based on Azure infrastructure. We examined how to set password policies, configure permissions, network access, and, finally, monitor and audit Active Directory.

Securing Google Managed Service for Microsoft AD

Google Managed Service for Microsoft AD is the GCP-managed Active Directory service.

Best practices for securing Google Managed Service for Microsoft AD

The following is a list of best practices:

  • Deploy Google Managed Microsoft AD in a shared VPC to allow access from multiple GCP projects to Active Directory.
  • Configure a password policy (which includes the minimum and maximum password age, the minimum password length, and enforces the use of password history and complex passwords).
  • Configure an account lockout policy (including the number of failed login attempts, the account lockout duration, and whether to allow a reset of the account lockout after a certain amount of time).
  • To avoid using a privileged account for a password reset, use the Compute Instance Admin role to allow your support team permission to reset passwords.
  • Create Active Directory groups, add users to the groups, and grant permissions over resources (such as access to files servers, login servers, and more) to those groups instead of granting permissions to specific users.
  • Use VPC firewall rules to restrict access from your virtual machine instances to your Managed Microsoft AD domain controllers.
  • Use authorized networks to control which VPC networks are allowed to access your Managed Microsoft AD.
  • For large-scale environments with multiple GCP projects, use VPC Service Controls to enforce access restrictions to your Managed Microsoft AD based on the identity of the IP address.
  • Use a complex password for the built-in admin account of your Managed Microsoft AD.

For more information, please refer to the following resources:

Best practices for running Active Directory on Google Cloud:

https://cloud.google.com/managed-microsoft-ad/docs/best-practices

Managed Service for Microsoft AD:

https://cloud.google.com/managed-microsoft-ad/docs/how-to

Managing authorized networks:

https://cloud.google.com/managed-microsoft-ad/docs/managing-authorized-networks

Accessing Managed Microsoft AD from within your VPC:

https://cloud.google.com/managed-microsoft-ad/docs/firewalls#accessing_from_within_your_vpc

Using VPC Service Controls:

https://cloud.google.com/managed-microsoft-ad/docs/how-to-use-vpc-service-controls

Best practices for monitoring Google Managed Service for Microsoft AD

Google allows you to monitor the Google Managed Microsoft AD using Google Cloud Logging.

The following is a list of best practices:

  • Enable Managed Microsoft AD audit logs for further Active Directory log analysis, such as tracking failed Active Directory logins.
  • Admin activity audit logs are enabled by default and cannot be disabled.
  • Explicitly enable Data access audit logs to log activities performed on Google Managed Microsoft AD.
  • Limit the level of access to the audit logs to a minimum number of employees, to avoid possible deletion or changes to the audit logs, using IAM roles.

For more information, please refer to the following resources:

Using Cloud Audit Logs for Managed Microsoft AD:

https://cloud.google.com/managed-microsoft-ad/docs/audit-logging

Using Managed Microsoft AD Audit Logs:

https://cloud.google.com/managed-microsoft-ad/docs/using-ad-audit-logs

Summary

In this section, we learned how to secure Google Managed Microsoft AD based on the GCP infrastructure. We examined how to set password policies, configure permissions, network access, and, finally, monitor and audit Active Directory.

Configuring MFA

Each cloud provider has its own mechanism to enforce the use of MFA to protect authentication attempts against potential account breaches.

Best practices for configuring MFA using AWS IAM

The following is a list of best practices:

  • Enable MFA on the AWS account root user.
  • Enable MFA on any IAM user with high privileges to the AWS console (such as an admin role).
  • Enable MFA for AWS console access and so that users must authenticate themselves using MFA before programmatically calling for API access requests.
  • For non-sensitive environments, use a virtual MFA device (such as Google Authenticator) for better protection of your IAM users' access.
  • For sensitive environments, use a hardware MFA device or U2F security key (such as Yubikey).
  • Avoid using SMS as part of MFA (due to vulnerabilities in the SMS protocol).

For more information, please refer to the following resources:

Using multi-factor authentication (MFA) in AWS:

https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_mfa.html

Enabling a virtual multi-factor authentication (MFA) device (console):

https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_mfa_enable_virtual.html

Enabling MFA devices for users in AWS:

https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_mfa_enable.html

Configuring MFA-protected API access:

https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_mfa_configure-api-require.html

Multi-factor Authentication:

https://aws.amazon.com/iam/features/mfa/

Best practices for configuring MFA using Azure Active Directory

The following is a list of best practices:

  • Enable MFA on the original global administrator account.
  • Enable MFA on any user with high privileges (such as the global administrator role).
  • Enable a conditional access policy to enforce the use of MFA for any attempts to connect to the Azure portal outside your corporate network.
  • For non-sensitive environments, use the Microsoft Authenticator app for better protection of your Azure AD users' access.
  • For sensitive environments, use a hardware MFA device such as FIDO2 security key or Windows Hello.
  • Avoid using SMS as part of MFA (due to vulnerabilities in the SMS protocol).
  • Configure an account lockout when there are multiple failed login attempts using MFA.

For more information, please refer to the following resources:

How it works: Azure AD Multi-Factor Authentication:

https://docs.microsoft.com/en-us/azure/active-directory/authentication/concept-mfa-howitworks

Tutorial: Secure user sign-in events with Azure AD Multi-Factor Authentication:

https://docs.microsoft.com/en-us/azure/active-directory/authentication/tutorial-enable-azure-mfa

Plan an Azure Active Directory Multi-Factor Authentication deployment:

https://docs.microsoft.com/en-us/azure/active-directory/authentication/howto-mfa-getstarted

What authentication and verification methods are available in Azure Active Directory?:

https://docs.microsoft.com/en-us/azure/active-directory/authentication/concept-authentication-methods

Configure Azure AD Multi-Factor Authentication settings:

https://docs.microsoft.com/en-us/azure/active-directory/authentication/howto-mfa-mfasettings

Enable per-user Azure AD Multi-Factor Authentication to secure sign-in events:

https://docs.microsoft.com/en-us/azure/active-directory/authentication/howto-mfa-userstates

Overview of Azure AD Multi-Factor Authentication for your organization:

https://docs.microsoft.com/en-us/azure/active-directory/fundamentals/concept-fundamentals-mfa-get-started

Best practices for configuring MFA using Google Cloud:

GCP doesn't directly control MFA settings since it doesn't create or manage user identities.

Identities in Google Cloud are managed by Google Workspace or Gmail accounts, where you can control the MFA settings before granting the identities account to GCP resources.

The following is a list of best practices for configuring MFA with Google Cloud:

  • Enable MFA on any user with high privileges (such as the GCP project owner role).
  • For non-sensitive environments, use the Google Authenticator app for better protection of your users' access.
  • For sensitive environments, use a hardware MFA device (such as Titan Security Keys).
  • Avoid using SMS as part of MFA (due to vulnerabilities in the SMS protocol).

For more information, please refer to the following resources:

Enforce uniform MFA to company-owned resources:

https://cloud.google.com/identity/solutions/enforce-mfa

Protect your business with 2-Step Verification:

https://support.google.com/a/answer/175197?hl=en

Protect your account with 2-Step Verification:

https://support.google.com/accounts/answer/185839

Deploy 2-Step Verification:

https://support.google.com/a/answer/9176657?hl=en

Summary

In this section, we learned how to configure MFA based on the AWS, Azure, and GCP infrastructures – from software-based MFA to hardware-based MFA devices.

Summary

In this chapter, we focused on the various IAM services in AWS, Azure, and GCP.

We discussed everything from managed Active Directory services to modern IAM services, and, finally, we provided recommendations regarding how to use MFA for extra protection of your identities.

In each section, we reviewed best practices for configuration, account management, monitoring, and auditing.

IdM services allow us to control access to resources and services in our cloud environment. They provide least privilege access to resources and monitor what actions were performed using identities in our cloud environments.

In the next chapter, we will review how to conduct security monitoring and auditing in the cloud (from audit trails and threat detection to digital forensics in the cloud).

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset
18.225.8.35