Eight essentials to make your account's security a priority

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.

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:

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.

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 permissions on these users.

You could increase or decrease a key's permissions without noticing it and break critical applications using programmatic access. Furthermore, whenever a user loses access to the Organization, all API keys attached to it will be revoked.

👉 What you can do
Use Applications to represent the identity of any program that need to perform actions using the Scaleway API. Applications have their own lifecycle that is manageable through the IAM section on the console and our devtools so that you can easily manage their access. Rotating an API key or managing the permissions attached to API keys is easy with applications.

5. Limit the use of your Owner account

An organization account is owned by the Owner account, in other words, the person who created the Organization. Owners have two specificities that make the use of their accounts very sensitive compared to other accounts:

• Owners do not receive their permissions through IAM policies like other users, but they have all permissions by default at the creation of the Organization. They can perform all actions on the Organization and these permissions are not revocable.
• Owner accounts can delete an Organization, and this permission cannot be given by any other permission set accessible through IAM.

With these two pieces of information in mind, it is easily understandable that the Owner's account is sensitive.

👉 What you can do
Only use Owner accounts for infrequent limited actions. Create and invite other users to perform actions in your Organization with more limited permissions. You can use groups and policies to define precisely the rights of any guest in the Organization.

6. Create new projects whenever resources need dedicated access

IAM enables you to set up access management at the project level and for each product (e.g. Instances, buckets, functions). For example, in each project, you can decide if a user can list certain products, create them, delete them. You can even decide to limit a user’s access to these products.

It has yet to be possible to grant different permissions for two occurrences of the same product in the same project. We advise you to create two distincts projects whenever you need to give different rights to different products rights.

Switching between projects is easy: you just have to select a new project from the console using the Project Switcher in the top left corner. With IAM, you now have the possibility to create a token with permissions on project management (ProjectManager permission set) and use it to create projects using the CLI, Terraform, or any of the SDKs supported by Scaleway.
Projects also have another benefit: they will give you a clearer view of your consumption on your invoice, depending on the project.

👉 What you can do
Leverage Project and IAM features to manage your access granularly and improve your Organization's security.

7. Renew API keys and user passwords regularly

The secret part of an API key should always be considered with the same level of sensitivity as a password, as it provided access to your Organization resources.

Both user passwords and secret keys should be renewed regularly to mitigate the impact in case of a security breach, whether it is an attack or an accident.

This is also applicable for API keys, for example, if they become available to attackers - by accident when uploading code on a remote repository or when people leave the company. We recommend you set up an expiration date on all API keys you generate, so they do not give perpetual access to your Organization. In the console, you can choose a timeframe, from one hour to one year or you can select a custom expiration date.

👉 What you can do
Renew these credentials every 3 to 6 months to prevent your accounts and tokens from being attacked - no matter the cloud providers or SaaS you use. You should put an expiration date on all API keys you generate.

8. Secure your account by using MFA

Multi-Factor Authentication (MFA) brings an additional layer of security to your account by forcing you to prove your identity using at least two different methods. Usually, these methods will rely on proof of ownership (for example, an email address or an account like GitHub or Google), the knowledge of a secret (password, private key) or biometric data.

Frequent password leaks are evidence that authentication relying only on passwords cannot be considered safe. Even if it is more secure to use a magic link and provide access to an email account, there are better options for high-security contexts.

👉 What you can do

Set up a second-factor authentication using a third-party application such as Authy or Google Authenticator, and make sure all users in your Organization do the same.

What’s next?

Going forward, Scaleway will keep working hard towards a safer platform, and deliver more access management features for our clients. For instance, you can expect news on bucket policies, enforcing MFA in an Organization, and access logs to be delivered this year - among other things! Keep an eye on the changelog to stay updated.