azure云数据库_Azure SQL数据库的安全注意事项

azure云数据库

You have to agree with me, when public clouds were introduced your thought was that you will never put your production data in there. Our idea was that your data is exposed, insecure and vulnerable. This was not the case back then, it is not case at the moment as well.

您必须同意我的看法，当引入公共云时，您的想法是您永远不会将生产数据放入其中。 我们的想法是您的数据是公开的，不安全的和易受攻击的。 那时不是这种情况，目前也不是这种情况。

Microsoft Azure implemented numerous features to help us secure our Azure SQL Databases on so many different levels, from securing the inbound connections to encrypting your whole database. Along with the possibility to setup firewall rules and setup server and database audits I would suggest that now Azure is quite a safe place to run a SQL Database.

Microsoft Azure实施了许多功能，以帮助我们在许多不同级别上保护我们的Azure SQL数据库，从保护入站连接到加密整个数据库。 除了可以设置防火墙规则以及设置服务器和数据库审核外，我还建议Azure现在是运行SQL数据库的安全场所。

We can divide the current options for protecting our SQL databases within azure in three major categories:

我们可以将Azure上保护SQL数据库的当前选项分为三个主要类别：

• Monitoring the activities 监控活动
• Controlling the access 控制访问
• Physically protecting the data 物理保护数据

Starting with Monitoring – we have the possibility to enable a server wide audit session that is by default inherited by each of the databases created within this logical server. Of course, we can disable this on server level and enable it on each database, the second option is to exclude only certain databases.

从监视开始-我们可以启用服务器范围的审核会话，默认情况下，该会话由此逻辑服务器内创建的每个数据库继承。 当然，我们可以在服务器级别禁用此功能，并在每个数据库上启用它，第二个选择是仅排除某些数据库。

The default configurations that we see when navigating to the “Auditing & Thread detection” tab is as follows:

导航到“ 审核和线程检测 ”选项卡时看到的默认配置如下：

When we disable the “Inherit settings from server” additional configuration options appear.

当我们禁用“从服务器继承设置”时，会出现其他配置选项。

We can choose if we would like to enable auditing and thread detection. Along with the possibility to choose where to store our audits, which thread detection types we would like to use and an email to be notified upon a new thread. Recommended is to keep the audits within a blob storage as it is both faster and less expensive than using a Table – which is now also deprecated and will not be available in the future.

我们可以选择是否要启用审核和线程检测。 除了可以选择在哪里存储我们的审核，我们想使用哪种线程检测类型以及在新线程被通知时发送电子邮件外，还可以。 建议将审核保留在Blob存储中，因为与使用表相比，审核既快速又便宜，现在不推荐使用，将来也将不可用。

Once the audit settings are altered and saved, we have the possibility to directly review the stored data from the portal using the “View audit logs” button.

一旦更改并保存了审核设置，我们便可以使用“查看审核日志”按钮直接从门户查看已存储的数据。

Of course, there are other ways of reviewing the log and extracting the required data, one of them is to use the “Microsoft Azure Storage Explorer”:

当然，还有其他方法可以查看日志并提取所需的数据，其中一种方法是使用“ Microsoft Azure存储资源管理器”：

Note that the audit logs are stored as .xel files and you can use SSMS to review them as well.

请注意，审核日志存储为.xel文件，您也可以使用SSMS对其进行审核。

Thread detection (currently in public preview) is activated in similar way, in addition we have the possibility to choose for which kind of threads we would like to monitor – SQL Injection, SQL Injection vulnerability, Anomalous client login or all.

线程检测 （当前在公共预览中）以类似的方式激活，此外，我们还可以选择我们要监视的线程类型-SQL注入，SQL注入漏洞，异常客户端登录或全部。

Once this is configured our SQL database will be monitored automatically, on the background three different methods are working on for us – Integrated threat intelligence, Behavioural analytics and Anomaly detection. Thread intelligence and Behavioural analytics rely on the insights that Microsoft gather from their broad range of services, security teams and the know patters of different attacks.

一旦配置完成，我们SQL数据库将被自动监视，在后台我们可以使用三种不同的方法-集成威胁情报，行为分析和异常检测。 线程智能和行为分析依赖于Microsoft从其广泛的服务，安全团队以及各种攻击的已知模式中收集的见解。

Anomaly detection is a more personalized solution which utilizes machine learning capabilities to get familiar with our environment and to spot any strange actions that may occur and deviate from the standard. All of the security recommendations and threads are reported within a central location named “Azure Security Center”, in addition it allows you to directly integrate it with PowerBI or take the recommended actions securing your environments directly from the Security Center.

异常检测是一种更加个性化的解决方案，它利用机器学习功能来熟悉我们的环境并发现可能发生的任何偏离标准的奇怪动作。 所有安全建议和线程均在名为“ Azure安全中心”的中央位置报告，此外，它还使您可以将其直接与PowerBI集成或采取建议的措施直接从安全中心保护环境。

