Kategorie: Microsoft Azure

Choosing between Azure VNet Peering and VNet Gateways

As customers adopt Azure and the cloud, they need fast, private, and secure connectivity across regions and Azure Virtual Networks (VNets). Based on the type of workload, customer needs vary. For example, if you want to ensure data replication across geographies you need a high bandwidth, low latency connection. Azure offers connectivity options for VNet that cater to varying customer needs, and you can connect VNets via VNet peering or VPN gateways.

It is not surprising that VNet is the fundamental building block for any customer network. VNet lets you create your own private space in Azure, or as I call it your own network bubble. VNets are crucial to your cloud network as they offer isolation, segmentation, and other key benefits. Read more about VNet’s key benefits in our documentation “What is Azure Virtual Network?”

VNet peering

VNet peering enables you to seamlessly connect Azure virtual networks. Once peered, the VNets appear as one, for connectivity purposes. The traffic between virtual machines in the peered virtual networks is routed through the Microsoft backbone infrastructure, much like traffic is routed between virtual machines in the same VNet, through private IP addresses only. No public internet is involved. You can peer VNets across Azure regions, too – all with a single click in the Azure Portal.

VNet peering – connecting VNets within the same Azure region
Global VNet peering – connecting VNets across Azure regions

To learn more, look at our documentation overview "Virtual network peering" and "Create, change, or delete a virtual network peering."

VPN gateways

A VPN gateway is a specific type of VNet gateway that is used to send traffic between an Azure virtual network and an on-premises location over the public internet. You can also use a VPN gateway to send traffic between VNets. Each VNet can have only one VPN gateway.

To learn more, look at our documentation overview "What is VPN Gateway?" and "Configure a VNet-to-VNet VPN gateway connection by using the Azure portal."

Which is best for you?

While we offer two ways to connect VNets, based on your specific scenario and needs, you might want to pick one over the other.

VNet Peering provides a low latency, high bandwidth connection useful in scenarios such as cross-region data replication and database failover scenarios. Since traffic is completely private and remains on the Microsoft backbone, customers with strict data policies prefer to use VNet Peering as public internet is not involved. Since there is no gateway in the path, there are no extra hops, ensuring low latency connections.

VPN Gateways provide a limited bandwidth connection and is useful in scenarios where encryption is needed, but bandwidth restrictions are tolerable. In these scenarios, customers are also not as latency-sensitive.

VNet Peering and VPN Gateways can also co-exist via gateway transit

Gateway transit enables you to use a peered VNet’s gateway for connecting to on-premises instead of creating a new gateway for connectivity. As you increase your workloads in Azure, you need to scale your networks across regions and VNets to keep up with the growth. Gateway transit allows you to share an ExpressRoute or VPN gateway with all peered VNets and lets you manage the connectivity in one place. Sharing enables cost-savings and reduction in management overhead.

With gateway transit enabled on VNet peering, you can create a transit VNet that contains your VPN gateway, Network Virtual Appliance, and other shared services. As your organization grows with new applications or business units and as you spin up new VNets, you can connect to your transit VNet with VNet peering. This prevents adding complexity to your network and reduces management overhead of managing multiple gateways and other appliances.

To learn more about the powerful and unique functionality of gateway transit, refer to our blog post "Create a transit VNet using VNet peering."

Differences between VNet Peering and VPN Gateways

 

 

VNet Peering

VPN Gateways

Cross-region support?

Yes – via Global VNet Peering

 

Yes

Cross-Azure Active Directory tenant support?

Yes, learn how to set it up in our documentation "Create a virtual network peering."

Yes, see our documentation on VNet-to-VNet connections. 

Cross-subscription support?

Yes, see our documentation "Resource Manager, different subscriptions."

Yes, see our documentation "Configure a VNet-to-VNet VPN gateway connection by using the Azure portal."

Cross-deployment model support?

Yes, see our documentation "different deployment models, same subscription."

 

Yes, see our documentation "Connect virtual networks from different deployment models using the portal."

Limits

You can keep up to 500 VNets with one VNet as seen in the documentation on Networking Limits.

Each VNet can only have one VPN Gateway. VPN Gateways depending on the SKU have type different number of tunnel supported.

Pricing

Ingress/Egress charged.

Gateway + Egress charged.

 

Encrypted?

Software level encryption is recommended

Yes, custom IPsec/IKE policy can be created and applied to new or existing connections.

Bandwidth limitations?

No bandwidth limitations.

Varies based on type of Gateway from 100 Mbps to 1.25Gps.

 

Private?

Yes, no Public IP endpoints. Routed through Microsoft backbone and is completely private. No public internet involved.

Public IP involved.

Transitive relationship

If VNet A is peered to VNet B, and VNet B is peered to VNet C, VNet A and VNet C cannot currently communicate. Spoke to spoke communication can be achieved via NVAs or Gateways in the hub VNet. See an example in our documentation.

If VNet A, VNet B, and VNet C are connected via VPN Gateways and BGP is enabled in the VNet connections, transitivity works.

Typical customer scenarios

Data replication, database failover, and other scenarios needing frequent backups of large data.

Encryption specific scenarios that are not latency sensitive and do not need high throughout.

Initial setup time

It took me 24.38 seconds, but you should give it a shot!

30 mins to set it up

FAQ link

VNet peering FAQ

VPN gateway FAQ

Conclusion

Azure offers VNet peering and VNet gateways to connect VNets. Based on your unique scenario, you might want to pick one over the other. We recommend VNet peering within region/cross-region scenarios.

We always love to hear from you, so please feel free to provide any feedback via our forums.
Quelle: Azure

Announcing general availability for the Azure Security Center for IoT

As organizations pursue digital transformation by connecting vital equipment or creating new connected products, IoT deployments will get bigger and more common. In fact, IDC forecasts that IoT will continue to grow at double digit rates until IoT spending surpasses $1 trillion in 2022. As these IoT deployments come online, newly connected devices will expand the attack surface available to attackers, creating opportunities to target the valuable data generated by IoT.

Organizations understand the risks and are rightly worried about IoT. Bain’s research shows that security concerns are the top reason organizations have slowed or paused IoT rollouts*. Because IoT requires integrating many different technologies (heterogenous devices must be linked to IoT cloud services that connect to analytics services and business applications), organizations face the challenge of securing both the pieces of their IoT solution and the connections between those pieces. Attackers target weak spots; even one weak device configuration, cloud service, or admin account can provide a way into your solution. Your organization must monitor for threats and misconfigurations across all parts of your IoT solution: devices, cloud services, the supporting infrastructure, and the admin accounts who access them.

To give your organization IoT threat protection and security posture management across your entire IoT solution, we’re announcing the general availability of Azure Security Center for IoT. Azure Security Center allows you to protect your end-to-end IoT deployment by identifying and responding to emerging threats, as well as finding issues in your configurations before attackers can use them to compromise your deployment. As organizations use Azure Security Center for IoT to manage their security roadblocks, they remove the barriers keeping them from business transformation:

“With Azure Security Center for IoT, we can both address very real IoT threat models with the velocity of Azure and gain management control over the fastest scaling part of our business, which allows me to focus on delivering outcomes rather than hot fixing devices.” – Alex Kreilein, CISO RapidDeploy

Building secure IoT solutions with Azure Security Center

Securing IoT is challenging for many reasons: IoT deployments are complicated, creating opportunity for integration errors that attackers can exploit; IoT devices are heterogenous and often lack proper security measures; organizations may not have the skillsets or SecOps headcount to take on a new IoT security workload; and IoT deployments are difficult to monitor using traditional IT security tools. When organizations choose Microsoft for their IoT deployments, however, they get secure-by-design devices and services such as Azure Sphere and IoT Hub, end-to-end integration and monitoring from device to cloud, and the expertise from Microsoft and our partners to build a secure solution that meets their exact use case.

Azure Security Center for IoT builds on Microsoft’s secure-by-design IoT services with threat protection and security posture management designed for securing entire IoT deployments, including Microsoft and 3rd party devices. Azure Security Center is the first IoT security service from a major cloud provider that enables organizations to prevent, detect, and help remediate potential attacks on all the different components that make up an IoT deployment: from small sensors, to edge computing devices and gateways, to Azure IoT Hub, and on to the compute, storage, databases, and AI/ML workloads that organizations connect to their IoT deployments. This end-to-end protection is vital to secure IoT deployments. Although devices may be a common target for attackers, the services that store your data and the admins who manage your IoT solution are also valuable targets.

As IoT threats evolve due to creative attackers analyzing the new devices, use cases, and applications the industry creates, Microsoft’s unique threat intelligence, sourced from the more than 6 trillion signals that Microsoft collects every day, keeps your organization ahead of attackers. Azure Security Center creates a list of potential threats, ranked by importance, so security pros and IoT admins can remediate problems across devices, IoT services, connected Azure services, and the admins who use them.

Azure Security Center also creates ranked lists of possible misconfigurations and insecure settings, allowing IoT admins and security pros to fix the most important issues in their IoT security posture first. To create these security posture suggestions, Azure Security Center draws from Microsoft’s unique threat intelligence, as well as the industry standards. Customers can also port their data into SIEMs such as Azure Sentinel, allowing security pros to combine IoT security data with data from across the organization for artificial intelligence or advanced analysis.

Organizations can monitor their entire IoT solution, stay ahead of evolving threats, and fix configuration issues before they become threats. When combined with Microsoft’s secure-by-design devices, services, and the expertise we share with you and your partners, Azure Security Center for IoT provides an important way to reduce the risk of IoT while achieving your business goals. 

Next steps

Watch Securing your IoT Application with Azure Security Center.
Get started with IoT Hub to start using Azure Security Center for IoT.
Learn more about Azure Security Center.
Learn more about IoT Security.

 

*Used with permission from Bain & Company
Quelle: Azure

Accessing virtual machines behind Azure Firewall with Azure Bastion

Azure Virtual Network enables a flexible foundation for building advanced networking architectures. Managing heterogeneous environments with various types of filtering components, such as Azure Firewall or your favorite network virtual appliance (NVA), requires a little bit of planning.

Azure Bastion, which is currently in preview, is a fully managed platform as a service (PaaS) that provides secure and seamless remote desktop protocol (RDP) and secure shell (SSH) access to your virtual machines (VMs) directly through the Azure portal. Azure Bastion is provisioned directly in your virtual network, supporting all VMs attached without any exposure through public IP addresses.

When you deploy Azure Firewall, or any NVA, you invariably force tunnel all traffic from your subnets. Applying a 0.0.0.0/0 user-defined route can lead to asymmetric routing for ingress and egress traffic to your workloads in your virtual network.

While not trivial, you often find yourself creating and managing a growing set of network rules, including DS NAT, forwarding, and so on, for all your applications to resolve this. Although this can impact all your applications, RDP and SSH are the most common examples. In this scenario, the ingress traffic from the Internet may come directly to your virtual machine within your virtual network, but egress traffic will end up going to the NVA. Since most NVAs are stateful, it ends up dropping this traffic as it did not initially receive it.

Azure Bastion, allows for simplified set up of RDP/SSH to your workloads within virtual networks containing stateful NVAs or Azure Firewall with force tunneling enabled. In this blog, we will look at how to make that work seamlessly.

For a reference on how to deploy Azure Bastion (preview) in your virtual network, please see the documentation “Create an Azure Bastion host (Preview).”
To learn how to implement Azure Firewall in your virtual network, refer to the documentation “Deploy and configure Azure Firewall using the Azure portal.”

Having deployed both Azure Bastion and Azure Firewall in your virtual network, let us look at how you can configure Azure Bastion to work in this scenario.

Configuring Azure Bastion

When deploying Azure Firewall, or a virtual appliance, you may end up associating your RouteTable, which was created while deploying Azure Firewall, to all subnets in your virtual network. You may even be including the AzureBastionSubnet subnet as well. 

This applies a user-defined route to the AzureBastionSubnet subnet which directs all Azure Bastion traffic to Azure Firewall, thereby blocking traffic required for Azure Bastion. To avoid this, configuring Azure Bastion is very easy, but do not associate the RouteTable to AzureBastionSubnet subnet.

As you would have noticed above, myRouteTable is not associated with the AzureBastionSubnet, but with other subnets like Workload-SN.

The AzureBastionSubnet subnet is secure platform managed subnet, and no other Azure Resource can deploy in this subnet except Azure Bastion. All connections to Azure Bastion are enforced through the Azure Active Directory token-based authentication with 2FA, and all traffic is encrypted/over HTTPS. 

Azure Bastion is internally hardened and allows traffic only through port 443, saving you the task of applying additional network security groups (NSGs) or user-defined routes to the subnet.

With this, the RDP/SSH requests will land on Azure Bastion. Configured using the example above, the default route (0.0.0.0/0) does not apply to AzureBastionSubnet as it's not associated with this subnet. Based on the incoming RDP/SSH requests, Azure Bastion connects to your virtual machines in other subnets, like Workload-SN, which do have a default route associated. The return traffic from your virtual machine will go directly to Azure Bastion, instead of going to the NVA, in your virtual network as the return traffic is directed to a specific private IP in your virtual network. The specific private IP address in your virtual network makes it a more specific route and hence, takes precedence over the force-tunnel route to the NVA, making your RDP/SSH traffic work seamlessly with Azure Bastion when a NVA or Azure Firewall is deployed in your virtual network.

We are grateful and appreciate the engagement and excitement of customers and community and are looking forward to your feedback in further improving the service and making it generally available soon.
Quelle: Azure

Azure publishes guidance for secure cloud adoption by governments

Governments around the world are in the process of a digital transformation, actively investigating solutions and selecting architectures that will help them transition many of their workloads to the cloud. There are many drivers behind the digital transformation, including the need to engage citizens, empower employees, transform government services, and optimize government operations. Governments across the world are also looking to improve their cybersecurity posture to secure their assets and counter the evolving threat landscape.

To help governments worldwide get answers to common cloud security related questions, Microsoft published a white paper, titled Azure for Secure Worldwide Public Sector Cloud Adoption. This paper addresses common security and isolation concerns pertinent to worldwide public sector customers. It also explores technologies available in Azure to help safeguard unclassified, confidential, and sensitive workloads in the public multi-tenant cloud in combination with Azure Stack and Azure Data Box Edge deployed on-premises and at the edge for fully disconnected scenarios involving highly sensitive data. The paper addresses common customer concerns, including:

Data residency and data sovereignty
Government access to customer data, including CLOUD Act related questions
Data encryption, including customer control of encryption keys
Access to customer data by Microsoft personnel
Threat detection and prevention
Private and hybrid cloud options
Cloud compliance and certifications
Conceptual architecture for classified workloads

For governments and the public sector industry worldwide, Microsoft provides Azure – a public multi-tenant cloud services platform that government agencies can use to deploy a variety of solutions. A multi-tenant cloud platform implies that multiple customer applications and data are stored on the same physical hardware. Azure uses logical isolation to segregate each customer's applications and data from those of others. This approach provides the scale and economic benefits of multi-tenant cloud services while rigorously helping prevent customers from accessing one another's data or applications.

A hyperscale public cloud provides resiliency in times of natural disaster or other disturbances. The cloud provides capacity for failover redundancy and empowers sovereign nations with flexibility regarding global resiliency planning. A hyperscale public cloud also offers a feature-rich environment incorporating the latest cloud innovations such as artificial intelligence, machine learning, Internet of Things (IoT) services, intelligent edge, and more. This rich feature set helps government customers increase efficiency and unlock insights into their operations and performance.

Using Azure’s public cloud capabilities, customers benefit from rapid feature growth, resiliency, and the cost-effective operation of the hyperscale cloud while still obtaining the levels of isolation, security, and confidence required to handle workloads across a broad spectrum of data classifications, including unclassified and classified data. Leveraging Azure isolation technologies, as well as intelligent edge capabilities (such as Azure Stack and Azure Data Box Edge), customers can process confidential and sensitive data in secure isolated infrastructure within Azure’s multi-tenant regions or highly sensitive data at the edge under the customer’s full operational control.

To get answers to common cloud security related questions, government customers worldwide should review Azure for Secure Worldwide Public Sector Cloud Adoption. To learn more about how Microsoft helps customers meet their own compliance obligations across regulated industries and markets worldwide, review “Microsoft Azure compliance offerings.
Quelle: Azure

Always-on, real-time threat protection with Azure Cosmos DB – part one

This two-part blog post is a part of a series about how organizations are using Azure Cosmos DB to meet real world needs, and the difference it’s making to them. In part one, we explore the challenges that led the Microsoft Azure Advanced Threat Protection team to adopt Azure Cosmos DB and how they’re using it. In part two, we’ll examine the outcomes resulting from the team’s efforts.

Transformation of a real-time security solution to cloud scale

Microsoft Azure Advanced Threat Protection is a cloud-based security service that uses customers’ on-premises Azure Active Directory signals to identify, detect, and investigate advanced threats, compromised identities, and malicious insider actions. Launched in 2018, it represents the evolution of Microsoft Advanced Threat Analytics, an on-premises solution, into Azure. Both offerings are composed of two main components:

An agent, or sensor, which is installed on each of an organization’s domain controllers. The sensor inspects traffic sent from users to the domain controller along with Event Tracing for Windows (ETW) events generated by the domain controller, sending that information to a centralized back-end.
A centralized back-end, or center, which aggregates the information from all the sensors, learns the behavior of the organization’s users and computers, and looks for anomalies that may indicate malicious activity.

Advanced Threat Analytics’ center used an on-premises instance of MongoDB as its main database—and still does today for on-premises installations. However, in developing the Azure Advanced Threat Protection center, a managed service in the cloud, Microsoft needed something more performant and scalable. “The back-end of Azure Advanced Threat Protection needs to massively scale, be upgraded on a weekly basis, and run continuously-evolving, advanced detection algorithms—essentially taking full advantage of all the power and intelligence that Azure offers,” explains Yaron Hagai, Principal Group Engineering Manager for Advanced Threat Analytics at Microsoft.

In searching for the best database for Azure Advanced Threat Protection to store its entities and profiles—the data learned in real time from all the sensors about each organization’s users and computers—Hagai’s team mapped out the following key requirements:

Elastic, per-customer scalability: Each organization that adopts Azure Advanced Threat Protection can install hundreds of sensors, generating potentially tens of thousands of events per second. To learn each organization’s baseline and apply its anomaly detection algorithms in real-time, Azure Advanced Threat Protection needed a database that could efficiently and cost-effectively scale.
Ease of migration: The Azure Advanced Threat Protection data model is constantly evolving to support changes in detection logic. Hagai’s team didn’t want to worry about constantly maintaining backwards compatibility between the service’s code and its ever-changing data model, which meant they needed a database that could support quick and easy data migration with almost every new update to Azure Advanced Threat Protection they deployed.
Geo-replication: Like all Azure services, Advanced Threat Protection must support customers’ critical disaster recovery and business continuity needs, including in the highly unlikely event of a datacenter failure. Through the use of geo-replication, customers’ data can be replicated from a primary datacenter to a backup datacenter, and the Azure Advanced Threat Protection workload can be switched to the backup datacenter in the event of a primary datacenter failure.

A managed, scalable, schema-less database in the cloud

The team chose Azure Cosmos DB as the back-end database for Azure Advanced Threat Protection. “As the only managed, scalable, schema-less database in Azure, Azure Cosmos DB was the obvious choice,” says Hagai. “It offered the scalability needed to support our growing customer base and the load that growth would put on our back-end service. It also provided the flexibility needed in terms of the data we store on each organization and its computers and users. And it offered the flexibility needed to continually add new detections and modify existing ones, which in turn requires the ability to constantly change the data stored in our Azure Cosmos DB collections.”

Collections and partitioning

Of the many APIs that Azure Cosmos DB supports, the development team considered both the SQL API and the Azure Cosmos DB API for MongoDB for Azure Advanced Threat Protection. Eventually, they chose the SQL API because it gave them access to a rich, Microsoft-authored client SDK with support for multi-homing across global regions, and direct connectivity mode for low latency. Developers chose to allocate one Azure Cosmos DB database per tenant, or customer. Each database has five collections, which each start with a single partition. “This allows us to easily delete the data for a customer if they stop using Azure Advanced Threat Protection,” explains Hagai. “More importantly, however, it lets us scale each customer’s collections independently based on the throughput generated by their on-premises sensors.”

Of the set of collections per customer, two usually grow to more than one partition:

UniqueEntity, which contains all the metadata about the computers and users in the organization, as synchronized from Active Directory.
UniqueEntityProfile, which contains the behavioral baseline for each entity in the UniqueEntity collection and is used by detection logic to identify behavioral anomalies that imply a compromised user or computer, or a malicious insider.

