Merge pull request #259694 from GennadNY/gennadyk-main34

defender

Author: v-dirichards

articles/postgresql/flexible-server/concepts-networking-ssl-tls.md

@@ -58,9 +58,16 @@ SELECT datname as "Database name", usename as "User name", ssl, client_addr, app
    ORDER BY ssl;
 ```
 
+For testing, you can also use the **openssl** command directly, for example:
+```bash
+openssl s_client -connect localhost:5432 -starttls postgres
+```
+This will print out a lot of low-level protocol information, including the TLS version, cipher, and so on. Note that you must use the option -starttls postgres, or otherwise this command will report that no SSL is in use. This requires at least OpenSSL 1.1.1. 
+
 > [!NOTE]  
 > To enforce **latest, most secure TLS version** for connectivity protection from client to Azure Database for PostgreSQL - Flexible Server set **ssl_min_protocol_version** to **1.3**. That would **require** clients connecting to your Azure Postgres server to use **this version of the protocol only** to securely communicate. However, older clients, since they don't support this version, may not be able to communicate with the server.
 
+
 ## Cipher Suites
 
 A **cipher suite** is a set of cryptographic algorithms. TLS/SSL protocols use algorithms from a cipher suite to create keys and encrypt information. 

articles/postgresql/flexible-server/concepts-security.md

@@ -44,6 +44,37 @@ When you're running Azure Database for PostgreSQL - Flexible Server, you have tw
 
   IP firewall rules grant access to servers based on the originating IP address of each request. For more information, see the [overview of firewall rules](concepts-firewall-rules.md).
 
+## Microsoft Defender for Cloud support
+
+**[Defender for Cloud](../../defender-for-cloud/defender-for-databases-introduction.md)** detects anomalous activities indicating unusual and potentially harmful attempts to access or exploit databases. Defender for Cloud provides [security alerts](../../defender-for-cloud/alerts-reference.md#alerts-osrdb) on anomalous activities so that you can detect potential threats and respond to them as they occur.
+When you enable this plan, Defender for Cloud will provide alerts when it detects anomalous database access and query patterns as well as suspicious database activities.
+
+These alerts appear in Defender for Cloud's security alerts page and include:
+
+* Details of the suspicious activity that triggered them
+* The associated MITRE ATT&CK tactic
+* Recommended actions for how to investigate and mitigate the threat
+* Options for continuing your investigations with Microsoft Sentinel
+
+> [!NOTE]
+> Microsoft Defender for Azure Database for PostgreSQL - Flexible Server currently has following limitations:
+> - No Azure CLI or PowerShell support.
+> - No ability to enable Cloud Defender for Azure Database for PostgreSQL - Flexible Server on subscription level.
+
+### Microsoft Defender for Cloud and Brute Force Attacks
+
+A brute force attack is among the most common and fairly successful hacking methods, despite being least sophisticated hacking methods. The theory behind such an attack is that if you take an infinite number of attempts to guess a password, you are bound to be right eventually. When Microsoft Defender for Cloud detects a brute force attack, it triggers an [alert](../../defender-for-cloud/defender-for-databases-introduction.md#what-kind-of-alerts-does-microsoft-defender-for-open-source-relational-databases-provide) to bring you awareness that a brute force attack took place. It also can separate  simple brute force attack from brute force attack on a valid user or a successful brute force attack.
+
+To get alerts from the Microsoft Defender plan you'll first need to **enable it** as shown in the next section.
+
+### Enable enhanced security with Microsoft Defender for Cloud
+1. From the [Azure portal](https://portal.azure.com), navigate to Security menu in the left pane
+2. Pick Microsoft Defender for Cloud 
+4. Click Enable in the right pane.
+
+:::image type="content" source="./media/concepts-security/defender-for-cloud-azure-portal-postgresql.png" alt-text="Screenshot of Azure portal showing how to enable Cloud Defender.":::
+
+
 ## Access management
 
 Best way to manage PostgreSQL database access permissions at scale is using the concept of [roles](https://www.postgresql.org/docs/current/user-manag.html). A role can be either a database user or a group of database users.  Roles can own the database objects and assign privileges on those objects to other roles to control who has access to which objects. It is also possible to grant membership in a role to another role, thus allowing the member role to use privileges assigned to another role.
@@ -146,7 +177,7 @@ In this example, user *user1* can connect and has all privileges in our test dat
 
 ## Row  level security
 
-[Row level security (RLS)](https://www.postgresql.org/docs/current/ddl-rowsecurity.html) is a PostgreSQL security feature that allows database administrators to define policies to control how specific rows of data display and operate for one or more roles.  Row level security is an additional filter you can apply to a PostgreSQL database table. When a user tries to perform an action on a table, this filter is applied before the query criteria or other filtering, and the data is narrowed or rejected according to your security policy. You can create row level security policies for specific commands like *SELECT*, *INSERT*, *UPDATE*, and *DELETE*, specify it for ALL commands. Use cases for row level security include PCI compliant implementations, classified environments, as well as shared hosting / multi-tenant applications. 
+[Row level security (RLS)](https://www.postgresql.org/docs/current/ddl-rowsecurity.html) is a PostgreSQL security feature that allows database administrators to define policies to control how specific rows of data display and operate for one or more roles.  Row level security is an additional filter you can apply to a PostgreSQL database table. When a user tries to perform an action on a table, this filter is applied before the query criteria or other filtering, and the data is narrowed or rejected according to your security policy. You can create row level security policies for specific commands like *SELECT*, *INSERT*, *UPDATE*, and *DELETE*, specify it for ALL commands. Use cases for row level security include PCI compliant implementations, classified environments, as well as shared hosting / multitenant applications. 
 Only users with `SET ROW SECURITY` rights may apply row security rights to a table. The table owner may set row security on a table. Like `OVERRIDE ROW SECURITY` this is currently an implicit right. Row-level security does not override existing *GRANT* permissions, it adds a finer grained level of control. For example, setting `ROW SECURITY FOR SELECT` to allow a given user to give rows would only give that user access if the user also has *SELECT* privileges on the column or table in question.
 
 Here is an example showing how to create a policy that ensures only members of the custom created *“manager”* [role](#access-management) can access only the rows for a specific account. The code in below example was shared in the [PostgreSQL documentation](https://www.postgresql.org/docs/current/ddl-rowsecurity.html).

articles/postgresql/flexible-server/concepts-storage-extension.md

@@ -50,7 +50,7 @@ To load data from Azure Blob Storage, you need [allowlist](../../postgresql/flex
  CREATE EXTENSION azure_storage;
 ```
 
-When you create a storage account, Azure generates two 512-bit storage **account access keys** for that account. These keys can be used to authorize access to data in your storage account via Shared Key authorization, or via SAS tokens that are signed with the shared key.Therefore, before you can import the data, you need to map  storage account using **account_add** method, providing **account access key** defined when account was created. Code snippet shows mapping storage account *'mystorageaccount'* where access key parameter is shown as string *'SECRET_ACCESS_KEY'*.
+When you create a storage account, Azure generates two 512-bit storage **account access keys** for that account. These keys can be used to authorize access to data in your storage account via Shared Key authorization. Therefore, before you can import the data, you need to map  storage account using **account_add** method, providing **account access key** defined when account was created. Code snippet shows mapping storage account *'mystorageaccount'* where access key parameter is shown as string *'SECRET_ACCESS_KEY'*.
 
 ```sql
 SELECT azure_storage.account_add('mystorageaccount', 'SECRET_ACCESS_KEY');