This promotion enables eligible commercial Dynamics on premises customers with an active Enhancement Plan (EP) to obtain discounted cloud licenses through the Cloud Solutions Provider Program, with partners like Jot Digital. 

Bridge to the Cloud 2 aims to facilitate a smooth transition to the cloud for Dynamics users. If you’re eligible, it’s a great opportunity to take advantage of the discounted pricing.  

Reach out to Jot Digital to learn if this promotion is right for you.

Key Details

Eligible Products: This promotion applies to customers migrating from most Dynamics on-premises perpetual products purchased through DPL to functionally similar Dynamics 365 online per-user offers available on NCE for commercial customers with a 3-year term.

Pricing:  Enjoy a 40% discount on the standard commercial list price.

Signup Period: January 1, 2023 – December 31, 2024.

Promotion Duration: Fixed 3-year term from enrollment. (Non-renewable) After promotion ends, normal pricing will apply.

Licensing Requirements:

Initial CSP value. Customer must purchase eligible Dynamics online licenses with an annualized greater than or equal to the annual EP renewal amount of their existing Dynamics on-premises license.

Maintain CSP value. Customers must maintain the minimum CSP license value during the promotional term. Customers who fail to meet this requirement, including as a result of cancelling or reducing their CSP subscription are liable for EP costs from the date that their paid EP ended (as well as 3% lapsed fees) and may not continue to receive promotional pricing/terms.

Active EP plan. Customer must have an active EP plan for the on-premises system being migrated (at the promotion enrollment). Customers with lapsed EP plans are ineligible (beyond a 30-day grace period). While customers with an active EP plan may enroll in the promotion at any time, no credit will be provided for the unused portion of the current EP plan’s term.

Functionally similar product. Migration must be to a functionally similar product. Permissible migration paths. (i.e. Microsoft Dynamics NAV on premises to Dynamics 365 Business Central)

Dual Access Rights. (For Business Central Licenses Only) During the promotional term, customers may continue to use, expand, and upgrade their legacy on-premises system while completing the migration without purchasing additional EP. Other EP benefits like affiliate license transfer remain available during this period. (Note: Expanding the number of on-premises users requires purchase of additional on-premises licenses).

This promotion is intended for customers committed to migrating to the cloud. Customers returning to or remaining on on-premises licenses after the promotional period who want Enhancement Plan (EP) benefits are subject to normal backpay and penalty policies.

NOTICE: Microsoft reserves the right to discontinue this promotion, and/or to modify these policies and the promotion’s terms, conditions and expected launch date, at any time.

Dynamics 365 Business Central represents the next generation of ERP solutions from Microsoft, designed to empower organizations with greater flexibility, scalability, and innovation. With its cloud-native architecture, intuitive user interface, and seamless integration capabilities, Business Central offers a modern and future-proof platform for managing your business.

Jot Digital, has a specialized team focused on Microsoft Dynamics 365 Business Central. We are helping clients move from their on premise version of Dynamics GP to the cloud.   When we asked what compelled clients to move, these were their common reasons: 

Why Consider Microsoft Dynamics 365 Business Central?

Flexibility and Scalability: Business Central offers cloud-based flexibility, enabling remote work and adaptability to changing business needs.

No More On-Premise Infrastructure: Say goodbye to managing servers and hardware. Business Central is fully cloud hosted.

Seamless Integration: Connect with other systems effortlessly, streamlining your operations.

Modern User Interface: Designed to enhance productivity and eliminate silos.

Business Intelligence and Analytics: Interactive dashboards provide real-time visibility into your data.

AI Capabilities with Copilot: Leverage AI for smarter decision-making.

Quick Comparison Table GP vs Business Central

Business Central is the trusted solution when migrating from your on-premise Dynamics GP to the cloud. It is time to take advantage of a modern user interface, scalable platform, integrated functionality and continuous innovation. If you are interested in migrating to Business Central or want to learn more about ERP - Jot Digital is here to help. Contact the JOT Team at hello@jot.digital.

—

I'm sorry for the click-bait title, but this article is written just for you, and I wanted to make sure you didn’t miss it.

Why? Because you're on this page. Most likely you've googled "Reasons to Use WordPress," "Why should I use WordPress" or "Is WordPress Really Made of Rainbows?" and you ended up here. Which means, you're thinking about using WordPress for your website.

And why wouldn't you consider it? It is used by 43% of all websites. That is a content management system (CMS) market share of 62.8%. The kind of market monopoly shared only by Microsoft's Internet Explorer for browsers in the 90's, or Apple's early 2010's US smart phone dominance.

WordPress has many great things going for it. It's open source, it's well supported, it's SEO optimized and, most importantly, it's free. But the internet doesn't need yet another article about how fantastic it is. What you're here for is another perspective, maybe one you hadn’t considered before.

It's time to take the red pill and see how deep the rabbit hole goes, as we look into 5 important reasons why you should not use WordPress for your next website.

REASON 1 - Less than Half of all WordPress Installations are Updated to the Latest Version

Even though WordPress actively encourages users to upgrade to the latest version, only 45.2% of website users have actually done so. All users who hesitate to upgrade their website are jeopardizing their security and putting personal information of users at risk. Furthermore, most businesses will buy a website with a shared web hosting company such as GoDaddy, where their website is likely on hosting that is shared with one of the sites that is running an outdated version of WordPress. And while many web hosting companies have security measures in place to keep shared hosted sites from infecting each other it doesn't remove the reality that...

REASON 2 - 96.2% of all Infected CMS Websites are WordPress

That is a scary statistic (it was 94% in 2020). Sucuri states that in most instances, the compromises that they analyzed had little, if anything, to do with the core of the CMS application itself but more to do with improper deployment, configuration, and overall maintenance by the website owners. And to further add to that, many compromised WordPress sites, don't show their true colors to the website owners. Many of the compromises I have seen have implemented scripts that determine if you've hit your website directly, or the admin page first and whitelist your IP so that you are shown your website, while your customers who will have come in through a google search or a social media network, will instead see a web page selling prescription medications for male erectile dysfunction. So why does WordPress, which technically is quite secured by itself, get compromised so quickly and so often? It might be because...

REASON 3 - WordPress Isn't All That Free

