Host DKE on IIS, using an on-premises server

by Contributed | Oct 23, 2020 | Technology

This article is contributed. See the original author and article here.

Double Key Encryption (DKE) is a new feature, which enables customers to protect their most confidential content using a key they control, thereby allowing them to comply with regulatory requirements. DKE ensures that Microsoft cannot access their data under any circumstances.

The quickest way to get the DKE reference implementation running is by publishing it to Azure – detailed steps can be found in our documentation . However, many of our customers prefer to test and run DKE on-premises – here we describe the necessary steps to implement this option.

For this post, we assume the server will be reachable under the following URL:

https://aip-dke4.contoso-o365.net

Preparation

Whether the DKE service is published on Azure or on IIS, the following preparation steps from our documentation are required:

1. Install software prerequisites for the DKE service


2. Clone the Double Key Encryption GitHub repository


3. Modify application settings


4. Generate test keys


5. Build the project
   
   

Provision machine and build IIS

By going through the following steps, the virtual machine is provisioned and IIS is installed:

1. Provision VM with Windows Server 2019 Datacenter.


2. Make sure the VM has outbound Internet Connectivity (among other, it needs to reach the following URL: <https://login.microsoftonline.com/common/v2.0>), for an exhaustive list of URLs and IP addresses, please consult box 56 on our documentation:URLs and IP addresses that need to be reachable


3. Join the server to a domain, in case membership of a local AD group should be the criteria for authorizing access to the DKE service.


4. Install a suitable Web server certificate to the machine store. The certificate needs to match the URL, under which the service can be reached.
   Certificate used for IIS


5. Install IIS with with default role features – selecting «Next» on each page of the wizard.
   
   


6. Download and install the .NET 3.1.9 hosting bundle. The bundle is available here.

Build and publish code to IIS

1. Switch to the machine with Visual Studio Code installed, which was used for steps 1 to 5.


2. Open an administrative command line and switch to the directory «DoubleKeyEncryptionServicesrccustomer-key-store»


3. Run the following command:
   dotnet publish –configuration Release


4. Transfer the following directory to the folder c: of the IIS machine – this will result in a new folder c:publish on the IIS machine:
   «DoubleKeyEncryptionServicesrccustomer-key-storebinReleasenetcoreapp3.1publish»


5. On IIS, create a new web site «DKE» with https binding, port 443 and using host name “aip-dke4.contoso-o365.net”:
   IIS site configuration


6. Make sure the value for «JwtAudience» matches the selected URL for the IIS Server:
   

Finish DKE implementation

The following steps are needed to complete the DKE implementation (refer again to our documentation)

7. Validate your deployment

8. Register your key store

9. Create sensitivity labels using DKE

10. Enable DKE in your client

11. Migrate protected files from HYOK labels to DKE labels

Conclusion

By publishing the DKE service on an on-premises server with IIS, customers maintain full control over the key used for protecting their most sensitive content.

Azure Policy for AKS

by Contributed | Oct 22, 2020 | Technology

This article is contributed. See the original author and article here.

Azure Policy for Azure Kubernetes Service (AKS) clusters now utilizes/extends Gatekeeper v3 (OPA). The overview, installation steps for the Azure Policy add-on, limitations and recommendations are documented here – https://aka.ms/kubepolicydoc
Azure Security Center actually requires the add-on to audit and enforce security capabilities and compliance inside your clusters.

I am depicting the 3 Gatekeeper pods in the following image – which are  utilized after the Azure Policy add-on has been enabled for an AKS cluster.

By installing / enabling  the Azure Policy add-on customers can gain the inherent benefits of utilizing a managed add-on – the most important benefit being that  – they would not need to resort to any manual upgrades if/when there is a version upgrade of Gatekeeper itself.

However, at present there are a few limitations. Let us focus on 2  limitations from the present list –
1.Installations of Gatekeeper outside of the Azure Policy Add-on aren’t supported. Uninstall any components installed by a previous Gatekeeper installation before enabling the Azure Policy Add-on.
2. Only built-in policy definitions are supported.
This means that the customer would not be able to utilize custom policies – considering – only built-in policies are supported + the usage of the add-on precludes any native Gatekeeper installation/usage.

So, for customers requiring policies beyond the list of built-in policies the overarching guidance is to use a combination of preventive and detective measures to achieve the same objective as their intended custom policies.
As an example – one of the customers wanted to take the policy driven route to ensure that the [default] namespace usage is always prohibited. At the time of this writing – it is not a built-in policy – so a preventive measure this customer could take is utilize Kubernetes native capabilities / RBAC as part of their deployment pipeline not allowing objects to be created in the [default] namespace.
Essentially, a preventive process enhancement to achieve their original objective.

The Azure Policy add-on is indeed an advantage-laden route  to take  – utilizing the set of built-in Kubernetes policies as applicable in combination with preventive and detective measures to achieve the any custom policy intent.

Access safeguard hold details with Update Compliance

by Contributed | Oct 22, 2020 | Technology

This article is contributed. See the original author and article here.

IT administrators using Update Compliance now have access to information on which safeguard holds are preventing individual devices in their organization from updating to a new version of Windows 10.

What are safeguard holds?

Microsoft uses quality and compatibility data to identify issues that might cause a Windows 10 feature update to fail or roll back. When find such an issue, we might apply holds to the updating service to prevent affected devices from installing the update in order to safeguard them from these experiences. We also use holds when a customer, a partner, or Microsoft internal validation finds an issue that would cause severe impact (for example, rollback of the update, data loss, loss of connectivity, or loss of key functionality) and when a workaround is not immediately available.

Safeguard holds prevent a device with a known issue from being offered a new operating system version. We renew the offering once a fix is found and verified. We use holds to ensure customers have a successful experience as their device moves to a new version of Windows 10.

The lifespan of holds varies depending on the time required to investigate and fix an issue. During this time Microsoft works diligently to procure, develop, and validate a fix and then offer it to affected devices. We monitor quality and compatibility data to confirm that a fix is complete before releasing the hold. Once we release the hold, Windows Update will resume offering new operating system versions to devices. Safeguard holds only affect devices that use the Window Update service for updates. We encourage IT admins who manage updates to devices through other channels (such as media installations or updates coming from Windows Server Update Services (WSUS)) to remain aware of known issues that might also be present in their environments.

How can you monitor safeguard holds impacting devices in your organization?

Previously, IT administrators using Update Compliance could see which devices were unable to update due to safeguard holds, but did not have any information on which individual hold was preventing the device from updating. We have made improvements to Update Compliance to address this customer pain point.

Update Compliance now supports two queries designed to help you retrieve data related to safeguard holds. The first query, “Devices with a safeguard hold”, shows the device data for all devices impacted by safeguard holds. The second query, “Target build distribution of devices with a safeguard hold”, shows data specific to how many devices are prevented from updating and which build version they belong to. One commercial ID can have devices that could be on different OS build versions. The “Target build distribution” queries displays the devices belonging to different build versions impacted by safeguard holds in the form of a chart.

Safeguard holds as they appear in Update Compliance

Update Compliance reporting surfaces the safeguard hold IDs for known issues impacting a device in the ‘DeploymentErrorCode’ column.  Every safeguard hold has a unique ID associated with it. Safeguard hold IDs for documented issues will be included in the Windows release health dashboard. To determine which safeguard hold is preventing your device’s update, go to the “Known issues and notifications” page for the specific version to which you are attempting to update (e.g. Known issues and notifications for Windows 10 and Windows Server, version 20H2). Once you have navigated to the appropriate known issues and notifications page, search (Ctrl + F) for the safeguard ID blocking your device (e.g. “25178825”). This process enables you to easily look up information related to the safeguard hold impacting your devices if that safeguard hold’s documentation is publicly available. 

Safeguard IDs as they appear on the Windows release health dashboard

Microsoft publicly discloses information about safeguard holds preventing Windows updates when the holds are broadly applied, and Microsoft can independently address the issues driving the block. When a safeguard is the result of third-party software or hardware incompatibilities, Microsoft is subject to confidentiality requirements. Only in certain circumstances are we authorized to disclose original equipment manufacturer-driven holds.

Safeguard holds help deliver a positive update experience. Similarly, this new reporting capability in Update Compliance helps to ensure that IT administrators have a positive management experience with the insights they need to effectively manage the devices in their organization. This is another step in our path toward providing IT administrators with greater transparency and control when managing Windows updates.

Zone Redundancy for Azure SQL Database general purpose tier now in preview

by Contributed | Oct 22, 2020 | Technology

This article is contributed. See the original author and article here.

Now in preview, your new and existing Azure SQL Databases and elastic pools that use the general purpose tier can enable the zone redundant configuration. The zone redundant configuration utilizes Azure Availability Zones to replicate databases across multiple physical locations within an Azure region. By selecting zone redundancy, you can make your general purpose single databases and elastic pools resilient to a much larger set of failures, including catastrophic datacenter outages, without any changes of the application logic. For more information see general purpose service tier zone redundant availability. 

How to enable the zone redundant configuration

The zone redundant configuration can be enabled for both new and existing general purpose databases and elastic pools. Once the zone redundant option is enabled, Azure SQL Database will automatically reconfigure the database or pool. You can configure this setting by using Portal, CLI, PowerShell, or ARM API.

Portal

The following diagram illustrates how to use Azure portal to configure a general purpose elastic pool to be zone redundant.

CLI

The following CLI commands can be used to enable the zone redundant configuration using the –zone-redundant {false, true} parameter.

• az sql db create


• az sql elastic-pool create


• az sql db update


• az sql elastic-pool update

PowerShell

The following PowerShell commands can be used to enable the zone redundant configuration using the -ZoneRedundant parameter.

• New-AzSqlDatabase


• New-AzSqlElasticPool


• Set-AzSqlDatabase


• Set-AzSqlElasticPool

ARM

The zone redundant configuration can be enabled using create or update in ARM.

Regions where this is available

Zone redundant general purpose Azure SQL databases and pools are available in preview in the following regions:

• East US


• East US 2


• West US 2


• North Europe


• West Europe


• Southeast Asia


• Australia East

Additional regions will be added over time. Visit the documentation for up to date information on regions that support Availability Zones in Azure.

Please visit the pricing pages for single databases and elastic pools for pricing details for this configuration.