Advanced Data Security
ADS for SQL Servers outside of Azure – Now in Public Preview
Advanced Data Security for Azure Arc enabled SQL Server includes the functionality for surfacing & mitigating potential vulnerabilities and detecting & investigating suspicious activities that could indicate threats to SQL servers running outside of Azure. This offering is an extension of our advanced data security offering that is already available and widely adopted by customers using Azure SQL Database/Managed Instances (~25% adoption), Azure Synapse Analytics (~37% adoption), and SQL servers on Azure VMs, all powered by Azure Security Center and Azure Sentinel .
With this announcement, customers can enjoy Azure Security Center’s multi-layered protection (SQL ,OS and Service Layers) across hybrid SQL estates even if their SQL servers are running outside of Azure.
ATP for Azure Storage now extends support for ADLS Gen 2
What’s new in ATP for ADLS Gen2?
Azure Data Lake Storage Gen2 (ADLS Gen2) is a set of capabilities dedicated to big data analytics. It’s built on Azure Blob storage, while focusing on performance, management and security. ADLS Gen2 was designed from the start to service multiple petabytes of information while sustaining hundreds of gigabits of throughput. ADLS Gen2 accounts can be accessed using both Azure Blob API and Azure Data Lake Gen2 API.
Advanced threat protection for Azure Storage provides an additional layer of security intelligence that triggers alerts upon the detection of unusual and potentially harmful attempts to access or exploit data in Azure storage accounts.
With this release, advanced threat protection offers protection of ADLS Gen2 accounts, for both Azure Blog and Azure Data Lake Gen2 APIs.
Customers using ADLS Gen2 accounts can now benefit from the following capabilities of advanced threat protection for Azure Storage:
- World-class algorithms that learn, profile, and detect unusual or suspicious activity in their data lakes
- Actionable alerts in a centralized view in Azure Security Center with optional email notifications
- Integration with Azure Sentinel for efficient threat investigation
- Azure-native support for ADLS Gen2 with one click enablement from the Azure portal and with no need to modify your application code
Looking forward, we will be working to improve and to enrich our detections for ADLS Gen2 towards the GA milestone later this year.
Here is an example of an alert indicating that an ADLS Gen2 storage account was accessed from a suspicious IP address (active TOR exit node)
ATP for Storage now supports Azure Files (Public Preview)
What is advanced threat protection (ATP) for Azure Files?
Azure Files delivers secure, Server Message Block (SMB) based, fully-managed cloud file shares that can also be cached on-premises for performance and compatibility. With Azure Files, organizations get the added benefit of a secure storage infrastructure that is massively scalable, and globally available.
Advanced threat protection support for Azure Files provides an additional layer of security intelligence that provides alerts when it detects unusual and potentially harmful attempts to access or exploit file shares in Azure Storage.
With this release, customers using Azure Files can benefit from the following capabilities of advanced threat protection for Azure Storage:
- World-class algorithms that learn, profile, and detect unusual or suspicious activity in your file shares
- Actionable alerts in a centralized view in Azure Security Center with optional email notifications
- Integration with Azure Sentinel for efficient threat investigation
- Azure-native support for Azure Files with one click enablement from the Azure portal and with no need to modify your application code
Looking forward, we will be working to improve and enrich our detections for Azure Files towards the GA milestone later this year
Azure Monitor
Azure Monitor now supports Customer Managed Key (CMK)
Azure Monitor ensures that all data is encrypted at rest using Azure-managed keys. Azure Monitor also provides an option for data encryption using your own key that is stored in your Azure Key Vault and accessed by storage using system-assigned managed identity authentication. This key can be either software or hardware-HSM protected.
Azure Monitor use of encryption is identical to the way Azure Storage encryption operates.
CMK lets you control the access to your data and revoke it at any time. Azure Monitor storage always respects changes in key permissions within an hour. Data ingested in the last 14 days is also kept in hot-cache (SSD-backed) for efficient query engine operation. This data remains encrypted with Microsoft keys regardless CMK configuration, but your control over SSD data adheres to key revocation. We are working to have SSD data encrypted with CMK in the second half of 2020.
The CMK capability is delivered on dedicated Log Analytics clusters. To verify that we have the required capacity in your region, we require that your subscription is allowed beforehand. Use your Microsoft contact to get your subscription allowed before you startconfiguring CMK
Azure Monitor for Containers support for Azure Arc is in preview
Azure Monitor for Containers is now extending monitoring support for Kubernetes clusters hosted on Azure Arc. This support is currently in preview.
Azure Monitor for Containers on Azure Arc-enabled Kubernetes gives you similar capabilities as Azure Kubernetes Service (AKS) monitoring, such as:
- Performance visibility by collecting memory and processor metrics from controllers, nodes, and containers that are available in Kubernetes.
- Visualization through workbooks and in the Azure portal.
- Alerting and querying historical data for troubleshooting issues.
- Capability to scrape Prometheus metrics
Azure Log Analytics agent for Windows SHA-2 signing date has been extended
The Azure Log Analytics agent for Windows will begin to use SHA-2 signing exclusively on Aug. 17, 2020. This date has been extended from May 18, 2020 to give customers more time to prepare.
The change will impact customers using the Log Analytics agent on a legacy OS as part of any Azure service (Azure Monitor, Azure Automation, Azure Update Management, Azure Change Tracking, Azure Security Center, Azure Sentinel, Windows Defender ATP).
This change requires action only if you’re running the agent on a legacy OS version (Windows 7, Windows Server 2008 R2, or Windows Server 2008). Customers running on a legacy OS version are required to apply the latest service updates and patches on their machines before Aug. 17, 2020, or their agents will stop sending data to their Log Analytics workspaces
Azure Storage logs integrated with Azure Monitor and Log Analytics
We are excited to announce the limited public preview of Azure Storage logs integration with Azure Monitor. You can now configure diagnostic settings to export to Log Analytics to query and analyze natively, consolidate storage logs to central storage accounts, and send to Event Hub for streaming ingestion with partners and custom integrations. For more detailed guidelines, you can read Monitoring Azure Storage documentation.
In addition to new native export options, we’ve also added:
- Diagnostic logs for Files
- Diagnostic logs for Premium storage
- Diagnostic logs for Azure Data Lake Storage Gen2
- Enhanced schema including authentication context, TLS version, etc.
- Native query and analysis experience with Log Analytics
The limited public preview is available in Azure public cloud. You can participate the preview by registering in Preview registration form.
Data encryption for Azure Database for PostgreSQL—single server
The preview of data encryption for Azure Database for PostgreSQL—single server is now available. Data encryption with customer-managed keys for Azure Database for PostgreSQL—single server enables you to bring your own key (BYOK) for data protection at rest. It also allows organizations to implement separation of duties in the management of keys and data. With customer-managed encryption, you are responsible for, and in a full control of, a key’s lifecycle, key usage permissions, and auditing of operations on keys
Cosmos DB
Use system-assigned managed identities to access Azure Cosmos DB data
You can now use any service that supports Azure managed identities to get access to Cosmos DB, without having to use an access key. The following example shows how to use an Azure Function which has a managed identity to access Cosmos DB
Configure customer-managed keys for your Azure Cosmos account with Azure Key Vault
There is now a new service to protect data at rest in Cosmos DB, by using Customer managed key. This is another layer of encryption that runs on top of the service managed key. Similar to Transparent Data Encryption for SQL DB, this service works as another layer of encryption on top of service managed keys
Key Vault bring your own key (BYOK) is now generally available
Finally, this long awaited service is GA
A new method to import keys into Azure Key Vault is now generally available.
The process of importing keys from on-premises HSMs to Key Vault HSMs is generally referred to as bring your own key (BYOK). Key Vault has supported BYOK with nCipher HSMs since its launch in 2015.
The new BYOK method will enable Azure customers to use any supported on-premises HSMs to generate keys and import them into Key Vault. Many customers prefer to use on-premise HSMs to generate keys to meet regulatory or compliance requirements.
The new method enables secure transfer of HSM-protected key to Key Vault HSM. The key to be transferred never exists outside an HSM in plaintext form. During the import process, the key material is protected with a key held in HSMs in Azure Key Vault. The original BYOK method (now referred to as nCipher BYOK) will be deprecated over time. We urge customers to start using this new method for importing HSM-protected keys to Key Vault.
Along with this announcement, the specification for new BYOK method is also now available, to enable HSM vendors to provide BYOK tools to their customers. It also allows independent software vendors and customers to fully automate the BYOK process to fit their needs.
For details (including a list of supported HSMs) read Import HSM-protected keys into Key Vault (overview)
Azure Firewall
- Custom DNS support now in preview.
- DNS Proxy support now in preview.
- FQDN filtering in network rules now in preview.
- IP Groups now generally available.
- AKS FQDN tag now generally available
- SQL FQDN tag in application rules is now GA
- Azure Firewall is now HIPPA compliant
Azure Firewall forced tunneling and SQL FQDN filtering now generally available
Forced tunneling lets you redirect all internet bound traffic from Azure Firewall to your on-premises firewall or to chain it to a nearby network virtual appliance (NVA) for additional inspection. You enable a firewall for forced tunneling when you create a new firewall. As of today, it is not possible to migrate an existing firewall deployment to a forced tunneling mode.
Azure Firewall FQDN filtering in network rules (preview)
Customers have been asking for plans to enable protocols other than https & mssql in “Application Firewall rules”
We have now introduced FQDN filtering support for all ports and protocols in network rules based on DNS resolution
Application rules in Azure Firewall provide FQDN filtering based on SNI headers. They require application level proxy as we have for HTTP/S and MSSQL. Support for FQDN filtering in network rules is based on DNS resolution, and it’s valid for all protocols. As such, application rules can discern between two FQDNs that are resolved to the same IP address. This is not the case with FQDN filtering in network rules, so it is always recommended you use application rules when possible.
This requires the use of DNS proxy in Azure Firewall. Azure Firewall translates the FQDN to an IP address(es) using its DNS settings and does rule processing based on Azure DNS or a custom DNS configuration
As such, it can discern between two FQDNs that are resolved to the same IP address. This is not the case with FQDN filtering in network rules, so it is always recommended you use application rules when possible
Azure Firewall AKS FQDN tag now in generally available
An Azure Kubernetes Service (AKS) FQDN tag can now be used in Azure Firewall application rules to simplify your firewall configuration for AKS protection. Azure Kubernetes Service (AKS) offers managed Kubernetes cluster on Azure that reduces the complexity and operational overhead of managing Kubernetes by offloading much of that responsibility to Azure.
For management and operational purposes, nodes in an AKS cluster need to access certain ports and FQDNs. For more guidance on how to add protection for Azure Kubernetes cluster using Azure Firewall, see Use Azure Firewall to protect Azure Kubernetes Service (AKS) Deployments
Azure Firewall Manager is now GA
Azure Firewall Manager is now generally available, and includes Azure Firewall Policy, Azure Firewall in a Virtual WAN Hub (Secure Virtual Hub), and Hub Virtual Network. In addition, we are introducing several new capabilities to Firewall Manager and Firewall Policy to align with the standalone Azure Firewall configuration capabilities
Key features in this release includes:
- Threat intelligence-based filtering allow list in Firewall Policy is now generally available.
- Multiple public IP addresses support for Azure Firewall in Secure Virtual Hub is now generally available.
- Forced tunneling support for Hub Virtual Network is now generally available.
- Configuring secure virtual hubs with Azure Firewall for east-west traffic (private) and a third-party security as a service (SECaaS) partner of your choice for north-south traffic (internet bound).
- Integration of third-party SECaaS partners is now generally available in all Azure public cloud regions.
- Zscaler integration will be generally available on July 3, 2020. Check Point is a supported SECaaS partner and will be in preview on July 3, 2020. iboss integration will be generally available on July 31, 2020.
- Support for domain name system (DNS) proxy, custom DNS, and fully qualified domain name (FQDN) filtering in network rules using Firewall Policy now in preview.
- Monitoring in place for 3P integration, alerting in place for control plane failures, 100% features now supported in ASC, 3P validation in place for BVTs and canary environments
Azure Core Networking
Network Encryption
This new addition to Azure data protection is amazing. Imagine encrypting all your data ‘in the wire’, whether is crossing the region or going inter-region. The good old MACSec encryption deployed at massive scale, in all Azure regions, for all your traffic, without any user action
0 Comments