WordPress is the America of CMSs, it's free until you actually need to do something. WordPress does one thing really well, and that is blogging. Everything else? Well you're going to need a plugin for that. Want to sell some "Make America Greaterest" hats? You'll need to install one of the 680 shopping cart plugins available to you. Want your customers to subscribe to get a different color of that hat every month? You'll need to buy a $200 extension plugin to go on top of your shopping cart plugin.

WordPress has (as of 2024) 59,470 plugins available. This seems all great and well, and it's nice to be able to have so many options in a convenient central location, similar to the Apple App Store, or Google Play Store. But there is a major flaw with this. The plugins in the directory are all free, and thus the plugin submission guidelines and the review process lack the scrutiny that would otherwise be funded by a commission-based app platform. And many of these free plugins that are on the directory are limited versions of fuller featured, more premium plugins that are sold on third party code-markets or individual websites. And these third-party markets require absolutely no code review. So, you might pick up a plugin from the WordPress Plugin Directory, find out you need a special feature that is only available in the paid version, and pay for it from a third-party market, where the full featured plugin has more security holes than Swiss cheese.

REASON 4 - WordPress Paints a Bullseye on Your Website

It's really easy to determine if your website is built with WordPress. In fact, most of the time it's announced in the footer of your site. This is why WordPress sites get over 132 million spam messages every month. The number of spam comments on a WordPress site is 24 times higher than the number of legitimate comments. If it's that easy for spammers to know your site is WordPress, it's just that easy for malicious bots to find out as well. As it turns out, the majority of WordPress websites are hacked by bots. So you're not really being targeted because of something you said, or because of your great business success. You're WordPress site is being targeted by hackers because it is WordPress.

REASON 5 - WordPress Requires Relatively Complex Systems

I personally don't know how we got to this place on the Internet. Why have so many businesses and individuals gone out of their way to get hosting on a Linux server with Apache, MySQL, PHP, and a complex CMS for 5 pages or less of content that never changes? I am aware that the reason boils down to simplicity. Anyone can install a WordPress site on the cheapest web hosting provider with a single click. But the reality is that it's overkill. WordPress has 1,326,910 lines of code. All of that code is going to generate essentially about 1000 lines of HTML and JavaScript when it's all said and done. Adding all of that complexity opens up more points for hackers to attack your website. For example, if you used WordPress to make a 5 page website, you will be giving hackers the ability to try attacks on potential vulnerabilities within wordpress's 2159+ files and if a hackers gets through one of those vulnerabilities it opens the gateway for them to try attacks on potential vulnerabilities in PHP, Apache, MySQL and the OS your server is running. If you just had a simple 5-page HTML website, you reduce those points of entry to 5 and remove the need for PHP or MySQL.

If WordPress is That Risky, Then What Should I Use Instead?

If you're a small business I really would encourage you to use a hosted CMS solution instead of a self-hosted system. If you're not doing anything that's complex (such as a regular website or an online store) then I would highly recommend using Wix, Squarespace, Webflow, or Shopify. For a low monthly fee, they handle the hosting, security, design and development and all you have to do is write in your content and upload your products. Those sites are too generic looking you say? Then hire a web agency that specializes in headless websites that use Hugo, Jekyll or VuePress. While not as inexpensive as any of the above mentioned hosted CMSs you'll get exactly what you want. Need to have your cake and eat it too? I understand that WordPress is very easy and familiar, for some, and the time and cost to learn a new CMS isn't worth it. There is a last resort option for running your own WordPress, and that's called decoupling. WordPress can be used as a back end to power a static front end. You will once again need a web developer to do this, but if it's critical you need both self-hosted WordPress and security, then decoupling is your best option.

Unlike CloudTail and CloudWatch Logs, EventBridge events are not captured by default and there isn’t an easy way to get a glimpse at the stream of events as they pass. If you fail to capture the events you desire, they will be gone for good.

Things have improved since the CloudWatch days. You can now create an archive of events and play them back for event rule development. They have also made many improvements in event rule functionality. But there are still some gotchas that will trip you up. Here are some things that have tripped me up.

Silent Failures

If there is a problem with an event rule, the event rule will fail its invocation. This is a problem as there isn’t any logging as to what the issue would be. The only evidence of these invocation failures is a metric recorded in CloudWatch and displayed under the event rule’s monitoring tab within the EventBridge interface. To be aware of these rule failures, you would have to setup a CloudWatch alarm. As for diagnosing the issue, if the problem is with the target, you will have to search through Lambda logs or CloudTrail for errors and hope you find something. If the issue is with the configuration of the rule and its pattern matching, you may end up with nothing to work with.

It is a good practice to create a CloudWatch metrics alarm to check for EventBridge invocation failures. This will give you some visibility of any event rule failures. For better visibility, you could setup a dead-letter queue on your event rules and have a Lambda function create log entries from that SQS queue in a CloudWatch Logs log group.

Event Patterns

Pattern Content Filters

The recent addition of content filters adds some much-needed flexibility to the pattern matching. I would like to highlight a feature called multiple matching. AWS’ documentation does touch on multiple matching, but only in relation to having a single content filter on multiple keys (properties). It is not possible to match multiple content filters on the same key, such as matching a prefix and a suffix. Attempting to use the same key more than once will cause only the last one to use evaluated. They now have a note mentioning this behavior. For the moment, there is no way to perform an all-of match against a single key. The reason for this might be down to how content filters are not delineated from regular key names and could cause conflicts. I suspect the EventBridge team have backed themselves into a corner with this design.

NOTE: The following examples do not work

This will return the error ‘Event pattern is not valid. Reason: “prefix” must be an object or an array’.

"object": {
  "key": {
    "suffix": ".csv",
    "prefix": "folder/"
  }
}

This will treat prefix and suffix as keys and always fail to match.

"object": {
  "key": {
    "suffix": [".csv"],
    "prefix": ["folder/"]
  }
}

It is also not possible to pass a list of values to a content filter.

"object": {
  "key": [
    {
      "suffix": [ ".csv", ".json"]
    }
  ]
}

With the recent addition of the “$or” functionality, which uses a “$” character to delineate it from key names. This deviates greatly from all other event pattern functionality and show a re-think on how advanced functionality is defined. We will likely see future content filters and other features being prefixed with ‘$’. There is no way to fix the current content filters without breaking backwards compatibility. They will need to release a version 2 for event pattern syntax.

