Azure Active Directory Identity Protection

Security is a top concern when managing databases, and it has always been a priority for Azure SQL Database. Your databases can be tightly secured to help satisfy most regulatory or security requirements, including HIPAA, ISO 27001/27002, and PCI DSS Level 1, among others. A current list of security compliance certifications is available at the Microsoft Trust Center site. You also can choose to place your databases in specific Azure datacenters based on regulatory requirements.

How you can learn to enable Azure Active Directory Identity Protection is a feature of the Azure AD Premium P2 edition that provides you an overview of the risk events and potential vulnerabilities affecting your organization’s identities. Microsoft has been securing cloud-based identities for over a decade, and with Azure AD Identity Protection, Microsoft is making these same protection systems available to enterprise customers. Identity Protection uses existing Azure AD’s anomaly detection capabilities available through Azure AD’s Anomalous Activity Reports, and introduces new risk event types that can detect real time anomalies.

Identity Protection uses adaptive machine learning algorithms and heuristics to detect anomalies and risk events that may indicate that an identity has been compromised. Using this data, Identity Protection generates reports and alerts that enable you to investigate these risk events and take appropriate remediation or mitigation action.

Security is a top concern when managing databases, and it has always been a priority for Azure SQL Database. Your databases can be tightly secured to help satisfy most regulatory or security requirements, including HIPAA, ISO 27001/27002, and PCI DSS Level 1, among others. A current list of security compliance certifications is available at the Microsoft Trust Center site. You also can choose to place your databases in specific Azure datacenters based on regulatory requirements.

In this article, we will discuss a collection of Azure database security best practices. These best practices are derived from our experience with Azure database security and the experiences of customers like yourself.

Azure database security best practices are:

• Use firewall rules to restrict database access
• Enable database authentication
• Protect your data using encryption
• Protect data in transit
• Enable database auditing
• Enable database threat detection

Handle faults that might take a variable amount of time to recover from, when connecting to a remote service or resource. This can improve the stability and resiliency of an application.

Challenge

In a distributed environment, calls to remote resources and services can fail due to transient faults, such as slow network connections, timeouts, or the resources being overcommitted or temporarily unavailable. These faults typically correct themselves after a short period of time, and a robust cloud application should be prepared to handle them by using a strategy such as the Retry Design Pattern.

However, there can also be situations where faults are due to unanticipated events, and that might take much longer to fix. These faults can range in severity from a partial loss of connectivity to the complete failure of a service. In these situations it might be pointless for an application to continually retry an operation that is unlikely to succeed, and instead the application should quickly accept that the operation has failed and handle this failure accordingly. Additionally, if a service is very busy, failure in one part of the system might lead to cascading failures. 

Solution

The Circuit Breaker pattern can prevent an application from repeatedly trying to execute an operation that’s likely to fail. Allowing it to continue without waiting for the fault to be fixed or wasting CPU cycles while it determines that the fault is long lasting. The Circuit Breaker pattern also enables an application to detect whether the fault has been resolved. If the problem appears to have been fixed, the application can try to invoke the operation.

The purpose of the Circuit Breaker pattern is different than the Retry pattern. The Retry pattern enables an application to retry an operation in the expectation that it’ll succeed. The Circuit Breaker pattern prevents an application from performing an operation that is likely to fail. An application can combine these two patterns by using the Retry pattern to invoke an operation through a circuit breaker. However, the retry logic should be sensitive to any exceptions returned by the circuit breaker and abandon retry attempts if the circuit breaker indicates that a fault is not transient.

I am going to use Visual Studio to create azure logic app. 

Launch Visual Studio and select File -> New Project -> Cloud -> Resource Group

Give it a name and then you’ll need to choose a template. Scroll down until you see Logic App.

Once everything spins up, you’ll notice you have the following file structure in Visual Studio.

• Deploy-AzureResourceGroup.ps1 – Is a PowerShell deployment script for the Logic App
• LogicApp.json – This is where your main logic for your Logic App Lives
• LogicApp.parameters.json – The parameters file that you’ll mostly want to leave alone

If you click on the LogicApp.json you’ll see the code and a JSON Outline in Visual Studio and you could begin hand coding your app. Go ahead and go to Tools and Extensions and search for Logic Apps and press Download.

A VSIX installer will appear after you close out of Visual Studio and just follow the steps to install it. Now you can right click your LogicApp.json and have the ability to open it with the Designer.

Fire up Visual Studio 2017 Logic App project. Right click on the name of your project and select Deploy and then either New or an existing resource group. It will prompt you to login, so do so now. 

If there are any fields that you missed, then it will prompt you to enter them now. In my case, I had not set the name and it prompted me to do so. Now you’ll see in the output window that it calls the PowerShell script to deploy the resources for your Logic App. Once it finishes deploying, log into the Azure Portal to see your new resource.