Book Review: Microsoft Azure Security Infrastructure

AzureSecurityInfrastructure_BookCover-150x150 Book Review: Microsoft Azure Security InfrastructureRecently, I finished reading the Microsoft Azure Security Infrastructure eBook.

The chapters that I found most helpful were Chapter 3 “Azure Network Security” and Chapter 4 “Data and Storage Security”, hence the majority of my highlights are from these chapters.

I’ve decided to share my highlights from reading this specific publication, in case the points that I found of note/interest will be of some benefit to someone else. So, here are my highlights (by chapter). Note that not every chapter will have highlights (depending on the content and the main focus of my work).

Chapter 01: Cloud Security

  • I tell friends that in the 1990s, if I needed a dozen servers for a new project, it would
    take four to six months to forecast, order, deliver, rack, network, configure, and deploy
    those servers before the team could begin testing the production service. Today, in
    Azure, I can do the same thing in 30 minutes, from my phone.
  • A private cloud is not the same as a traditional on-premises datacenter (although
    the term is often misused in that way).
  • Cloud computing security significantly differs from traditional datacenter security in two
    other major areas: assume breach and isolation
  • We assume that we are about to be breached, or have already been breached, and we have people, processes, and technology that help us find out when the breach occurred as early as possible, and then we eject the attacker with the goal being to limit expansion of the breach as much as possible.
  • Azure was built from a security foundation that uses the Security Development Lifecycle (SDL) principles from the ground up.
  • IMPORTANT Azure administrators should use Role-Based Access Control (RBAC) provided by Azure to delegate appropriate permission to users. Read more about RBAC at azure.microsoft.com/documentation/articles/role-based-access-control-configure.

Chapter 02: Identity Protection in Azure

