The security configuration of Azure services is a fairly broad subject area, and this is more of an introduction to how it works for a Resource Group, in the context of a Logic App that needs to interact with multiple resources. If a DevOps team, instead of the developers, is managing the security, a considerable amount of time will be spent planning and designing services beforehand, and later trying to figure out which security configurations are preventing the services working.
Obviously, with so many people having watched Mr. Bates vs The Post Office, and learning, through the dramatised version of events, the extent of what could safely be called a huge cover-up, the public wasn’t going to be content with yet another inquiry concluding with the usual crap about ‘failures in The System’ and ‘lessons being learned’ before the whole affair is forgotten about and it’s business as usual. I think that desensitisation to inquiry after inquiry over the scandals du jour is why it took an ITV drama to get the government to actually take it seriously.
A security incident was flagged this week. As it turned out, nothing was compromised, but it served as a valuable warning of how vulnerable an organisation using Microsoft Azure (or perhaps AWS) could be to a subdomain takeover that could be used in a more sophisticated attack.
The incident had something to do with a subdomain that was initially mapped to a staging Web site hosted on Azure.
The Web site was removed some time ago, but the mapping between the subdomain and the site’s public ‘azurewebsites.
One way to help understand how Active Directory, App Registrations, managed identities and Key Vaults work in Microsoft Azure is to look at a typical Logic App that authenticates itself with an API that provides data only to services registered with the organisation’s Active Directory.
The basic sequence for the authentication part of the Logic App here is this:
Get a password from an Azure Key Vault. Get an OAuth token for the Logic App from Active Directory.
Azure Key Vault is designed to store (and protect) secrets such as API keys, passwords, cryptographic keys, connection strings, etc. It can store the following categories of data:
Keys Certificates Secrets The Secrets storage can store arbitrary plaintext values, so Key Vault could potentially be used as a means of centrally managing a collection of usernames and passwords that could be copied and pasted straight from the Azure Portal. Is this a safe method of password management, though?
While everything in a Tails OS session is wiped from system memory after the laptop is switched off, the option to store data persistently in an encrypted partition (the Persistent Storage) is a critical feature for users, such as journalists, who, for example, need to create notes, save material and draft reports during a session.
The encryption used for this - LUKS - is the standard for disk and volume encryption in Linux.
Recently I was tasked with implementing role-based security for a .NET API, based on the Active Directory groups the user is a member of. Easy, I thought initially, as there’s a well-documented way of doing this by adding [Authorize] annotations to controller methods.
The first problem I ran into was the API was designed to be used by a Node.js/React application. In this case (and this is a simplified description), users obviously don’t authenticate themselves directly with the API, but instead with the React application, via Active Directory Single Sign-On.
Since dependency vulnerability scanning has been suggested by colleagues as something that could help with security/standards compliance and addressing legacy software, I’ve been looking into a few services to see how useful the available options could be.
NPM Audit Dependency scanning is performed by default with the install command for later versions of NPM, and by default, the output of npm audit will show a few lines of relevant information about each package with a reported vulnerability - its rating, a brief description of the vulnerability and whether an update is available.
One of the useful little applications that’s included with Tails OS is OnionShare, which enables the sharing of things on the .onion domain and the creation of hidden services. I think these are important options to have in a Tails-like setup.
Our freedom of expression, in practice, isn’t defined by laws or constitutions. It’s instead defined by what corporations’ terms of service and whatever arbitrary extra-legal pressures they’re subject to. And, unfortunately this applies to almost everything on the conventional Web, since almost everything is dependent on third party.
Though my views aren’t as extreme as Richard Stallman’s, he does have a point: A decade ago we’d be up in arms about relatively trivial privacy-invading crap in operating systems, but it’s since become the norm, with most smartphones and laptops having things pre-installed that send personal data in the background to Google, Microsoft and whichever assortment of corporations. A state of affairs brought about by a confluence of what we collectively surrendered for convenience.
