Windows Azure Tips, tools, and coding best practices

In the process of writing this series of articles, I have summed up a number of best practices. In this article, I've covered more things to consider when protecting your Windows Azure application.

Here are some tools and coding tips and best practices:

run on the operating system get the latest security patches try to run error handling in partial trust mode how to implement retry logical record error in Windows Azure access to the Blob access to storage connection string doorman mode rotate storage key Cryptographic services to ensure data security

Running on the operating system

Get the latest security patches

When you create a new application using Visual Studio, the default behavior is to set the guest operating system version in the Serviceconfiguration.cscfg file as follows:

osfamily= "1"
osversion= "*"

This is good because you will automatically get updates, which is one of the main advantages of PaaS. This is not a best practice, however, because the operating system you are using is not the latest version. In order to use the latest operating system version (Windows Server R2), you should set it as follows:

Osfamily= "4" osversion= "*"

Unfortunately, many customers decide to use a specific version of the operating system on a regular schedule, hoping to increase uptime by avoiding guest OS updates. This applies only to enterprise customers: they systematically test each update in the staging deployment, and then plan a VIP exchange for critical business applications running in production deployments. For customers who do not test each guest operating system update, not configuring Automatic Updates places Windows Azure applications in a dangerous situation.

-Source: Troubleshooting Best Practices for developing Windows Azure applications

Try to run in partial trust mode

Cloud service By default, roles deployed to Windows Azure will run in full trust mode. You need full trust if you want to call non. NET code or use a. NET library that requires full trust, or any code or library that requires administrator privileges. Restricting your code to running in partial trust means that anyone who has access to your code can perform more limited operations.

Use partial trust to limit the extent of an attacker's damage when your WEB application is threatened. For example, by default, a malicious attacker cannot modify any ASP.net page on the disk or change any system binaries.

Because the user account is not an administrator on the virtual machine, using partial trust increases the limit more than Windows automatically imposes. This trust level is enforced through. NET Code access Security (CAS) support.

Partial trust is similar to the medium trust level in. NET. Grants access only to certain resources and operations. Typically, your code can only connect to an external IP address over TCP and can access only the files and folders in its local storage (not anywhere on the system). Any library that your code uses must be run in partial-trust mode, or be specifically marked as "Allow partially trusted callers" property.

You can explicitly configure the trust level of a role in the service definition file. The service definition Schema provides the enablenativecodeexecution attribute of the webrole element and the workerrole element. To run your role in partial-trust mode, you must add the Enablenativecodeexecution attribute on the Webrole or workerrole element and set it to false.

However, partial trust limits the functionality of the application. For trivial reasons, some useful libraries, such as libraries for accessing the registry or accessing well-known file locations, cannot be run in such environments. Even Microsoft's own frameworks do not run in this environment because they do not have the partially trusted caller attribute set.

For restrictions on running in partial trust, see Windows Azure Partial trust policy reference.

Handling Errors

Windows Azure can repair itself, can your application be?

Retry logic

Transient fault errors are caused by temporary conditions such as a network connection or a service unavailable. Typically, if you retry the operation that causes a transient error soon, you will find that the error has disappeared.

Different services may have different transient failures, and different applications require different fault handling strategies.

Although it may seem unrelated to security, it is a best practice to have the logic of a retry embedded in the application.

Azure Storage

The Windows Azure Storage Client Library with the accompanying SDK already has the required retry behavior. You can set the retry behavior on any storage client by setting the Retrypolicy property.

SQL, Service bus, cache, and Azure storage

However, SQL Azure does not provide a ready-made default retry mechanism because it uses the SQL Server client library. Service bus does not provide a retry mechanism.

Therefore, the Microsoft mode and practice team and Windows Azure Customer consulting team developed a transient fault handling application block. This block provides a variety of ways to handle specific SQL Azure, storage, Service bus, and cache conditions.

The transient fault handling application Block contains information about transient failures that may occur when you use the following Windows Azure service in your application:

SQL Azure Windows Azure Service bus Windows Azure storage Windows Azure cache service

Currently, this block includes enhanced configuration support, enhanced support for wrapper asynchronous calls, and integration of block retry policies with Windows Azure Storage retry mechanism for Enterprise Library Dependency injection containers.

Catching errors

Unfortunately, any system will inevitably fail, and Windows Azure will certainly fail. Even with the retry logic, you occasionally experience failures. You can add custom error handling to your asp.net Web application. Custom error handling simplifies debugging and increases customer satisfaction.

Eli Robillard is a member of the Microsoft MVP program, and his article asp.net a rich customization process that describes how to create error-handling mechanisms that are very user-friendly and still provide the detailed technical information that developers need.

If the error page is displayed, it should provide service to developers and end users without sacrificing beauty. The ideal error page maintains the look and feel of the site, has the ability to provide detailed error information for internal developers (identified by IP addresses), and ensures that no details are provided to end users. Instead, it makes it easy for users to return to the site they are looking for without causing confusion. Site administrators should be able to check for errors encountered in email or in the server log, optionally, and receive feedback from users who have encountered a failure.

Log errors in Windows Azure

ELMAH (Error logging module and handler) is very useful in itself, and simple modifications provide a very efficient way to handle error logging for the entire ASP.net Web application. My colleague Wade Wegner in his article in Windows
In Azure, the steps that he suggests are described in conjunction with table storage in ELMAH.

When ELMAH starts running the WEB application and configures it correctly, you get the following features without changing any of the lines of code:

records almost any unhandled exception. You can view a Web page that has logged an exception full record remotely. There is a Web page that can be used to remotely view the full details of any logged exception, including colorful stack trace. In many cases, you can check the original yellow panic that asp.net generates for a given exception, even when the customErrors mode is turned off. An e-mail notification is sent when each error occurs. The last 15 wrong RSS subscriptions in the record.

For more information about ELMAH, see the MSDN article to create pluggable ASP.net components using HTTP modules and handlers, written by Scott Mitchell and Atif Aziz. Also, see the ELMAH project page.

Remote access Error

There are many scenarios that you can use to remotely manage Windows Azure storage accounts. For example, during development and testing, you might want to be able to check the contents of tables, queues, and blobs to verify that your application is running as expected. You may also need to insert test data directly into the store.

In a production environment, you may need to check the contents of the application's storage during troubleshooting, or view the diagnostic data that you reserve. You may also want to download diagnostic data for offline analysis and be able to delete stored log files to reduce storage costs.

Web search allows you to discover more and more Third-party tools that can act as these roles. See the Windows Azure Storage Management tool for some useful tools.

Storage access rights

Key

One urgent concern is that no application should use any of the keys provided by Windows Azure as the key to encrypt data. For example, Windows Azure provides a key for storage services. These keys have been configured to allow for security purposes or are easily rotated when threatened for any reason. In other words, they may not exist in the future and may be widely distributed.

Rotate key

When you create a storage account, your account has two 256-bit account keys assigned. One of the keys must be specified in the header as part of the HTTP (S) request. Provides two keys for key rotation to maintain good data security. Typically, your application uses one of the keys to access the data. Then after a period of time (depending on you), you switch the application to use another key. If you know that all your applications are already using another key, you can generate a new secret key, which automatically invalidates the first key. With two keys in this way, your application can access the data without any downtime.

See how to view, copy, and regenerate access keys for Windows Azure storage accounts, learn how to view and copy access keys for Windows Azure storage accounts, and perform a rolling rebuild of primary and secondary access keys.