Microsoft Azure News, Entwicklungen, Updates, HowTos - Seite 199 von 255

Microsoft is laser-focused on enabling and accelerating enterprise adoption of blockchain technologies. Our blockchain offerings are well known for providing the ability to rapidly and consistently deploy blockchain infrastructure.

However, as our customers and partners began to build their distributed applications, they identified the application layer as an area where Microsoft could take even greater steps to reduce the time and cost associated with blockchain Proof of Concept (PoC) projects.

More time on smart contracts, less time on “scaffolding”

When our customers and partners estimate the time and costs for developing a blockchain PoC, they often find that it can take 8-12 weeks and cost as much as $300,000. Besides being time consuming and expensive, this is a huge missed opportunity. Quickly understanding the viability of a PoC can accelerate a business’s understanding of blockchain and save the time and cost associated with a less impactful project.

Microsoft identified that most of the time in these PoC projects was spent developing code and building capabilities that surrounded the blockchain, often referred to as “scaffolding.” That scaffolding typically required building a responsive web client, writing and deploying a gateway API, implementing support for off-chain storage in technologies such as SQL DB, building out reporting and analytics, and integrating identity and key vault services into the solution.

Lower costs and faster time to value with a PoC Framework

We realized there were a common set of challenges related to PoC development that we could address by creating a type of “Proof of Concept Framework” that would dramatically reduce the amount of time needed to build a blockchain PoC.

The framework provides code assets and ARM template driven deployment for all the scaffolding needed for blockchain PoCs, including the blockchain network, a gateway API, a responsive web application, Azure Active Directory integration, Azure Key Vault integration, SQL DB that is configured and collecting on-chain data, and a set of supporting code and services such as a Hashing Service and a Signing Service. The framework uses Azure’s Event Hubs at its core, which provides the ability to readily add new capabilities such as sending raw data to Azure Data Lake or providing transaction data to Azure Search.

The framework also makes it possible to create the web application without writing any code. It uses meta-data provided for smart contracts to dynamically deliver a contextual user experience for participants. Since the framework populates SQL DB as an off-chain store, it enables an organization to leverage existing skills and tools to light up additional capabilities such as APIs, reporting with PowerBI, chat bots, Azure Data Factory, R, and machine learning.

With the framework, customers and partners can focus on creating truly innovative applications that demonstrate the potential of blockchain, and spend less time and resources on integration tasks that required to get even a basic PoC up and running.

At the Consensus Conference in New York, we’re looking forward to the opportunity to demonstrate the framework for the first time, and to connect with customers and partners to discuss how it can help significantly accelerate blockchain PoC development.
Quelle: Azure

18. Mai 2017

da Agency

WannaCrypt attacks: guidance for Azure customers

The recent global ransomware attack, known as WannaCrypt, has brought forward the importance of running a well secured infrastructure. Whether or not you were impacted by the recent WannaCrypt malware, we recommend all Azure customers take the following 8 steps to further protect your organization from attacks like these.

This recent WannaCrypt malware exploits a Service Message Block (SMB) vulnerability (CVE-2017-0145). Customers should immediately install MS17-010 to resolve this vulnerability.
Review all Azure subscriptions that have SMB endpoints exposed to the internet, commonly associated with ports TCP 139, TCP 445, UDP 137, UDP 138. Microsoft recommends against opening any ports to the internet that are not essential to your operations.
Disable SMBv1 – instructions located here: https://aka.ms/disablesmb1
Utilize Windows Update to keep your machines up-to-date with the latest security updates. If you are running Azure Cloud Services (Platform as a Service Web Roles and Worker Roles or Infrastructure as a Service (IaaS)) automatic updates are enabled by default, so there is no further action required. All Guest OS versions released after March 14th, 2017 contain the MS17-010 update. You can view the update status of your resources on an on-going basis in Azure Security Center.
Use the Azure Security Center to continuously monitor your environment for threats. Collect and monitor event logs and network traffic to look for potential attacks using the Azure Security Center, and check for new security alerts and quickly investigate any threats detected.
Use Network Security Groups (NSGs) to restrict network access. To reduce exposure to attacks, configure NSGs with in-bound rules that restrict access to only required ports. You can use network firewalls from a range of companies for additional security. Azure Security Center provides a view of the security for all your networks in Azure, and helps you identify those with internet accessible endpoints, insufficient NSG protections, and in some cases recommends a firewall solution.
Confirm that anti-malware is deployed and updated. If you are using Microsoft anti-malware for Azure or Windows Defender, Microsoft released an update last week which detects this threat as Ransom:Win32/WannaCrypt. If you are running anti-malware software from any number of security companies, you should confirm with your provider that your are protected. You can also use Azure Security Center to verify that anti-malware, and other critical security controls, are configured for all of your Azure virtual machines.
Configure backups with multifactor authentication. An important part of recovery from any compromise is having a strong backup solution in place. If you are already using Azure Backup, you can recover data if your servers are attacked by ransomware. Only users with valid Azure credentials can access the backups stored in Azure. We also recommend enabling Azure Multi-Factor Authentication to provide an additional layer of security to your backups in Azure.

