Premier Offerings: WorkshopPLUS Azure Security Best Practices

by Scott Muniz | Jul 1, 2020 | Azure, Microsoft, Technology, Uncategorized

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

G ‘day, I am Vic Perdana, Sr. PFE based in Melbourne, Australia.

As COVID-19 forces people to work from home, the number of bad actors is ramping up as demonstrated by the increase of cyber-attacks globally, it is becoming *very* important to educate ourselves with ways we can protect our IT assets from being compromised. 

IT Security is no longer a responsibility of the Security team but is everyone’s responsibility.  Moreover, as an IT engineer we have unprecedented responsibility to ensure that our system is secure especially as we expand our footprint to the cloud. I often get asked, how secure is cloud?  And as you know the answer is “it depends” on how much investment you’re willing to make to ensure it is secure. In Azure, we provide tons of security features, but not all customers are aware of these and this is the very reason this offering was created.

The Offering Overview

Within Microsoft Services, we provide a variety of support offerings which educate customers on several Azure Security-related features, and here the focus is our  WorkshopPLUS Azure Security Best Practices. 

The workshop introduces pivotal security controls to kickstart and improve your security journey in Azure. WorkshopPLUS designation signifies that hands-on labs will be part of the delivery experience. This enables you to implement various security concepts learned from Premier Field Engineer (PFE) knowledge sharing sessions and equips you with practical experience in a lab environment.

What’s Included

The content of this offering is a mix of governance, administration and security best practices at a L200-300 level which focuses on the breadth of Azure security topics. 

Azure Security Foundation

This module sets up the context of cloud security and not only applicable to Azure. Many customers may have a misconception cloud is not secure or the opposite, by moving to the cloud we are automatically secured. We will revisit the basic security concepts that are applicable to both on-premises and cloud environments plus a review of the shared responsibility concept of cloud security. 

You will be introduced with Microsoft Cybersecurity reference architecture which highlights  the vast Azure hybrid-security capabilities.

Azure Governance

Bruce Schneier famously mentions “security is a process, not a product” and here’s why you will examine this further by emphasizing that onboarding the whole organization in the security journey (the process) is a mandatory pre-requisite for a successful impact of configuring security services (the product). You will be introduced to relevant security components related to Azure Governance such as Subscription Management, Role-Based Access Control (RBAC), Azure Policy, Blueprints.

Azure Identity Protection

Identity is the modern security perimeter; hence, it is vital to understand the security controls and features available in Azure to secure our identity both on-premises and in the cloud. That’s why we start the module by revisiting our Securing Privileged Access (SPA) roadmap as it is still applicable when you go to the cloud.

Next, you are introduced to Azure advanced protections such as Conditional Access, Identity Protection, and various Azure Active Directory identity governance services which includes Access Reviews, Privileged Identity Management, and Entitlement Management.

Azure Network Security

As we extend our IT footprint to the cloud, our assets will no longer be within the perimeter of our data center.

In this module you will be introduced to modern network security controls and features in Azure that will allow you to extend and connect your on-premises networks securely, such as Express Route, DDoS protection, Azure Firewall, Network Security Groups, WAF, and much more.

Azure Data Protection

As Security professionals, protecting data is ultimately our objective; hence we will spend quality time in educating our customers on fundamental Azure services that will help with our mission to protect data.  Azure Key Vault is one of the core services which will be discussed including how we can leverage this effectively in a Business as Usual (BAU) setting.  We will also walkthrough features to secure services our customers use to store their data e.g., Azure Storage, Azure SQL, and Azure Information Protection.

PaaS Security

This module demonstrates the use of Key Vault in a Web App coupled with Managed Identity.  Deployment acceleration method with DevOps is widely used, we will cover the importance of embedding security in a DevOps process using  Secure DevOps Kit.

Security Operations

This is the module where we put things together and provide practical information related to our flagship Security services in Azure: Azure Security Center and Azure Sentinel.  We will also cover relevant technologies supporting these Security features such as Log Analytics, Activity Logs, and Azure Monitor.

Delivery model

This is a 3-day delivery (onsite or remote) led by an accredited Premier Field Engineer (PFE).  While we focus on the breadth of Azure security topics, we will be discussing implementation areas that provide highest impact to your organization. 

• Pre-engagement scoping call to highlight the overall engagement, including pre-requisites for a successful delivery.
• Knowledge Transfer and labs sessions
  • Azure Security Foundation
  • Azure Governance
  • Identity Protection
  • Azure Network Security
  • Virtual Machine Security
  • Data Protection
  • Securing PaaS
  • Security Operations
• Wrap up with a top 10 Azure security best practices

*For a closed workshop, there is an option to focus on some parts of the topics, but this needs to be agreed in advance as part of a scoping call.

Conclusion

Cybersecurity is a hot topic and there is no single product or a quick fix (band-aid) that can be applied to address security challenges.  This recent post from our National Security Officer highlights the importance of keeping our security hygiene in check.

Taking up this offering is a great start to kickstart and boost your security journey as you extend your IT footprint to the cloud.

What are you waiting for, ask your TAMs to reserve a spot! :)

Disclaimer

As of this writing, the above modules are in scope, however, they are subject to change as Azure Security offerings and the offering evolve responding to customers feedback.

Credit

Special thanks to the offering team: Elliot Huffman, Joao Paulo Ramos.

Released: Preview of Azure Arc enabled SQL Server

by Scott Muniz | Jul 1, 2020 | Azure, Microsoft, Technology, Uncategorized

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

We are making available the private preview of Azure Arc enabled SQL Server. The preview includes the following features:

• Use the Azure Portal to register and track the inventory of your SQL Server instances across on-premises, edge sites, and multi-cloud in a single view.
• Use Azure Security Center to produce a comprehensive report of vulnerabilities in SQL Servers and get advanced, real time security alerts for threats to SQL Servers and the OS.
• Investigate threats in SQL Servers using Azure Sentinel.

You can register any Windows or Linux based SQL Server to track your inventory. Azure Security Center’s advanced data security works on Windows-based SQL Server version 2012 or higher, running on virtual machines and physical servers and hosted on any infrastructure outside of Azure.

Here’s a video of the Arc enabled SQL Server experience with Azure Security Center.

If you are interested in participating in this preview, please fill out the sign-up form and select the option Server Management (SQL Server).

5 Ways Selecting Injected Instance from Multiple Instances of Same Interface on Azure Functions

by Scott Muniz | Jul 1, 2020 | Azure, Microsoft, Technology, Uncategorized

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

While building an Azure Functions application, setting an IoC container for dependency injection has many benefits by comparing to just using the static classes and methods. Azure Functions leverages the built-in IoC container featured by ASP.NET Core that is easy to use, without having to rely on any third-party libraries. Throughout this post, I’m going to discuss five different ways to pick up a dependency injected from multiple instances sharing with the same interface.

Implementing Interface and Classes

Let’s assume that we’re writing one IFeedReader interface and three different classes, BlogFeedReader, PodcastFeedReader and YouTubeFeedReader implementing the interface. There’s nothing fancy.

public interface IFeedReader
{
    string Name { get; }
    string GetSingleFeedTitle();
}

public class BlogFeedReader : IFeedReader
{
    public BlogFeedReader()
    {
        this.Name = "Blog";
    }

    public string Name { get; }

    public string GetSingleFeedTitle()
    {
        return "This is blog item 1";
    }
}

public class PodcastFeedReader : IFeedReader
{
    public PodcastFeedReader()
    {
        this.Name = "Podcast";
    }

    public string Name { get; }

    public string GetSingleFeedTitle()
    {
        return "This is audio item 1";
    }
}

public class YouTubeFeedReader : IFeedReader
{
    public YouTubeFeedReader()
    {
        this.Name = "YouTube";
    }

    public string Name { get; }

    public string GetSingleFeedTitle()
    {
        return "This is video item 1";
    }
}

IoC Container Registration #1 – Collection

Let’s register all the classes declared above into the Configure() method in Startup.cs.

public override void Configure(IFunctionsHostBuilder builder)
{
    builder.Services.AddTransient<IFeedReader, BlogFeedReader>();
    builder.Services.AddTransient<IFeedReader, PodcastFeedReader>();
    builder.Services.AddTransient<IFeedReader, YouTubeFeedReader>();
}

By doing so, all three classes have been registered as IFeedReader instances. However, from the consumer perspective, it doesn’t know which instance is appropriate to use. In this case, using a collection as IEnumerable<IFeedReader> is useful. In other words, inject a dependency of IEnumerable<IFeedReader> to the FeedReaderHttpTrigger class and filter one instance from the collection.