Chapter 03: Azure Network Security

  • The reason for this is that the ASM model is being phased out and there is no future in it, so it would be best to migrate your ASM assets (if you have any) to the new Azure Resource Management model.
  • MORE INFO For more information about the differences between the ASM and Azure
    Resource Management models, read the article “Azure Resource Manager vs. classic deployment: Understand deployment models and the state of your resources” at https://azure.microsoft.com/documentation/articles/resource-manager-deployment-model.
  • Microsoft takes advantage of the Windows Server software defined networking stack—also known as “ Hyper-V Network Virtualization” (HNV). With HNV, Microsoft can isolate each customer’s network from other customer networks by encapsulating each customer’s network communications within a generic routing encapsulation (GRE) head
    that contains a field that is specifically for the customer. This effectively isolates each customer’s network from the others, even if different customers are using the same IP address schemes on their Azure Virtual Networks.
  • MORE INFO For more information about Hyper-V network virtualization, read the article “Hyper-V Network Virtualization Overview” on TechNet at https://technet.microsoft.com/library/jj134230(v=ws.11).aspx.
  • Azure Virtual Networks require you to use private IP addresses (RFC 1918) for VMs. The address ranges are:
    • Class A: 10.0.0.0/24
    • Class B: 172.16.0.0/12
    • Class C: 192.168.1.0/24
  • Just like with on-premises networking, you should carefully consider which IP address scheme you want to use, especially if you think you will connect your Azure Virtual Network to your on-premises network. In that scenario, you should make sure there is no overlap between the IP addresses you use on-premises and those you want to use on an Azure Virtual Network.
  • For VMs that perform roles requiring a static IP address, you can assign a static IP address to the VM. Keep in mind that you do not configure the NIC within the VM to use a static IP address. In fact, you should never touch the NIC configuration settings within a VM. All IP addressing information should be configured within the Azure portal or by using PowerShell Remoting in Azure.
  • Keep in mind that you cannot bring your own DHCP server. The VMs are automatically configured to use only the DHCP server provided by Azure.
  • MORE INFO For more information on IP addressing in Azure, read the article “IP
    addresses in Azure” at https://azure.microsoft.com/documentation/articles/virtual-network-ip-addresses-overview-arm.
  • When you create an Azure Virtual Network, you get a simple DNS server in the bargain, at no extra charge. This simple DNS server service provides you with basic name resolution for all VMs on the same Azure Virtual Network. Name resolution does not extend outside of the Azure Virtual Network.
  • The simple Azure Virtual Network DNS is not configurable. You can’t create your own A
    records, SRV records, or any other kind of record. If you need more flexibility than simple name resolution, you should bring your own DNS server.
  • A Network Security Group is the equivalent of a simple stateful packet filtering firewall or
    router.
  • NSGs use a 5-tuple to evaluate traffic:
    • Source and destination IP address
    • Source and destination port
    • Protocol: transmission control protocol (TCP) or user datagram protocol (UDP)
  • This means you can control access between a single VM and a group of VMs, or a single VM to another single VM, or between entire subnets. Again, keep in mind that this is simple stateful packet filtering, not full packet inspection. There is no protocol validation or network level intrusion detection system (IDS) or intrusion prevention system (IPS) capability in a Network Security Group.
  • When you create an Azure Virtual Network and then define subnets within it, Azure automatically creates a collection of system routes that allows machines on the various subnets you’ve created to communicate with each other. You don’t have to define the routes, and the appropriate gateway addresses are automatically assigned by the DHCP server–provided addresses.
  • Take advantage of User Defined Routes. In Azure, you can use User Defined Routes to control the entries in the routing table and override the default settings.
  • For a virtual network security device, you configure the Azure routing table to forward all outbound and inbound connections through that device. When you want to prevent VMs from initiating outbound connections to the Internet, you configure forced tunneling.
  • MORE INFO For more information about User Defined Routes, read the article “What are User Defined Routes and IP Forwarding?” at https://azure.microsoft.com/documentation/articles/virtual-networks-udr-overview. For more information about forced tunneling, read “Configure forced tunneling using the Azure Resource Manager deployment model” at https://azure.microsoft.com/documentation/articles/vpn-gateway-forced-tunneling-rm.
  • MORE INFO For more information about more secure remote access that uses RDP and
    other protocols, read the article “Securing Remote Access to Azure Virtual Machines over the Internet” at https://blogs.msdn.microsoft.com/azuresecurity/2015/09/08/securing-remote-access-to-azure-virtual-machines-over-the-internet.
  • The SSTP VPN protocol is interesting because, unlike other methods of remote access VPN client/server connections (such as IPsec, LTP/IPsec, or PPTP), the SSTP protocol tunnels communications over the Internet by using a TLS-encrypted HTTP header. What this means in practice is that SSTP can be used across firewalls and web proxies.
  • This means that you can block direct inbound access for the RDP and SSH protocols to VMs on your Azure Virtual Network over the Internet and still reach them by using those protocols after you establish the VPN connection. This entire process is secure because you have to authenticate the VPN connection first, and then authenticate again with the RDP or SSH protocols.
  • With a point-to-site VPN, you can connect a single device (at a time) to an Azure Virtual Network. To be clear, that doesn’t mean that when you use a point-to-site VPN you can only connect a single device at a time, which would block all other connections to the Azure Virtual Network. What it means is that when you use a point-to-site VPN, only that device is connected to the Azure Virtual Network. Other devices can connect to the same Azure Virtual Network by using a point-to-site VPN at the same time.
  • Most industry standard on-premises VPN gateways work with the Azure VPN gateway. Note that in contrast to the point-to-site VPN connections that use SSTP, the site-to-site VPN uses IPsec tunnel mode for the site-to-site VPN connection.
  • Using site-to-site VPN connections has a couple of downsides:
    • Connections to Azure top out at around 200 megabits per second (Mbps).
    • They, by definition, traverse the Internet, which could be a security issue.
  • The MPLS version of ExpressRoute tops out at around 1 Gbps, whereas the Exchange Provider option provides you with up to 10 Gbps.
  • MORE INFO To learn more about dedicated WAN links to Azure Virtual Networks, read the article “ExpressRoute Technical Overview” at https://azure.microsoft.com/documentation/articles/expressroute-introduction.
  • MORE INFO To learn more about external load balancing, read the article “Load balancing for Azure infrastructure services” at https://azure.microsoft.com/documentation/articles/virtual-machines-linux-load-balance.
  • MORE INFO To learn more about internal load balancing, read the article “Internal Load Balancer Overview” at https://azure.microsoft.com/documentation/articles/load-balancer-internal-overview.
  • MORE INFO To learn more about Traffic Manager and how you can take advantage of
    all its global load balancing features, read the article “What is Traffic Manager?” at
    https://azure.microsoft.com/documentation/articles/traffic-manager-overview.
  • At the time this chapter was written, you can’t get the same level of visibility into network
    traffic that you can get on-premises. Many of the on-premises devices work at the Link layer (OSI layer 2), which is not available on Azure Virtual Networks. The reason for this is that Azure Virtual Networks make use of software-defined networking and network virtualization, so the lowest level of traffic analysis you can get is at the Network layer (OSI layer 3).
  • At this time, you have the ability to get some network information for traffic that moves
    through Network Security Groups. In particular, you can:

    • Use Azure audit logs to get information about connections made through a Network Security Group.
    • View which Network Security Group rules are applied to VMs and instance roles based on the MAC address.
    • View how many times each Network Security Group rule was applied to deny or allow traffic.
  • MORE INFO To learn more about how you can obtain logging information from Network
    Security Groups, read the article “Log Analytics for Network Security Groups (NSGs)” at
    https://azure.microsoft.com/documentation/articles/virtual-network-nsg-manage-log.
  • MORE INFO To learn more about the Azure DNS service, read the article “Azure DNS Overview” at https://azure.microsoft.com/documentation/articles/dns-overview.
  • MORE INFO To learn more about what virtual network security devices are available in the Azure Marketplace, on the Azure Marketplace home page (https://azure.microsoft.com/en-us/marketplace), enter security in the search box. You can find Azure security partners at https://azure.microsoft.com/marketplace/?term=security.
  • Azure has a reverse proxy service that you can use to proxy connections to your on-premises resources. The reverse proxy service is called Azure Active Directory Application Proxy. You won’t find this service in the list of Azure Active Directory products on Azure.com, and you won’t find it in the table of contents.
  • The Azure Application Proxy is already built into Azure, and you configure it so that when
    client systems want to request resources on your on-premises servers, they actually make the request to the reverse proxy on Azure. The Azure Application Proxy forwards those requests back to your on-premises servers.
  • MORE INFO To learn more about the Azure Application Proxy, read the article “Publish applications using Azure AD Application Proxy” at https://azure.microsoft.com/documentation/articles/active-directory-application-proxy-publish.
  • Best practices are based on two things: the positive experience others have had using a specific practice and the confirmation that the best practices work across a number of environments.
  • If you plan to connect your on-premises network to one or more Azure Virtual Networks, you need to ensure that there are no IP address conflicts. That is to say, you have to ensure that the IP address ranges you select and the subnets you create on your Azure Virtual Networks do not overlap with what you have on-premises.
  • A better solution is to define subnets for each of these roles and then put each VM that supports these roles into a subnet created for each role. That leads you to putting the domain controllers on the domain controllers’ subnet, the database servers on the database server subnet, the web front ends on the web front-ends subnet, and so on.
  • Although Network Security Groups are useful for basic network access control, keep in mind that they do not provide you any level of application layer inspection. All you have control over is the source and destination IP address, source and destination TCP or UDP port number, and the direction to allow access.
  • Another thing to be aware of is that if you want to create restrictive access rules with
    Network Security Groups, you have to be aware of what you might inadvertently block.
  • Another scenario you might not think of is communications outside of your Azure Virtual
    Network, but still within the Azure fabric itself; for example, when you encrypt Azure
    Virtual Machines by using Azure Disk Encryption. To encrypt your operating system and
    data disks, the VM needs to be able to reach the Azure Key Vault Service and an Azure
    Application (these are prerequisites for Azure Disk Encryption). If you lock down your
    NSGs too tight, you won’t be able to reach the Key Vault or the Azure Active Directory
    application, and your VMs won’t start because the disks can’t be unencrypted.
  • MORE INFO For more information about how to create a site-to-site VPN connection between two Azure Virtual Networks, read the article “Configure a VNet-to-VNet Connection by using Azure Resource Manager and PowerShell” at https://azure.microsoft.com/documentation/articles/vpn-gateway-vnet-vnet-rm-ps.
  • Regardless of what operating system you deploy in Azure Virtual Machines, you want to make sure that a host-based firewall is enabled, just as you do on-premises.
  • You should use IPsec for all communications that aren’t encrypted by some other method (such as HTTPS or encrypted SMB 3.0).
  • MORE INFO To learn more about how to use IPsec for server and domain isolation, read the article “Server and Domain Isolation Using IPsec and Group Policy” at https://technet.microsoft.com/library/cc163159.aspx.
  • When you put a VM on an Azure Virtual Network, you might notice that the VM can connect to any other VM on the same Azure Virtual Network, even if the other VMs are on different subnets. This is possible because there is a collection of system routes that are enabled by default that allow this type of communication.
  • You should configure User Defined Routes when you deploy a virtual network security appliance
  • MORE INFO To learn more about User Defined Routes, read the article “What are User Defined Routes and IP Forwarding” at https://azure.microsoft.com/documentation/articles
    /virtual-networks-udr-overview.
  • The default routes for an Azure Virtual Network allow VMs to initiate traffic to the Internet. This process can pose a security risk because it represents a form of split tunneling, and these outbound connections could increase the attack surface of a VM and be used by attackers. For this reason, you should enable forced tunneling on your VMs when you have cross-premises connectivity between your Azure Virtual Network and your on-premises network.
  • MORE INFO To learn more about forced tunneling and how to enable it, read the article
    “Configure forced tunneling using the Azure Resource Manager deployment model” at
    https://azure.microsoft.com/en-us/documentation/articles/vpn-gateway-forced-tunneling-rm.
  • If you require a higher level of network security than you can obtain with network-level access controls, then you should investigate and deploy Azure Virtual Network security appliances.
  • For all high-security deployments, you should consider deploying a perimeter network to
    enhance the level of network security for your Azure resources.
  • MORE INFO To learn more about perimeter networks and how to deploy them in Azure, read the article “Microsoft Cloud Services and Network Security” at https://azure.microsoft.com/documentation/articles/best-practices-network-security.
  • If you require an exceptional level of security or performance for your cross-premises connections, you should consider using Azure ExpressRoute for your cross-premises connectivity. ExpressRoute is a dedicated WAN link between your on-premises location or an Exchange hosting provider. Because this is a telco connection, your data doesn’t travel over the Internet and therefore is not exposed to the potential risks inherent in Internet communications.
  • MORE INFO To learn more about how Azure ExpressRoute works and how to deploy it, read the article “ExpressRoute Technical Overview” at https://azure.microsoft.com/documentation/articles/best-practices-network-security.
  • You should consider using Azure Application Gateway when you have:
    • Applications that require requests from the same user or client session to reach the same back-end VM. Examples of this are shopping cart apps and web mail servers.
    • Applications that want to free web server farms from SSL termination overhead by taking advantage of Application Gateway’s SSL offload feature.
    • Applications, such as a content delivery network, that require multiple HTTP requests on the same long-running TCP connection to be routed or load balanced to different backend servers.
  • MORE INFO To learn more about how Azure Application Gateway works and how you can use it in your deployments, read the article “Application Gateway Overview” at https://azure.microsoft.com/documentation/articles/application-gateway-introduction.
  • MORE INFO To learn more about how the Azure External Load Balancer works and how you can deploy it, read the article “Get Started Creating an Internet Facing Load Balancer in Resource Manager using PowerShell” at https://azure.microsoft.com/documentation/articles/load-balancer-get-started-internet-arm-ps.
  • Point-to-site VPN is more secure than direct RDP or SSH connections because the user has to authenticate twice before connecting to a VM. First, the user needs to authenticate (and be authorized) to establish the point-to-site VPN connection; second, the user needs to authenticate (and be authorized) to establish the RDP or SSH session.
  • It is highly recommended that you enable Azure Security Center for all of your Azure
    deployments.
  • Microsoft has created the Datacenter Extension Reference Architecture Diagram and supporting collateral to help you understand what such a datacenter extension would look like. This provides a reference implementation that you can use to plan and design a secure enterprise datacenter extension to the cloud. You should review this document to get an idea of the key components of a secure solution.
  • MORE INFO For more information about the Datacenter Extension Reference Architecture Diagram, read “Datacenter extension reference architecture diagram – Interactive” at https://gallery.technet.microsoft.com/Datacenter-extension-687b1d84.

Chapter 04: Data and Storage Security

  • Many people think of storage security as securing the disk on which the data is stored. Any security for the data itself is inherited from the security applied to the storage system. In contrast, data security is security applied directly to the data, so no matter what the storage medium is, the data remains as secure as possible.
  • With Azure Disk Encryption, you can encrypt both the operating system .vhd and any data disk .vhd files that you have attached to your VMs.
  • Azure Disk Encryption works for both Windows and Linux VMs. For Windows VMs, Microsoft uses BitLocker as the disk encryption technology. For Linux VMs, Microsoft uses dm-crypt.
  • Azure Disk Encryption supports the following scenarios:
    • You can bring a VM that you’ve already encrypted on-premises into Azure and use the same keys you used to encrypt that VM.
    • You can create a VM from the Microsoft Azure Marketplace and encrypt that VM as you create it.
    • You can have unencrypted VMs that are currently running in Azure and encrypt them.
    • You can unencrypt VMs that you have encrypted, regardless of whether you’ve encrypted them on-premises, encrypted them from the time you created them in Azure, or encrypted them after you created them.
  • To help ensure the security of your keys, you can sort the keys (in the case of BitLocker) or the secrets (in the case of dm-crypt) in Azure Key Vault. Key Vault is the Azure “vaulting” solution that provides you with a hardware security module (HSM) in which you store your disk encryption keys.
  • The following lists key points you might want to know about Azure Disk Encryption:
    • Currently, no charges are incurred for encrypting VMs.
    • Not all operating systems can be encrypted.
    • Not all operating systems can be decrypted.
    • Not all types of virtual disk storage can be encrypted.
    • You can use the Azure command-line interface (CLI), Azure PowerShell, or Azure
      Resource Manager templates to encrypt an Azure VM.
    • The Azure VM and the Key Vault you use to store the VM’s keys must be in the same Azure country/region.
    • An Azure Active Directory application must be configured for Azure Disk Encryption usage.
    • A Key Vault access policy must be configured.
  • MORE INFO To get detailed information, read “Azure Disk Encryption for Windows and Linux Azure Virtual Machines” at https://gallery.technet.microsoft.com/Azure-Disk-Encryption-for-a0018eb0 or “Encrypt an Azure Virtual Machine” at https://azure.microsoft.com/documentation/articles/security-center-disk-encryption.
  • You should always encrypt your Azure VMs, regardless of the role that VM performs on your network.
  • Azure Storage Service Encryption automatically encrypts blob files ( binary large objects)
    when you save them to your Azure storage account. When you save the object to Azure storage, the object is automatically encrypted for you. When you read the file from storage, the file is automatically decrypted for you. You don’t need to maintain any keys or secrets—Azure does all that for you in the background.
  • The level of encryption used by Azure Storage Service Encryption is similar to what is used in the rest of Azure, which is Advanced Encryption Standard (AES)–256
  • Customers have asked whether VMs that have been encrypted by using Azure Disk
    Encryption have significant overhead, because these machines would have double encryption if you also use Azure Storage Service Encryption. This double encryption causes nominal overhead. Although multiple encryption/decryption operations still take place, the overhead isn’t comparable to what you see with double encryption of network traffic because with storage encryption, you don’t have the protocol overhead also.
  • The following list provides key facts you should know about Azure Storage Service Encryption:
    • Only Azure Resource Manager storage accounts are supported.
    • You cannot encrypt classic storage accounts that have been migrated to Azure Resource Manager accounts.
    • Azure Storage Service Encryption will not encrypt data that exists in a storage account prior to enabling encryption on the account. If you enable storage encryption on a storage account that already has data in it, you will need to remove the data from the account and then put it back in, because the encryption takes place when the data is actually placed into the storage account.
    • VMs created by using images available from the Azure Marketplace are a special
      situation: the base image will remain unencrypted, but any subsequent writes will be encrypted. Because your private data appears only on the subsequent writes, your information is more secured.
    • Other types of Azure storage are not encrypted by using Azure Storage Service
      Encryption; this excludes table, queue, and file storage options.
  • MORE INFO To learn more about Azure Storage Service Encryption, read the article “Azure Storage Service Encryption for Data at Rest” at https://azure.microsoft.com/documentation/articles/storage-service-encryption.
  • Azure Files use the same SMB protocol currently used on-premises. Server and client
    applications that use the SMB protocol to access file shares on-premises now can also access information in Azure Files. In fact, you can configure Azure file shares so that they are accessible over the Internet through TCP port 445.
  • One significant difference between on-premises file shares and Azure Files is the level of access control. On-premises, you can apply robust and granular access controls to file shares and you can assign even deeper NTFS permissions to the files inside of those file shares. With Azure Files, access to objects within the share is controlled by a single storage account key that gives the same level of access to all files. There is also no Azure Active Directory support for permissions assignment to data contained within the file shares.
  • MORE INFO You can learn more about creating a shared access policy by reading the “Generate a shared access signature for a file or file share” section of the article “Develop with File storage,” at https://azure.microsoft.com/documentation/articles/storage-dotnet-how-to-use-files
    /#generate-a-shared-access-signature-for-a-file-or-file-share.
  • When you use the SMB 3.x protocol to access Azure Files, you can also take advantage of automatic and transparent encryption of file data over the wire.
  • If the client fully supports SMB 3.x, it will be able to transparently work with Azure File Storage to generate per-session encryption keys. The encryption protocol is AES-128 CCM (128-bit Advanced Encryption Standard with CCM mode), which provides some of the highest levels of security available and enables you to confidently access these file shares across any type of network.
  • You can still take advantage of accessing Azure File Shares over the Internet through site-to-site VPN connections. Or, if you want to avoid the Internet entirely, you can access Azure File Shares by using the SMB protocol through ExpressRoute.
  • MORE INFO To learn more about Azure Files, read the article “Get Started with Azure
    File Storage on Windows” at https://azure.microsoft.com/documentation/articles
    /storage-dotnet-how-to-use-files/#develop-with-file-storage.
  • You might consider using StorSimple for many reasons, including the following:
    • You can use StorSimple as a primary storage solution for your on-premises workloads, such as a file server, collaboration server, database server, and for VMs.
    • You can configure policies that offload “cold” data from the on-premises StorSimple appliance into Azure storage.
    • You can create automated storage snapshots and have the data backed up to Azure storage.
    • You can use StorSimple to help with disaster recovery by installing StorSimple appliances to your new on-premises locations and then retrieving the data you need from Azure storage.
  • MORE INFO You can learn more about StorSimple at https://www.microsoft.com/en-us/server-cloud/products/storsimple/features.aspx.
  • From a security perspective, StorSimple addresses four different security scenarios:
    • User authentication to the Azure storage account where the data is stored
    • StorSimple appliance access to the data stored in Azure storage
    • Security of the data as it moves over the network
    • Security of the data at rest, as it sits on the disk when not being accessed
  • It is highly recommended that you become familiar with how to change access keys in the Azure portal and in your StorSimple systems. You should also configure Azure to regenerate access keys every 90 days.
  • StorSimple systems can connect to as many as 64 different storage accounts. You can use multiple storage accounts and their associated storage access keys to compartmentalize access to data in Azure Storage by department, role, team, project, or other categorizations that might work best for you.
  • Data transmission between the StorSimple system and cloud storage is encrypted by using Secure Sockets Layer (SSL), supporting up to AES-256 session encryption during data transfers between the StorSimple system and Azure Storage. This encryption is separate from the storage access keys and data-at-rest encryption, although both of these measures are also in force when data is on the wire.
  • StorSimple encrypts data stored in the cloud with an encryption key that you provide, and
    also uses AES-256 encryption that is derived from a passphrase you define or one that is generated by a key management system for you. Because StorSimple can support up to 64 storage accounts, up to 64 different encryption keys can be used in a single StorSimple system.
  • In general, 16 million objects are distributed across an indeterminate number of cloud storage disks for every 1 terabyte (TB) of data stored in the cloud.
  • User identities are stored in Azure RMS as certificate files. When a user encrypts a document, a small RMS client application creates a content key and encrypts the document with that key. The RMS client application creates a certificate that includes a policy for the document. This policy has the rights for the users or groups and the restrictions on how the document can be used.
  • You should remember the following four key things about Azure RMS:
    • File content is never sent to the Azure RMS service. Microsoft never has access to the actual data.
    • Applications enable RMS protection by allowing the configuration and enforcement of access rights.
    • Applications use the Azure RMS SDK to communicate with the RMS service and servers.
    • Azure RMS takes advantage of Azure Rights Management, Active Directory RMS, Active Directory, and Azure Key Vault.
  • MORE INFO To learn more about Azure Right Management, read the article “What is Azure Rights Management?” at https://docs.microsoft.com/rights-management/understand-explore/what-is-azure-rms.
  • Azure SQL provides a rudimentary firewall that allows simple source IP address access control. This is a popular feature because you can enforce access controls on a network level so that only IP addresses that you deem safe are allowed to connect to the Azure SQL Database server or specific databases contained within the server.
  • There are two types of firewall access rules you can configure:
    • Those that allow IP addresses that you define access to the entire Azure SQL Database server and all the databases contained within it
    • Those that allow IP addresses that you define access to specific databases contained within the Azure SQL Database server
  • MORE INFO To learn more about the Azure SQL Firewall and how to configure it, read the article “Configure Azure SQL Database firewall rules – overview” at https://azure.microsoft.com/documentation/articles/sql-database-firewall-configure.
  • MORE INFO To learn more about SQL Always Encrypted, read the article “Always Encrypted (Database Engine)” at https://msdn.microsoft.com/library/mt163865.aspx.
  • SQL row-level security (RLS) makes it possible for you to control access to rows in a database.
  • Access restriction logic is located in the database tier, in contrast to SQL Always Encrypted, which takes place away from the data at the client tier. The database service applies the access control each time there is an attempt to access the data.
  • MORE INFO To learn more about row-level security, read the article “Row-Level Security” at https://msdn.microsoft.com/library/dn765131.aspx.
  • Transparent data encryption performs real-time encryption and decryption of both data and log files. The encryption process uses a database encryption key. The database encryption key is:
    • A symmetric key secured by a certificate stored in either the master database or the server.
    • An asymmetric key protected by an Extensible Key Management module.
  • Transparent data encryption enables software IT pros to encrypt data by using AES-encryption and 3DES-encryption algorithms without requiring the need for developers to change existing applications.
  • MORE INFO To learn more about SQL transparent data encryption, read the article “Transparent Data Encryption (TDE)” at https://msdn.microsoft.com/library/bb934049.aspx.
  • If the amount of data that must be encrypted is small or if the application can be designed to use cell-level encryption and if performance is not a concern, cell-level encryption is recommended over transparent data encryption. Otherwise, you should use transparent data encryption for encrypting existing applications.
  • MORE INFO To learn more about cell-level encryption, read the article “Recommendations for using Cell Level Encryption in Azure SQL Database” at http://i1.blogs.msdn.com/b/sqlsecurity/archive/2015/05/12/recommendations-for-using-cell-level-encryption-in-azure-sql-database.aspx.
  • Dynamic data masking hides protected data in the result set of a query over designated database fields without changing the actual data contained within the database. You don’t need to make any changes to your application to use this feature because the masking rules are applied in the results of the query when they are sent back to the client from the server.
  • You should be aware that dynamic data masking is not intended to prevent users
    from connecting directly to a database and then running queries that might expose sensitive data. Therefore, consider dynamic data masking as a complement to other Microsoft SQL Server security features discussed.
  • MORE INFO To learn more about dynamic data masking, read the article “Dynamic Data
    Masking” at https://msdn.microsoft.com/library/mt130841.aspx.

Chapter 05: Virtual Machine Protection with Antimalware

  • Microsoft Antimalware for Azure Cloud Services and Virtual Machines is built on the
    same common antimalware platform as Microsoft Security Essentials, Microsoft Forefront Endpoint Protection, Microsoft System Center Endpoint Protection, Microsoft Intune, and Windows Defender for Windows 10, Windows 8.1, and Windows 8.
  • The customer’s Azure storage is used to store the antimalware event information. The event provider source name is Microsoft Antimalware, which is recorded by the Antimalware service. The Antimalware service also uses the Azure Diagnostics extension to collect these events from the Azure system into tables in the customer’s Azure storage account.
  • IMPORTANT In Windows Server 2016, Microsoft Antimalware is called Windows Defender.
  • MORE INFO For more information about the capabilities of AMSI, go to
    https://msdn.microsoft.com/library/windows/desktop/dn889588(v=vs.85).aspx.
  • The default configuration settings have been preoptimized for running in the Azure environment. You can customize the default antimalware configuration settings as required for your Azure application or service deployment and apply them for the Antimalware deployment scenarios. Antimalware Client and Service is not installed by default in the VM’s platform; it is available as an optional security extension.
  • It is important to note that VMs created in 2015 or earlier that have an old version of the Virtual Machine guest agent might need to be manually updated to a newer version of the Virtual Machine guest agent before you deploy the antimalware. The older version of the Virtual Machine guest agent has an issue that results in the %temp% folder being filled with log files, and that prevents the antimalware installation from succeeding.
  • By default, the antimalware files are installed in %ProgramFiles%\Microsoft Security Client. The Antimalware user interface (UI) is not available in the VM; however, you can create custom policies to turn the UI on if your organization needs that. You can also use the mpcmdrun command line in the VM itself if you need to perform a manual scan.
  • MORE INFO To learn how to create custom policies to turn on the UI, read the blog at https://blogs.msdn.microsoft.com/azuresecurity/2016/03/09/enabling-microsoft-antimalware-user-interface-post-deployment.
  • Enabling Antimalware through the Azure portal does not enable its diagnostics logs. However, if you use PowerShell for Antimalware to enable it, PowerShell has an option to enable diagnostics logs.
  • For more information about this behavior, go to https://blogs.msdn.microsoft.com/azuresecurity/2016/04/19/enabling-diagnostics-logging-for-azure-antimalware.
  • MORE INFO You can use PowerShell to deploy non-Microsoft antimalware solutions also. Read more about deployment of other antimalware solutions at https://azure.microsoft.com/blog/deploying-antimalware-solutions-on-azure-virtual-machines.
  • MORE INFO The easiest way to monitor your VMs for antimalware compliance is by using Azure Security Center
  • IMPORTANT As a best practice, you should always install an antimalware solution on a VM.

Chapter 06: Key Management in Azure with Key Vault

  • When planning to adopt data encryption, you should also plan how to manage the encryption keys because if the keys are compromised, the data is no longer secure.
  • One important concept to keep in mind is the difference between a secret and a key. A
    secret is any sequence of bytes under 10 kilobytes (KB) and used by authorized users and apps to write and read back the secret value. Key Vault stores these secrets by encrypting them with a unique key per vault. A key refers to a cryptographic key, such as RSA 2048. The key is used by authorized users and apps to import the key or ask the service to generate one key for them. In this case, authorized users cannot read it back; they must ask the service to decrypt or sign with the key. This provides higher isolation, at the cost of higher latency because every decryption requires a remote call to the service. If your app needs frequent, low-latency access to a key (for example, Secure Sockets Layer [SSL] keys), then the key should be stored as a secret. If your app reads the key at runtime and uses it locally, and the security is more important than performance, it should be stored as a key.
  • MORE INFO For more information about the Key Vault REST API, go to
    https://msdn.microsoft.com/library/azure/dn903609.aspx.
  • MORE INFO For information about Key Vault, read the Developer’s Guide at
    https://azure.microsoft.com/documentation/articles/key-vault-developers-guide.

Chapter 07: Azure Resource Management Security

  • Azure Security Center is an Azure service that can be used to monitor your infrastructure
    as a service (IaaS) resources, such as Azure Virtual Machines and Azure Virtual Network, in addition to PaaS resources such as Azure SQL Database.
  • Security Center can monitor one or more subscriptions while keeping a centralized view
    of all resources through the dashboard. To detect threats, Azure Security Center uses global threat intelligence from Microsoft products and services, the Microsoft Digital Crimes Unit (DCU), the Microsoft Security Response Center (MSRC), and external feeds. For detection purposes, it also applies advanced analytics, including machine learning and behavioral analysis.
  • IMPORTANT You can use Role-Based Access Control (RBAC) to delegate administrative tasks to other IT personnel based on the need to access information. For more information about this, read “Azure Security Center Planning and Operations Guide” at https://azure.microsoft.com/documentation/articles/security-center-planning-and-operations-guide.
  • Security Center integrates with an ecosystem of partners, making it easy for organizations to deploy and monitor a variety of security solutions, like endpoint protection, firewalls, and more.
  • When you enable data collection in the subscription, all resource groups inherit the
    same security policy. However, if your organization requires different polices per resource group, you can disable inheritance and configure unique policies.
  • The prevention policies available are as follows:
    • System updates This policy verifies whether the operating system running in the VMs monitored by Security Center is fully updated.
    • Baseline rules This policy verifies the VM settings against a set of security baseline rules to verify whether the VMs are using a recommended configuration. Security Center uses Common Configuration Enumeration4 (CCE) to assign unique identifiers for configuration rules.
    • Endpoint Protection This policy verifies whether the VM has an endpoint protection
      solution installed on it. If it does not, Endpoint Protection suggests installing one.
    • Network Security Group This policy evaluates your network security group and makes recommendations according to the current configuration.
    • Web Application Firewall This policy evaluates whether there are web applications
      exposed to vulnerabilities and suggests the installation of a WAF solution.
    • Next Generation Firewall This policy verifies the current networking configuration and, based on the current configuration, might suggest an installation of a next-generation firewall solution.
    • SQL Auditing This policy evaluates your current SQL Azure PaaS solution and verifies whether auditing is enabled in the database. If it is not enabled, SQL Auditing suggests that you enable it.
    • SQL Transparent Data Encryption This policy evaluates your current SQL Azure PaaS solution and verifies whether the database has transparent data encryption enabled.
  • You can download a Microsoft Excel file with all these rules from https://gallery.technet.microsoft.com/Azure-Security-Center-a789e335.
  • Azure Security Center uses a multi-layer approach to detect attacks on your Azure environment. The first layer is Network Analytics, which is used to detect incoming
    brute-force attacks and compromised machines (bots) that are used for malicious
    activity (for example, sending spam). This layer heavily uses machine learning to
    build usage profiles in order to accurately perform the detections. The second layer is
    Virtual Machines Behavior Analysis, which detects suspicious behavior on the VM by
    analyzing security events and processes crash dumps. The third layer includes alerts
    sent from deployed partner solutions and alerts generated by the Azure resources
    themselves. Lastly, Azure Security Center fuses the alerts from the different layers into
    incidents, which detail the attack timeline and what the attacker actually performed.
  • For more information about Azure SQL Server auditing, read the article “Get started with SQL database auditing” at https://azure.microsoft.com/documentation/articles/sql-database-auditing-get-started.
  • MORE INFO You can also use Power BI to visualize Security Center data related to your security status, threats, and detections. For more information, read the article “Get insights from Azure Security Center data with Power BI” at https://azure.microsoft.com/documentation/articles/security-center-powerbi.

Chapter 08: Internet of Things Security

Chapter 09: Hybrid Environment Monitoring

Chapter 10: Operations and Management in the Cloud

  • Azure Security Center helps you set security policies for your deployments, implement
    security recommendations to ensure best practices are adhered to, and monitor
    the security health of your assets, in addition to the partner solutions you might be
    using.
%d bloggers like this: