- GC Cloud Guardrails
- Overview
- Azure Active Directory Required Configuration and Recommendations
- Guardrails
- 1. Protect Root / Global Admins Account
- 2. Management of Administrative Privileges
- 3. Cloud Console Access
- 4. Enterprise Monitoring Accounts
- 5. Data Location
- 6. Protection of Data-at-Rest
- 7. Protection of Data-in-Transit
- 8. Segment and Separate
- 9. Network Security Services
- 10. Cyber Defense Services
- 11. Logging and Monitoring
- 12. Configuration of Cloud Marketplaces
As part of the Government of Canada (GC) Cloud Operationalization Framework, the GC has provided a set of minimum guardrails to be implemented within the first 30-days of standing up a cloud environment. From the GC Cloud Guardrails repository:
The purpose of the guardrails is to ensure that departments and agencies are implementing a preliminary baseline set of controls within their cloud-based environments. These minimum guardrails are to be implemented within the GC-specified initial period (e.g. 30 days) upon receipt of an enrollment under the GC Cloud Services Framework Agreement.
This document identifies the key considerations as part of each guardrail and provides information on how an Azure Landing Zones for Canadian Public Sector (ALZCPS) deployment meets (or could meet) each consideration.
Many of the guardrails contain identity and access management requirements. However, configuration of Azure Active Directory (Azure AD) is a prerequisite to deploying a landing zone using the ALZCPS project. Key configuration information is contained within our architecture documentation.
With an appropriately configured Azure AD, 34% of the guardrail considerations are covered.
When configuring your Azure AD tenant, ensure that:
NOTE: Azure AD P1/P2 is required to ingest sign-in logs to Microsoft Sentinel.
To create alerts from sign-in logs, refer to:
- Create, view, and manage log alerts using Azure Monitor
- Microsoft Sentinel: Create custom analytics rules to detect threats
The following features provide native solutions to several guardrails, including:
- Protect Root / Global Admins Account
- Management of Administrative Privileges
- Cloud Console Access
- Enterprise Monitoring Accounts
Consider implementing Azure AD Conditional Access to create fine-tuned access policies with contextual factors such as user, device, location, and real-time risk information to control what a specific user can access, and how and when they have access.
Refer to Plan a Conditional Access deployment to get started.
Consider implementing Azure AD Identity Protection to detect, investigate, and remediate suspicious user and sign-in behavior in your environment.
When configuring Azure AD Identity Protection, ensure that:
- Azure AD Identity Protection alerts are configured
- Azure AD Identity Protection logs are being sent to Log Analytics
- Azure AD Identity Protection logs are being sent to Microsoft Sentinel.
Consider implementing Azure AD Privileged Identity Management (PIM) to provide time-based and approval-based role activation to mitigate the risks of excessive, unnecessary, or misused access to important resources in your organization
When configuring Azure AD PIM, ensure that Azure AD PIM alerts are configured.
Refer to Plan a Privileged Identity Management deployment to get started.
Consider implementing Azure AD Access Reviews to efficiently manage group memberships, access to enterprise applications, and role assignments. User's access can be reviewed on a regular basis to make sure only the right people have continued access.
Refer to Plan an Azure Active Directory access reviews deployment to get started.
Consider enabling User and Entity Behavioral Analytics within Microsoft Sentinel to identify anomalous activity and help you determine if an asset has been compromised (usage fees apply).
The following policies related to identity management are enabled by default in ALZCPS deployments:
- Azure Policy - NIST SP 800-53 Rev. 5 AC-2: Account Management
- Azure Policy - NIST SP 800-53 Rev. 5 AC-2 (1): Automated System Account Management
- Azure Policy - NIST SP 800-53 Rev. 5 AC-3: Access Enforcement
- Azure Policy - NIST SP 800-53 Rev. 5 AC-5: Separation of Duties
- Azure Policy - NIST SP 800-53 Rev. 5 AC-6: Least Privilege
- Azure Policy - NIST SP 800-53 Rev. 4 AC-6 (5): Account Management
- Azure Policy - NIST SP 800-53 Rev. 4 AC-6 (10): Prohibit Non-privileged Users from Executing Privileged Functions
- Azure Policy - NIST SP 800-53 Rev. 4 AC-7: Unsuccessful Logon Attempts
- Azure Policy - NIST SP 800-53 Rev. 4 AC-19: Access Control for Mobile Devices
- Azure Policy - NIST SP 800-53 Rev. 5 IA-2: Identification and Authentication (organizational Users)
- Azure Policy - NIST SP 800-53 Rev. 5 IA-2 (1): Multi-factor Authentication to Privileged Accounts
- Azure Policy - NIST SP 800-53 Rev. 5 IA-2 (2): Multi-factor Authentication to Non-privileged Accounts
- Azure Policy - NIST SP 800-53 Rev. 4 IA-2 (11): Remote Access - Separate Device
- Azure Policy - NIST SP 800-53 Rev. 5 IA-4: Identifier Management
- Azure Policy - NIST SP 800-53 Rev. 5 IA-5: Authenticator Management
- Azure Policy - NIST SP 800-53 Rev. 5 IA-5 (1): Password-based Authentication
- Azure Policy - NIST SP 800-53 Rev. 4 IA-5 (7): No Embedded Unencrypted Static Authenticators
- Azure Policy - NIST SP 800-53 Rev. 4 IA-5 (13): Expiration of Cached Authenticators
- Azure Policy - NIST SP 800-53 Rev. 4 IA-6: Authenticator Feedback
- Azure Policy - NIST SP 800-53 Rev. 4 IA-8: Identification and Authentication (non-organizational Users)
This consideration can be met by appropriately configuring your Azure AD instance. Review the following tutorial: Secure user sign-in events with Azure AD Multi-Factor Authentication
Azure AD Conditional Access is a native solution that can help to meet this consideration.
Multi-factor authentication controls are implemented as listed in ALZCPS Identity Management Policies.
Relevant Links:
1.2 Document a break glass emergency account management procedure. Including names of users with root or master account access.
Documentation exercises are out of scope. GC intranet users can reference the break-glass emergency account procedure document.
Relevant Links:
1.3 Obtain signature from Departmental Chief Information Officer (CIO) and Chief Security Officer (CSO) to confirm acknowledgement and approval of the break glass emergency account management procedures.
Documentation exercises are out of scope. GC intranet users can reference the break-glass emergency account procedure document.
Relevant Links:
This consideration can be met by appropriately configuring your Azure AD instance. Specifically, creating and assigning users to appropriate Azure AD groups and then granting permissions to those groups.
The following native solutions can help to meet this consideration:
Access authorization controls are implemented as listed in ALZCPS Identity Management Policies.
Relevant Links:
- Authorization with Azure AD
- What is Azure role-based access control (Azure RBAC)?
- Steps to assign an Azure role
1.5 Configure appropriate alerts on root/master accounts to detect a potential compromise, in accordance with the GC Event Logging Guidance.
This consideration can be met by appropriately configuring your Azure AD instance. See Azure AD Logging and Monitoring and the GC Event Logging Guidance.
The following native solutions can help to meet this consideration:
Related Links:
- Azure Active Directory Identity Protection notifications
- Identity Protection - How To: Export risk data
2.1 Document a process for managing accounts, access privileges, and access credentials for organizational users, non-organizational users (if required), and processes based on the principles of separation of duties and least privilege (for example, operational procedures and active directory).
Documentation exercises are out of scope.
The following native solutions can help to meet this consideration:
Relevant Links:
This consideration can be met by appropriately configuring your Azure AD instance. Specifically, creating and assigning users to appropriate Azure AD groups and then granting permissions to those groups.
The following native solutions can help to meet this consideration:
Access authorization controls are implemented as listed in ALZCPS Identity Management Policies.
Relevant Links:
- Authorization with Azure AD
- What is Azure role-based access control (Azure RBAC)?
- Steps to assign an Azure role
2.3 Implement a mechanism for uniquely identifying and authenticating organizational users, non-organizational users (if applicable), and processes (for example, username and password).
This consideration can be met by appropriately configuring your Azure AD instance.
Controls for authenticating organizational users, non-organizational users, and processes are implemented as listed in ALZCPS Identity Management Policies.
Relevant Links:
- Azure Active Directory Authentication management operations reference guide
- B2B collaboration overview (Guest Accounts)
- Application and service principal objects in Azure Active Directory (Apps)
2.4 Implement a multi-factor authentication mechanism for privileged accounts (for example, username, password and one-time password) and for external facing interfaces.
This consideration can be met by appropriately configuring your Azure AD instance. Review the following tutorial: Secure user sign-in events with Azure AD Multi-Factor Authentication
Azure AD Conditional Access is a native solution that can help to meet this consideration.
Multi-factor authentication controls are implemented as listed in ALZCPS Identity Management Policies.
Relevant Links:
This consideration can be met by appropriately configuring your Azure AD instance.
Password controls are implemented as listed in ALZCPS Identity Management Policies.
Relevant Links:
As described in the Microsoft Cloud Adoption Framework design recommendations, there is one custom owner role created:
- Custom - Landing Zone Subscription Owner
However, this is not truly a "subscription owner", as it has limited permissions and is unable to manage RBAC and networking.
Role-related controls are implemented as listed in ALZCPS Identity Management Policies.
This consideration can be met by appropriately configuring your Azure AD instance.
Password controls are implemented as listed in ALZCPS Identity Management Policies.
Relevant Links:
Out of scope.
Relevant Links:
- B2B collaboration overview (Guest Accounts)
2.9 Determine access restrictions and configuration requirements for GC-issued endpoint devices, including those of non-privileged and privileged users, and configure access restrictions for endpoint devices accordingly. Note: Some service providers may offer configuration options to restrict endpoint device access. Alternatively, organizational policy and procedural instruments can be implemented to restrict access.
This consideration can be met by appropriately configuring your Azure AD instance.
The following native solutions can help to meet this consideration:
Access restriction controls are implemented as listed in ALZCPS Identity Management Policies.
3.1 Implement multi-factor authentication mechanism for privileged accounts and remote network (cloud) access.
This consideration can be met by appropriately configuring your Azure AD instance. Review the following tutorial: Secure user sign-in events with Azure AD Multi-Factor Authentication
Azure AD Conditional Access is a native solution that can help to meet this consideration.
Multi-factor authentication controls are implemented as listed in ALZCPS Identity Management Policies.
Relevant Links:
3.2 Determine access restrictions and configuration requirements for GC managed devices, including those of non-privileged and privileged users, and configure access restrictions for endpoint devices accordingly.
This consideration can be met by appropriately configuring your Azure AD instance.
The following native solutions can help to meet this consideration:
Access restriction controls are implemented as listed in ALZCPS Identity Management Policies.
3.3 Ensure that administrative actions are performed by authorized users following a process approved by Chief Security Officer (CSO) (or delegate) and designated official for cyber security. This process should incorporate the use of trusted devices and a risk-based conditional access control policy with appropriate logging and monitoring enabled.
The following native solutions can help to meet this consideration:
For logging and monitoring, see Azure AD Logging and Monitoring.
Access-control controls are implemented as listed in ALZCPS Identity Management Policies.
Relevant Links:
This consideration can be met by appropriately configuring your Azure AD instance. Specifically, creating and assigning users to appropriate Azure AD groups and then granting permissions to those groups.
The following native solutions can help to meet this consideration:
Access authorization controls are implemented as listed in ALZCPS Identity Management Policies.
Relevant Links:
- Authorization with Azure AD
- What is Azure role-based access control (Azure RBAC)?
- Steps to assign an Azure role
This consideration can be met by appropriately configuring your Azure AD instance. Specifically, configuring Azure AD smart lockout or by implementing a passwordless authentication deployment.
Password controls are implemented as listed in ALZCPS Identity Management Policies.
Relevant Links:
- What authentication and verification methods are available in Azure Active Directory?
- Forget passwords, go passwordless
- Plan and deploy on-premises Azure Active Directory Password Protection
- Combined password policy and weak password check in Azure Active Directory
4.1 Assign roles to approved GC stakeholders to enable enterprise visibility. Roles include billing reader, policy contributor/reader, security reader, and global reader.
This consideration can be met by appropriately configuring your Azure AD instance. Specifically, by assigning the appropriate RBAC roles.
Role-related controls are implemented as listed in ALZCPS Identity Management Policies.
Relevant Links:
4.2 Ensure that multi-factor authentication mechanism for enterprise monitoring accounts is enabled.
This consideration can be met by appropriately configuring your Azure AD instance. Review the following tutorial: Secure user sign-in events with Azure AD Multi-Factor Authentication
Azure AD Conditional Access is a native solution that can help to meet this consideration.
Relevant Links:
5.1 As per the Directive on Service and Digital "Ensuring computing facilities located within the geographic boundaries of Canada or within the premises of a Government of Canada department located abroad, such as a diplomatic or consular mission, be identified and evaluated as a principal delivery option for all sensitive electronic information and data under government control that has been categorized as Protected B, Protected C or is Classified."
ALZCPS deployments restrict resource deployments by default to the locations "canadacentral" or "canadaeast".
The following policies related to data location are enabled by default in ALZCPS deployments:
Relevant Links:
6.1 Seek guidance from privacy and access to information officials within institutions before storing personal information in cloud-based environments.
Institutional policy guidance exercises are out of scope.
6.2 Implement an encryption mechanism to protect the confidentiality and integrity of data when data are at rest in your solution's storage.
Most Azure services that support encryption at rest typically support offloading the management of encryption keys to Azure. The Azure resource provider creates the keys, places them in secure storage, and retrieves them when needed. This means that the service has full access to the keys and the service has full control over the credential lifecycle management. However, there are various supported encryption models, including:
- Server-side encryption using Service-Managed keys
- Server-side encryption using customer-managed keys in Azure Key Vault
- Server-side encryption using customer-managed keys in customer-controlled hardware
- Client-side encryption
Refer to this list to see encryption models are supported by each service.
The following policies related to protection of information at rest are enabled by default in ALZCPS deployments:
Relevant Links:
- Azure encryption overview
- Azure Data Encryption at rest
- Azure Storage encryption for data at rest
- Data encryption models
- Azure data security and encryption best practices
6.3 Use CSE-approved cryptographic algorithms and protocols, in accordance with ITSP.40.111 and ITSP.40.062.
Azure provides the ability to use CSE-approved algorithms and protocols. However, policy enforcement is not possible across all use-cases as it is dependant upon the individual application architecture. For example, the default certificate signing algorithm within Azure AD is SHA-256. However, if an application only supports SHA-1, Azure AD can be manually configured to sign SAML responses using SHA-1 for that application.
The following policies related to approved cryptographic algorithms are enabled by default in ALZCPS deployments:
- Azure Policy - NIST SP 800-53 Rev. 4 SC-13: Cryptographic Protection
- Azure Policy - NIST SP 800-53 Rev. 5 SC-28 (1): Cryptographic Protection
Relevant Links:
- ITSP.40.111: Cryptographic Algorithms for UNCLASSIFIED, PROTECTED A, and PROTECTED B Information
- ITSP.40.062: Guidance on Securely Configuring Network Protocols
- Azure encryption overview
Most Azure services that support encryption at rest typically support offloading the management of encryption keys to Azure. The Azure resource provider creates the keys, places them in secure storage, and retrieves them when needed. This means that the service has full access to the keys and the service has full control over the credential lifecycle management. Customer-managed key scenarios are supported within ALZCPS in the Healthcare and Machine Learning archetypes. See Key management in Azure for more details on platform-managed and customer-managed keys.
The following policies related to key management are enabled by default in ALZCPS deployments:
- Azure Policy - NIST SP 800-53 Rev. 5 SC-12: Cryptographic Key Establishment and Management
- Azure Policy - NIST SP 800-53 Rev. 4 SC-17: Public Key Infrastructure Certificates
Relevant Links:
- Government of Canada Considerations for the Use of Cryptography in Commercial Cloud Services: Key Management
- Key management in Azure
- Data encryption models
- About Azure Key Vault
7.1 Implement an encryption mechanism to protect the confidentiality and integrity of data when data are in transit to and from your solution.
For client applications, this is specific to the application architecture and determined risk profiles. Azure PaaS services can be audited for compliance via Azure Policy. Azure offers many mechanisms for keeping data private as it moves from one location to another..
The following policies related to protection of data in transit are enabled by default in ALZCPS deployments:
Relevant Links:
- Azure encryption overview
- Encryption of data in transit
- Data encryption models
- Azure data security and encryption best practices
Azure provides the ability to use CSE-approved algorithms and protocols. However, policy enforcement is not possible across all use-cases as it is dependant upon the individual application architecture. For example, the default certificate signing algorithm within Azure AD is SHA-256. However, if an application only supports SHA-1, Azure AD can be manually configured to sign SAML responses using SHA-1 for that application.
The following policies related to approved cryptographic algorithms are enabled by default in ALZCPS deployments:
- Azure Policy - NIST SP 800-53 Rev. 4 SC-13: Cryptographic Protection
- Azure Policy - NIST SP 800-53 Rev. 5 SC-28 (1): Cryptographic Protection
Relevant Links:
7.3 Encryption of data in transit by default (e.g. TLS v1.2, etc.) for all publicly accessible sites and external communications as per the direction on Implementing HTTPS for Secure Web Connections (ITPIN 2018-01).
TLS 1.2 is set as the minimum TLS version in the following deployed resources:
- App Service
- SQL Database
- Storage
The following policies related to encryption of data in transit for publicly accessible sites and external communications are enabled by default in ALZCPS deployments:
- Azure Policy - Canada Federal PBMM SC8(1): Transmission Confidentiality and Integrity | Cryptographic or Alternate Physical Protection
- Azure Policy - NIST SP 800-53 Rev. 5 SC-8(1): Cryptographic Protection
Relevant Links:
- ITPIN 2018-01: Implementing HTTPS for Secure Web Connections
- Azure encryption overview
- Encryption of data in transit
The following policies related to encryption for access to cloud services are enabled by default in ALZCPS deployments:
- Azure Policy - Canada Federal PBMM SC8(1): Transmission Confidentiality and Integrity | Cryptographic or Alternate Physical Protection
- Azure Policy - NIST SP 800-53 Rev. 5 SC-8(1): Cryptographic Protection
Relevant Links:
7.5 Consider encryption for internal zone communication in the cloud based on risk profile and as per the direction in CCCS network security zoning guidance in ITSG-22 and ITSG-38.
For client applications, this is specific to the application architecture and determined risk profiles. Azure PaaS services can be audited for compliance via Azure Policy. Azure offers many mechanisms for keeping data private as it moves from one location to another.
As an additional layer of protection, Azure Private Link enables access to Azure PaaS Services (for example, Azure Storage and SQL Database) and Azure hosted customer-owned/partner services over a private endpoint in your virtual network. Azure Private Link is enabled on all supported PaaS services in an ALZCPS deployment.
The following policies related to information flow enforcement are enabled by default in ALZCPS deployments:
- Azure Policy - NIST SP 800-53 Rev. 5 AC-4: Information Flow Enforcement
- Azure Policy - NIST SP 800-53 Rev. 5 SC-28 (1): Cryptographic Protection
Relevant Links:
- ITSG-22: Baseline Security Requirements for Network Security Zones in the Government of Canada
- ITSG-38: Network Security Zoning - Design Considerations for Placement of Services within Zones
- What is Azure Private Link?
See Key management in Azure for details on platform-managed and customer-managed keys.
The following policies related to key management are enabled by default in ALZCPS deployments:
- Azure Policy - NIST SP 800-53 Rev. 5 SC-12: Cryptographic Key Establishment and Management
- Azure Policy - NIST SP 800-53 Rev. 4 SC-17: Public Key Infrastructure Certificates
Relevant Links:
- Government of Canada Considerations for the Use of Cryptography in Commercial Cloud Services: Key Management
- Data encryption models
- About Azure Key Vault
8.1 Develop a target network security design that considers segmentation via network security zones, in alignment with ITSG-22 and ITSG-38.
The ALZCPS network design implements separate hub virtual networks that allow for segmenting management operations. However, it is up to the implementer to determine how these networks should be enhanced to meet their specific security needs.
The following policies related to network security are enabled by default in ALZCPS deployments:
- Azure Policy - NIST SP 800-53 Rev. 5 AC-4: Information Flow Enforcement
- Azure Policy - NIST SP 800-53 Rev. 5 SC-7: Boundary Protection
- Azure Policy - NIST SP 800-53 Rev. 4 SC-7 (5): Deny by Default / Allow by Exception
Relevant Links:
- ITSG-22: Baseline Security Requirements for Network Security Zones in the Government of Canada
- ITSG-38: Network Security Zoning - Design Considerations for Placement of Services within Zones
- Archetype: Hub Networking with Azure Firewall
- Archetype: Hub Networking with Fortigate Firewalls
ALZCPS adheres to boundary protection policies for management interfaces. This includes the use of Azure Private Link, routing traffic to a deployed firewall, and disabling public network access to sensitive resources.
For custom applications, it is up to the implementer to identify management interfaces which may need increased levels of protection.
The following policies related to protection for management interfaces are enabled by default in ALZCPS deployments:
9.1 Ensure that egress/ingress points to and from GC cloud-based environments are managed and monitored. Use centrally provisioned network security services where available.
ALZCPS provides two default firewall configurations:
- Azure Firewall, which is pre-configured with firewall rules, DNS proxy and forced-tunneling mode.
- Fortigate Network Virtual Appliance (NVA) Firewall, which requires additional configuration.
For logging and monitoring, review the Azure Firewall Archetype Log Analytics Integration documentation.
The following policies related to boundary protection are enabled by default in ALZCPS deployments:
Relevant Links:
- What is Azure Firewall?
- Monitor Azure Firewall logs and metrics
- Azure Firewall Premium features
- Monitor logs using Azure Firewall Workbook
9.2 Implement network boundary protection mechanisms for all external facing interfaces that enforce a deny-all or allow-by-exception policy.
When using the Azure Firewall Archetype, please review the pre-configured Azure Firewall Rules.
The following policies related to boundary protection are enabled by default in ALZCPS deployments:
9.3 Perimeter security services such as boundary protection, intrusion prevention services, proxy services, TLS traffic inspection, etc. must be enabled based on risk profile, in alignment with GC Secure Connectivity Requirements and ITSG-22 and ITSG-38.
The required/available security services will depend on the deployed workload, such as the firewall used, and any additional requirements of the workload based on risk profile. When deploying using ALZCPS:
- Microsoft Defender for Cloud is enabled via a custom policy on all supported resources.
- Microsoft Sentinel is enabled, but requires further configuration and management.
- Azure Private DNS Zones are used to enable Private Link for Azure PaaS services.
- Azure DDoS Standard can optionally be enabled during hub networking configuration.
- TLS Inspection can be enabled on Azure Firewall Premium.
The following policies related to perimeter security services are enabled by default in ALZCPS deployments:
- Azure Policy - NIST SP 800-53 Rev. 5 SC-5: Denial-of-service Protection
- Azure Policy - NIST SP 800-53 Rev. 5 SC-7: Boundary Protection
- Azure Policy - NIST SP 800-53 Rev. 5 SI-3: Malicious Code Protection
- Azure Policy - NIST SP 800-53 Rev. 4 SI-3 (7): Nonsignature-based Detection
- Azure Policy - NIST SP 800-53 Rev. 4 SI-4: System Monitoring
Relevant Links:
- ITSG-22: Baseline Security Requirements for Network Security Zones in the Government of Canada
- ITSG-38: Network Security Zoning - Design Considerations for Placement of Services within Zones
- What is Microsoft Defender for Cloud?
- What is Microsoft Sentinel?
- Azure DDoS Protection Standard overview
- Azure Firewall Premium features
9.4 Ensure that access to cloud storage services is protected and restricted to authorized users and services.
For the archetypes provided in ALZCPS, we provide Private Endpoints for storage accounts. Further controls may be required to limit access to specific users and groups as needed.
The following policies related to access to cloud storage services are enabled by default in ALZCPS deployments:
Relevant Links:
This is out of scope.
Relevant Links:
The required/available cyber defense services will depend on the deployed workload, such as the firewall used, and any additional requirements of the workload based on risk profile. When deploying using ALZCPS:
- Microsoft Defender for Cloud is enabled via a custom policy on all supported resources.
- Microsoft Sentinel is enabled, but requires further configuration and management.
- Azure DDoS Standard can optionally be enabled during hub networking configuration.
- TLS Inspection can be enabled on Azure Firewall Premium.
The following policies related to to cyber defense services are enabled by default in ALZCPS deployments:
- Azure Policy - NIST SP 800-53 Rev. 4 SI-2: Flaw Remediation
- Azure Policy - NIST SP 800-53 Rev. 5 SI-4: System Monitoring
Relevant Links:
- What is Microsoft Defender for Cloud?
- What is Microsoft Sentinel?
- Azure DDoS Protection Standard overview
- Azure Firewall Premium features
11.1 Implement adequate level of logging and reporting, including a security audit log function in all information systems.
In ALZCPS deployments, the default configuration collects logs from VMs and PaaS services into a central Log Analytics Workspace.
The included Log Analytics Workspace solutions include:
- AgentHealthAssessment
- AntiMalware
- AzureActivity
- ChangeTracking
- Security
- SecurityInsights
- ServiceMap
- SQLAdvancedThreatProtection
- SQLAssessment
- SQLAdvancedThreatProtection
- Updates
- VMInsights
For VMs, diagnostic logs are collected using the Microsoft Monitoring Agent which is deployed by default via Azure Policy.
For PaaS services, diagnostics settings are turned on.
The following policies related to to logging and reporting are enabled by default in ALZCPS deployments:
- Azure Policy - NIST SP 800-53 Rev. 4 AU-2: Audit Events
- Azure Policy - NIST SP 800-53 Rev. 4 AU-3: Audit Events
- Azure Policy - NIST SP 800-53 Rev. 5 AU-6: Audit Record Review, Analysis, and Reporting
- Azure Policy - NIST SP 800-53 Rev. 4 AU-9: Protection of Audit Information
- Azure Policy - NIST SP 800-53 Rev. 4 AU-9 (4): Access by Subset of Privileged Users
- Azure Policy - NIST SP 800-53 Rev. 5 AU-12: Audit Record Generation
- Azure Policy - NIST SP 800-53 Rev. 5 SI-4: System Monitoring
Relevant Links:
11.2 Identify the events within the solution that must be audited in accordance with GC Event Logging.
Review GC Event Logging.
11.3 Configure alerts and notifications to be sent to the appropriate contact/team in the organization.
ALZCPS sets up email notifications for the following alerts by default:
- Service Health Alerts
- Subscription Budget Alerts
Further configuration is required to set up appropriate alerts and notifications for any deployment.
Relevant Links:
- Microsoft Defender for Cloud: Configure email notifications for security alerts
- Microsoft Sentinel: Automate incident handling in Microsoft Sentinel with automation rules
11.4 Configure or use an authoritative time source for the time-stamp of the audit records generated by your solution components.
Azure PaaS Services and Azure Marketplace Windows VMs use time.windows.com as the default authoritative time source.
Since early 2021, Azure Marketplace Linux VMs use the chronyd service to synchronize with the host time (time.windows.com).
There are two standard time-stamp columns within Azure Monitor logs:
- TimeGenerated, which contains the date and time that the record was created by the data source.
- _TimeReceived, which contains the date and time that the record was received by the Azure Monitor ingestion point in the Azure cloud.
The following policies related to to time stamps are enabled by default in ALZCPS deployments:
Relevant Links:
In ALZCPS deployments, the default configuration collects logs from VMs and PaaS services into a central Log Analytics Workspace.
The included Log Analytics Workspace solutions include:
- AgentHealthAssessment
- AntiMalware
- AzureActivity
- ChangeTracking
- Security
- SecurityInsights
- ServiceMap
- SQLAdvancedThreatProtection
- SQLAssessment
- SQLVulnerabilityAssessment
- Updates
- VMInsights
For VMs, diagnostic logs are collected using the Microsoft Monitoring Agent which is deployed by default via Azure Policy.
For PaaS services, diagnostics settings are turned on.
Additionally, Microsoft Defender for Cloud is enabled by default on all supported solutions.
The following policies related to to logging and reporting are enabled by default in ALZCPS deployments:
- Azure Policy - NIST SP 800-53 Rev. 4 AU-2: Audit Events
- Azure Policy - NIST SP 800-53 Rev. 4 AU-3: Audit Events
- Azure Policy - NIST SP 800-53 Rev. 5 AU-6: Audit Record Review, Analysis, and Reporting
- Azure Policy - NIST SP 800-53 Rev. 4 AU-9: Protection of Audit Information
- Azure Policy - NIST SP 800-53 Rev. 4 AU-9 (4): Access by Subset of Privileged Users
- Azure Policy - NIST SP 800-53 Rev. 5 AU-12: Audit Record Generation
- Azure Policy - NIST SP 800-53 Rev. 5 SI-4: System Monitoring
Relevant Links:
- Azure Monitor: Log Analytics workspaces
- Monitoring solutions in Azure Monitor
- What is Microsoft Defender for Cloud?
12.1 Only GC approved cloud marketplace products are to be consumed. Turning on the commercial marketplace is prohibited.
The private marketplace is not enabled by default. Once enabled, only approved public marketplace offerings are allowed.
Relevant Links:
This is out of scope.
Relevant Links: