Security Overview of Windows Azure, Part 2
Continuation of the first part:
The second part of the review will provide information about SQL Databases, physical security, client-side security tools, platform certification, and security recommendations.
SQL Databases Security
')
SQL Azure Databases uses the standard SQL Server Tabular Data Stream (TDS) protocol, but only encrypted communications are allowed. In SQL Server 2008, a new tool was introduced: transparent data encryption (TDE), which allows you to fully encrypt data with minimal effort. However, at the moment, SQL Azure Databases does not support encryption at the database level. It should be noted that at present SQL Azure Databases is available only through TCP connections and only through port 1433. Therefore, you need to consider the ADO.NET encryption capabilities and certificates. And, for example, the properties of the connection Encrypt = True and TrustServerCertificate = False will protect the transmitted data and help prevent man-in-the-middle attacks. The second means of protecting SQL Database Azure, and, in general, the main one is SQL Azure Databases firewall, which initially blocks all access to SQL Azure Databases. Attempts to connect to the appropriate settings will be unsuccessful. To start working with the SQL Azure Databases server, you need to go to the SQL Azure portal and define the firewall settings for accessing your server. 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, managing user accounts is another aspect that needs to be tightly controlled. With these tools, SQL Azure is a highly secure, managed platform for applications in the cloud.
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 datacenters designed to work around the clock, each of which uses various means to protect the system from power failures, physical intrusion and network connection interruptions. These geographic distributed data centers comply with industry standards for physical security and reliability. Microsoft does not delegate the tasks of servicing its own data centers to other companies, and Microsoft employees fully manage, monitor and administer the corporation's data centers.
Microsoft uses high-security access mechanisms that are available only to a limited number of employees who regularly change administrator access passwords. Data center access and authority to open data center access tickets are controlled by the network director in accordance with local data center security recommendations.
Security Development Lifecycle
Windows Azure fully complies with the security requirements of the development cycle (Security Development Lifecycle, SDL) of Microsoft Corporation, which has been recognized as a software security model of a fairly high level.
Customer Security
Of course, despite all the enormous efforts of Microsoft to ensure all aspects of the security of customer data and its own data centers, the customer must be directly involved in this process. At the moment there are many methods, tools and tools for security on the client side, including certified software from Microsoft. This section provides a brief list of Microsoft-certified tools you can and should use for security.
Windows Azure Virtual Network
A Windows Azure virtual network allows you to configure and manage virtual private networks (VPNs) in Windows Azure, as well as securely integrate them with your local infrastructure. Using a virtual network, you can extend the local infrastructure to the cloud, while managing the network topology, including the configuration of IP addresses, routing tables, and security policies. Typical scenarios for using Windows Azure Virtual Network include securely expanding a data center to the cloud (traditional VPN networks to securely scale a data center. A virtual network uses IPSEC to establish a secure connection between the corporate VPN gateway and Windows Azure. Outside the VPN gateway you can add any number of computers) and the development of hybrid scenarios (integration of a cloud application with a local infrastructure of any type, including a Unix system).
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 complete control for creating virtual networks and setting up IP addresses in the cloud.
Common scenarios for using Windows Azure Connect include: creating distributed applications (securely connecting to the local infrastructure without unnecessary code, for example, a cloud-based application can access a local SQL Server database server or Active Directory), debugging applications (remotely, using a direct connection between the local developer’s computer and applications hosted on the Windows Azure platform, which allows troubleshooting and debugging using the tools used for local applications).
Service bus
The Service Bus service provides secure data transfer and relay support, 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, one cannot avoid the issue of platform certification by various organizations. Windows Azure has a set of certificates from leading industry leaders in the field of certification.
General information on certification is given in Table. one.
Table 1. Certification of Windows Azure functionality
ISO 27001
The Windows Azure platform was certified to meet the ISO 27001 British Standards Institute (BSI). At the time of writing this article on ISO, the following platform components are certified:
• Compute (including Web and Worker roles)
• Storage (including blob, queue, and table storage services)
• Virtual Machine (including VM role)
• Virtual Network (including Traffic Manager and Connect)
At the same time, Microsoft Global Foundation Services has a separate ISO 27001 certification for those data centers that host the Windows Azure platform.
Fisma
The Windows Azure platform was certified as satisfying the conditions for operation for federal authorities by the Federal Information Security Management Act (FISMA).
Security Advisories
Use the latest security updates.
A good practice is to use the osFamily and osVersion properties in ServiceConfiguration.cscfg - by specifying the latest available version of the OS, you guarantee the availability of the latest automatically installed updates, including security.
Limit the maximum amount of stored logs and keep track of their contents.
One type of attack is DoS, when the log repository can grow to large sizes, which can lead to the failure of any services. Limit the maximum amount of stored logs. In addition, carefully monitor their content and in no case log the critical and important data. Regularly analyze the resulting logs, since not all attacks can be fast - many of them can stretch for a long time, and in this case the main task is their timely detection. Regularly back up so that the attacker, even with a successful burglary, could not wipe away the traces of his activity.
Avoid checking important data on the client side
Do not implement mechanisms for checking important data on the client side, transferring serious business logic to the server.
Use complex passwords
Best practice for security - use complex passwords and change them after a certain period of time. A simple password can be cracked using various brute-force attacks or a dictionary-based attack.
Use the connection pool model carefully.
Despite the advantage of optimizing performance provided by using a connection pool, this can be a potential hazard — there may be a situation where a user with less privileges will take advantage of the connection of the administrator user.
Do not store credentials and just data in an insecure place.
Remember to encrypt your credentials, and use authentication and authorization mechanisms that convey 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 transmit data in HTTP GET requests, as this may lead to a situation where important data can be copied by simple copying the request line, except for this line, HTTP GET requests are stored in browser history, on proxy servers and in web server logs.
Develop an authorization system based on the role model
Develop 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 admin rights. Do not make superuser from administrator.
Plan authentication type in advance
Depending on the tasks available, 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, do not use anything more than simple logins, passwords and role models, the use of authentication may be a good solution. based on forms with data source in Windows Azure storage services. If you need more complex business logic, you can use SQL Azure Databases as a data source, or if your script involves complex integration tasks for using the local Active Directory from a cloud application, using assertion authentication and AD FS 2.0 can be your choice. . If you need to use federated authentication, a great option is the Windows Azure Active Directory (Access Control Service), behind which you can combine a set of both public (Facebook, Live Id, ...) and private (Active Directory) identity providers.
Group parts of the application
Placing the maximum number of components of your service within one data center or region will help to improve both its performance and speed, and the degree of security by minimizing the traffic transmitted outside the data center.
Handle exceptions correctly
Potential vulnerabilities, sometimes very serious, can be caused by too excessive text of the thrown exception. Do not include in the exception text information that can tell 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 checking this. Check everything, otherwise it is possible to hack the system using various attacks, for example, SQL Injection. Centralize verification mechanisms by developing a special library. Never immediately create containers or other entities in your Windows Azure storage using information provided by the user — first check it or convert it.
Partial trust
By default, roles deployed to the Windows Azure platform work using full trust, which allows you to call non-.NET code or use the appropriate libraries that require administrative rights, which can cause a certain likelihood of a security breach. The use of partial trust allows at least a slight limit on the possibility that a cracker will have full access to the system — for example, with partial trust, a cracker will not be able to modify files. You can explicitly define partial trust in the service definition file (ServiceDefinition.cscfg) using the enableNativeCodeExecution attribute, defining its value as false.
Manage your keys correctly
The principle is simple - you cannot use keys provided by Windows Azure as keys for data encryption. In addition, what is related to key management, a great solution would be to change keys in a certain time period. For example, since two 256-bit keys are allocated to each storage account, you can use one at a time, and the second at another, after some time, you can generate a new primary key and switch to using it.
Actively use Shared Access Signatures and permissions
Actively use Shared Access Signatures and various permissions to limit 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 implementations of Microsoft:
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 — most likely they will be less perfect than the standard mechanisms adopted.
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, while using asymmetric encryption, use RSA with a minimum key length of 2048 bits.
Conclusion
Summarizing, you can combine the main points relating 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 the 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, the root OS, the guest OS, and the 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 the Fabric Controller is strictly limited.
• Packet filters . The hypervisor and root OS use packet filters to limit the possibility of spoofing traffic from untrusted virtual machines. Also limited to broadcast traffic.
• VLAN - all critical components are located in their own isolated VLAN-ah.
• When a client performs a data erase operation, the system ensures that it cannot be restored .
As with any new platform, even with all the changes made, the means of protection and encryption in Windows Azure are still under development and require constant improvement, but 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 links
Windows Azure Trust Center - www.windowsazure.com/en-us/support/trust-center
The second part of the review will provide information about SQL Databases, physical security, client-side security tools, platform certification, and security recommendations.
SQL Databases Security
')
SQL Azure Databases uses the standard SQL Server Tabular Data Stream (TDS) protocol, but only encrypted communications are allowed. In SQL Server 2008, a new tool was introduced: transparent data encryption (TDE), which allows you to fully encrypt data with minimal effort. However, at the moment, SQL Azure Databases does not support encryption at the database level. It should be noted that at present SQL Azure Databases is available only through TCP connections and only through port 1433. Therefore, you need to consider the ADO.NET encryption capabilities and certificates. And, for example, the properties of the connection Encrypt = True and TrustServerCertificate = False will protect the transmitted data and help prevent man-in-the-middle attacks. The second means of protecting SQL Database Azure, and, in general, the main one is SQL Azure Databases firewall, which initially blocks all access to SQL Azure Databases. Attempts to connect to the appropriate settings will be unsuccessful. To start working with the SQL Azure Databases server, you need to go to the SQL Azure portal and define the firewall settings for accessing your server. 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, managing user accounts is another aspect that needs to be tightly controlled. With these tools, SQL Azure is a highly secure, managed platform for applications in the cloud.
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 parameters 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 the 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 role 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 occurs via the Tabular Data Stream (TDS) application-level protocol, which is protected by SSL, through TCP / 1433 port. Using SSL is optional for Microsoft SQL Server and optional for SQL Azure Databases.
- In SQL Server, IP-based access control must be performed at the host or network level using firewalls. SQL Azure Databases has a built-in firewall that restricts all access to SQL Azure Databases prior to identifying clients of computers that have access rights. The firewall gives 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 functionality of Transparent Data Encryption (TDE). 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 datacenters designed to work around the clock, each of which uses various means to protect the system from power failures, physical intrusion and network connection interruptions. These geographic distributed data centers comply with industry standards for physical security and reliability. Microsoft does not delegate the tasks of servicing its own data centers to other companies, and Microsoft employees fully manage, monitor and administer the corporation's data centers.
Microsoft uses high-security access mechanisms that are available only to a limited number of employees who regularly change administrator access passwords. Data center access and authority to open data center access tickets are controlled by the network director in accordance with local data center security recommendations.
Security Development Lifecycle
Windows Azure fully complies with the security requirements of the development cycle (Security Development Lifecycle, SDL) of Microsoft Corporation, which has been recognized as a software security model of a fairly high level.
Customer Security
Of course, despite all the enormous efforts of Microsoft to ensure all aspects of the security of customer data and its own data centers, the customer must be directly involved in this process. At the moment there are many methods, tools and tools for security on the client side, including certified software from Microsoft. This section provides a brief list of Microsoft-certified tools you can and should use for security.
Windows Azure Virtual Network
A Windows Azure virtual network allows you to configure and manage virtual private networks (VPNs) in Windows Azure, as well as securely integrate them with your local infrastructure. Using a virtual network, you can extend the local infrastructure to the cloud, while managing the network topology, including the configuration of IP addresses, routing tables, and security policies. Typical scenarios for using Windows Azure Virtual Network include securely expanding a data center to the cloud (traditional VPN networks to securely scale a data center. A virtual network uses IPSEC to establish a secure connection between the corporate VPN gateway and Windows Azure. Outside the VPN gateway you can add any number of computers) and the development of hybrid scenarios (integration of a cloud application with a local infrastructure of any type, including a Unix system).
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 complete control for creating virtual networks and setting up IP addresses in the cloud.
Common scenarios for using Windows Azure Connect include: creating distributed applications (securely connecting to the local infrastructure without unnecessary code, for example, a cloud-based application can access a local SQL Server database server or Active Directory), debugging applications (remotely, using a direct connection between the local developer’s computer and applications hosted on the Windows Azure platform, which allows troubleshooting and debugging using the tools used for local applications).
Service bus
The Service Bus service provides secure data transfer and relay support, 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, one cannot avoid the issue of platform certification by various organizations. Windows Azure has a set of certificates from leading industry leaders in the field of certification.
 |
