Skip to content

Commit 7a9fbfb

Browse files
Merge pull request #263634 from AlicjaKucharczyk/patch-4
polishing
2 parents dd24477 + 192c361 commit 7a9fbfb

File tree

1 file changed

+51
-64
lines changed

1 file changed

+51
-64
lines changed

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

Lines changed: 51 additions & 64 deletions
Original file line numberDiff line numberDiff line change
@@ -16,25 +16,25 @@ ms.date: 2/10/2023
1616

1717
[!INCLUDE [applies-to-postgresql-flexible-server](../includes/applies-to-postgresql-flexible-server.md)]
1818

19-
Multiple layers of security are available to help protect the data on your Azure Database for PostgreSQL flexible server instance. This article outlines those security options.
19+
Multiple layers of security are available to help protect the data on your Azure Database for PostgreSQL - Flexible Server instance. This article outlines those security options.
2020

2121
## Information protection and encryption
2222

23-
Azure Database for PostgreSQL flexible server encrypts data in two ways:
23+
Azure Database for PostgreSQL - Flexible Server encrypts data in two ways:
2424

25-
- **Data in transit**: Azure Database for PostgreSQL flexible server encrypts in-transit data with Secure Sockets Layer and Transport Layer Security (SSL/TLS). Encryption is enforced by default. See this [guide](how-to-connect-tls-ssl.md) for more details. For better security, you may choose to enable [SCRAM authentication](how-to-connect-scram.md).
25+
- **Data in transit**: Azure Database for PostgreSQL - Flexible Server encrypts in-transit data with Secure Sockets Layer and Transport Layer Security (SSL/TLS). Encryption is enforced by default. See this [guide](how-to-connect-tls-ssl.md) for more details. For better security, you may choose to enable [SCRAM authentication](how-to-connect-scram.md).
2626

27-
Although it's not recommended, if needed, you have an option to disable TLS\SSL for connections to Azure Database for PostgreSQL flexible server by updating the `require_secure_transport` server parameter to OFF. You can also set TLS version by setting `ssl_max_protocol_version` server parameters.
27+
Although it's not recommended, if needed, you have an option to disable TLS\SSL for connections to Azure Database for PostgreSQL - Flexible Server by updating the `require_secure_transport` server parameter to OFF. You can also set TLS version by setting `ssl_max_protocol_version` server parameters.
2828

2929

30-
- **Data at rest**: For storage encryption, Azure Database for PostgreSQL flexible server uses the FIPS 140-2 validated cryptographic module. Data is encrypted on disk, including backups and the temporary files created while queries are running.
30+
- **Data at rest**: For storage encryption, Azure Database for PostgreSQL - Flexible Server uses the FIPS 140-2 validated cryptographic module. Data is encrypted on disk, including backups and the temporary files created while queries are running.
3131

3232
The service uses the AES 256-bit cipher included in Azure storage encryption, and the keys are system managed. This is similar to other at-rest encryption technologies, like transparent data encryption in SQL Server or Oracle databases. Storage encryption is always on and can't be disabled.
3333

3434

3535
## Network security
3636

37-
When you're running Azure Database for PostgreSQL flexible server, you have two main networking options:
37+
When you're running Azure Database for PostgreSQL - Flexible Server, you have two main networking options:
3838

3939
- **Private access**: You can deploy your server into an Azure virtual network. Azure virtual networks help provide private and secure network communication. Resources in a virtual network can communicate through private IP addresses. For more information, see the [networking overview for Azure Database for PostgreSQL - Flexible Server](concepts-networking.md).
4040

@@ -77,30 +77,30 @@ To get alerts from the Microsoft Defender plan you'll first need to **enable it*
7777

7878
## Access management
7979

