How to mitigate unauthorized access risks from credential leaks - Object Storage Service

Si les paires AccessKey des utilisateurs individuels ou professionnels sont divulguées, des personnes non autorisées peuvent effectuer des opérations sur les ressources Object Storage Service (OSS). Cela compromet la sécurité des données. Pour résoudre ce problème, OSS propose des bonnes pratiques visant à garantir la sécurité des données.

Important

Les bonnes pratiques ci-dessous constituent des mesures de sécurité générales et ne représentent pas des solutions de sécurité exhaustives. Elles sont fournies à titre indicatif et peuvent ne pas convenir à vos scénarios métier. Nous vous recommandons de rester vigilant face aux menaces pesant sur la sécurité des données et de prendre les mesures préventives nécessaires.

Définissez l'ACL de vos buckets ou objets sur private

Ne définissez pas la liste de contrôle d'accès (ACL) de vos buckets ou objets sur public-read ou public-read-write, sauf si votre activité exige que tous les utilisateurs, y compris les utilisateurs anonymes, puissent lire et écrire des données dans vos ressources OSS. Par exemple, si vous définissez l'ACL d'un bucket sur public-read ou public-read-write, les modifications suivantes s'appliquent :

public-read-write : Tous les utilisateurs, y compris les utilisateurs anonymes, peuvent lire et écrire des données dans les objets du bucket.

Avertissement
Tous les internautes peuvent accéder aux objets du bucket et y écrire des données. Cela peut entraîner des fuites de données et des frais imprévus élevés. Si un utilisateur écrit des données ou des informations interdites dans les objets du bucket, vos intérêts et droits légitimes peuvent être violés. Nous vous recommandons de ne pas définir l'ACL du bucket sur public-read-write, sauf en cas de nécessité absolue.
public-read : Seul le propriétaire du bucket peut écrire des données dans les objets du bucket. Les autres utilisateurs, y compris les utilisateurs anonymes, peuvent lire les données des objets du bucket.

Avertissement
Tous les internautes peuvent accéder aux objets du bucket. Cela peut entraîner des fuites de données et des frais imprévus élevés. Faites preuve de prudence lorsque vous définissez l'ACL du bucket sur public-read.

Remarque

Si une AccessKey pair est divulguée, l'attaquant dispose des identifiants valides du propriétaire. Même si l'ACL d'un bucket est définie sur public-read, l'attaquant peut utiliser la AccessKey pair divulguée pour appeler DeleteObject et supprimer des objets du bucket. Une ACL public-read contrôle uniquement l'accès des utilisateurs anonymes et ne restreint pas les opérations effectuées par les utilisateurs authentifiés disposant d'une AccessKey pair valide. En cas de divulgation d'une AccessKey pair, désactivez immédiatement la AccessKey pair compromise et vérifiez les journaux de modification des ressources de votre bucket.

Un bucket ou un objet autorisant l'accès public-read ou public-read-write peut entraîner des violations de données. Nous vous recommandons donc de définir l'ACL de l'objet ou du bucket sur private. Si vous définissez l'ACL du bucket sur private, seul le propriétaire du bucket peut lire et écrire des données dans les objets du bucket. Avant de modifier l'ACL de l'objet ou du bucket pour la définir sur private, assurez-vous que cette modification n'affecte pas votre activité.

Plusieurs méthodes permettent de définir l'ACL de l'objet ou du bucket sur private. Pour plus d'informations, consultez les rubriques ACL des buckets et Configurer l'ACL des objets.

N'incluez pas de paires AccessKey en clair dans le code et ne stockez pas localement de paires AccessKey chiffrées

Les paires AccessKey en clair présentes dans le code peuvent être divulguées avec celui-ci. Les paires AccessKey chiffrées et stockées localement ne sont pas non plus sécurisées, car le contenu chiffré et déchiffré est stocké en mémoire et les données en mémoire peuvent être enregistrées sur un autre appareil. Les applications mobiles et les applications informatiques sont exposées à ces risques. Pour obtenir les données déchiffrées, il suffit aux attaquants d'utiliser des technologies telles que l'injection, le hooking d'API et le débogage dynamique.

Pour éviter d'inclure des paires AccessKey en clair dans le code, utilisez des plug-ins de gestion des secrets pour les SDK Alibaba Cloud sur le serveur. Cette approche empêche la divulgation des paires AccessKey avec le code source ou le code compilé. Pour plus d'informations sur les plug-ins de gestion des secrets pour les SDK Alibaba Cloud, consultez la rubrique Plug-in de gestion des secrets pour les SDK Alibaba Cloud.

Important

Cette méthode ne s'applique pas aux clients. N'intégrez pas de paires AccessKey dans les clients.

Accédez à OSS via un utilisateur RAM

La paire AccessKey d'un compte Alibaba Cloud dispose d'autorisations sur toutes les opérations API. L'utilisation de ces identifiants pour effectuer des opérations dans OSS présente un risque élevé. Nous vous recommandons d'utiliser un utilisateur RAM pour appeler les opérations API ou effectuer les tâches d'exploitation et de maintenance courantes.

Créez des utilisateurs RAM et attribuez-leur différentes autorisations afin de gérer l'accès à vos ressources. RAM vous aide à garder strictement confidentiels votre compte Alibaba Cloud et votre mot de passe dans les scénarios où plusieurs utilisateurs de votre entreprise doivent gérer conjointement les ressources cloud. Il vous permet également d'accorder aux utilisateurs les autorisations minimales requises pour garantir la sécurité des données. Pour plus d'informations, consultez la rubrique Créer un utilisateur RAM.

Après avoir créé un utilisateur RAM, accordez-lui des autorisations via une stratégie RAM. Vous pouvez ainsi gérer vos utilisateurs, tels que les employés, les systèmes et les applications, ainsi que les ressources auxquelles ils peuvent accéder. Par exemple, vous pouvez utiliser la stratégie RAM suivante pour empêcher certains utilisateurs RAM d'accéder à un bucket nommé examplebucket et aux objets ou répertoires qu'il contient.

{
    "Version": "1",
    "Statement": [
        {
            "Effect": "Deny",
            "Action": "oss:*",
            "Resource": [
                "acs:oss:*:*:examplebucket",
                "acs:oss:*:*:examplebucket/*"
            ]
        }
    ]
}

Vous pouvez également utiliser des stratégies RAM pour empêcher les utilisateurs RAM de supprimer un répertoire dans un bucket ou pour autoriser les utilisateurs RAM à lire uniquement les ressources d'un bucket. Pour plus d'informations, consultez la rubrique Exemples courants de stratégies RAM.

Activez l'authentification MFA

L'authentification multifacteur (MFA) est une méthode d'authentification simple à utiliser et efficace. Si vous activez l'authentification MFA, votre nom d'utilisateur, votre mot de passe et un code de vérification dynamique généré par un dispositif MFA sont requis lors de la connexion à la console Alibaba Cloud Management Console. Ainsi, en cas de divulgation de mot de passe, l'accès non autorisé peut être bloqué pour garantir la sécurité de votre compte Alibaba Cloud.

Activez l'authentification MFA pour votre compte Alibaba Cloud. Pour plus d'informations, consultez la rubrique Associer un dispositif MFA à un compte Alibaba Cloud. Vous pouvez également activer l'authentification MFA pour un utilisateur RAM. Pour plus d'informations, consultez la rubrique Associer un dispositif MFA à un utilisateur RAM.

Accédez à OSS à l'aide d'identifiants d'accès temporaires fournis par STS

Utilisez Security Token Service (STS) pour générer des identifiants d'accès temporaires afin d'autoriser un utilisateur RAM à accéder à vos ressources OSS pendant une période déterminée. Cette approche vous dispense de partager votre paire AccessKey, ce qui renforce la sécurité des données.

Pour savoir comment accéder à OSS à l'aide d'identifiants d'accès temporaires fournis par STS, consultez la rubrique Utiliser les identifiants temporaires fournis par STS pour accéder à OSS.

Configurez des stratégies de bucket

Configurez des stratégies de bucket pour accorder à d'autres utilisateurs les autorisations d'accès à des ressources OSS spécifiques dans un bucket. Par exemple, vous pouvez configurer des stratégies de bucket pour accorder à d'autres comptes les autorisations d'accès ou de gestion de toutes les ressources ou d'une partie des ressources de votre bucket. Vous pouvez également configurer des stratégies de bucket pour accorder différentes autorisations à différents utilisateurs RAM d'un même compte.

Lorsque vous configurez des stratégies de bucket, respectez le principe du moindre privilège (PoLP) afin de réduire les risques de sécurité.

N'accordez pas aux utilisateurs les autorisations d'accès à toutes les ressources de votre bucket

Pour éviter les autorisations excessives et les accès illégaux, nous vous recommandons d'accorder des autorisations uniquement sur les chemins de ressources requis.
N'autorisez pas l'accès anonyme

Les comptes anonymes peuvent être utilisés pour accéder à OSS si un endpoint et un nom de bucket sont fournis. Toutefois, les endpoints peuvent être énumérés et les noms de bucket peuvent être obtenus à partir des URL des objets auxquels les comptes peuvent accéder. Par conséquent, l'accès anonyme augmente les risques de sécurité.
Spécifiez Action

Lorsque vous configurez une stratégie de bucket dans la console OSS, Action, qui propose quatre opérations d'autorisation, constitue uniquement une méthode pratique pour configurer les stratégies ; l'action spécifiée peut ne pas répondre à vos besoins métier. Nous vous recommandons d'accorder uniquement les autorisations requises aux utilisateurs via les Paramètres avancés. Par exemple, les autorisations en lecture seule incluent oss:ListObjects et oss:GetObject. Dans la plupart des scénarios, seule l'autorisation oss:GetObject est nécessaire si vous souhaitez télécharger un objet.
Activez HTTPS pour l'accès

Activez HTTPS pour résoudre des problèmes tels que les attaques de type « man-in-the-middle » et le détournement de domaine. De plus, si vous utilisez Google Chrome pour afficher un site web HTTPS, les ressources HTTP du site ne peuvent pas être chargées par défaut. Assurez-vous d'activer HTTPS. HTTPS est la méthode la plus rentable pour résoudre divers problèmes.
Spécifiez les adresses IP sources

Si les adresses IP utilisées pour accéder aux ressources OSS sont fixes et peuvent être énumérées, nous vous recommandons de configurer les adresses IP.

Par exemple, vous pouvez utiliser une stratégie de bucket pour accorder à l'utilisateur RAM Test les autorisations de téléchargement de tous les objets du répertoire log dans examplebucket à l'aide des SDK OSS ou de l'outil de ligne de commande ossutil.

Définissez Action sur Paramètres avancés et sélectionnez oss:GetObject. Définissez Effect sur Allow. Dans la section Condition, sélectionnez HTTPS pour Méthode d'accès et saisissez 10.10.10.10 pour IP =. Cliquez ensuite sur OK.