The good news is that it is possible to perform an any-of match on a list of content filters for a single key. This doesn’t help us with the use case above, but does allow for some other ones that are beneficial.

The following will match on the suffix or prefix, but not both:

"object": {
  "key": [
    {
      "suffix": ".csv"
    },
    {
      "prefix": "folder/"
    }
  ]
}

You can duplicate content filters, unlike keys. This now allows us to match both suffixes:

"object": {
  "key": [
    {
      "suffix": ".csv"
    },
    {
      "suffix": ".json"
    }
  ]
}

The AWS documentation never gives an example of using more then a single content filter object within a key’s value list. You can actually specify multiple content filter objects and even mix them with plain text values. As long as one of the content filters or text values matches, the event will match the pattern.

This undocumented ability of multiple-matching is inherited from the base functionality where providing a list of text values within [] brackets will default to match any-of instead of all-of. If the event property matched one of the items in the key’s value list, the event will match the pattern. The fact that content filter are treated the same as text values when it comes to potential values is a hidden bonus.

This discovery of using multiple content-based filters on a single key fixed an edge case issue that was causing me to give up on complex pattern matching within the event rules and re-create my own pattern matching engine in a Lambda function. The following example is how you can match a path that may not always exist.

Let’s say you have a specific “deployment-role” IAM role whose events you want to ignore. Well, you would use an “anything-but” content filter to exclude it. What happens if you have an AWS account with IAM users that don’t assume roles? Well, the events caused by an IAM user will not contain the same “sessionIssuer” section as an event caused by someone assuming an IAM role. If the path does not exist, “anything-but” will fail to match events caused by the IAM user. A value at the specified path is required to be there to have that content filter match. Strangely, when one of those events occur, the event rule will not just skip the event, but will actually fail the invocation.

To solve this problem, you can use multiple matching and add an {“exists”: false} content filter into the same list as the “anything-but” content filter. As long as one of those content filters is true, the event will match the pattern.

{
  "detail-type": ["AWS API Call via CloudTrail"],
  "source": ["aws.ec2"],
  "detail": {
    "eventName": ["CreateSecurityGroup", "DeleteSecurityGroup", "AuthorizeSecurityGroupIngress", "AuthorizeSecurityGroupEgress", "RevokeSecurityGroupIngress", "RevokeSecurityGroupEgress"],
    "eventSource": ["ec2.amazonaws.com"],
    "userIdentity": {
      "sessionContext": {
        "sessionIssuer": {
          "userName": [
            {
              "anything-but": ["deployment-role"]
            },
            {
              "exists": false
            }
          ]
        }
      }
    }
  }
}

When an IAM user causes an event, the username property is found under “sessionContext”. The “sessionContext/sessionIssuer” section is empty. When an IAM role causes an event, the username property is found in “sessionContext/sessionIssuer”. This highlights how not just cloudTrail events, but many other AWS events do not adhere to a strict structure. Properties will move around and identifiers will change. Another example of this is where an iam:CreatePolicy event will return a policyName attribute while an iam:DeletePolicy and all other policy events will return a policyArn attribute instead. You might think the trick above could solve this issue, but it can’t. You could potentially match events where neither username paths exist. This brings us to another limitation with event patterns, there isn’t support for conditionals or string manipulation to solve these complex but common situations. If you want to consistently extract certain details without running into invocation failures, you will need to send the event to a Lambda function for pre-processing and transformation.

Events With Lists

Occasionally you will run into an event with a list of objects. This is actually a common occurrence with CloudTrail as it will return a list of affected resources within the responseElements path. Let’s say you want to match if a specific resource has been affected. You would expect to be able to do a matching of an attribute with the object of that resource list. Well, it is not possible to do that. You are not able to drill into a list of objects to do a match for a specific object. With event rule patterns, once you run into a list, you can’t go any further.

Input Transformer

Illegal paths

Like I mentioned above, events do not follow a strict structure. Some events will contain properties that others will not. Sometimes an AWS service will return different identifiers depending on the event. An example of this is when one event returns an ARN while the other returns a resource name.

These differences between AWS events structures are little nightmares when working with the Input Transformer. Input Transformer requires that all paths, specified in the input paths JSON, exist. If any of them do not, your event rule invocation will fail, silently. This is where a coalesce style function or conditionals would be useful. As done with event patterns, adding functions to JSON based templates is difficult, but not impossible. Hopefully there are solutions in the future for allowing missing paths or pulling a value from the first available path (coalesce).

To get around this, you would have to create highly specific event rules that match each type of event you would want to react to, pass whole sections of the event through or pass the unaltered event to something else to process. Doing this may cause you to sometimes run into the dynamic data limit mentioned below. This only leaves you with option of sending the full event to a Lambda function for pre-processing and transformation.

Dynamic Data

Some data will cause the input transformer to break. An example is an embedded policy document which happens on IAM policy change events. When modifying an IAM policy, a copy of the document is included within the requestParameters and/or responseElements sections. If you try to pass in the full event or section containing the document as a property, it will cause the invocation to fail. The AWS documentation lists a value length limit of 256 characters, but that doesn’t appear to be the same as the computed value length limit, as I have far exceeded that without issue. There is either a special character or a content length issue. I am not sure as I have no error message to work with, only theories. As you are not able to manipulate the JSON object within the input paths, you will be forced to give up on the import transformer and send the unaltered matched event to a Lambda function for pre-processing and transformation. Are you seeing a pattern here?

Matched Event

If you do away with the Input Transformer and go back to using matched events, your Lambda function target will have to rely on the contents of the original event to identify and direct it to its final destination. With matched event, you will not have the luxury of a rule name, additional attributes, or tags to help you. This breaks the practice of using a generic Lambda function for processing events from multiple event rules and sources. You may need to create separate Lambda functions to handle events from every AWS service you work with and possibly every destination.

Let’s say you want code pipeline events to go to the developers, EC2 and ECS events to go to the cloud infrastructure team, or VPC changes to the security team. You would need to have separate Lambda processing functions for each event rule or build a single complex Lambda function that uses a lookup table (DynamoDB) to help identity the event, transform it, determine which team the event message should be sent to, and how the message should look. If you get to this point, you have effectively recreated EventBridge’s event rules with the functionality you needed.

