Skip to content

Commit f3a1589

Browse files
feat: add security checklist
1 parent 6d51e07 commit f3a1589

File tree

9 files changed

+311
-127
lines changed

9 files changed

+311
-127
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/concepts/orgs-units-projects.md

Lines changed: 5 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -89,6 +89,11 @@ the project. The following are some examples of how customers organize their ser
8989

9090
## Best practices for organizations
9191

92+
The following are recommendations for organizing your resources in the Aiven Platform
93+
using organizations, organizational units, and projects. Read the
94+
[security checklist](/docs/platform/reference/security-best-practices) for more
95+
information on best practices for securing your organization using Aiven features.
96+
9297
### Small organizations
9398

9499
For smaller organizations that have a limited number of projects and services,
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: 10 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -16,7 +16,7 @@ to access this feature.
1616

1717
:::important
1818
Application users can be a security risk if not carefully managed and monitored. Follow
19-
[best practices](/docs/platform/concepts/application-users#security-best-practices) for
19+
[best practices](/docs/platform/reference/security-best-practices) for
2020
mitigating these risks.
2121
:::
2222

@@ -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/howto/unsafe-passwords.md

Lines changed: 6 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -2,6 +2,8 @@
22
title: Change unsafe passwords
33
---
44

5+
import RelatedPages from "@site/src/components/RelatedPages";
6+
57
The Aiven Platform checks your email and password combination against a database of exposed credentials every time you log in and change your password.
68

79
If Aiven detects an unsafe password, your login is blocked until you
@@ -12,3 +14,7 @@ You don't need to do anything else, but Aiven recommends every user
1214
[enable two-factor authentication](/docs/platform/howto/user-2fa).
1315
Two-factor authentication also needs to be re-enabled after you
1416
reset or change your password.
17+
18+
<RelatedPages/>
19+
20+
* Get tips for creating secure passwords in the [security checklist](/docs/platform/reference/security-best-practices)

docs/platform/reference/password-policy.md

Lines changed: 0 additions & 37 deletions
This file was deleted.

0 commit comments

Comments
 (0)