public class FeedReaderHttpTrigger
{
    private readonly IFeedReader _reader;

    public FeedReaderHttpTrigger(IEnumerable<IFeedReader> readers)
    {
        this._reader = readers.SingleOrDefault(p => p.Name == "Blog");
    }

    [FunctionName(nameof(FeedReaderHttpTrigger.GetFeedItemAsync))]
    public async Task<IActionResult> GetFeedItemAsync(
        [HttpTrigger(AuthorizationLevel.Function, "post", Route = "feeds/item")] HttpRequest req,
        ILogger log)
    {
        var title = this._reader.GetSingleFeedTitle();

        return new OkObjectResult(title);
    }
}

It’s one way to use the collection as a dependency. The other way to use the collection is to use a loop. It’s useful when we implement either a Visitor Pattern or Iterator Pattern.

public class FeedReaderHttpTrigger
{
    private readonly IEnumerable<IFeedReader> _readers;

    public FeedReaderHttpTrigger(IEnumerable<IFeedReader> readers)
    {
        this._readers = readers;
    }

    [FunctionName(nameof(FeedReaderHttpTrigger.GetFeedItemAsync))]
    public async Task<IActionResult> GetFeedItemAsync(
        [HttpTrigger(AuthorizationLevel.Function, "post", Route = "feeds/item")] HttpRequest req,
        ILogger log)
    {
        var title = default(string);
        foreach (reader in this._readers)
        {
            if (reader.Name != "Blog")
            {
                continue;
            }

            title = reader.GetSingleFeedTitle();
        }

        return new OkObjectResult(title);
    }
}

IoC Container Registration #2 – Resolver

It’s similar to the first approach. This time, let’s use a resolver instance to get the dependency we want. First of all, declare both IFeedReaderResolver and FeedReaderResolver. Keep an eye on the instance of IServiceProvider as a dependency. It’s used for the built-in IoC container of ASP.NET Core, which can access to all registered dependencies.

In addition to that, this time, we don’t need the Name property any longer as we use conventions to get the required instance.

public interface IFeedReaderResolver
{
    IFeedReader Resolve(string name);
}

public class FeedReaderResolver : IFeedReaderResolver
{
    private readonly IServiceProvider _provider;

    public FeedReaderResolver(IServiceProvider provider)
    {
        this._provider = provider;
    }

    public IFeedReader Resolve(string name)
    {
        var type = Assembly.GetAssembly(typeof(FeedReaderResolver))
                           .GetType($"{name}FeedReader");
        var instance = this._provider.GetService(type);

        return instance as IFeedReader;
    }
}

After that, update Configure() on Startup.cs again. Unlike the previous approach, we registered xxxFeedReader instances, not IFeedReader. It’s fine, though. The resolver sorts this out for FeedReaderHttpTrigger.

public override void Configure(IFunctionsHostBuilder builder)
{
    builder.Services.AddTransient<BlogFeedReader>();
    builder.Services.AddTransient<PodcastFeedReader>();
    builder.Services.AddTransient<YouTubeFeedReader>();

    builder.Services.AddTransient<IFeedReaderResolver, FeedReaderResolver>();
}

Update the FeedReaderHttpTrigger class like below.

public class FeedReaderHttpTrigger
{
    private readonly IFeedReader _reader;

    public FeedReaderHttpTrigger(IFeedReaderResolver resolver)
    {
        this._reader = resolver.Resolve("Blog");
    }

    [FunctionName(nameof(FeedReaderHttpTrigger.GetFeedItemAsync))]
    public async Task<IActionResult> GetFeedItemAsync(
        [HttpTrigger(AuthorizationLevel.Function, "post", Route = "feeds/item")] HttpRequest req,
        ILogger log)
    {
        var title = this._reader.GetSingleFeedTitle();

        return new OkObjectResult(title);
    }
}

IoC Container Registration #3 – Resolver + Factory Method Pattern

Let’s slightly modify the resolver that uses the factory method pattern. After this modification, it removes the dependency on the IServiceProvider instance. Instead, it creates the required instance by using the Activator.CreateInstance() method.