“Both collections have very high read/write throughput with large Request Units per second (RU/s) consumption,” explains Hagai. “Azure Cosmos DB seamlessly scales out storage of collections as they grow, and some of large customers have scaled up to terabytes in size per collection, which would have not been possible with MongoDB on VMs.”

The other three collections for each customer typically contain less than 1,000 documents and do not grow past a single partition. They include:

SystemProfile, which contains data learned for the tenant and applied to behavioral based detections.
SystemEntity, which contains configuration information and data about tenants.
Alert, which contains alerts that are generated and updated by Azure Advanced Threat Protection.

Migration

As the Azure Advanced Threat Protection detection logic constantly evolves and improves, so does the behavioral data stored in each customer’s UniqueEntityProfile collection. To avoid the need for backwards compatibility with outdated schemas, Azure Advanced Threat Protection maintains two migration mechanisms, which run with each upgrade to the service that includes changes to its data models:

On-the-fly: As Azure Advanced Threat Protection reads documents from Azure Cosmos DB, it checks their version field. If the version is outdated, Azure Advanced Threat Protection migrates the document to the current version using explicit transformation logic written by Hagai’s team of developers.
Batch: After a successful upgrade, Azure Advanced Threat Protection spins up a scheduled task to migrate all documents for all customers to the newest version, excluding those that have already been migrated by the on-the-fly mechanism.

Together, these two migration mechanisms ensure that after the service was upgraded and the data access layer code was changed, no errors will occur due to parsing outdated documents. No backwards compatibility code is needed besides the explicit migration code, which is always removed in the subsequent version.

Automatic scaling and backups

Collections with very high read/write throughput often are rate-limited as they reach their provisioned RU/s limits for a collection. When one of the service’s nodes, each node is a virtual machine, tries to perform an operation against a collection and gets a “429 Too Many Requests” rate limiting exception, it uses Azure Service Fabric remoting to send a request to a centralized auto-scale service for increased throughput. The centralized service aggregates such requests from multiple nodes to avoid increasing throughput more than once within a short window of time, as this may be caused by a single burst of throughput that affects multiple nodes. To minimize overall RU/s costs, a similar, periodic scale-down process reduces provisioned throughput when appropriate, such as during each customer’s non-working hours.

Azure Advanced Threat Protection takes advantage of the auto-backup feature of Azure Cosmos DB to help protect each of the collections. The backups reside in Azure Blob storage and are replicated to another region through the use of geo-redundant storage (GRS). Azure Advanced Threat Protection also replicates customer configuration data to another region, which allows for quick recovery in the case of a disaster. “We do this primarily to safeguard the sensor configuration data—preventing the need for an IT admin to reconfigure hundreds of sensors if the original database is lost,” explains Hagai.

Azure Advanced Threat Protection recently began onboarding full geo-replication. “We’ve started to enable geo-replication and multi-region writes for seamless and effortless replication of our production data to another region,” says Hagai. “This will allow us to further improve and guarantee service availability and will simplify service delivery versus having to maintain our own high-availability mechanisms.”

Continue on to part two, which covers the outcomes resulting from the Azure Advanced Threat Protection team’s implementation of Azure Cosmos DB.
Quelle: Azure

Always-on, real-time threat protection with Azure Cosmos DB – part two

This two-part blog post is a part of a series about how organizations are using Azure Cosmos DB to meet real world needs, and the difference it’s making to them. In part one, we explored the challenges that led the Microsoft Azure Advanced Threat Protection team to adopt Azure Cosmos DB and how they’re using it. In part two, we’ll examine the outcomes resulting from the team’s efforts.

Built-in scalability, performance, availability, and more

The Azure Advanced Threat Protection team’s decision to use Azure Cosmos DB for its cloud-based security service has enabled the team to meet all key requirements, including zero database maintenance, uncompromised real-time performance, elastic scalability, high availability, and strong security and compliance. “Azure Cosmos DB gives us everything we need to deliver an enterprise-grade security service that’s capable of supporting the largest companies in the world, including Microsoft itself,” says Yaron Hagai, Principal Group Engineering Manager for Advanced Threat Analytics at Microsoft.

Zero maintenance