In order to Control access to our SQL Databases we can rely on the Azure Firewall implementation, or technologies that we are familiar with from the on premise implementations – Active Directory authentication, Dynamic data masking and roll-level security.

为了控制对SQL数据库的访问 ，我们可以依赖Azure防火墙实现或内部实现中熟悉的技术-Active Directory身份验证，动态数据屏蔽和卷级安全性。

Firewall implementation is fairly simple, we have a server and database level rules that allow a range of IPs access to our resources. Without explicitly creating new rule no one has access to our SQL Databases. Server level rules can be created from the portal by specifying the Start and End IPs of a certain range:

防火墙的实现非常简单，我们有一个服务器和数据库级别的规则，允许各种IP访问我们的资源。 没有明确创建新规则，没有人可以访问我们SQL数据库。 可以通过指定特定范围的开始和结束IP从门户创建服务器级别规则：

Database level rules can be created only using TSQL or PowerShell. Creating a new firewall rule using TSQL utilizes the stored procedure “sp_set_firewall_rule”, deleting a firewall rule utilizes the “sp_delete_firewall_rule” procedure

只能使用TSQL或PowerShell创建数据库级规则。 使用TSQL使用存储过程“ sp_set_firewall_rule”创建新的防火墙规则，使用“ sp_delete_firewall_rule”过程删除防火墙规则

 
EXECUTE sp_set_firewall_rule @name = N'Allow_Megalan_Inbound',
@start_ip_address = '77.70.0.0', @end_ip_address = '77.70.127.255'
 

Dynamic data masking has its own configuration tab as well, in which we could see recommendations for columns that contain sensitive data and can benefit from masking them.

动态数据屏蔽也有其自己的配置选项卡，在其中我们可以看到有关包含敏感数据的列的建议，并且可以从对其进行屏蔽中受益。

Adding a mask that was recommended to us is fairly simple, we only need to choose “Add mask” for the certain column and then Save the changes.

添加推荐给我们的蒙版非常简单，我们只需要为特定列选择“添加蒙版”，然后保存更改即可。

Azure is able to determine the type of data that is stored within a column and choose a suitable masking function, in our case the email masking function is hiding most of the email, and the Credit card masking function is hiding all except the last four digits.

Azure能够确定存储在列中的数据类型并选择合适的屏蔽功能，在我们的示例中，电子邮件屏蔽功能将隐藏大多数电子邮件，而信用卡屏蔽功能将隐藏除最后四位数字以外的所有电子邮件。

Other available masking functions available at our disposal are the “Default value”, “Random value” and “Custom string”.

我们可以使用的其他可用屏蔽功能是“默认值”，“随机值”和“自定义字符串”。

Once a masking functions is enabled only administrators and users that are explicitly listed can unmask the data, otherwise it is visible as follows:

启用屏蔽功能后，只有明确列出的管理员和用户才能取消屏蔽数据，否则可见如下：

To grant a user rights to unmask data it should be listed as follows:

要授予用户取消屏蔽数据的权限，应列出以下内容：

Physically protecting your data is something quite important, especially in the case when your database resides in somebodies else datacentre. Encrypting your data and making it readable only when using a certificate or key can be done by either using Transparent Data Encryption (TDE) or Always Encrypted.

在物理上保护数据非常重要，尤其是在数据库位于其他数据中心的情况下。 可以通过使用透明数据加密（TDE）或始终加密来加密数据并使其仅在使用证书或密钥时才可读。

Transparent data encryption for SQL Databases in Azure is quite easily configured true its configuration tab. With SQL databases we do not have the possibility to control where the keys and certificates are placed. Using a SQL Server hosted on a virtual machine we have the additional option to use an asymmetric key from Azure Key Vault.

在“配置”选项卡中，可以轻松配置Azure中SQL数据库的透明数据加密。 使用SQL数据库，我们无法控制密钥和证书的放置位置。 使用虚拟机上托管SQL Server，我们还有其他选择，可以使用Azure Key Vault中的非对称密钥。

Once configured the physical files of your database are now encrypted and can be accessed only by the SQL engine that has the required certificates and keys*****; In addition to this the database backups, logs and geo-replicated copies are encrypted as well and Azure manages all of the required actions on our behalf. When exporting a database from Azure the export file .bacpac is a non-encrypted one and it is our responsibility to secure it once we have it.

配置完成后，数据库的物理文件现在已加密，并且只有具有所需证书和密钥SQL引擎才能访问*****； 除此之外，数据库备份，日志和地理复制副本也被加密，Azure代表我们管理所有必需的操作。 从Azure导出数据库时，导出文件.bacpac是未加密的文件，因此我们有责任保护它。

翻译自: https://www.sqlshack.com/security-considerations-for-your-azure-sql-databases/

azure云数据库