public class FeedReaderResolver : IFeedReaderResolver
{
    public IFeedReader Resolve(string name)
    {
        var type = Assembly.GetAssembly(typeof(FeedReaderResolver))
                           .GetType($"{name}FeedReader");
        var instance = Activator.CreateInstance(type);

        return instance as IFeedReader;
    }
}

If we implement the resolver class in this way, we don’t need to register all xxxFeedReader classes to the IoC container, but IFeedReaderResolver would be sufficient. By the way, make sure that all xxxFeedReader instances cannot be used as a singleton if we take this approach.

public override void Configure(IFunctionsHostBuilder builder)
{
    builder.Services.AddTransient<IFeedReaderResolver, FeedReaderResolver>();
}

IoC Container Registration #4 – Explicit Delegates

We can replace the resolver with an explicit delegates. Let’s have a look at the code below. Within Startup.cs, declare a delegate just outside the Startup class.

public delegate IFeedReader FeedReaderDelegate(string name);

Then, update Configure() like below. As we only declared the delegate, its actual implementation goes here. The implementation logic is not that different from the previous approach.

public override void Configure(IFunctionsHostBuilder builder)
{
    builder.Services.AddTransient<BlogFeedReader>();
    builder.Services.AddTransient<PodcastFeedReader>();
    builder.Services.AddTransient<YouTubeFeedReader>();

    builder.Services.AddTransient<FeedReaderDelegate>(provider => name =>
    {
        var type = Assembly.GetAssembly(typeof(FeedReaderResolver))
                           .GetType($"FeedReaders.{name}FeedReader");
        var instance = provider.GetService(type);

        return instance as IFeedReader;
    });
}

Update the FeedReaderHttpTrigger class. As FeedReaderDelegate returns the IFeedReader instance, another method call should be performed through the method chaining.

public class FeedReaderHttpTrigger
{
    private readonly FeedReaderDelegate _delegate;

    public FeedReaderHttpTrigger(FeedReaderDelegate @delegate)
    {
        this._delegate = @delegate;
    }

    [FunctionName(nameof(FeedReaderHttpTrigger.GetFeedItemAsync))]
    public async Task<IActionResult> GetFeedItemAsync(
        [HttpTrigger(AuthorizationLevel.Function, "post", Route = "feeds/item")] HttpRequest req,
        ILogger log)
    {
        var title = this._delegate("Blog").GetSingleFeedTitle();

        return new OkObjectResult(title);
    }
}

IoC Container Registration #5 – Implicit Delegates with Lambda Function

Instead of using the explicit delegate, the Lambda function can also be used as the implicit delegate. Let’s modify the Configure() method like below. As there is no declaration of the delegate, define the Lambda function.

public override void Configure(IFunctionsHostBuilder builder)
{
    builder.Services.AddTransient<BlogFeedReader>();
    builder.Services.AddTransient<PodcastFeedReader>();
    builder.Services.AddTransient<YouTubeFeedReader>();

    builder.Services.AddTransient<Func<string, IFeedReader>>(provider => name =>
    {
        var type = Assembly.GetAssembly(typeof(FeedReaderResolver))
                           .GetType($"FeedReaders.{name}FeedReader");
        var instance = provider.GetService(type);

        return instance as IFeedReader;
    });
}

As the injected object is the Lambda function, FeedReaderHttpTrigger should accept the Lambda function as a dependency. While it’s closely similar to the previous example, it uses the Lambda function this time for dependency injection.

public class FeedReaderHttpTrigger
{
    private readonly Func<string, IFeedReader> _func;

    public FeedReaderHttpTrigger(Func<string, IFeedReader> func)
    {
        this._func = func;
    }

    [FunctionName(nameof(FeedReaderHttpTrigger.GetFeedItemAsync))]
    public async Task<IActionResult> GetFeedItemAsync(
        [HttpTrigger(AuthorizationLevel.Function, "post", Route = "feeds/item")] HttpRequest req,
        ILogger log)
    {
        var title = this._func("Blog").GetSingleFeedTitle();

        return new OkObjectResult(title);
    }
}

—

So far, we have discussed five different ways to resolve injected dependencies using the same interface, while building an Azure Functions application. Those five approaches are very similar to each other. Then, which one to choose? Well, there’s no one approach better than the other four, but I guess it would depend purely on the developer’s preference.