Skip to main content

Security best practices

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 use of these features and improve your security posture.

Verify a domain​

To make your organization users managed users and to set up single sign-on through an identity provider (IdP), verify your organization's domain. Even if you don't use an IdP for logins, verifying your domain helps to secure you organization on the Aiven Platform.

Related pages:

Add an identity provider​

Use SAML federation for regular access to the Aiven Platform through an IdP. IdPs let you centralize identity management for multiple platforms, give your organization users access through single sign-on (SSO), and help to reduce the risk of credential exposure. Many IdPs also have additional security features like multi-factor authentication and auditing.

All users with an email address from a verified domain linked to your IdP can sign up and log in to the Aiven Platform without the need for your admin to create individual user accounts. Use the strongest cryptographic signature method supported by the provider.

When configuring an IdP it's best to enable the Sign authorization request sent to IdP security setting. This ensures authenticity and integrity with a digital signature.

The authentication policy for your organization is also an important component in securing access through an IdP.

Related pages:

Configure your authentication policy​

Set a policy that allows organization users to access your organization on the Aiven Platform only through approved methods.

For a greater level of security, only allow users to log in with your Idp and select the require log in with an identity provider option. If you do allow password authentication, enforce two-factor authentication for all users.

Don't allow users to create personal tokens. If you decide to allow your users to create personal tokens, you can still make these more secure by enabling the require log in with this organization's identity provider setting. This means that users cannot access your organization's resources with a token they created when logged in with another organization's allowed authentication methods or a previously allowed method. This setting also gives you the flexibility to change the authentication policy at any time because tokens that are no longer compliant with the new policy cannot be used.

A more secure way to centrally manage access through tokens is to create application users and application tokens.

Related pages:

Password requirements​

Aiven enforces the following rules for password strength:

  • Minimum length is 8 characters
  • Cannot contain single repeating characters such as aaaaaaaa
  • Cannot contain your name or email address
  • Cannot contain common words, phrases, or strings such as password, security, or common names
  • Cannot contain words that are very similar to common words such as password1

These rules are also used for service integration passwords. For remote external integrations these rules are not enforced, but they are recommended.

Create secure password​

If you use password authentication, follow these guidelines to create secure passwords:

  • Use a password manager to create a randomly generated strong passwords.
  • Use passphrases as these are harder to guess.
  • Always use a unique password for every service and app.

Use units and projects to separate concerns​

Avoid creating projects directly in the organization. Instead, create organizational units to separate your projects, and use projects to further divide your services. To support the principle of least privilege and to enable appropriate configuration baselines, create unrelated services in different projects. For example, put an OLTP database for order tracking and a time-series database for website analytics in separate projects.

Related pages:

Use groups​

Use groups to streamline and increase the visibility of the process of granting access to users. If you choose to automatically add users to a group when they sign up, make sure the group has minimal permissions. Only grant users permissions to projects that they have a business need for.

Grant least-privilege access to users​

Use granular permissions and roles to grant the lowest level of access needed to users and groups at the appropriate level. Roles and permissions are available at the organization, unit, and project level. This is where using projects and units to separate services makes it easier to manage access.

At the service level, don't use the avnadmin service user for normal operations. This user is intended for provisioning and recovery. Instead, create lower-privileged service users within the service that have only the necessary permissions. Additionally, users who only need to access services may not need to have Aiven user accounts. For example, a database administrator (DBA) who is configuring a PostgreSQL service for an application might not need access to the Aiven Platform. You can create service users for these types of users and give them the connection string and credentials for only that specific service.

For Runtime applications, you can restrict access to the app by adding an authentication method to it.

Related pages:

Limit the number of admin​

Grant the organization admin roleto a limited number of users in the organization. Instead, assign specific permissions at the organization level such as the organization:billing:write permission to manage billing and payments.

Most importantly, minimize the number of super admin in your organization. Reserve super admin for emergency access when no other users have enough permissions. Don't use super admin for normal operational tasks. For user accounts with super admin access follow these best practices to secure them:

  • Enable two-factor authentication and require it as part of your organization's authenticaiton policy.
  • Re-generate credentials after use. If a super admin account is used, change its password.
  • Restrict access to the email associated with a super admin user.
  • Configure an email address not associated with a super admin account for billing, project, service, and other system notifications.

Examples​

The following are examples of typical user types along with the roles and permissions they need.

Finance team members

Users on this team often only need to view and download invoices. Grant these users the organization:billing:read permission. If they need to edit billing details, grant them the organization:billing:write permission.

Auditors

Grant these users the read only role in the projects relevant for their work.

Database administrators

For users like database administrators, who use the Aiven Console or API to configure services, but don't need to create them or power them off, grant them the service:configuration:write role in the relevant projects.

DevOps

For users who maintain service updates and maintenance windows, grant the role:services:maintenance role. If they also need to be able to help restore a service after an incident, grant them the role:services:recover permission.

Related pages:

Create application users for automated access​

Application users are non-human users intended for programmatic and automated access to the platform. Because application users are granted access to projects and services, it's important to secure these accounts and their tokens to avoid abuse.

Create dedicated application users for each tool​

Create a different application user for each tool and generate application tokens for each. For example, if you have a tool that needs to connect to services in one of your projects and you're also using Aiven Terraform Provider in the same project, create two application users. Use the description field for each user to clearly indicate what it's used for.

This helps you manage the lifecycle of the users and ensure the access permissions are correct for each use case.

Restrict access to trusted networks​

Specify allowed IP address ranges for each token. This prevents tokens from being used outside of your trusted networks, reducing the risk of breaches. You can also specify these ranges in your organization's authentication policy, limiting all access to the Aiven Platform to these IP addresses.

Keep tokens secure and rotate them regularly​

Make sure application tokens are securely stored and only accessible by people who need them. Tokens should also be routinely revoked and replaced with new tokens.

Delete unused users and tokens​

Regularly audit your list of application users to identify unused users. You can view all application users, get details about when their tokens were last used, and delete unused users in the Aiven Console and API.

Related pages:

Give AI agents read only access​

When using the Aiven MCP, restrict access to viewing resources using the read-only mode. For greater security, enable this as an organization policy. You can also limit tools to specific services.

Related pages:

Create virtual private clouds​

Many security compliance standards such as PCI DSS require that databases not be reachable over the internet. Place services that don't need to be accessible from the internet within a Virtual private cloud (VPC) in a supported cloud. Peer the VPC with your cloud account at the relevant provider. Route non-cloud resources through the provider.

Alternatively, you can create custom clouds using Aiven's bring your own cloud (BYOC) feature to configure your infrastructure to meet your specific business requirements.

Related pages:

Employ a multi-cloud, geographically distributed strategy​

For critical services, deploy read-only replicas or standbys in different cloud providers and regions. For example, for a primary service hosted on AWS in the us-west-2 region, create a standby on Azure in eastus2.

Keep services up-to-date​

When a new major version of a service becomes available, upgrade to it as soon as possible. Don't continue to use end-of-life versions or discontinued services.

Don't avoid or delay maintenance and updates. Set maintenance windows during periods of low activity or low business criticality. Stagger the maintenance windows for redundant services.

Related pages:

Use enhanced compliance environments​

If your environment is subject to a security compliance standards like PCI DSS or HIPAA, Aiven can help you set up projects as enhanced compliance environments (ECE) so that they meet these standards.

Related pages: