You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: azure-sql/database/data-discovery-and-classification-overview.md
+2-2Lines changed: 2 additions & 2 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -107,7 +107,7 @@ After the organization-wide policy has been defined, you can continue classifyin
107
107
108
108
## <aid="audit-sensitive-data"></a>Audit access to sensitive data
109
109
110
-
An important aspect of the classification is the ability to monitor access to sensitive data. [Azure SQL Auditing](../../azure-sql/database/auditing-overview.md) has been enhanced to include a new field in the audit log called `data_sensitivity_information`. This field logs the sensitivity classifications (labels) of the data that was returned by a query. Here's an example:
110
+
An important aspect of the classification is the ability to monitor access to sensitive data. [Azure SQL Auditing](/azure/azure-sql/database/auditing-overview) has been enhanced to include a new field in the audit log called `data_sensitivity_information`. This field logs the sensitivity classifications (labels) of the data that was returned by a query. Here's an example:
@@ -228,6 +228,6 @@ You can use the following SQL drivers to retrieve classification metadata:
228
228
229
229
## Next steps
230
230
231
-
- Consider configuring [Azure SQL Auditing](../../azure-sql/database/auditing-overview.md) for monitoring and auditing access to your classified sensitive data.
231
+
- Consider configuring [Azure SQL Auditing](/azure/azure-sql/database/auditing-overview) for monitoring and auditing access to your classified sensitive data.
232
232
- For a presentation that includes data Discovery & Classification, see [Discovering, classifying, labeling & protecting SQL data | Data Exposed](https://www.youtube.com/watch?v=itVi9bkJUNc).
233
233
- To classify your Azure SQL Databases and Azure Synapse Analytics with Microsoft Purview labels using T-SQL commands, see [Classify your Azure SQL data using Microsoft Purview labels](/azure/sql-database/scripts/sql-database-import-purview-labels).
Copy file name to clipboardExpand all lines: azure-sql/database/disaster-recovery-guidance.md
+1-1Lines changed: 1 addition & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -107,7 +107,7 @@ For more information about database alert rules, see [Receive Alert Notification
107
107
108
108
### Enable auditing
109
109
110
-
If auditing is required to access your database, you need to enable Auditing after the database recovery. For more information, see [Database auditing](../../azure-sql/database/auditing-overview.md).
110
+
If auditing is required to access your database, you need to enable Auditing after the database recovery. For more information, see [Database auditing](/azure/azure-sql/database/auditing-overview).
Copy file name to clipboardExpand all lines: azure-sql/database/firewall-configure.md
+1-1Lines changed: 1 addition & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -120,7 +120,7 @@ You create the first server-level firewall setting by using the [Azure portal](h
120
120
To improve performance, server-level IP firewall rules are temporarily cached at the database level. To refresh the cache, see [DBCC FLUSHAUTHCACHE](/sql/t-sql/database-console-commands/dbcc-flushauthcache-transact-sql).
121
121
122
122
> [!TIP]
123
-
> You can use [Database Auditing](../../azure-sql/database/auditing-overview.md) to audit server-level and database-level firewall changes.
123
+
> You can use [Database Auditing](/azure/azure-sql/database/auditing-overview) to audit server-level and database-level firewall changes.
124
124
125
125
### Use the Azure portal to manage server-level IP firewall rules
In Azure SQL Database and Azure Synapse Analytics, a server is a logical construct that acts as a central administrative point for a collection of databases. At the server level, you can administer [logins](logins-create-manage.md), [firewall rules](firewall-configure.md), [auditing rules](../../azure-sql/database/auditing-overview.md), [threat detection policies](threat-detection-configure.md), and [auto-failover groups](auto-failover-group-sql-db.md). A server can be in a different region than its resource group. The server must exist before you can create a database in Azure SQL Database or a data warehouse database in Azure Synapse Analytics. All databases managed by a single server are created within the same region as the server.
18
+
In Azure SQL Database and Azure Synapse Analytics, a server is a logical construct that acts as a central administrative point for a collection of databases. At the server level, you can administer [logins](logins-create-manage.md), [firewall rules](firewall-configure.md), [auditing rules](/azure/azure-sql/database/auditing-overview), [threat detection policies](threat-detection-configure.md), and [auto-failover groups](auto-failover-group-sql-db.md). A server can be in a different region than its resource group. The server must exist before you can create a database in Azure SQL Database or a data warehouse database in Azure Synapse Analytics. All databases managed by a single server are created within the same region as the server.
19
19
20
20
This server is distinct from a SQL Server instance that you may be familiar with in the on-premises world. Specifically, there are no guarantees regarding location of the databases or data warehouse database in relation to the server that manages them. Furthermore, neither Azure SQL Database nor Azure Synapse expose any instance-level access or features. In contrast, the instance databases in a managed instance are all physically co-located - in the same way that you are familiar with SQL Server in the on-premises or virtual machine world.
Copy file name to clipboardExpand all lines: azure-sql/database/maintenance-window.md
+2-2Lines changed: 2 additions & 2 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -134,11 +134,11 @@ To get the maximum benefit from maintenance windows, make sure your client appli
134
134
135
135
* In Azure SQL Database, any connections using the proxy connection policy could be affected by both the chosen maintenance window and a gateway node maintenance window. However, client connections using the recommended redirect connection policy are unaffected by a gateway node maintenance reconfiguration.
136
136
137
-
* In Azure SQL Managed Instance, the gateway nodes are hosted [within the virtual cluster](../../azure-sql/managed-instance/connectivity-architecture-overview.md#virtual-cluster-connectivity-architecture) and have the same maintenance window as the managed instance, but using the redirect connection policy is still recommended to minimize number of disruptions during the maintenance event.
137
+
* In Azure SQL Managed Instance, the gateway nodes are hosted [within the virtual cluster](/azure/azure-sql/managed-instance/connectivity-architecture-overview#virtual-cluster-connectivity-architecture) and have the same maintenance window as the managed instance, but using the redirect connection policy is still recommended to minimize number of disruptions during the maintenance event.
138
138
139
139
For more on the client connection policy in Azure SQL Database, see [Azure SQL Database Connection policy](../database/connectivity-architecture.md#connection-policy).
140
140
141
-
For more on the client connection policy in Azure SQL Managed Instance, see [Azure SQL Managed Instance connection types](../../azure-sql/managed-instance/connection-types-overview.md).
141
+
For more on the client connection policy in Azure SQL Managed Instance, see [Azure SQL Managed Instance connection types](/azure/azure-sql/managed-instance/connection-types-overview).
Copy file name to clipboardExpand all lines: azure-sql/database/manage-data-after-migrating-to-database.md
+3-3Lines changed: 3 additions & 3 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -85,11 +85,11 @@ To learn more about Disaster recovery, see: [Azure SQL Database Disaster Recover
85
85
SQL Database takes Security and Privacy very seriously. Security within SQL Database is available at the database level and at the platform level and is best understood when categorized into several layers. At each layer you get to control and provide optimal security for your application. The layers are:
86
86
87
87
- Identity & authentication ([SQL authentication and Azure Active Directory [Azure AD] authentication](logins-create-manage.md)).
88
-
- Monitoring activity ([Auditing](../../azure-sql/database/auditing-overview.md) and [threat detection](threat-detection-configure.md)).
88
+
- Monitoring activity ([Auditing](/azure/azure-sql/database/auditing-overview) and [threat detection](threat-detection-configure.md)).
89
89
- Protecting actual data ([Transparent Data Encryption [TDE]](/sql/relational-databases/security/encryption/transparent-data-encryption-azure-sql) and [Always Encrypted [AE]](/sql/relational-databases/security/encryption/always-encrypted-database-engine)).
90
90
- Controlling Access to sensitive and privileged data ([Row Level security](/sql/relational-databases/security/row-level-security) and [Dynamic Data Masking](/sql/relational-databases/security/dynamic-data-masking)).
91
91
92
-
[Microsoft Defender for Cloud](https://azure.microsoft.com/services/security-center/) offers centralized security management across workloads running in Azure, on-premises, and in other clouds. You can view whether essential SQL Database protection such as [Auditing](../../azure-sql/database/auditing-overview.md) and [Transparent Data Encryption [TDE]](/sql/relational-databases/security/encryption/transparent-data-encryption-azure-sql) are configured on all resources, and create policies based on your own requirements.
92
+
[Microsoft Defender for Cloud](https://azure.microsoft.com/services/security-center/) offers centralized security management across workloads running in Azure, on-premises, and in other clouds. You can view whether essential SQL Database protection such as [Auditing](/azure/azure-sql/database/auditing-overview) and [Transparent Data Encryption [TDE]](/sql/relational-databases/security/encryption/transparent-data-encryption-azure-sql) are configured on all resources, and create policies based on your own requirements.
93
93
94
94
### What user authentication methods are offered in SQL Database
95
95
@@ -147,7 +147,7 @@ Port 1433. SQL Database communicates over this port. To connect from within a co
147
147
148
148
#### SQL Database Auditing
149
149
150
-
With SQL Database, you can turn ON Auditing to track database events. [SQL Database Auditing](../../azure-sql/database/auditing-overview.md) records database events and writes them into an audit log file in your Azure Storage Account. Auditing is especially useful if you intend to gain insight into potential security and policy violations, maintain regulatory compliance etc. It allows you to define and configure certain categories of events that you think need auditing and based on that you can get preconfigured reports and a dashboard to get an overview of events occurring on your database. You can apply these auditing policies either at the database level or at the server level. A guide on how to turn on auditing for your server/database, see: [Enable SQL Database Auditing](secure-database-tutorial.md#enable-security-features).
150
+
With SQL Database, you can turn ON Auditing to track database events. [SQL Database Auditing](/azure/azure-sql/database/auditing-overview) records database events and writes them into an audit log file in your Azure Storage Account. Auditing is especially useful if you intend to gain insight into potential security and policy violations, maintain regulatory compliance etc. It allows you to define and configure certain categories of events that you think need auditing and based on that you can get preconfigured reports and a dashboard to get an overview of events occurring on your database. You can apply these auditing policies either at the database level or at the server level. A guide on how to turn on auditing for your server/database, see: [Enable SQL Database Auditing](secure-database-tutorial.md#enable-security-features).
Copy file name to clipboardExpand all lines: azure-sql/database/move-resources-across-regions.md
+2-2Lines changed: 2 additions & 2 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -58,7 +58,7 @@ This article provides a general workflow for moving resources to a different reg
58
58
1. If database-level audit is enabled, disable it and enable server-level auditing instead. After failover, database-level auditing will require the cross-region traffic, which isn't desired or possible after the move.
59
59
1. For server-level audits, ensure that:
60
60
- The storage container, Log Analytics, or event hub with the existing audit logs is moved to the target region.
61
-
- Auditing is configured on the target server. For more information, see [Get started with SQL Database auditing](../../azure-sql/database/auditing-overview.md).
61
+
- Auditing is configured on the target server. For more information, see [Get started with SQL Database auditing](/azure/azure-sql/database/auditing-overview).
62
62
1. If your instance has a long-term retention policy (LTR), the existing LTR backups will remain associated with the current server. Because the target server is different, you'll be able to access the older LTR backups in the source region by using the source server, even if the server is deleted.
63
63
64
64
> [!NOTE]
@@ -109,7 +109,7 @@ Once the move completes, remove the resources in the source region to avoid unne
109
109
1. If a database-level audit is enabled, disable it and enable server-level auditing instead. After failover, database-level auditing will require cross-region traffic, which is not desired, or possible after the move.
110
110
1. For server-level audits, ensure that:
111
111
- The storage container, Log Analytics, or event hub with the existing audit logs is moved to the target region.
112
-
- Audit configuration is configured at the target server. For more information, see [SQL Database auditing](../../azure-sql/database/auditing-overview.md).
112
+
- Audit configuration is configured at the target server. For more information, see [SQL Database auditing](/azure/azure-sql/database/auditing-overview).
113
113
1. If your instance has a long-term retention policy (LTR), the existing LTR backups will remain associated with the current server. Because the target server is different, you'll be able to access the older LTR backups in the source region using the source server, even if the server is deleted.
0 commit comments