Search results matching tags 'Windows Azure', 'SQL Azure', 'Best Practices', and 'Cloud'

Pay in the future should make you think in the present

BuckWoody — Tue, 10 Apr 2012 13:53:50 GMT

Distributed Computing - and more importantly “-as-a-Service” models of computing have a different cost model. This is something that sounds obvious on the surface but it’s often forgotten during the design and coding phase of a project.

In on-premises computing, we’re used to purchasing a server and all of the hardware infrastructure and software licenses needed not only for one project, but several. This is an up-front or “sunk” cost that we consume by running code the organization needs to perform its function. Using a direct connection over wires you’ve already paid for, we don’t often have to think about bandwidth, hits on the data store or the amount of compute we use - we just know more is better. In a pay-as-you-go model, however, each of these architecture decisions has a potential cost impact. The amount of data you store, the number of times you access it, and the amount you send back all come with a charge. The offset is that you don’t buy anything at all up-front, so that sunk cost is freed up. And financial professionals know that money now is worth more than money later. Saving that up-front cost allows you to invest it in other things.

It’s not just that you’re using things that now cost money - it’s that the design itself in distributed computing has a cost impact. That can be a really good thing, such as when you dynamically add capacity for paying customers. If you can tie back the cost of a series of clicks to what a user will pay to do so, you can set a profit margin that is easy to track.

Here’s a case in point: Assume you are using a large instance in Windows Azure to compute some data that you retrieve from a SQL Azure database. If you don’t monitor the path of the application, you may not know what you are really using. Since you’re paying by the size of the instance, it’s best to maximize it all the time. Recently I evaluated just this situation, and found that downsizing the instance and adding another one where needed, adding a caching function to the application, moving part of the data into Windows Azure tables not only increased the speed of the application, but reduced the cost and more closely tied the cost to the profit.

The key is this: from the very outset - the design - make sure you include metrics to measure for the cost/performance (sometimes these are the same) for your application. Windows Azure opens up awesome new ways of doing things, so make sure you study distributed systems architecture before you try and force in the application design you have on premises into your new application structure.

“I could use a little help here” or “I can do it myself, thank you” for Cloud Projects

BuckWoody — Tue, 03 Apr 2012 13:20:55 GMT

Windows Azure allows you to write code in languages within the .NET stack, you can use Java, C++, PHP, NodeJS and others. Code is code - other than keeping things stateless, using a Web or Worker Role in Azure is not all that different from working with an on-premises system.

However….

Working in a scalable, component-based stateless architecture that can use federated security is not all that common for many developers. Some are used to owning the server, scaling up, and state-full paradigms that have a single security domain. Making the transition whilst trying to create a new software application or even port a previous one can be daunting. Sure, we have absolutely tons of free training, kits, videos, online books and more to learn on your own, but some things like architecture can be pivotal as you move along.

So the question is, should you just strike out on your own for a Cloud project, or get Microsoft Consulting Services or another partner to work with you on your first one? I use a few decision points to help guide the projects I assist in.

Note: I’m a huge fan of having help that ends up giving you training and leaves you in charge. If you do engage with someone to help you, make sure you keep this clear and take more and more ownership yourself as the project progresses.

How much time do you have?

Usually the first thing I ask is about the timeline for the project. It doesn’t matter how skilled you are, if you have a short window to get things done it’s better to get help - especially if this is your first cloud project. Having someone that knows the platform well can save you amazing amounts of time. If you have longer, then start with the training in the link above and once you feel confident, jump in.

How complex is the project?

If there are a lot of moving parts, it’s best to engage a partner. The reason is that certain interactions - particularly things like Service Bus or Data Integration - can be quite different than what you may have encountered before.

How many people do you have?

I have a “pizza rule” about projects I’ve used in my career - if it takes over two pizzas to feed everyone on the project, it’s too big and will fail. That being said, one developer and a one-week deadline does not a good project make, usually. It’s best to have at least one architect (or someone in that role) guiding the project along, and at least two developers to work on a cloud project. That’s a generalization of course, since I’ve seen great software on Azure with one developer writing code all by herself, but for more complex projects, more (to a point) is better. The nice thing about bringing on a partner is that you don’t have to hire them full time - they help you and then they go away.

How critical is the project?

