Skip to content

Commit f21086e

Browse files
staceysalamon-aivenstaceysalamon-aiven
committed
feat: add security checklist
1 parent 6d51e07 commit f21086e

File tree

5 files changed

+274
-88
lines changed

5 files changed

+274
-88
lines changed

‎docs/platform/concepts/application-users.md‎

Lines changed: 3 additions & 45 deletions
Original file line numberDiff line numberDiff line change
@@ -8,56 +8,14 @@ An application user is a type of user that provides programmatic access to the A
88

99
You must be an [organization admin](/docs/platform/concepts/permissions#organization-roles-and-permissions) to access this feature.
1010

11-
## Application user permissions
12-
1311
You [create and manage application users](/docs/platform/howto/manage-application-users)
1412
at the organization level and you
1513
[give them access to projects and services](/docs/platform/howto/manage-permissions)
1614
in the same way as organization users. You can also grant application users the
1715
organization admin role, giving them full access to your organization,
1816
its organizational units, projects, services, billing, and other settings.
1917

20-
Unlike organization users, application users can't log in to the Aiven Console and the
21-
authentication policies don't apply to them.
22-
23-
## Security best practices
24-
25-
Because application users can have the same level of access to projects and services it's
26-
important to secure these accounts and their tokens to avoid abuse. The
27-
following are some suggested best practices for using Aiven application users.
28-
29-
### Create dedicated application users for each application
30-
31-
Try to create a different application user for each tool or application. For example, if
32-
you have an application that needs to connect to services in one of your projects and
33-
you're using Aiven Terraform Provider in the same project, create two application users. Use
34-
the description field for each user to clearly indicate what it's used for.
35-
36-
This helps you manage the lifecycle of the users and ensure the access permissions are
37-
correct for each use case.
38-
39-
### Restrict access to trusted networks
40-
41-
Specify allowed IP address ranges for each token. This prevents tokens from being used
42-
outside of your trusted networks, reducing the risk of breaches. You can also specify
43-
these ranges in your organization's
44-
[authentication policy](/docs/platform/howto/set-authentication-policies), limiting
45-
all access to the Aiven Platform to these IP addresses, including
46-
through application tokens.
47-
48-
### Keep tokens secure and rotate them regularly
49-
50-
Make sure tokens are securely stored and only accessible by people who need them. Tokens
51-
should also be routinely [revoked](/docs/platform/howto/manage-application-users#revoke-a-token-for-an-application-user)
52-
and replaced with new tokens.
53-
54-
### Delete unused users and tokens
55-
56-
Regularly audit your list of application users to delete unused users. You can view a
57-
list of your organization's application users and the last time they were used in
58-
**Admin** > <ConsoleLabel name="Application users"/>. Click
59-
<ConsoleLabel name="actions"/> > <ConsoleLabel name="view app user profile"/>
60-
to see a user's tokens.
18+
Unlike organization users, application users can't log in to the Aiven Console.
6119

62-
You can [delete unused users](/docs/platform/howto/manage-application-users#delete-an-application-user)
63-
and [revoke specific tokens](/docs/platform/howto/manage-application-users#revoke-a-token-for-an-application-user).
20+
Follow the [security best practices for application users]
21+
to keep these account secure.

‎docs/platform/howto/list-identity-providers.md‎

Lines changed: 9 additions & 43 deletions
Original file line numberDiff line numberDiff line change
@@ -1,11 +1,12 @@
11
---
2-
title: SAML identity providers and verified domains
2+
title: Identity providers and SAML authentication
33
sidebar_label: Identity providers
44
---
55

66
Set up single sign-on (SSO) access to Aiven through a Security Assertion Markup Language (SAML) compliant identity provider (IdP). This lets you centrally manage your users in your IdP while giving them a seamless login experience.
77

8-
Every IdP must be linked to a domain in Aiven. After you
8+
Every IdP must be linked to a domain in Aiven and you can link each verified domain to
9+
only one IdP. After you
910
[verify that you own a domain](/docs/platform/howto/manage-domains), the users in your
1011
organization become managed users, which provides a higher level of security for your
1112
organization by controlling things like
@@ -15,48 +16,13 @@ With a verified domain you can add an IdP. All users with an email address from
1516
the verified domain are automatically authenticated with the linked IdP. With
1617
IdP-initiated SSO enabled, users can log in to Aiven directly from the IdP.
1718

18-
Aiven also supports System for Cross-domain Identity Management (SCIM) for Okta to automatically
19-
provision, update, and deactivate user identities from your IdP.
19+
Aiven also supports System for Cross-domain Identity Management (SCIM) for Okta to
20+
automatically provision, update, and deactivate user identities from your IdP.
2021
With automatic provisioning you don’t need to manually create organization users.
21-
2222
When adding an IdP you link it to the verified domain
23-
and can set up SCIM at the same time.
24-
25-
## Limitations
26-
27-
You can link each verified domain to only one IdP. If you set up user provisioning with
23+
and can set up SCIM at the same time. If you set up user provisioning with
2824
SCIM, you should only make changes to user details in the IdP.
2925

30-
## Security best practices
31-
32-
It’s recommended to verify your domains in Aiven even if you don’t use SSO. When
33-
configuring an IdP it's best to enable the following SAML security settings:
34-
35-
- **Require assertion to be signed**: Verifies assertions were issued by a trusted party
36-
and have not been tampered with.
37-
- **Sign authorization request sent to IdP**: Ensures authenticity and integrity with a
38-
digital signature.
39-
40-
The [authentication policy](/docs/platform/howto/set-authentication-policies) for the
41-
organization is also an important component in securing access through an IdP. At a
42-
minimum, use these settings for your authentication policy:
43-
44-
- Don't allow password authentication
45-
- Require log in with this organization's identity provider
46-
47-
To limit access further, also consider these authentication policy settings:
48-
49-
- **Don't allow third-party authentication**: This combined with the preceding password and
50-
organization identity provider settings ensures that users only log in to the Console
51-
with your chosen IdP.
52-
- **Don't allow users to create personal tokens**: This prevents users from accessing
53-
organization resources through the API using a long-lived
54-
[personal token](/docs/platform/concepts/authentication-tokens) they created.
55-
56-
If you allow your users to create personal tokens, you can still make these more
57-
secure by enabling **Require users to be logged in with an allowed
58-
authentication method**. This means that users cannot access your organization's
59-
resources with a token they created when logged in with another organization's
60-
allowed authentication methods or a previously allowed method.
61-
This setting also gives you the flexibility to change the authentication policy at any
62-
time because tokens that are no longer compliant with the new policy cannot be used.
26+
See the [security checklist](/docs/platform/reference/security-best-practices#add-an-identity-provider)
27+
for best practices for configuring your identity providers and
28+
organization authentication policy.

‎docs/platform/howto/manage-application-users.md‎

Lines changed: 9 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -72,6 +72,15 @@ More information on this resource and its configuration options are available in
7272
</TabItem>
7373
</Tabs>
7474

75+
## View application users and tokens
76+
77+
To view your organization's application users and the last time they
78+
were used:
79+
80+
1. In your organization, click **Admin**.
81+
1. Click <ConsoleLabel name="Application users"/>.
82+
1. Click the name of an application user to view its profile, tokens, and groups.
83+
7584
## Revoke a token for an application user
7685

7786
1. Click **Admin** > <ConsoleLabel name="application users"/>.

‎docs/platform/reference/security-best-practices.md‎

Lines changed: 252 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,252 @@
1+
---
2+
title: Security checklist
3+
---
4+
5+
import ConsoleLabel from "@site/src/components/ConsoleIcons";
6+
7+
The Aiven Platform offers security features to help you protect your data and resources. Security needs vary based on organization, but the following are best practices you can use to make the best use of these features and increase your security posture.
8+
9+
- [Verify a domain](#verify-a-domain)
10+
- [Add an identity provider](#add-an-identity-provider)
11+
- [Configure your authentication policy](#configure-your-authentication-policy)
12+
- [Use units and projects to separate concerns](#use-units-and-projects-to-separate-concerns)
13+
- [Grant least-privilege access to users](#grant-least-privilege-access-to-users)
14+
- [Limit the number of admin](#limit-the-number-of-admin)
15+
- [Use groups](#use-groups)
16+
- [Examples](#examples)
17+
- [Create application users for automated access](#create-application-users-for-automated-access)
18+
- [Create dedicated application users for each application](#create-dedicated-application-users-for-each-application)
19+
- [Restrict access to trusted networks](#restrict-access-to-trusted-networks)
20+
- [Keep tokens secure and rotate them regularly](#keep-tokens-secure-and-rotate-them-regularly)
21+
- [Delete unused users and tokens](#delete-unused-users-and-tokens)
22+
- [Create virtual private clouds](#create-virtual-private-clouds)
23+
- [Employ a multi-cloud, geographically distributed strategy](#employ-a-multi-cloud-geographically-distributed-strategy)
24+
- [Keep services up-to-date](#keep-services-up-to-date)
25+
- [Use enhanced compliance environments](#use-enhanced-compliance-environments)
26+
27+
## Verify a domain
28+
29+
To make your organization users managed users and to set up single sign-on through
30+
an identity provider, verify your organization's domain. Even if you
31+
don't use an identity provider for logins, verifying your domain helps to
32+
secure you organization on the Aiven Platform.
33+
34+
- [Verify your domain](/docs/platform/howto/manage-domains)
35+
- [Learn about managed users](/docs/platform/concepts/managed-users)
36+
37+
## Add an identity provider
38+
39+
Use SAML federation for regular access to the Aiven Platform through an
40+
identity provider (IdP). IdPs let you centralize identity management for multiple
41+
platforms, give your organization users access through single sign-on (SSO), and
42+
help to reduce the risk of credential exposure. This can reduce administrative
43+
overhead and improve the user experience. Many IdPs also have additional
44+
security features like multi-factor authentication and auditing.
45+
46+
All users with an email address from a verified domain
47+
linked to your IdP can sign up and log in to the Aiven Platform without the need
48+
for your admin to create individual user accounts. Use the strongest
49+
cryptographic signature method supported by the provider.
50+
51+
When configuring an IdP it's best to enable the following SAML security settings:
52+
53+
- **Require assertion to be signed**: Verifies assertions were issued by a trusted party
54+
and have not been tampered with.
55+
- **Sign authorization request sent to IdP**: Ensures authenticity and integrity with a
56+
digital signature.
57+
58+
The [authentication policy](#configure-your-authentication-policy) for the
59+
organization is also an important component in securing access through an IdP.
60+
61+
- [Add an identity provider](/docs/platform/howto/saml/add-identity-providers)
62+
- [Configure your IdP following security best practices](/docs/platform/howto/list-identity-providers#security-best-practices)
63+
64+
## Configure your authentication policy
65+
66+
Set a policy that allows your organization users to access your organization on
67+
the Aiven Platform only through approved methods.
68+
69+
For a greater level of security, only allow users to log in with your identity provider
70+
and select the **require log in with an identity provider** option. If you do allow
71+
password authentication, enforce two-factor authentication for all users.
72+
73+
Don't allow users to create personal tokens. If you decide to allow your users to
74+
create personal tokens, you can still make these more secure by enabling the
75+
**require log in with this organization's identity provider** setting.
76+
This means that users cannot access your organization's resources with a token they
77+
created when logged in with another organization's allowed authentication methods
78+
or a previously allowed method. This setting also gives you the flexibility to change
79+
the authentication policy at any time because tokens that are no longer compliant
80+
with the new policy cannot be used.
81+
82+
A more secure way to centrally manage access through tokens is to create
83+
[application users and application tokens](#create-application-users-for-automated-access).
84+
85+
- [Set an organization authentication policy](/docs/platform/howto/set-authentication-policies)
86+
87+
## Use units and projects to separate concerns
88+
89+
Avoid creating projects directly in the organization. Instead, create organizational
90+
units to separate your projects, and use projects to further divide your services.
91+
To support the principle of least privilege and to enable appropriate configuration
92+
baselines, create unrelated services in different projects.
93+
For example, put an OLTP database for order tracking and a time-series database
94+
for website analytics in separate projects.
95+
96+
- [Learn about units and projects](/docs/platform/concepts/orgs-units-projects)
97+
98+
## Grant least-privilege access to users
99+
100+
Use granular permissions and roles to grant the lowest level of access needed to
101+
users and groups at the appropriate level.
102+
[Roles and permissions](/docs/platform/concepts/permissions) are available
103+
at the organization, unit, and project level. This is where
104+
[using projects and units to separate services](#use-units-and-projects-to-separate-concerns)
105+
makes it easier to manage access.
106+
107+
At the service level, don't use the `avnadmin` service user for normal operations.
108+
This user is intended for provisioning and recovery. Instead, create lower-privileged
109+
service users within the service that have only the necessary permissions.
110+
Additionally, users who only need to access services may not need to have
111+
Aiven user accounts. For example ,a database administrator (DBA) who is configuring
112+
a PostgreSQL service for an application might not need access to the Aiven Console.
113+
You can create service users for these types of users and give them the connection string
114+
and credentials for only that specific service.
115+
116+
### Limit the number of admin
117+
118+
Limit the number of organization admin and project admin. Grant the organization admin
119+
to a limited number of users in the organization. Instead, assign specific permissions
120+
at the organization level such as the **manage groups** or **manage projects** permissions.
121+
122+
Most importantly, minimize the number of
123+
[super admin](/docs/platform/howto/manage-permissions#make-users-super-admin)
124+
in your organization. Reserve super admin for emergency access when no other users have
125+
enough permissions. Don't use super admin for normal operational tasks.
126+
For user accounts with super admin access follow these best practices to secure them:
127+
128+
- **Store passwords offline**: Store printed passwords in a secure location that requires
129+
two-party control for access.
130+
- **Enable two-factor authentication** and store the credentials offline.
131+
- **Re-generate credentials after use**: If a super admin account is used, change its
132+
password.
133+
- **Restrict access to the email associated with a super admin user**: A user with
134+
access to this email address can reset its password.
135+
- **Use different emails for notifications**: Configure an email address not associated
136+
with a super admin account for billing, project, service, and other system notifications.
137+
138+
### Use groups
139+
140+
Use groups to streamline and increase the visibility of the process of granting access
141+
to users. If you choose to automatically add users to a group when they sign up,
142+
make sure the group has minimal permissions. Only grant users permissions to projects
143+
that have a business need to access them.
144+
145+
### Examples
146+
The following are examples of typical user types along with the roles and permissions they
147+
need.
148+
149+
**Finance team members**
150+
151+
Users on this team often only need to view and download invoices. Grant these users
152+
the **view billing** permission. If they need to edit billing details, grant them
153+
the **manage billing** permission.
154+
155+
**Auditors**
156+
157+
Grant these users the **read only** role in the projects relevant for their work.
158+
159+
**Database administrators**
160+
161+
For users like database administrators, who use the Aiven Console or API to
162+
configure services, but don't need to create them or power them off, grant them
163+
the **developer** role in the relevant projects.
164+
165+
**DevOps**
166+
167+
For users who maintain services to keep them updated and set the maintenance window to
168+
avoid downtime, grant the **maintain services** permission. If they also need to be
169+
able to help restore a service after an incident, grant them the **recover services**
170+
permission.
171+
172+
- [Roles and permissions](/docs/platform/concepts/permissions)
173+
- [Manage permissions for users and groups](/docs/platform/howto/manage-permissions)
174+
175+
## Create application users for automated access
176+
177+
Because application users can have the same level of access to projects and services it's
178+
important to secure these accounts and their tokens to avoid abuse.
179+
180+
### Create dedicated application users for each application
181+
182+
Create a different application user for each tool or application and generate
183+
application tokens for each. For example, if you have an application that needs to
184+
connect to services in one of your projects and you're using Aiven Terraform Provider
185+
in the same project, create two application users. Use the description field for
186+
each user to clearly indicate what it's used for.
187+
188+
This helps you manage the lifecycle of the users and ensure the access permissions are
189+
correct for each use case.
190+
191+
### Restrict access to trusted networks
192+
193+
Specify allowed IP address ranges for each token. This prevents tokens from being used
194+
outside of your trusted networks, reducing the risk of breaches. You can also specify
195+
these ranges in your organization's
196+
[authentication policy](#configure-your-authentication-policy), limiting
197+
all access to the Aiven Platform to these IP addresses, including
198+
through application tokens.
199+
200+
### Keep tokens secure and rotate them regularly
201+
202+
Make sure application tokens are securely stored and only accessible by people
203+
who need them. Tokens should also be routinely
204+
[revoked](/docs/platform/howto/manage-application-users#revoke-a-token-for-an-application-user)
205+
and replaced with new tokens.
206+
207+
### Delete unused users and tokens
208+
209+
Regularly audit your list of application users to identify unused users. You can
210+
view all application users, get details about when their tokens were last used,
211+
and delete unused users in the Aiven Console and API.
212+
213+
- [Manage application users and tokens](/docs/platform/howto/manage-application-users)
214+
215+
## Create virtual private clouds
216+
217+
Many security compliance standards such as PCI DSS require that databases
218+
not be reachable over the internet. Place services that don't need to be accessible
219+
from the internet within a Virtual private cloud (VPC) in a supported cloud.
220+
Peer the VPC with your cloud account at the relevant provider.
221+
Route non-cloud resources through the provider.
222+
223+
Alternatively, you can create custom clouds using Aiven's bring your own cloud (BYOC)
224+
feature to configure your infrastructure to meet your specific business requirements.
225+
226+
- [Learn more about VPCs](/docs/platform/concepts/vpcs)
227+
- [Learn about BYOC](/docs/platform/concepts/byoc)
228+
229+
## Employ a multi-cloud, geographically distributed strategy
230+
231+
For mission-critical services, deploy read-only replicas or standbys in different cloud
232+
providers and regions. For example, for a primary service hosted on AWS in the
233+
`us-west-2` region, create a standby on Azure in `eastus2`.
234+
235+
## Keep services up-to-date
236+
237+
When a new major version of a service becomes available, upgrade to it as soon as possible.
238+
Don't continue to use end-of-life versions or discontinued services.
239+
240+
Don't avoid or delay maintenance and updates. Set maintenance windows during periods of
241+
low activity or low business criticality. Stagger the maintenance windows for
242+
redundant services.
243+
244+
- [Learn about maintenance, updates, and upgrades](/docs/platform/concepts/maintenance-window)
245+
246+
## Use enhanced compliance environments
247+
248+
If your environment is subject to a security compliance standards like PCI DSS or HIPAA,
249+
Aiven can help you set up projects as enhanced compliance environments (ECE) so that
250+
they meet these standards.
251+
252+
- [Learn about ECEs](/docs/platform/concepts/enhanced-compliance-env)

0 commit comments

Comments
 (0)