Eight essentials to make your account's security a priority

Eight essentials to make your account's security a priority Build • Cyril Petel • 12/01/23 • 9 min read

Security is and will always be a two-way street: it requires effort from both the user and the platform. At Scaleway, your organization account's security remains our top priority. As a result, we are continuously deploying new features to make sure we stay true to our words.

Recently, we added the reset of users' passwords after a certain period of inactivity or we made the authentication by magic link mandatory, as soon as we have a doubt about the number of login attempts.

In the same vein, we launched Identity and Access Management (IAM) in December. IAM is a new system designed to improve security features. In this blogpost, we wanted to share with you eight good practices that will improve the security of your Scaleway Organization's.

But first: what is IAM?

IAM stands for "Identity and Access Management” and refers to the system that controls and manages access to resources within the cloud environment.

IAM allows an Organization to securely control who has access to its resources and what actions those users can perform. This can include:

managing user accounts,

creating groups to manage multiple users at the same time,

assigning policies to users or applications to give them permissions on resources.

IAM is an important component of any cloud infrastructure, as it ensures that only authorized users can access and modify the Organization's resources. As a result, it prevents unauthorized access and potential security breaches.

Let’s dive into good practices to secure your account!

1. Activate IAM now

Before IAM, only three roles were available for users: Admin, Editor and Billing Admin, and API Keys were used to give all the permissions in a project.

With IAM, you get to define who can access which product in your Organization based on the roles and responsibilities of everyone, for both users and applications.

IAM_Scaleway.webp

Migrating to IAM has nothing but advantages. While your current users’ and applications’ rights will remain unchanged by default, you can quickly increase or narrow down their access to your products within your Organization.

We updated our platforms to support your onboarding on IAM and make it as smooth as possible: the console experience , our documentation , and our developer's website are available to ease your onboarding. In addition, if you are looking for in-depth information about IAM, you can learn in our documentation what IAM is and learn more about the terminology .

Please also note that all Organizations will be migrated to the IAM system in February. This operation won’t impact your current usage of our services. Even if you decide not to use IAM features after the migration, you can still keep using Scaleway products the way you always have.

👉 What you can do

Activate IAM before the automatic migration right here in your console .

2. Switch from legacy roles to your policies

Moving out of legacy roles to implement your own policies will only apply to Organizations created before December 5, 2022.

Groups, policies rules and applications have been created during the migration, and they can now be precisely configured using IAM. Here is how API keys and users have been migrated during IAM activation:

API Key's evolution with IAM.webp

Since the default legacy setup is probably not the most appropriate one for you, we encourage you to change these settings . For example, you will probably not use all Scaleway products in your organization, so API keys do not need permissions on each of them.

User roles evolution with IAM

As IAM allows your Organization owner or anyone with IAM permissions to manage access rules precisely, we recommend you create a setup based on your users' needs and usage of your Scaleway Organization, using the least privilege principle explained right after.

👉 What you can do

Assess how your users are using their various resources and create custom policies based on their needs.

3. Apply the “least privilege” principle

The principle of least privilege is a core security concept that states that a user should only have access to the exact resources needed to function - not more, not less.

For each application and user you create, you can ask yourself the following questions: what access do they need? Should this user or application access billing operations? Should they access important information about the Organization? Should they be able to give permission to other users?

What should they not be able to do? Should they only be able to list and see the products? Is there a need to be able to create, edit or delete resources?

The answers to these questions will help you define the minimum rights to grant.

For example:

An accountant in the company might need access to Billing information and consumption. In some cases, the need to list resources can be legitimate. But you should not give any write permission (provided by the suffix FullAccess in permission sets) for any product.

A developer should have access to create, edit and delete all resources whenever used for development. But resources used for your production should not be editable - even not visible in some cases - by any developer without Operation responsibilities.

If your Organization does not consume all products, we don’t recommend putting the AllProductsFullAccess permissions set in your policy. Instead, only select permission applicable to products you currently use when building policies.

👉 What you can do

Ensure that your access is always at the most restricted level possible based on the real needs of each user or application.

4. API keys on users for development, applications for production

Two types of identities can access your Scaleway Organization: Users and Applications .

Users are humans with console access, while applications represent the identity of scripts, providers, or agents. They are identities used to attach API keys and give them dedicated rights through policies.

Usually, user accounts are linked to engineers, auditors, FinOps specialists, or any other employee or third-party partner that needs access to your Organization. Over time, the level of access to the resources of those people will evolve or will need to be shut down. Those evolutions can threaten your infrastructure: their API keys will be impacted whenever you change the…