There’s no shame in using some help. If the platform is new, if the project is large and complex, and if it is critical to the business, you should engage a partner. That’s regardless of Cloud or anything else - get some help. You don’t want to hit your company’s bottom line in a negative way, but you have to innovate and get them a competitive advantage. Do your research, make sure the partner is qualified to help you, and get it done.

Don’t let these questions scare you off. There are lots of projects you can implement on Windows and SQL Azure with nothing other than the Software Development Kit (SDK) that you get for free with Windows Azure. And assistance comes in many forms - sometimes just phone support, a friend you can ask. Microsoft Consulting Services or any of our great partners. You can get help on just the architecture piece or have them show you how to write the code. They’ll get involved as little or as much as you like.

Should All Data Be Encrypted By Default?

BuckWoody — Tue, 09 Aug 2011 13:45:04 GMT

Recently several IT industry information outlets have reported that there has been a 10-year concentrated, organized effort on breaking through computer security at some of the largest companies in the world. Government sites have also been attacked in multiple countries. Add to this the regular loss of data by banking and other industries, and the fear of “the cloud” as a storage location, and it seems to beg the question asked in the title in this post: “should all data, everywhere, be encrypted by default?”

If you’re new to encryption, there’s an excellent video and overview here: http://blogs.msdn.com/b/plankytronixx/archive/2010/10/23/crypto-primer-understanding-encryption-public-private-key-signatures-and-certificates.aspx

If all data were encrypted, the break-in to websites would still continue, but the value would be lessened for some types of “orthogonal” attacks that only seek the pure stream of data.

Data States

Computing has two major components - static program elements and data. The program doesn’t change (until it is updated, of course) over the course of a transaction between a user and the ultimate data store. Data is classified as anything that is manipulated by the program. That implies three states of the data interchange: Creation, Transmission, and Storage. In on-premise systems, many times none of these states are encrypted. The entire system from user to data store is viewed as “secure”, which of course evidence has proved it is not. In some cases, even laptops are viewed as part of an on-premise system, and so is left unprotected. If all data were treated as “publicly viewable”, that mindset would lead to encrypting the data at all states, even for on-premise systems.

Creation

In this phase, a user, device or other input program creates data to send to the program. This can be entries on a web form, input from a weather sensor, or one service (program) sending information to another service. There are multiple ways to encrypt data at this state, most notably using client-side libraries such as the Windows Crypto API, hardware encryption and others. The reference for the Crypto API is here: http://msdn.microsoft.com/en-us/library/ms867086.aspx

Transmission

After the data is created, it needs to be transmitted to the processing and storage system. the references above explain how to secure the communications channel between the client systems and the various components used within the system. In the case of Windows Azure, the session can be protected with a secure session, and all communications within the Azure datacenters are encrypted. The key is that the transmission of data, regardless of method, should be considered to be “in the clear”, and treated as such. Without the decryption algorithm, it’s much harder to get to the ultimate goal.

Storage (data at rest)

It follows that f the data is encrypted at the source, and the decryption method is retained only with the code that processes the data, then the data “at rest” if obtained is less accessible. If the data is not encrypted at the source, then this step should be put into place at a minimum. In many cloud systems, including Windows and SQL Azure, the data is not encrypted at rest. There are various reasons for this, including performance, physical and logical security already in place, and the fact that the encryption process would expose customer data to the provider while it is being encrypted. In this case, the key is to encrypt the data before it is transmitted and stored, so that it is encrypted ahead of time.

Considerations

Encrypting data is a separate process, and must be factored into the original codebase. This means additional effort, and more CPU power for the encryption process (although many systems have security hardware included which help with this) and of course protecting the keys. If the keys are accessed, the data is considered unencrypted from then on, and all previous encryption with that particular key is now vulnerable. Key rotation and protection is essential. Even so, the benefits of treating all data as being at risk outweighs the efforts.

You can learn more about general encryption here: http://msdn.microsoft.com/en-us/library/aa380255(VS.85).aspx

Windows Azure Security Review

BuckWoody — Tue, 02 Aug 2011 13:24:50 GMT

Current as of 08/01/2011 - Check the Resources listed below for more up-to-date information on this topic

Background:

Security for any computing platform involves three primary areas:

