Windows Azure Security Essentials – Part 1/N – Security Overview

   Security is one of the very important parts of Cloud Computing, since we are in a completely new environment that the ones we are used to. When using Cloud Computing “The Platform is managed for us” rather, the “Us managing our platform”.

    Another thing that is completely different between the On-Premise and the Platform as a Service Model, is because instead of having full control of the platform (Physical/Network/Host/Application and Data), we are really only controlling the Data and the Application, since the rest is the responsibility of our vendor, in the Windows Azure Service Platform case this is Microsoft. But having this managed by Microsoft, we need assurance that our data is secure, and protected even from Microsoft Admins.

   So some of the Cloud Security Concerns are:

  • Where is my data located? Is the Data Stored in some place that is possible based on my country laws and regulations?
  • Is the Microsoft Cloud “secure”?
  • Who can see my data?
  • How do you make sure my company data follows “the rules”? (Country rules and laws)

  And for all of this Cloud Security needs a Mind Shift, since:

  • Much of the traditional infrastructure security moves to the platform and application layers, and we are unable to change them. So we need to do something different like:
    • So Network Access Control Lists and Firewalls become host packet filters and virtual filters
    • Reduction of the attack surface, least privilege, user authentication and input sanitization become key concerns when designing and developing an application.
    • Also the Platform and Network Level encryption will still play a very important role, but the most important point is that the developer becomes more responsible for the application security and encryption design.

   In order to manage the Security on Windows Azure we can use:

  • Service Management Security
    • Customers create a Windows Azure subscription using LiveID credentials
      • Live ID is one of the longest running Internet Authentication Services available
    • Hosted services and storage accounts managed through LiveID or a Service Management API or SMAPI with user-generated public/private key pairs.
      • SMAPI protocol runs over SSL and it’s authenticated based on the user-generated public/private keys.
    • All communications between the several Windows Azure internal components are encrypted using SSL, and also the communication between the Fabric Controller and the managed nodes is unidirectional.

  By default the Web Roles run in partial trust mode, and the recommendation is that all public facing roles should use Partial Trust as well as avoiding to have secret information. Instead we should really pass that information to a higher level trust role, for example to a Worker Role running on Full-Trusted mode and only with Internal Endpoints.

   Within each Windows Azure Subscription a developer can create multiple storage account, and each account has 2 Keys in order to provide the key rollover capability, the same way as we change our passwords frequently in order to maintain security.

 SQL Azure Security

  • Same security Model as in SQL Server Authentication Model
    • SQL Server Logins
      • Authenticate access to SQL Azure
    • Database Users
      • Grant access to the database level
    • Database Roles
      • Group users and grant to the database level
  • Only SQL Server authentication is supported
    • User must provide credentials every time they connect
    • Password resets will not force a connection to be re-authenticated
    • Every 60 minutes has passed since last authentication, a re-authentication is performed (done automatically, and if there is a password update, this will be used instead)
  • During the provisioning process, SQL Server created a login for you that is the server-level principal similar to SA (System Administrator) login in SQL Azure.
    • Used to create additional user accounts
  • Only available thought port TCP 1433, which needs that customers configure their internal firewalls to allow Outgoing request to this port.
  • Source IP address needs to be authorized in SQL Azure Firewall

Leave a Reply

Your email address will not be published. Required fields are marked *