80-
The best way to manage Azure Database for PostgreSQL flexible server 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.
81-
Azure Database for PostgreSQL flexible server lets you grant permissions directly to the database users. **As a good security practice, it can be recommended that you create roles with specific sets of permissions based on minimum application and access requirements. You can then assign the appropriate roles to each user. Roles are used to enforce a *least privilege model* for accessing database objects.**
80+
The best way to manage Azure Database for PostgreSQL - Flexible Server 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.
81+
Azure Database for PostgreSQL - Flexible Server lets you grant permissions directly to the database users. **As a good security practice, it can be recommended that you create roles with specific sets of permissions based on minimum application and access requirements. You can then assign the appropriate roles to each user. Roles are used to enforce a *least privilege model* for accessing database objects.**
8282

83-
The Azure Database for PostgreSQL flexible server instance is created with the three default roles defined. You can see these roles by running the command:
83+
The Azure Database for PostgreSQL - Flexible Server instance is created with the three default roles defined. You can see these roles by running the command:
8484
```sql
8585
SELECT rolname FROM pg_roles;
8686
```
87-
* azure_pg_admin.
88-
* azuresu.
89-
* administrator role.
87+
* `azure_pg_admin`
88+
* `azuresu`
89+
* administrator role
9090

91-
While you're creating the Azure Database for PostgreSQL flexible server instance, you provide credentials for an **administrator role**. This administrator role can be used to create more [PostgreSQL roles](https://www.postgresql.org/docs/current/user-manag.html).
92-
For example, below we can create an example role called *demouser*,
91+
While you're creating the Azure Database for PostgreSQL - Flexible Server instance, you provide credentials for an **administrator role**. This administrator role can be used to create more [PostgreSQL roles](https://www.postgresql.org/docs/current/user-manag.html).
92+
For example, below we can create an example user/role called `demouser`,
9393

9494
```SQL
95-
postgres=> create role demouser with password 'password123';
95+
postgres=> CREATE USER demouser PASSWORD 'password123';
9696
```
9797
The **administrator role** should never be used by the application.
9898

99-
In cloud-based PaaS environments access to an Azure Database for PostgreSQL flexible server superuser account is restricted to control plane operations only by cloud operators. Therefore, the **azure_pg_admin** account exists as a pseudo-superuser account. Your administrator role is a member of the **azure_pg_admin** role.
100-
However, the server admin account is not part of the **azuresu** role, which has superuser privileges and is used to perform control pane operations. Since this service is a managed PaaS service, only Microsoft is part of the superuser role.
99+
In cloud-based PaaS environments access to an Azure Database for PostgreSQL - Flexible Server superuser account is restricted to control plane operations only by cloud operators. Therefore, the `azure_pg_admin` account exists as a pseudo-superuser account. Your administrator role is a member of the `azure_pg_admin` role.
100+
However, the server admin account is not part of the `azuresu` role, which has superuser privileges and is used to perform control plane operations. Since this service is a managed PaaS service, only Microsoft is part of the superuser role.
101101

