Windows Azure Security Overview, Part 2
Continuation of the first part:
The second part of the review will provide information on SQL Databases, physical security, security tools that the client can use, platform certification and security recommendations.
SQL Databases Security
SQL Azure Databases uses the standard SQL Server Tabular Data Stream (TDS) protocol, but exclusively encrypted communications are allowed. SQL Server 2008 introduced a new feature: transparent data encryption (TDE), which allows you to fully encrypt data with minimal effort. However, at this time, SQL Azure Databases does not support database-level encryption. It should be noted that at present, SQL Azure Databases is available only through TCP connections and only through port 1433. Therefore, it is necessary to consider the ADO.NET encryption capabilities and certificates. And, for example, the properties of the Encrypt = True and TrustServerCertificate = False connection will protect the transmitted data and help prevent man-in-the-middle attacks. The second SQL Database Azure protector, and, in general, the main one is the Azure Databases SQL Firewall, which initially blocks all access to the Azure Databases SQL Server. Attempts to connect to the appropriate settings will fail. To start working with the SQL Azure Databases server, you need to go to the SQL Azure portal and determine the firewall settings for access to your server. The Azure SQL Firewall can be managed through the Azure SQL Portal or directly in the main database using stored procedures such as sp_set_firewall_rule and sp_delete_firewall_rule.
As with any SQL Server implementation, user account management is another aspect that needs to be tightly controlled. With these tools, SQL Azure is a highly secure managed platform for cloud applications.
There is a list of differences between SQL Server and SQL Azure Databases in the security context:
You can also use Windows Azure Trust Services to encrypt data. Physical Security Windows Azure services are provided to users through a global network of data centers designed to work around the clock, each of which uses various means to protect the system from power failures, physical intrusion, and network connection breaks. These geographically distributed data centers meet industry standards for physical security and reliability. Microsoft does not delegate the task of servicing its own data centers to other companies, and Microsoft employees fully manage, monitor and administer the data centers of the corporation.
Microsoft uses highly secure access mechanisms that are available only to a limited number of employees who regularly change administrator access passwords. Access to data centers and the authority to open access tickets to data centers are controlled by the network operations director in accordance with local recommendations for data center security.
Security Development Lifecycle
Windows Azure is fully compliant with Microsoft's Security Development Lifecycle (SDL), which has been recognized as a fairly high-level software security model.
Customer Safety
Of course, despite all the enormous efforts of Microsoft Corporation to ensure all aspects of customer data security and its own data centers, the client must be directly involved in this process. At the moment, there are many methods, tools and tools for ensuring client-side security, including Microsoft certified software tools. This section provides a short list of Microsoft Certified Tools that you can and should use for security.
Windows Azure Virtual Network
The Windows Azure virtual network allows you to configure and manage virtual private networks (VPNs) in Windows Azure, as well as safely integrate them with your local infrastructure. Using a virtual network, you can expand your on-premises infrastructure to the cloud while managing the network topology, including the configuration of IP addresses, routing tables, and security policies. Typical scenarios for using the Windows Azure Virtual Network include a secure expansion of the data center to the cloud (traditional VPNs to safely scale the data center. The virtual network uses IPSEC to establish a secure connection between the corporate VPN gateway and Windows Azure.
Windows Azure Connect
Windows Azure Connect provides integration of Windows Azure and local resources based on Azure Connect agents, including database servers and domain controllers. Windows Azure provides full control for creating virtual networks and setting IP addresses in the cloud.
Common scenarios for using Windows Azure Connect include: creating distributed applications (securely connecting to the local infrastructure without extra code, for example, a cloud application can access the local SQL Server or Active Directory database server), debugging applications (remotely, using a direct connection between the local computer of the developer and applications hosted on the Windows Azure platform, which allows troubleshooting and debugging using the tools used for local applications).
Service bus
Service Bus provides the ability to securely transfer data and provide relay, which allows you to build distributed and loosely coupled applications in the cloud. Using the Service Bus, you can easily secure communication channels from local clients to the cloud, or inside the cloud.
Certification
In the security review of any platform that is actively used, you cannot ignore the issue of certification of the platform by various organizations. Windows Azure has a set of certificates from industry leading certification companies.
General information on certification is given in table. 1.
Table 1. Windows Azure Functionality Certification
ISO 27001
The Windows Azure platform has been certified as compliant with the ISO 27001 British Standards Institute (BSI). At the time of writing, ISO has certified the following platform components:
• Compute (including Web and Worker roles)
• Storage (including blob, queue and table storage services)
• Virtual Machine (including the VM role)
• Virtual Network (including Traffic Manager and Connect)
At the same time, Microsoft Global Foundation Services has a separate certification according to ISO 27001 for those data centers that host the Windows Azure platform.
Fisma
The Windows Azure platform has been certified to meet the operational requirements for federal governments under the Federal Information Security Management Act (FISMA).
Security recommendations
Use the latest security updates. It’s
good practice to use the osFamily and osVersion properties in ServiceConfiguration.cscfg - by specifying the latest available OS version, you guarantee the latest automatically installed updates, including security.
Limit the maximum amount of logs stored and monitor their contents
One type of attack is DoS, when the log storage can grow to large sizes, which can lead to the failure of any services. Limit the maximum amount of logs stored. In addition, carefully monitor their content and in no case do not log critical and important data. Regularly analyze the received logs, since not all attacks can be quick - many of them can stretch for a long time, and in this case the main task is to detect them in a timely manner. Make regular backups so that an attacker, even with a successful hack, cannot erase traces of his activities.
Avoid client-side
validation of important data Do not implement client-side validation of important data by transferring serious business logic to the server.
Use complex passwords.
Best security practice - use complex passwords and change them after a certain period of time. A simple password can be cracked using various attacks such as brute force or dictionary attacks.
Carefully use the connection pool model
Despite the performance optimization advantage provided by using the connection pool, this can be a potential danger - there may be a situation when a user with less privileges will use the administrator-user connection.
Do not store credentials and just data in an insecure place
Remember to encrypt your credentials, and use authentication and authorization mechanisms that transmit credentials in plain text. If you use claims-based authentication, use an encrypted channel to transfer security tokens. An encrypted channel can also help against various attacks, for example, session replay, when an attacker intercepts messages and repeats them in order to mislead the system. Do not transfer data in HTTP GET requests, as this can lead to a situation where important data can be copied by simply copying the request line, in addition, HTTP GET request lines are stored in the browser history, on proxy servers and in the web server logs.
Design an authorization system based on a role model
Design a system in which there will be several types of roles - for example, a role or account with the least privileges and an administrator, as well as principles for restricting access to different areas of your service. Do not give too many people administrator rights. Do not make superuser the administrator.
Plan your authentication type in advance
Depending on your tasks, you can use different types of authentication with different data sources. For example, if you have a ready-made ASP.NET application that uses Membership and your tasks do not necessarily include the use of complex authorization, that is, using nothing more than simple logins, passwords and role models, using authentication can be a good solution Based on forms with a data source in Windows Azure Storage Services. If you need more complex business logic, you can use Azure Databases as a SQL data source, or if your scenario involves complex integration tasks using a local Active Directory from a cloud application, your choice may be to use claims-based authentication and AD FS 2.0 .
Group parts of the application
Placing the maximum number of components of your service within a single data center or region will help to increase both its productivity and speed, as well as the degree of security by minimizing traffic transmitted outside the data center.
Handle Exceptions Correctly
Potential vulnerabilities, sometimes very serious ones, can be caused by excessive text of the thrown exception. Do not include in the text of the exception information that may tell you about your system that you would not want a stranger to know.
Check what the user gives you
Never trust what the client will enter without several layers of verification of this. Check everything, otherwise it is possible to hack the system using various attacks, for example, SQL Injection. Centralize verification mechanisms by developing a dedicated library. Never immediately create containers or other entities in the Windows Azure storage using the information provided by the user - first check it or convert it.
Partial trust
By default, roles deployed to the Windows Azure platform operate using full trust, which allows you to call non-.NET code or use the appropriate libraries that require administrator rights, which can cause a certain probability of a security breach. Using partial trust allows you to at least slightly limit the possibility that the cracker will have full access to the system - for example, with partial trust, the cracker will not be able to modify the files. Partial trust can be explicitly defined in the service definition file (ServiceDefinition.cscfg) using the enableNativeCodeExecution attribute, setting its value to false.
Manage your keys wisely
The principle is simple - you cannot use the keys provided by Windows Azure as keys for encrypting data. In addition, with regard to key management, an excellent solution would be to change keys in a certain time period. For example, since two 256-bit keys are allocated for each storage account, one can be used at one time, the other at the other, and after some time, a new primary key can be generated and transferred to its use.
Actively use Shared Access Signatures and Permissions
Actively use Shared Access Signatures and various permissions to restrict access to the storage account. After June 7, 2012, Shared Access Signature became available for all storage services (until June 7, they were available only for blobs).
Actively use encryption services.
Do not forget about the existence of various implementations of cryptographic standards (Cryptographic Service Providers), algorithms, etc. Including Microsoft implementations:
Microsoft Base Cryptographic Provider
Microsoft Strong Cryptographic Provider
Microsoft Enhanced Cryptographic Provider
Microsoft AES Cryptographic Provider
Microsoft DSS Cryptographic Provider
Microsoft Base DSS and Diffie-Hellman Cryptographic Provider
Microsoft Enhanced DSS and Diffie-Hellman Cryptographic Provider
Microsoft DSS and Diffie-Hellman / Schannel Cryptographic Provider
Microsoft RSA / Schannel Cryptographic Provider
Microsoft RSA Signature Cryptographic Provider
Avoid developing your own encryption mechanisms - they are likely to be less perfect than the standard mechanisms.
Do not encrypt or hash Partition Keys for entities in Windows Azure Storage.
When using unidirectional hash functions, use SHA with a minimum key length of 256 bits, when using symmetric encryption, use AES with a minimum key length of 256 bits, when using asymmetric encryption, use RSA with a minimum key length of 2048 bits.
Conclusion
Summarizing, you can combine the main points related to security in one short list:
• Authentication with SSL for all internal traffic - all communications within the platform are protected by SSL.
• Certificates and private keys are installed separately from the code that uses them.
• The principle of least privileges for software - users do not have administrator privileges on virtual machines, while software deployed on the platform runs under an unprivileged account.
• Data keys - all storage accounts have two secret keys used to control access to data.
•Isolation of the hypervisor, root OS, guest OS and Fabric Controller - the root OS is isolated from the guest, the guest OS is isolated from each other, everything is controlled by the hypervisor and the root OS. Access to Fabric Controller is severely restricted.
• Packet filters . The hypervisor and root OS use packet filters to limit the ability to spoof traffic from untrusted virtual machines. Broadcast traffic is also limited.
• VLAN - all critical components are located in their own isolated VLANs.
• When a client performs a data deletion operation, the system ensures that it cannot be restored .
As with any new platform, even taking into account all the changes made, the security and encryption tools in Windows Azure are still under development and require constant improvement, however this is an absolutely normal situation - new threats regularly appear that need to be taken into account when planning the development of the platform.
Useful Windows Azure Trust Center links
- www.windowsazure.com/en-us/support/trust-center
The second part of the review will provide information on SQL Databases, physical security, security tools that the client can use, platform certification and security recommendations.
SQL Databases Security
SQL Azure Databases uses the standard SQL Server Tabular Data Stream (TDS) protocol, but exclusively encrypted communications are allowed. SQL Server 2008 introduced a new feature: transparent data encryption (TDE), which allows you to fully encrypt data with minimal effort. However, at this time, SQL Azure Databases does not support database-level encryption. It should be noted that at present, SQL Azure Databases is available only through TCP connections and only through port 1433. Therefore, it is necessary to consider the ADO.NET encryption capabilities and certificates. And, for example, the properties of the Encrypt = True and TrustServerCertificate = False connection will protect the transmitted data and help prevent man-in-the-middle attacks. The second SQL Database Azure protector, and, in general, the main one is the Azure Databases SQL Firewall, which initially blocks all access to the Azure Databases SQL Server. Attempts to connect to the appropriate settings will fail. To start working with the SQL Azure Databases server, you need to go to the SQL Azure portal and determine the firewall settings for access to your server. The Azure SQL Firewall can be managed through the Azure SQL Portal or directly in the main database using stored procedures such as sp_set_firewall_rule and sp_delete_firewall_rule.
As with any SQL Server implementation, user account management is another aspect that needs to be tightly controlled. With these tools, SQL Azure is a highly secure managed platform for cloud applications.
There is a list of differences between SQL Server and SQL Azure Databases in the security context:
- Microsoft SQL Server supports Windows Integrated authentication using access settings from Active Directory; SQL Azure Databases only supports SQL Server Authentication.
- Microsoft SQL Server and SQL Azure Databases use the same authorization model based on users and roles created in each database and associated with user logins.
- Microsoft SQL Server has standard server-level roles such as serveradmin, securityadmin, and dbcreator. SQL Azure Databases does not have these roles. Instead, SQL Azure Databases has the roles of loginmanager (creating logins) and dbmanager (creating and managing databases). These roles can be associated with users in the master database.
- Access to SQL Server and SQL Azure Databases takes place via the Tabular Data Stream (TDS) application layer protocol, which is protected by SSL protocol, through TCP / 1433 port. Using SSL is optional for Microsoft SQL Server and required for SQL Azure Databases.
- In SQL Server, IP-based access control must be done at the host or network level using firewalls. SQL Azure Databases has a built-in firewall that restricts all access to the SQL Azure Databases server to determine which clients are authorized computers. The firewall issues access based on the IP address of each request.
- SQL Server provides real-time encryption of all stored data at the page level using the Transparent Data Encryption (TDE) functionality. Such encryption is not supported in SQL Azure Databases.
You can also use Windows Azure Trust Services to encrypt data. Physical Security Windows Azure services are provided to users through a global network of data centers designed to work around the clock, each of which uses various means to protect the system from power failures, physical intrusion, and network connection breaks. These geographically distributed data centers meet industry standards for physical security and reliability. Microsoft does not delegate the task of servicing its own data centers to other companies, and Microsoft employees fully manage, monitor and administer the data centers of the corporation.
Microsoft uses highly secure access mechanisms that are available only to a limited number of employees who regularly change administrator access passwords. Access to data centers and the authority to open access tickets to data centers are controlled by the network operations director in accordance with local recommendations for data center security.
Security Development Lifecycle
Windows Azure is fully compliant with Microsoft's Security Development Lifecycle (SDL), which has been recognized as a fairly high-level software security model.
Customer Safety
Of course, despite all the enormous efforts of Microsoft Corporation to ensure all aspects of customer data security and its own data centers, the client must be directly involved in this process. At the moment, there are many methods, tools and tools for ensuring client-side security, including Microsoft certified software tools. This section provides a short list of Microsoft Certified Tools that you can and should use for security.
Windows Azure Virtual Network
The Windows Azure virtual network allows you to configure and manage virtual private networks (VPNs) in Windows Azure, as well as safely integrate them with your local infrastructure. Using a virtual network, you can expand your on-premises infrastructure to the cloud while managing the network topology, including the configuration of IP addresses, routing tables, and security policies. Typical scenarios for using the Windows Azure Virtual Network include a secure expansion of the data center to the cloud (traditional VPNs to safely scale the data center. The virtual network uses IPSEC to establish a secure connection between the corporate VPN gateway and Windows Azure.
Windows Azure Connect
Windows Azure Connect provides integration of Windows Azure and local resources based on Azure Connect agents, including database servers and domain controllers. Windows Azure provides full control for creating virtual networks and setting IP addresses in the cloud.
Common scenarios for using Windows Azure Connect include: creating distributed applications (securely connecting to the local infrastructure without extra code, for example, a cloud application can access the local SQL Server or Active Directory database server), debugging applications (remotely, using a direct connection between the local computer of the developer and applications hosted on the Windows Azure platform, which allows troubleshooting and debugging using the tools used for local applications).
Service bus
Service Bus provides the ability to securely transfer data and provide relay, which allows you to build distributed and loosely coupled applications in the cloud. Using the Service Bus, you can easily secure communication channels from local clients to the cloud, or inside the cloud.
Certification
In the security review of any platform that is actively used, you cannot ignore the issue of certification of the platform by various organizations. Windows Azure has a set of certificates from industry leading certification companies.
 |
General information on certification is given in table. 1.
Table 1. Windows Azure Functionality Certification
| Windows Azure Functionality | ISO 27001 | SSAE 16 ISAE 3402 | EU Model Clauses | HIPAA BAA |
| Web sites | ||||
| Virtual machines | X | X | X | X |
| Cloud services | X | X | X | X |
| Storage (Tables, Blobs, Queues) | X | X | X | X |
| SQL Database | ||||
| Caching | ||||
| Content Delivery Network (CDN) | ||||
| Networking | X | X | X | X |
| Windows Azure Active Directory | ||||
| Service bus | ||||
| Media services |
ISO 27001
The Windows Azure platform has been certified as compliant with the ISO 27001 British Standards Institute (BSI). At the time of writing, ISO has certified the following platform components:
• Compute (including Web and Worker roles)
• Storage (including blob, queue and table storage services)
• Virtual Machine (including the VM role)
• Virtual Network (including Traffic Manager and Connect)
At the same time, Microsoft Global Foundation Services has a separate certification according to ISO 27001 for those data centers that host the Windows Azure platform.
Fisma
The Windows Azure platform has been certified to meet the operational requirements for federal governments under the Federal Information Security Management Act (FISMA).
Security recommendations
Use the latest security updates. It’s
good practice to use the osFamily and osVersion properties in ServiceConfiguration.cscfg - by specifying the latest available OS version, you guarantee the latest automatically installed updates, including security.
Limit the maximum amount of logs stored and monitor their contents
One type of attack is DoS, when the log storage can grow to large sizes, which can lead to the failure of any services. Limit the maximum amount of logs stored. In addition, carefully monitor their content and in no case do not log critical and important data. Regularly analyze the received logs, since not all attacks can be quick - many of them can stretch for a long time, and in this case the main task is to detect them in a timely manner. Make regular backups so that an attacker, even with a successful hack, cannot erase traces of his activities.
Avoid client-side
validation of important data Do not implement client-side validation of important data by transferring serious business logic to the server.
Use complex passwords.
Best security practice - use complex passwords and change them after a certain period of time. A simple password can be cracked using various attacks such as brute force or dictionary attacks.
Carefully use the connection pool model
Despite the performance optimization advantage provided by using the connection pool, this can be a potential danger - there may be a situation when a user with less privileges will use the administrator-user connection.
Do not store credentials and just data in an insecure place
Remember to encrypt your credentials, and use authentication and authorization mechanisms that transmit credentials in plain text. If you use claims-based authentication, use an encrypted channel to transfer security tokens. An encrypted channel can also help against various attacks, for example, session replay, when an attacker intercepts messages and repeats them in order to mislead the system. Do not transfer data in HTTP GET requests, as this can lead to a situation where important data can be copied by simply copying the request line, in addition, HTTP GET request lines are stored in the browser history, on proxy servers and in the web server logs.
Design an authorization system based on a role model
Design a system in which there will be several types of roles - for example, a role or account with the least privileges and an administrator, as well as principles for restricting access to different areas of your service. Do not give too many people administrator rights. Do not make superuser the administrator.
Plan your authentication type in advance
Depending on your tasks, you can use different types of authentication with different data sources. For example, if you have a ready-made ASP.NET application that uses Membership and your tasks do not necessarily include the use of complex authorization, that is, using nothing more than simple logins, passwords and role models, using authentication can be a good solution Based on forms with a data source in Windows Azure Storage Services. If you need more complex business logic, you can use Azure Databases as a SQL data source, or if your scenario involves complex integration tasks using a local Active Directory from a cloud application, your choice may be to use claims-based authentication and AD FS 2.0 .
Group parts of the application
Placing the maximum number of components of your service within a single data center or region will help to increase both its productivity and speed, as well as the degree of security by minimizing traffic transmitted outside the data center.
Handle Exceptions Correctly
Potential vulnerabilities, sometimes very serious ones, can be caused by excessive text of the thrown exception. Do not include in the text of the exception information that may tell you about your system that you would not want a stranger to know.
Check what the user gives you
Never trust what the client will enter without several layers of verification of this. Check everything, otherwise it is possible to hack the system using various attacks, for example, SQL Injection. Centralize verification mechanisms by developing a dedicated library. Never immediately create containers or other entities in the Windows Azure storage using the information provided by the user - first check it or convert it.
Partial trust
By default, roles deployed to the Windows Azure platform operate using full trust, which allows you to call non-.NET code or use the appropriate libraries that require administrator rights, which can cause a certain probability of a security breach. Using partial trust allows you to at least slightly limit the possibility that the cracker will have full access to the system - for example, with partial trust, the cracker will not be able to modify the files. Partial trust can be explicitly defined in the service definition file (ServiceDefinition.cscfg) using the enableNativeCodeExecution attribute, setting its value to false.
Manage your keys wisely
The principle is simple - you cannot use the keys provided by Windows Azure as keys for encrypting data. In addition, with regard to key management, an excellent solution would be to change keys in a certain time period. For example, since two 256-bit keys are allocated for each storage account, one can be used at one time, the other at the other, and after some time, a new primary key can be generated and transferred to its use.
Actively use Shared Access Signatures and Permissions
Actively use Shared Access Signatures and various permissions to restrict access to the storage account. After June 7, 2012, Shared Access Signature became available for all storage services (until June 7, they were available only for blobs).
Actively use encryption services.
Do not forget about the existence of various implementations of cryptographic standards (Cryptographic Service Providers), algorithms, etc. Including Microsoft implementations:
Microsoft Base Cryptographic Provider
Microsoft Strong Cryptographic Provider
Microsoft Enhanced Cryptographic Provider
Microsoft AES Cryptographic Provider
Microsoft DSS Cryptographic Provider
Microsoft Base DSS and Diffie-Hellman Cryptographic Provider
Microsoft Enhanced DSS and Diffie-Hellman Cryptographic Provider
Microsoft DSS and Diffie-Hellman / Schannel Cryptographic Provider
Microsoft RSA / Schannel Cryptographic Provider
Microsoft RSA Signature Cryptographic Provider
Avoid developing your own encryption mechanisms - they are likely to be less perfect than the standard mechanisms.
Do not encrypt or hash Partition Keys for entities in Windows Azure Storage.
When using unidirectional hash functions, use SHA with a minimum key length of 256 bits, when using symmetric encryption, use AES with a minimum key length of 256 bits, when using asymmetric encryption, use RSA with a minimum key length of 2048 bits.
Conclusion
Summarizing, you can combine the main points related to security in one short list:
• Authentication with SSL for all internal traffic - all communications within the platform are protected by SSL.
• Certificates and private keys are installed separately from the code that uses them.
• The principle of least privileges for software - users do not have administrator privileges on virtual machines, while software deployed on the platform runs under an unprivileged account.
• Data keys - all storage accounts have two secret keys used to control access to data.
•Isolation of the hypervisor, root OS, guest OS and Fabric Controller - the root OS is isolated from the guest, the guest OS is isolated from each other, everything is controlled by the hypervisor and the root OS. Access to Fabric Controller is severely restricted.
• Packet filters . The hypervisor and root OS use packet filters to limit the ability to spoof traffic from untrusted virtual machines. Broadcast traffic is also limited.
• VLAN - all critical components are located in their own isolated VLANs.
• When a client performs a data deletion operation, the system ensures that it cannot be restored .
As with any new platform, even taking into account all the changes made, the security and encryption tools in Windows Azure are still under development and require constant improvement, however this is an absolutely normal situation - new threats regularly appear that need to be taken into account when planning the development of the platform.
Useful Windows Azure Trust Center links
- www.windowsazure.com/en-us/support/trust-center