General information on certification is given in Table. one.
Table 1. Certification of Windows Azure functionality
| 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 was certified to meet the ISO 27001 British Standards Institute (BSI). At the time of writing this article on ISO, the following platform components are certified:
• Compute (including Web and Worker roles)
• Storage (including blob, queue, and table storage services)
• Virtual Machine (including VM role)
• Virtual Network (including Traffic Manager and Connect)
At the same time, Microsoft Global Foundation Services has a separate ISO 27001 certification for those data centers that host the Windows Azure platform.
Fisma
The Windows Azure platform was certified as satisfying the conditions for operation for federal authorities by the Federal Information Security Management Act (FISMA).
Security Advisories
Use the latest security updates.
A good practice is to use the osFamily and osVersion properties in ServiceConfiguration.cscfg - by specifying the latest available version of the OS, you guarantee the availability of the latest automatically installed updates, including security.
Limit the maximum amount of stored logs and keep track of their contents.
One type of attack is DoS, when the log repository can grow to large sizes, which can lead to the failure of any services. Limit the maximum amount of stored logs. In addition, carefully monitor their content and in no case log the critical and important data. Regularly analyze the resulting logs, since not all attacks can be fast - many of them can stretch for a long time, and in this case the main task is their timely detection. Regularly back up so that the attacker, even with a successful burglary, could not wipe away the traces of his activity.
Avoid checking important data on the client side
Do not implement mechanisms for checking important data on the client side, transferring serious business logic to the server.
Use complex passwords
Best practice for security - use complex passwords and change them after a certain period of time. A simple password can be cracked using various brute-force attacks or a dictionary-based attack.
Use the connection pool model carefully.
Despite the advantage of optimizing performance provided by using a connection pool, this can be a potential hazard — there may be a situation where a user with less privileges will take advantage of the connection of the administrator user.
Do not store credentials and just data in an insecure place.
Remember to encrypt your credentials, and use authentication and authorization mechanisms that convey 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 transmit data in HTTP GET requests, as this may lead to a situation where important data can be copied by simple copying the request line, except for this line, HTTP GET requests are stored in browser history, on proxy servers and in web server logs.
Develop an authorization system based on the role model
Develop 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 admin rights. Do not make superuser from administrator.
Plan authentication type in advance
Depending on the tasks available, 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, do not use anything more than simple logins, passwords and role models, the use of authentication may be a good solution. based on forms with data source in Windows Azure storage services. If you need more complex business logic, you can use SQL Azure Databases as a data source, or if your script involves complex integration tasks for using the local Active Directory from a cloud application, using assertion authentication and AD FS 2.0 can be your choice. . If you need to use federated authentication, a great option is the Windows Azure Active Directory (Access Control Service), behind which you can combine a set of both public (Facebook, Live Id, ...) and private (Active Directory) identity providers.
Group parts of the application
Placing the maximum number of components of your service within one data center or region will help to improve both its performance and speed, and the degree of security by minimizing the traffic transmitted outside the data center.
Handle exceptions correctly
Potential vulnerabilities, sometimes very serious, can be caused by too excessive text of the thrown exception. Do not include in the exception text information that can tell 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 checking this. Check everything, otherwise it is possible to hack the system using various attacks, for example, SQL Injection. Centralize verification mechanisms by developing a special library. Never immediately create containers or other entities in your Windows Azure storage using information provided by the user — first check it or convert it.
Partial trust
By default, roles deployed to the Windows Azure platform work using full trust, which allows you to call non-.NET code or use the appropriate libraries that require administrative rights, which can cause a certain likelihood of a security breach. The use of partial trust allows at least a slight limit on the possibility that a cracker will have full access to the system — for example, with partial trust, a cracker will not be able to modify files. You can explicitly define partial trust in the service definition file (ServiceDefinition.cscfg) using the enableNativeCodeExecution attribute, defining its value as false.
Manage your keys correctly
The principle is simple - you cannot use keys provided by Windows Azure as keys for data encryption. In addition, what is related to key management, a great solution would be to change keys in a certain time period. For example, since two 256-bit keys are allocated to each storage account, you can use one at a time, and the second at another, after some time, you can generate a new primary key and switch to using it.
Actively use Shared Access Signatures and permissions
Actively use Shared Access Signatures and various permissions to limit 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 implementations of Microsoft:
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 — most likely they will be less perfect than the standard mechanisms adopted.
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, while using asymmetric encryption, use RSA with a minimum key length of 2048 bits.
Conclusion
Summarizing, you can combine the main points relating 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 the 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, the root OS, the guest OS, and the 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 the Fabric Controller is strictly limited.
• Packet filters . The hypervisor and root OS use packet filters to limit the possibility of spoofing traffic from untrusted virtual machines. Also limited to broadcast traffic.
• VLAN - all critical components are located in their own isolated VLAN-ah.
• When a client performs a data erase operation, the system ensures that it cannot be restored .
As with any new platform, even with all the changes made, the means of protection and encryption in Windows Azure are still under development and require constant improvement, but 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 links
Windows Azure Trust Center - www.windowsazure.com/en-us/support/trust-center
Source: https://habr.com/ru/post/153299/
All Articles