A managed database service has saved Hagai’s team immense maintenance efforts, allowing Azure Advanced Threat Protection to stay up and running with only a handful of service engineers. “Azure Advanced Threat Protection saves us from having to patch and upgrade servers, worry about compliance, and so on,” says Hagai. “We also get capabilities like encryption at rest without any work on our part, which further enables us to direct our resources to improving the service instead of keeping it up and running.”

Scaling to support customer growth is just as hands-free. “We use Azure CLI scripts to provision and deprovision clusters in multiple Azure regions—it’s all done automatically, so new clusters for new customers can be deployed easily and when needed,” says Hagai. “Scaling is also automatic. Throughput-based splitting has been especially helpful because it lets our databases scale to support customer growth with zero maintenance from the team.”

Real-time performance

Azure Cosmos DB is delivering the performance needed for an important security service like Azure Advanced Threat Protection. “Since we protect organizations after they have been breached, speed of detection is essential to minimizing the damage that might be done,” explains Hagai. “A high-throughout, super-scalable database lets us support lots of complex queries in real-time, which is what allows us to go from breach to alerting in seconds. The performance provided by Azure Cosmos DB is one more thing that makes it the most production-grade document DB in the market, which is another reason we chose it.”

The following graph shows sustained high throughout for the service’s largest tenant, with a heavy bias towards writes, which happen every 10 minutes as Azure Advanced Threat Protection persists in-memory caches of profiles to Azure Cosmos DB.

Elastic scalability

Since Azure Advanced Threat Protection launched in March 2018, its usage has grown exponentially in terms of both users protected and paying organizations. “Azure Cosmos DB allows us to scale constantly, without any friction, which has helped us support a 600 percent growth in our customer base over the past year,” says Hagai. “That same scalability allows us to support larger customer installations than we could with Microsoft Advanced Threat Analytics, our on-premises solution. Microsoft’s own internal network is a prime example; it had grown too large to support with a single, on-premises server running Mongo DB, but with Azure Cosmos DB, it’s no problem.”

Scaling up and down to support frequent fluctuations in traffic, as shown in the following graph, is just as painless. “The graph shows traffic for our largest tenant, with the spikes in throughout due to scheduled tasks that produce business telemetry,” he explains. “This is a great example of the auto-scaling benefits of Azure Cosmos DB and how they allow us to automatically scale up individual databases to support a short burst of throughput each day, then automatically scale back down after the telemetries are calculated to minimize our service delivery costs.”

Strong security and compliance

Because Azure Advanced Threat Protection is built on Azure Cosmos DB and other Azure services, which themselves have high compliance certifications, it was easy to achieve the same for Azure Advanced Threat Protection. “The access control mechanisms in Azure Cosmos DB allow us to easily secure access and apply advanced JIT policies, helping us keep customer data secure,” says Hagai.

High availability

Although the availability SLA for Azure Cosmos DB is 99.999 percent for multi-region databases, to Hagai, the actual availability they’ve seen in production is even higher. “I had the Azure Cosmos DB team pull some historical availability numbers, and it turns out that the actual availability we’ve seen during April, May, and June of 2019 has been between 99.99995 and 99.99999 percent,” says Hagai. “To us, that’s essentially 100 percent uptime, and another thing we don’t need to worry about.”

Learn more about Azure Advanced Threat Protection and Azure Cosmos DB today.
Quelle: Azure

IoT sensors and wearables revolutionize patient care

When was the last time you or a loved one went to the doctor or hospital? Things have changed dramatically over the last few years, with kiosks to register, portals to track your health history, and texts reminding you about upcoming appointments.

These changes have made a difference in how we interact with our healthcare providers. But there are more changes, not on the horizon, but here today. It is estimated as many as 50 billion medical devices will connect to clinicians, health systems, patients, and to each other.

Cardiac patient monitoring improvements

Imagine that you or a family member have periodic symptoms of irregular heartbeats, an all too common medical disorder known as an arrhythmia. If persistent, an arrhythmia can cause blood to clot in the heart, significantly increasing the risk of a heart attack or stroke. If caught early, a clot or blockage can be contained or cleared away and stent can be put in to keep blood flowing normally. In the US, more than 1.8 million stents are implanted annually, along with countless other preventative cardiac procedures to treat the 28.2 million US adults with diagnosed heart disease. Following any cardiac related procedure, a patient is typically counseled about the importance of exercise and nutrition then sent home. Post procedure, it’s common to be concerned about another cardiac related event in the immediate days following discharge, but what if the patient could be proactive, as well as reactive, to cardiac disease? 