Eventual Consistency

This isn’t as much of an issue as it is a fact of life. Your event rule may not fire when the event actually happens. Sometime AWS has issues where the event bus stream is delayed. In those cases, the events will eventually get posted to the bus and your event rule could trigger many hours after when it should have. There is also a chance an event could be duplicated, or your rule gets triggered twice. You may need to think of these edge cases when planning your event rules. If you have a rule starting an EC2 instance or ECS task on a matching event, you could end up with a bit of a mess.

In addition to event triggered rules, classic schedule event rules are also affected by EventBridge’s eventual consistency, and your rules may not trigger at the time you expected.

They have recently added new functionality under the rule trigger configuration to specify a shorter retry window and the maximum number of retry attempts. They also have added support for a dead-letter queue for collecting failed invocations.

Scheduler

AWS has built a new EventBridge Scheduler to replace the scheduled event rules and centralize scheduling of events. It is a completely separate service under the hood with its own API interface and quotas, but officially it is still housed under the EventBridge umbrella. It has the same new features mentioned above that help deal with eventual consistency. In addition, there is also support for a flexible start window, time-zones, and grouping.

Troubleshooting

Previously, troubleshooting event rule issues was nearly impossible as there wasn’t any event history to work with, unlike CloudTrail. If you wanted to get a snapshot of the events you were trying to match, you had to make an event rule with a generic pattern and target a Lambda function to dump the event details to a CloudWatch log group. The new archive/replay functionality of EventBridge doesn’t provide any visibility, but it does allow you to replay those captured events from within EventBridge. Having a list of captured events is useful for testing event rules, but it doesn’t make troubleshooting effortless as not all causes of a failed event rule invocation will produce an error event in CloudTrail. The recent addition of the dead-letter queue may help a bit more with troubleshooting. There still isn’t a single pain of glass to help you with troubleshooting event rule issues. You will need to build your own monitoring and perform a lot of trial-and-error to solve invocation issues.

Pro tip: One of the first event rules you should create is one that alerts you on event rule invocation failures. Without custom alerting there is no way to monitor that your event rules are working without checking CloudWatch metrics and CloudTrail logs.

Conclusion

For many years, EventBridge was another section under CloudWatch and its pattern matching engine was very basic to not that effective. Since the split, they have added many new features to the EventBridge service such as streams, archive/replay, schema registry, and pipes. In addition to those features there were also a lot of improvements made to the pattern matching engine and expanding the list of trigger destinations. Some recent changes have allowed me to strike off some of the issues on my list, but, as outlined above, there is still room for improvement when it comes to debugging, error handling, pattern matching, and the input transformer.

• What is an Azure Landing Zone?

• Azure Landing Zones and Break-glass Accounts

In this post, let’s talk about VNet networking within Azure Landing Zones.

Networking is simple, right?

Sure thing boss! No, seriously, this blog post could be a book. In order to keep it focused, I want to concentrate on networking within Azure. An Azure Virtual Network (VNet) is the primary building block for creating your private network in Azure. Typically, deployments will have a few to several virtual networks, providing management and networking boundaries between workloads.

In order to understand the topologies within the Azure Landing Zone, we need to cover a couple of concepts.

Peering

Virtual networks are private address spaces that can be used to deploy resources. Virtual networks can then be connected by way of peering. With peering, resources in separate virtual networks can directly address each other using private IP addresses. Importantly, Azure supports the concept of global peering, which allows you to directly connect two virtual networks in different regions to each other.

Peering is a complicated topic, but one point to understand for this discussion is the concept of VNet transit. In Azure, virtual networks that are peered together can talk to each other directly. However, spokes in a traditional hub-and-spoke topology cannot natively talk to each other. A networking device (router/firewall/etc.) is required to allow this traffic to work.

Azure Firewall

According to the docs Azure Firewall is a “cloud-native and intelligent network firewall service”. As opposed to network virtual appliances (NVAs) you can think of Azure Firewall as a “firewall-as-a-service”. Designed to scale and providing many of the same features as traditional NVAs, Azure Firewall can be an effective way of providing both north-south (in/out of your environment) and east-west (lateral between systems/services in your environment) protection for your Azure workloads.

Network Security Groups

Network Security Groups allow you to filter traffic at the network level for resources deployed in Azure. Configurable on both the subnet and resource level, you can make use of network security groups to provide micro-segmentation protection.

Networking Options

The ALZ has two built-in models for networking in enterprise scale.

Hub-And-Spoke

The traditional approach to Azure networking is the create a hub-and-spoke topology.

Remember, spokes cannot talk to each other. So, in this topology, a firewall or NVA is required in the hub to enable that communication flow. Because of this, all communication flows will require some step for configuration of that firewall.

One consideration is how to expand this networking topology to be cross region. There are likely 2 ways to accomplish this. The first way would be to create another hub/spoke topology in the second region, and then peer the two “hubs” together. In this scenario, the firewall would be traversed twice during networking transit between regions.

The second way would be to globally peer VNets together that are allowed to talk to each other.

Virtual WAN

Azure Virtual WAN is a “meta” networking service within Azure that brings together several services in Azure to greatly decrease the complexity of networking. You can see how the ALZ uses Virtual WAN here.

In this setup, you effectively deploy a Virtual WAN Hub in each region. Hubs can connect to each other directly. Virtual networks can associate themselves with the hub. Virtual WAN offers a couple of cool capabilities such as direct VNet transit access and secure Virtual WAN hubs. I’m not going to go into detail here, but you can likely understand that there are several benefits to this topology over the traditional hub-and-spoke.

Lastly, you can enable any-to-any type communication patterns.

Hidden 3rd Option

At time of writing, Azure has a new service called the Azure Virtual Network Manager (VNM). I feel like this service really combines the best of both the hub-and-spoke and the Virtual WAN solutions when it comes to VNet considerations within Azure. Here are some key features:

• You can centrally manage policy which automatically creates your networking topology.

• You can enable hub-and-spoke and mesh topologies (VNets with direct access to each other)

• You can manage other features of your virtual networks, including network security groups and new admin rules

