Author: snp

Use a secure hub-spoke network architecture and Azure Policies to enforce the use of Private Endpoints in a hub’s centralized, private DNS zone.

Security is a leading concern as enterprises adopt hybrid cloud strategies and a challenging one at that. At SNP Technologies, we have hybrid security solutions to meet the stringent security requirements of our customers.

In this article, we highlight the scenario wherein the organization has adopted Azure managed resources, such as Azure SQL Database and Azure App Service, in their hybrid cloud solution architecture. These so-called “platform-as-a-services” resources (or PaaS for short) are exposed to the public internet by default.

Hence, the challenge is how to reign in the PaaS resources, so their traffic only flows over the organization’s private network. The solution entails the integration of DNS zones with private endpoints and the use of government policies to enforce the security configuration for each PaaS resource added to the network.

First, we discuss a recommended network architecture to fulfill this requirement. Then we provide examples of governance policies designed by SNP that enforce secure practices for private IP range integration and name resolution. These methods solve many hybrid cloud solution architecture concerns, like:

• Configuring a Hub & Spoke network model with an Azure private DNS zone
• Handling the redirect of DNS queries originating from on-premises to an Azure private DNS zone via a private IP
• Providing an Azure Virtual Network private IP for Azure managed (PaaS) resources (e.g., Azure SQL, App Service)
• Connecting Azure PaaS resources to Azure private DNS zones for DNS resolution
• Blocking public endpoints on Azure PaaS resources
• Deploying PaaS resources on different subscriptions within the same tenant

Networking Solution

Figure 1 illustrates the architecture designed by SNP engineers to secure a hybrid cloud having PaaS resources. This example has an Azure SQL database and the architecture features:

1. For the on-premises network, the Active Directory DNS servers are configured with conditional forwarders for each private endpoint public DNS zone, such as *.database.windows.net* and *.windows.net*. These are then pointed to the DNS server hosted in the Hub VNet in Azure.
2. The DNS server hosted in the hub VNet on Azure uses the Azure-provided DNS resolver (168.63.129.16) as a forwarder.
3. The virtual network used as a hub VNet is linked to the Private DNS zone for Azure services names, such as privatelink.database.windows.net.
4. The spoke virtual network is only configured with hub VNet DNS servers and will send requests to DNS servers.
5. When the DNS servers hosted on Azure VNet are not the authoritative Active Directory domain names, conditional forwarders for the private link domains are set up on on-premises DNS servers pointing to the azure DNS forwarders.

Figure 1

 

Governance Solution

A ensure private networking for PaaS resources, the following conditions should be met:

• The PaaS resource has a private endpoint, not a public endpoint
• A DNS record for the PaaS resource is entered in the central, private DNS zone for the entire network

Below we describe three policies that work together to ensure these conditions are met.

Please note that the policies are customized and not built-in Azure policies (e.g. Azure Policy samples). In the list of resources provided at the end of this article is a link to a tutorial on how to create a custom policy definition in Azure.

Policy 1: Disable public endpoint for PaaS services

Why: Access to endpoints are by default accessible over the public internet.

How: This policy prevents users from creating Azure PaaS services with public endpoints and invokes an error if the private endpoint is not configured at resource creation.

Note: In Azure, the resource that enables the private endpoint is Azure Private Link. Please refer to the Resources section at the end of this article for links to related Azure documentation.

Figure 2 depicts the Azure Portal screen when the policy criteria is not met:

1. Validation fails because of the governance policy

2. Error Details indicate the Azure Policy that disallows the Public Endpoint creation

3. In the Networking section we see that “Private endpoint” setting is set to “None”

4. Once the Private endpoint is added, the policy validation passes (Figure 3)

Figure 2

 

Figure 3

Policy 2: Deny creation of a private DNS zone with a Private Link prefix

Why: By default, when you create a private endpoint, a private DNS zone is created on each spoke subscription.

As a centralized DNS with a conditional forwarder and private DNS zones is used in our architecture, we need to prevent the user from creating their own Private Link, private DNS zones for each new resource added to the network. If ungoverned, sprawl would occur.

How: This policy prevents creation of a private DNS zone with a Private Link prefix in the spoke subscriptions. With Policy 3 that follows, we associate the newly created resource with a central, private DNS zone already in the hub.

Figure 4 shows the Azure Portal screen when the policy criteria is not met, and user tries to deploy a DNS zone for a Private Link.

1. Deployment fails due to policy

2. Error Details shows the Azure Policy that denied creation of resource and the reason

Figure 4

To avoid the deployment error, during resource creation, users must set the “Integrate with private DNS zone” to “No” (Figure 5).

Figure 5

 

If the user tries to create a private endpoint with Private link integration, then the policy will deny creation of the resource during validation as depicted in Figure 6, the Azure Portal resource creation screen when the “Integrate with DNS private zone?” setting is set to “Yes”.

1. Integrate with Private DNS Zone is set to “Yes”.

2. Error details reference the policy that denied creation of resource, and reason.

Figure 6

 

Figure 7 depicts the Azure Portal screen when the “Integrate with DNS private zone?” setting is set to “No”.