Principals (users or programmatic access to an asset or other program)
Securables (objects, data or programs that can be accessed)
Channels (methods of access by Principals to Securables)

On-premise systems normally use a central system to control security. In a Windows operating system-based environment, this is often accomplished with Active Directory or other systems that provide sign-on and user identity information. While other networking security paradigms have different terminology, all involve the three areas defined above.

In addition to the names and passwords for a user, Active Directory (like other security mechanisms) store other information about Principals - called Claims. These claims can include any custom fields the provider allows. In many networks, these fields are not used heavily, because applications that eventually need to secure the assets they control are not always deployed on the same platforms everywhere.

In a single environment, security is often quite simple. A Principal is created such as a user or group, and then the Principal is granted access to a Securable such as a a folder, database or other asset. Permissions or Rights (or both) combine to allow a particular Principal to read, write, delete or edit data, or to access or run a particular program.

Figure 1 - On-premise security environment example

The simplicity of this arrangement is due to a single, homogenous boundary. Even if more than one location is used, the Principals and Securables are grouped into a single logical boundary that is managed from one location.

This background serves as the starting point for the Federating Security topic below.

Windows Azure Security Boundaries

Windows Azure is a series of resources - servers, data and service buses, in addition to other features. Developers write code, and the deploy that to the Azure environment.

Figure 2 - Azure Components

The code or data can be deployed to use one or more of the services. In other words, the Web Role in Windows Azure might host a simple website, and no other component need be used.

Figure 3 - Simple Azure Web Role Application - only one feature used

Or, a complex mix of Web, Worker and Data Services, along with a Service Bus, RDBS and even on-site systems can be grouped into a much larger program.

Figure 4 - Complex Windows and SQL Azure Application With Multiple Interactions

For a more basic introduction to Windows and SQL Azure, see this link: http://channel9.msdn.com/Events/TechEd/Europe/2010/COS322

Windows Azure, like any web-based property, has three general layers of security:

Physical Access
Operating Environment (Including the Operating System itself)
Data and Programmatic Security

Each of these layers have additional layers within themselves, and this forms the basis of a secure experience for the end user or program. Some of these layers are the responsibility of Microsoft; others are the responsibility of the architect and developer; others are a joint or shared responsibility of both Microsoft and the client.

Layer One: Physical Access

The first layer of security within a web property such as Windows or SQL Azure is a secure facility. the following data points are important to understand for the worldwide facilities that host Windows and SQL Azure:

Microsoft Global Foundation Services (GFS) is responsible for the physical security of the datacenters located worldwide for Windows and SQL Azure. Information on Microsoft datacenters can be found here: http://www.globalfoundationservices.com/
The address and exact locations facilities are not commonly documented for security reasons.
Microsoft runs it’s own data centers and does not contract this function out.
The GFS controlled facilities hold an ISO/IEC 27001:2005 certification, and are audited to SAS level II.
Standard secure operations protocols are in place, including least-privilege access.

Layer Two: Operating Environment

Windows Azure and SQL Azure do not currently hold certifications. Microsoft does not comment on the security certifications being pursued for Windows or SQL Azure. That being said, the Windows Azure environment is based on a modified Windows 2008 R2 Enterprise environment, developed using the Trustworthy Computing Initiative (TCI).

The system controlling the host machines and their guest environments that ultimately hold the Web and Worker Roles within Windows Azure is called the Fabric - not to be confused with the Application Fabric feature. The Fabric is not accessible by client code - it controls the inner workings of Windows Azure, including Load-balancing, system restarts, maintenance and monitoring.

Within the host machines that house the Web and Worker Roles, special networking constructs broker all conversations between Virtual Machines. Virtual Machines - even ones configured to communicate with each other - move through this network. Direct-machine to machine communication is not allowed, protecting one application from another or one data construct from another.

Figure 5 - Windows Azure Fabric

Windows and SQL Azure support only TCP-based communications. Ports commonly used are:

80 - Default public port used for Web Roles - can be enabled/disabled per configuration
443 - Default secure port used for Web roles - can be enabled/disabled per configuration
9350-9353 - These ports are used by the Windows Azure AppFabric service bus bindings. Refer to http://msdn.microsoft.com/en-us/library/ee732535.aspx for more details
1433 - SQL Azure
3389 - This port is used for RDP access to VM-based roles, only if enabled