There is currently no guidance on how to use ALZ with AVNM. For me, this option really allows you to start configuring your guardrails (around networking and network security) and enforcing that via policy within the platform. There are several reasons why I would recommend starting here vs the other two topologies mentioned above.

Conclusion

Networking is a complex topic with many nuances that can affect your security posture. I hope that I did an okay-ish job going over some of the basics here and showing that there are many alternatives to building a secure networking topology within Azure.

What are “break-glass” accounts?

First, some background. In Azure, user management is delegated off to a service called Azure Active Directory or AAD for short. AAD can have multiple different “user types”, but the most common are federated and cloud-only. In the federated case, identities can be enabled with multiple different authentication options, most of which effectively hand off the authentication responsibility to a 3rd party provider (that isn’t AAD). In the cloud-only case, authentication of user accounts is actually done by AAD itself. In all cases, user access can be protected with additional mechanisms such as Azure Multi-factor authentication (MFA) or Azure Conditional Access.

Typically, when enterprise customers set up access to Azure resources, they will do so by federating user accounts with their existing enterprise systems. This approach makes sense from a security perspective, as you can control how/when your identities are used centrally within your enterprise system. However, this architecture also introduces an extra failure case that you need to consider.

When you are planning your cloud deployment, you need to also plan for disaster recovery. Cloud consoles are typically accessible over the internet, and so you need to understand what your response would be in the following scenarios:

• On-prem identity provider is offline, inaccessible, or having issues (with MFA, authorization, or other)

• Azure MFA (the service) is having issues and not functioning correctly

• Azure Conditional Access policies are not working correctly

“Break glass” accounts are a strategy for providing access to the cloud console in the event of any of the failures described above. They are typically cloud-only accounts that do not have the additional security protections of MFA and Conditional Access. By creating accounts like this, you allow for management of your cloud resources in the event of failures in any of the above-described systems.

I think it is important to note that break-glass accounts are a tradeoff between continued operations and overall security. Typically, failure of authentication services does not prevent you from using already running cloud resources, but it does prevent you from managing them further. Businesses need to assess the tradeoff/risk of creating high-privileged accounts with limited account protections against the likelihood of failure in the authentication systems along with the impact. While Azure Landing Zones strongly recommend emergency access accounts, they might not always make sense for all situations.

Strategies for “break glass” accounts in Azure

To me, there are three different options when implementing “break glass” accounts.

AAD Global Admin Access Path

Within AAD there is a directory role called Global Admin. This role has full access to the directory. Further, global admins have the option to elevate access to all Azure subscriptions. Effectively, using this function, you can become a User Access Administrator at the root scope of your management group hierarchy. From there, you can make any access changes you need to make, including granting yourself more access.

EA “Account Administrator” Access Path

Depending on your agreement with Microsoft to purchase Azure, you may have what is called an Enterprise Agreement. In this situation, billing is handled via a separate mechanism within Azure. This mechanism allows for the creation of enterprise enrollment accounts, and one of the roles that you create is an account administrator. All subscriptions will belong to exactly one enterprise enrollment account. Enterprise Enrollment account administrators can set the service administrator for each subscription . In this access path, your “break glass” account could be the enterprise enrollment account administrator. In the event of access issues, use the enterprise enrollment portal experience to set a different service administrator for the target subscription.

Management Group Access Path

Within Azure, all subscriptions belong to a hierarchy level within Azure Management Groups. Even if you have never really configured this before, you always have the root management group where each subscription will automatically live. In this access path, your “break glass” accounts can be assigned a certain permission level (Owner, or other) within an appropriate area of your management group structure. If there are access issues, simply log in to Azure with your “break glass” account and use its permissions to fix any issues.

Recommendations?

Long story short, is, not really. All the access paths above have different trade-offs. Off the top of my head, here are some considerations:

• Level of access of the “break glass” account, and what blast radius a compromise would mean

• Organization structure for managing different areas of your Microsoft landscape

• Ability to monitor/react to inappropriate use of break-glass accounts

• Support model / structure

Most conventional wisdom is to use the AAD global admin access path for your break-glass accounts. You can even see this recommendation for Canadian Government Use.

Hope you enjoyed the post!

What is an Azure Landing Zone?

I think there are a couple of different ways to frame the concept of a landing zone.

From a cloud adoption framework you can think of landing zones as the technical end-game. They represent the prescribed architecture that considers the people/process/technology guidance (as best as it can) laid out within the cloud adoption frameworks. Where required, assumptions are made about how the organization will want to interact with cloud resources, and those assumptions are baked into the deliverables.

The other way to frame landing zones is that they provide building blocks for organizations to use while adopting the cloud. The building blocks take into account Azure/product limitations along with a host of “best practices” as it relates to scaling, security, governance, networking, and identity. Organizations adopting the cloud can choose to use some or all of the prescribed components to build out their environment.

What is in the box?

I think it’s important to look at the design principles that went into creating the Azure Landing Zones.

Subscription Democratization

With this design principle, Azure Landing Zones utilize subscriptions as both a unit of scale and a as a unit of management. The idea is that centralized platform teams can create/govern core parts of a subscription (think networking, identity, governance via Azure Policy) but ultimately the management of a subscription belongs to the workload or business unit teams for which the subscription was created.

There are reasons why organizations would not find this a suitable approach to building out the cloud. One of the main reasons here is that it pushes various aspects of management (of cloud infrastructure) to teams that might not be well equipped to manage at that level. I would say that it takes more of a “DevOps approach” to cloud management rather than a “platform engineering” approach. Those teams are heavily overloaded, so, another way to think about it is that it forces the developers of an application to manage the infrastructure as well, rather than having a centralized team of cloud infra experts that work with development teams to create appropriate infra. Scaling, for example, is a far more nuanced topic than simply adding or removing subscriptions.

Policy-Driven Governance

In a policy-driven governance approach, cloud ops teams will make use of Azure Policy (and apply said policy) on top of democratized subscriptions. The idea is that the policy controls provide the guardrails by which Azure services can be used in the given context. Some of the Azure policies are easy enough to think about, such as ones that restrict the type of services that can be deployed and others that restrict the locations where services can be deployed.