For a comprehensive look at the Affected Software, Vulnerability Information and Security Update Deployment, see Microsoft Security Bulletin MS17-010.

For more information about this update, see Microsoft Knowledge Base Article 4013389.

Support

For understanding your cloud security state: Azure Security Center

Help for installing updates: Windows Update FAQ

Security solutions for IT professionals: TechNet Security Support and Troubleshooting

Help for protecting your Windows-based computer from viruses and malware: Microsoft Secure
Quelle: Azure

18. Mai 2017

da Agency

In-Memory OLTP Update

In November 2016, we announced the general availability (GA) of In-Memory OLTP technology in Azure SQL Database worldwide. From then on we have been working towards unlocking some more useful features which we believe will significantly help you leverage this technology more efficiently into your applications.

Today we are pleased to announce a string of improvements to In-Memory OLTP technology in Azure SQL Database, which spans multiple avenues and continues to unlock and expand the T-SQL surface area and improve the overall manageability.

The new feature improvements are listed below and are available today in Azure SQL Database and will also be available in SQL Server vNext.

Increased number of indexes for memory-optimized tables

The limitation of 8 indexes for memory-optimized tables has been eliminated. You can now create as many indexes on memory-optimized tables as you can create on disk-based tables.

Any disk-based table in your database that you could not migrate previously because of this limitation can now be memory-optimized, and thus leverage the performance benefits of In-Memory OLTP technology.

In-Memory OLTP schema management

The GA of In-Memory OLTP in Azure SQL Database included support for ALTER operations on memory-optimized objects. This enabled you to perform most schema management operations such as adding or dropping columns, managing indexes, and updating natively compiled stored procedures. At that time, the one operation not yet supported was renaming objects.

We have addressed this now by adding support for the system stored procedure sp_rename with memory-optimized tables and natively compiled T-SQL modules. With this, Azure SQL Database now supports all the main schema management operations for In-Memory OLTP.

sp_rename – sp_rename is used to change the name of the user object in the current database. In-Memory OLTP objects such as tables, table columns, natively compiled procedures, etc. can now all be renamed with this stored procedure.

Note that natively compiled T-SQL modules must be created as schema-bound modules. Tables, columns, and modules referenced from a schema-bound module cannot be renamed. Therefore, to rename a table or column referenced from a natively compiled T-SQL module, first drop the module, then perform the rename, and finally recreate the module referencing the new name.

Max commit dependencies limit eliminated

The limit on the maximum number of transactions a given transaction depends on or the number of transactions that depend on a given transaction is eliminated.

So you will no longer receive the corresponding error message: "41839: Transaction exceeded the maximum number of commit dependencies".

Extended T-SQL support for In-Memory OLTP

In-Memory OLTP in Azure SQL Database at GA supported T-SQL surface area that was on full parity with SQL Server 2016, including support for constructs like DISTINCT, SUBQUERIES, IN, EXISTS, OR, NOT, OUTER JOIN, etc.

We have further extended the T-SQL support and added the following:

CASE – CASE expressions are now fully supported in SELECT statements in natively compiled T-SQL modules. Prior to this you would have to create a table variable to construct the single result set and from this table variable you would then SELECT based on the predicate that defines the CASE.
COMPUTED COLUMNS – Computed columns, as well as indexes on computed columns, are now supported in memory-optimized tables. Additionally, you can now also create indexes on these computed columns in memory-optimized tables.
CROSS APPLY and JSON – The CROSS APPLY operator is now supported in natively compiled T-SQL modules. In addition, all JSON functions and clauses are now supported in natively compiled T-SQL modules and on constraints in memory-optimized tables. Indexes on computed columns allow indexing JSON data. Learn more about optimizing JSON processing using In-Memory OLTP.

Another feature worth mentioning is the support for sp_spaceused. Even though on Azure SQL Database the storage is managed for you by the platform, sp_spaceused will give you a good insight into the storage characteristics of the data stored in memory-optimized tables.

sp_spaceused – sp_spaceused can now be used to understand the storage footprint associated with In-Memory OLTP. A new parameter '@include_total_xtp_storage' has been added to the stored procedure for the same. Get more details about sp_spaceused.

If you are currently leveraging In-Memory OLTP technology in your application or if you do plan on using it in the future, we sincerely hope that these improvements will enable new scenarios for you whilemaking it easier for you to leverage this technology in your application.
Quelle: Azure