3. The setting is observed in the Networking configuration

4. Policy validation passes

Figure 7

Policy 3: “Deploy If Not Exists” policy to automate DNS entries

Why: As described above, since the “Integrate with DNS private zone?” setting is set to “No”, a DNS zone for the Private Link is not created. Therefore, we need to have a method to integrate the Private Link with the centralized DNS zone of the hub. Out of the box, Azure does not provide this option during resource creation.

How: We use a Remediation policy to automate the DNS entry. Within Azure, resources that are non-compliant to a deployIfNotExists policy can be put into a compliant state through Remediation.

The Azure portal screen captures below depict the policy remediation plan:

1. In Figure 8 we see the policy to remediate. The Remediation task is to automatically  add the Azure Resource DNS record to the central private DNS zone.

2. Figure 9 shows that the remediation policy successfully added the DNS entries on the private DNS zone for the respective Private Link DNS records.

Figure 8

 

Figure 9

 

Conclusion

In this article we have shown how one can securely deploy Azure PaaS resources with private endpoints. While thoughtful hybrid network planning is a given, Azure governance is an ingredient for success that is often overlooked. We hope you explore the resources provided below to learn more about Azure Private Link, how DNS in Azure is managed and how Azure Policy can automate the governance of resource creation once the network and security foundation is in place. Contact SNP Technologies here.

Resources

• What is Azure Private Link?
• What is Azure DNS?
• What is Azure Private DNS?
• What is an Azure DNS private zone
• Overview of Azure Policy – Azure Policy
• Tutorial: Create a custom policy definition – Azure Policy
• Remediate non-compliant resources – Azure Policy

The legal or law industry has changed a great deal in recent years. Increasing client demands, globalization, and greater IT complexity have all affected firm profitability. The requirement to have a comprehensive, agile, and user-friendly financial and practice management system to manage operations and support key decision making has now moved beyond a functional need to a strategic requirement. Therefore, choosing the right system demands much more than comparing software functionality.

Often when law firms consider the idea of “moving to the cloud,” they think it is changing their existing software entirely, abandoning their current legal software and switching to a web-based application. But this is not required with Aderant. Law firms can keep their existing software and still get the benefits of the Cloud via a fully managed private cloud platform.

If you are not already familiar, Aderant is  a fantastic tool that assists law firms in handling their invoicing, payments received, managing their cases, and generating helpful financial reports to determine the fiscal health of the firm.

 

Getting Started with SNP Technologies Inc.

A well-planned, well-executed implementation minimizes disruption and avoids negative consequences. If you are like most law firms, your team has not implemented a new practice management system in many years. Selecting a partner with experience is important to your success. This is where we come in.

• The SNP professional services teams have extensive experience of moving data, on-premises servers, applications, and other business elements used by law firms to the Cloud.
• Our solution experts come with years of experience of  implementing practice management systems to Azure for many firms like yours.
• Our services professionals have extensive knowledge and deep understanding of the challenges a law firm will face when they take on a system conversion.
• SNP will guide you every step of the way and help you to stay on track, meet your business objectives, and get your system up and running on time and within budget.

 

In this blog, we will walk you through some of the challenges you may come across while migrating your Aderant system to the Cloud and how SNP can help you overcome them to achieve better and reliable performance while making optimal use of your resources.

Because Aderant is most often installed on physical servers located within a law office, all the components are connected via LAN, this directly impacts the network, storage connectivity mechanism and performance of the system causing bottlenecks while migrating to Azure.

 

A Better Way: Responsive, Knowledgeable Product Support Keeps your Firm Up & Running

The best way to move Aderant to the cloud is to leverage a fully managed private cloud platform from Azure. You get to avoid the hassle that often comes with not understanding how to install or manage all the components required. You get to just enjoy using Aderant from the cloud. A fully managed private cloud from Azure results in more uptime as well as knowing that you have a team of experts on your side to install and manage Aderant while providing you with the support you need. How we do it:

VIRTUAL MACHINE & DISK PERFORMANCE:

Key factors to consider while selecting the resource to host your Aderant system:

• How the disk model and size you choose defines the Input Output (IO) cap
• What generation of the virtual machine and size define the Input Output (IO) cap?
• How the virtual machine and disk combination affects the total Input Output (IO) cap
• How host caching feature affects the disk Input Output cap and how it improves overall Input Output cap of the virtual machine.

Azure virtual machines have input/output operations per second (IOPS) and throughput performance limits based on the virtual machine type and size. The disks have their own IOPS and throughput limits. Aderant’s efficient performance depends on size of the VM, type and size of disks which we select.

Here we cover several scenarios which are considered while moving to Azure:

Scenario 1: Aderant hosted on an on-premises data center

Scenario 2: How application performance gets capped due to disk input output capping