There is a lot more to Azure policy than that, however. While Azure does release policy guidance (some which adhere to various security frameworks) that guidance is generic and requires tuning. This tuning goes beyond the traditional “exception” management. Many frameworks do not cover all services that Azure has, cannot deal with certain security controls, and do not reflect any corporate standards.

The key point here is that adopting Azure Landing Zones requires corporations to have proactive (rather than reactive) policy governance teams that are constantly evolving / testing the policy code to ensure compliance.

Simplified Management

The idea here is that the landing zones take into account best-practice patterns for usage of both infrastructure-as-a-service and platform-as-a-service tooling. This ensures that you are not restricted, at least initially, to service choice.

Application-Centric Service Model

The policy/governance tooling provided within the base landing zone configuration are designed to provide a set of services at the “application” level, not at the infrastructure component level. What this basically means is that you need to think about resources in terms of the application lifecycle. You’ll move away, for example, from deploying a centralized SQL server that hosts many application databases to creating application specific SQL servers. While this tradeoff may increase work for traditional infra teams (such as your DBAs) it’ll decrease work at the Azure policy/governance/management level.

Align with Azure-native design and roadmaps

Azure landing zones, obviously, make use of Azure-native services when addressing scale, security, governance, etc. When adopting Azure Landing Zones, you need to think about Azure services managing Azure, and then, from a corporate level, integrating reporting with other centralized systems.

Conclusion

I’ve never been a fan of generic advice as I feel like the whole role of architecture is to ensure that a solution is fit-for-purpose for a client environment and context. That being said, Azure Landing Zones seems like a great place to start for most organizations. I like that the landing zones are not just paper based, but there are ARM/BICEP/Terraform artifacts to deploy required components along with a CI/CD framework that seems easy enough to use. I’m hoping over the next few blog posts to dive into key areas within the Azure Landing Zone framework and discuss some possible architectural alternatives.

• Creates a set of Azure resources (grouped into an Azure Static Web App) to host the code components

• Creates/forces a set of CI/CD automation to support the deployment and promotion of code from a repository of your choice

I’ve been using Azure Static Web Apps to host a few marketing type websites. It has been relatively quick and easy to setup. The one annoying thing, however, is that you have to have a CI/CD pipeline setup to perform a deployment. While this is always the recommended way, sometimes you just want to do it manually. You’ll notice that there are no tools provide by Azure to do this, so I had to go hunting around to make it work.

Investigating the GitHub Action

My first stop proved promising as I went to go and have a look at the github action that was created to support this deployment. Turns out it uses a docker container, which means we can try and reproduce the steps locally. Here is a link to the repo

From here, you can effectively run the docker container and mount in your web artifacts using something like:

docker run -it -v app:/app mcr.microsoft.com/appsvc/staticappsclient:stable /bin/bash

The main program to facilitate a deployment is located in the /bin/staticsites folder.

At first I thought I had to set a bunch of environment variables to make this work (as per the custom GitHub actions documentation) but it turns out that you can use –help on the StaticSitesClient binary to manually enter in the required information.

Here is a sample of the options for the “upload” action:

Based on this, you can work out a command to deploy your relevant configuration. Keep in mind that you will need to specify your apiToken on the command line here.

Enjoy!

What is Azure Storage Encryption?

By default, all data stored in Azure storage accounts are encrypted at rest. This is done transparently at the storage service layer using a 256-bit AES Encryption key. The service and key usage is FIPS 140-2 compliant. As per the documentation this encryption is enabled automatically and cannot be disabled.

From a data flow perspective, it looks something like this:

The encryption service offers 3 methods for encrypting your data on the underlying infrastructure. The first is the default which uses Microsoft-managed encryption keys and follows the flow above. Anyone with API access to the Azure storage account will be able to read the data, and, all data stored within the Azure storage account is encrypted using the same key. Microsoft manages the key, which effectively means that there is a key rotation process that happens in the background.

The second method is to use customer-managed keys. Here is the diagram from the docs page.

In this method, an encryption key is still stored as part of the encryption service, just like in the first scenario. The difference here is that the key stored in the encryption service is wrapped by a customer managed key. This customer-managed key acts as a key-encrypting key and is stored in Azure Key Vault.

The main benefit here would be around deletion of the data itself. Rendering the data irretrievable in this scenario would be as simple as deleting the customer managed key in the Azure Key Vault. This benefit comes at the cost of some important trade-offs. The first is that Azure Key Vault is priced in a per-operation perspective. Because the encryption service within the Azure storage account needs to decrypt the encryption key in order to use it, every operation will incur a call to Azure Key vault. Further, each call could result in increased latency as you’ve now added another service into the overall data flow. The last trade-off is that your customer managed key becomes a key that you will also have to rotate/manage/control.

The last method is called the customer-provided key. In this method, the flow above is the same, however, the encryption service no longer stores the encryption key (in any form) for the back-end data. Instead, the client sends up the key to use during both the read and write operations. This method provides the most control over which key is used to encrypt the data in the storage account at the expense of passing all the key management and distribution responsibilities to the client.

Encryption Scopes (Preview)

A feature that is currently in preview for Azure storage is encryption scopes. Based on my understanding of the feature, encryption scopes is designed to be an alternative to customer-provided keys. Effectively, you can now define multiple encryption keys that can be used in a given storage account. You can then define the default key to be used (at the container level, for example) and you can also specify which key to be used when individual blobs are created (as an override, perhaps).

The benefit here, over customer-provided keys, is that you don’t have to manage the storage and distribution of the key to all the various clients that would need access to the data. The disadvantage is that I do not believe there is any access controls on an encryption scope itself. Therefore, any client interacting with storage could use any of the encryption scopes currently defined.

A use case

At Keep Secure, we work with many start-ups that deal with customer data in a multi-tenant fashion. A potential use-case for encryption scopes is to allow for multi-tenant storage of data while giving customers fine grain control over the data stored.

For example, a SaaS provider could provision a key vault for each customer for whom they want to store data for. Using key vault authentication, they could provide access to customers to create a customer-managed key within that key vault. Then, they would create an encryption-scope tied to that customer which uses the created/shared key-vault. Now, all data tied to a given customer could be encrypted with a customer-specific encryption scope, tied to a key to which the end customer has full control over.