Peerbridge Health, a New York-based remote patient monitoring company has developed the Peerbridge Cor™ (Cor), an award-winning, multi-channel wearable electrocardiogram (ECG) to better assist physicians and their patients detect and treat irregular heart activity, expeditiously. Prescribed by a cardiologist, the Cor is an elegant wearable worn 24 hours a day for up to 7 days with the ability to record every single heartbeat. In the event of abnormal cardiac activity, the patient can transmit select ECG activity to the prescribing physician’s care team for analysis at the press of a button. This continuous recording with transmitted events provides an unparalleled “window” into the patient’s heart activity as they go about their daily activities. Finally, an ECG monitoring solution providing critical data transmission patient’s expect with modern medicine.

Frustrated by all the wires in the hospital, Peerbridge Health was founded by Dr. Angelo Acquista when he was caring for his father in the ECU in 2006. Instead of getting up and walking around, his father was covered in wires and sensors unable to move, like most cardiac patients. Shortly after this experience, Dr. Acquista started Peerbridge Health, determined to change how this chronic disease is managed. Today, Peerbridge is a leading-edge manufacturer of the Peerbridge Cor (pictured above), the smallest and lightest FDA-cleared, multi-channel, wireless ECG.

The Peerbridge team selected Microsoft’s Azure IoT platform for their cardiac monitor because they, “saw the Microsoft IoT platform as being a foundational ingredient to help them grow and scale.” Peerbridge CEO, Adrian Gilmore states, “Azure IoT not only provides the secure data stream that is needed to monitor patients, it also offers cloud tools enabling us to present data in formats physicians expect, making the entire system a real revolution in cardiac care.” He continued, “Our engagement at the Microsoft AI and IoT Insider Lab, was the perfect opportunity for us to sharpen our team’s digital strategy, ensuring we optimize the company’s cloud architecture, and take full advantage of the variety of data services Microsoft offers.”

Avoiding diabetic amputations

Another company, Sensoria Health, a Seattle-based company, has taken on the problem of diabetes-related amputations. Why diabetes? Well, the statistics from the American Podiatric Medical Association are staggering:

More than 400 million people have diabetes worldwide
32 million people in the US have diabetes, costing more than 327 billion dollars
In the world today, a lower limb is lost to diabetes every 20 seconds
Cost in the US is estimated to be about 20 billion dollars

The typical progression to the amputation of a toe, foot, or more, always begins with a foot ulcer. The team at Sensoria asked themselves, “What can be done to expedite the healing of foot wounds to avoid amputations?” In response, Sensoria joined forces Optima to develop the Motus Smart powered by Sensoria®. It combines Sensoria® Core technologies, together with the clinically-tested Optima Molliter Offloading System, to take the pressure off the area of ulceration to improve blood circulation which is a critical factor to improve chance of healing.

Originally unveiled at the Consumer Electronics Show in January 2018, where it won Innovation Honoree Award, the Motus Smart, leverages Sensoria® Core to monitor activity and compliance, and is a clinically-proven and viable alternative to a total contact cast, and non-removable cam boot. The Sensoria® sensors work with a real-time app and alert system and an Azure based dashboard to inform patients, caregivers, and clinicians of non-compliant patients, allowing for easy and immediate intervention. The expensive and uncomfortable cast finally has an IoT, viable, and clinically-proven alternative with Motus Smart.

Why did Sensoria choose Microsoft’s Azure IoT platform for their patient monitoring devices? Davide Vigano, co-founder and CEO of Sensoria, shares in this video the three reasons why they selected Azure:

The richness of the development tools and already knowing how to use them
The openness of the platform and ability to use open source
Microsoft’s understanding and command of the enterprise market segment

Furthermore, Sensoria is using the Microsoft cloud and the Azure IoT platform to build a connected medical device platform, as they continue to develop new patient monitoring devices, like their smart sock v2.0 and Sensoria® Core, that drive improved outcomes for a variety of conditions. 

Learn more

Want to learn more about Microsoft and our work in healthcare? Check out our healthcare microsite, detailing our approach to the cloud and security, as well as compelling customer stories from Ochsner Health, BD, and others.
Quelle: Azure