102102
> [!NOTE]
103-
> Number of superuser only permissions , such as creation of certain [implicit casts](https://www.postgresql.org/docs/current/sql-createcast.html), are not available with Azure Database for PostgreSQL flexible server, since azure_pg_admin role doesn't align to permissions of postgresql superuser role.
103+
> Number of superuser only permissions, such as creation of certain [implicit casts](https://www.postgresql.org/docs/current/sql-createcast.html), are not available with Azure Database for PostgreSQL - Flexible Server, since `azure_pg_admin` role doesn't align to permissions of PostgreSQL superuser role.
104104
105105
You can periodically audit the list of roles in your server. For example, you can connect using `psql` client and query the `pg_roles` table which lists all the roles along with privileges such as create additional roles, create databases, replication etc.
106106

@@ -122,64 +122,50 @@ rolvaliduntil |
122122
rolbypassrls | f
123123
rolconfig |
124124
oid | 24827
125-
126-
127-
128125
```
129126

130-
[Audit logging](concepts-audit.md) is also available with Azure Database for PostgreSQL flexible server to track activity in your databases.
131-
132-
> [!NOTE]
133-
> Azure Database for PostgreSQL flexible server currently doesn't support [Microsoft Defender for Cloud protection](../../security-center/azure-defender.md).
134-
127+
[Audit logging](concepts-audit.md) is also available with Azure Database for PostgreSQL - Flexible Server to track activity in your databases.
135128

136129
### Controlling schema access
137130

138-
Newly created databases in Azure Database for PostgreSQL flexible server have a default set of privileges in the database's public schema that allow all database users and roles to create objects. To better limit application user access to the databases that you create on your Azure Database for PostgreSQL flexible server instance, we recommend that you consider revoking these default public privileges. After doing so, you can then grant specific privileges for database users on a more granular basis. For example:
131+
Newly created databases in Azure Database for PostgreSQL - Flexible Server have a default set of privileges in the database's public schema that allow all database users and roles to create objects. To better limit application user access to the databases that you create on your Azure Database for PostgreSQL - Flexible Server instance, we recommend that you consider revoking these default public privileges. After doing so, you can then grant specific privileges for database users on a more granular basis. For example:
139132

140-
* To prevent application database users from creating objects in the public schema, revoke create privileges to *public* schema
133+
* To prevent application database users from creating objects in the public schema, revoke create privileges to `public` schema from `public` role.
141134
```sql
142135
REVOKE CREATE ON SCHEMA public FROM PUBLIC;
143-
144136
```
145-
* Next, create new database:
146-
```sql
147-
CREATE DATABASE Test_db;
148-
149-
```
137+
* Next, create new database.
138+
```sql
139+
CREATE DATABASE Test_db;
140+
```
150141
* Revoke all privileges from the PUBLIC schema on this new database.
151-
```sql
152-
REVOKE ALL ON DATABASE Test_db FROM PUBLIC;
153-
154-
```
142+
```sql
143+
REVOKE ALL ON DATABASE Test_db FROM PUBLIC;
144+
```
155145
* Create custom role for application db users
156-
```sql
157-
CREATE ROLE Test_db_user;
158-
```
146+
```sql
147+
CREATE ROLE Test_db_user;
148+
```
159149
* Give database users with this role the ability to connect to the database.
160-
```sql
161-
GRANT CONNECT ON DATABASE Test_db TO Test_db_user;
162-
GRANT ALL PRIVILEGES ON DATABASE Test_db TO Test_db_user;
163-
164-
165-
```
150+
```sql
151+
GRANT CONNECT ON DATABASE Test_db TO Test_db_user;
152+
GRANT ALL PRIVILEGES ON DATABASE Test_db TO Test_db_user;
153+
```
166154
* Create database user
167-
```sql
168-
CREATE ROLE user1 LOGIN PASSWORD 'Password_to_change'
169-
```
155+
```sql
156+
CREATE USER user1 PASSWORD 'Password_to_change'
157+
```
170158
* Assign role, with its connect and select privileges to user
171-
```sql
172-
GRANT Test_db_user TO user1;
173-
174-
175-
```
159+
```sql
160+
GRANT Test_db_user TO user1;
161+
```
176162
In this example, user *user1* can connect and has all privileges in our test database *Test_db*, but not any other db on the server. It would be recommended further, instead of giving this user\role *ALL PRIVILEGES* on that database and its objects, to provide more selective permissions, such as *SELECT*,*INSERT*,*EXECUTE*, etc. For more information about privileges in PostgreSQL databases, see the [GRANT](https://www.postgresql.org/docs/current/sql-grant.html) and [REVOKE](https://www.postgresql.org/docs/current/sql-revoke.html) commands in the PostgreSQL docs.
177163

178164
## Row level security
179165

180-
[Row level security (RLS)](https://www.postgresql.org/docs/current/ddl-rowsecurity.html) is an Azure Database for PostgreSQL flexible server 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 an Azure Database for PostgreSQL flexible server 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.
166+
[Row level security (RLS)](https://www.postgresql.org/docs/current/ddl-rowsecurity.html) is an Azure Database for PostgreSQL - Flexible Server 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 an Azure Database for PostgreSQL - Flexible Server 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.
181167

182-
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.
168+
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.
183169

184170
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 the following example was shared in the [PostgreSQL documentation](https://www.postgresql.org/docs/current/ddl-rowsecurity.html).
185171

@@ -191,30 +177,31 @@ ALTER TABLE accounts ENABLE ROW LEVEL SECURITY;
191177
CREATE POLICY account_managers ON accounts TO managers
192178
USING (manager = current_user);
193179
```
194-
The USING clause implicitly adds a `WITH CHECK` clause, ensuring that members of the manager role cannot perform SELECT, DELETE, or UPDATE operations on rows that belong to other managers, and cannot INSERT new rows belonging to another manager.
180+
181+
The USING clause implicitly adds a `WITH CHECK` clause, ensuring that members of the manager role cannot perform `SELECT`, `DELETE`, or `UPDATE` operations on rows that belong to other managers, and cannot `INSERT` new rows belonging to another manager.
182+
195183
> [!NOTE]
196-
> In [PostgreSQL it is possible for a user to be assigned the *BYPASSRLS* attribute by another superuser](https://www.postgresql.org/docs/current/ddl-rowsecurity.html). With this permission, a user can bypass RLS for all tables in Postgres, as is superuser. That permission cannot be assigned in Azure Database for PostgreSQL flexible server, since administrator role has no superuser privileges, as common in cloud based PaaS PostgreSQL service.
184+
> In [PostgreSQL it is possible for a user to be assigned the `BYPASSRLS` attribute by another superuser](https://www.postgresql.org/docs/current/ddl-rowsecurity.html). With this permission, a user can bypass RLS for all tables in Postgres, as superuser. That permission cannot be assigned in Azure Database for PostgreSQL - Flexible Server, since administrator role has no superuser privileges, as common in cloud based PaaS PostgreSQL services.
197185
198186

199187
## Updating passwords
200188

201-
For better security, it is a good practice to periodically rotate your admin password and database user passwords. It is recommended to use strong passwords using upper and lower cases, numbers and special characters.
189+
For better security, it is a good practice to periodically rotate your admin password and database users passwords. It is recommended to use strong passwords using upper and lower cases, numbers and special characters.
202190

203191
## Using SCRAM
204192
The [Salted Challenge Response Authentication Mechanism (SCRAM)](https://datatracker.ietf.org/doc/html/rfc5802) greatly improves the security of password-based user authentication by adding several key security features that prevent rainbow-table attacks, man-in-the-middle attacks, and stored password attacks, while also adding support for multiple hashing algorithms and passwords that contain non-ASCII characters.
205-
If your [client driver supports SCRAM](https://wiki.postgresql.org/wiki/List_of_drivers) , you can **[setup access to Azure Database for PostgreSQL flexible server using SCRAM](./how-to-connect-scram.md)** as `scram-sha-256` vs. default `md5`.
193+
If your [client driver supports SCRAM](https://wiki.postgresql.org/wiki/List_of_drivers) , you can **[setup access to Azure Database for PostgreSQL - Flexible Server using SCRAM](./how-to-connect-scram.md)** as `scram-sha-256` vs. default `md5`.
206194

207195

208196
### Reset administrator password
209-
210197
Follow the [how to guide](./how-to-manage-server-portal.md#reset-admin-password) to reset the admin password.
211198

212199
### Update database user password
213-
214200
You can use client tools to update database user passwords.
215201
For example,
202+
216203
```SQL
217-
postgres=> alter role demouser with password 'Password123!';
204+
postgres=> ALTER ROLE demouser PASSWORD 'Password123!';
218205
ALTER ROLE
219206
```
220207
## Next steps

0 commit comments

Comments
 (0)