Aderant makes a query that need 25,000 IOPS. As it is a D16s_v3 and it has 25600 IOPS limit, IOPS requested by application are allowed. The 25,000 IOPS requests are broken down into four different requests. 8,000 IOPS are requested to each of 3 data disks and 1000 IOPS to OS disk. As shown in above diagram, OS disk is P15 with a limit of 1100 IOPS and as application requested 1000 IOPS, it responds to the request with 1000 IOPS. Data disk for temp DB is P40 with a limit of 7500 and as application requested 8000 IOPS, it responds with 7500 IOPS only. Data disk for Logs is P50 with a limit of 7500 and as application requested 8000 IOPS, it responds with 7500 IOPS only. Data disk with DB is P60 with a limit of 16000 and as application requested 8000 IOPS, it responds with 8000. The application’s performance is capped by the attached disks, and it can only process 24,000 IOPS.

• VM Size – D16s_v3
• OS Disk – P15 (256 GB with 1100 IOPS)
• Data Disk for DB – P60 (8TB with 16000 IOPS)
• Data disk for Logs ­– P50 (4TB with 7500 IOPS)
• Data disk for TempDB – P40 (2TB with 7500 IOPS)

Scenario 3: How application performance gets capped due to VM IO capping

Aderant makes a query that need 25,000 IOPS. As it is a D8s_v3 and it has 12800 IOPS limit, IOPS requested by application are capped at 12800. Though the attached disks combinedly can handle the IOPS requested by application, it does not perform due to VM IOPS limit.

• VM Size – D8s_v3
• OS Disk – P15 (256 GB with 1100 IOPS)
• Data Disk for DB – P60 (8TB with 16000 IOPS)
• Data disk for Logs ­– P60 (8TB with 16000 IOPS)
• Data disk for TempDB – P60 (8TB with 16000 IOPS)

By looking at the above two examples, anyone can conclude that application performs better using the disk configurations in example 2 and using VM configuration in example 1. But how can you further refine these configurations to cut down cost as using D16s_v3 is 100% more expensive as compared to D8s_v3?

 

Scenario 4: Hosting the caching feature for disks to make the application work with D8s_v3

Aderant makes a query that need 25,000 IOPS. As host caching is enabled on the data disk for logs and the other data disk for temp DB, IOPS request is divided into two sets. As these both data disks are receiving 16000 IOPS requests from application and as host caching is enabled on these disks, they can serve the 16000 IOPS which are not counted into 12800 uncached limit of VM.

Azure VMs enabled with host caching has two different IOPS limits. Cached IOPS limit and Uncached IOPS limit. D8s_v3 has max cached limit of 16000 IOPS and uncached limit of 12800.

• VM Size – D8s_v3
• OS Disk – P15 (256 GB with 1100 IOPS)
• Data Disk for DB – P60 (8TB with 16000 IOPS)
• Data disk for Logs ­– P60 (8TB with 16000 IOPS)
•  Data disk for TempDB – P60 (8TB with 16000 IOPS)

APPLICATION & SERVER LOAD BALANCING FOR ADERANT

You may be using 3rd party load balancers like Kent, F5 or NetScaler to facilitate load balancing for Aderant application servers. You may also be considering whether you need to have the same appliance deployed in Azure which will be easy for your administrators to manage or replacing it with Azure native load balancer. Majority of these load balancers mask the client IP with load balancer IP and presents it as the source to the application servers. Due to this you may not face an issue while opting persistence, but can you do same with Azure load balancer?

Yes. It is possible. You can use Azure standard load balancer with session persistence enabled for client IP and it works great with Aderant app servers.

 

TESTING

Planning and creating a testing strategy for such a performance sensitive application is key to successful migration. Testing with limited load and limited users will give an idea about application functionality but it does not give you a choice to test the application reaction for usual heavy load created on daily basis. Identify the test cases for various Aderant expert modules, run the test cases in production environment, make a note of time, execute the same test cases in test environment and performing a comparison will give insights on the performance of the system. By performing similar activity as above by on boarding few users to test environment and asking them to perform their regular activities will give you the information and data you need to fine tune the infrastructure to be production ready.

 

CONCLUSION: MODERN TECHNOLOGY + NON-DISRUPTIVE MIGRATIONS + GOOD CUSTOMER EXPERIENCE = SUCCESS

SNP’s dedicated professional services and support teams come with years of experience to help you implement practice management systems that can easily be configured to meet your exact business requirements with ongoing support you need to maintain peak operations.

SNP is a partner you can trust to ensure that your financial and practice management system provides the functionality you need to run your firm and support your strategic goals for years to come. The operational benefits that our clients gain include:

• Access to cutting-edge functionality with Azure.
• Reduced integration issues.
• Extremely responsive and knowledgeable client support.
• The ability to participate in new product development.
• Eliminating the hassle of working with multiple vendors.
• Faster deployment and higher user adoption rates.
• Lower total cost of ownership.

 

These benefits then lead directly to the things that really impact your success:

• Responding to client requests (new pricing models, billing information, matter status, etc.) faster.
• Getting actionable performance management data to accurately track performance and enable smart decision making.
• A stronger infrastructure that enables you to better leverage new opportunities for the success of both your partners and your staff.

 

If you are considering a new practice and financial management system or your law firm already uses Aderant as a practice management tool and you’d like to learn more about hosting it from Azure, contact SNP, we would love to help you explore how Azure cloud can benefit your law firm!