by Contributed | Oct 6, 2020 | Uncategorized
This article is contributed. See the original author and article here.
The Azure App Service is offered as two deployment types: the multi-tenant service and the App Service Environment. In the multi-tenant service there are thousands of customers on the same infrastructure. Your apps are always secured but they share the network, address space, front ends, and some other components. In an App Service Environment you get a single tenant version of App Service that runs in your Azure Virtual Network. In this article, you will learn how to build network-secured, multi-tier web applications in the multi-tenant App Service.
Multi-tier web applications
The obvious question to start with is, what is a multi-tier web application? A multi-tier web application is an application with a front end that makes calls to one or more API applications behind it. By itself this is not a complex concept, but when a user wants to secure the API applications so they are not internet accessible the architecture becomes more complex.
There are multiple ways to secure your API applications so that they can only be reached from your front end applications. They all involve securing your API application’s inbound traffic. There are multiple features that could be used for this purpose:
- Service endpoints secure the listening service. With Service Endpoints, the source address must be in an Azure Virtual Network subnet.
- Private endpoints prevent data exfiltration and secure the listening service. With private endpoints, you can reach the web app from anywhere that has network access to the private endpoint address.
- Access restrictions can lock down your inbound traffic to a set of address blocks.
Each of those features satisfies a specific situation and there are trade offs. Access restrictions are useful if you have public address access points like NAT devices or perhaps a virtual network device with a dedicated public address. If you use service endpoints, you do not add any new resources to your subscription and are able to use one subnet. If you use private endpoints you will add a new top level resource, add Azure DNS private zones to your VNet and will require two subnets. Let’s now dicsuss each of these options in greater detail.
Service endpoints
To configure a multi-tier application using service endpoints to secure your API application, you need to use VNet Integration with your front end app and service endpoints with your API app. Set service endpoints on the integration subnet used by your Front End application. This solution is fast to set up and easy as well.
If you have multiple front end apps, the configuration is the same if all of the front end apps are in the same App Service plan. With VNet Integration, the apps in the same App Service plan can use the same integration subnet. If you have additional front end applications in separate App Service plans, you will need to use multiple integration subnets. In this situation, service endpoints must be configured against each of the integration subnets. With VNet Integration, you cannot have more than one App Service plan configured with a subnet.
If you have multiple API apps and multiple front end apps from separate App Service plans, you need to configure VNet Integration from each front end app and then service endpoints on each API app against the integration subnets.
As you add front end applications, you need to configure service endpoints with each dependent API application. This means service endpoints are great at smaller scale. It can quickly get out of hand if you have many–or an ever increasing number of–front end applications with multiple API applications. Managing the configuration can be confusing as the number of front ends grows.
Private endpoints
With private endpoints, the configuration is both easier and harder. It is easier in that when you place a private endpoint in your VNet for an app, you are done managing the inbound traffic to your API app. Unlike with service endpoints, there is no additional configuration to your API app as you add new front end consumers. It is harder because setting up private endpoints creates a new, top-level resource and Azure DNS private zones.
If you have one front end app or more than that, the configuration is the same. You set up VNet Integration with the same VNet that your API app has a private endpoint in. You also have private endpoints configured on your API application.
If you have more than one front end app, the only difference is that this second front end app needs VNet Integration to be configured with it. If this additional front end application is in a different App Service plan, it will use a separate subnet. Each time you use VNet Integration from another App Service plan, you will need another subnet for integration.
If you have multiple API applications, you will need multiple private endpoints. Those private endpoints can be in the same subnet, or not. Private endpoints are more flexible in this regard than VNet Integration. Once your API application has exposed itself with a private endpoint, any front end app that integrates with that VNet should be able to reach it.
At a small scale, private endpoints incurs more overhead. You will have more to manage and maintain than with service endpoints. On the other hand, private endpoints are a solution for data exfiltration concerns. They also do better at scale as it is easy to add more front end applications.
Access restrictions
With access restrictions you can secure inbound traffic to a set of IP address blocks. This is useful when you want to lock your traffic to a set of egress devices. You can also use it with other edge protection services such as Azure Front Door. With respect to using it directly with multi-tier applications, you can secure your API applications to the egress addresses used by your front end applications. The problem with this approach is that the outbound addresses are shared with all of the other customers in the same scale unit. From a security review perspective it doesn’t look as secure as service endpoint or private endpoint based solutions. So while it is possible and worth noting, it is not recommended to use access restrictions to create multi-tier web applications.
by Contributed | Oct 6, 2020 | Uncategorized
This article is contributed. See the original author and article here.
Before taking a journey through the lifecycle of an item in Sharepoint, I recommend reading the following Microsoft Docs covering retention in M365. These docs will give you the requisite knowledge of the retention features in M365 before we dive a bit deeper here.
Retention policies help you retain what you need to preserve and delete what you no longer need. What is the difference between a retention label and a retention policy? Let’s take a step back to explain a few gotchas first:
- Labels are applied at the item level (folder, document, or email) whereas retention policies are applied at a container level (mailbox or site).
- All retention policies contain at least one retention rule. The rule defines how long an item is retained and/or when it is deleted. You will notice that when you create a retention policy, the associated retention rule is automatically created.
- A retention policy defines where the rule(s) are applied.
A retention label is simply a retention rule with a few extra features:
- You have can trigger a disposition at the end of the retention period
- You can declare the item as a record or regulatory record
- The enforcement point can be based on an event or when the label was applied
A label policy is simply a retention policy with a few extra features:
Now that you understand the difference between a retention label and a retention policy, our team is ready to take you through a visual representation of the different containers in which an item may reside throughout its lifecycle in SharePoint. The scenarios will show what actions are taken on the item based on each potential retention scenario.
We already know that retention takes precedence over deletion and that the longest retention period always wins. What happens if I have a 2-year delete policy applied to a site alongside an item that has a 3-year retention label? What happens if I apply a 3-year delete label to an item that resides in a site with a 10-year retention policy? While the principles of retention will always be your north star, it can help to have some visual guidance to understand where these items move and when.
For the scenarios below, the Retention Policy (Site level) and the Retention Label (item level) are both configured based on the items creation to Retain and then Delete:
- The Retention Label (item level) is configured to retain for 3 years and then delete
- The Retention Policy (site level) is configured to retain for 10 years and then delete
- The Deletion policy (site level) is configured to delete after 2 years
*NOTE: The Recycle Bin is not indexed and therefore unavailable for searching. As a result, an eDiscovery search cannot find any Recycle Bin content on which to place a hold.
_______________________________________________________________________________________________________________________________________________________________
Scenario 1: End-user takes NO action on the item
Example #1
Policies or Labels: NONE
Actions: The item remains in place.
Example #2
Policies or Labels: Deletion Policy in Place
Actions: The deletion policy will delete the item 2 years after creation.
Example #3
Policies or Labels: Retention Policy in Place
Actions: The item will be deleted 10 years after creation.
Example #4
Policies or Labels: Retention Label in Place
Actions: The item will be deleted 3 years after creation.
Example #5
Policies or Labels: Retention Policy in Place + Deletion Policy in Place
Actions: The item will be deleted after 2 years due to the deletion policy. The retention policy still in effect and a copy of item will be retained in the PHL for the remainder of the 10 years.
Example #6
Policies or Labels: Retention Label in Place + Deletion Policy in Place
Actions: The retention label prevents the deletion policy from deleting the item. The item will only be deleted at the end of the label retention duration after 3 years.
Example #7
Policies or Labels: Retention Label in Place + Retention Policy in Place + Deletion Policy in Place
Actions: The retention label prevents the deletion policy from deleting the item. The item will only be deleted at the end of the label retention duration after 3 years.
________________________________________________________________________________________________________________________________________________________________
Scenario 2 – User takes no action on item but empties recycle bin. This triggers a move from first stage recycle bin to second stage recycle bin.
Example #1
Policies or Labels: NONE
Actions: There is no action taken on the item.
Example #2
Policies or Labels: Deletion Policy in Place
Actions: The item will be deleted after 2 years due to the deletion policy.
Example #3
Policies or Labels: Retention Policy in Place
Actions: The item will be deleted 10 years after creation.
Example #4
Policies or Labels: Retention Label in Place
Actions: The item will only be deleted at the end of the label retention duration after 3 years.
Example #5
Policies or Labels: Retention Policy in Place + Deletion Policy in Place
Actions: The item is deleted after 2 years. After deletion, the retention policy still in effect and will retain a copy of the item in the PHL for the remainder of the 10 years.
Example #6
Policies or Labels: Retention Label in Place + Deletion Policy in Place
Actions: The retention label prevents the deletion policy from deleting the item. The item will only be deleted at the end of the label retention duration after 3 years.
Example #7
Policies or Labels: Retention Label in Place + Retention Policy in Place + Deletion Policy in Place
Actions: The retention label prevents the deletion policy from deleting the item. The item will only be deleted at the end of the label retention duration after 3 years. Upon deletion, the retention policy is still in effect and will retain a copy of the item in the PHL for the remainder of the 10 years.
________________________________________________________________________________________________________________________________________________________________
Scenario 3 – User deletes item in first 2 years and does not empty the recycle bin
Example #1
Policies or Labels: NONE
Actions: The end-user deletes item from list or library with no policies in place. Item moves to 1st stage recycle bin.
Example #2
Policies or Labels: Deletion Policy in Place
Actions: The deletion policy has no impact. The item was deleted before the deletion policy could take action.
Example #3
Policies or Labels: Retention Policy in Place
Actions: The retention policy is in effect and will retain a copy of item in the PHL for the remainder of the 10 years.
Example #4
Policies or Labels: Retention Label in Place
Actions: The end-user is prevented from deleting the item due to the label. The item will only be deleted at the end of the label retention duration of 3 years.
Example #5
Policies or Labels: Retention Policy in Place + Deletion Policy in Place
Actions: The deletion policy has no impact here as the end-user deleted the item before 2 years. The retention policy still in effect and will retain a copy of item in the PHL for the remainder of the 10 years.
Example #6
Policies or Labels: Retention Label in Place + Deletion Policy in Place
Actions: The retention label prevents both the end-user and deletion policy from deleting the item. The item will only be deleted at the end of the label retention duration of 3 years.
Example #7
Policies or Labels: Retention Label in Place + Retention Policy in place + Deletion Policy in Place
Actions: The retention label prevents both the end-user and deletion policy from deleting the item. The item will only be deleted at the end of the label retention duration of 3 years. The retention policy still in effect and will retain a copy of the item in the PHL for the remainder of the 10 years.
________________________________________________________________________________________________________________________________________________________________
Scenario 4 – User deletes item within the first 2 years and does empty recycle bin. This triggers move from the first stage recycle bin to second stage recycle bin.
Example #1
Policies or Labels: NONE
Actions: User deletes item from list or library with no policies in place.
Example #2
Policies or Labels: Deletion Policy in Place
Actions: The deletion policy has no impact here. The item was deleted by the end-user.
Example #3
Policies or Labels: Retention Policy in Place
Actions: User deletes the original copy. The retention policy still in effect and will retain a copy of the item in the PHL for the remainder of the 10 years.
Example #4
Policies or Labels: Retention Label in Place
Actions: User deletion is prevented by label. The item will only be deleted at the end of the label retention duration of 3 years.
Example #5
Policies or Labels: Retention Policy in Place + Deletion Policy in Place
Actions: The deletion policy has no impact here. The retention policy still in effect and will retain a copy of item in the PHL for the remainder of the 10 years.
Example #6
Policies or Labels: Retention Label in Place + Deletion Policy in Place
Actions: The retention label prevents both the end-user and deletion policy from deleting the item. The item will only be deleted at the end of the label retention duration of 3 years.
Example #7
Policies or Labels: Retention Label in Place + Retention Policy in place + Deletion Policy in Place
Actions: The retention label prevents both the end-user and the deletion policy from deleting the item. The item will only be deleted at the end of the label retention duration after 3 years. Upon deletion, the retention policy still in effect and will retain the item in the PHL for the remainder of the 10 years.
________________________________________________________________________________________________________________________________________________________________
@Stefanie_Bier and Ryan Sturm (@SnCadvct4all) of the M365 MIP and Compliance CxE team!
by Contributed | Oct 6, 2020 | Uncategorized
This article is contributed. See the original author and article here.
TL;DR – Survey is available at: https://aka.ms/MIP/FeatureSurvey-21H1
Hello Microsoft Security and Compliance tech community
I’m excited to announce that the MIP + DLP 21H1 customer feature survey is now open!
This survey captures the top asks we captured from our customers via the various engagements, discussions and UserVoice suggestions.
The survey is available at: https://aka.ms/MIP/FeatureSurvey-21H1 and it will be opened for the next 2 weeks.
As the platform have really grown over the last few months, this survey is now longer than before and allows you to select to provide your feedback for MIP, DLP or both.
If you want to influence the platform with features and capabilities that you want, need and like, this is the time to make it happen and share your feedback.
Thanks,
Nir Hendler on behalf of the Microsoft Information Protection + Data Loss Prevention product groups
by Contributed | Oct 6, 2020 | Azure, Technology, Uncategorized
This article is contributed. See the original author and article here.
Microsoft Azure SQL Edge, now generally available, and DH2i DxOdyssey for IoT are combining native on-device capabilities with dynamic tunneling technology for an optimal IoT edge security solution.
It’s no news that IoT devices are generating more and more of data, but did you know that ? *
With so much data being created at the edge, security is one of the top concerns for IoT adopters. In a recent study, 97% of IoT adopters have security concerns when implementing IoT, and the top concern was ensuring data privacy.** Data needs to be protected both at the edge and as it moves outside the device boundaries to edge networks and other external networks and devices.
Azure SQL Edge is a small footprint data engine optimized for IoT workloads.
Built on the same code base as Microsoft SQL Server and Azure SQL, Azure SQL Edge provides the same industry leading security, familiar developer experience, and tooling that many teams already know and trust – now extended to IoT deployments for real-time intelligence.
Thanks to this shared codebase, application developers who have been building solutions for SQL Server and Azure SQL can extend their skills to deploy the same code to build IoT solutions at the edge that work with or without network connectivity.
Azure SQL Edge answers the need for an IoT-specific data platform by:
- Providing the flexibility to develop solutions that work with or without network connectivity and help enable secure data movement of the local edge data to on-premises datacenters or to the cloud.
- Offering support with standard tooling, programming languages, and a query language (T-SQL) that are already familiar to developers and compatible with existing code.
- Enabling artificial intelligence (AI) and analytics at the edge.
- Including native support for ingesting and streaming time-series data.
Unparalleled database security of the Microsoft SQL data engine.
The same security features of SQL Server Enterprise available in Azure SQL Edge ensure your data is secure on the device, customer data will be kept safe, and regulatory compliance will be met.
Here are the built-in security features that you won’t have to worry about in your solution thanks to Azure SQL Edge:
- Role-based access control (RBAC) and attribute-based access control (ABAC) to manage access to specific resources based on the user’s group (or role) and/or based on the attributes of the user, target data or resource
- Data protection with the ability to encrypt sensitive data and execute rich computations on encrypted data with Transparent Data Encryption (TDE) and Always Encrypted capabilities
- Sensitive PII/GDPR data discovery using SQL Data Discovery and Classification tool in SSMS
- Data classification to help organizations comply with security regulations by allowing data to be categorized by sensitivity and business impact
Azure SQL Edge extends the security of Azure and SQL Server to the Edge, protecting your data within the database and the Azure IoT Hub infrastructure.
Enhanced secure data movement with DxOdyssey
Beyond the security of the Azure SQL Edge and Azure IoT Hub network, Microsoft has partnered with DH2i to support enhanced security of data movement with its Software Defined Perimeter (SPD) software, DxOdyssey for IoT. DH2i is a software vendor with over 10 years of experience helping customers around the world enhance their data security and SQL Server capabilities with their innovative software offerings. Where common approaches to networking such as VPNs, open ports and SD-WAN are insufficient and lack the security capabilities required to support IoT deployments, DH2i’s DxOdyssey (DxO) for IoT extends SDP software capabilities to edge devices, allowing seamless bi-directional access from edge devices to the datacenter and cloud. As data moves outside of edge device perimeters and between networks, DxO for IoT ensures the data remains secure.
DxO for IoT is purpose-built for IoT use cases where bi-directional communication is needed between edge devices such as sensors, edge gateways or edge servers. Its technology:
- provides discreet, private and secure network communication over untrusted networks, such as the public internet.
- eliminates the lateral network attack surface and is more secure and performant than VPNs, open ports or SD-WAN.
- creates a Zero Trust network architecture for IoT devices and applications while consistently proving less expensive, easier and more effective than those legacy alternatives.
This lightweight software runs on any Linux or Windows host and can be installed on any IoT device or container on x64 and ARM 64 architecture.
When used in tandem with Azure SQL Edge, organizations can ensure their data is secure on the edge device and when passing outside of edge networks and IoT Hub boundaries.
Join us on October 21 to deep dive into edge security and learn about Azure SQL Edge and DxOdyssey for IoT including a demo of how to securely connect a remote user to an edge device, Register Now
* “Edge Computing Solutions for Industrial IoT”, July 2018, Gartner, “Top Strategic IoT Trends and Technologies Through 2023” September 2018, Gartner
** “IoT Signals” September 2020, Microsoft.
Recent Comments