One of the key benefits I see for this approach is in off-boarding scenarios. With a simple action of deleting the customer-managed key in the key vault, all data stored against that key would be rendered useless. An effective way to provide various assurances to customers that data deletion was done properly.

Conclusion

There are a couple of neat new features as it relates to Azure storage that I hope to explore. Encryption scopes is one of them. I think this could provide some very interesting features particularly as it relates to data security and privacy regulations. I hope you enjoyed.

1. Who can make what types of changes to your ADF resources?

2. In what environments do you allow certain change types?

3. Who is responsible for making changes "operational"?

The goal of this post is to discuss how to use Azure Custom Roles to help secure your ADF resources in both development and operations. In order to understand how to use this, we need to walk through a couple of concepts.

ADF Components

As per the documentation here there are several components that actually make up an ADF. These include developer components, such as pipelines and activities, data components, such as datasets, and then operational components, such as linked services and triggers.

When you develop or interact with ADF via the portal, you get to use a drag/drop interface to effectively configure an ARM template representation of that particular component. Each one is actually backed by a schema, and you can view these here.

Because the underlying service uses ARM as it's configuration engine, there is also an associated ARM Resource Provider which handles all the calls to create/update an ADF instance. You can view a full list of all the actions you can take here.

What are Azure Custom Roles?

If you've ever granted access to anyone to Azure resources, you've likely had to give them permissions to a target resource, resource group, or subscription. Likely, you've played around with several of the built-in roles, including the most common ones of Contributor, Owner, or Reader. Over the last while, Azure had greatly expanded the amount of built-in roles you can use, getting more granular with how permissions are applied.

All role definitions are effectively a set of Actions (or not-actions in the case of deny) that a role can take on the target. In the case of ADF, Azure provides one built-in role in additional to the default, called Data Factory Contributor.

Depending on your development and operations process, this single built-in role might not provide enough granularity. For example, in production, your support personnel would be able to change linked service configuration using the Data Factory Contributor role. You might not want this as it could be a potential security issue.

Azure custom roles effectively allow you to build your own permission sets that you can use to grant to users or groups in Azure. This allows you to get more fine grained with your permission model.

ADF Personas

With all the pre-amble out of the way, lets talk about a couple of different personas you might have. It is important to keep in mind that you will likely also have distinctions between environments as to who has access to what. Here is a stab:

Operator
An ADF operator is someone who manages the health of an ADF instance. They could, for example, monitor job runs, queue lengths, etc. They would never make changes to the ADF itself in terms of data pipeline code.

Developer
An ADF developer is someone who would have access to make changes to developer relates components such as pipelines, activities, and data sets. They wouldn't create or modify linked services, and they wouldn't schedule triggers or other runs.

Admin
This is your infrastructure administrator who is responsible for the ADF itself. Typically, they would have full access to the ADF. Most importantly, they would be the ones creating/modifying security settings, repository settings, and linked services.

Data
This role might make sense for a subset of developers who are responsible for creating/maintaining datasets and the various configurations in that dataset. You could create a data role separate from your developer role.

Creating Custom Roles

A full discussion around creating custom roles is out of scope for this post, but here is an example of an implemented operator role.

{
    "Name":"Data Factory Operator",
    "Id": "",
    "IsCustom": true,
    "Description":"A custom role that grants users access to operate ADF",
    "Actions":[
        "Microsoft.Authorization/*/read",
        "Microsoft.Resources/subscriptions/resourceGroups/read",
        "Microsoft.ResourceHealth/availabilityStatuses/read",
        "Microsoft.DataFactory/datafactories/*/read",
        "Microsoft.DataFactory/factories/*/read",
        "Microsoft.Resources/deployments/*/read",
        "Microsoft.DataFactory/datafactories/datapipelines/pause/action",
        "Microsoft.DataFactory/datafactories/datapipelines/resume/action",
        "Microsoft.DataFactory/datafactories/gateways/connectioninfo/action",
        "Microsoft.DataFactory/factories/cancelpipelinerun/action",
        "Microsoft.DataFactory/factories/pipelines/createrun/action",
        "Microsoft.DataFactory/factories/pipelineruns/cancel/action",
        "Microsoft.DataFactory/factories/triggers/start/action",
        "Microsoft.DataFactory/factories/triggers/stop/action",
        "Microsoft.DataFactory/factories/pipelines/sandbox/action",
        "Microsoft.DataFactory/factories/pipelines/sandbox/create/action",
        "Microsoft.DataFactory/factories/pipelines/sandbox/run/action",
        "Microsoft.DataFactory/factories/getDataPlaneAccess/action"
    ],
    "NotActions": [
    ],
    "AssignableScopes": [
      "/an/assignable/scope"
    ]
}

The goal of the above role is to give the operator enough permissions to monitor the ADF resource and restart jobs as required.

Conclusion

ADF is a pretty powerful tool, but combines the development and operation planes together. This separation is still required for both security reasons and development process reasons. While you can use policy to hopefully enforce separation of concerns, Azure Custom Roles provides an effective way of enforcing the same via Azure RBAC.

You can use linked services to interface ADF with other services, such as Azure Databricks. Here is what the configuration for an Azure Databricks linked service looks like:

In the image above, there are several items that you may want to change between environments that this linked service is deployed to. Moreover, Azure Databricks recently announced a move from generic URLs to per-workspace URLs.

Unfortunately, by default, the “domain” (Databricks Workspace URL in the image above) attribute of an Azure Databricks linked service is not exposed in the ARM template parameters file. Therefore, it cannot be overridden easily at deployment time.

Luckily, the ADF team opted to have a configuration file determine which components of the ARM template are exposed to a parameters file, and which ones are not. You can read more about it here.

