update

Author: JulianePadrao

learn-pr/wwl-data-ai/implement-data-security-compliance/includes/1-introduction.md

@@ -1,4 +1,4 @@
-Data security isn't just about preventing external attackers. You must protect sensitive information from unauthorized internal access, maintain compliance with regulations like HIPAA and GDPR, and create accountability through detailed audit trails. Microsoft's SQL platforms provide built-in security features that address these requirements without requiring extensive application changes.
+Data security isn't just about preventing external attackers. You must protect sensitive information from unauthorized internal access, maintain compliance with regulations, and create accountability through detailed audit trails. Microsoft's SQL platforms provide built-in security features that address these requirements without requiring extensive application changes.
 
 Modern development practices require you to build security into your database designs from the start. When you create tables that store personal information, you need to consider who should see that data and how to protect it. When you write stored procedures, you must think about what permissions they require and whether they could expose sensitive information. Security decisions made during development are far easier to implement than adding them later.
 

learn-pr/wwl-data-ai/implement-data-security-compliance/includes/10-exercise-implement-security-features.md

@@ -1,9 +1,9 @@
 Now it's your chance to implement data security and compliance features in Azure SQL Database.
 
-In this exercise, you'll configure Dynamic Data Masking to protect sensitive data, implement Row-Level Security for multi-tenant data isolation, and set up auditing to track database activity for compliance purposes.
+In this exercise, you'll configure Dynamic Data Masking to protect sensitive data, implement Row-Level Security for multitenant data isolation, and set up auditing to track database activity for compliance purposes.
 
 > [!NOTE]
-> To complete this exercise, you will need an [Azure subscription](https://azure.microsoft.com/pricing/purchase-options/azure-account?cid=msft_learn).
+> To complete this exercise, you'll need an [Azure subscription](https://azure.microsoft.com/pricing/purchase-options/azure-account?cid=msft_learn).
 
 Launch the exercise and follow the instructions.
 

learn-pr/wwl-data-ai/implement-data-security-compliance/includes/2-design-implement-data-encryption.md

@@ -8,15 +8,15 @@ Database encryption operates at different layers, each addressing specific secur
 
 :::image type="content" source="../media/encryption.png" alt-text="Diagram comparing three encryption layers: TDE at the database file level, column-level encryption at specific columns, and Always Encrypted with encryption keys held outside the database at the client application level.":::
 
-With TDE enabled, SQL Server automatically encrypts the database files, transaction logs, and backups. The encryption happens transparently to applications, requiring no code changes. TDE uses a database encryption key protected by a certificate stored in the master database.
+With TDE enabled, SQL Server automatically encrypts the database files, transaction logs, and backups. The encryption happens transparently to applications, requiring no code changes. TDE uses a database encryption key protected by a certificate stored in the `master` database.
 
 Unlike TDE, column-level encryption requires you to explicitly encrypt and decrypt data in your T-SQL code or application. This approach gives you granular control over which columns contain sensitive data and who can decrypt them.
 
 Always Encrypted takes a different approach by keeping encryption keys outside the database engine. The database never sees plaintext data, providing protection even from database administrators with high-level access.
 
 ## Configure Always Encrypted
 
-Always Encrypted protects sensitive data by ensuring the database engine never processes plaintext values. Client applications hold the encryption keys and perform all encryption and decryption operations. This separation means that even users with administrative access to the database cannot view the protected data.
+Always Encrypted protects sensitive data by ensuring the database engine never processes plaintext values. Client applications hold the encryption keys and perform all encryption and decryption operations. This separation means that even users with administrative access to the database can't view the protected data.
 
 :::image type="content" source="../media/ae-data-flow.png" alt-text="Diagram showing the data flow for Always Encrypted, where client applications encrypt and decrypt data while the database engine only processes ciphertext.":::
 

learn-pr/wwl-data-ai/implement-data-security-compliance/includes/3-design-implement-dynamic-data-masking.md

@@ -8,13 +8,13 @@ Dynamic Data Masking supports four masking functions, each designed for differen
 
 :::image type="content" source="../media/masking.png" alt-text="Table showing the four Dynamic Data Masking functions with before and after comparisons: Default shows XXXX, Email shows [email protected], Random shows random numbers, and Partial shows 206-XXX-XX89.":::
 
-The default masking function replaces the entire value with a fixed string. For string data types, it shows "XXXX" (or fewer X characters for shorter columns). Numeric values display as zero, and date values show 01-01-1900. This function works for any data type and provides complete obfuscation.
+The default masking function replaces the entire value with a fixed string. For string data types, it shows *"XXXX"* (or fewer X characters for shorter columns). Numeric values display as zero, and date values show *"01-01-1900"*. This function works for any data type and provides complete obfuscation.
 
-The email masking function reveals the first character of an email address, replaces the rest with "XXX", and preserves the domain suffix. For example, "[email protected]" appears as "[email protected]". This format maintains the appearance of valid email data while protecting the actual address.
+The email masking function reveals the first character of an email address, replaces the rest with "XXX", and preserves the domain suffix. For example, *"[email protected]"* appears as *"[email protected]"*. This format maintains the appearance of valid email data while protecting the actual address.
 
 With the random masking function, numeric values display as a random number within a specified range. You define minimum and maximum values, and each query returns a different random value. This approach works well for financial or statistical data where maintaining realistic-looking numbers matters.
 
-The partial masking function (also called custom string masking) gives you precise control over which characters to reveal. You specify a prefix length to show, padding characters to use, and a suffix length to display. For example, masking a phone number might show "206-XXX-XX89".
+The partial masking function (also called custom string masking) gives you precise control over which characters to reveal. You specify a prefix length to show, padding characters to use, and a suffix length to display. For example, masking a phone number might show *"206-XXX-XX89"*.
 
 ## Configure column masks
 
@@ -38,8 +38,8 @@ CREATE TABLE Customers (
 Each column uses a masking function appropriate for its data:
 
 - `Email` uses email masking to preserve the email format
-- `Phone` shows the first 3 digits and last 2 digits
-- `CreditCardNumber` reveals only the last 4 digits
+- `Phone` shows the first 3 digits and last two digits
+- `CreditCardNumber` reveals only the last four digits
 - `Income` displays a random value between 10,000 and 100,000
 - `SSN` uses default masking for complete obfuscation
 
@@ -120,4 +120,4 @@ Consider these scenarios where masking excels:
 > [!NOTE]
 > Dynamic Data Masking in SQL databases in Microsoft Fabric follows the same syntax and behavior as Azure SQL Database. Configure masks using T-SQL statements through the SQL analytics endpoint.
 
-Masking provides an additional layer of defense but shouldn't be your only protection for sensitive data. Use it alongside encryption, Row-Level Security, and proper permission management for comprehensive data protection.
+Masking provides an extra layer of defense but shouldn't be your only protection for sensitive data. Use it alongside encryption, Row-Level Security, and proper permission management for comprehensive data protection.

learn-pr/wwl-data-ai/implement-data-security-compliance/includes/4-design-implement-row-level-security.md

@@ -6,19 +6,19 @@ This capability proves valuable when multiple users or tenants share the same ta
 
 Row-Level Security in SQL Server and Azure SQL uses two components working together: security predicates and security policies. Understanding how these components interact helps you design effective RLS implementations.
 
-:::image type="content" source="../media/row-level-security.png" alt-text="Diagram showing Row-Level Security in a multi-tenant database where three users query the same Customers table but each sees only their tenant's rows, filtered by a Security Policy component.":::
+:::image type="content" source="../media/row-level-security.png" alt-text="Diagram showing Row-Level Security in a multitenant database where three users query the same Customers table but each sees only their tenant's rows, filtered by a Security Policy component.":::
 
 A security predicate is an inline table-valued function that returns 1 (true) or 0 (false) for each row. This function receives the current user context and row values as input, then determines whether that user should see the row. The predicate function encapsulates your business logic for data access.
 
 A security policy binds predicate functions to tables and specifies the type of filtering to apply. You can create filter predicates that silently exclude unauthorized rows from query results, or block predicates that prevent unauthorized insert, update, and delete operations.
 
-Filter predicates affect `SELECT`, `UPDATE`, and `DELETE` statements by removing rows the user cannot access. Users don't receive errors; they simply see a filtered result set. Block predicates prevent data modifications that would violate the security rules, raising an error when users attempt unauthorized changes.
+Filter predicates affect `SELECT`, `UPDATE`, and `DELETE` statements by removing rows the user can't access. Users don't receive errors; they see a filtered result set. Block predicates prevent data modifications that would violate the security rules, raising an error when users attempt unauthorized changes.
 
 ## Create filter predicates
 
 Start by creating a predicate function that evaluates row access. The function accepts parameters representing the column values to check and returns a table containing a single row when access is allowed.
 
-Consider a multi-tenant application where each row has a `TenantID` column:
+Consider a multitenant application where each row has a `TenantID` column:
 
 ```sql
 CREATE SCHEMA Security;
@@ -80,7 +80,7 @@ ADD BLOCK PREDICATE Security.fn_SalesRepPredicate(SalesRepID)
 WITH (STATE = ON);
 ```
 
-The block predicates ensure users can only insert or update rows they would be able to see. Without block predicates, a user could potentially insert rows with a different `SalesRepID` and lose access to data they just created.
+The block predicates ensure users can only insert or update rows they would be able to see. Without block predicates, a user could potentially insert rows with a different `SalesRepID` and lose access to data they created.
 
 ## Implement hierarchical access patterns
 
@@ -112,7 +112,7 @@ RETURN
 This recursive common table expression (CTE) builds the complete chain of employees reporting to the current user. The predicate allows access to any row owned by someone in that hierarchy.
 
 > [!NOTE]
-> Recursive predicates can impact query performance on large datasets. Consider caching hierarchy relationships or limiting recursion depth for better performance.
+> Recursive predicates can affect query performance on large datasets. Consider caching hierarchy relationships or limiting recursion depth for better performance.
 
 ## Manage security policies
 

learn-pr/wwl-data-ai/implement-data-security-compliance/includes/5-design-implement-object-level-permissions.md

@@ -6,7 +6,7 @@ Designing effective permission strategies requires understanding the permission
 
 SQL Server uses a hierarchical permission model where permissions granted at higher levels flow down to lower levels. The hierarchy flows from server to database to schema to individual objects. Understanding this hierarchy helps you grant permissions efficiently without excessive administrative burden.
 
-At the server level, permissions control login management, database creation, and server configuration. Database-level permissions govern actions within a specific database, such as creating tables or managing users. Schema-level permissions apply to all objects within a schema, while object-level permissions target specific tables, views, or procedures.
+At the server level, permissions control sign-in management, database creation, and server configuration. Database-level permissions govern actions within a specific database, such as creating tables or managing users. Schema-level permissions apply to all objects within a schema, while object-level permissions target specific tables, views, or procedures.
 
 When you grant `SELECT` permission on a schema, users can select from all tables and views in that schema, including objects created in the future. This approach simplifies administration compared to granting permissions on each object individually.
 

learn-pr/wwl-data-ai/implement-data-security-compliance/includes/6-implement-secure-database-access.md

@@ -1,4 +1,4 @@
-Secure database access extends beyond granting permissions to the right users. Modern applications require authentication methods that minimize credential exposure while maintaining operational flexibility. Passwordless authentication using Microsoft Entra ID (formerly Azure Active Directory) provides a more secure approach than traditional SQL authentication with usernames and passwords.
+Secure database access extends beyond granting permissions to the right users. Modern applications require authentication methods that minimize credential exposure while maintaining operational flexibility. Passwordless authentication using Microsoft Entra ID provides a more secure approach than traditional SQL authentication with usernames and passwords.
 
 Moving to passwordless authentication eliminates the risks associated with password management, including credential theft, password reuse, and the operational burden of rotating secrets. This unit explores how to implement secure, passwordless database access across SQL Server, Azure SQL, and SQL databases in Microsoft Fabric.
 
@@ -10,11 +10,11 @@ SQL authentication uses a username and password stored in the database. While st
 
 Windows authentication (for on-premises SQL Server) uses Active Directory credentials. Users authenticate to the domain, and SQL Server trusts that authentication. This approach works well for applications running on domain-joined servers.
 
-Microsoft Entra authentication extends identity integration to cloud scenarios. Applications can authenticate using Entra ID credentials, managed identities, or service principals. This method works with Azure SQL Database, Azure SQL Managed Instance, SQL Server 2022+, and SQL databases in Microsoft Fabric.
+Microsoft Entra authentication extends identity integration to cloud scenarios. Applications can authenticate using Microsoft Entra ID credentials, managed identities, or service principals. This method works with Azure SQL Database, Azure SQL Managed Instance, SQL Server 2022+, and SQL databases in Microsoft Fabric.
 
 ## Configure Microsoft Entra authentication
 
-To use Entra authentication with Azure SQL Database, first set an Entra administrator for the logical server:
+To use Microsoft Entra authentication with Azure SQL Database, first set a Microsoft Entra administrator for the logical server:
 
 ```sql
 -- Connect using the Entra admin account, then create database users
@@ -23,7 +23,7 @@ CREATE USER [[email protected]] FROM EXTERNAL PROVIDER;
 CREATE USER [DataAnalystsGroup] FROM EXTERNAL PROVIDER;
 ```
 
-The `FROM EXTERNAL PROVIDER` clause tells SQL to look up the identity in Microsoft Entra ID. You can create users for individual accounts, managed identities, or Entra groups.
+The `FROM EXTERNAL PROVIDER` clause tells SQL to look up the identity in Microsoft Entra ID. You can create users for individual accounts, managed identities, or Microsoft Entra groups.
 
 Grant permissions to these Entra-based users just like SQL users:
 
@@ -32,7 +32,7 @@ ALTER ROLE db_datareader ADD MEMBER [[email protected]];
 ALTER ROLE db_datawriter ADD MEMBER [app-service-identity];
 ```
 
-For SQL Server 2022 and later, enable Entra authentication through server configuration:
+For SQL Server 2022 and later, enable Microsoft Entra authentication through server configuration:
 
 ```sql
 -- Enable Azure AD authentication on SQL Server 2022
@@ -59,7 +59,7 @@ ALTER ROLE db_datareader ADD MEMBER [MyWebApp];
 ALTER ROLE db_datawriter ADD MEMBER [MyWebApp];
 ```
 
-Update your application connection string to use Entra authentication:
+Update your application connection string to use Microsoft Entra authentication:
 
 ```
 Server=myserver.database.windows.net;Database=mydb;Authentication=Active Directory Managed Identity;
@@ -111,9 +111,9 @@ await connection.OpenAsync();
 
 ## Implement contained database users
 
-Contained database users exist only within the database, without requiring a server-level login. This approach simplifies deployment and supports database portability across servers.
+Contained database users exist only within the database, without requiring a server-level sign-in. This approach simplifies deployment and supports database portability across servers.
 
-Create a contained user with a password when Entra authentication isn't available:
+Create a contained user with a password when Microsoft Entra authentication isn't available:
 
 ```sql
 CREATE USER AppUser WITH PASSWORD = 'ComplexPassword123!';
@@ -154,4 +154,4 @@ A secure connection string for Azure SQL with managed identity:
 Server=tcp:myserver.database.windows.net,1433;Database=mydb;Authentication=Active Directory Managed Identity;Encrypt=True;TrustServerCertificate=False;Connection Timeout=30;
 ```
 
-For SQL databases in Microsoft Fabric, connections use Entra authentication through the workspace identity. Configure access by adding Entra users or groups to workspace roles, which automatically grants appropriate database permissions.
+For SQL databases in Microsoft Fabric, connections use Microsoft Entra authentication through the workspace identity. Configure access by adding Microsoft Entra users or groups to workspace roles, which automatically grant appropriate database permissions.