Layer Three: Data and Programmatic Security

All internal access through use of keys only. Without the proper key, code or data will not transfer. Storage Accounts have individual keys, so in this manner different security layers may be applied not only programmatically but at the account layer.

Figure 6 - Windows Azure communications between components

Calls to Windows Azure are made using standard SOAP, XML or REST-based protocols. The communications channel can be encrypted between the client and Windows Azure or allow it to remain unencrypted based on security needs.

SQL Azure uses the standard SQL Server Tabular Data Stream (TDS) protocol, but only allows encrypted communications.

Data is unencrypted within Windows Azure Blob or Table Storage - but is only accessible via the key for a storage account. Data can be encrypted client-side and stored in Windows Azure in an encrypted fashion. Microsoft does not inspect internal data for validity or encryption enforcement. The key is that the data is client-side encrypted and decrypted.

Figure 7 - Example data at rest encryption scenario

Alternatively, a hybrid solution can store sensitive data locally and non-sensitive data in Azure Storage. The data can be coalesced at the client level such that the data is never transferred over any channel not owned or controlled by the organization.

Federating Security:

In the case of a single security boundary for Windows Azure, multiple security options are available. Users can be anonymously authorized, such as in the case of a public website for advertisement or informational purposes.

Another option is to create an Internet Information Services (IIS) Internal Security Store. This is not a best-practice (although still possible) approach since the Fabric services within Windows Azure may recycle an instance and the session may sever between a given role and a client. Architecting stateless applications is a preferred approach.

Using Claims-Based Authentication is a better solution. In this approach, the Principal is authenticated through a trusted party, such as Active Directory, OpenID, OpenAuthentication, or LiveID. Many web-properties use these methods, such as Microsoft, Google, Yahoo and Facebook to name a few. After authenticating with one of these services, the client is issued Claims using the WS-Federation (WS-Fed) or Security Assertion Markup Language (SAML) that are passed to Windows Azure. At no time does Windows Azure store, transfer or interrogate the Principal’s security token. Claims can be anything from a group or role membership to location or any other settable attribute. Assets are then secured allowing only the Claim, without regard to the user’s location or access method. In this fashion a single security paradigm covers the Securables, with the Principals being controlled in any number of other mechanisms. This allows single-sign-on and/or federated security access from multiple providers.

The simplest mechanism for building this environment is the Access Control Services (ACS) feature found in the Windows Azure Application Fabric component. It is a federated authorization management service that simplifies user access authorization across organizations and ID providers and performs claims transformation to map identities with access levels.

ACS can:

Create and manage scopes such as URLs
Create and manage claim types
Create and manage signing and encryption keys
Create and manage rules within an application scope
Chain claims rules
Manage permissions on scopes or perform delegation

Figure 8 - Federated Security Example

Full information on the Access Control Service is available at this link: http://social.technet.microsoft.com/wiki/contents/articles/windows-identity-foundation-wif-and-azure-appfabric-access-control-service-acs-survival-guide.aspx?wa=wsignin1.0

Since the Web and Worker Roles within Windows Azure are designed to be stateless, Microsoft created a Certification Store within the Management area to hold Certificates that can be called from within code. An example of using the Certification Store is here: http://blogs.msdn.com/b/jnak/archive/2010/01/29/installing-certificates-in-windows-azure-vms.aspx

Additional Resources:

Official, authoritative security resource list: http://msdn.microsoft.com/en-us/library/ff934690.aspx
Technical Overview of the Security Features in the Windows Azure Platform: http://www.microsoft.com/online/legal/?langid=en-us&docid=11.
Windows Azure Security Overview: http://www.globalfoundationservices.com/security/documents/WindowsAzureSecurityOverview1_0Aug2010.pdf
Windows Azure Privacy: http://www.microsoft.com/online/legal/?langid=en-us&docid=11
Securing Microsoft Cloud Infrastructure: http://www.globalfoundationservices.com/security/documents/SecuringtheMSCloudMay09.pdf.
A list of other security resources is here: http://blogs.msdn.com/b/buckwoody/archive/2010/12/07/windows-azure-learning-plan-security.aspx

Image Attribution: David Pallmann: http://davidpallmann.blogspot.com/2011/07/windows-azure-design-patterns-part-1.html