Taking a look at the default configuration, one notices that the “domain” keyword is missing from the parameters list.

    "Microsoft.DataFactory/factories/linkedServices": {
        "*": {
            "properties": {
                "typeProperties": {
                    "accountName": "=",
                    "username": "=",
                    "userName": "=",
                    "accessKeyId": "=",
                    "servicePrincipalId": "=",
                    "userId": "=",
                    "clientId": "=",
                    "clusterUserName": "=",
                    "clusterSshUserName": "=",
                    "hostSubscriptionId": "=",
                    "clusterResourceGroup": "=",
                    "subscriptionId": "=",
                    "resourceGroupName": "=",
                    "tenant": "=",
                    "dataLakeStoreUri": "=",
                    "baseUrl": "=",
                    "database": "=",
                    "serviceEndpoint": "=",
                    "batchUri": "=",
                    "databaseName": "=",
                    "systemNumber": "=",
                    "server": "=",
                    "url": "=",
                    "aadResourceId": "=",
                    "connectionString": "|:-connectionString:secureString",
                    "existingClusterId": "=",
                    "host": "=",
                    "secretName": "="
                }
            }
        },

You can simply add “domain”:"-", under type properties above to have that property now exposed. For reference, the - means that no default should be given to the parameter, forcing you to override it at deployment time. This is likely what you want given you hopefully are not reusing workspaces between environments.

What is really nice is that you can make use of the new Azure Data Factory Management Hub to expose an editor to help you make these changes.

Hope that helps!

By default, particularly with workspaces in the standard tier, all users have access to all resources within the workspace. By resources, I mean specific Databricks “objects” such as directories, notebooks, clusters, pools, jobs and tables. Luckily, Azure Databricks offers a premium plan, which allows administrators to configure custom role-based access controls based on the permissions API.

When you are creating production Databricks workspaces, you are likely going to have two main use-cases. The first is job specific. This workspace is used to run pre-created reports and functions that have followed some type of development process and have been promoted into production. The second type is going to be more for exploratory type processing. End users will want to experiment and play with the data, creating notebooks in an interactive fashion and examining the results.

From a job specific workspace perspective, you likely want to have creation of new notebooks, jobs, clusters, etc locked down to only approved CI/CD processes. Because these jobs will likely be using service principals, ensuring that users cannot just create notebooks and run them would be of extreme importance. Of course, you will still have support personnel who will need to monitor job execution and results. Azure Databricks role-based access control can help with this use case.

For interactive clusters, you will likely want to ensure that users have “safe” places to create their notebooks, run jobs, and examine results. Because the results of the notebooks are stored with the notebook themselves, you’ll want to create appropriate role-based access controls to ensure that only users with the same security clearance can see their outputs. You may also want to create “home” directories only accessible by the individual users. Again, role-based access control is a good fit here.

Permissions Architecture

From an architecture perspective, the permissions in Azure Databricks is quite simplistic. Each object within a Databricks workspace (for example a notebook) has a set of “permissions” that can be associated with it.

For example, notebooks can have the following permissions:

• CAN_READ

  • Users can view and comment on a notebook

• CAN_RUN

  • Users can view, comment and also attach/detach the notebook from a cluster. They can also run commands within that notebook

• CAN_EDIT

  • All the above plus the ability to edit the notebook

• CAN_MANAGE

  • All the above and can also change permissions on the notebook

These permissions can be assigned to the respective objects along with a user or a group. This typically manifests itself as adding an access control list to that particular object. Generically, it looks something like this:

{
	"access_control_list"​: [
	{
		"user_name"​:​"<UserName>"​ || ​"group_name"​:​"<GroupName>" ,
		​"permission_level"​: ​"<PermissionLevel>
	}
	]
} 

Conclusion

At time of writing, permissions can be used in premium tier workspaces with workspace access control enabled. It is editable via the portal experience, and, if you ask nicely, you may get access to a preview for setting the permissions via script.

The term “bucket” as it relates to object storage is a term almost as old as the term “cloud computing”. In AWS, a bucket is effectively described as a container for objects. They are the highest level of organization for objects.

Because buckets are the only organization option available, general settings such as versioning, ACLs, default encryption, replication, logging, and lifecycle are set at this level.

In Azure, you create storage accounts that have child resources called containers. All blobs must live in a container. At a high level, account level settings are similar to the bucket level settings for AWS with the exception of access policies. In general, access policies are set/maintained at the container level.

Authentication Types

Both AWS and Azure have their services setup such that permissions on the management plane can bleed into permissions on the data plane.

In the case of AWS, identities for object storage access are either the root account or IAM users. Depending on which is in use, different authentication flows can be utilized. IAM users have the added steps of verifying authentication information and policies with IAM before making the request to S3. Here is an example of a authentication flow that shows all the options.

Important to note is that bucket owners are owners on all objects inside that bucket, regardless of any policies set within that bucket. See https://docs.aws.amazon.com/AmazonS3/latest/dev/access-control-overview.html for more information. Obviously, the guidance from AWS is to not use root credentials for access to storage accounts, rather create an IAM user and apply appropriate policies.

Azure storage functions in a very similar fashion to AWS S3. Firstly, anyone with appropriate permissions to the management plane of a storage account can also have full access to all items in the storage account. This is controlled via access to one of the two storage access keys (shared keys) that are provisioned with every account. RBAC permissions here are fairly important (which we will talk about later).

SAS tokens were originally introduced to solve issues with using shared keys for temporary access to the object storage. SAS tokens provide a way of generating temporary credentials that can be used to a subset of permissions for a period of time.

SAS tokens are not associated with users, which has inherent benefits and tradeoffs. The benefit is that I don’t need to have a user object associated with each token. The tradeoff is that managing and revoking SAS tokens becomes a bit of a chore. In a way, SAS Policies can be seen as an entity equivalent to IAM users. AWS STS can be seen (used) in a similar fashion to SAS tokens.

In short, it seems like both solutions (while architected quite differently) facilitate many of the common use cases one may require.

1 | Administrative access to buckets and objects

In AWS and Azure this is inherent in the design. Having appropriate access at the management plane level allows for access at the data plane level. In AWS, this is done via the policy system whereas in Azure this is done by controlling access to the shared access keys.

2 | Granular user access

In AWS, this type of access is easily provisioned as part of IAM users/roles configuration. In Azure, SAS tokens are used to provide granular access, but are not tied to users specifically. Concepts such as SAS Policies can be used to facilitate this. AAD based permissions (currently in preview) provides a better story around this use case.

3 | Temporary credentials

The valet key pattern is a core pattern from an application architecture standpoint. In Azure, this is easily accomplished via SAS tokens and policies. Each request can generate an appropriate SAS token which expires automatically.

In AWS, this is likely a combination of IAM users and AWS STS for issuing temporary credentials.